FHIR Chat · docs / Issue #13 Flesh out a guideline appropriate orderi... · cds hooks

Stream: cds hooks

Topic: docs / Issue #13 Flesh out a guideline appropriate orderi...

Github Notifications (May 06 2017 at 13:26):

bdoolittle commented on Issue #13

It would be really nice for the CDS-hooks spec to be supportive of regulations like PAMA, but it should do so in a generalized way that may apply to many different use cases making the standard more flexible. For PAMA, CDS-hooks would not only need to communicate an appropriateness score for an existing order, but would also need to provide suggestions with better appropriateness scores. One way that this could be achieved within in the hooks standard to support PAMA as well as many other things is by introducing the _data_ field (naming suggestions are welcome).

data: An array of JSONs or FHIR resources that provide additional information in a software consumable format

To support PAMA, the data field would probably need to be added to the card top-level as well as individual suggestions. I think such a field would also make sense in the context of links and decisions as well.

For individual cards:

{
    summary: 'PAMA Suggestions',
    indicator: 'info',
    data: [
        // This is an example of what data could look like,
        // not a proposal of what it should look like
        {
            type: 'PAMA Appropriateness Score',  // identifies what kind of data we are dealing with
            identifier: FHIRResource/123,  // identifies the order to which the score applies (id or FHIR resource)
            score: 37
        }
    ],
    suggestions: [ ... ]
}

Likewise, for individual suggestions:

{
    label: 'Replace Order',
    uuid: 'abc-123',
    delete: [ FHIRResource/123 ],
    create: [ FHIRResource/456 ],
    data: [
        // This is an example of what data could look like,
        // not a proposal of what it should look like
        {
            type: 'PAMA Appropriateness Score',
            identifier: FHIRResource/456,
            score: 79
        }
    ]
}

The same could work for links and decisions.

Introducing a generic 'data' field raises some questions:
- How do we define what the data looks like?
- Is there a standard that we can use within the spec?
- Does the hooks community define a bunch of supported data types?
- Do EHR and Vendor come up with their data structures outside of the spec?
- How do we handle different code sets and units of measure?
- Does a generic data field make sense in the hooks spec?
- Does it introduce too much flexibility and uncertainty?
- In addition to PAMA, what else could this field be used for?

Github Notifications (May 06 2017 at 13:42):

jmandel commented on Issue #13

Thanks @brian doolittle — this is real food for thought. One more question to add to the pile: what is the "meaning" of this kind of data? In other words, what is an EHR expected to do with them? Display them? Log them? Generate reports from them? Does an EHR need to understand them specifically?

Github Notifications (May 06 2017 at 14:22):

bdoolittle commented on Issue #13

For the PAMA use case, the score would be shown to the healthcare provider and used during the billing of its associated order. The EHR would need to understand what the score is to bill for it properly.

In general, data could be used for a variety of purposes including visualization, logging, and billing. The EHR would need to understand how to use the data and what the units of measure are.

Last updated: Apr 12 2022 at 19:14 UTC