FHIR Chat · docs / Issue #48 Provide a consistent structure for top-l... · cds hooks/github

Stream: cds hooks/github

Topic: docs / Issue #48 Provide a consistent structure for top-l...

---

Github Notifications (May 09 2017 at 12:28):

jmandel opened Issue #48

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"
      }
    }
  }]
}

Github Notifications (May 24 2017 at 16:02):

robs16 commented on Issue #48

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).

Github Notifications (May 30 2017 at 21:35):

bkaney commented on Issue #48

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

One 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 https://github.com/cds-hooks/docs/pull/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.

Github Notifications (Jun 05 2017 at 20:21):

kpshek milestoned Issue #48

Github Notifications (Jul 10 2017 at 20:21):

brynrhodes commented on Issue #48

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.

Github Notifications (Jul 10 2017 at 20:29):

brynrhodes assigned Issue #48

Github Notifications (Jul 10 2017 at 21:13):

isaacvetter commented on Issue #48

@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?

Github Notifications (Jul 11 2017 at 20:20):

ElliotSilver commented on Issue #48

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.

Github Notifications (Jul 13 2017 at 19:43):

bkaney commented on Issue #48

A note on decisions; in the case the decision indicates an item to be deleted, it makes sense to have the value be a string identifier. However, in the create case, we are finding it much more convenient (and less ambitious as to what the root URL / fhir-server is) if the resource is inlined (much like the context is.

Github Notifications (Jul 18 2017 at 23:10):

brynrhodes commented on Issue #48

@Isaac Vetter - 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

Github Notifications (Aug 04 2017 at 20:45):

isaacvetter commented on Issue #48

Fixing in #64

Github Notifications (Aug 16 2017 at 11:51):

robs16 commented on Issue #48

@Isaac Vetter 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?

Github Notifications (Aug 16 2017 at 20:21):

isaacvetter commented on Issue #48

@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

Github Notifications (Aug 16 2017 at 21:15):

robs16 commented on Issue #48

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 #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 #20 also. This solution does not cover that need.

Github Notifications (Nov 21 2017 at 22:46):

brynrhodes commented on Issue #48

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.

Github Notifications (Nov 21 2017 at 22:46):

brynrhodes closed Issue #48

Github Notifications (Nov 21 2017 at 22:48):

kpshek commented on Issue #48

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.

---

Last updated: Apr 12 2022 at 19:14 UTC