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.

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). 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. 

Purpose

The Interoperability Standards Advisory is meant to serve at least the following purposes:

1. 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.  
2. 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.
3. 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. 

The ISA is organized and structured into four sections.

• Vocabulary/Code Sets/Terminology Standards and Implementation Specifications (i.e., “semantics”).
• Content/Structure Standards and Implementation Specifications (i.e., “syntax”).
• Standards and Implementation Specifications for Services and Exchange (i.e., the infrastructure components deployed and used to address specific interoperability needs)
• Administrative Standards and Implementation Specifications (i.e., payment, operations and other "non-clinical" interoperability needs)
• 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 III for educational information about observations and observation values. 

In the Vocabulary/Terminology section, 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, 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 Content/Structure: 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.

Interoperability need: [Descriptive Text]

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

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. 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 are 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.”

Comments on the ISA are accepted year-round, and changes are made to the web version of the ISA frequently throughout the year, based on comments and other changes to the health IT standards environment as ONC becomes aware of them. An annual Review and Comment period also occurs each summer-fall, when a majority of comments are received. See the process timeline below for more details. 

Annual ISA Process Timeline

• January: Current Year Reference Edition is published, web version of ISA is available for ongoing review and comments.
• Winter/Spring/Summer: Changes may be made to the web-version of the ISA throughout the year, while the ISA Reference Edition remains static.
• Late Summer/Early Fall: Annual Review and Comment Period opens for sixty days - site changes are on hold so all reviewers are seeing the same content. 
• Fall: ONC and HHS staff review comments received, make site updates and prepare the following year's Reference Edition for publication by early January. 

How to Comment on the ISA

• An ISA site account is required in order to comment on the ISA.
  • If you have an account already, click the "Login" button at the top right of the ISA. 
  • To create an account, click the "Login" button, then "Create new account" tab above the login window. Account approval is required, and is generally completed within 1 - 24 hours. 
• Once you're authenticated to the ISA site, you can submit comments on most ISA pages - just scroll to the bottom of the relevant page, enter the text of your comment (or provide attachments, if needed) and submit. Your comment will be reviewed by ONC or other HHS subject matter experts, and changes will be considered for publication to the ISA. 
• While comments by topic (posted to individual Interoperability Need pages) are preferred, and allow greater visibility to your comments by other industry stakeholders, consolidated comment letters are also accepted. You may provide these comments on general information pages, and ONC staff will triage them, and assign them to subject matter experts. 

What is the ISA?

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. For more information, see the About the ISA page.

Who is the ISA for?

The ISA is meant to serve as a resource for the health IT community. ONC has heard from stakeholders across the health IT industry – public health agencies, standards development organizations, health IT developers, healthcare delivery systems, hospitals, and more – that they are finding a single list of available standards to be a helpful resource for their work to improve healthcare through interoperability.

How often is the ISA updated?

The web version of the ISA is updated on a regular basis by ONC and other HHS staff as changes in the health IT standards environment become apparent or when public comments are received at any point throughout the year. Annually, ONC solicits comments during an official “review and comment period”, typically in the Summer/Fall timeframe, which helps ensure the ISA content is up to date for the annual Reference Edition publication.

How can I comment?

To comment, you’ll need to create an account first. See the Timeline and Comment Process page for more information about account creation, tips for comments, and more.

What is the Reference Edition?

ONC began publishing ISA Reference Editions in 2017 when the ISA transitioned from a static PDF document (with draft/final versions and multiple comment periods annually) to a more interactive web platform. The Reference Edition is meant to provide a stable, non-changing version of the ISA that can be pointed to by industry stakeholders that have that requirement (i.e., for use in contracts, etc). The web version of the ISA is intended to be dynamic and may change a number of times throughout the year as additional comments are received or as ONC becomes aware of changes in the standards listed within the ISA.

How is adoption level calculated?

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. 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 are also provided.

Can I propose an interoperability need that is not listed?

Yes - ONC is always looking for additional interoperability needs that might be valuable for industry stakeholder awareness. You can propose a new interoperability need through the ongoing comment process (account required).

Am I required to use the standards listed in the ISA? 

A standard's listing in the ISA itself does not require its implementation or adoption. 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, program requirements, 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 (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.

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). 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. 

Purpose

The Interoperability Standards Advisory is meant to serve at least the following purposes:

