The ISA is organized and structured into four 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 – Administrative Standards and Implementation Specifications (i.e., payment, operations and other "non-clinical" interoperability needs)
- 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 III 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, Section I: 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: 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 |
| Limitations, Dependencies, and Preconditions for Consideration: |
Section I: Applicable Value Set(s) and Starter Set(s):
Other Sections: Applicable Security Patterns for Consideration:
|
|---|
- In the case where there is a need to reflect a conformance statement, the verbs “must” and “shall” will reflect an absolute requirement and the verbs “can” and “may” reflect optionality.
- Where standards listed for an interoperability need have active projects listed on ONC’s Interoperability Proving Ground, a link to that standard will be provided in this section. Please note, all projects for the standard will be listed, including those that may be demonstrating use of the standard for different interoperability needs.
|
|
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.”
Submitted by mattreid on 2020-03-26
The AMA requests that the…
The AMA requests that the Current Procedural Terminology (CPT) code set be added to the standards listed in Section I: Representing Patient Allergic Reactions. The Allergy and Clinical Immunology CPT codes (95004 – 95199) identify patient assessment and intervention for allergy testing, ingestion challenge testing, and allergen immunotherapy. CPT is a comprehensive and regularly curated uniform language that accurately describes medical, surgical, and diagnostic services and provides for reliable communication among users. It has an extremely robust and mature development process with open and transparent meetings and clinical input from national medical specialties and relevant stakeholders. It is the most widely adopted outpatient procedure code set. Use of the CPT code set is federally required under HIPAA.