Provide a consistent structure for top-level feedback, suggestions, and decisions

[jmandel]

Right now our suggestions and decisions share a lot of structure. We should formalize this to
include uuid, label, create and delete, as well as two new
optional elements (assessment and about). This gives us a pretty goood base structure
that can be used for suggestions, decisions, and top-level feedback. Here's the rough idea:

Add a new top-level feedback

At the top level of CDS Hooks response, we define a new array-valued feedbaack property, where
each feedback item follows the augmented suggestion structure. For example:

{
  "decisions": [],
  "cards": [],
  "feedback": [{
    "uuid": "c91554be-a7ec-4067-b544-33efabffe9d6",
    "about": ["ProcedureRequest/123"],
    "assessment": {
      "rating": {
        "value": 4,
        "unit": "Rating Scale",
        "system": "https://acr.org"
      },
      "radiation": {
        "value": 3,
        "unit": "Relative Radiation Level",
        "system": "https://acr.org"
      }
    }
  }]
}

The specific assessement properties ("ratings", "radiation") would be hook-specific,
so here I'm imagining a "radiology imaging order" hook...

Individual suggestions can be decorated with assessments, too

Same structure applies to any given suggestion in a suggestion card:

{
  "suggestions": [{
    "uuid": "c91554be-a7ec-4067-b544-33efabffe9d6",
    "delete": ["ProcedureRequest/123"],
    "create": [{"resourceType": "ProcedureRequest", "code": {}}],
    "assessment": {
      "rating": {
        "value": 4,
        "code": "appropriateness-scale",
        "system": "http://acr.org"
      },
      "radiation": {
        "value": 3,
        "code": "relative-radiation-scale",
        "system": "http://acr.org"
      }
    }
  }]
}

And of course decisions

The items in a decisions array could also be decorated with this same structure.
I won't repeat here, for brevity...

{
  "cards": [],
  "decisions": [{
    "uuid": "c91554be-a7ec-4067-b544-33efabffe9d6",
    "delete": ["ProcedureRequest/123"],
    "assessment": {
      "rating": {
        "value": 4,
        "unit": "Rating Scale",
        "system": "https://acr.org"
      },
      "radiation": {
        "value": 3,
        "unit": "Relative Radiation Level",
        "system": "https://acr.org"
      }
    }
  }]
}

[robs16]

In general, I like the solution. It provides an answer to where to put the data discussed in #13. It also provides the reference in the 'about' field which is requested in #20. However I think it should also be available at the card level similar to the top level feedback (at the card level it should include the 'about' in addition to the assessment).

[bkaney]

This could be nice. The approach we've been trying is to provide this sort of structure in the FHIR resources embedded in the decision. This can be difficult.

Related note, I think this group should look at JSON Schema (http://json-schema.org) to specify all the structures in CDS Hooks. This could allow us to iterate on things like this (and #26) in a less "example-driven" manner. I'd be happy to do a PR with a JSON schema representation of the current state of master, if that's helpful.

[brynrhodes]

I'm a little concerned about modeling things like assessment and radiation directly as part of the CDS Hooks service API. I thought one of the advantages of having CDS Hooks be separate was that we could leverage the clinical modeling in FHIR, and avoid modeling those items in CDS Hooks directly.

[isaacvetter]

@brynrhodes - I think that makes a lot sense. The assessment/score value isn't obviously part of the clinical/business model, though. Is there a reasonable and established way that we can include this score as part of the business model?

[ElliotSilver]

Echoing @brynrhodes, I hope that inclusion of radiation was just an example, and not an indication of intent to model radiation dosing. If you decide to head down that route, please contact HL7 Imaging Integration to discuss the complexities involved.

[brynrhodes]

@isaacvetter - Here's a link to the extension defined as part of QI-Core that supports identifying the assessment score as part of a GAO request/response. The idea is that the ProcedureRequest that was submitted as the procedure being assessed is returned with this assessmentScore extension applied:

appropriatenessScore

[isaacvetter]

Closing in favor of #64

[robs16]

@isaacvetter Does the fix in #64 cover all of the above need, or is the expectation to implement that as well as the solution in #64?

[isaacvetter]

@robs16 - good point. The idea is that the approach in #64 should cover all of the above need. I'm modifying the above comments from "Fixing" to "Closing in favor of".

Sounds reasonable? What do you think?

Isaac

[robs16]

I saw two features combined in the original solution:

1. Scoring
   I thinks this works in the general sense - however there is an important workflow issue here - For the case where the user can dismiss the dialog or ignore it, there must be a default/dismiss suggestion that is taken in this case. To put another way, the only time a rating should not be applied is when the triggering order/etc was deleted. Without a default/dismiss suggestion, there is no way for the appropriate rating to be retrieved by the EHR. This further requires some form of 'type' of suggestion as mentioned in Add a Suggestion Type #21, such that the EHR can understand which suggestion is the default/dismiss.

2. About
   As mentioned in my comment at the top of this issue I could see the original solution solving Resources related to a card #20 also. This solution does not cover that need.

[brynrhodes]

On issue 1, I agree that there's still a need for some sort of response processing, but since that's not part of the 1.0 scope, we can address it when we resolve #21. Within the 1.0 timeframe, the use case could be addressed with extensions and pre-coordination.

On issue 2, agree that a resource pointer would be useful, but also out of scope for 1.0, so we can address when we resolve #20.

[kpshek]

It's worth noting that we will address #76 for 1.0 which will allow developers who want to address these types of scenarios with CDS Hooks today the ability to do so.