1. 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.  
2. 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.
3. 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. 

Current and Historical ISA Publications include:

• 2024 ISA - Reference Edition (published February 2024)
• 2023 ISA - Reference Edition (published January 2023)
• 2022 ISA - Reference Edition (published January 2022)
• 2021 ISA - Reference Edition (published January 2021)
• 2020 ISA - Reference Edition (published December 2019)
• 2019 ISA - Reference Edition (published January 2019)
• 2018 ISA - Reference Edition (published December 2017)
• 2017 ISA - Reference Edition (published December 2016)
• 2016 ISA - Final Version (published December 2015)
  • 2016 ISA Public Comments
• 2016 ISA - Draft (published August 2015)
  • 2016 Draft ISA Public Comments
• 2015 ISA (published January 2015)
  • 2015 ISA Public Comments

Check here regularly for the latest updates to the ISA. Please note, that revisions to individual interoperability needs (such as adding/removing of standards or changes to their informative characteristics) are not included here. Revision history is available on each ISA page. In addition, 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. Once logged in, look for the blue “change notification” button at the bottom of the interoperability need page, or at the bottom of this page to be notified of any changes across the ISA.

An RSS Feed that captures all changes made to the ISA is also available for visibility into more granular ISA updates.

• Winter 2023 - Added a new Administrative section Administrative Transactions: Price Transparency and Interoperability Need Advanced Estimates for Patient Costs from Providers & Payers.
• August 8, 2023 - In Section II, Content/Structure, Human and Social Services:
  • Moved Format for Sharing Social Care Services Information Interoperability Need to Section I, Vocabulary/Code Set/Terminology, Social, Psychological and Behavioral Data, and renamed to Representing Social Care Services Information
• May 23, 2023 - Renamed Referral to Extra-Clinical Services - Request, Updates, Outcome interoperability need to Referrals Between Clinicians and Community-Based Organizations and Other Extra-Clinical Services.
• Fall 2022 - Numerous changes made to address public comments received and prepare the 2023 Reference Edition, including but not limited to:
  • In Section I, Vocabulary/Code Set/Terminology, Changed Race and Ethnicity subsection to Race, Ethnicity and Tribal Affiliation:
    • Added Representing Tribal Affiliation Interoperability Need
  • Changed Section I, Vocabulary/Code Set/Terminology, Laboratory:
    • Added Representing Laboratory Test Specimen Interoperability Need
    • Changed Representing Laboratory Values and Results Interoperability Need to Representing Laboratory Result Values
  • Changed Section I, Vocabulary/Code Set/Terminology, Procedures:
    • Added Representing Social Care Procedures Interoperability Need
  • In Section II, Content/Structure, created a new Human and Social Services subsection with two new Interoperability Needs:
    • Format for Sharing Social Care Services Information
    • Format for Structuring and Sharing Social Care Directory Information 
  • Changed Section II, Content/Structure, Laboratory:
    • Changed InVitro Diagnostics( IVD) Test Orders & Results Interoperability Need to Exchange InVitro (IVD) Orders and Results
    • Changed Receive Electronic Laboratory Test Results Interoperability Need to Exchange Laboratory Test Results
    • Changed Ordering Laboratory Tests for a Patient Interoperability Need to Order Laboratory Test 
    • Changed Support the Transmission of a Laboratory’s Directory of Services to Provider’s Health IT or EHR System Interoperability Need to Transmit Laboratory Directory of Services to Provider System
  • Changed Section II, Content/Structure, Pharmacy Interoperability:
    • Renamed subsection Pharmacy Interoperability from Electronic Prescribing and consolidated with previous Drug Formulary subsection
  • In Section III, Services/Exchange:
    • Added Infrastructure subsection and Client Application Management Interoperability Need
  • Changed Section III, Services/Exchange, Resource Location:
    • Added Finding and Retrieving Human Services Information Interoperability Need
  • In Section IV, Administrative, Operating Rules for Administrative Transactions:
    • Added Attributed Patient Roster and Connectivity for Operating Rules Interoperability Needs
    • Changed Operating Rules for Benefit Enrollment Interoperability Need to CAQH® CORE Operating Rules for Enrollment and Disenrollment 
  • Added in 2022 SVAP Approved Standards throughout Reference Edition
