Introduction to the 2025 Interoperability Standards Advisory Reference Edition

The Interoperability Standards Advisory (ISA) process represents the model by which the Assistant Secretary for Technology Policy (ASTP) coordinates 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, research and administrative purposes. ASTP 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, ASTP encourages further pilot testing and industry experience to be sought with respect to standards and implementation specifications identified as “emerging” in the ISA.


The 2025 ISA Reference Edition reflects the numerous changes made across the ISA throughout 2024. To learn more about what has changed, refer to the Recent ISA Updates page, which provides a summary of major changes to the ISA. 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. Anyone may become a registered user, by creating an account. 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, capturing more granular changes to individual pages across the ISA, is also available.


For additional information about the ISA, including scope, purpose, structure, an overview of the informative characteristics attributed to each standard/implementation specification, frequently asked questions, and the annual timeline and comment process, please see pages under the site’s About the ISA section.


Vocabulary/Code Set/Terminology

Allergies and Intolerances

Interoperability Need: Representing Patient Allergic Reactions

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observation values
Final
Production
Rating 4
Yes
Free
N/A
Standard for observations
Final
Production
Rating 3
No
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • SNOMED CT U.S. Edition may not be sufficient to differentiate between an allergy or adverse reaction, or the level of severity.
  • For use of SNOMED CT U.S. Edition, codes should generally be chosen from the clinical finding axis.
  • For more information about observations and observation values, see Appendix III for an informational resource developed by the Health IT Standards Committee. 

 

 

Interoperability Need: Representing Patient Allergies and Intolerances; Environmental Substances

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 3
No
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • The starter value set Common Environmental Substances for Allergy and Intolerance documentation (2.16.840.1.113762.1.4.1186.4) provides a limited set of SNOMED CT codes for substances commonly associated with allergic reactions, but it is not exhaustive. Many other substances with codes in the SNOMED CT Substance hierarchy may be associated with allergic reactions.
  • The Allergic disposition (disorder) hierarchy provides an alternative representation for allergies that can be used on a problem list, medical history, or encounter diagnosis.

 

Interoperability Need: Representing Patient Allergies and Intolerances; Food Substances

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 4
No
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • The starter value set Common dietary substances for allergy and intolerance documentation (2.16.840.1.113762.1.4.1186.3) provides a limited set of SNOMED CT codes for substances commonly associated with allergic reactions, but is not exhaustive. Many other substances with codes in the SNOMED CT Substance hierarchy may be associated with allergic reactions.
  • The Propensity to adverse reactions to food (disorder) hierarchy provides an alternative representation for allergies that can be used on a problem list, medical history, or encounter diagnosis.

 

Interoperability Need: Representing Patient Allergies and Intolerances; Medications

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 4
Yes
Free
N/A
Standard
Final
Production
Rating 3
Yes
Free
N/A
Standard
Final
Production
Feedback Requested
No
Free
Emerging Standard
Final
Production
Feedback Requested
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • SNOMED CT U.S. Edition should be used to represent an allergy or intolerance at the medication class level.
  • MED-RT is managed by the US Veterans Health Administration and may be used to represent an allergy or intolerance at the medical class level. 

     

Representing Medication:

Representing Drug Classes for Allergy and Intolerance documentation:

Representing Adverse Reactions/Intolerances:

 

Biologics

Interoperability Need: Representing Biological Products

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • ISBT 128 is the global standard for the terminology, identification, coding and labeling of medical products of human origin (including blood, cell, tissue, milk, and organ products).

  • Feedback requested.

 

Clinical Notes

Interoperability Need: Representing Clinical Notes

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Production
Rating 5
Yes
Free
N/A
Standard for observations
Final
Production
Feedback Requested
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)

LOINC:

  • A Consultation note is generated as part of a request from a clinician for an opinion or advice from another clinician.

  • A Discharge Summary note is a synopsis of a patient’s admission and course in a hospital or post-acute care setting.

  • A History & Physical note documents the current and past conditions of the patient.

  • A Progress Note represents a patient's interval status during a hospitalization, outpatient visit, treatment with a LTPAC provider, or other healthcare encounter.

IHE:

LOINC:

IHE:

 

 

Clinical Tests

Interoperability Need: Representing Clinical Tests Ordered/Performed

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Feedback Requested
No
Free
Standard
Final
Production
Feedback Requested
No
$
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • Clinical Tests is a USCDI data class representing non-imaging and non-laboratory tests performed on a patient that results in structured or unstructured (narrative) findings specific to the patient, such as electrocardiogram (ECG), visual acuity exam, macular exam, or graded exercise testing (GXT), to facilitate the diagnosis and management of conditions.

 

Interoperability Need: Representing Clinical Tests Result/Value

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observation values
Final
Production
Rating 3
Yes
Free
N/A
Standard for observation values
Final
Production
Rating 1
Yes
Free
N/A
Standard for observation values
Final
Production
Rating 1
Yes
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • Feedback requested.
  • Feedback requested.

 

Cognitive Status

Interoperability Need: Representing Patient Cognitive Status

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Production
Rating 2
No
Free
N/A
Emerging Implementation Specification
In Development
Feedback requested
Feedback Requested
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • The PACIO Project is developing FHIR use cases for the exchange of functional status and cognitive status information between healthcare settings.
  •  The CMS Data Element Library provides the ability to download assessment data elements, including functional status, and associated health IT standards from the:
    • Inpatient Rehabilitation Facility Patient Assessment Instrument (IRF-PAI)
    • Long-Term Care Hospital Continuity Assessment Record Set (LCDS)
    • Resident Assessment Instrument - Minimum Data Set (MDS)
    • Outcome and Assessment Information Set (OASIS)
    • Hospice Item Set (HIS) 
  • The following Cognitive Status data elements and their associated LOINC codes were published in the Data Element Library (DEL) in June 2018:
    • Brief interview for mental status (BIMS) 52491-8
    • Confusion Assessment Method (CAM) 52495-9 
    • Montreal Cognitive Assessment (MoCA) 72133-2
    • Mini-Mental State Examination (MMSE) 72107-6

 

COVID-19 Novel Coronavirus Pandemic

Interoperability Need: COVID-19 Novel Coronavirus Pandemic

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
Yes
Free
N/A
Standard
Final
Production
Rating 5
Yes
Free
N/A
Standard
Final
Production
Rating 5
Yes
Free
N/A
Standard
Final
Production
Rating 5
Yes
$
N/A
Standard
Final
Production
Rating 5
Yes
Free
N/A
Standard
Final
Production
Rating 5
Yes
Free
N/A
Standard
Final
Production
Rating 5
Yes
Free
N/A
Implementation Specification
Final
Production
Rating 5
No
Free
Yes
Standard
Final
Production
Rating 4
No
Free
N/A
Standard
Final
Production
Feedback Requested
No
Free
N/A
Implementation Specification
Final
Feedback requested
Feedback Requested
No
Free
N/A
Emerging Implementation Specification
In Development
Feedback requested
Feedback Requested
No
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)

 

Demographics

Interoperability Need: Representing Patient Contact Information for Telecommunications

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 4
Yes
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)

Examples from ITU–T E.123 (02/2001)

Multiple phone numbers:

  • Tel. (0607) 123 4567
  • Fax (0607) 123 4568
  • Mobile (0607) 321 9876

Phone numbers and email:

  • Telephone: (0609) 123 4567
  • International +22 609 123 4567
  • Mobile (0607) 321 9876
  • E-mail: jdeo@isp.com

 

Dietary and Nutritional Needs

Interoperability Need: Representing Nutrition Assessment, Diagnosis, Interventions and Monitoring/Evaluation

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
No
$
No
Standard
Final
Production
Rating 3
No
Free
N/A
Standard
Final
Production
Rating 3
No
$
N/A
Standard
Final
Production
Feedback Requested
No
Free
N/A
Standard
Balloted Draft
Production
Feedback Requested
No
Free
Yes
Standard
Balloted Draft
Production
Feedback Requested
No
Free
Yes

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • Nutrition Care Process Terminology (NCPT) and is owned, maintained, and distributed by the Academy of Nutrition and Dietetics to support standardization of the Nutrition Care Process. Many of the terms in the NCPT have been mapped to SNOMED and/or LOINC.
  • Refer to the Gravity Project for details on identifying food insecurities.

 

 

Emergency Medical Services

Interoperability Need: Representing Health Care Data for Emergency Medical Services

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 4
Yes
Free
N/A
Standard
Final
Production
Rating 3
Yes
Free
N/A
Standard
Final
Production
Rating 5
No
Free
Yes
Standard
Final
Production
Rating 4
No
Free
Yes
Standard
Final
Production
Feedback Requested
No
$
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • The National Emergency Medical Services Information System (NEMSIS) administered by the National Highway Traffic Safety Administration’s Office of Emergency Medical Services provides a universal standard for the collection and transmission of emergency medical services (EMS) operations and patient care data. Using NEMSIS-compliant electronic patient care record (ePCR) software products, data are collected by EMS practitioners at the point of care and includes information on the EMS system response, scene characteristics, patient demographics, patient condition, medical treatment provided, transport decision, patient and incident disposition and EMS system times (e.g., response time, scene time, transport time).  NEMSIS includes the National EMS Database which accepts EMS data voluntarily submitted by U.S. States and Territories. Using NEMSIS-compliant ePCR software products, local EMS systems collect a national set of data elements for submission to the National EMS Database through their respective state. Local EMS systems and states have the option to collect additional NEMSIS data elements to meet local and state needs. The NEMSIS standard follows a 5-year revisioning cycle.  The two most recent NEMSIS standard versions (V3.4.0 and 3.5.0 as of January 2021) are available for ePCR software product compliance testing and submission to the National EMS Database.  NEMSIS standard version 3.5.0 was released in 2019.  NEMSIS Version 3 standards (i.e., V3.4.0, and V3.5.0) include integration of several HL7® data standards, such as LOINC®, RxNorm, and ICD-10-CM.  NEMSIS standard versions V3.4.0 and V3.5.0 are HL7 compliant and ANSI accredited.
  • NEMSIS uses Extensible Markup Language (XML) to move data. States and software companies create products that are used to send and receive EMS data in the proper XML format from agencies to states, then on to the National EMS Database. More information about NEMSIS is available at https://nemsis.org/technical-resources/.
  • Mapping and translation resources are available for mapping or translating older versions of the NEMSIS dataset to newer versions of the dataset.
  • CPT 99281 - 99285: patient evaluation, examination, and medical decision making for emergency department services
  • CPT 99288: direction of emergency care to EMS personnel by a physician or other qualified health care professional

 

Encounter Diagnosis, Assessment and Plan

Interoperability Need: Representing Assessment and Plan of Treatment

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Production
Feedback Requested
No
Free
N/A
Standard for observation values
Final
Production
Feedback Requested
No
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • Feedback requested.
  • Feedback requested.

 

Interoperability Need: Representing Patient Dental Encounter Diagnosis

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 4
No
$
N/A
Standard
Final
Production
Rating 4
No
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • SNODENT is owned, maintained and distributed by the American Dental Association (ADA®). The SNODENT code set is available under license at no cost for non-commercial use. The license agreement terms also permit licensees to use SNODENT in the development of non-commercial, academic, scholarly articles and presentations for publication.

 

Interoperability Need: Representing Patient Medical Encounter Diagnosis

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 4
Yes
Free
N/A
Standard
Final
Production
Rating 4
Yes
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • Use of SNOMED CT U.S. Edition codes should generally be chosen from three axes: Clinical finding, Situation with explicit context, and Event.
  • The use of these standards may be further constrained by other standards and implementation specifications found elsewhere in the ISA.
  • Systems should be able to process (or at minimum display) data coded using the older ICD-9-CM standard, as this legacy content still exists and may be used for analysis/decision support/quality measurement needs, where retroactive analysis is often required, but ICD-9 should not be collected for new entries. NLM has maps from ICD-9-CM diagnosis and procedure codes to SNOMED CT U.S. Edition to facilitate code translation and integration with newly collected SNOMED CT U.S. Edition data:
  • A mapping from SNOMED CT U.S. Edition to ICD-10-CM is available from the National Library of Medicine to support semi-automated generation of ICD-10-CM codes from clinical data encoded in SNOMED CT U.S. Edition for reimbursement and statistical purposes.
  • HIPAA mandates the use of ICD-10 for pharmacy claims using NCPDP® standards, while SNOMED CT U.S. Edition is optional for this use. 
  • Problem urn:oid:2.16.840.1.113883.3.88.12.3221.7.4 (SNOMED CT U.S. Edition)
  • Recommended starter set: CORE Problem List Subset urn:oid: 2.16.840.1.113762.1.4.1018.240

 

