How does health information exchange support Epic analytics?

An outside provider's record can add information that a local Epic extract does not contain. It can also describe an event already represented in the local system. Before counting the records together, the analyst needs to know which situation applies.

The received information needs to become usable in the analysis. Retaining its source and explaining its relationships are part of that work. A measure can then combine the records under a stated definition.

Exchange and analytical use

Establish what a received record adds to the question. A document, notification and reporting row can describe the same care with different fields and timing. Their relationship determines how each contributes to the evidence.

Health information exchange, or HIE, supports sharing across organizations, as the HealthIT overview explains. For an analytical project, the next task is to identify which received information belongs in the proposed population and measures.

Keep the originating system and its identifiers with the received record. An analyst can use them to distinguish a new event from another account of an existing event. Uncertain relationships need review before they contribute to a shared count.

Test the information received against the intended analysis. A feed built for one workflow may lack the detail or history another needs. Establish the approved use and examine those fields before preparing the combined dataset.

HL7 messages and FHIR resources

HL7 develops both Version 2 messaging and FHIR. Version 2 messages commonly carry events between healthcare systems. The receiver parses the fields and uses its implemented interface rules to interpret them.

The interface must establish what a local code means, which system issued an identifier and what a timestamp represents. Correct parsing is the starting point for this interpretation. The mappings supply the context needed to use the message.

FHIR means Fast Healthcare Interoperability Resources. It represents information in resources such as Patient and Observation; R4 is one release. The FHIR R4 overview explains the model and its use alongside other exchange standards.

FHIR also supports bulk data specifications. Assess the content and access patterns implemented and authorized by the actual source. In particular, determine which local fields it exposes for the proposed work.

The records an Epic analysis needs

Locate the fields, history and freshness the Epic analysis needs. Clarity provides relational reporting data on the institution's refresh schedule. Caboodle supplies structures for subject areas implemented locally. An event feed may deliver relevant information on another timetable.

Use Epic's FHIR catalogue to locate relevant resources and operations. Then test the fields and applicable bulk access in the proposed interface. That establishes whether it can supply the evidence for a defined application.

For a broad cohort or local measure, the proposed API may omit detail that Clarity contains. FHIR can supplement the extract in that case. Establish the required coverage before replacing an analytical route with an API.

A feed and extract can be useful together. HL7 messages arrive as the interface sends events; a Clarity extract represents data at its reporting cutoff. Account for the timing and any overlap when they contribute to the same analysis.

Trace a representative record through the proposed route and locate every required attribute. Include the earlier values the analysis needs. The route's implemented coverage determines whether it can serve the question.

Matching records without losing their source

Resolve both the patient relationship and the event relationship before combining counts. Two records can belong to one person while describing separate encounters. The rules for identifying a shared patient cannot, on their own, establish a shared event.

Retain source identifiers alongside any shared identifier. When a match changes, the team can then investigate which source records contributed to the earlier result. A shared identifier without that history makes discrepancies harder to explain.

Keep the event date and arrival date separately. If Monday's encounter arrives on Tuesday, an activity report follows when the care occurred. A report about information available on Monday needs the arrival history instead. The definition determines which date governs the result.

Keep raw values when normalizing terminology or units. Leave uncertain identities and unmatched codes visible for review. The cohort definition should explain how these exceptions affect its count, so recipients understand the records represented.

A local code mapping also needs a period of applicability. If a source changes how it uses a code, retain the earlier mapping with the records it described. Applying only today's interpretation can change a historical measure even when no additional events have arrived. Test that case when maintaining the combined dataset.

Operating the combined dataset

Keep the dataset's interpretation current as its sources change. A transfer can succeed while a code or relationship changes underneath a measure. Test the affected calculations before sharing the revised result.

Follow the proposed record through exchange, interface processing and institutional analysis when evaluating a platform. Establish which parts the provider implements and maintains. This identifies the remaining work between a functioning connection and a usable result.

Databasin connects Epic and other sources, implements local mappings and builds governed views. Its team also delivers reporting and supports its use. The institution's available exchange feed or API supplies outside records for preparation alongside the local data.

Try a delayed message, uncertain match and source correction before starting recurring delivery. Each should produce an understandable status for the operator and recipient. That tests how the maintained dataset handles the changes it will encounter.

Example: one event arriving through two routes

This illustrative sequence follows a discharge through a local extract and a later exchange record. Before counting it, the team must establish whether the records describe the same event.

Keeping both dates and source identities lets the team explain its count. If the encounter relationship is uncertain, the record follows the review rule until that question is resolved.

Before combining the records

1. Establish the analytical purposeEstablish the question and approved use. Identify the evidence outside records add to what the institution already holds.
2. Test source coverageTrace the required fields and history through the interface, including local customizations. Establish the source cutoff the analysis will use.
3. Resolve identities and timesSet separate rules for matching patients and events. Keep source identifiers and both event and arrival times for later investigation.
4. Plan continuing operationTry delayed records, uncertain matches and corrections. Define who resolves each exception and how recipients see an incomplete result.

Sources