The Interoperability Standards Advisory (ISA) process represents the model by which the Office of the National Coordinator for Health Information Technology (ONC) will coordinate the identification, assessment, and public awareness of interoperability standards and implementation specifications that can be used by the healthcare industry to address specific interoperability needs including, but not limited to, interoperability for clinical, public health, and research purposes. ONC encourages all stakeholders to implement and use the standards and implementation specifications identified in the ISA as applicable to the specific interoperability needs they seek to address. Furthermore, ONC encourages further pilot testing and industry experience to be sought with respect to standards and implementation specifications identified as “emerging” in the ISA.
The 2017 ISA has been updated to include improvements made based on recommendations received from public comments and the Health IT Standards Committee. For historical background on the ISA please review prior ISA publications.
The most substantial changes between the 2016 and the 2017 ISA are largely related to the ISA’s organization, content and framing. This includes the following:
- Further transition of the ISA from a stand-alone document to a Web-based resource with greater interactive features, additional opportunities for engagement with stakeholders, and also providing enhanced transparency to the process of updating the ISA.
- The discontinued use of the label “best available” as an overall concept for the ISA. This change, at the recommendation of the Health IT Standards Committee, seeks to address feedback that stakeholders may perceive varied standards and implementation specifications associated with an interoperability need as “best” despite known limitations or low adoption levels. Further, that the use of “best available” as a general label for all listings in the ISA would not provide a sufficient pathway for industry input to ultimately distinguish whether one standard or implementation specification listed in the ISA may be more “fit for purpose” and preferred for implementation over another for the same interoperability need.
- Changing the scope of the ISA to include more specific references to research and public health.
- Including Personal Health Device, Nursing, Research, Nutritional Health, and Social Determinant interoperability needs within the ISA.
- Adding a new section that begins to include Functional and Data Models as well as Functional Profiles.
- Where applicable, the addition of “Applicable Starter Set(s)” alongside appropriate code sets in Section I.
- Links to active projects listed in ONC’s Interoperability Proving Ground as a way to indicate their use of an ISA-listed standard or implementation specification to showcase ongoing implementations.
- Better representation of the pairing of standards for observations (i.e., questions) and standards for observation values (i.e., answers).
- A shift in the timeline and annual publication cycle from the process first established with the publication of the 2015 ISA. In December of each year, ONC will publish a static “Reference Edition” of the ISA that can be referenced in contracts, agreements, or as otherwise needed with certainty that the information will not change. For example, in December 2016, ONC will publish the 2017 ISA Reference Edition. The web-based version of the ISA, however, is expected to be updated frequently throughout the year as needed to reflect real-time updates to standards and implementation specifications from standards development organizations (SDOs) and allow dialogue and debate between stakeholders about the ISA’s interoperability needs, standards, and implementation specifications on an ongoing basis. While a call for public comments is still expected to occur annually to ensure the published Reference Edition is as accurate as possible, the web-based version of the ISA will allow for continuous feedback from stakeholders, with a more rapid ability to update the ISA to reflect changes in the standards landscape, to provide additional information that helps stakeholders better understand the limitations, preconditions, and dependencies for interoperability, and to provide corrections to any factual errors. Your continued feedback and engagement is critical to improve and refine the ISA.
The 2017 ISA includes revisions and additional descriptive text for several of the six informative characteristics.
Starting with the 2017 ISA, the ISA’s focus has expanded to more explicitly include public health and health research interoperability. Thus, its scope includes electronic health information created in the context of treatment, and subsequently used to accomplish a purpose for which interoperability is needed (e.g., a referral to another care provider, public health reporting, or research). The ISA does not include within its scope administrative/payment oriented interoperability purposes or administrative transaction requirements that are governed by HIPAA and administered by the Centers for Medicare & Medicaid Services (CMS). CMS maintains a list of standards for this purpose that can be referenced: https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/HIPAA-ACA/index.html.
The ISA is not exhaustive but it is expected to be incrementally updated to include a broader range of health IT interoperability needs. When more than one standard or implementation specification is listed it is intended to prompt industry dialogue as to whether one standard or implementation specification is necessary or if the industry can efficiently interoperate more than one. It may also reflect the fact that there is an ongoing transition from the use of one standard towards a new version or even next-generation approach.
As noted in previous ISA publications, a standard listed in one section is not intended to imply that it would always be used or implemented independent of a standard in another section. To the contrary, it will often be necessary to combine the applicable standards from multiple sections to achieve interoperability for a particular clinical health information interoperability need.
It is also important to note that the ISA is designed to inform standards and implementation specification choices for all types of health IT that support interoperability needs, not solely electronic health record (EHR) systems. Furthermore, the ISA is not intended to imply that health IT systems need to support all of the listed standards and implementation specifications. Rather, in the event that a health IT developer or health care provider seeks to address a particular interoperability need, the ISA should serve as the first resource consulted to inform the selection of standards and implementation specifications. Additionally, the ISA is designed to inform the “what” that could be used to address an interoperability need in order to assure industry consistency around standards selection and is not mean to explicitly direct “how” the standards and implementation specifications would be implemented to address an interoperability need (e.g., application programming interface or conversion tools).
The ISA is designed to be a coordinated catalog of standards and implementation specifications that can be used by different stakeholders to consistently address a specific interoperability need. However, a listed interoperability need (and its associated standard(s) and implementation specifications(s)) is not meant to universally apply to all stakeholders. Rather, if a listed interoperability need is relevant to a particular clinical specialty, for example, the ISA is designed to provide a consistent foundation from which these stakeholders can agree on applicable technical requirements. Similarly, in cases where a listed interoperability need is not applicable to a given stakeholder group, the ISA in no way compels such stakeholders to consider that interoperability need.
The Interoperability Standards Advisory is meant to serve at least the following purposes:
- To provide the industry with a single, public list of the standards and implementation specifications that can best be used to address specific clinical health information interoperability needs. Currently, the ISA is focused on interoperability for sharing information between entities and not on intra-organizational uses.
- To reflect the results of ongoing dialogue, debate, and consensus among industry stakeholders when more than one standard or implementation specification could be used to address a specific interoperability need, discussion will take place through the ISA public comments process. The web-version of the ISA will improve upon existing processes, making comments more transparent, and allowing for threaded discussions to promote further dialogue.
- To document known limitations, preconditions, and dependencies as well as provide suggestions for security best practices in the form of security patterns for referenced standards and implementation specifications when they are used to address a specific clinical health IT interoperability need.
The ISA is designed to provide clarity, consistency, and predictability for the public regarding the standards and implementation specifications that could be used for a given clinical health IT interoperability purpose.
Stakeholders who administer government programs, procurements, and testing or certification programs with clinical health IT interoperability components are encouraged to look first to the ISA in order to more fully inform their goals. In that regard, standards and implementation specifications in the ISA and their associated informative characteristics are also available to help more fully inform policymaking. In this case, a standard or implementation specification’s reference in the ISA may serve as the initial basis for industry or government consideration and action. While the ISA itself is a non-binding document, standards and implementation specifications listed in the ISA may be considered for rulemaking or other Federal requirements. However, those decisions would be made on a case-by-case basis by the administering organization.
The ISA is organized and structured into five sections.
- Section I – Vocabulary/Code Sets/Terminology Standards and Implementation Specifications (i.e., “semantics”).
- Section II – Content/Structure Standards and Implementation Specifications (i.e., “syntax”).
- Section III – Standards and Implementation Specifications for Services (i.e., the infrastructure components deployed and used to address specific interoperability needs)
- Section IV – Models and Profiles
- Section V – Questions and Requests for Stakeholder Feedback
Within each section specific “interoperability need” subheadings are listed and followed by the table illustrated below. Each interoperability need may have one or more standards and/or implementation specifications associated with it. Each standard and implementation specification has six informative characteristics attributed to it in order to provide added context.
When known, an “emerging” standard or implementation specification is also listed and is shaded in a lighter color and italicized for additional emphasis. In addition, for vocabulary standards, where there may be one standard used to represent the “observation” or question being asked, and one standard used for the “observation value” or answer these are listed in distinct rows.
The ISA also now includes links within the limitations, dependencies and preconditions to ONC’s Interoperability Proving Ground (IPG) to showcase real-world implementations of standards listed within the ISA. Please note: when accessing links to the IPG, all projects for the selected standard will be listed, including those that may be demonstrating use of the standard for different interoperability needs. In addition, IPG entries are self-reported by stakeholders, so the quality and accuracy of the data may vary across entries.
In Section I, the vocabulary standards with unspecified code sets or context may be further constrained by a more explicit standard named in a subsequent section. For example, I-B Encounter Diagnoses specifies SNOMED-CT and ICD-10-CM but does not define the context of use. The Standard/Implementation Specification named for the “Interoperability Need: Ordering Labs for a Patient in Section II-M: Laboratory” further constrains the diagnosis for the patient in the context of a lab order to ICD-9CM or ICD-10CM since the lab order diagnosis is for billing/claims, not clinical diagnostics.
| Standard Implementation/Specification | Standards Process Maturity | Implementation Maturity | Adoption Level | Federally Required | Cost | Test Tool Availability |
|---|---|---|---|---|---|---|
| Standard | Final | Production |  |
No | Free | No |
| Standard for observations | Final | Production | |
Yes | Free | Yes |
| Standard for observation values | Final | Production | |
No | Free | Yes |
| Emerging Standard | Balloted Draft | Pilot |  |
No | Free | No |
| Limitations, Dependencies, and Preconditions for Consideration: |
Section I: Applicable Value Set(s): Sections II & III: Applicable Security Patterns for Consideration: |
|---|---|
|
|
The following describes the ISA’s six informative characteristics in greater detail. This detail is meant to better inform stakeholders about the maturity and adoptability of a given standard or implementation specification and provides definition for the terms and symbols used throughout the ISA. These definitions remain similar in nature to those presented in the 2016 ISA, but have been modified slightly to provide additional clarity as requested by public comments. Stakeholders should consider all six characteristics together to gain insight into the level of maturity and adoptability of the standards and implementation specifications provided within the ISA.
#1: Standards Process Maturity
This characteristic conveys a standard or implementation specification’s maturity in terms of its stage within a particular organization’s approval/voting process.
- “Final” – when this designation is assigned, the standard or implementation specification is considered “final text” or “normative” by the organization that maintains it. This also includes approved “ANSI Informative” specifications.
- “Balloted Draft” – when this designation is assigned, the standard or implementation specification is considered to be a Draft Standard for Trial Use (DSTU), Standard for Trial Use (STU), or in a “trial implementation” status by the organization that maintains it and has been voted on or approved by its membership as such. This designation does not include standards and implementation guides that are unofficial drafts and early “works in progress”.
- “In Development” – when this designation is assigned, the standard or implementation specification is currently in development. It also includes those that are in the midst of being balloted. These standards would generally benefit from lessons learned through development and pilots.
#2: Implementation Maturity
This characteristic conveys a standard or implementation specification’s maturity based upon its implementation state. Where available, a link to published maturity assessments based on known published criteria about the standards is also provided. [See Question 5, Section V]
- “Production” – when this designation is assigned, the standard or implementation specification is being used in production to meet a health care interoperability need.
- “Pilot” – when this designation is assigned, the standard or implementation specification is being used on a limited scale or only as part of pilots to meet a health care interoperability need.
#3: Adoption Level
This characteristic conveys a standard or implementation specification’s approximate, average adoption level for that specific interoperability need in health care within the United States. The adoption level attempts to consider all implemented technology that would be used to address the identified interoperability need and is not limited to EHRs. Adoption means that the standard or implementation specification is being used in health IT in the field by end users to address the specific interoperability need. Presently, the adoption levels listed are based on ONC’s analysis of several factors, including, but not limited to: 1) whether and/or how long a standard or implementation specification has been included in regulation for health IT certification (if applicable) or another HHS regulatory or program requirement which is used only as a proxy for industry adoption; 2) feedback from subject matter experts and 3) public comments.
The adoption level also considers the variety of stakeholders and stakeholder groups that would use the standard and implementation specification to address the specified interoperability need and attempts to display it as such, with the understanding that the designation is a generality and not a pre-defined measured value. Where available, annotated references or links to publicly available documentation known about adoption levels for listed standards is also provided. [See Question 6, Section V]
The following scale is used to indicate the approximate, average adoption level among the stakeholders that would use a standard or implementation specification to meet the specified interoperability need:
| “Feedback Requested” | Indicates that we do not have a known status for the current level of adoption in health care. |
|
Indicates low adoption. |
 |
Indicates low-medium adoption. |
 |
Indicates medium adoption. |
|
Indicates medium-high adoption. |
 |
Indicates high or widespread adoption. |
#4: Federally Required
This characteristic (provided as a “Yes” or “No”) conveys whether a standard or implementation specification has been adopted in regulation, referenced as a federal program requirement, or referenced in a federal procurement (i.e., contract or grant) for a particular interoperability need. Where available, a link to the regulation has been provided.
#5: Cost
This characteristic conveys whether a fee is involved to purchase, license, or obtain membership for access or use of the recommended standard or implementation specification.
- “$” – when this designation is assigned, it signifies that some type of payment needs to be made in order to obtain the standard or implementation specification. Where known, the estimated cost for access will be provided.
- “Free” – when this designation is assigned, it signifies that the standard or implementation specification can be obtained without cost. This designation applies even if a user account or license agreement is required to obtain the standard at no cost.
#6: Test Tool Availability
This characteristic conveys whether a test tool is available to evaluate health IT’s conformance to the standard or implementation specification for the particular interoperability need. Where available, a link will be provided to the publicly available test tool. [See Question 7, Section V]
- “Yes” – When this designation is assigned, it signifies that a test tool is available for a standard or implementation specification and is free to use. Where available, a hyperlink pointing to the test tool will be included.
- “Yes$”– When this designation is assigned, it signifies that a test tool is available for a standard or implementation specification and has a cost associated with its use. Where available, a hyperlink pointing to the test tool will be included.
- “Yes – Open” – When this designation is assigned, it signifies that a test tool is available for a standard or implementation specification and is available as open source with rights to modify. Where available, a hyperlink pointing to the test tool will be included.
- “No” – When this designation is assigned, it signifies that no test tool is available for a standard or implementation specification.
- “N/A” – When this designation is assigned, it signifies that a test tool for the standard or implementation would be “not applicable.”