Family Health History

Interoperability Need: Representing Patient Family Health History

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 3
Yes
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)

Diagnosis and Conditions:

  • Problem Type: 2.16.840.1.113883.3.88.12.3221.7.2 (SNOMED CT U.S. Edition)
  • Problem: 2.16.840.1.113883.3.88.12.3221.7.4 (SNOMED CT U.S. Edition)

For genomic data:

For family relationships and roles:

 

Functional Status/Disability

Interoperability Need: Representing Patient Functional Status and/or Disability

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Production
Rating 2
No
Free
N/A
Standard for observation values
Final
Production
Rating 1
No
Free
N/A
Emerging Implementation Specification
In Development
Feedback requested
Feedback Requested
No
Free

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • Functional Status data elements were developed by CMS and are integrated in CMS PAC assessments and CMS’ Home and Community Based Services (HCBS) Functional Assessment Standardized Items (FASI). Value sets on functional status were published by Regenstrief in version 2.63 and continue to be updated in recent versions as needed, including the most recent release v2.72. Functional Status data elements and their associated LOINCs were published in the DEL in 2018.

 

 

 

Goals

Interoperability Need: Representing Patient Goals

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Production
Rating 1
No
Free
N/A
Standard for observation values
Final
Production
Rating 1
No
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • The CMS Data Element Library also provides the ability to download assessment data elements, including various assessments of patient goals, and associated health IT standards such as LOINC and SNOMED CT U.S. Edition from the:
    • Inpatient Rehabilitation Facility Patient Assessment Instrument (IRF-PAI)
    • Long-Term Care Hospital Continuity Assessment Record and Evaluation Data Set (LCDS)
    • Resident Assessment Instrument - Minimum Data Set (MDS)
    • Outcome and Assessment Information Set (OASIS)
    • Functional Assessment Standardized Items (FASI) 

 

Health Care Providers, Family Members and Other Caregivers

Interoperability Need: Representing Health Care Providers

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
Yes
Free
N/A
Standard
Final
Production
Rating 3
No
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • NPPES permits non-billable care team members to apply for an NPI number to capture the concept of ‘person’.
  • The National Uniform Claim Committee (NUCC) Health Care Provider Taxonomy code set identifies health care provider groupings, classifications, and areas of specialization. It does include other providers than health care providers, which is defined by federal regulations.
  • The adoption of NPI for pharmacy/prescribing may be higher than for general use, however, not all prescribers (e.g., veterinarians, etc) are able to obtain an NPI. 

 

Interoperability Need: Representing Provider Role in Team Care Settings

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 3
No
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • Feedback requested.

 

Interoperability Need: Representing Relationship Between Patient and Another Person

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 2
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • This value set is derived from the HL7 Vocabulary code system "RoleCode".

 

Health Concerns

Interoperability Need: Representing Patient Health Concerns

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Production
Rating 1
No
Free
N/A
Standard for observation values
Final
Production
Rating 1
No
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • A Health Concern is a health-related matter that is of interest, importance or worry to someone, who may be the patient, patient's family, or patient's health care provider. Health concerns are derived from a variety of sources within an EHR (such as Problem List, Family History, Social History, Social Worker Note, etc.). Health concerns can be medical, surgical, nursing, allied health or patient-reported concerns.

 

Imaging (Diagnostics, Interventions and Procedures)

Interoperability Need: Representing Imaging Diagnostics, Interventions, and Procedures

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
Yes
Free
N/A
Standard
Final
Production
Rating 5
Yes
$
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)

LOINC:

  • An Imaging Narrative contains a consulting specialist's interpretation of image data.

 

Immunizations

Interoperability Need: Representing Immunizations

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
Yes
Free
N/A
Standard
Final
Production
Rating 5
Yes
Free
N/A
Standard
Final
Production
Rating 4
No
Free
N/A
Standard
Final
Production
Rating 4
No
$
No
Standard
Final
Production
Rating 3
No
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)

General considerations:

  • The list above includes any vocabulary used to record immunizations in any health IT system including IIS, pharmacy, billing, etc. 
  • NDC has been used by pharmacies to report historical doses for billing purposes, so it is included here in that context.  
  • The CDC's National Center for Immunization and Respiratory Diseases (NCIRD) developed and maintains the CVX and MVX code systems, and developed and maintains the NDC vaccine tables based on information published by the FDA.
  • RxNorm is an acceptable alternative code set for use at the local level.
  • RxNorm is utilized for immunization analytics.
  • RxNorm is not utilized for reporting of previous dispensing but can be employed to specify the drug being prescribed. 

For Immunization Information System (IIS) consideration:

  • The CDC's National Center for Immunization and Respiratory Diseases (NCIRD) developed and maintains the CVX and MVX code systems, and developed and maintains the NDC vaccine tables based on information published by the FDA.
  • CVX codes are designed to represent administered and historical immunizations and will not contain manufacturer-specific information.
  • If an MVX code is paired with a CVX (vaccine administered) code, the specific trade named vaccine may be indicated providing further specificity as to the vaccines administered.
  • There is a potential issue with use of the National Drug Code regarding which code to use when there are multiple active ingredients in a single package or multiple separate ingredients that need to be mixed together. CDC has published guidance on NDC Unit of Use and Unit of Sale; it can be found at: https://www.cdc.gov/vaccines/programs/iis/2d-barcodes/downloads/guidance-documenting-ndc.pdf.
  • The lot number is used in conjunction with the NDC when reporting immunizations to IIS. There is no standard codification for lot numbers.
  • The IIS community does not utilize RxNorm as a code set and thus it may have limitations for interoperability across systems.

 

Laboratory

Interoperability Need: Representing Laboratory Result Values

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Feedback Requested
No
Free
N/A
Standard
Final
Production
Feedback Requested
No
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • Correct handling and interpretation of laboratory test values requires information about the test instance, including the result value, the units, the reference range. 
  • Units of measure for quantitative result values may be represented using UCUM, see Representing Units of Measure
  • Qualitative result values may be represented using LOINC answer lists or SNOMED CT U.S. Edition codes.
  • Future uses of laboratory test results may include “real world evidence” collection for final regulatory approval, test harmonization status, and performance monitoring of specific commercial products. These tasks will require results to include device IDs, test kit IDs, kit versions, reagent lots, and calibrator lots. 

 

 

 

Interoperability Need: Representing Laboratory Test Ordered

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 2
Yes
Free
N/A
Standard
Final
Production
Rating 1
No
$

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • LOINC codes identify the clinical concept of the test ordered, which enables consistent interpretation across systems and organizations regardless of a laboratory’s local codes. The LOINC code to represent the order may not be the same LOINC code as the one for the performed test when the performed test code is more specific in one of the LOINC parts (e.g., method or system) or when the order combines multiple tests into a panel.
  • CPT-PLA codes represent advanced diagnostic laboratory tests (ADLTs) and clinical diagnostic laboratory tests (CDLTs) that are cleared and approved by the Food and Drug Administration (FDA). CPT-PLA codes provide relevant clinical information about the test ordered, including information on analytical services required for the analysis (e.g., cell lysis, nucleic acid stabilization, extraction, digestion, amplification, hybridization, and detection).
  • LOINC Code Rankings for Top 20,000 Codes  In the context of Laboratory Test Ordered, where the Order/Observation attribute is not equal to obs only.
  • CPT:
    • CPT Proprietary Laboratory Analyses (PLA) Codes PLA codes are published are available on the AMA website to represent laboratory tests.
    • 80047 - 89398 - including Multianalyte Assays with Algorithmic Analyses (MAAA) codes 81490-81599.
    • MAAA administrative M Codes (0002M-0013M).

 

Interoperability Need: Representing Laboratory Test Performed

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Feedback Requested
Yes
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • Laboratory test performed is used by a laboratory to report test results.
  • LOINC codes represent laboratory tests in general and do not represent a manufacturer's specific laboratory test. 
  • For more information about representing laboratory tests as a procedure, see the Representing Medical Procedures page. 
  • For more information about observations and observation values, see Appendix III for an informational resource developed by the Health IT Standards Committee. 

 

Interoperability Need: Representing Laboratory Test Specimen

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 2
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • Feedback requested.
  • Specimen Type: SNOMED CT U.S. Edition specimen hierarchy
  • Specimen Source Type: SNOMED CT U.S. Edition body structure hierarchy
  • Specimen Source Site Modifier: SNOMED CT U.S. Edition qualifier hierarchy
  • Specimen Collection Method: SNOMED CT U.S. Edition procedure hierarchy 

 

Medications

Interoperability Need: Representing Patient Medications

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
Yes
Free
N/A
Standard
Final
Production
Rating 5
Yes
Free
N/A
Standard
Final
Production
Rating 5
No
Free
Yes

 

Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • RxNorm is often used for the exchange of information; however, it may not be available for export and import by end users.
  • RxNorm is a terminology built on and derived from other terminologies which represent various elements within RxNorm, including dose form and units of measure. RxNorm reflects and preserves the meanings, drug names, attributes, and relationships from its sources.  
  • The use of NDC in conjunction with RxNorm can help minimize gaps in representing medications, including compounded products, over -the-counter medications, and herbals.
  • Note: All over-the-counter, botanicals, and herbal supplements also need to be considered in the management of medications and the conditions for which they are used. Not all of these are well-represented using the standards indicated above.
  • Immunizations are not considered medications for this interoperability need.
  • Medication Route and other components of Medication is often represented using SNOMED CT, US Edition in some interoperability specifications such as C-CDA.
  • Grouping Value Set: Medication Clinical Drug 2.16.840.1.113762.1.4.1010.4
    • Medication Clinical General Drug (2.16.840.1.113883.3.88.12.80.17)
    • Medication Clinical Brand-specific Drug (2.16.840.1.113762.1.4.1010.5) (RxNorm).
  • Grouping Value Set: Clinical Substance 2.16.840.1.113762.1.4.1010.2
    • Medication Clinical Drug (2.16.840.1.113762.1.4.1010.4) (RxNorm )
    • Unique Ingredient Identifier - Complete Set (2.16.840.1.113883.3.88.12.80.20) (UNII)

 

Nursing

Interoperability Need: Representing Clinical/Nursing Assessments

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Production
Rating 2
No
Free
N/A
Standard for observation values
Final
Production
Rating 2
No
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • Concepts for observation values from SNOMED CT U.S. Edition should generally be chosen from two axes: Clinical finding and Situation with explicit context.
  • When representing validated scales, LOINC should be used for the question and LOINC answers (LA Codes) should be used for the answers.
  • Question/Answer (name/value) pairs are a valuable representation of assessments, but best practices indicate the full question with answer should be included in communication. 
  • For more information about observations and observation values, see Appendix III for an informational resource developed by the Health IT Standards Committee. 

 

Interoperability Need: Representing Nursing Interventions

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Feedback Requested
No
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • According to the Journal of Nursing Education  nursing interventions can be defined as "any task that a nurse does to or for the patient" or "something that directly leads to a patient outcome."
  • Coded interventions may be linked as related/dependent concepts to observations and assessments, as appropriate.
  • The Procedure axis of SNOMED CT U.S. Edition is the terminology used for Nursing Interventions.

 

Interoperability Need: Representing Outcomes for Nursing

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Production
Feedback Requested
No
Free
N/A
Standard for observation values
Final
Production
Feedback Requested
No
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • Reference to Standard Nursing Terminologies
  • Other ANA-recognized terminologies should be mapped to LOINC for comparison across health systems and/or transmission.
  • Use LOINC if the outcome is a measurement.
  • Use SNOMED CT U.S. Edition if the outcome is an observed assessment that a patient state has improved.  In addition, when the outcome is recorded as an assertion (e.g., normotensive, afebrile, etc.) the terminology to be used is SNOMED CT U.S. Edition. 
  • Additional information about terminology standards related to nursing is available in an ASTP-funded report: Standard  Nursing Terminologies (A Landscape Analysis)
  • For more information about observations and observation values, see Appendix III for an informational resource developed by the Health IT Standards Committee. 
  • Feedback requested.

 

