1. Care Coordination and Interoperable Health IT Systems
Unit 5: Standards for Interoperable Health IT
Lecture b – Survey of Standards
Welcome to Care Coordination and Interoperable Health IT Systems, Standards for Interoperable Health IT, Lecture b.
This material (Comp 22 Unit 5) was developed by Columbia University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number 90WT0004.
This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. To view a copy of this license, visit

2. Standards for Interoperable Health IT Learning Objectives
Objective 1: Explain why standards are required, how they are developed, and how adoption is encouraged (Lecture a)
Objective 2: Name and describe the types of interoperability standards available (Lecture b)
Objective 3: Summarize functionality of HL7 V2®, CDA®/CCDA, and FHIR® (Lectures c, d, and e)
Objective 4: Recognize HL7 V2® messages, CDA® documents, and FHIR® resources (Lectures c, d, and e)
This unit will cover the following learning objectives: 1) explain why standards are required, how they are developed, and how adoption is encouraged; 2) name and describe the types of interoperability standards available; 3) summarize functionality of HL7 V2®, CDA®/CCDA, and FHIR®; and 4) recognize HL7 V2® messages, CDA® documents, and FHIR® resources. This lecture will give a survey of standards for health care interoperability.

3. Types of health care interoperability standards
Lower level standards
Not necessarily health care specific
Health care content standards
Terminology standards
Implementation guides and profiles
There are several types of health care interoperability standards. There are lower levels standards and these might not necessarily be healthcare specific. There are the health care content interoperability standards, terminology standards, and then there are implementation guides and profiles.
Health IT Workforce Curriculum Version 4.0

4. Lower level standards Standards are necessary to assure:
The lower levels of interoperability (OSI Model Levels 1-6)
The security of the data being transmitted
Some standards in this space include:
ebXML, XML, REST, UML, SOAP, TCPIP, ATNA, SSL, OAUTH2, etc.
Focus is on the application layer
Where interoperability implies that the systems understand and can use the information at the application level
Such as EHRs successfully communicating and using allergy information
Refer to component 9 to understand networking and the lower level standards that are commonly employed
Lower level standards are standards that are necessary to ensure interoperability, but not with the actual health care content. It is lower level in the sense like the wires that you need to connect in a network. These are referred to the open-system interconnect models one to six, which are at the lower levels. Also, it is important for the security of the data being transmitted. The actual content is not of consideration. Some standards that are in this space include: ebXML, XML, REST, UML, SOAP, TCPIP, AETNA, SSL, and OAUTH2 . These are many acronyms and communication standards are beyond the scope of this unit. But you can go to component nine to learn about networking and how lower level standards are commonly employed. Our focus here is on the application layer where interoperability implies that the system understands and can use the information at that application level. However, we will briefly mention two lower level standards developed specifically for health care interoperability on the next two slides.
Health IT Workforce Curriculum Version 4.0

5. Specifications from NwHIN project
Nationwide Health Information Network (NwHIN)
CONNECT
Implementation specifications were created to provide an underlying framework to support health information exchange across the country
Now managed by the Sequoia eHealth Exchange initiative
One example of a lower level standard specifically developed for healthcare interoperability is the NWHIN standards. NWHIN stands for the Nationwide Health Information Network and there are sets of specifications that were created by this organization. They created two main specifications; one set was called “Connect” and the other set was called “Direct”. Originally, the Nationwide Health Information Network, NWHIN, was called NHIN. You will often hear about NWHIN connect and NHIN direct because that was its previous name. We often called it NHIN direct. Connect was the first specification that was created. It was created to provide an underlying framework to support health information exchange across the country. Originally, it was ideal to have specified standards that would allow anyone to plug into this nationwide network. A few years ago, Connect had ambitious goals to do this and several organizations are participating. Connect is now managed by an organization called The Sequoia Project eHealth Exchange Initiative and the link is provided here.

6. Specifications from NwHIN project (Cont’d – 1)
DIRECT
Implementation guide enables secure, directed health information exchange at a more local and less complex level among trusted providers using a directed push mechanism
Often referred to as “NHIN Direct”
NHIN (National Health Information Network) was the prior name for NwHIN
NHIN Direct is required to be used when meeting the Health Information Exchange (HIE) objective for Meaningful Use
However, it was identified that Connect was too complex for the initial use case of sending a summary of care document from one provider to another when a patient was referred or transitioned. A simpler solution called NHIN Direct came into the picture. NHIN Direct is a simplified version of Connect that does more of a point-to-point connection between systems with a secure mailbox analogy. So in short, secured directed health exchange is at a more local level among trusted providers using a directed push mechanism. Direct is required in certified health information technology that is used for Meaningful Use and Merit-based Incentive Payment System, or MIPS. Due to its use in Meaningful Use, it has widespread adoption.

