HL7 Version 2 Privacy and Security

Back to Security Main Page

Need to Update HL7 V2 Chapter 1 Security and Privacy Content

A two part series articles by Dallas Hasselhorst examine the security risks in HL7 V2 Interfaces:

• HL7 Data Interfaces in Medical Environments: Understanding the Fundamental Flaw in Healthcare
• HL7 Data Interfaces in Medical Environments Attacking and Defending the Achilles' Heel of Healthcare
• The author of the paper also did a podcast interview in which he discusses the paper here (starts around the 4 minute mark): https://isc.sans.edu/podcastdetail.html?id=5700

8https://gforge.hl7.org/gf/project/security/docman/V2%20Security/HL7%20Transport%20Security/transport-mllp.htm Transport Specification: MLLP, Release 2 (V3)

Three older HL7 transport security specs provided by Bernd Blobel

• SHTI69-0141_7 Secure HL7 Transactions Using Internet Mail Internet Draft

• SHTI69-0153_8 Standard Guide for EDI HL7 Communication Security

• SHTI69-0183_9 Standard Guide for Implementing HL7 Communication Security

• Earlier v2 version v2.2 and v2.3 did offer some high level guidance, e.g.https://gforge.hl7.org/gf/project/security/docman/HL7%20v.2%20Security%20and%20Privacy/Implementation%20Guide%20v2.2.pdf HL7 v2.2 Implementation Guide]
• Guidance from HL7 V2 Chapter 1 on Security, is "silent" on the same topics according to the follow text,which has remained unchanged from HL7 v2.5 through HL7 v2.9.

Chapter 1: Introduction, Section 1.8.2 Protection of Healthcare Information p. 18

• HL7 Version 2.9 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.
• In addition, HL7 does not, at this time, specify what, if any, encryption method should be used when transporting HL7-based messages between two or more systems. At this time, HL7 implementers should familiarize themselves with legal and professional requirements for these topics specific to their country’s national or local requirements.
• 1.8.3 Department of Defense (DOD) Requirements for Systems Security and Robustness

HL7 Version 2.9 does not attempt to support U.S. DOD Security Divisions (A, B, C, D) and Classes (1, 2, 3). If a user requires these features, they will have to define their own structures to support these classifications and insure a uniform implementation across multiple systems in an enterprise.

• 1.8.4 Enforcement of Organizational Security and Access Control Policies

HL7 Version 2.9, itself, does not provide for the enforcement of a provider organization’s security and access control policies. There are no messages specifically defined, at this time, that affect the movement of data based on an organization’s security and access control policies in conjunction with message content information that identifies the users of the message data and the organization’s policies for that user’s authorization to access that data. In the U.S., systems implementers may want to reference relevant ASTM standards and IOM recommendations on this topic.

• 1.8.5 Security Classifications (Markings) and User Authentication and Identification

HL7 Version 2.9 does not, at this time, attempt to address DOD requirement for marking or access control labels that are associated with data objects. This particular method might be one way of supporting both U.S. IOM and JCAHO recommendations for providing different levels of data confidentiality and authentication of both producers and consumers of confidential data.

• 1.8.6 Roles and Relationships

HL7 Version 2.9 does not, in itself, attempt to define or even support the implicit and explicit relationships between persons such as patients, physicians, providers, etc. It is possible that current data modeling efforts by HL7 and other standards developers will, in the future, result in HL7 assuming this responsibility.

• 1.8.7 Accountability, Audit Trails and Assigned Responsibility

HL7 Version 2.9 does not attempt to define typical transaction processing features such as audit trails. A feature such as an audit trail may well be needed to successfully implement both a robust and security-auditable environment. This feature could also support verifying that a given action is performed by individuals who are also responsible. A user may decide that these features are necessary in their integrated environment.

• 1.8.8 Central, Unified Hardware and Software Controls for Security and Trusted Continuous Protection

HL7 Version 2.9 does not attempt to support hardware and software security controls, nor does it provide means to insure continuous protection of data from unauthorized changes. Such a feature may be useful in limiting access to certain types of data to devices and/or users, based on device type or location. Certain U.S. DOD requirements and IOM recommendations may require users to implement these on their own and/or rely on specific applications vendors to support this requirement.

• 1.8.9 Uniform Data Definition and Data Architecture

HL7 Version 2.9 does not include an explicit data model or composite data dictionary. However, extensive work has taken place within the HL7 Working Group to produce a data model for previous versions of HL7 2.x. While these models have not been formally balloted, they are available on the HL7 web server. HL7 does today have a balloted data model. This model is an integral foundation to HL7 Version 3, CDA R2 and other HL7 Standards. HL7 Work Groups made extensive use of the HL7 Data Model when they formulated HL7 Versions 2.5 and 2.5.1 to, as much as possible, align HL7 Version 2.5 and 2.5.1 to the HL7 Data Model.

• 1.8.10 Controlled Disclosure, Notification of Disclosed Information as Protected and Tracking Exceptions of Protected Health Information

HL7 Version 2.9 is silent on supporting the controlled disclosure of protected health information where HL7 is the vehicle of the disclosure across multiple systems in a healthcare delivery system. It is also silent on messages that notify a user that requested information is protected and messages to track allowed exceptions that may take place at the discretion of potentially, but not certified, authorized users (e.g., a physician in the emergency room).

• 1.8.11 Tracking of Corrections, Amendments or Refusals to Correct or Amend Protected Health Information

HL7 Version 2.9 does not provide messages to support the tracking of corrections, amendments or refusals to correct or amend protected health information. These messages would support the process to verify, challenge and ultimately correct inaccuracies discovered in protected health information. Users needing such messages may need to define custom messages to support this requirement.

• 1.8.12 Disclosure of Disidentified Health Information

HL7 Version 2.9 does not have specific messages to disclose “disidentified” health information. Disidentified data is data that does not reveal the identity of the person or care provider(s) (either organizations or individual licensed practitioners or both). While it may be possible to support this need with existing HL7 messages, it would create an unexpected message with missing required patient identification.

• 1.8.13 Ensuring and Tracking Data Source Authentication and Non-alterability

While HL7 Version 2.9 does support an electronic signature for chart completion transactions, it does not, in general, support an electronic signature that is also tied to relevant applications to insure the authentication of the source or arbitrary health data and a prohibition against the alteration of data that has been electronically signed. Chapter 1: Introduction Page 20 Health Level Seven, Version 2.9 © 2017. All rights reserved. January 2017 Normative Ballot 1.

• 1.8.14 Tracking Input Validation

HL7 Version 2.9 does not provide messages for tracking the validation (or lack of validation) of data from its source (human or machine).