Messaging Overview

Work Flow
3. Patient attends the appointment and doctor order for
tests

5. Consultant fee information is sent to billing system

1. Patient goes to the hospital to book an

appointment

Electronic Health Record

7. Bill is generated

8. Patient is given the

bill

Patient Administration System Billing System

2. Patient is registered and an appointment is booked

Laboratory System
4. Sample is received

6. Lab test fee information is sent to billing system

2
 HOW?
Data flows between the different systems

3. Patient attends the appointment and doctor order for

tests

5. Consultant fee information is sent to billing system

1. Patient goes to the hospital to book an

appointment

Patient Data Fee charges

Appointment details Electronic Health Record

Order
7. Bill is generated
Patient Data
2. Patient is registered and an appointment is 8. Patient is given the
booked bill

Patient Administration System Billing System

Test charges
Patient Data

Laboratory System
4. Sample is received

6. Lab test fee information is sent to billing system

3
• HL7 messages are used to transfer data electronically between various healthcare providers.
• Think of it as a special language healthcare systems use to talk to each other.
• These messages are sent whenever an event happens with a patient, such as
o Registration
o Admitting to the hospital
o ordering them a prescription etc

4
Health Level Seven
(HL7) Overview

5
What is HL7?
• HL7 refers to a set of international standards for transfer of clinical and administrative data between software applications used by various healthcare
providers.
• HL7 standards are produced by the Health Level Seven International, an international standards organization, and are adopted by other standards issuing
bodies such as American National Standards Institute and International Organization for Standardization.
• Hospitals and other healthcare provider organizations typically have many different computer systems used for everything from billing records to patient
tracking. All of these systems should communicate with each other. when they receive new information or when they wish to retrieve information, but not
all do so.
• HL7 International specifies a number of flexible standards, guidelines, and methodologies by which various healthcare systems can communicate with
each other. Such guidelines or data standards are a set of rules that allow information to be shared and processed in a uniform and consistent manner. These
data standards are meant to allow healthcare organizations to easily share clinical information.
• Theoretically, this ability to exchange information should help to minimize the tendency for medical care to be geographically isolated and highly variable

6
Types of message standards

• V2 – Messaging
V2 Asynchronous messages. These type of messages we mainly use in out bound as we follow fire and
forget model.
• V3 - Messaging
It is a secure and synchronous text messages. Mostly this is used in case of Inbound messages where
we require ACK or NACK to be sent back to the system based on the outcome of the message
FHIR V3 processed. Example is PDS Messaging.
HL7 • CDA (Clinical document Architecture)
Message It is an XML based mark up standard. It is intended to specify the encoding, structure and semantics of
Standards clinical documents.
• CCOW, or "Clinical Context Object Workgroup
It is a standard protocol designed to enable disparate applications to share user context and patient
context in real-time, and at the user-interface level
CCOW CDA
• FHIR
Fast Healthcare Interoperability Resources. It leverages a modern web-based suite of API technology,
including a HTTP-based RESTful protocol, HTML and Cascading Style Sheets for user interface
integration, a choice of JSON or XML for data representation, OAuth for authorization and ATOM for
query results.

7
Types of message
• ADT
Admit Discharge Transfer messages. ADT messages within the HL7 standard are typically initiated by the Hospital Information Systems (HIS), or a
registration application, to inform ancillary systems that a patient has been admitted, discharged, transferred, merged, that other demographic data about
the patient has changed (name, ins(patient location, attending doctor, etc.).
• MDM
Medical document management messages . The Medical Document Management (MDM) transaction set supports transmission of new or updated
documents or information about their status
• REF
Referral messages. It supports the transmission of referral related data.
• ORM
Order Messages. The function of this message is to initiate the transmission of information about an order. This includes placing new orders, cancellation
of existing orders, discontinuation, holding, etc.
• ORU
Observation results Unsolicited. Used to return the finished transcriptions to the client using Observation Result

8
Types of message
• QBP
Query By parameter. This is an synchronous message for which a query will be sent to the external and get the response.
• RSP
Response message for the QBP Message
• MFN
Master file notification. This message is used to send messages to external systems regarding user and organization updates.
• SIU
Scheduling Information Unsolicited. This message is mainly used to send or receive about scheduling activities.
• ACK/NACK
Acknowledgement / Negative Acknowledgement messages.

9
Message Structure
MSH|^~\&|CSCLRC|RY1|TIE|RY1|20170418072110|Esakki02|ADT^A02^ADT_A02|600000410910|P|2.4|54145||AL|AL|GBR||||LZO_R2 _4
EVN||20170418072110||IBS-C||20170418071400
PID|1||PASID-001696^^^RY1^FACIL^RY1||Prime^Prime^sdfsd^sdfsdf^MR||19930729000000|M|||fsddsf^dfd^sdffsd^^45474^UK^HOME^fdf^fsfsdf||
^H^Internet^adfada@test.com~+567987684654^PHONE^Telephone~+4567788976876^MOB^Cellular Phone|+489786786786^WKTEL^Telephone||S|G2|||||HINDU|vcbgdsdf|
SINGL||||10||N||Y~""~""
PD1|||SI Acute^^RY1^^^^NATNL|22133014^rajakumar^bharani^^^^^NATNL^^^600000189299||||||||
PV1|1|I|AWard123^AFloor123^AFloor123^RY1^HIGHSEC^FLOOR^^^AWard123|28|EPI-309^^^RY1|
AWard123^AFloor123^AFloor123^RY1^IC^FLOOR^^^AWard123||Nat-5057^tmagham^Good^^^MRS^^NATNL^RY1^^600000189686~UUI-
5057^tmagham^Good^^^MRS^^SDSID^^^600000189686~Tmaincode-5057^tmagham^Good^^^MRS^^TMAINCODE^RY1^^600000189686|uui
rd2782^Das^Raga^^^MS^^SDSID^^^600000170043~RagaDas1^Das^Raga^^^MS^^NATNL^^^600000170043|710||||79|||uui
rd2782^Das^Raga^^^MS^^SDSID^^^600000170043~RagaDas1^Das^Raga^^^MS^^NATNL^^^600000170043|NHS|Enc.0164^^^LRC_ENCOUNTER|||||||||||||||||||||||||
20170418071300||||||1000000020251|L
PV2|||3|CAREPRVRECOMND|||||20170420071300
ZU1||8|||||||||||||||||||||||||||||710

10
Parts of message
• Segment
Each segment starts with a 3-letter label like MSH,EVN,PID,PV1,AL1,DG1,PR1.
• Data Field
Each segments is divided into fields separated by a pipe character (|). In the example below, it shows that the segment PID is composed of 10 fields with
some fields missing.

• Component/Subcomponent (optional)
Fields are further divided into sub fields which are separated by a caret (^) character as shown below.

11
Message segments
• MSH – Message Header
• EVN – Event details
• PID – Patient Identifier Details
• PD1 – Patient Demographic Information
• NK1 – Next of Kin
• IN1 – Insurance details
• PV1 – Patient Visit Information
• PV2 – Additional Patient Visit Information
• AL1 – Patient Allergy Information
• DG1 – Diagnosis Information
• PR1 – Procedure information
• OBX – Observation result
• QAK – Query Acknowledgement

12
Message segments
• QPD – Query Parameter Definition
• ROL – PV1 and PD1 care providers mapping
• RF1 – Referral Information Segment
• PRD - Provider Data Segment
• PRA - Practitioner Detail
• NTE - Notes and Comments Segment
• MFI - Master File Identification
• MFE - Master File Entry
• MRG - Merge Patient Information
• ZU1 – Additional UK data
• ZU4 - Additional UK Data – Waiting List
• ZAC – Additional Australia Data – Acute care certificate

13
Field separators
• | - Field separator, aka pipe
• ^ - Component separator, aka hat
• & - Sub-component separator
• ~ - Field repeat separator
• \ - Escape character

14
Lorenzo Messaging

15
High level architecture of Lorenzo
User Interface Messaging

Web Service

HO

BC

HO

DAC

Parameters

DAE

Parameters
HO – Health Object
BC – Business Component
Data base DAC – Data Access Component
DAE – Data Access Engine

16
Lorenzo Messaging Architecture
LAA External
Lorenzo MHS TIE Trust TIE
Sequence Systems

IXML

IXML

Message

Message

Message

Message

Message

Message

IXML

HO

17
Lorenzo Integration Services

ADT Inbound Messaging

ADT Outbound Messaging

ADT R&R Messaging

Query Messaging

PDS Messaging
eRS Messaging
LRS Messaging

Desktop Integration

18
Lorenzo Messaging
Configuration

19
Configuration Setup

Trading Partner & Communication Profiles

Interface Profiles Transmission Profiles Localisation Reference Data

20