Interoperability Need: Representing Patient Problems for Nursing

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observation values
Final
Production
Feedback Requested
No
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • The use of SNOMED CT U.S. Edition for this interoperability need, codes should generally be chosen from two axes: Clinical finding and Situation with explicit context.
  • Local and other ANA-recognized terminologies should be converted to SNOMED CT U.S. Edition for comparison across health systems and/or transmission.

 

Patient Clinical Problem List (i.e., "Conditions")

Interoperability Need: Representing Patient Clinical Problem List (i.e., "Conditions")

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observation values
Final
Production
Rating 5
Yes
Free
N/A
Standard
Final
Production
Rating 4
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • The use of SNOMED CT U.S. Edition for this interoperability need, codes should generally be chosen from three axes: Clinical finding, Situation with explicit context, and Event.
  • SNOMED CT U.S. Edition supports the combination of codes (post-coordination) to generate new meaning. Codes from other axes can be used in post-coordination. The need to pick multiple codes may be seen as a disadvantage. This can be avoided if post-coordination is limited to the backend, exposing a single code for users to pick.
  • For more information about observations and observation values, see Appendix III for an informational resource developed by the Health IT Standards Committee. 

 

Preferred Language

Interoperability Need: Representing Patient Preferred Language (Presently)

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Feedback Requested
Yes
Free
N/A
Standard
Final
Production
Feedback Requested
No
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • RFC 5646 encompasses ISO 639-1, ISO 639-2, ISO 639-3 and other standards related to identifying preferred language.

 

Pregnancy Status

Interoperability Need: Representing Patient Pregnancy Status

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Production
Rating 1
No
Free
No
Standard for observation values
Final
Production
Rating 1
No
Free
No
Standard
Balloted Draft
Feedback requested
Feedback Requested
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)

 

Procedures

Interoperability Need: Representing Dental Procedures Performed

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 4
No
$
N/A

 

Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • Feedback requested.
  • Feedback requested.

 

Interoperability Need: Representing Medical Procedures Performed

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
Yes
Free
N/A
Standard
Final
Production
Rating 5
Yes
$
N/A
Standard
Final
Production
Rating 5
Yes
Free
N/A
Standard
Final
Production
Rating 4
Yes
Free
N/A
Standard
Final
Production
Feedback Requested
Yes
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • ICD-10-PCS is primarily a billing code used only in inpatient settings.
  • CPT and HCPCS are codes used to report procedures and services in outpatient procedures.
  • ICD-10-PCS is named in the 2015 Edition certification rules as an optional code set for procedures.
  • SNOMED CT U.S. Edition procedure codes can be used to describe treatment in any clinical setting and is not tied to billing but can be cross-mapped to corresponding ICD-10-PCS and CPT/HCPCS codes.

LOINC:

  • A Procedure Note records the indications for a non-operative procedure and, when applicable, post-procedure diagnosis, pertinent events of the procedure, and the patient's tolerance of the procedure.
  • A Pathology Report Narrative contains a consulting specialist's interpretation of the pathology report.

 

 

 

Interoperability Need: Representing Social Care Procedures

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
No
$
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • Feedback requested.
  • Feedback requested.

 

Provenance

Interoperability Need: Representing Data Provenance

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Emerging Implementation Specification
In Development
Production
Rating 2
No
Free
Implementation Specification
Balloted Draft
Feedback requested
Feedback Requested
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • Data Elements:
    • Author Time Stamp-indicates the time the information was recorded
    • Author Organization-the organization the author is associated with at the time they interacted with the data.

 

  • Feedback requested.

 

Public Health Emergency Preparedness and Response

Interoperability Need: Representing Healthcare Personnel Status

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 3
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • The CDC, Center of Emergency Preparedness and Response, Situational Awareness branch, collaborating with the National Information Exchange Model (NIEM), developed -a population-level public health emergency preparedness and response information exchange requirements, which includes a minimum data set, and standardized vocabulary. Data comes directly from hospital and long-term care facility databases, not directly linked to the EHR.
  • The Healthcare personnel status section of the minimum data set provides vocabulary for a population-level reporting healthcare personnel morbidity and mortality during an emergency event.

 

Interoperability Need: Representing Hospital/Facility Beds Utilization

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Emerging Implementation Specification
Balloted Draft
Feedback requested
Feedback Requested
No
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)

Feedback requested

Feedback requested

 

Race, Ethnicity and Tribal Affiliation

Interoperability Need: Representing Patient Race and Ethnicity

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 4
Yes
Free
N/A
Standard
Final
Production
Rating 4
Yes
Free
Yes
Standard
Final
Production
Rating 4
Yes
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • The CDC Developed Code Systems includes Race & Ethnicity Code System – CDCREC 1.2 and Race & Ethnicity Code System – CDCREC 1.0 which expands upon and can be rolled up to the OMB standards may help to further define race and ethnicity for this interoperability need as it allows for multiple races and ethnicities to be chosen for the same patient.
  • The CDC Race and Ethnicity Code Set Version 1.2 is minor update to Version 1.0 and is the current version for CDC reporting requirements.
  • The high-level race/ethnicity categories in the OMB Standard may be suitable for some statistical or epidemiologic or public health reporting purposes but may not be adequate for other uses such as in the pursuit of precision medicine and enhancing therapy or clinical decisions.
  • LOINC® provides observation codes for use in the observation/observation value pattern for communicating race and ethnicity. LOINC is used to capture race and/or ethnicity in multiple coded panels; some of these align with the OMB race and ethnicity Category codes (e.g., 72826-1 69490-1).
  • On March 28, 2024, OMB finalized revisions to Statistical Policy Directive No. 15: Standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity (SPD 15). The 2024 revisions to SPD 15 are effective as of its publication date, and Federal agencies must comply with these updates as soon as possible, and, in any case, no later than March 28, 2029.

 

Interoperability Need: Representing Tribal Affiliation

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Feedback Requested
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • Any patient receiving healthcare in the United States may have some tribal affiliation, including patients from any other country or locale in the world. Some patients are members of a federally recognized tribe, some are members of a state recognized tribe, some are members of tribes in the process of seeking federal or state recognition, and some may self-report an affiliation or enrollment in more than one tribe or community inside or outside the U.S. Only tribes define and determine tribal enrollment. Federal, state, and local entities do not have the ability to verify tribal enrollment. Use of tribal affiliation allows for the collection of what tribe(s) an individual patient identifies with, without impeding on tribal sovereignty in any way.
  • The HL7 TribalEntityUS code system is modeled after the Bureau of Indian Affairs (BIA) list of federally recognized tribes, state recognized tribes, and other entities in Alaska and the contiguous U.S. To aid in identifying Tribal name changes, the Tribe's previously listed, former name, or also known as (aka) is included in parentheses after the correct current Tribal name on the https://www.bia.gov/as-ia/ofa website.
  • The HL7 codesystem for TribalEntityUS is defined as "Indian entities recognized and eligible to receive services from the United States Bureau of Indian Affairs".
  • This Code system is referenced in the content logical definition of the following value sets:

 

Research

Interoperability Need: Representing Data for Biomedical and Health Services Research Purposes

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
Yes
Free
N/A
Standard
Final
Production
Rating 5
Yes
$
N/A
Standard
Final
Production
Rating 3
Yes
Free
N/A
Standard
Final
Production
Rating 1
Yes
Free
N/A
Standard
Final
Production
Rating 3
No
Free
N/A
Standard
Final
Production
Feedback Requested
No
Free
N/A
Standard
Final
Production
Rating 4
No
Free
Yes
Standard
Final
Production
Rating 2
No
Free
N/A
Standard
Final
Production
Rating 3
No
Free
N/A
Standard
Final
Production
Rating 3
No
Free
N/A
Standard
Final
Production
Rating 3
No
Free
N/A
Implementation Specification
Final
Production
Rating 1
No
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • The adoption and federally required levels for using CDISC SDTM for QRS, Medical Devices and Pharmacogenomics purposes vary.
  • Medical Dictionary for Regulatory Activities (MedDRA) is a standardized medical terminology developed by ICH,  to facilitate sharing of regulatory information internationally for medical products used by humans. It is used for registration, documentation and safety monitoring of medical products both before and after a product has been authorized for use. 
  • Feedback requested.

 

Sex at Birth, Sexual Orientation and Gender Identity

Interoperability Need: Representing Patient Gender Identity

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Production
Rating 3
Yes
Free
N/A
Standard for observation values
Final
Production
Rating 3
Yes
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • The HL7 Gender Harmony Project provides guidance on how to exchange clinical sex and gender affirming information using HL7 models. 
  • For more information about observations and observation values, see Appendix II for an informational resource developed by the Health IT Standards Committee. 

 

Interoperability Need: Representing Patient Sex (At Birth)

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Production
Rating 5
No
Free
N/A
Standard for observation values
Final
Production
Rating 5
Yes
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • Sex Assigned at Birth may be exchanged as a unique data element or as a kind of Recorded Sex or Gender as described in the HL7 Gender Harmony implementation guide. 
  • For more information about observations and observation values, see Appendix III for an informational resource developed by the Health IT Standards Committee. 

 

 

Interoperability Need: Representing Sexual Orientation

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Production
Rating 2
Yes
Free
N/A
Standard for observation values
Final
Production
Rating 2
Yes
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • For more information about observations and observation values, see Appendix III for an informational resource developed by the Health IT Standards Committee. 


 

 

Social, Psychological and Behavioral Data

Interoperability Need: Representing Alcohol Use

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 1
No
Free
N/A
Standard for observations
Final
Production
Rating 3
Yes
Free
N/A
Standard for observation values
Final
Production
Rating 1
No
Free
N/A
Standard
Final
Production
Rating 1
No
$
N/A
Standard for observation values
Final
Production
Rating 3
Yes
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • The optional 2015 Edition Cures Act Social, psychological, and behavioral data criterion (170.315(a)(15)) specifies LOINC codes for exchanging alcohol use observations. This criterion was not changed in HTI-1
  • The Alcohol Use Disorder Identification Test - Consumption [AUDIT-C] contains a subset of the World Health Organization’s 10-question AUDIT alcohol screening. Both are used to identify patients who are hazardous drinkers or have active alcohol use disorders (including alcohol abuse or dependence). 
  • Screening, Brief Intervention, and Referral to Treatment (SBIRT) is a comprehensive, integrated, public health approach to the delivery of early intervention and treatment services for persons with substance use disorders, as well as those who are at risk of developing these disorders. 
  • Units of measure for quantitative result values must be represented using UCUM, see Representing Units of Measure
  • For more information about observations and observation values, see Appendix III for an informational resource developed by the Health IT Standards Committee. 

 

Interoperability Need: Representing Depression

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 3
Yes
Free
N/A
Standard for observation values
Final
Production
Rating 3
Yes
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • The optional 2015 Edition Cures Act Social, psychological, and behavioral data criterion (170.315(a)(15)) specifies LOINC codes for exchanging depression observations. This criterion was not changed in HTI-1
  • The Patient Health Questionnaire 2 item (PHQ-2) is a two-question screening tool for symptoms of depression in the past two weeks.  It consists of the first two questions of the PHQ-9
  • The full Patient Health Questionnaire 9 item (PHQ-9) incorporates DSM-IV depression criteria with other major depressive symptoms into a brief self-report instrument commonly used for screening and diagnosis, as well as selecting and monitoring treatment.
  • The HL7® Post Acute Care Interoperability (PACIO) project provides additional information about the depression screening panels.
  • The Beck Depression Inventory Fast Screen (BDI FS) is a shorter version of the Beck Depression Inventory II (BDI II). The BDI FS contains seven items from the BDI II and is used to evaluate depression symptoms in alignment with the Diagnostic and Statistical Manual of Mental Disorders, fourth edition (DSM-IV) criteria for depression. [PMID:19010075]
  • Units of measure for quantitative result values must be represented using UCUM, see Representing Units of Measure
  • For more information about observations and observation values, see Appendix III for an informational resource developed by the Health IT Standards Committee. 

 

Interoperability Need: Representing Educational Attainment

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 3
Yes
Free
N/A
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
$
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)

 

