When do I need to use the ClinicalSummary data model?
If your application is looking to receive a patient’s clinical information, either historical or in real time, then our ClinicalSummary data model is for you. This model is based on documents that are formatted using Clinical Document Architecture, or CDA documents. We can map any CDA document type to our ClinicalSummary data model but the most common is the Continuity of Care Document, or CCD. Ultimately these documents and the standards behind them are pretty complex so there are some things that you should know if our ClinicalSummary is something you will need to consume or generate.
Patient vs. Visit summary endpoints: What’s the difference?
Some CDA documents are visit-level and have data specific to one visit included in their headers; we map these documents to our visit summary event types. CCDs specifically can be either visit-level or patient-level. It is also important to note that a document we map to our visit event type will still contain patient-level information like the patient’s problem list, allergies and medications list. Conversely, documents we map to our patient-level events will still contain encounter-level information, like recent Encounters, Procedures, Results, and Vital Signs. This brings us to our next question…
How much encounter information is included in patient-level documents?
This varies per health system and we won’t know their configurations until we start speaking with them regarding the integration project. In a lot of cases, these sections contain data spanning the most recent 1-3 months.
Push vs. Query events: Which do I build against?
CDA documents can either be queried at any time or pushed, which typically happens at the end of a visit. Some EHRs can support both methods while others may just support one or the other. If you know your first integration site’s EHR vendor let us know and we can talk through what we’ve seen that EHR support. Ultimately, however, if you’re unsure what your connections will be able to support then you should build against the event type that best suits your workflow, understanding that changes may need to be made down the road to accommodate what your partners can support.
What if I query for a visit summary during the visit?
In the integrations we’ve implemented with EHRs that support visit summary queries, querying for the visit summary during the admission before the patient has been discharged returns most documented data in a “final” state, like a signed note. Not all documented data may be returned; in our experience the MedicationsAdministered section in particular may only return the last three medications administered to the patient.
What’s the difference between the Medications section and the MedicationsAdministered section in the visit summary?
The Medications section, available in both the patient and visit summaries, is the list of medications the patient is currently marked as taking, which includes any prescribed medications as well as any patient-reported medications. The MedicationsAdministered section, available in visit summaries, details any medications administered to a patient during an inpatient stay.
Can I push a ClinicalSummary back into an EHR?
The short answer is absolutely! The longer answer is that when you post a ClinicalSummary message to Redox, each EHR will receive and consume the corresponding CCD document that we send differently. Some systems will be able to integrate elements of a pushed CCD discretely while others will simply attach the summary document as a whole to the patient’s chart so it’s important to keep in mind this might vary across your integrations.
What are these Text nodes?
CDA documents contain two types of information: human-readable text called a narrative and machine-processable discrete data. Most of our data model (like codes and timestamps) is oriented around the discrete fields, but it is possible for a CDA to contain additional information in the narrative. Some sections such as Reason For Visit or Chief Complaint may be only textual. Redox presents this information to you in the Text nodes as they were originally present in the CDA. The format is HTML-esque XML, but we can easily convert this into pure HTML or even plain text for you. Similarly, when you push a ClinicalSummary into an EHR, you can provide these textual summaries for your data. It’s worth noting you don’t have to, though, as our engine will automatically generate a narrative based on the fields you provide.
Can I get ICD-10 for problems?
Meaningful Use requires SNOMED, so most EHRs use this as the default codeset for CCDs. However, many EHRs support sending ICD-10 in addition to SNOMED, so it’s usually possible but may require an update on the EHR side.
What communication methods will EHRs use to send CDA documents to Redox?
There are several different ways in which a CDA documents can be transmitted and the method used for a given implementation will be dependent on what the EHR in question supports.
What can I expect to receive from Redox when a patient doesn’t have information for a section (eg: allergies, medications) in the EHR?
If we don’t receive any information back for that section or get a null flavor (an indicator from the EHR that they’re aware there is nothing in that section), you will receive an empty array. If the health system sends a value to specifically state that they don’t have any data to send (eg: “No known medications” or “Data not captured”), you will see that as an item within the array.
Anything else I should be aware of?
Some Epic organizations may require documented patient consent before making their CCD and other clinical documents available. If you initiate a ClinicalSummary query for a patient who does not have documented consent at these sites the query will return an error.
Keep in mind that we’re happy to talk through the above in more detail as we scope your integration project but this should at least give you an understanding of the nuance and variability we might come across during integration projects involving CDA documents and our ClinicalSummary model.