7. NHIN Direct “secure health messaging”
In this diagram, we see that Doctor A’s office used NHIN direct to securely send a clinical summary, also known as the CCDA, to Doctor B’s office via the Internet and it is a concept of a HISP, or health information service provider. So, the sender has a HISP, which is kind of like having an exchange box like Outlook or a similar exchange. The sender is sending from his outbound secure mailbox to the receiver’s health information service provider. This NHIN direct provides addresses for the sender and the receiver, the secure packaging around the message, and the message where the actual health care content standard would exist.
5.1 Figure (maxmdirect.com). Used with permission.
Health IT Workforce Curriculum Version 4.0

8. Health care content standards
Describe the structure and meaning of information sent and the protocol for sending it
For example:
A standard application programming interface (API) and the variables to be exchanged
A standard set of messages and their contents and events that trigger their transmission
A standard structure for a clinical document
Let’s talk more about the health care content standards. These are interoperability standards that are needed to describe the structure and meaning of information sent and the protocol for sending it. There are also rules on what the receiver should do. Some examples could be a standard API with variables exchanged; a standard set of messages and trigger events; or a structured clinical document.
Health IT Workforce Curriculum Version 4.0

9. Health Level Seven (HL7)
“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”
Three primary interoperability standards in use:
Version 2® (V2)
Clinical Document Architecture (CDA®)
FHIR® (Fast Healthcare Interoperability Resources)
Health Level Seven, or HL7, has created three general purpose standards for interoperability in the space of healthcare content standards. The three primary interoperability standards in use for Health Level Seven and are version 2®, CDA® or clinical document architecture, and FHIR®, or fast health interoperability resources.
Health IT Workforce Curriculum Version 4.0

10. HL7 V2®, CDA®, and FHIR®: in brief
A general health care messaging standard
HL7 CDA®
A structured document standard representing any clinical statement
HL7 FHIR®
An API interface used to query and update any type of health care resource
These will be covered in further detail in other lectures in this unit
HL7 version 2® provides a way of communication all different types of health care information via formatted messages. CDA® is a structured document standard representing any clinical statement and meant to represent documents in healthcare. FHIR® is an application programming interface or API that is used to query and update various types of healthcare resources. Due to the prevalence of these three standards in health care interoperability, these will be covered further in other lectures in this unit.
Health IT Workforce Curriculum Version 4.0

11. Digital Imaging and Communication in Medicine (DICOM)
A standard digital format for medical images in health care
DICOM images can be packaged and shared between imaging centers and providers
DICOM, or Digital Imaging and Communication In Medicine, is the standard that is used to represent an image. It is developed by the American College of Radiology and the National Electrical Manufacturer’s Association. An image is a very important piece of information in healthcare. There are many types of diagnostic tests that produce images, like X-rays and CT-Scans. Images are often shared within an organization between the radiology information system and a picture archive system where the images are stored. Images can also be sent between organizations – however, due to their large size, a link into the source system is sometimes provided instead. When images are sent between systems, they are usually in the DICOM format. This picture shows a little bit of the standard’s layout.
5.2 Figure (Wikimedia Commons, 2009)
Health IT Workforce Curriculum Version 4.0

12. National Council for Prescription Drug Programs (NCPDP) Script
Messaging standard for ePrescribing
ONC 2011 and ONC 2014 certification requirement
New prescriptions only
ONC 2015 certification requirement
Bi – directional communication between provider and pharmacy for new prescriptions, cancellations, refills, dispenses, and queries
The National Council for Prescription Drug Programs, or NCPDP, publishes a standard called Script, which is a messaging standard for communicating electronic prescriptions also known as e-prescribing. NCPDP scripts provides a standard way to communicate new prescriptions, cancellations, refills, dispenses, and queries. Systems certified for ONC 2011 and ONC 2014 support new prescriptions. ONC 2015 certified systems support all of the functions.
Health IT Workforce Curriculum Version 4.0