Interoperability Need: Representing Elder Abuse

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 1
No
Free
N/A
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
$
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • Elder abuse is defined by the HL7 Gravity Project as an intentional act or failure to act by a caregiver or another person in a relationship involving an expectation of trust that causes or creates a risk of harm to an older adult and can be in the form of physical abuse, psychological abuse, sexual abuse, financial abuse, and neglect by someone in a caregiving role. 
  • LOINC is used for Social Determinants of Health (SDOH) observations (assessment instrument panels, questions, and answers.)  
  • SNOMED CT U.S. Edition is used for SDOH observations, conditions, goals, and interventions.
  • ICD-10-CM is used for SDOH diagnoses.
  • CPT is used for SDOH interventions.
  • Implementation information for Elder Abuse exchange can be found in Structure and Exchange of Social Determinants of Health Information.
  • For more information about observations and observation values, see Appendix III for an informational resource developed by the Health IT Standards Committee. 

     

 

Interoperability Need: Representing Employment Status

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 1
No
Free
N/A
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
$
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • Employment status is defined by the HL7 Gravity Project as whether a person is employed or not employed, is available for work or is looking for employment.
  • LOINC is used for Social Determinants of Health (SDOH) observations (assessment instrument panels, questions, and answers.)  
  • SNOMED CT U.S. Edition is used for SDOH observations, conditions, goals, and interventions.
  • ICD-10-CM is used for SDOH diagnoses.
  • CPT is used for SDOH procedures and interventions.
  • Implementation information for Employment Status exchange can be found in Structure and Exchange of Social Determinants of Health Information.
  • For more information about observations and observation values, see Appendix III for an informational resource developed by the Health IT Standards Committee. 

 

Interoperability Need: Representing Financial Insecurity

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 3
Yes
Free
N/A
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
$
N/A

 

Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)

 

Interoperability Need: Representing Food Insecurity

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
$
N/A
Standard
Final
Production
Rating 1
No
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • Food insecurity is defined by the HL7 Gravity Project as uncertain, limited, or unstable access to food that is: adequate in quantity and in nutritional quality; culturally acceptable; safe and acquired in socially acceptable ways.  
  • LOINC is used for Social Determinants of Health (SDOH) observations (assessment instrument panels, questions, and answers.)  
  • SNOMED CT U.S. Edition is used for SDOH observations, conditions, goals, and interventions.
  • ICD-10-CM is used for SDOH diagnoses.
  • CPT and HCPCS Level II are used for SDOH procedures and interventions.
  • Implementation information for Food Insecurity exchange can be found in Structure and Exchange of Social Determinants of Health Information.
  • For more information about observations and observation values, see Appendix III for an informational resource developed by the Health IT Standards Committee. 

 

Interoperability Need: Representing Health Insurance Coverage

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 1
No
Free
N/A
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
$
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)

Health insurance coverage is defined by the HL7 Gravity Project as documentation of presence and type of insurance. 

LOINC is used for Social Determinants of Health (SDOH) observations (assessment instrument panels, questions, and answers.)  

SNOMED CT U.S. Edition is used for SDOH observations, conditions, goals, and interventions.

ICD-10-CM is used for SDOH diagnoses.

CPT is used for SDOH procedures and interventions.

Implementation information for Health Insurance Coverage exchange can be found in Structure and Exchange of Social Determinants of Health Information.

For more information about observations and observation values, see Appendix III for an informational resource developed by the Health IT Standards Committee. 

 

Interoperability Need: Representing Homelessness

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
$
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • Homelessness is defined by the HL7 Gravity Project in two ways, sheltered and unsheltered. 
    • Sheltered homelessness is currently living in a shelter, motel, temporary or transitional living situation, scattered-site housing, or not having a consistent place to sleep at night. 
    • Unsheltered homelessness is residing in a place not meant for human habitation, such as cars, parks, sidewalks, abandoned buildings, on the street.
  • LOINC is used for Social Determinants of Health (SDOH) observations (assessment instrument panels, questions, and answers.)  
  • SNOMED CT U.S. Edition is used for SDOH observations, conditions, goals, and interventions.
  • ICD-10-CM is used for SDOH diagnoses.
  • CPT is used for SDOH procedures and interventions.
  • Implementation information for Homelessness exchange can be found in Structure and Exchange of Social Determinants of Health Information.
  • For more information about observations and observation values, see Appendix III for an informational resource developed by the Health IT Standards Committee. 

 

Interoperability Need: Representing Housing Instability

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
$
N/A
Standard
Final
Production
Rating 1
No
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • Housing instability is defined by the HL7 Gravity Project as currently consistently housed but experiencing any of the following circumstances in the last 12 months: behind on rent or mortgage, 3 or more relocations, housing cost burden, homelessness, or risk of eviction.
  • LOINC is used for Social Determinants of Health (SDOH) observations (assessment instrument panels, questions, and answers.)  
  • SNOMED CT U.S. Edition is used for SDOH observations, conditions, goals, diagnoses, procedures and interventions.
  • ICD-10-CM is used for SDOH diagnoses.
  • CPT and HCPCS Level II are used for SDOH procedures and interventions.
  • Implementation information for Housing Instability exchange can be found in Structure and Exchange of Social Determinants of Health Information.
  • For more information about observations and observation values, see Appendix III for an informational resource developed by the Health IT Standards Committee. 

 

Interoperability Need: Representing Inadequate Housing

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
$
N/A
Standard
Final
Production
Rating 1
No
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)

 

Interoperability Need: Representing Intimate Partner Violence

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 3
Yes
Free
N/A
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
$
N/A
Standard
Final
Production
Rating 3
Yes
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)

 

Interoperability Need: Representing Material Hardship

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 1
No
Free
N/A
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
$
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)

 

Interoperability Need: Representing Medical Cost Burden

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 1
No
Free
N/A
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
$
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • Medical cost burden is defined by the HL7 Gravity Project as a measure of financial pressure resulting from health spending stemming from inadequate resources to meet medical cost needs.
  • LOINC is used for Social Determinants of Health (SDOH) observations (assessment instrument panels, questions, and answers.)  
  • SNOMED CT U.S. Edition is used for SDOH observations, conditions, goals, and interventions.
  • ICD-10-CM is used for SDOH diagnoses.
  • CPT is used for SDOH procedures and interventions.
  • Implementation information for Medical Cost Burden exchange can be found in Structure and Exchange of Social Determinants of Health Information.
  • For more information about observations and observation values, see Appendix III for an informational resource developed by the Health IT Standards Committee. 

 

Interoperability Need: Representing Physical Activity

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 1
Yes
Free
N/A
Standard
Final
Production
Rating 3
Yes

 

Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)

 

Interoperability Need: Representing Social Care Services Information

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
No
$
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • Feedback requested.
  • Feedback requested.

 

Interoperability Need: Representing Social Connection and Isolation

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 3
Yes
Free
N/A
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
$
N/A
Standard
Final
Production
Rating 3
Yes
Free

 

Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • The optional 2015 Edition Cures Act Social, psychological, and behavioral data criterion (170.315(a)(15)) specifies LOINC codes for exchanging  information about social connection and isolation. This criterion was not changed in HTI-1
  • Social connection is defined by the HL7 Gravity Project as encompassing the structural, functional, and quality aspects of how individuals connect to each other, and contains three components:
    • Social Isolation: Objectively being alone, having few relationships, or infrequent social contact,
    • Loneliness: Subjectively feeling alone. The discrepancy between one’s desired level of connection and one’s actual level, and
    • Social Support: Actual or perceived availability of resources (e.g., informational, tangible, emotional) from others. Four types of social supportive behaviors: emotional, instrumental, informational, and appraisal. 
  • The scope of the HL7 Gravity Project Social Connection domain is more broad than the certification criterion and includes information about related conditions and interventions.
  • LOINC is used for Social Determinants of Health (SDOH) observations (assessment instrument panels, questions, and answers.)  
  • SNOMED CT U.S. Edition is used for SDOH observations, conditions, goals, and interventions.
  • ICD-10-CM is used for SDOH diagnoses.
  • CPT is used for SDOH procedures and interventions.
  • Units of measure for quantitative result values must be represented using UCUM, see Representing Units of Measure
  • Implementation information for Social Connection exchange can be found in Structure and Exchange of Social Determinants of Health Information.
  • For more information about observations and observation values, see Appendix III for an informational resource developed by the Health IT Standards Committee. 

 

Interoperability Need: Representing Social Determinants of Health - Conditions and Diagnoses

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 1
Yes
Free
Standard
Final
Production
Rating 1
Yes
Free

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)

 

Interoperability Need: Representing Social Determinants of Health - Goals

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 1
Yes
Free

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)

 

Interoperability Need: Representing Social Determinants of Health - Interventions

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 1
Yes
Free
N/A
Standard
Final
Production
Rating 1
Yes
$
Standard
Final
Production
Rating 1
Yes
Free

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)

 

Interoperability Need: Representing Social Determinants of Health - Screening Assessments

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 1
Yes
Free
No
Standard
Final
Production
Rating 1
Yes
Free

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • Social Determinants of Health (SDOH) Screening Assessments are questionnaire-based, structured evaluations for an SDOH-related risk. (e.g., PRAPARE, Hunger Vital Sign, AHC-HRSN screening tool).
  • The HL7 Gravity Project established and maintains current value sets which represent SDOH Screening Assessments.  
  • SNOMED CT U.S. Edition is used to represent answers to SDOH assessment questions.
  • LOINC is used to represent SDOH assessment tools and the questions within. 
  • Implementation information for SDOH Assessment exchange can be found in Structure and Exchange of Social Determinants of Health Information.
  • For more information about observations and observation values, see Appendix III for an informational resource developed by the Health IT Standards Committee. 

 

Interoperability Need: Representing Stress

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 3
Yes
Free
N/A
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
$
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)

 

Interoperability Need: Representing Substance Use

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
No
Free
No
Standard
Final
Production
Rating 3
No
Free
No
Standard
Final
Production
Rating 3
Yes
Free
No
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
$
No
Standard
Final
Production
Rating 3
No
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • The Drug Abuse Screen Test (DAST-10) was designed to provide a brief, self-report instrument for population screening, clinical case finding and treatment evaluation research. It can be used with adults and older youth. 
    • (c)1982 Harvey Skinner, PhD, Centre for Addiction and Mental Health, Toronto, Canada.
  • Units of measure for quantitative result values must be represented using UCUM, see Representing Units of Measure
  • Screening, Brief Intervention, and Referral to Treatment (SBIRT) is a comprehensive, integrated, public health approach to the delivery of early intervention and treatment services for persons with substance use disorders, as well as those who are at risk of developing these disorders.
  • Prescription Drug Monitoring Programs (PDMPs) are electronic databases that track controlled substance prescriptions in a state. More information on standards and implementation specifications in use for the exchange of PDMP data can be found on the Allows for the Exchange of State Prescription Drug Monitoring Program (PDMP) Data ISA page.
  • For more information about observations and observation values, see Appendix III for an informational resource developed by the Health IT Standards Committee.  
  • Drug Abuse Screening Test-10 [DAST-10]: LOINC 82666-9

     

 

Interoperability Need: Representing Transportation Insecurity

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
Free
Standard
Final
Production
Rating 1
No
$

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • Transportation insecurity is defined by the HL7 Gravity Project as uncertain, limited, or no access to safe, reliable, accessible, affordable, and socially acceptable transportation infrastructure and modalities necessary for maintaining one’s health, well-being, or livelihood.
  • LOINC is used for Social Determinants of Health (SDOH) observations (assessment instrument panels, questions, and answers.)  
  • SNOMED CT U.S. Edition is used for SDOH observations, conditions, goals, and interventions.
  • ICD-10-CM is used for SDOH diagnoses.
  • CPT and HCPCS Level II are used for SDOH interventions and procedures.
  • Implementation information for Transportation Insecurity exchange can be found in Structure and Exchange of Social Determinants of Health Information.
  • For more information about observations and observation values, see Appendix III for an informational resource developed by the Health IT Standards Committee. 

 

Interoperability Need: Representing Veteran Status

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 1
No
Free
N/A
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
Free
No
Standard
Final
Production
Rating 1
No
$
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)

 

Tobacco Use

