Flesh out a guideline appropriate ordering scoring data flow

[isaacvetter]

Guideline appropriate ordering scoring cds services generate a score that rates the appropriateness of a particular order as well as a unique identifier that can be used to reference the advice after the fact.

In some cases, this score can be used to bypass prior authorization or in billing claims.

In the case where an alternate order (or perhaps even the same order?) is being recommended, a suggestion could be used and the existing uuid can identify the advice.

There's not a clear-cut location for the external GAO cds-service to return the score as a discrete piece of data.

This could be a significant use-case. It would be nice to accommodate it.

[robs16]

Agreed. This will also be necessary for PAMA. I believe the score should be provided on a per-order basis. Support for multiple code systems which impact a single order may be required, so I see this as a CodeableConcept.

[bdoolittle]

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

[jmandel]

Thanks @bdoolittle — 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?

[bdoolittle]

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 that the data is an appropriateness score for PAMA 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.

[isaacvetter]

Should this issue be closed in light of @brynrhodes 's PR #64 and the resulting http://cds-hooks.org/examples/#radiology-appropriateness ?