Skip to main content
Version: v0.1.10

Built-in profiles

Eight profiles ship on the profiles object. Each is defined with the public defineProfile() API, so you can use one directly (parseHL7(raw, profiles.epic)) or extend it (defineProfile({ name: "mine", extends: profiles.epic })). Use and write vendor profiles shows both.

ProfileSenderDate formats it addsZ-segments it declares
profiles.epicEpic Bridges InterconnectMM/DD/YYYY HH:mm:ss, MM/DD/YYYYZDP, ZRS
profiles.cernerCerner MillenniumYYYY-MM-DD[T]HH:mm:ss, YYYY-MM-DDZDS, ZCO
profiles.meditechMEDITECH MAGIC, 6.x and ExpanseYYYYMMDDHHmmZF1, ZF2
profiles.athenaathenahealthMM/DD/YYYYZCA
profiles.genericLaba reference laboratoryYYYYMMDD HHmm, YYYY-MM-DDZLB, ZNT
profiles.visageVisage 7 imaging (PACS)noneZDS
profiles.philipsPhilips Vue PACS (IS Link)noneZDS, ZLK, ZAO, ZEB, ZAP, ZAV
profiles.vaVA VistA Radiology and Nuclear MedicinenoneZDS
import { profiles } from "@cosyte/hl7";

Object.keys(profiles).sort(); // => ["athena", "cerner", "epic", "genericLab", "meditech", "philips", "va", "visage"]
profiles.meditech.dateFormats; // => ["YYYYMMDDHHmm"]
Object.keys(profiles.philips.customSegments ?? {}); // => ["ZDS", "ZLK", "ZAO", "ZEB", "ZAP", "ZAV"]

Where each profile comes from​

Four profiles are grounded in a public interface specification, cited in the profile's source:

The other four (epic, cerner, athena, genericLab) carry formats and Z-segments common in those senders' feeds and cite no published specification. Check one against your own sender's interface specification before you rely on it, and extend it where your feed differs.

The Z-segments and their field names​

Each name reads with seg.get(name) once the profile is applied.

ProfileSegmentField names (position)
epicZDPdepartmentCode (3), departmentName (4)
epicZRSresultStatus (1), statusDateTime (2)
cernerZDSsummaryText (3)
cernerZCOcommentText (3), continuationFlag (5)
meditechZF1providerEncounter (1), misServiceGroup (2), serviceGroupCopay (3), visitCopay (4), copayMinimum (5), copayMaximum (6)
meditechZF2setId (1), providerEncounter (2), encounterDate (3), encounterProcedure (4), encounterProcedureQuantity (5), encounterProcedureCharge (6), prvProcedureAmountPaid (7), prvProcedureAmountDue (8)
athenaZCAcareTeamRole (3), providerId (5), providerName (6)
genericLabZLBspecimenOverride (3), methodOverride (5)
genericLabZNTnoteText (3)
visageZDSstudyInstanceUid (1)
vaZDSstudyInstanceUid (1)
philipsZDSstudyInstanceUid (1)
philipsZLKexternalWorkitemId (1), orderLinkId (2)
philipsZEBencryptedPatientInfo (1)
philipsZAVvisitAdditionalDetails (1)
philipsZAO31 fields, from orderAdditionalDetails (1) to acquisitionStatus (32): modality, body part, transfer and acquisition status, technician and radiologist
philipsZAP13 fields, from patientAdditionalDetails (1) to patientCustomDate3 (14)

ZDS in the three imaging profiles carries the DICOM Study Instance UID, which ties an HL7 order to its imaging study. In cerner, ZDS is a different segment that happens to share the name: a discharge summary. profiles.philips.customSegments lists every ZAO and ZAP field.

Reference​