• March 29, 2022 - Added Representing Patient Address and Representing Patient Names Interoperability Needs within Section I: Demographics.
• March 18, 2022 - Added Section I: Biologics and Representing Biological Products Interoperability Need.
• March 15, 2022 - Added Adverse Event Reporting Interoperability Need within Section II: Public Health Reporting.
• Fall 2021 - Numerous changes made to address public comments received and prepare the 2022 Reference Edition, including but not limited to:
  • Changed Vocabulary/Code Set/Terminology: Laboratory, adding two Interoperability Needs and removing one:
    • Added Representing Laboratory Test Ordered
    • Added Representing Laboratory Test Performed
    • Removed Representing Laboratory Tests
  • Changed Vocabulary/Code Set/Terminology: Tobacco Use Interoperability Need from:
    • Representing Patient Second Hand Tobacco Smoke Exposure to Representing Patient Secondhand Tobacco Smoke Exposure
  • Added Content/Structure: Added Work Information page with Work Information Templates Interoperability Need 
  • Changed Content/Structure: Admission, Discharge, and Transfer Interoperability Need from:
    • Sending a Notification of a Long Term Care Patient’s Admission, Discharge and/or Transfer Status to the Servicing Pharmacy to Sending a Notification of a Long-Term Care Patient’s Admission, Discharge and/or Transfer Status to the Servicing Pharmacy
  • Changed Content/Structure: Clinical Decision Support Interoperability Need from:
    • Sharable Clinical Decision Support to Shareable Clinical Decision Support
  • Changed Content/Structure: ePrescribing Interoperability Needs (2) from:
    • Allows a Long Term or Post-Acute Care to Request to Send an Additional Supply of Medication to Allows a Long-Term or Post-Acute Care to Request to Send an Additional Supply of Medication 
    • Allows a Pharmacy to Request a New Prescription For a New Course of Therapy or to Continue Therapy to Allows a Pharmacy to Request a New Prescription for a New Course of Therapy or to Continue Therapy 
  • Changed Administrative: Removed CMS Interoperability Standards for Provider to Provider Communication and 3 corresponding Interoperability Needs:
    • Durable Medical Equipment/Home Health Agency Document Request
    • Durable Medical Equipment/Home Health Agency Order Submission
    • Durable Medical Equipment/Home Health Agency Signature Request
• June 14, 2021 - Created new Interoperability Need: Representing Mass Vaccination Status within Vocabulary/Code Set/Terminology: Public Health Emergency Preparedness and Response.
• March 23, 2021 - Changed "Data Segmentation of Sensitive Information" sub-section and Interoperability to: "Security Tags for Sensitive Information" and added a Specialty Care/Settings page for Social Determinants of Health related Interoperability Needs.
• December 12, 2020 - Added Content/Structure: Added Work Information page with Representing Job, Usual Work, and Other Work Information Interoperability Need.
  • Removed Patient Industry and Occupation Page with Representing Patient Industry and Occupation Interoperability Need
