Comments (5)
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.
from docs.
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?
from docs.
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?
from docs.
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.
from docs.
Should this issue be closed in light of @brynrhodes 's PR #64 and the resulting http://cds-hooks.org/examples/#radiology-appropriateness ?
from docs.
Related Issues (20)
- transition from 1.0 to current HOT 3
- Patient-view: context.encounter should be named encounterId HOT 2
- Patient-view: encounter access HOT 4
- Patient-view and risks for inappropriate advice HOT 3
- CDS Hooks Dynamic Behavior HOT 3
- Add guidance on the access of data referred to be id's in hook context.
- `selectionBehavior` is conditionally required, not `OPTIONAL`
- Issue with building using Python 3.8
- `context.userId` is inconsistent and should almost always be `PractitionerRole` HOT 2
- FHIR Data Types HOT 2
- Provide more specific guidance on the Bundle needed for draftOrders HOT 2
- Context.userId containing ResourceType and ResourceId causes problems HOT 33
- Improve clarity on how to propose a new hook
- Discuss industry-used override reasons
- Discuss industry-used card topics
- Document Best Practice considerations regarding how much to prefetch
- Capturing Feedback for SMART App Launches
- CDS Client capability endpoint proposal
- CDS Specification Version is ambiguous in the 2.0 specification
- Support for Relative Dates in Prefetch
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from docs.