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 United States 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 ISA is frequently 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. An RSS Feed was also added in 2018, capturing more granular updates made to the ISA.
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). Added in late 2017, the ISA now also includes interoperability needs related to Administrative functions within healthcare. These additions were made through coordination with CMS, other administrative healthcare interoperability needs continue to be added.
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 a 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.
Please note that the ISA serves as an informational resource for available standards, specifications, profiles, etc that exist to meet the interoperability needs contained within. Stakeholders should ensure and verify that they are adhering to applicable federal, state, and/or local laws or regulations regarding requirements to use a specific standard or specification that may conflict with the information listed in the ISA, as these requirements supersede the ISA.
The Interoperability Standards Advisory is meant to serve at least the following purposes:
- To provide the industry with a single, public list of standards and implementation specifications that can be used to address specific health information interoperability needs in the United States. 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.
This site contains numerous links to other federal agencies and to private organizations. You are subject to these sites’ privacy policies when you access them. HHS is not responsible for Section 508 compliance (accessibility) on other federal or private sites. HHS is not responsible for the contents of any "off-site" web page referenced from this site.
Comment
Submitted by ravi.kafle@doh… on
ISA Comments from Washington State Department of Health
Please refer to the attached comments from the Washington State Department of Health. Thank you for the opportunity to comment.
Submitted by AMIA_Policy on
AMIA's Comments on the ONC ISA 2024 Reference Edition
Please see attached the American Medical Informatics Association's feedback on the 2024 ISA Reference Edition. Thank you for the opportunity to comment.
Submitted by AMIA_Policy on
AMIA's Comments on the ONC ISA 2024 Reference Edition
Please see attached the American Medical Informatics Association's feedback on the 2024 ISA Reference Edition. Thank you for the opportunity to comment.
Submitted by AMIA_Policy on
AMIA's Comments on the ONC ISA 2024 Reference Edition
Please see attached the American Medical Informatics Association's feedback on the 2024 ISA Reference Edition. Thank you for the opportunity to comment.
Submitted by Solarf3050 on
HL7's Feedback on the 2024 ISA Reference Edition
Please see attached Health Level Seven International's feedback on the 2024 ISA Reference Edition. Thank you for the opportunity to comment.
Submitted by Solarf3050 on
HL7's Comments on the 2023 ISA Reference Edition
Please see attached Health Level Seven International's feedback on the 2023 ISA Reference Edition. Thank you for the opportunity to comment.
Master 2023 ISA Draft Consolidated Response 06.05.23 FINAL.pdf
Submitted by Riki Merrick on
APHL Comments on ISA 2022
APHL strongly supports the mission of the Interoperability Standards Advisory (ISA) and thus is respectfully submitting the following comments on the current version of the ISA
Vocabulary/Code Set/Terminology Standards and Implementation Specifications
General comment for this section:
In several sections the ISA lists implementation guides rather than linking to the explicit vocabulary defined in those guides (for example HL7 FHIR (v4.0.1) Situational Awareness for Novel Epidemic Response (SANER) IG 0.1.0 Continuous Build and the Logica COVID-19 (FHIR v4.0.1) Implementation Guide CI Build under COVID-19 Novel Coronavirus Pandemic , or in the referenced FHIR resources NutritionIntake and NutritionProduct under Representing Nutrition Assessment, Diagnosis, Interventions and Monitoring/Evaluation).
#1: Suggest to review and update with the respective code systems (or value sets, if appropriate to constrain to that level).
- Representing Non-imaging and Non-laboratory Clinical Tests:
Currently the section under “Limitations, Dependencies, and Preconditions for Consideration” includes a bullet explaining that this attribute really consists at minimum of 2 elements,
#1 Suggest to split attribute into “Clinical Test performed” and “Clinical Test Result Value” as a main section to avoid confusion when different code systems are suggested. That way it is clear that LOINC is the coding system to identify the “Clinical Test performed”, while SNOMED CT, mostly drawn from the clinical finding hierarchy, should be used when codifying results under “Clinical Test Result Value”. Other code systems useful in this context are Unified Units of Measure (UCUM) when numeric results are reported – this is described as its own attribute (Representing Units of Measure (For Use with Numerical References and Values), but the association to result values should be pointed out here.
-- Representing Laboratory Test Ordered
This section is missing a separate category for Specimen, which should point to SNOMED CT (from the specimen hierarchy).
#1 Suggest to add a new attribute “Specimen information” which should have the following sub-attributes, some of which are mentioned in the USCDI:
Specimen Type – referencing SNOMED CT (from the specimen hierarchy)
Specimen source site – referencing SNOMED CT (from the body structure and physical object hierarchies)
Source site modifier – referencing SNOMED CT (from the qualifier hierarchy)
Specimen collection method – referencing SNOMED CT (from the procedure hierarchy)
The reference to CPT is confusing as the goal is to order lab tests using LOINC wherever possible (as further defined in the Laboratory Order Interface (LOI) Implementation Guide in the Ordering Laboratory Tests for a Patient section) and the use of CPT is uncommon in this use case. CPT codes are commonly used for billing, which should be a separate section under laboratory to accommodate the administrative use case.
#2 Suggest to remove CPT from this section and create a separate section “Representing Laboratory Test in Billing” where CPT should be listed – with the same attributes as currently in this section.
Content/Structure
-- Exchanging InVitro Diagnostics (IVD) Test Orders & Results
LIVD – Digital Format for Publication of LOINC to Vendor IVD Test Results :
#1 Suggest to remove the ‘$’ in the “Cost” column as there is no cost associated with accessing or using this implementation guide.
-- Ordering Laboratory Tests for a Patient
#1Suggest to update HL7 Version 2.5.1 Implementation Guide: Laboratory Orders from EHR (LOI) Release 1, STU Release 3 - US Realm to the latest version of LOI version (will provide updated name and hyperlink once published in October 2022)
#2 Suggest to update the HL7 Version 2 Implementation Guide: Laboratory Value Set Companion Guide Release 1, STU Release 3 - US Realm HL7 Standard for Trial Use to the latest version (will provide updated name and hyperlink once published in October 2022) in support of LOI
#3 Suggest to add this Implementation Guide from Jan 2021: HL7 Version 2.5.1 Implementation Guide: Standards & Interoperability (S&I) Framework Laboratory Test Compendium Framework (eDOS) Ask at Order Entry (AOE) Release 2, STU Release 3.1 - US Realm because it provides guidance on using the most common Ask at Order Entry questions; “Adoption Level” Emerging Standard. Of note is that this IG is not explicitly implemented, but rather used as a resource by laboratories when setting up their catalog and order messages.
-- Receive Electronic Laboratory Test Results
#1 Suggest to update HL7® Version 2.5.1 Implementation Guide: Lab Results Interface (LRI) Release 1, STU Release 3 - US Realm to the latest version of LOI version (will provide updated name and hyperlink once published in October 2022)
#2 Suggest to HL7® Version 2 Implementation Guide: Laboratory Value Set Companion Guide Release 1, STU Release 3 - US Realm, June 2018 to the latest version (will provide updated name and hyperlink once published in October 2022) in support of LRI
#3 Suggest to add the following text into “Limitations, Dependencies, and Preconditions for Consideration”: While the HL7® Version 2.5.1 Implementation Guide: S&I Framework Lab Results Interface, Release 1—US Realm [HL7 Version 2.5.1: ORU_R01] Draft Standard for Trial Use, July 2012 was named in Meaningful Use and may thus be implemented at a few sites, the recommended standard for new implementations is <the new version of HL7® Version 2.5.1 Implementation Guide: Lab Results Interface (LRI) Release 1, STU Release 3 - US Realm> because that is the specification that is actively being maintained and updated with new use cases, when needed.
#1 Suggest to HL7® Version 2 Implementation Guide: Laboratory Value Set Companion Guide Release 1, STU Release 3 - US Realm, June 2018 to the latest version (will provide updated name and hyperlink once published in October 2022) in support of eDOS
#2 Suggest to add HL7 Version 2.5.1 Implementation Guide: Standards & Interoperability (S&I) Framework Laboratory Test Compendium Framework (eDOS) Ask at Order Entry (AOE) Release 2, STU Release 3.1 (US Realm), because prior to this release this content was published as Appendix A in a single document as part of HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Test Compendium Framework (eDOS) Release 2, STU Release 3 (US Realm). In 2021, the AOE content was published separately for greater visibility and because it is standard agnostic, except for the data types which may be different for HL7 V2 vs. HL7 FHIR. There is an HL7 project (1634) to publish an update in the future to also reference FHIR datatypes.
-- Unique Device Identification
#1 Suggest to update HL7 Cross-Paradigm Implementation Guide: UDI Pattern, Release 1 to the latest release: HL7 Cross Paradigm Implementation Guide: UDI Pattern, Release 2 for all sub-points in this section (Defining a Globally Unique Device Identifier, Representing Unique Implantable Device Identifiers and Transmitting a Unique Device Identifier); its adoption level should be increased since this is being used as building blocks for implementation of other IGs in certified systems across the US.
Submitted by mphillips@caqh.org on
CAQH CORE Comments on the ONC ISA Annual Update
- CAQH CORE appreciates the opportunity to provide content updates for the 2023 ISA Reference Edition and web version.
- CAQH CORE has proposed several substantive updates including the addition of two new Operating Rule Sets supporting value-based payment and requirements to ensure secure and consistent connectivity between trading partners. Details surrounding these Operating Rules, including the language that is proposed for entry into the 2023 ISA Reference Edition and web version, are in the attached document on pages 4-5.
- Non-substantive updates include edits to address consistency in naming conventions, the order that CAQH CORE Operating Rules appear on the web version of ISA and the 2023 ISA Reference Edition, and other grammar and syntax corrections. These changes are interspersed throughout the attached document highlighted in gray. Proposed deletions are highlighted gray and shown with strikethrough text.
- Additional comments have been entered into the web version of the ISA for each CAQH CORE Operating Rule directing the reader to the pages in the attached document where changes have been made.
Submitted by jkegerize on
ACLA ISA comment re: Annual Reference Edition
We appreciate the annual Reference Edition .pdf, but Is it also possible to get a revision marked version of the annual draft for comment and reference edition ISA in future? Narrowing the review to content that has changed will allow us greater focus on future comments.
Submitted by Victius on
Over recent years, the…
Over recent years, the healthcare industry has undergone a huge digital transformation due to the need to completely update its existing infrastructure.