Interoperability Need: Representing Patient Electronic Cigarette Use (Vaping)

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Production
Rating 3
No
Free
N/A
Standard for observation values
Final
Production
Rating 3
No
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • The 2015 Edition smoking status criterion (§ 170.315(a)(15)) applies only to smoked tobacco.  It does not require the ability to capture other forms of tobacco or nicotine use (e.g., smokeless tobacco, e-cigarettes, secondhand smoke). In HTI-1, the criterion language did not change however SNOMED CT is required as a result of including USCDI v3
  • HL7® FHIR® US Core 7.0.0 and C-CDA 3.0 terminology bindings are updated to reference a value set that encompasses smoked tobacco, exposure to secondhand smoke, vaping and other methods of ingesting tobacco products. Smoking Status Type is used to categorize whether the smoking status is for smoking or tobacco use. It also includes concepts to reflect number of pack years or calculated pack years for cumulative lifetime tobacco exposure.
  • Units of measure for quantitative result values should be represented using UCUM, see Representing Units of Measure
  • For more information about observations and observation values, see Appendix III for an informational resource developed by the Health IT Standards Committee.  

 

Interoperability Need: Representing Patient Secondhand Tobacco Smoke Exposure

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Production
Rating 3
No
Free
N/A
Standard for observation values
Final
Production
Rating 3
Yes
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)

The 2015 Edition smoking status criterion (§ 170.315(a)(15)) applies only to smoked tobacco.  It does not require the ability to capture other forms of tobacco or nicotine use (e.g., smokeless tobacco, e-cigarettes, secondhand smoke). 

In HTI-1, the criterion language did not change however SNOMED CT is required as a result of including USCDI v3

HL7® FHIR® US Core 7.0.0 and C-CDA 3.0 terminology bindings are updated to reference a value set that encompasses smoked tobacco, exposure to secondhand smoke, vaping and other methods of ingesting tobacco products. Smoking Status Type is used to categorize whether the smoking status is for smoking or tobacco use. It also includes concepts to reflect number of pack years or calculated pack years for cumulative lifetime tobacco exposure.

Units of measure for quantitative result values should be represented using UCUM, see Representing Units of Measure

For more information about observations and observation values, see Appendix III for an informational resource developed by the Health IT Standards Committee.  

 

Interoperability Need: Representing Patient Tobacco Use (Smoking Status)

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Production
Rating 5
No
Free
N/A
Standard for observation values
Final
Production
Rating 5
Yes
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • The 2015 Edition smoking status criterion (§ 170.315(a)(15)) applies only to smoked tobacco.  It does not require the ability to capture other forms of tobacco or nicotine use (e.g., smokeless tobacco, e-cigarettes, secondhand smoke). 
  • In HTI-1, the criterion language did not change however SNOMED CT is required as a result of including USCDI v3
  • HL7® FHIR® US Core 7.0.0 and C-CDA 3.0 terminology bindings are updated to reference a value set that encompasses smoked tobacco, exposure to secondhand smoke, vaping and other methods of ingesting tobacco products. Smoking Status Type is used to categorize whether the smoking status is for smoking or tobacco use. It also includes concepts to reflect number of pack years or calculated pack years for cumulative lifetime tobacco exposure.
  • Units of measure for quantitative result values should be represented using UCUM, see Representing Units of Measure
  • For more information about observations and observation values, see Appendix III for an informational resource developed by the Health IT Standards Committee.   

 

Units of Measure

Interoperability Need: Representing Units of Measure (For Use with Numerical References and Values)

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 4
Yes
Free
Yes
Yes

 

Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • UCUM is a syntax for representing units of measure for use with numerical references and values. It is not an enumerated set of codes.
  • The case sensitive version is the correct unit string to be used for interoperability purposes.
  • Per public comments received, there may be some limitations with UCUM in the laboratory domain that remain unresolved.
  • The abbreviations used for a few of the units of measure listed in the UCUM standard are currently on lists of prohibited abbreviations from the Institute for Safe Medication Practice (ISMP).
  • Some abbreviations for units of measure include symbols which may be in conflict with other HL7 standards.
  • Some abbreviations for units are nonstandard for human understanding.(For example, if a result for a White Blood Cell count is 9.6 x 103/μL, the UCUM recommendation for rendering this value in a legacy character application is 9.6 x 10*3/uL. Because the “*” is a symbol for multiplication in some systems.) This recommendation may result in errors either by the information system or the human reading the result.
  • Some abbreviations used in UCUM are not industry standard for the tests that use these units of measure.
  • Units Of Measure Case Sensitive 2.16.840.1.113883.1.11.12839 (most frequently used codes)
  • “Table of Example UCUM Codes for Electronic Messaging" published by the Regenstrief Institute, Inc. Value set is made available at http://loinc.org/usage/units and identified by the OID 1.3.6.1.4.1.12009.10.3.1

 

Vital Signs

Interoperability Need: Representing Patient Vital Signs

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
Yes
Free
N/A
Standard
Final
Production
Rating 3
No
$
Yes
Yes

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • See Section I - Units of Measure for discussion of units of measure used with quantitative observations.
  • See LOINC collaboration with IEEE for information on the Medical Device Code Mapping Table, which provides linkages between LOINC terms and IEEE EMB/11073 standard. 
  • ISO/IEEE 11073 is a family of standards for point-of-care medical device communication, with specific standards within the 11073 family that support collection of vital signs from medical devices, including:
    • IEEE P11073-10404: Device Specialization - Pulse Oximeter
    • IEEE 11073-10406: Device Specialization - Basic electrocardigraph (ECG) 
    • IEEE P11073-10407: Device Specialization - Blood Pressure Monitor
    • IEEE 11073-10408: Device Specialization - Thermometer 
    • IEEE P11073-10415: Device Specialization - Weighing Scale
    • IEEE 11073-10417: Device Specialization - Glucose Meter
    • IEEE 11073-10201: Implantable Cardiac Devices
  • Vital Sign Result urn:oid:2.16.840.1.113883.3.88.12.80.62
  • LOINC standard applies to USCDI required vital signs:
    • Diastolic blood pressure

    • Systolic blood pressure

    • Body height

    • Body weight

    • Heart Rate

    • Respiratory rate

    • Body temperature

    • Pulse oximetry

    • Inhaled oxygen concentration

    • BMI Percentile (2 - 20 years)

    • Weight-for-length Percentile (Birth - 36 Months)

    • Head Occipital-frontal Circumference Percentile (Birth - 36 Months)

 

Work Information

Interoperability Need: Representing Job, Usual Work, and Other Work Information

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard for observations
Final
Production
Rating 1
No
Free
N/A
Standard for observation values
Balloted Draft
Pilot
Feedback Requested
No
Free
No
Standard for observation values
Balloted Draft
Production
Rating 1
No
Free
Yes
Implementation Specification
Balloted Draft
Feedback requested
Feedback Requested
No
Free

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • Self-reported, structured and standardized work history has broad applicability to healthcare as part of the medical record and is suitable for many use cases supporting patient care, population health, and public health.
  • An Information Model, Occupational Data for Health (ODH), supports the collection and classification of Work Information in health IT systems and has been published in JAMIA.
  • NIOSH has prepared A Guide to the Collection of Occupational Data for Health to provide tips to health IT system developers seeking to implement work concepts.
  • The ODH industry value set includes the search-friendly terms from the North American Industry Classification System (NAICS) index with the respective category. The terms in this value set are relatable to the general public.
  • The ODH occupation value set includes the search-friendly terms from the Occupational Information Network-Standard Occupational Classification (O*NET-SOC) system alternate titles with the respective category. The terms in this value set are relatable to the general public.
  • The CDC_Census 2010 Industry and Occupation System will be deprecated when the HL7 CDA R2 Implementation Guide: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers, Release 1; DSTU Release 1.1 – US Realm.is updated through SVAP.

 

Content/Structure

Admission, Discharge and Transfer

Interoperability Need: Sending a Notification of a Long-Term Care Patient’s Admission, Discharge and/or Transfer Status to the Servicing Pharmacy

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
No
Free
No
Standard
Final
Production
Rating 3
No
$
No
Standard
Final
Feedback requested
Feedback Requested
No
$
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The “Census Message” transaction allows for long-term and post-acute care settings to notify the servicing pharmacy of a patient’s admission, discharge and/or transfer status.
  • Secure Communication – Create a secure channel for client-to- serve and server-to-server communication.
  • Secure Message Router – Securely route and enforce policy on inbound and outbound messages without interruption of delivery and having multi-directional feedback loops for prompt access to ancillary data, for clarifications, and for quickly reporting and addressing system and data transmission errors.
  • Authentication Enforcer – Centralized authentication processes.
  • Authorization Enforcer – Specifies access control policies.
  • Credential Tokenizer – Encapsulate credentials as a security token for reuse (e.g., SAML, Kerberos).
  • Assertion Builder – Define processing logic for identity, authorization and attribute statements.
  • User Role – Identifies the role asserted by the individual initiating the transaction.
  • Purpose of Use - Identifies the purpose for the transaction.

 

Interoperability Need: Sending a Notification of a Patient’s Admission, Discharge and/or Transfer Status to Other Providers

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
No
Free
No
Implementation Specification
Final
Feedback requested
Feedback Requested
No
Free
No
Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
No
Implementation Specification
Final
Production
Rating 4
No
Free
No
Emerging Implementation Specification
In Development
Pilot
Feedback Requested
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  •  DirectTrust Standards Implementation Guide "Event Notifications via the Direct Standard®" provides a profile for the payload included in event notifications when Direct is the transport. The guide standardizes HL7 2.5.1 usage and maps metadata elements to support appropriate routing and workflow for receiving systems. Human readable text is also stipulated as a part of the specification to support uncomplicated edge systems. The Implementation Guide was published and ANSI approved May 11, 2022. If unformatted, text only notifications are sent to Direct Addresses, the systems using the Direct specification will not be able to process these messages without the necessary metadata.  
  • Secure Communication – Create a secure channel for client-to-server and server-to-server communication.
  • Secure Message Router – Securely route and enforce policy on inbound and outbound messages without interruption of delivery.
  • Authentication Enforcer – Centralized authentication processes.
  • Authorization Enforcer – Specifies access control policies.
  • Credential Tokenizer – Encapsulate credentials as a security token for reuse (e.g., – SAML, Kerberos).
  • Assertion Builder – Define processing logic for identity, authorization and attribute statements.
  • User Role – Identifies the role asserted by the individual initiating the transaction.
  • Purpose of Use -Identifies the purpose for the transaction.

 

Interoperability Need: Sending a Notification of a Patient’s Encounter to a Record Locator Service

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Feedback Requested
No
Free
Yes
Yes
Yes
Implementation Specification
Final
Production
Feedback Requested
No
Free
Yes
Yes
Implementation Specification
In Development
Feedback requested
Feedback Requested
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Feedback requested.
  • Feedback requested. 

 

Care Coordination

Interoperability Need: Advance Directive

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Emerging Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
No
Emerging Implementation Specification
In Development
Feedback requested
Feedback Requested
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The ePOLST CDA Implementation Guide is based on the National POLST form, first published in August 2019 and adopted by several states. The National POLST form represents a major step toward national consensus on a POLST form developed through many months of interviews and listening, consensus building, feedback, compromise, and iterative revisions.
    Use of the ePOLST CDA Implementation Guide requires that a state-adopted POLST form be compatible with the National POLST form, but does not require adoption of the National POLST form.
  • Feedback requested.

 

Interoperability Need: Referral from Acute Care to a Skilled Nursing Facility

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Balloted Draft
Production
Feedback Requested
No
Free
Yes
Implementation Specification
Balloted Draft
Production
Feedback Requested
No
Free
No
Implementation Specification
Balloted Draft
Production
Feedback Requested
No
Free
No
Emerging Implementation Specification
In Development
Feedback requested
Feedback Requested
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The HL7 CDA R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 3 - US Realm is a newer version of the standard that is available for health IT developers to voluntarily update and provide to their customers. It became available when it was added to the Approved Standards for 2022 through ASTP’s Standards Version Advancement Process (SVAP).
  • Feedback requested.

 

Interoperability Need: Referral to a Specialist - Request, Status Updates, Outcome

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Balloted Draft
Production
Rating 5
Yes
Free
Yes
Implementation Specification
Balloted Draft
Production
Feedback Requested
No
Free
No
Implementation Specification
Balloted Draft
Production
Feedback Requested
No
Free
No
Emerging Implementation Specification
Balloted Draft
Production
Rating 1
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The HL7 CDA R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 3 - US Realm is a newer version of the standard that is available for health IT developers to voluntarily update and provide to their customers. It became available when it was added to the Approved Standards for 2022 through ASTP's Standards Version Advancement Process (SVAP).
  • Feedback requested.

 