• Fall 2020 - numerous changes made to address public comments received and prepare the 2021 Reference Edition, including: 
  • Added Vocabulary/Code Set/Terminology: Public Health Emergency Preparedness and Response, with four Interoperability Needs:
    • Representing Healthcare Personnel Status
    • Representing Hospital/Facility Beds Utilization
    • Representing Laboratory Operations (Population Laboratory Surveillance)
    • Representing Population-Level Morbidity and Mortality
  • Changed Vocabulary/Code Set/Terminology: Research Interoperability Need from Representing Analytic Data for Research Purposes to Representing Data for Biomedical and Health Services Research Purposes
  • Changed Vocabulary/Code Set/Terminology from Tobacco Use (Smoking Status) to Tobacco Use
  • Added Interoperability Need: Sending a Notification of a Patient’s Encounter to a Record Locator Service to Content/Structure: Admission, Discharge, and Transfer
  • Changed Content/Structure: Care Coordination for Referrals Interoperability Needs:
    • “Referral to a Specialist – Request, Status Updates, Outcomes” changed to “Referral to a Specialist – Request, Status Updates, Outcome”
    • “Referral to Extra-Clinical Services – Request, Status Updates, Outcomes” changed to “Referral to Extra-Clinical Services – Request, Updates, Outcome”
  • Added Content Structure: Clinical Notes with Interoperability Need: Documentation of Clinical Notes
  • Changed Content/Structure: Clinical Quality Measurement and Reporting Interoperability Need from “Reporting Aggregate Quality Data to Quality Reporting Initiatives” to “Reporting Aggregate Quality Data for Quality Reporting Initiatives”
  • Corrected typo in Content/Structure: Healthy Weight Interoperability Need from “Sending Health Weight Information” to "Sending Healthy Weight Information”
  • Changed Content/Structure: Laboratory Interoperability Need from “Support the Transmission of a Laboratory’s Directory of Services to Health IT” to "Support the Transmission of a Laboratory’s Directory of Services to Provider’s Health IT or EHR System”
  • Changed Services/Exchange: Patient Identification Management Interoperability Need from “Exchanging Patient Identification Management Within a Community” to “Exchanging Patient Identification Within and Between Communities"
  • Added Interoperability Needs to Administrative: Operating Rules to Support Administrative Transactions:
    • Operating Rules for Premium Payments
    • Operating Rules for Claims
    • Eligibility and Benefits Operating Rules for Standard Transactions
  • Revised Interoperability Needs in Administrative: Operating Rules to Support Administrative Transactions:
    • Changed “Operating Rules for Claims, Enrollment, and Premium Payments (Phase IV)” to “Operating Rules for Benefit Enrollment”
    • Changed “Operating Rules for Prior Authorization (Phase V)” to “Operating Rules for Prior Authorization and Referrals”
    • Changed “Operating Rules to Support Eligibility and Claim Status Transactions (Phase II)” to “Operating Rules to Support Claim Status Transactions”
    • Changed “Operating Rules for Electronic Funds Transfer (EFT) and Electronic Remittance Advice (ERA) for Payments and Reconciliation (Phase III)” to “Operating Rules for Electronic Funds Transfer (EFT) and Electronic Remittance Advice (ERA) for Payments and Reconciliation"
  • Removed Interoperability Need: “Operating Rules to Support Eligibility Transactions (Phase I)” from Administrative: Operating Rules to Support Administrative Transactions
  • Added a Specialty Care/Settings page for COVID-19 related interoperability needs. 
• April 13, 2020 - Rolled out improved site navigation for enhanced user experience. Dropped Section "numbers" (i.e., Section I, Section II, Section III, Section IV, etc) and instead use type of standards as Section title.
• March 24, 2020 - Added Interoperability for COVID-19 Novel Coronavirus Pandemic
• Fall 2019 – numerous changes made to address public comments received and prepare the 2020 Reference Edition, including:
  • Added Section I: Clinical Notes and Interoperability Need: Representing Clinical Notes
  • Added Section I: Cognitive Status and Interoperability Need: Representing Patient Cognitive Status
  • Added Section I: Demographics and Interoperability Need: Representing Patient Contact Information for Telecommunications
  • Added Section I: Dietary and Nutritional Needs and Interoperability Need: Representing Nutrition Assessment, Diagnosis, Interventions and Monitoring/Evaluation
  • Changed Section I: Encounter Diagnosis to Encounter Diagnosis, Assessment and Plan and added Interoperability Need: Representing Assessment and Plan of Treatment
  • Added Section I: Goals and Interoperability Need: Representing Patient Goals
  • Added Interoperability Need: Representing Laboratory Values/Results to Section I: Laboratory
  • Added Section I: Provenance and Interoperability Need: Representing Data Provenance
  • Added four new Interoperability Needs to Section I: Social, Psychological and Behavioral Data:
    • Representing Drug Use
    • Representing Food Insecurity
    • Representing Housing Insecurity
    • Representing Transportation Insecurity
  • Added Section II: Care Coordination for Referrals and three new Interoperability Needs:
    • Referral from Acute Care to Skilled Nursing Facility
    • Referral to a Specialist – Request, Status Updates, Outcome
    • Referral to Extra-Clinical Services – Request, Updates, Outcome  
  • Added Interoperability Need: Documenting Care Plans for Person Centered Services to Section II: Care Plan
  • Added Interoperability Need: Allows a Prescriber to Send a Prescription to a Pharmacy for a Controlled Substance to Section II: Electronic Prescribing.
  • Added Interoperability Need: Collection and Exchange of Patient Reported Outcomes to Section III: Consumer Access/Exchange of Health Information.
  • Added Interoperability Need: Administrative Transaction Acknowledgements to Section IV: Administrative Transactions – Non-Claims
  • Added Interoperability Need: Operating Rules for Prior Authorization (Phase V) to Section IV: Operating Rules to Support Administrative Transactions
