Skip to main content

HL7v2

How Vital integrates using HL7v2.

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, our integration solutions enable streamlined data exchange processes, accelerated interoperability, and enhanced patient care coordination.

EHR Agnostic

Our system supports all segments and fields. Our 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, we recommend filtering on PV1.3.1 and PV1.6.1 where these equal the appropriate ED department values.

  • This allows us to track the patient's visit and end it as soon as they are admitted or transferred.

  • For Vital Inpatient, we recommend filtering on PV1.3.1 and PV1.6.1 where these equal the in-scope department values.

  • Similarly, this allows us to track the patient's visit and end it as soon as they move outside of an in-scope location.

  • We recommend providing all note types relevant to the ED workflow as well as all note statuses.

  • In progress notes inform us 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 T for Test or P for 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.

Did this answer your question?