Interoperability Need: Referrals Between Clinicians and Community-Based Organizations and Other Extra-Clinical Services

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 3
No
Free
No
Emerging Standard
Balloted Draft
Feedback requested
Feedback Requested
No
Free
No
Emerging Standard
Balloted Draft
Feedback requested
Feedback Requested
No
Free
No
Emerging Standard
Balloted Draft
Feedback requested
Feedback Requested
No
Free
No
Emerging Implementation Specification
In Development
Feedback requested
Feedback Requested
No
Free
No
Emerging Implementation Specification
In Development
Pilot
Feedback Requested
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Use cases under this section refer to interactions between clinical settings and organizations outside of the clinical setting ("extra-clinical").
  • The 360X Project, building on and in close coordination with the Gravity Project, is leveraging existing IHE 360X profiles to develop a profile designed to support closed-loop referrals to extra-clinical organizations in support of social determinants of health use cases.
  • FHIR Resources are in various stages of maturity. Please refer to the FHIR website for updates on specific profiles and their progress. The FHIR Maturity Model and each of the levels is described on the HL7 wiki.
  • Feedback requested.

 

Care Plan

Interoperability Need: Documenting and Sharing Care Plans for a Single Clinical Context

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 3
No
Free
N/A
Implementation Specification
Final
Production
Rating 2
Yes
Free
Implementation Specification
Balloted Draft
Production
Rating 3
Yes
Free
Yes
Implementation Specification
Final
Production
Rating 1
No
Free
No
Implementation Specification
Balloted Draft
Production
Feedback Requested
No
Free
No
Implementation Specification
Balloted Draft
Production
Feedback Requested
No
Free
No
Emerging Implementation Specification
In Development
Feedback requested
Feedback Requested
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The care plan as expressed in the C-CDA standard does not attempt to represent the longitudinal care plan; rather it represents a “snapshot” of a care plan at a single point in time for transmission to other providers and teams to ensure continuity of care.
  • The Care Plan Domain Analysis Model is used as a reference model for C-CDA care plan documents in the context of the longitudinal care plan.
  • FHIR Resources are in various stages of maturity. Please refer to the FHIR website for updates on specific profiles and their progress. The FHIR Maturity Model and each of the levels is described on the HL7 wiki.
  • The HL7 CDA R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 3 - US Realm is a newer version of the standard that is available for health IT developers to voluntarily update and provide to their customers. It became available when it was added to the Approved Standards for 2022 through ASTP's Standards Version Advancement Process (SVAP).
  • Feedback requested.

 

Interoperability Need: Documenting and Sharing Medication-Related Care Plans by Pharmacists

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 3
No
Free
No
Implementation Specification
Final
Production
Rating 3
No
Free
No
Implementation Specification
Final
Production
Rating 2
No
Free
Yes
Implementation Specification
Final
Production
Rating 2
No
$
No
Implementation Specification
Balloted Draft
Production
Rating 3
Yes
Free
No
Implementation Specification
Balloted Draft
Production
Feedback Requested
No
Free
No
Implementation Specification
Balloted Draft
Production
Feedback Requested
No
Free
No
Emerging Implementation Specification
Balloted Draft
Pilot
Feedback Requested
No
Free
No
Emerging Implementation Specification
In Development
Production
Rating 1
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The Pharmacist eCarePlan implementation specifications listed for this interoperability need are a result of a joint effort between HL7 and NCPDP to create a standardized, interoperable document for exchange of consensus-driven prioritized medication-related activities, plans and goals for an individual needing care. This project was partially funded by ASTP's High Impact Pilots Cooperative Agreement Program. The Community Pharmacy Enhanced Services Network maintains a listing of vendor participants from this program. 
  • More than 100 value sets are currently captured in VSAC in support of this interoperability need. Search for "PharmacyHIT" to view them. 
  • The HL7 CDA R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 3 - US Realm is a newer version of the standard that is available for health IT developers to voluntarily update and provide to their customers. It became available when it was added to the Approved Standards for 2022 through ASTP's Standards Version Advancement Process (SVAP).
  • Feedback requested. 

 

Interoperability Need: Documenting Care Plans for Person Centered Services

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The electronic Long-Term Services and Supports (eLTSS) Implementation Guide (IG) is based on FHIR R4. The standards were developed to enable the creation, exchange and re-use of interoperable person centered service plans for use by health care, home and community based service providers, payers and the individuals they serve. These plans can help to improve the coordination of health and social services that support an individual’s mental and physical health. 
     
  • The eLTSS data referenced in this implementation guide refers to the eLTSS Dataset that was developed by the eLTSS Initiative, a joint project between the Assistant Secretary for Technology Policy (ASTP) and the Centers for Medicare and Medicaid Services (CMS).  See eLTSS Initiative website for more information.
  • Feedback requested.

 

Interoperability Need: Domain or Disease-Specific Care Plan Standards

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 3
No
Free
No
Implementation Specification
Balloted Draft
Production
Rating 3
Yes
Free
Yes
Implementation Specification
Final
Production
Rating 1
No
Free
Implementation Specification
Balloted Draft
Pilot
Rating 3
No
Free
No
Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
No
Implementation Specification
Balloted Draft
Production
Feedback Requested
No
Free
No
Implementation Specification
Balloted Draft
Production
Feedback Requested
No
Free
No
Emerging Implementation Specification
In Development
Feedback requested
Feedback Requested
No
Free
No
Emerging Implementation Specification
In Development
Feedback requested
Feedback Requested
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The HL7 CDA R2 IG is based on C-CDA R2.1 and aligns with the Care Plan document specifications.
  • The IHE Profile is based on HL7 V2.6 IG: Early Hearing Detection and Intervention (EHDI) Messaging, Release 1.
  • The Personal Advance Care Plan Document is for the domain of patient-authored goals, priorities and preferences, including but not limited to Advance Directives.
  • The HL7 CDA R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 3 - US Realm is a newer version of the standard that is available for health IT developers to voluntarily update and provide to their customers. It became available when it was added to the Approved Standards for 2022 through ASTP's Standards Version Advancement Process (SVAP).
  • Feedback requested.

 

Interoperability Need: Sharing Patient Care Plans for Multiple Clinical Contexts

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Balloted Draft
Production
Rating 3
Yes
Free
No
Implementation Specification
Final
Production
Rating 3
No
Free
No
Implementation Specification
Final
Production
Rating 3
No
Free
Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
No
Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
Implementation Specification
Balloted Draft
Production
Feedback Requested
No
Free
No
Implementation Specification
Balloted Draft
Production
Feedback Requested
No
Free
No
Emerging Implementation Specification
In Development
Feedback requested
Feedback Requested
No
Free
No
Emerging Implementation Specification
In Development
Feedback requested
Feedback Requested
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The HL7 CDA R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 3 - US Realm is a newer version of the standard that is available for health IT developers to voluntarily update and provide to their customers. It became available when it was added to the Approved Standards for 2022 through ASTP's Standards Version Advancement Process (SVAP).
  • Feedback requested.

 

Clinical Decision Support

Interoperability Need: Communicate Appropriate Use Criteria with the Order and Charge to the Filling Provider and Billing System for Inclusion on Claims

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • No CDS-OAT-specific test tools. 
  • Feedback requested.

 

Interoperability Need: Provide Access to Appropriate Use Criteria

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 4
No
Free
Yes

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The CDS Hooks specification describes the RESTful APIs and interactions between EHRs and CDS Services. 
  • Guideline Appropriate Ordering using CDS Hooks, is a stakeholder-led initiative and part of the Argonaut project, supports Protecting Access to Medicare Act (PAMA) requirements.
  • Note that the maturity level of FHIR resources may vary and is described with the specification itself. 
  • Feedback requested.

 

Interoperability Need: Shareable Clinical Decision Support

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 4
No
Free
Yes
Standard
Final
Production
Rating 4
No
Free
Yes
Emerging Standard
Balloted Draft
Pilot
Rating 1
No
Free
N/A
Standard
Balloted Draft
Pilot
Rating 2
No
Free
Yes
Standard
Final
Production
Rating 3
No
Free
N/A
Emerging Standard
Final
Production
Rating 1
No
Free
N/A
Implementation Specification
Balloted Draft
Pilot
Rating 2
No
Free
Yes

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Note that the FHIR Maturity Model and each of the levels is described on the HL7 wiki.
  • Feedback requested.

 

Clinical Notes

Interoperability Need: Documentation of Clinical Notes

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Feedback Requested
Yes
Free
Yes
Implementation Specification
Balloted Draft
Production
Feedback Requested
Yes
Free
Yes
Implementation Specification
Balloted Draft
Production
Feedback Requested
No
Free
Yes
Implementation Specification
Balloted Draft
Feedback requested
Feedback Requested
Yes
Free
Yes

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • A Consultation note is generated as part of a request from a clinician for an opinion or advice from another clinician.
  • A Discharge Summary note is a synopsis of a patient’s admission and course in a hospital or post-acute care setting.
  • A History & Physical note documents the current and past conditions of the patient.
  • An Imaging Narrative contains a consulting specialist's interpretation of image data.
  • A Laboratory Report Narrative contains a consulting specialist's interpretation of the laboratory report.
  • A Pathology Report Narrative contains a consulting specialist's interpretation of the pathology report.
  • A Procedure Note records the indications for a non-operative procedure and, when applicable, post-procedure diagnosis, pertinent events of the procedure, and the patient's tolerance of the procedure.
  • A Progress Note represents a patient's interval status during a hospitalization, outpatient visit, treatment with a LTPAC provider, or other healthcare encounter.
  • The HL7 CDA R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 3 - US Realm is a newer version of the standard that is available for health IT developers to voluntarily update and provide to their customers. It became available when it was added to the Approved Standards for 2022 through ASTP's Standards Version Advancement Process (SVAP).
  • Feedback requested.

 

Clinical Quality Measurement and Reporting

Interoperability Need: Reporting Aggregate Quality Data for Quality Reporting Initiatives

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
No
Free
No
Standard
Balloted Draft
Production
Rating 3
No
Free
Yes
Implementation Specification
Final
Production
Rating 4
Yes
Free
Yes
Implementation Specification
Balloted Draft
Production
Rating 4
Yes
Free
Yes
Implementation Specification
Balloted Draft
Pilot
Rating 3
No
Free
Yes

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The CMS Implementation Guide for Quality Reporting Document Architecture: Category III; Eligible Clinicians and Eligible Professionals Programs; Implementation Guide for 2022 is a newer version of the standard that is available for health IT developers to voluntarily update and provide to their customers. It became available when it was added to the Approved Standards for 2022 through ASTP's Standards Version Advancement Process (SVAP).
  • Feedback requested.

 

Interoperability Need: Reporting Patient-level Quality Data for Quality Reporting Initiatives

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Feedback Requested
Yes
Free
Yes
Implementation Specification
Balloted Draft
Production
Rating 4
Yes
Free
Yes
Implementation Specification
Balloted Draft
Production
Rating 4
Yes
Free
Yes
Implementation Specification
Balloted Draft
Pilot
Rating 2
Yes
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Testing tools for FHIR and QRDA-based quality reporting are available:
    • https://ecqi.healthit.gov/fhir?qttabs_fhir=1
    • https://ecqi.healthit.gov/qrda?qttabs_qrda=1
  • The Data Exchange for Quality Measures Implementation Guide is being expanded to support communication for gaps-in-care.
  • The CMS Implementation Guide for Quality Reporting Document Architecture: Category I; Hospital Quality Reporting; Implementation Guide for 2022 is a newer version of the standard that is available for health IT developers to voluntarily update and provide to their customers. It became available when it was added to the Approved Standards for 2022 through ASTP's Standards Version Advancement Process (SVAP).
  • Feedback requested.

 

Interoperability Need: Sharing Quality Measure Artifacts for Quality Reporting Initiatives

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 4
No
Free
Yes
Standard
Final
Production
Rating 4
No
Free
Yes
Standard
Balloted Draft
Production
Rating 4
No
Free
Yes
Standard
Balloted Draft
Production
Rating 2
No
Free
Yes
Standard
In Development
Production
Rating 4
No
Free
Yes
Standard
In Development
Pilot
Feedback Requested
No
Free
Implementation Specification
Balloted Draft
Production
Rating 4
No
Free
Yes
Implementation Specification
Balloted Draft
Production
Rating 2
No
Free
Yes
Implementation Specification
Balloted Draft
Production
Rating 2
No
Free
Yes

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • QI Core Profiles are used to express the data involved in a shareable measure and depend on US Core profiles.
  • Note that the maturity level of FHIR resources may vary. The FHIR Maturity Model and each of the levels is described on the HL7 wiki.
  • Feedback requested.

 