• April 4, 2019 - Added two new Interoperability Needs in Section I: Tobacco Use:
  • Representing Patient Electronic Cigarette Use (Vaping)
  • Representing Patient Second Hand Tobacco Smoke Exposure
• February 18, 2019 - Added several Interoperability Needs in Section II: Electronic Prescribing:
  • Allows for Communication of Information Between Prescribers and Dispensers
  • Allows a Prescriber to Communicate with a REMS Administrator
  • Allows a Prescriber to Recertify the Continued Administration of a Medication Order
  • Allows for the Exchange of State Prescription Drug Monitoring Program (PDMP) Data
  • Allows a Prescriber to Communicate Drug Administration Events
  • Allows a Long Term or Post-Acute Care to Request to Send an Additional Supply of Medication
• February 11, 2019 - A section dedicated to ONC Standards has been added, including the API Resource Collection in Health (ARCH) and the U.S. Core Data for Interoperability (USCDI). In addition, new functionality is now available that supports "Specialty Care and Settings" to display a list of interoperability needs supporting particular care needs or settings, including Pediatrics and Opioids (prevention and treatment). 
• January 11, 2019 - A new Interoperability Need: Allows a Prescriber to Send a Prescription to a Pharmacy for a Controlled Substance has been added to Section II: Electronic Prescribing. 
• January 9, 2019 - A new Appendix IV has been added, providing links to State and Local Public Health Agencies and their interoperability efforts. 
• Fall 2018 - numerous changes made to address public comments received and prepare the 2019 Reference Edition ISA, including: 
  • Added Interoperability Needs for:
    • Representing Relationship Between Patient and Another Person
    • Allows a Pharmacy to Request a New Prescription For a New Course of Therapy or to Continue Therapy
    • Allows a Pharmacy to Request, Respond to, or Confirm a Prescription Transfer
    • Allows a Pharmacy to Request Additional Refills
    • Allows a Prescriber to Prescribe Medication Using Weight-Based Dosing
    • Operating Rules for Claims, Enrollment, and Premium Payments (Phase IV)
    • Operating Rules to Support Electronic Prescribing Transactions
  • Changed Health Care Providers to Health Care Providers, Family Members and Caregivers, reflecting additional interoperability needs and a more inclusive sub-section title
  • Changed Section I – Lab Tests to Laboratory to align with other ISA sections
  • Relocated Unique Device Identification Interoperability Needs to Section II for better representation of underlying standards (content/structure)
  • Changed Drug/Formulary Benefits Interoperability Need to “Allows Pharmacy Benefit Payers to Communicate Formulary and Benefit Information to Prescriber Systems
  • Revision of multiple Electronic Prescribing Interoperability Need titles from “A prescriber’s ability to..” to “Allows a prescriber to..”
  • Revision of Patient Education Materials Interoperability Need title.
  • Revision of various Research Interoperability Need titles
  • Changed “Document level segmentation” to "Data segmentation" in Segmentation of Sensitive Information section
• March 6, 2018 - Changed menus and table of contents to reflect move from "lettered" sub-section format to alphabetized sub-section titles. Further work ISA-wide continues to ensure individual pages are updated to the same format. 
• December 2017 - numerous changes made to address public comments received and prepare the 2018 Reference Edition ISA, including:
  • Revision of ISA Introduction language.
  • Change of Section I-S title from Social Determinants to "Social, Psychological, and Behavioral Data".  
  • Addition of two new interoperability needs in Section II-B: Care Plan, including "Documenting and Sharing Medication-Related Care Plans by Pharmacists" and "Sharing Patient Care Teams for Care Planning in Multiple Clinical Contexts".
  • Consolidation of previous Sections II-D and II-E into a single Section II-D: Clinical Quality Measurement and Reporting.
  • Addition of three interoperability needs to Section II-H: Electronic Prescribing, including Allows Prescriber to Respond to a Prior Authorization for a Medication Electronically to the Payer/Processor", "Prior Authorization Cancel Request", and "A Prescriber’s Ability to Obtain a Patient’s Medication History from a Prescription Drug Monitoring Program". 
  • Addition of an interoperability need in Section II-K: Images, "Format of Radiation Exposure Dose Reports for Exchange and Distribution".
  • In Section II-O: Patient Identification Management, a change to the title of the interoperability need to "Patient Demographic Record Matching".
  • In Section II-Q: Public Health Reporting, addition of four new interoperability needs, including "Data Submission for Title X Family Planning Annual Reporting", "Reporting Death Records to Public Health Agencies", "Reporting Newborn Screening Results to Public Health Agencies", "Reporting Birth and Fetal Death to Public Health Agencies" and a revision to one interoperability need's title "Exchanging Immunization Data with Immunization Registries" to better reflect the interoperability need. 
  • Addition of a new Section V-F: CMS Interoperability Standards for Provider to Provider Communication with three interoperability needs related to CMS' Electronic Medical Documentation Interoperability work. 
  • Numerous updates within individual interoperability needs from public comments. 
