Gone are the days when nurses had to wear a wrist watch, with a second hand, to count the patient's pulse and respirations. And nurses no longer stand grasping an oral thermometer for 60 seconds to take the patient's temperature. These are just a couple of the patient care tasks that are easier to perform thanks to up-to-date technology used in many hospitals. This article provides a basic overview on why the use of technology has increased in the healthcare industry. It also takes a look at some of the electronic medical record capabilities. And, it discusses interface engines--the technology used to share medical data.
January 2010, the 111th Congress passed the Patient Protection and Affordable Care Act (commonly referred to as the Affordable Care Act) . Two months later President Obama signed the Act into law. The Affordable Care Act "encourages the use of, integration with, and coordination of health information technology (including [the] use of technology that is compatible with electronic medical records and personal health records) ..."
While the Act encouraged the use of technology; the real incentive came through the promise of Meaningful Use incentive payments. The Centers for Medicare & Medicaid Services (a division of the US Department of Health & Human Services) promised two forms of incentive payments: One from Medicare and the other from Medicaid. The Medicare and Medicaid Electronic Health Record (EHR) Incentive Programs promised incentive payments to eligible professionals and medical facilities as they adopt, implement or upgrade and demonstrate meaningful use of certified EHR technology. The Medicare EHR Incentive Program promised up to $44,000; and, the Medicaid EHR Incentive Program promised up to $63,750.
Data Standardization
One key aspect of the Electronic Health Record (also referred to as the electronic medical record) is that patient care information is captured using standardized data. Some key benefits to the health industry adopting standards to classify diseases, procedures, treatments, etc. is compelling. For example, hospitals can share syndromic surveillance data (used for early detection of biologic terrorism) with the Center for Disease Control (CDC). And, the CDC's system would be able to store data received and generate accurate reports although the data came from different organizations and different systems.
Following is a list of some of the data standards used by electronic medical record systems:
This section outlines some of the software capabilities found in an electronic health record. It also includes example screenshots from CPRS--the electronic medical records system implemented by the US Department of Veterans Affairs implemented.
Staff can capture and manage autopsy results that help determine the cause of death. In CPRS this information is accessed using the Labs tab.
Nurses can also electronically document a patient's admission assessment.
Note: The US Department of Veterans Affairs also built VistA Web, a web-based user interface that allows practitioners to view a patient's record from any location. The premise was patients should be able to receive care from any clinic or hospital. Unfortunately, many employees don't know about VistA web and even fewer know how to use it. This proves no matter how impressive the features of a system are; they are useless without end-user training.
For additional information on Electronic Health Record capabilities review 45 CFR Part 170.
For years many hospitals used individual systems for laboratory transactions (i.e., capture lab results), to admit/discharge patients and to manage patient accounts and billing. But, there was an imbalance because some information was electronic and some wasn't. When it was decided the health systems should be able to share data (both internally and externally) someone needed to define a way in which health data could be passed from one system to another.
An organization called the Health Level Seven International (HL7) developed a group of health standards that outlined the message types, formats, segments, fields, data types and symbols that could be used to share health data. Today these message types, formats, segments, fields, data types and symbols are used to build HL7 messages to share health data.
The name HL7 was used, for the standards and organization, because the HL7 messages use the Seventh Layer (also called the Application Layer) of the Open Systems Interconnection (OSI) model to share the health data.
One might envision an HL7 message to look like an email message; but it does not. Instead these messages include a combination of data and symbols. Developers use a special HL7 Mapping Tool to work with HL7 messages. Following is an HL7 message displayed using standard encoding rules. Note that the recommended XML format exists, although it is not shown in this article:
MSH|^~\&|TBHS|The Best Hospital System|SBHS|Second Best Hospital System|20130701143619||ADT^A04|MSG.0|D|2.4
EVN||20040328134602.1234+0600||03
PID|1||A74328~A74333~A74331||Doe^John^Ellie|Doer|20040328134602.1234+0600|M|||3117 Clopper Road&90238^^Atlanta^GA^30076-1455||404-693-3432^^^joe.doe@mybus.com~(404)555-2312^^^Jan.doe@herbus.com~(404)221-7218^^^jane@herbus.com~(404)463-9900|||||A743324335||IN35489768457^G^19980319
PV1|1|C||U|||3472390832^Reinhold^Wesley|3472390832^Simmons^Connor|||||||||||A74324|||||||||||||||||||||||||20040328134602.1234+0600|20040328134602.1234+0600|1243.00|43824.12||3897.00
There are several important things to know about an HL7 message. First, there are various types of HL7 messages. Each message type is identified by its three-letter code and a trigger event code. For example, the above message is an ADT-A01 message. ADT tells us the message is associated with a patient admit/visit activity. A01 is the trigger event, which is registering a patient. Whenever a patient is registered as part of the patient care admittance or visit process, an ADT-A01 message can be sent to store the patient's identity and other patient registration information. There are a number of HL7 messages that can be sent based on events that occur throughout the patient care process. A few of the HL7 messages are as follows:
ADT-A01 - Admit/Visit Notification
ADT-A02 - Transfer a Patient
ADT-A03 - Discharge/End Visit
ADT-A06 - Change an outpatient to an inpatient
ADT-A07 - Change an inpatient to an outpatient
ADT-A11 - Cancel Admit/Visit Notification
ADT-A12 - Cancel Transfer
VXU-V04 - Unsolicited Vaccination record update
SSR-U05 - Specimen Status Request
Every HL7 message is made up of segments. Some segments are required others are not. And, the segments included vary from message to message. Although it should be noted that the MSH segment is included in every message because it contains important information about the message.
Within a segment there are fields that contain information relevant to the associated event. Following is a table that outlines the segments and descriptions included in the ADT-A01 message:
The above table shows the segments that make up the ADT-A01 message. As previously mentioned each segment includes fields that contain data related to the event. For example, the PID segment includes information about the patient such as family name (last name), given name (first name), mother's maiden name, date/time of birth, patient address, along with some demographic data fields. Notice some of the above segments are enclosed in brackets []. The brackets mean the segments are optional and are not required. This means you may or may not see a message with the [OBX], [AL1] and [DG1] segments. Curly brackets {} mean the segment may contain repeating fields so that additional information may be added. The following picture shows how the data may look using an HL7 Developer Mapping Tool.
Just as fields in a database table are assigned a data type; fields in an HL7 message are also assigned data types. Some of the common data types include string, date/time, money, numeric, etc. In addition to fields (that hold data) HL7 messages include symbols. For example, each field begins and ends with a field separator that looks like this: | If a field does not contain any data and the field beside it does contain data the message field separators look like this: | |field with data| Adding a field separator, even if no data is included, ensures each field falls in its correct position based on the HL7 standard's definition of the message.
If a field has more than one part a component separator ^ is used. For example, |Doe^John^I^^| field includes multiple components such as the patient's last name, first name and middle initial.
The ~ character is used to identify a repeating field. The following image shows an example of this character and how the repeating field works.
HL7 also includes an escape character that looks like this: / . This character can be used with other characters to ensure message field data is presented in its proper context. For example, if message data includes the ampersand sign (&) the "&" would be added to the message as follows /T/ so the message data relays as an ampersand. This is done because the "&" symbol is also an encoded symbol in HL7.
As previously mentioned, all fields in a segment are accounted for through the field separators. Within a message the identity of the segment will always be first. The following partial message shows the MSH segment. After the segment identity the first position holds a field separator. The second position defines the encoding characters ^~\&. The third position includes the name of the sending application (TBHS). The fourth position includes the name of the sending facility "The Best Hospital System", etc.
MSH|^~\&|TBHS|The Best Hospital System|SBHS|Second Best Hospital System|20130701143619||ADT^A04|MSG.0|D|2.4
The MSH segment of every message will always contain the same fields because segments are defined by the standard. Through the standard's definition systems built by different organizations or even different developers can share data because everyone knows the rules regarding what is or is not acceptable.
Whether two systems in the same medical facility want to share data; or, two systems in two different facilities want to share data--information regarding what will be shared must be defined. Most organizations produce a guide that describes the HL7 messages to be shared and relevant information about those messages. For example, the Center for Disease Control (CDC) developed an HL7 Implementation Guide describing immunization messages that can be shared. The US Department of Veterans Affairs produced an HL7 Interface Specification or handbook that contains the HL7 message information. Regardless of what the guide is called it must include details about the HL7 messages, segments and fields that will be shared.
These documents typically describe the message types that will be shared, the segments and fields as well as what fields will be repeated. The guides will also define what fields are required. If this information is not captured sharing data will become a problem. For example, if a receiving system requires data that the sending system does not include, the receiving system will not accept the message. In addition, the acceptable field lengths are also included in the document. And, if Z segments (which are locally defined segments not outlined in the HL7 standards) will be used these segments are also described in detail along with other HL7 message details
To share data between medical systems (whether internal or external) an interface engine is required. An HL7 Interface Engine is created by installing the applicable interface engine software on a computer running the appropriate operating system.
An HL7 Message Mapping tool must be used to map the HL7 segment fields to database table fields. This ensures the interface engine knows what database table fields the HL7 segment fields are associated with. A Software Developer also must build two components (if the interface engine doesn't come with them). These components reside on the interface engine. One component assembles database table data into an HL7 message. The interface engine then sends the data to the receiving system. The second component strips away the HL7 symbols so only data that can be inserted into a database table remains. Interface Engines include listeners that look out for incoming HL7 messages. As these messages are received they are properly processed and the data is inserted into the applicable database table.
Another message type worth discussing is the Acknowledgment or ACK HL7 message type. Most interface engines can be configured to support Acknowledgment messages, which are particularly useful for messages sent between two different local area networks (LANs). When a sending interface engine sends a message the receiving interface engine can return an Acknowledgement message. The Acknowledgement includes information identifying the message received. One key purpose of the ACK is to let the sending system know the message sent was received.
There are a number of HL7 Interface Engines available on the market. Following is a list of some of the HL7 Interface Engines available today:
For more information about HL7 you can visit Health Level Seven International.
Why Technology Has Become Popular
January 2010, the 111th Congress passed the Patient Protection and Affordable Care Act (commonly referred to as the Affordable Care Act) . Two months later President Obama signed the Act into law. The Affordable Care Act "encourages the use of, integration with, and coordination of health information technology (including [the] use of technology that is compatible with electronic medical records and personal health records) ..."
While the Act encouraged the use of technology; the real incentive came through the promise of Meaningful Use incentive payments. The Centers for Medicare & Medicaid Services (a division of the US Department of Health & Human Services) promised two forms of incentive payments: One from Medicare and the other from Medicaid. The Medicare and Medicaid Electronic Health Record (EHR) Incentive Programs promised incentive payments to eligible professionals and medical facilities as they adopt, implement or upgrade and demonstrate meaningful use of certified EHR technology. The Medicare EHR Incentive Program promised up to $44,000; and, the Medicaid EHR Incentive Program promised up to $63,750.
A Look at the Electronic Medical Record Capabilities
45 CFR Part 170 - Health Information Technology Standards, Implementation Specifications, and Certification Criteria and Certification Programs for Health Information Technology defines the capabilities and certification criteria electronic health records must meet. The following section outlines some of the information found in 45 CFR Part 170.Data Standardization
One key aspect of the Electronic Health Record (also referred to as the electronic medical record) is that patient care information is captured using standardized data. Some key benefits to the health industry adopting standards to classify diseases, procedures, treatments, etc. is compelling. For example, hospitals can share syndromic surveillance data (used for early detection of biologic terrorism) with the Center for Disease Control (CDC). And, the CDC's system would be able to store data received and generate accurate reports although the data came from different organizations and different systems.
Following is a list of some of the data standards used by electronic medical record systems:
- International Classification of Diseases (ICD-9) and ICD-10 provides a set of universal names and ID codes for diagnosis, procedures, diseases and injuries and causes of injury.
- Logical Observation Identifiers Names and Codes (LOINC) provides a universal set of names and ID codes to describe laboratory and clinical test results.
- Systematized Nomenclature of Medicine--Clinical Terms (SNOMED-CT) is a structured listing of coded, clinical terms developed for use in Electronic Health Record systems.
- RX Norm provides standardized names for drugs along with links to the varying names for the drugs.
This section outlines some of the software capabilities found in an electronic health record. It also includes example screenshots from CPRS--the electronic medical records system implemented by the US Department of Veterans Affairs implemented.
- Real-Time Status Updates: When a user first logs into the system the user sees the following cover, which provides real-time status updates on the selected patient.
- Record a Patient's Problem: The ability to document the patient's problem using ICD-10 or other applicable standard is necessary.
- Electronic prescribing: A facility should be able to electronically transmit a patient's prescription directly to a pharmacy.
- Electronic submission to public health agencies for surveillance or reporting: Facilities should be able to transmit messages to the Center for Disease Control or other organizations.
- Capture a Patient's Progress: This capability ensures medical staff can add daily notes about a patient's response to treatment and care.
- Audit Trail for User Actions: The Electronic Health Record should record actions by documenting the date, time, patient identification, and user identification associated with data that is created, modified, accessed, or deleted.
- Perform Drug-drug, drug-allergy interaction checks: "The Electronic Health Record should automatically and electronically generate and indicate in real-time, notifications at the point of care for drug-drug and drug-allergy contraindications."
- Capture, store & manage diagnosis information.
- Generate clinical reminders: The system should generate clinical reminders based on relevant clinical data to support preventive care. For example, based on a man's race, age and other demographics a reminder may prompt the facility to contact the patient to schedule prostate cancer screening.
- Patient medications, labs, x-rays/images: The electronic health record should provide a way for physicians to order patient medications, labs, x-rays/images.
Note: The US Department of Veterans Affairs also built VistA Web, a web-based user interface that allows practitioners to view a patient's record from any location. The premise was patients should be able to receive care from any clinic or hospital. Unfortunately, many employees don't know about VistA web and even fewer know how to use it. This proves no matter how impressive the features of a system are; they are useless without end-user training.
For additional information on Electronic Health Record capabilities review 45 CFR Part 170.
How Medical Information Technology Is Integrated
For years many hospitals used individual systems for laboratory transactions (i.e., capture lab results), to admit/discharge patients and to manage patient accounts and billing. But, there was an imbalance because some information was electronic and some wasn't. When it was decided the health systems should be able to share data (both internally and externally) someone needed to define a way in which health data could be passed from one system to another.
An organization called the Health Level Seven International (HL7) developed a group of health standards that outlined the message types, formats, segments, fields, data types and symbols that could be used to share health data. Today these message types, formats, segments, fields, data types and symbols are used to build HL7 messages to share health data.
The name HL7 was used, for the standards and organization, because the HL7 messages use the Seventh Layer (also called the Application Layer) of the Open Systems Interconnection (OSI) model to share the health data.
One might envision an HL7 message to look like an email message; but it does not. Instead these messages include a combination of data and symbols. Developers use a special HL7 Mapping Tool to work with HL7 messages. Following is an HL7 message displayed using standard encoding rules. Note that the recommended XML format exists, although it is not shown in this article:
MSH|^~\&|TBHS|The Best Hospital System|SBHS|Second Best Hospital System|20130701143619||ADT^A04|MSG.0|D|2.4
EVN||20040328134602.1234+0600||03
PID|1||A74328~A74333~A74331||Doe^John^Ellie|Doer|20040328134602.1234+0600|M|||3117 Clopper Road&90238^^Atlanta^GA^30076-1455||404-693-3432^^^joe.doe@mybus.com~(404)555-2312^^^Jan.doe@herbus.com~(404)221-7218^^^jane@herbus.com~(404)463-9900|||||A743324335||IN35489768457^G^19980319
PV1|1|C||U|||3472390832^Reinhold^Wesley|3472390832^Simmons^Connor|||||||||||A74324|||||||||||||||||||||||||20040328134602.1234+0600|20040328134602.1234+0600|1243.00|43824.12||3897.00
There are several important things to know about an HL7 message. First, there are various types of HL7 messages. Each message type is identified by its three-letter code and a trigger event code. For example, the above message is an ADT-A01 message. ADT tells us the message is associated with a patient admit/visit activity. A01 is the trigger event, which is registering a patient. Whenever a patient is registered as part of the patient care admittance or visit process, an ADT-A01 message can be sent to store the patient's identity and other patient registration information. There are a number of HL7 messages that can be sent based on events that occur throughout the patient care process. A few of the HL7 messages are as follows:
ADT-A01 - Admit/Visit Notification
ADT-A02 - Transfer a Patient
ADT-A03 - Discharge/End Visit
ADT-A06 - Change an outpatient to an inpatient
ADT-A07 - Change an inpatient to an outpatient
ADT-A11 - Cancel Admit/Visit Notification
ADT-A12 - Cancel Transfer
VXU-V04 - Unsolicited Vaccination record update
SSR-U05 - Specimen Status Request
Every HL7 message is made up of segments. Some segments are required others are not. And, the segments included vary from message to message. Although it should be noted that the MSH segment is included in every message because it contains important information about the message.
Within a segment there are fields that contain information relevant to the associated event. Following is a table that outlines the segments and descriptions included in the ADT-A01 message:
| Segment | Description |
| MSH | Message header |
| EVN | Event type |
| PID | Patient identification data |
| PV1 | Patient visit details |
| [{OBX}] | Observation / Result information |
| [{AL1}] | Patient allergy details |
| [{DG1}] | Diagnosis details |
The above table shows the segments that make up the ADT-A01 message. As previously mentioned each segment includes fields that contain data related to the event. For example, the PID segment includes information about the patient such as family name (last name), given name (first name), mother's maiden name, date/time of birth, patient address, along with some demographic data fields. Notice some of the above segments are enclosed in brackets []. The brackets mean the segments are optional and are not required. This means you may or may not see a message with the [OBX], [AL1] and [DG1] segments. Curly brackets {} mean the segment may contain repeating fields so that additional information may be added. The following picture shows how the data may look using an HL7 Developer Mapping Tool.
Just as fields in a database table are assigned a data type; fields in an HL7 message are also assigned data types. Some of the common data types include string, date/time, money, numeric, etc. In addition to fields (that hold data) HL7 messages include symbols. For example, each field begins and ends with a field separator that looks like this: | If a field does not contain any data and the field beside it does contain data the message field separators look like this: | |field with data| Adding a field separator, even if no data is included, ensures each field falls in its correct position based on the HL7 standard's definition of the message.
If a field has more than one part a component separator ^ is used. For example, |Doe^John^I^^| field includes multiple components such as the patient's last name, first name and middle initial.
The ~ character is used to identify a repeating field. The following image shows an example of this character and how the repeating field works.
As previously mentioned, all fields in a segment are accounted for through the field separators. Within a message the identity of the segment will always be first. The following partial message shows the MSH segment. After the segment identity the first position holds a field separator. The second position defines the encoding characters ^~\&. The third position includes the name of the sending application (TBHS). The fourth position includes the name of the sending facility "The Best Hospital System", etc.
MSH|^~\&|TBHS|The Best Hospital System|SBHS|Second Best Hospital System|20130701143619||ADT^A04|MSG.0|D|2.4
The MSH segment of every message will always contain the same fields because segments are defined by the standard. Through the standard's definition systems built by different organizations or even different developers can share data because everyone knows the rules regarding what is or is not acceptable.
Defining the Data to Share
Whether two systems in the same medical facility want to share data; or, two systems in two different facilities want to share data--information regarding what will be shared must be defined. Most organizations produce a guide that describes the HL7 messages to be shared and relevant information about those messages. For example, the Center for Disease Control (CDC) developed an HL7 Implementation Guide describing immunization messages that can be shared. The US Department of Veterans Affairs produced an HL7 Interface Specification or handbook that contains the HL7 message information. Regardless of what the guide is called it must include details about the HL7 messages, segments and fields that will be shared.
HL7 Interface (or Integration) Engines
To share data between medical systems (whether internal or external) an interface engine is required. An HL7 Interface Engine is created by installing the applicable interface engine software on a computer running the appropriate operating system.
An HL7 Message Mapping tool must be used to map the HL7 segment fields to database table fields. This ensures the interface engine knows what database table fields the HL7 segment fields are associated with. A Software Developer also must build two components (if the interface engine doesn't come with them). These components reside on the interface engine. One component assembles database table data into an HL7 message. The interface engine then sends the data to the receiving system. The second component strips away the HL7 symbols so only data that can be inserted into a database table remains. Interface Engines include listeners that look out for incoming HL7 messages. As these messages are received they are properly processed and the data is inserted into the applicable database table.
Another message type worth discussing is the Acknowledgment or ACK HL7 message type. Most interface engines can be configured to support Acknowledgment messages, which are particularly useful for messages sent between two different local area networks (LANs). When a sending interface engine sends a message the receiving interface engine can return an Acknowledgement message. The Acknowledgement includes information identifying the message received. One key purpose of the ACK is to let the sending system know the message sent was received.
There are a number of HL7 Interface Engines available on the market. Following is a list of some of the HL7 Interface Engines available today:
For more information about HL7 you can visit Health Level Seven International.