Data Provenance

Interoperability Need: Establishing the Authenticity, Reliability, and Trustworthiness of Content Between Trading Partners

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Balloted Draft
Production
Rating 1
No
Free
No
Implementation Specification
Final
Production
Rating 3
No
Yes – Open
Implementation Specification
Final
Production
Feedback Requested
Yes
Free
Yes
Implementation Specification
Final
Production
Feedback Requested
Yes
Free
Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
Yes – Open
Emerging Implementation Specification
Balloted Draft
Pilot
Feedback Requested
No
Free
No
Emerging Implementation Specification
In Development
Production
Rating 2
No
Free

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The first implementation specification listed is focused on data provenance representation for CDA R2 implementations and the use of CDA templates.
  • Note that the maturity level of FHIR resources may vary. The FHIR Maturity Model and each of the levels is described on the HL7 wiki.
  • The FHIR implementation specification listed leverages the W3C Provenance specification to represent HL7 support of provenance throughout its standards. It is explicitly modeled as functional capabilities in ISO/HL7 10781 EHR System Functional Model Release 2 and ISO 21089 Trusted End-to-End Information Flows. Mappings are available within the resource. 
  • The Basic Provenance IG "provides the functional and technical guidance for communicating ‘Minimum Viable Provenance’ in CDA and FHIR when information is moved from the source to downstream systems." It includes a design for representing the ‘last hop’ only and doesn't address the potential need to share and display full provenance (full chain of custody).
  • The Object Management Group (OMG) Data Governance Working Group is developing an RFP on Data Provenance & Pedigree. ASTP will consider inclusion of the standard in a future version of the ISA when it is available. More information can be found at: https://www.omgwiki.org/datagovernance/doku.php.
  • The IHE IT Infrastructure (ITI) Technical Framework defines a number of profiles for health information exchange. The document sharing profiles (e.g., XDS, XCA, XDR, XDM, MHD) define metadata elements for documents, including the full provenance of the document. The Document Digital Signature (DSG) Profile defines general purpose methods of digitally signing documents for communication and persistence. For additional information, please see the Enabling Document Sharing Health Information Exchange Using IHE Profiles whitepaper.
  • Feedback requested.
  • Information about security patterns can be found in Appendix I.

 

Diet and Nutrition

Interoperability Need: Exchanging Diet and Nutrition Orders Across the Continuum of Care

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Balloted Draft
Pilot
Rating 1
No
Free
Yes
Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
No
Emerging Standard
Balloted Draft
Pilot
Rating 1
No
Free
Yes
Emerging Standard
In Development
Pilot
Feedback Requested
No
Free
No
Emerging Standard
In Development
Pilot
Feedback Requested
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Feedback Requested

  • System Authentication – The information and process necessary to authenticate the systems involved.
  • User Details – Identifies the end user who is accessing the data.
  • User Role – Identifies the role asserted by the individual initiating the transaction.
  • Purpose of Use – Identifies the purpose for the transaction.

 

Family Health History (Clinical Genomics)

Interoperability Need: Representing Family Health History for Clinical Genomics

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Balloted Draft
Production
Rating 1
No
Free
No
Implementation Specification
Balloted Draft
Production
Rating 1
No
Free
No
Implementation Specification
Final
Pilot
Feedback Requested
No
Free
Yes

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • There is no widely recognized vocabulary to capture family genomic health history, but several vocabularies/value sets are available for consideration. 
  • Further constraint of this standard and implementation specification may be required to support this interoperability need.
  • The Assistant Secretary for Technology Policy (ASTP), in partnership with the National Institutes of Health (NIH), created Sync for Genes to strengthen genomic data sharing, a key component of the Precision Medicine Initiative. This project is also in alignment with the recommendations made by the Precision Medicine Task Force under the Health IT Standards Committee (HITSC) to advance data standards, address relevant privacy policies, and advance innovations in health IT that support precision medicine. Sync for Genes is the first step toward integrating clinical genomics into the point-of-care by expediting the use of standards, such as Health Level 7 (HL7) Fast Healthcare Interoperability Resource (FHIR), to enable and improve patient’s ability to seamlessly share their genomics information via point-of-care applications, such as application programming interfaces (APIs). Sync for Genes supports a critical element of sharing genomic data amplifying the ability to seamlessly share genomic information for research and commercial purposes. Below are the HL7 FHIR Clinical Genomic profiles that were tested as part of the Sync for Genes work:
  • The HL7 Version 2.5.1 Implementation Guide: Lab Results Interface (LRI) Version 1, STU 3 - US Realm includes a section that regards genomic information variants. It may be used as an option for meeting this interoperability need until FHIR resources are more mature.  
  • The U.S. Surgeon General also offers the My Family Health Portrait, allowing individuals to enter their family health history details to share with their family members and/or healthcare providers, learn about risk for conditions that can be hereditary, and be saved as a resource that can be maintained and updated over time. 

The following vocabularies/value sets may be considered:

  • Gene Identifier: HGNC Value Set
  • Transcript Reference Sequence Identifier: NCBI vocabulary
  • DNA Sequence Variation Identifier: NCBI vocabulary
  • DNA Sequence Variation: HGVS nomenclature

 

Healthy Weight

Interoperability Need: Sending Healthy Weight Information

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
Yes

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The Integrating the Healthcare Enterprise (IHE) Healthy Weight Profile Childhood obesity surveillance systems utilize either measured (e.g., NHANES) or parent/self-report height and weight to calculate BMI.  The profile also includes the HL7® Occupational Data for Health (ODH) template.
  • Public health agencies have been studying the relationship between obesity and work factors; for example, the prevalence of obesity has been shown to vary substantially by occupation. 
  • System Authentication – The information and process necessary to authenticate the systems involved.
  • User Details – Identifies the end user who is accessing the data.
  • User Role – Identifies the role asserted by the individual initiating the transaction.
  • Purpose of Use – Identifies the purpose for the transaction.

 

Human and Social Services/Social Determinants of Health

Interoperability Need: Format for Structuring and Sharing Social Care Directory Information

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • HSDS defines the content that provides a minimum data set for Information and Referral (I&R) applications and specialized service directory applications used to discover these services.
  • Feedback requested.

 

Images

Interoperability Need: Format of Medical Imaging Reports for Exchange and Distribution

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
No
Free
Yes
Implementation Specification
Final
Production
Rating 1
No
Free
Yes

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • DICOM defines both its own encoding of reports and templates for encoding narrative reports and machine-generated output as DICOM Structured Reports (SR) for use within imaging systems.
  • DICOM Part 20 is an implementation guide for HL7 CDA R2.
  • DICOM also defines a Diagnostic Imaging Report HL7 CDA Template, which is intended to supersede the C-CDA Diagnostic Imaging Report.
  • Secure Communication – Create a secure channel for client-to- serve and server-to-server communication.
  • Secure Message Router – Securely route and enforce policy on inbound and outbound messages without interruption of delivery.
  • Authentication Enforcer – Centralized authentication processes.
  • Authorization Enforcer – Specifies access control policies.
  • Credential Tokenizer – Encapsulate credentials as a security token for reuse (e.g., SAML, Kerberos).
  • Assertion Builder – Define processing logic for identity, authorization and attribute statements.
  • User Role – Identifies the role asserted by the individual initiating the transaction.
  • Purpose of Use – Identifies the purpose for the transaction.

 

Interoperability Need: Format of Radiation Exposure Dose Reports for Exchange and Distribution

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 2
No
Free
Yes – Open
Implementation Specification
Final
Production
Rating 2
No
Free
Yes – Open
Implementation Specification
Final
Pilot
Rating 1
No
Free
Yes – Open
Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
No
Implementation Specification
Final
Pilot
Feedback Requested
No
Free
Yes – Open

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • These reports record radiation dose in three forms:
    • The dose-related information provided by an exposing device (e.g., CT) as reported by the device.
    • The dose-related information about a radiopharmaceutical administration, as reported by the administering system.
    • The patient or organ absorbed dose based on exposure information, patient characteristics, and patient model.
  • The DICOM PS3.3 2017e A.35.8 X-Ray Radiation Dose SR IOD has a higher adoption level for use with CT than for other x-ray modalities.
  • To survey DICOM implementations, an internet search for the relevant SOP Class UID and the phrase “DICOM Conformance Statement” will typically return links to specific products. SOP Class UIDs can be found by searching for the SOP Class name (e.g., Radiation Dose) in Annex A of DICOM Part 6For example, implementations of X-ray, Radiopharmaceutical and Patient Dose can be found with the following searches, respectively:
    • 1.2.840.10008.5.1.4.1.1.88.67 "dicom conformance statement"

    • 1.2.840.10008.5.1.4.1.1.88.68 "dicom conformance statement"

    • 1.2.840.10008.5.1.4.1.1.88.75 "dicom conformance statement" 

  • REM PixelMed DoseUtility test tool uses Gazelle EVS Client Application on the front end.
  • Feedback requested. 

 

Interoperability Need: Format of Radiology Reports for Exchange and Distribution

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
Yes
Implementation Specification
Balloted Draft
Pilot
Feedback Requested
No
Free
Yes

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Feedback requested.
  • Feedback requested.

 

Interoperability Need: Medical Image Formats for Data Exchange and Distribution

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
No
Free
Yes – Open

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Use Image Acquisition Technology Specific Service/Object Pairs (SOP) Classes.
  • For this interoperability need, reference DICOM Parts 3, 5, and 6: Image Object Definitions, Data Structures and Encoding, Data Dictionary.  The DICOM Standard - Parts 3, 5 and 6 define the required meta information, and standard encoding for storing and exchanging most types of medical “Image Objects”.
  • The adoption level reflects DICOM’s usage when exchanging data between an imaging modality and PACS. An adoption level of three would better reflect the standard’s usage when exchanging medical images between organizations. 
  • DICOM Image Object Definitions are “self-describing objects” that include the meta information and image information in one object.
  • DICOM also specifies standard “meta objects” that can be used to reference specific images and describe other information that can be applied to those images (e.g., annotations, overlays, window/level settings, measurements, key objects, etc.)
  • The DICOM standard includes the specification for encapsulating standard JPEG photos and MPEG videos with DICOM-defined meta information – so the photo/video becomes a DICOM object. The original JPEG image or MPEG video is preserved inside a DICOM shell. DICOM protocols can then be used to exchange these DICOM-wrapped photos/videos – the same as any other DICOM object.
  • Currently machine learning output in radiology is not stored in a standard format - often it is encapsulated as a 'secondary capture' image or in a proprietary format. This means that ML output is not in a format that could be reused and that it is not portable. Algorithm output below the level of an image specified using the FHIR ImagingStudy object should use either a DICOM SR using Template TID 1500 (for graphical annotations) or DICOM Segmentation objects for segmentations.
  • Image encryption - Encryption of “whole object” or “specific attributes of the image."
  • Digital signatures - To ensure the object has not been altered.

 

Laboratory

Interoperability Need: Exchange InVitro Diagnostics (IVD) Orders and Results

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Pilot
Rating 1
No
$
Yes
Standard
Final
Production
Rating 1
Yes
Free
No
Implementation Specification
Final
Production
Rating 3
No
Free
Yes
Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)

For IHE LAW:

  • The Laboratory Analytical Workflow (LAW) Profile is part of the Pathology and Laboratory Medicine (PaLM) domain and defines plug-n-play connectivity between instruments, middleware, and LIS systems in the laboratory. It standardizes the data flow of IVD patient and QC test work order steps and results.  LAW is incorporated into the PaLM Volume 1 and Volume 2 Technical Framework (see link in Table above) and also can be found here.
  • The LAW Profile defines the physical connection, message definitions (based on the HL7 Messaging Standard v2.5.1), and workflow definitions between instruments, middleware, and LIS systems in the laboratory. IICC collaborated with the IHE Pathology and Laboratory Medicine (PaLM) domain to develop the LAW Profile. See: http://ivdconnectivity.org/law-profile/   
  • This is a SHIELD (Systemic Harmonization and Interoperability Enhancement for Laboratory Data) standard. 