13. Sample NCPDP script messages
Here are examples of NCPDP script in two different formats. There is an EDI, or Electronic Data Interchange, format. This is more of a legacy format. A more modern format is an XML format. Example messages are excerpted from the NIST test data for ONC 2014 certification for ePrescribing.
5.3 Figure (NIST, 2014) ePrescribing test example, EDI (electronic data interchange) format
5.4 Figure (NIST, 2014) ePrescribing test example, XML format
Health IT Workforce Curriculum Version 4.0

14. X12 Communication with health insurance companies
Claims and authorizations (except for pharmacy)
Required by HIPAA
Another information standard in health care is X12. X12 is important because it provides the standard messages for communication with health insurance companies. This is how it communicates claims and how it communicate authorizations, except for pharmacy. Here is a list of particular transactions or messages used for claims and authorizations. The 270 message is for eligibility coverage or benefit inquiry and the 837 message is for health care claim. HIPAA requires that X12 be used when providers communicate with payers.
5.5 Figure (X12, 2011)
Health IT Workforce Curriculum Version 4.0

15. Terminology standards
Codify the meaning of structured values
Can be a simple value set
Can include synonyms and relationships, such as hierarchies
Are necessary to achieve interoperable health IT at scale
Impacts all coded elements communicated in interoperability
If each interface used local value sets, there would be exponential harmonization work
Terminology standards are extremely important for achieving interoperable health IT. So, while a content standard will tell you the different data fields that must be communicated, if any of those fields are coded, then knowing those coding systems and the value sets that can be used in those fields is extremely important. That is why terminology standards are so important in interoperability, especially when you try to reach any large scale. It is not ideal to negotiate and harmonize terminologies. If you use local value sets, there would be an exponential amount of harmonization work. Terminology standards can range from just a simple small value set with abbreviated representation to a complex terminology that includes synonyms and relationships.
Health IT Workforce Curriculum Version 4.0

16. Terminology standards: SNOMED – CT
One of the most sophisticated standard clinical terminologies
Includes concepts, synonyms, hierarchies of concepts, and relationships between concepts
A great example of a complex terminology standard is SNOMED-CT. SNOMED-CT is one of the most sophisticated standard clinical terminologies used in health care. It includes concepts, synonyms, hierarchies of concepts, and relationship between concepts. In the picture, the SNOMED-CT concept of Common Cold is represented. It names a name, an ID, and synonyms like “Head Cold” and “Cold”. It has defining relationships which help to better explain its meaning and allows users to classify the concept. For example, an application could query for all the SNOMED-CT concepts. It has a parent concept of “viral upper respiratory tract infection” and no children concepts. As defining relationships, it is related to a virus, has a finding set, has a pathological process, and a whole series of synonyms.
5.6 Figure (Wikimedia Commons, 2011)
Health IT Workforce Curriculum Version 4.0

17. Terminology systems and value sets
LOINC
A universal code system for identifying laboratory and clinical observations
SNOMED – CT
RxNorm
A standardized nomenclature for clinical drugs
HL7 CVX
Immunizations
ISO Language Codes
CDC Race and Ethnicity Codes
UCUM
Unified Code of Units of Measure used to specify the units on results values.
HL7 Version 3 (V3) Normative Edition, 2015
Administrative gender
ICD-9, ICD-10, ICD-11
Diagnoses and procedures
CPT Procedure Codes
This slide shows terminology systems and value sets that have been used as part of the ONC Certification of Health IT. Here is a list of terminology systems and value sets, but there are more. LOINC is a code system for identifying laboratory and clinical observations. It is used for lab tests, radiology tests, document IDs, and other data types. SNOMED-CT is a rich clinical terminology that covers a lot of different terms. RXNorm is a standardized nomenclature for clinical drugs. CVX is for administered vaccines. The Centers for Disease Control maintains race and ethnicity terminology. It has several codes sets including ISO language codes. UM or Unified Code of Units of Measure provides terminology for units often used with result values. ICD-10 is what is being used right now in the United States for diagnoses. And then there are CPT procedure codes. The National Library of Medicine has a value set authority that helps manage value sets used in certified systems. This is not an exhaustive list.
Health IT Workforce Curriculum Version 4.0