• October 25, 2017 - A new subsection (I-W: Pregnancy Status) and associated interoperability need, Representing Patient Pregnancy Status, has been added to the ISA to reflect Federal Advisory Committee recommendations. 
• September 18, 2017 - New Questions and Requests for Stakeholder Feedback have been added as part of the Fall 2017 comment and review period. 
• September 18, 2017 - A new sub-section related to Consumer Access/Exchange of Health Information has been added, with four initial interoperability needs. This was recommended by the 2017 ISA Task Force and the Health IT Standards Committee.
• September 15, 2017 - Advanced Search functionality has been added, allowing users to find content based on standards/implementation specifications, informative characteristics, etc. Please note: we are aware of some minor issues with this functionality and are working to resolve these as quickly as possible. 
• August 16, 2017 - A new Section V has been created that includes standards for administrative transactions.
• April 19, 2017 - A new interoperability need, Reporting Birth Defects to Public Health Agencies, has been added to Section II-R: Public Health Reporting.
• April 3, 2017 - A new appendix has been added, with informational and educational resources as recommended by the Health IT Standards Committee.

ONC has established the voluntary Standards Version Advancement Process (SVAP)¹ to enable health IT developers’ ability to incorporate newer versions of Secretary-adopted standards and implementation specifications, as part of the “Real World Testing” Condition and Maintenance of Certification requirement (§ 170.405) of the 21st Century Cures Act.  

Using SVAP, certified health IT developers are permitted to voluntarily use a more advanced version of the standard(s) and implementation specification(s) approved by the National Coordinator than is adopted in the ONC 2015 Edition Certification Criteria. Currently, this flexibility is limited to standards and implementation specifications that are adopted in the certification criteria required to meet “Real World Testing” condition of certification, which include § 170.315(b), (c)(1) through (c)(3), (e)(1), (f), (g)(7) through (g)(10), and (h).

Health IT developers taking advantage of the SVAP flexibility must ensure that their real-world testing plans and results of the certified health modules use these updated standards and implementation specifications. Additionally, certified health IT developers are required to provide advance notice to their clients and their ONC-Authorized Certification Body (ONC-ACB) before adopting the new standards.

Working with industry stakeholders and providing ample notice, ONC will follow a collaborative process to identify a more advanced version of the standards or implementation specifications, for approval by the National Coordinator. 

The table below lists the standards and implementation specifications (and their versions) that will be considered for advancement and those that have received National Coordinator approval via the Standards Version Advancement Process. It does not include any minimum vocabulary standards as health IT can continue to be certified or upgraded to newer version(s) of identified minimum standard code sets, unless newer version(s) are explicitly prohibited by the Secretary. The table can be sorted by either "Current Standard/Implementation Specification" or "Regulatory Text Citation" by clicking on the column name.

The table below will be updated throughout the year to include standards with newer versions under consideration for the current SVAP cycle. However, if there is a newer version of a standard and it’s not listed below it can still be considered for inclusion in the current SVAP cycle. As with previous SVAP cycles, future public comment periods will align with important standards development activities, such as the yearly release of new United States Core Data for Interoperability (USCDI) versions and HL7® standards related to C-CDA® and FHIR® US Core, thereby establishing a consistent cadence of SVAP comment periods and releases. The yearly SVAP comment cycle is open from January to May with a final release of SVAP approved standards for each year to occur in June. The public comment period for SVAP 2024 ran from January 16 through May 21. 

The SVAP Approved Standards for 2024 are now published. For the latest information on the approved standards for use, see the ONC Health IT Certification Program SVAP page.