For LIVD:

  • The digital format for publication of LOINC® to Vendor IVD Test results (LIVD) includes vendor defined IVD tests associated with a set of pre-defined LOINC codes. LIVD helps assure that laboratory personnel select the appropriate LOINC codes for IVD tests used by their laboratory. LIVD also allows LIS systems to automatically map the correct in vitro diagnostic (IVD) vendor test result to a LOINC code. LIVD was developed by the IVD Industry Connectivity Consortium in collaboration with SHIELD.
  • This is a SHIELD (Systemic Harmonization and Interoperability Enhancement for Laboratory Data) standard. 
  • For additional context, please refer to the Guidance for Industry and Food and Drug Administration Staff “Logical Observations Identifiers Names and Codes (LOINC) for In Vitro Diagnostics.”
  • Note that the LIVD Implementation Specification (LIVD – Digital Format for Publication of LOINC to Vendor IVD Test Results) has not been vetted through a Voluntary Consensus Standards Body (VCSB) as defined in OMB Circular A-119.

 

 

 

Interoperability Need: Exchange Laboratory Test Results

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 1
Yes
Free
Yes
Implementation Specification
Final
Pilot
Rating 1
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • 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 be implemented at a few sites, the recommended standard for new implementations is HL7 Version 2.5.1 Implementation Guide: Lab Results Interface (LRI) Release 1, STU Release 4 - US Realm which is actively maintained. 

 

 

 

Interoperability Need: Order Laboratory Test

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Pilot
Rating 1
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)

 

Interoperability Need: Transmit Laboratory Directory of Services to Provider System

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 1
No
Free
No
Implementation Specification
Final
Production
Rating 1
No
Free
No
Implementation Specification
Final
Pilot
Rating 1
No
Free
No
Emerging Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • The Version 2.5.1 Implementation Guide: S&I Framework Laboratory Test Compendium Framework, R2, STU Release 3.1 is a companion guide to the HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Orders from EHR- US Realm (Laboratory Orders Interface Implementation Guide (LOI IG) and the HL7 Version 2.5.1 Implementation Guide: Orders and Observations; Interoperable Laboratory Reporting to EHR (US Realm) (Laboratory Result Interface IG (LRI IG)). 
  • The 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) is not explicitly implemented, but rather used as a resource by laboratories when setting up their catalog and order messages.

 

 

Medical Device Communication to Other Information Systems/Technologies

Interoperability Need: Transmitting Patient Vital Signs from Medical Devices to Other Information Systems/Technologies

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 3
No
Free
Yes
Implementation Specification
Final
Production
Rating 3
No
Free
Yes

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • IHE-PCD, Continua and ITU refer to the IEEE 11073-10101 standard for its nomenclature.
  • The following specific IHE-PCD profiles that best meet this interoperability need include:
    • IHE-PCD (Patient Care Device Profiles) - Alert Communication Management (ACM)

    • IHE-PCD (Patient Care Device Profiles) - Device Enterprise Communication (DEC)

    • IHE-PCD (Patient Care Device Profiles) - Implantable Device – Cardiac Observation (IDCO)

    • IHE-PCD (Patient Care Device Profiles) - Point-of-Care Infusion Verification (PIV)

    • IHE-PCD (Patient Care Device Profiles) - Rosetta Terminology Mapping (RTM)

  • The Regenstrief LOINC®/IEEE Medical Device Code Mapping Table  allows enterprise information systems (i.e. ""Other information Systems/Technologies") to process vital signs and combine those observations with other types of information; it bridges the semantic map between IEEE 11073 10101 conformant medical devices and certified health IT or aligned information systems that use LOINC already for laboratory reports, document taxonomies, standard forms, questionnaires, assessments, social determinants, and screeners. 
  • FDA  cybersecurity recommendations for medical device manufacturers.  
  • Design Considerations and FDA Pre-Market Submission Recommendations for Interoperable Medical Devices.
  • Feedback requested.

 

Patient Education Materials

Interoperability Need: Clinical Information Systems to Request Context-Specific Clinical Knowledge From Online Resources

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 2
Yes
Free
No
Implementation Specification
Final
Production
Rating 3
Yes
Free
No
Implementation Specification
Final
Production
Rating 3
Yes
Free
No
Emerging Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
Yes

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Feedback requested.
  • Feedback requested.

 

Patient Identity/Identification Management

Interoperability Need: Patient Demographic Record Matching

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
No
Free
Yes
Implementation Specification
Final
Production
Rating 5
No
Free
Yes
Yes
Yes
Implementation Specification
Final
Production
Rating 5
No
Free
Yes
Yes
Emerging Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
Yes
Yes
Emerging Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
Yes
Yes
Emerging Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
No
Emerging Implementation Specification
Balloted Draft
Feedback requested
Feedback Requested
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Chapter 3 of the HL7 Standard 2.5.1 named "Patient Administration" is the relevant chapter for Clinical and Administrative Domains.
  • The Implementation Guide for Expressing Context in Direct Messaging was designed to facilitate inter-organizational patient demographic record matching by standardizing the inclusion of patient demographic metadata in Direct messages. Direct is also listed in several Interoperability Needs in Section III - Push Exchange.
  • Patient Identity Proofing is outside of the scope of this interoperability need.
  • Secure Communication – Create a secure channel for client-to- serve and server-to-server communication.
  • Secure Message Router – Securely route and enforce policy on inbound and outbound messages without interruption of delivery.
  • Authentication Enforcer – Centralized authentication processes.
  • Authorization Enforcer – Specifies access control policies.
  • Credential Tokenizer – Encapsulate credentials as a security token for reuse (e.g., SAML, Kerberos).
  • Assertion Builder – Define processing logic for identity, authorization and attribute statements.
  • User Role – Identifies the role asserted by the individual initiating the transaction.
  • Purpose of Use – Identifies the purpose for the transaction.

 

Interoperability Need: Representing Patient Address

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Pilot
Feedback Requested
No
Free
No
Operating Rules
Final
Pilot
Feedback Requested
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • Feedback requested.
  • Feedback requested.

 

Interoperability Need: Representing Patient Names

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Operating Rules
Final
Feedback requested
Feedback Requested
No
Free
No
Standard
Final
Pilot
Rating 1
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • Feedback requested.
  • Feedback requested.

 

Patient Preference/Consent

Interoperability Need: Recording Patient Preferences for Electronic Consent to Access and/or Share their Health Information with Other Care Providers

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 1
No
Free
Yes
Implementation Specification
Final
Pilot
Rating 1
No
Free
N/A
Emerging Standard
In Development
Pilot
Rating 1
No
Free
Yes
Emerging Standard
In Development
Pilot
Rating 1
No
Free
Yes
Emerging Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
Yes
Implementation Specification
Final
Pilot
Rating 1
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The IHE and CDA-based specifications operate in conjunction with the IHE XDS, XCA, and XDR profiles.
  • IHE BPPC may not support management of patient privacy across governmental jurisdictions which may have different regulations regarding access to patient data by providers, patients, governmental entities, and other organizations.
  • Along with security tokens and consent documents, security labels are the critical third part of the Attribute-Based-Access-Control and SLS for this interoperability need. Security Labels are used in CDA, FHIR, as well as the IHE Document Sharing (e.g. XDS), as described on the FHIR security page at https://www.hl7.org/fhir/security-labels.html 
  • Carequality® is working to develop a technical method for distributing and identifying consent forms to be used as part of their Patient Consent Framework
  • Secure Communication – Create a secure channel for client-to- serve and server-to-server communication.
  • Secure Message Router – Securely route and enforce policy on inbound and outbound messages without interruption of delivery.
  • Authentication Enforcer – Centralized authentication processes.
  • Authorization Enforcer – Specifies access control policies.
  • Credential Tokenizer – Encapsulate credentials as a security token for reuse (e.g., SAML, Kerberos).
  • User Role – Identifies the role asserted by the individual initiating the transaction.
  • Purpose of Use – Identifies the purpose for the transaction.
  • Patient Consent Information – Identifies the patient consent information that may be required before data can be accessed.

 

Additional information about security patterns can be found in Appendix 1.

 

 

Pharmacy Interoperability

Interoperability Need: Allows a Long-Term or Post-Acute Care to Request to Send an Additional Supply of Medication

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 3
Yes
$
Yes
Implementation Specification
Final
Feedback requested
Feedback Requested
Yes

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Please refer to CMS.gov for more information regarding Medicare Part D electronic prescribing requirements and sign up for e-mail updates to receive the latest announcements.
  • The NCPDP SCRIPT Standard Implementation Guide supports the Resupply transaction; a request from a Long-Term or Post-Acute Care (LTPAC) organization to a pharmacy to send an additional supply of medication for an existing order. An example use case is when a medication supply for a resident is running low (2-3 doses) and a new supply is needed from the pharmacy, the LTPAC organization needs a way to notify the pharmacy that an additional supply for the medication is needed.
  • Both the prescriber and the pharmacy must have their systems configured for the transaction in order to facilitate successful exchange, including the ability to send or receive verify, status, or error transactions.
  • Secure Message Router – Securely route and enforce policy on inbound and outbound messages without interruption of delivery.
  • Authentication Enforcer – Centralized authentication processes.
  • Authorization Enforcer – Specifies access control policies.
  • Credential Tokenizer  Encapsulate credentials as a security token for reuse (e.g., SAML, Kerberos).
  • Assertion Builder – Define processing logic for identity, authorization and attribute statements.
  • User Role – Identifies the role asserted by the individual initiating the transaction.
  • Purpose of Use – Identifies the purpose for the transaction.

 

Interoperability Need: Allows a Pharmacy to Notify a Prescriber of Prescription Fill Status

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 2
Yes
$
Yes
Implementation Specification
Final
Feedback requested
Feedback Requested
Yes

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Please refer to CMS.gov for more information regarding Medicare Part D electronic prescribing requirements and sign up to receive the latest announcements.
  • The following transactions need to be implemented for interoperability purposes:
    • NCPDP SCRIPT 2017071 -
      • RxFill: sent from a pharmacy to a prescriber or long-term or post-acute care (LTPAC) facility indicating the FillStatus (dispensed, partially dispensed, not dispensed or returned to stock, transferred to another pharmacy) of the new, refill or resupply prescriptions for a patent.
      • RxFillIndicator: Informs the pharmacy of the prescriber’s intent for fill status notifications for a specific patient/medication.
      • RxFillIndicatorChange: Sent by the prescriber to the pharmacy to indicate that the prescriber is changing the types of RxFill transactions that were previously requested, where the prescriber may modify the fill status of transactions previously selected or cancel future RxFill transactions.
      • When transferring a prescription, the RxFillRequestIndicator should be passed to the new pharmacy as part of the prescription information. If it supports the RxFill transaction, the pharmacy to which the prescription was transferred is responsible to send the appropriate Physician RxFill Request Flag with each subsequent dispensing event.
  • The prescriber must electronically send the prescription via the NCPDP SCRIPT standard in order for the prescriber’s system to receive RxFill transactions and ensures the correct matching between the original prescription and the subsequent RxFill transactions.
  • Adoption of RxFill may be improved by allowing prescribers to specify which prescriptions are to receive RxFill transactions and which RxFill message types to receive. Additionally, prescribers may choose to receive RxFill transactions for patients receiving certain medications. EMRs may also provide additional capabilities to support RxFill message handling and prescriber preferred notifications that may provide process improvements such as limiting the number of transactions received, the cost of transactions, privacy concerns and information overload.
  • Both the pharmacy and the prescriber must have their systems configured for the transaction in order to facilitate successful exchange, including the ability to send or receive verify, status, or error transactions.
  • Secure Communication – Create a secure channel for client-to- server and server-to-server communication.
  • Secure Message Router – Securely route and enforce policy on inbound and outbound messages without interruption of delivery.
  • Authentication Enforcer – Centralized authentication processes.
  • Authorization Enforcer – Specifies access control policies.
  • Credential Tokenizer – Encapsulate credentials as a security token for reuse (e.g., SAML, Kerberos).
  • Assertion Builder – Define processing logic for identity, authorization and attribute statements.
  • User Role – Identifies the role asserted by the individual initiating the transaction.
  • Purpose of Use – Identifies the purpose for the transaction.

 

Interoperability Need: Allows a Pharmacy to Request a Change to a Prescription

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification