When do I use the ClinicalDecisions Data Model?
If your application is looking to deliver real-time, immediate clinical decision support (CDS) to providers, then the Redox ClinicalDecisions Data Model may be a good solution to leverage. There are a myriad of potential use cases that could use the ClinicalDecisions model, such as recommending alternative medications and procedures or identifying drug-drug interactions at the point of ordering.
What triggers the initial ClinicalDecisions Request message?
This will vary depending on the use case and will be configured within the EHR alert setup – e.g. an alternative medications alert would be configured to fire when a provider attempts to sign an order, or an alert regarding a possible chronic condition might fire based on a patient’s vitals history when a new set is documented.
Will the alert always display to the provider?
It doesn’t have to! The application responding to the request from the EHR can set Advisories.ShowAlert to False.
What actually appears to the provider if Advisories.ShowAlert is set to True?
The application responding to the request from the EHR can specify the alert text by setting Advisories.Description field.
What if more information is needed?
The responding application can include an external link for the provider to access and provide the necessary data. This link can be sent in the field Advisories.AdditionalInfo.Link.
What are those question and answer fields?
The question and answer fields correspond to any custom Ask at Order Entry (AOE) questions the provider may have filled out when placing an order. This applies to CDS workflows triggered by the placing of medication or procedure orders, where the healthcare organization can configure AOE questions to appear for certain orders to ensure the application responding to the CDS request has all of the data it needs.
What EHRs support the ClinicalDecisions model?
The connecting EHR in a ClinicalDecisions flow needs to have a corresponding CDS API that can map to the Redox ClinicalDecisions model. The ClinicalDecisions model was built based on the FHIR/CDS Hooks specification, which has the potential to be supported agnostically across different EHR vendors. Currently we have only seen Epic EHRs have such a web service available.
How does the ClinicalDecisions Data Model differ from the SSO Data Model?
Both the ClinicalDecisions and SSO Data Models involved workflow embedded bi-directional exchange. However, they differ in several capacities:
- Trigger Point
- ClinicalDecisions is typically triggered from the EHR via a normal workflow step such as ordering or adding of a problem.
- SSO is typically triggered from the EHR via a specially configured button made available within the right EHR module.
- Returned Content
- ClinicalDecisions returns discrete data that the EHR can utilize as part of an alert to advise on the user’s behavior.
- SSO returns a URL that the EHR can launch for the user.
We’re happy to talk through the above in more detail as we scope your integration project!