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. For historical background on the ISA please review prior ISA publications.
The 2018 ISA has been updated to include improvements made based on recommendations received from public comments and subject matter expert feedback. To learn more about major revisions of the ISA, please review recent ISA updates. Registered users may subscribe to change notifications to be alerted by e-mail of all revisions to individual interoperability needs or for ISA-wide changes. Anyone may become a registered user by submitting an account request. Once logged in, look for the blue “change notification” button at the bottom of the interoperability need page, or at the bottom of the home page to be notified of any changes across the ISA.
Note that due to the volume of comments received, some comments will be addressed, with feedback incorporated to the web version of the ISA in early 2018.
Scope
Starting with the 2017 ISA, the ISA’s focus 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). In late 2017, and included in the 2018 Reference Edition, the ISA now also includes interoperability needs related to Administrative functions within healthcare. These additions were made through coordination with CMS, and it is anticipated to include other administrative healthcare interoperability needs throughout 2018.
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 healthcare 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 improves 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 and meant to be advisory in nature, 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 – Administrative Standards and Implementation Specifications (i.e., payment, operations and other "non-clinical" interoperability needs)
- Section VI – Questions and Requests for Stakeholder Feedback
- Appendices
Within each section specific “interoperability need” subheadings are listed and followed by tables similar to the one 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. See Appendix II for educational information about observations and observation values.
The ISA also 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-L: 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) and Starter Set(s): Other Sections: 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 originally 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.
- “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 or "best guess" 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.
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. Please note this is meant to be provided as a reference only. Entities seeking to comply with federal regulations should look to any and all federal regulations that may apply to ensure adequate compliance.
#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, but is not meant to imply that there are no costs associated with implementation.
#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.
- “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.”
Comment
Dear Madam,…
Dear Madam,
Dear Sir,
On behalf of the IVD Industry Connectivity Consortium we are pleased to provide written comments to the Office of the National Coordinator for Health Information Technology (ONC) in response to the 2017 Interoperability Standards Advisory (ISA).
The IVD Industry Connectivity Consortium (IICC) is a global, nonprofit organization dedicated to creating and encouraging adoption of a unified connectivity standard to reduce the cost and variability of data exchange between IVD devices and healthcare informatics in clinical laboratories. This will improve healthcare efficiency and patient care.
The IICC has collaborated with several government bodies, including the US Food and Drug Administration (DMD/OIR/CDRH), US Centers for Disease Control and Prevention, and US Department of Health and Human Services (HHS) (ONC), National Institutes of Health (NIH), and industry organizations such as IHE International, HL7, Clinical & Laboratory Standards Institute, the College of American Pathologists, the Association of Public Health Laboratories (APHL), the Medical Device Innovation Consortium (MDIC), and the Regenstrief Institute to develop two standards that together allow for true Plug & Play connectivity of IVD instruments to Middleware and Laboratory Information Systems (LIS).
The IVD Industry Connectivity Consortium appreciates the opportunity to leverage our volunteers’ expertise in commenting on the Standards Advisory, and we look forward to continuing our dialogue with ONC on identifying, assessing, and determining the best available interoperability standards and implementation specifications. We feel that this effort will provide the necessary foundation for more rapidly advancing interoperability.
The IVD Industry Connectivity Consortium finds that it would be beneficial if ONC would add the LAW – Laboratory Analytical Workflow Profile and LIVD – Digital Format for Publication of LOINC to Vendor IVD Test Results standards to the following proposed new sections:
Type
Standard/Implementation Specification
Standards
Process
Maturity
Implementation Maturity
Adoption Level
Federally
Required
Cost
Test Tool
Availability
Standard
LIVD – Digital Format for Publication of LOINC to Vendor IVD Test Results
Final
Production
1
No
Free
No
Type
Standard/Implementation Specification
Standards
Process
Maturity
Implementation Maturity
Adoption Level
Federally
Required
Cost
Test Tool
Availability
Standard
LAW – Laboratory Analytical Workflow Profile
Final
Production
3
No
Free
Yes
For more information on LAW [ click here ]
For more information on LIVD [ click here ]
Why are LAW and LIVD important for clinical laboratories?
The LAW Profile and LIVD specifications should have a significant positive impact on laboratory operations. Clinical laboratories are encouraged to ask their instrument, middleware, and LIS vendors about their current or planned support for the IICC/IHE Laboratory Analytical Workflow (LAW) and LIVD. The LAW Profile is currently being implemented by all major IVD companies.
The IVD Industry Connectivity Consortium (IICC) would also ask ONC’s support to make both standards “Federally Required” for federal agencies as well as commercial entities.
We appreciate the opportunity to submit comments on the 2017 ISA. Our comments are intended to recognize the importance of each stakeholder’s role in advancing standards-based interoperability and health information exchange, and ensuring that each domain is invested in overcoming the inherent challenges, while further enhancing health IT’s pivotal role in enabling healthcare transformation.
Please feel free to contact me if you have any questions or to obtain more information.
Sincerely,
Serge Jonnaert, BiD
President, IVD Industry Connectivity Consortium - ivdconnectivity.org
serge.jonnaert@ivdconnectivity.org
+1.949.259.3807
/ Board Member, At-Large - IHE International - ihe.net
/ President, AERTWORKS® LLC – www.aertworks.com
Premier healthcare alliance: Comments on ISA
Dear Dr. Rucker,
The Premier healthcare alliance is pleased to submit these comments in response to the Office of the National Coordinator’s (ONC) Request for Public Comments regarding the Interoperability Standards Advisory (ISA).
Premier is a leading healthcare improvement company, uniting an alliance of approximately 3,900 U.S. hospitals, hundreds of thousands of clinicians and more than 150,000 other provider organizations. Premier has one of the most comprehensive and largest healthcare databases in the industry. Premier works with its members on utilizing informatics, analytics, and data to improve care quality and patient safety, while achieving cost efficiencies. With integrated data and analytics, collaboratives, supply chain solutions, and advisory and other services, Premier enables better care and outcomes at a lower cost. Premier, a Malcolm Baldrige National Quality Award recipient, plays a critical role in the rapidly evolving healthcare industry, collaborating with members to co-develop long-term innovations that reinvent and improve the way care is delivered to patients nationwide. Specific comments in response to your questions are provided in the attached chart.
Premier shares the vision of achieving health information technology interoperability and the establishment and deployment of core standards and functions of health information technology (HIT) to enable an interoperable, learning health ecosystem. Premier appreciates ONC’s ongoing efforts to develop and enhance the ISA. However, the existence of standards and the publication of the ISA does not by itself ensure that application developers and HIT vendors implement and configure their software using the standards. Certainly, nationwide healthcare data exchange requires standards development and their timely adoption. Beyond exchange of data, however, interoperability requires data usability, understandability and development, recognition and adoption of common data sets, clinical terminologies and vocabularies and data definitions. Additionally, standards are needed for openly accessible electronic health record application program interfaces (APIs) to assure interoperability with other health information technologies and third party applications.
Premier hopes our comments (detailed in the attached letter) are helpful as you continue this important work. Premier stands ready to actively participate in ONC’s ongoing efforts to achieve nationwide interoperability. Please feel free to contact us for participation in your listening sessions, workgroups and other activities.
If you have any questions regarding our comments or need more information, please contact me or Meryl Bloomrosen, Senior Director, Federal Affairs, at meryl_bloomrosen@premierinc.com or 202.879.8012. We look forward to continued participation and dialogue. Thank you again for the opportunity to provide comments.
Sincerely,
Blair Childs
Senior vice president, Public Affairs
Premier healthcare alliance
Allscripts Comments on ONC 2017 Interoperability Standards
We thank you for the opportunity to review and provide as input perspectives gathered from our subject matter experts.
NCPDP - Scope Comments
IHE QRPH Domain Standard Addition Request
AMA's comments to ONC on proposed 2018 ISA
On behalf of American Medical Association (AMA) I appreciate the ability to comment on ONC's Interoperability Standards Advisory (ISA).
Section I: Vocabulary/Code Set/Terminology Standards and Implementation Specifications
Comment:
The AMA recommends that the ISA include a seventh characteristic to the interoperability need table to inform stakeholders of the presence and inclusion of the terminology’s guidelines. The use of a terminology’s guidelines is critical for consistent application of the codes and semantic interoperability of the data being exchanged through the terminology. Consistent use of codes further ensures comparability of data that can better quantify the value of care and determine outcomes. The following shows how this additional characteristic would be included in the table.
Representing Medical Procedures Performed
Type
Standard Implementation/Specification
Guidelines
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
SNOMED CT®
Yes
Final
Production
Yes
Free
N/A
Standard
the combination of CPT-4 and HCPCS
CPT-4: Yes
HCPCS: Yes
Final
Production
Yes
$
N/A
Standard
ICD-10-PCS
Yes
Final
Production
Yes
Free
N/A
UCSF Center for Digital Health Innovation's Comments on 2018 ISA
Dear Dr. Rucker,
UC San Francisco’s Center for Digital Health Innovation submits these comments on the 2018 Reference Edition of the Interoperability Standards Advisory. We thank you for the opportunity to provide these comments.
Very truly yours,
Mark Savage
Mark Savage
Director, Health Policy
Center for Digital Health Innovation
University of California, San Francisco
E. Mark.Savage@ucsf.edu
C. 415.225.1676
O. 415.502.1997
CDISC Requests from 2018 ONC ISA
Thank you for the opportunity to provide input on the 2018 Interoperability Standards Advisory (ISA) online document. Although the catalog focuses on the implementation needs of healthcare, it will play a role in ONC’s programs that support the 21st Century Cures Act. The Clinical Data Interchange Standards Consortium (CDISC) has engaged in projects with our fellow standards development organizations such as the Regenstrief Institute, IHE and HL7 over the past year to also help support 21st Century Cures Act and other initiatives at the intersection of care and research.
CDISC believes that, in order to realize the full impact of the bill, we as a society must invest in interoperation between existing healthcare and biomedical research standards and infrastructure. We thank the ONC for recognizing the importance of research as part of a learning health system through the inclusion of CDISC standards in the ISA. Our standards provide a consensus-based global language for protocol-driven clinical and translational research. They are also part of a larger tapestry of common research standards.
Many, if not most, major components of cancer-related research infrastructure in the United States are assets of or are being/have been funded by the United States National Cancer Institute (NCI). Their Enterprise Vocabulary Services (EVS) team manages dozens of commonly used semantic structures for research, including but not limited to CDISC terminology, and health. The following recommendations and requests are in support of expanding the ISA to include appropriate semantics to support ONC’s activities toward the 21st Century Cures Act. We recommend the following updates in support of cancer, and broader, research as it pertains to the coordination of multiple agencies involved with human health and research-based evolution:
We appreciate the ONC’s consideration of these requests and suggestions.
Lauren Becnel, Ph.D.
VP Strategy & Innovation
Clinical Data Interchange Standards Consortium (CDISC)
Kaiser Permanente Comments on ONC's Proposed 2018 ISA
Please see attached document
DoD / VA Interagency Program Office (IPO) comments on 2017 ISA
Thank you for allowing us an opportunity to provide comments on the 2017 as you prepare for the 2018 version. Included within our comments are comments we also received from VHA representatives. If there are any questions regarding our comments, please let me know. This document is key to help move the Industry towards a more open and standard's based approach in exchanging Health information.
Very Respectfully,
Chris Hills
Regenstrief Institute comments on the 2018 ISA
Thank you for the opportunity to provide comments on the 2017 edition of the ISA. We want to start by thanking ONC for their efforts to continually improve the ISA. The evolution of the format greatly improves its usefulness and navigation, especially the web-based layout and in-context comments.
The added clarity on standards for observations and observation values is also a very important and welcome improvement. Across many interoperability needs, the ISA pairing of LOINC and SNOMED CT is an appropriate and helpful distinction.
Since publication of the 2017 edition, the ISA has expanded considerably in scope. It now includes a new section for Administrative Standards and interoperability needs around research and public health. The spectrum from public health to clinical care (including its administrative component) to clinical research is much more a continuum than discrete domains. We strongly support building towards a common, shared infrastructure across this spectrum and thus having them together in the ISA makes sense. However, the current set of interoperability needs across these domains are not very clearly defined and appear more to be generic labels for existing standards rather than actual use cases. Similarly, it is unclear why Administrative standards needs a separate section, when those standards also have the components of vocabularies and structures (and, perhaps later, models).
We strongly agree with the suggestions made by the IVD Industry Connectivity Consortium (IICC) that ONC should add two new interoperability needs naming the LAW – Laboratory Analytical Workflow Profile and LIVD – Digital Format for Publication of LOINC to Vendor IVD Test Results standards.
As we previously recommended, there are three high-value, well-established domains where the ISA can recommend additional vocabulary standards. They are a) Clinical measurements and observations, b) Clinical document types, and c) Patient reported outcome measures, survey instruments, and other standardized patient assessments.
There are large scale implementations around the world who have implemented the vocabularies in this way. And this usage has been recommended previously in the U.S. in many contexts, including the CHI initiatives, HITSC, and others.
Specifically, we recommend adding these areas to the ISA Section I: Vocabulary/Code Set/Terminology Standards and Implementation Specifications:
__
Daniel J. Vreeman, PT, DPT, MS, FACMI
Director, LOINC and Health Data Standards, Regenstrief Center for Biomedical Informatics
Regenstrief-McDonald Scholar in Data Standards, Indiana University School of Medicine
Research Scientist, Regenstrief Institute, Inc
FHA's Comments on ONC's ISA new edition
SECTION VI: Questions and Requests for Stakeholder Feedback
Section II: Content/Structure Standards and Implementation Specifications
Under “Case Reporting to Public Health Agencies”,
HL7 FHIR Implementation Guide: Structured Data Capture (SDC) Release 1. The page link is broken.
Section V: Administrative Standards and Implementation Specifications
Under “V-A: Health Care Claims and Coordination of Benefits”
“Health Care Claims or Equivalent Encounter Information for Retail Pharmacy Claims” is listed twice and one of the two links is broken. It leads to an unavailable temporary link.