MAHARASHTRA UNIVERSITY OF HEALTH SCIENCES ( MUHS)

HEALTH INFORMATICS
TOPIC – HEALTH LEVEL 7 ( HL7)

PRESENTED TO – DR. SANDEEP PARCHURE

PRESENTED BY – DR RADHIKA MOKASHI

DR SHARMILI GAWHALE
MUHS MBA( HCA)
4TH SEMESTER
 HIGHLIGHTS
2
• Why is Medical Standard needed ?
• What is Health Level Seven (HL7)?
• Purpose
• Timeline of HL7 Standards
• Scope of HL7
• HL7 Standards
• HL7 Message Standards
• HL7 Interfaces
• Understanding HL7 Message Structure
• Uses of HL7
• Benefits of HL7
• Limitations
3
4
5
Why is Medical Standard needed ?

• In order to reduce disconnects between all healthcare

systems, there must some standard to achieve
interoperability.
• Standards are vital for interoperability.
• Provide quality improvement and greater value.
• Improve information access.
• Helps to identify the mechanisms for protecting the privacy &
confidentiality of individual’s health data.
• Allows industry to move forward without having each
individual having to the ground implementation.
6 What is Health Level Seven (HL7)?
• An Application Protocol for Electronic Data Exchange in Healthcare
Environments
• Health Level-7 or HL7 refers to a set of international standards for transfer of
clinical and administrative data
• Language that describes you, and your medical information, to all the
Hospital information systems
• Produced by the Health Level Seven International
• A not-for-profit, international standards developing organization
• ANSI-accredited
• Founded in 1987
 What HL7 Mean?
7
8 PURPOSE

• To provide a comprehensive framework and related standards for the exchange,

integration, sharing and retrieval of electronic health information that supports
clinical practice and the management, delivery and evaluation of health services
• HL7 Vision - A world in which everyone can securely access and use the right health
data when and where they need it
• HL7 Mission - To provide standards that empower global health data interoperability
• HL7 provides standards for interoperability that improves –
– Care delivery
– Reduce ambiguity
– Enhance knowledge transfer
among healthcare providers, government agencies, vendor community and patient
9
Timeline of HL7 Standards

1987 Founded and Version 1.0

1988 Version 2.0
1990-2000 Version 2.1 to 2.4
2000-2007 Version 2.5
2007-2014 Version 2.6 to Version 2.7
2014 Version 2.8 to version 2.8.2
2015 Version 2.8.2
10
SCOPE OF HL7
HL7 Version 2.8.2 provide a considerable service in everyday use, in thousands of locations
and in many different countries, However, there are certainly many areas of healthcare
system integration that HL7 does not address or addresses with what may prove to be an
inadequate or incomplete solution.
• A Complete Solution
- HL7 Version 2.8.2 is not, in itself, a complete systems integration solution. There are
several barriers in today’s healthcare delivery environment that makes it difficult for
HL7 to create a complete “plug- and-play” solution.
• Protection of Healthcare Information
• HL7 Version 2.8.2 is largely silent about the issues of privacy authentication and
confidentiality of data that pass through HL7 messages. HL7 makes no assumption
about the ultimate use of data but rather assumes that both source and destination
applications provide for these requirements.
• Enforcement of Organizational Security and Access Control Policies
- HL7 Version 2.8.2, itself, does not provide for the enforcement of a provider
organization’s security and access control policies.
11 • Roles and Relationships
- HL7 Version 2.8.2 does not, in itself, attempt to define or even support the
implicit and explicit relationships between persons such as patients, physicians,
providers, etc.
• Accountability, Audit Trails and Assigned Responsibility
- HL7 Version 2.8 does not attempt to define typical transaction processing
features such as audit trails.
• Tracking of Corrections, Amendments or Refusals to Correct or Amend
Protected Health Information
- HL7 Version 2.8 does not provide messages to support the tracking of
corrections, amendments or refusals to correct or amend protected health
information.
• Tracking Input Validation
- HL7 Version 2.8 does not provide messages for tracking the validation (or lack
of validation) of data
from its source (human or machine).
12 HL7 Standards