18. Recap of standards
Lower level standards: interoperability at levels under the application layer and for security of transmitted data
NwHIN Connect: health information exchange across country
NHIN Direct: secure health messaging between two points.
Health care content standards: structure and meaning of information and protocol for communicating
HL7 V2®, CDA®, and FHIR®: health information
DICOM: medical images
NCPDP Script: prescriptions
X12: claims and other payer communications
Terminology standards: codify the meaning of structured values
SNOMED-CT, LOINC, ICD9 and ICD10, RxNorm, CPT, etc.
We just went through many kinds of standards so let’s recap. Lower level standards are for interoperability at the application layer and for data security. The lower level standards we discussed were NwHIN Connect and NHIN Direct. A second type of standards is health care content standards, which describe the structure and meaning of information and the protocol for communicating it. The health care content standards we discussed were HL7 V2®, HL7 CDA®, HL7 FHIR®, DICOM, NCPDP, and X12. A third type of standards is terminology standards. Several common ones are SNOMED-CT, LOINC, ICD9 and ICD10, RxNorm, and CPT.
Health IT Workforce Curriculum Version 4.0

19. Implementation guides / profiles
Standard implementation guides are important
Are published by SDOs, as well as organizations fostering standards adoption (e.g. ONC and IHE)
Provide tighter rules and guidance on a standard or a group of standards to solve a particular use case
Reduce variability by tightening optionality and clarifying ambiguities of the base standards
Facilitate “plug and play” interoperability
Let’s now move onto the topic of implementation guides or profiles. Standard implementation guides are important because standards are often not specified enough to allow interoperability without negotiation and implementation-specific code. The purpose of a standard implementation guide is to narrow variability by providing additional rules and constraint on top of the base standards specification. This is to solve a particular use case or to work in a particular jurisdiction. These implementation guides remove the optionality and variation and fill in the gaps that are often required to be filled when implementing standards. That means that less site specific implementation work will be required. If an implementation guide is good enough and removes all variability and both the sending and receiving vendor fully comply to the guide, then their two products should be able to be connected together without having to implement custom translations between the systems. We call that “plug and play” interoperability.
Health IT Workforce Curriculum Version 4.0

20. Implementation guide example: laboratory results interface
Standard implementation guide for Lab Results messaging in the United States:
HL7 Version Implementation Guide: S&I Framework Laboratory Results Interface (LRI) Implementation Guide, Release 2 STU, US Realm
Includes special guidance on how to implement lab results in the United States
Tells what value sets to use to specific test codes, organism codes, and units of measure
Requires fields that are recommended by U.S. labs such as performing lab information
Provides specific scenarios
For example, the HL7 V2® Lab Result Message does not require that each result component be coded and does not require a particular code set. However, an implementation guide might choose to require the test code field and also require that only the LOINC code system be used. These requirements will ensure that there is less negotiation left for a particular implementation. Just such an implementation guide has been published in the United States by HL7. It is called the LRI specification, which is short for HL7 Version Implementation Guide: S&I Framework Laboratory Results Interface Implementation Guide, Release 2 STU, U.S. Realm. The LRI specification includes special guidance on how to implement lab results. It is especially tailored for the United States, but could be used in other countries as well. It includes terminology requirements. For example, it tells what value sets must be used to specify tests and their components, what codes must be used to specify microorganisms, and what codes must be used to specify units of measure. It also provides U.S. specific implementation guidance on fields and makes certain fields required based on U.S. lab policy recommendations.
Health IT Workforce Curriculum Version 4.0

21. Some implementation guides required for ONC 2015 certification
HL7 CDA® R2 Implementation Guide: Quality Reporting Document Architecture (QRDA)
HL7 CDA® R2 Implementation Guide: Consolidated Clinical Document Architecture (CCDA)
PHIN Messaging Guide for Syndromic Surveillance
HL7 V2.5.1 Implementation Guide for Immunization Messaging, R1.5
Here are examples of implementation guides that are actually required for ONC 2015 certification of Health IT. The first guide, QRDA, describes how to use HL7 CDA® to specify a clinical quality measurement. The next one, CCDA, primarily describes a clinical summary for a patient and provides very specific guidance on how to represent and encode key data types of a care summary such as allergies, medications, problems, and results. The PHIN Messaging Guide for Syndromic Surveillance describes how to use HL7 Version 2® to communicate syndromic surveillance information to a public health authority. HL7 V2.5.1 Implementation Guide for Immunization Messaging, R1.5 describes how to use HL7 Version 2 to communicate share immunization information between providers and public health authorities. These examples are meant to give you an idea of the kinds of implementation guides that are available and their usefulness.
Health IT Workforce Curriculum Version 4.0

