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, you should build against the event type that best suits your workflow.
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 (for example, instead of
elements, CDA uses
), 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.
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.