1. HL7 Version 2 (HL7 V2)

2. HL7 Clinical Document Architecture (CDA)
3. HL7 Version 3 (HL7 V3)
4. HL7 Fast Healthcare Interoperability Resources (FHIR)
5. HL7 Version 4 (HL7 V4)
6. HL7 Continuity of Care Document (CCD)
7. HL7 Common Terminology Services 2 (CTS2)
8. HL7 Clinical Genomics (HL7 CG)
13
1. HL7 Version 2 (HL7 V2): This is one of the most widely used HL7 standards. It defines a set
of messaging standards for the exchange of clinical and administrative data between
healthcare applications. HL7 V2 messages are text-based and consist of segments and
fields with specific meanings.
2. HL7 Clinical Document Architecture (CDA): CDA is an XML-based standard for structuring
clinical documents, such as discharge summaries and progress notes. It provides a way to
represent structured and unstructured information in a standardized format, making it
easier to exchange clinical information.
3. HL7 Version 3 (HL7 V3): HL7 V3 is designed to be more comprehensive and consistent
than HL7 V2. It uses a formal methodology called the Reference Information Model (RIM)
and the Clinical Document Architecture (CDA) to create a more robust framework for
healthcare data exchange. However, it has seen slower adoption due to its complexity.
4. HL7 Fast Healthcare Interoperability Resources (FHIR): FHIR is a modern and rapidly
growing HL7 standard. It uses a RESTful API and is designed for ease of implementation.
FHIR resources are based on common clinical concepts and can be used to exchange
structured healthcare data. It has gained popularity for its flexibility and is well-suited for
mobile applications and web-based healthcare systems.
14

5. HL7 Version 4 (HL7 V4): This is a future version of the HL7 standard that has been in
development. It aims to address some of the limitations of previous versions and provide a
more comprehensive framework for healthcare data exchange. However, it is not as widely
adopted as HL7 V2 or FHIR.
6. HL7 Continuity of Care Document (CCD): CCD is a standardized version of the Continuity of
Care Record (CCR), which is used to summarize a patient's medical history and care plan. It
is based on the HL7 CDA standard and is used for sharing essential patient information
between healthcare providers.
7. HL7 Common Terminology Services 2 (CTS2): CTS2 is a standard for managing and
accessing terminology services and code systems used in healthcare, making it easier to
ensure consistent use of medical codes and terminologies.
8. HL7 Clinical Genomics (HL7 CG): This standard focuses on the exchange of genetic and
genomic information in healthcare settings. It provides a framework for representing
genetic data and its associated clinical information.
 HL7 Message Standards
15

1. Patient Administration
2. Observation Reporting
3. Medical Records
4. Order entry
5. Application Management
6. Scheduling
7. Patient Referral
8. Financial Management
9. Master Files
10.Patient Care
11.Clinical Laboratory Automation
12.Personnel Management
13.Claims and Reimbursement
14.Materials Management
16
TYPES OF HL7 INTERFACES

1. ADT – transmit administrative data such as patient admittances or discharge.

2. AIP - transmit application information, such as a patient’s lab results.
3. CCI – transmit clinical information such as ICD-10 diagnosis codes.
4. CDE –transmit clinical documents such as EKG and X-ray reports.
5. DFT –transmit financial information such as charges and insurance.
6. DRM –are used to transmit clinical research data.
7. FLT –transmit an event type, such as a patient’s visit.
8. GLB –share an event, such as a patient’s discharge.
9. MSH –transmit medical texts such as observations and reports.
10.NCH –are used to transmit patient admissions and discharges.
17 Message Delimiters
 HL7 Message Structure
18
19
USES OF HL7
20
BENEFITS OF
HL7
21
LIMITATIONS

1. Complexity of HL7 V3
2. Interoperability Issues
3. Slow Adoption
4. Lack of Real-time Support
5. Limited Support for Modern Technologies
6. Lack of Semantic Consistency
7. Version Compatibility Issues
8. Limited Support for Patient Engagement
9. Data Security and Privacy Concerns
10.Vendor Lock-In
22

THANK
YOU