22. IHE integration profiles
IHE uses the term Integration Profile instead of Implementation Guide
IHE Implementation Profiles:
Organize and leverage the integration capabilities that can be achieved by coordinated implementation of communication standards, such as DICOM, HL7 W3C and security standards
Provide precise definitions of how standards can be implemented to meet specific clinical needs (
IHE uses the term Integration Profile instead of Implementation Guide. IHE Implementation Profiles organize and leverage the integration capabilities that can be achieved by coordinated implementation of communication standards, such as DICOM, HL7 W3C, and security standards. They provide precise definitions of how standards can be implemented to meet specific clinical needs. Many IHE Profiles have widespread adoption. Whenever people implement the DICOM standard, they implement it by following an IHE Implementation profile.
Health IT Workforce Curriculum Version 4.0

23. IHE Domains Pathology and Laboratory Medicine
Cardiology
Dental
Eye Care
IT Infrastructure
Includes IHE Cross-Domain document sharing (XDS)
Includes Patient Demographics Query and Patient ID Cross Referencing (PIX/PDQ)
Pathology and Laboratory Medicine
Patient Care Coordination
Patient Care Devices
Pharmacy
Quality, Research, and Public Health
Radiation Oncology
Radiology
IHE Profiles have been developed for numerous functional domains including Cardiology, Dentistry, Eye Care, Pathology and Laboratory Medicine, Patient Care Coordination, Patient Care Devices, Pharmacy, Quality, Research and Public Health, Radiation Oncology, and Radiology. Profiles have also been created in the domain called IT Infrastructure which supports common utility functions needed in healthcare interoperability. For example, the IHE XDS profile specifies how documents can be located and securely exchanged in an inter-organizational context. The IHE PIX and PDQ profiles are often used by EMPIs and describe how patients can be matched in an inter-organizational context. Imagine a patient presents in the Emergency Room at a city hospital which uses a Health Information Exchange or HIE. Using IHE PIX/PDQ and IHE XDS, the HIE is able to match the patient and locate records for the patient across the HIE’s region and bring them back to the clinician treating the patient in the Emergency Room.
Health IT Workforce Curriculum Version 4.0

24. Implementation guides and implementation profiles: summary
Describes specific use cases
Provides tighter rules
Gives specific implementation guidance
Might include one or more standards
Content
Terminology
Lower – level
In summary, Implementation Guides or Integration Profiles are specifications that describe how to implement a standard or set of standards for a specific use case. A specific implementation guide or profile might include one or more content standards, terminology standards, and lower level standards. It would describe how each one of the standards would be used together to provide interoperability. While base standards provide rules for interoperability, they are often too general and loose to implement. Implementation Guides on the other hand provide practical specifications that have been honed to meet specific use cases. Whenever possible, it is best to implement standard implementation guides or integration profiles.
Health IT Workforce Curriculum Version 4.0

25. Unit 5: Standards for Interoperable Health IT, Summary – Lecture b, Survey of Standards
There are three types of interoperability standards: lower level, health care content, and terminology
Standards are needed to ensure interoperability; secure transmitted data; and describe structure, meaning, and protocol
Implementation guides, or profiles, provide guidance on how to integrate and implement standards for particular use cases by providing additional rules and constraints to narrow variability in implementation of standards
This concludes Lecture b of Standards for Interoperable Health IT. To summarize, there are three types of interoperability standards: lower level, health care content, and terminology. Standards are needed to ensure interoperability, secure transmitted data, and describe structure, meaning, and protocol. Standards are not constrained to particular use cases and are not integrated with other standards leading to variability in implementation. Standard Implementation guides, or profiles, solve this problem by providing additional rules and constraints to narrow variability in implementation of standards.

26. Standards for Interoperable Health IT References – Lecture b
Integrating the Healthcare Enterprise.
Integrating the Healthcare Enterprise profiles.
JASON. (2014). A robust health data infrastructure. Available at:
Charts, Figures, and Tables
5.1 Figure: maxmdirect.com. NHIN Direct secure health messaging. Used with permission.
5.2 Figure: Wikimedia Commons, DICOM.
5.3 Figure: (NIST) ePrescribing test example, EDI (electronic data interchange) format.
5.4 Figure: (NIST) ePrescribing test example, XML format.
5.5 Figure: X12, Health Insurance Transactions, X12 EDI Transaction Sets.
No audio.

27. Standards for Interoperable Health IT References – Lecture b (Cont’d – 1)
Charts, Figures, and Tables
5.6 Figure: Wikimedia Commons, SNOMED-CT.
No audio.

28. Unit 5: Standards for Interoperable Health IT, Lecture b – Survey of Standards
This material was developed by Columbia University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information Technology under Award Number 90WT0004.
No audio.
End.