HL7v2 is the most widely adopted standard for healthcare data exchange with approximately 95% of US healthcare organizations relying on HL7v2. By leveraging this standard, the Vital integration enables streamlined data exchange processes, accelerated interoperability, and enhanced patient care coordination.
EHR Agnostic
The Vital system supports all segments and fields. The minimum required specifications can be found for each interface below.
Required Interfaces
Click for more information on each interface.
*For Cerner clients where location information is unavailable via the ADT.
Best Practices
Data Filtering
For Vital Emergency, Vital recommends filtering on PV1.3.1 and PV1.6.1 where these equal the appropriate ED department values.
This allows Vital to track the patient's visit and end it as soon as they are admitted or transferred.
For Vital Inpatient, Vital recommends filtering on PV1.3.1 and PV1.6.1 where these equal the in-scope department values.
Similarly, this allows Vital to track the patient's visit and end it as soon as they move outside of an in-scope location.
Vital recommends providing all note types relevant to the ED workflow as well as all note statuses.
In progress notes inform Vital of the patient's progression throughout the ED and can be more timely than authenticated/final notes.
ADT Data Elements
MSH.4 contains an identifier that is unique per facility.
MSH.6 contains an interface identifier - this is documented in each of the specifications above.
The control ID in MSH.10 should be unique across all facilities and feeds.
The processing ID in MSH.11 should contain a
Tfor Test orPfor Production.PID.2/PID.3 should only contain the patient's MRN, both at a facility and Enterprise level.
This should be consistent across all interfaces/feeds.
The identifier type code should be specified.
The telephone use code in PID.13.2 should be specified in any repetition.
The visit number in PV1.19 should be consistent across all interfaces/feeds.
If there is an alternate visit number in PV1.50, this should be consistent across all interfaces/feeds.
ORM Data Elements
Universal Service Identifier on ORMs should be SNOMED or LOINC (if available).
Order ID (OBR-2) should be consistent between Orders and Results.
Order Code (OBR-4.1) should be consistent between Orders and Results.
ORU Data Elements
Observation Identifier Coding System on outbound Results should be LOINC.
Order ID (OBR-2) should be consistent between Orders and Results.
Order Code (OBR-4.1) should be consistent between Orders and Results.