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
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 to receive the latest announcements.
  • The following transactions need to be implemented for interoperability purposes:
    • NCPDP SCRIPT 2017071 -
      • RxChangeRequest, originated from the pharmacy to request:
        • A change in the original prescription (new or fillable).
        • Validation of prescriber credentials.
        • A prescriber to review the drug requested.
        • Prior authorization from the payer for the prescription.
      • FollowUpRequest, originated from the pharmacy to:
        • Notify prescribers that this is a follow-up RxRenewalRequest or RxChangeRequest transaction, when the prescriber has not responded to the first RxRenewalRequest or first RxChangeRequest transaction in a reasonable amount of time.
        • Not sent on the original request of the RxRenewalRequest or RxChangeRequest transaction.
      • RxChangeResponse, originated from the prescriber to respond:
        • To a prescription change request from a pharmacy.
        • To a request for a prior authorization from a pharmacy.
        • To a prescriber credential validation request from a pharmacy.
      • Options allowed when generating an RxChangeResponse in response to an RxChangeRequest from a pharmacy:
        • Approved: Grant the RxChangeRequest when the prescriber concurs with the request. The prescriber must submit an RxChangeResponse equal to what the pharmacy requested.
        • ApprovedWithChanges: When the information submitted in the RxChangeRequest does not include all elements constituting a fillable prescription; the prescriber should include all information.
        • Denied: Denies the RxChangeRequest with information that explains the denial.
        • Validated: Sent by the prescriber system in response to an RxChangeRequest for prescriber authorization.
  • When drug allergies and/or drug-drug interactions initiate a prescription change request, best practice is to alert the ordering provider and the pharmacy so that they may document these events in their respective systems for future error avoidance.
  • The receiving pharmacy should handle Approved, ApprovedWithChanges, and Validated responses as a fillable NewRx where the original linked prescription/order is discontinued. A Denied response should be directed to a review queue where the Denial reason code is displayed.
  • 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 New Prescription for a New Course of Therapy or to Continue Therapy

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 1
Yes
$
Yes
Implementation Specification
Final
Feedback requested
Feedback Requested
No
Free
No
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:
    • SCRIPT 2017071 -
      • NewRxRequest: This transaction is a request from a pharmacy to a prescriber for a new prescription for a patient
        • NewRxResponseDenied: This transaction is a denied response to a previously sent NewRxRequest (If approved, a NewRx would be sent)
          • A NewRxResponseDenied response may occur when the NewRxRequest cannot be processed or if information is unavailable 
  • 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 Request Additional Refills

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 5
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:
    • SCRIPT 2017071 -
      • RxRenewalRequest, originated from the pharmacy to request additional refills beyond those originally prescribed. (Within the RxRenewalRequest) FollowUpRequest, originated from the pharmacy to: 
        • Notify prescribers that this is a follow-up RxRenewalRequest or RxChangeRequest transaction, when the prescriber has not responded to the first RxRenewalRequest or first RxChangeRequest transaction in a reasonable amount of time.
        • Not sent on the original request of the RxRenewalRequest or RxChangeRequest transaction.
        • RxRenewalResponse, originated from the prescriber to respond to the request.
      • Options allowed when generating an RxRenewalResponse to an RxRenewalRequest from a pharmacy:
        • Approved: Grant the RxRenewalRequest as requested by the pharmacy, or, when the pharmacy does not request a specific number of fills (PharmacyRequestedRefills is not present) and the prescriber approves any number of fills.
        • ApprovedWithChanges: Grant the RxRenewalRequest, approving a NumberOfRefills different than the number requested by the pharmacy or when the information submitted in the RxRenewalRequest does not include all elements constituting a fillable prescription; the prescriber should include all information.
        • Denied: Deny the RxRenewalRequest as requested by the pharmacy.
        • In a Denied response, the only new meaning that should be conveyed to the pharmacy is information that explains the denial. It is recommended that the prescribing software update the NumberOfRefills to zero and leave all other data as is in the RxRenewalResponse.
        • Replace: Data is allowed to be changed except the patient DateOfBirth. If patient DateOfBirth changes, a Denied response would be sent, and then a NewRx would follow.
        • The receiving pharmacy might handle each of these responses differently. Approved, ApprovedWithChanges, and Replace responses might be directed to a fulfillment queue, where a Denied response might be directed to a review queue.
        • The Replace response should be used if there are any changes beyond what is outlined in the Response Element.
      • RxRenewalRequest should never be responded to with a NewRx, as this would result in duplicate valid prescriptions.
  • 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, Respond to or Confirm a Prescription Transfer

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 1
No
$
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:
    • RxTransferRequest: Used when the pharmacy is asking for a transfer of one or more prescriptions for a specific patient to the requesting pharmacy.
      • The transfer is for a fillable prescription which may be:
        • Yet to be filled.
        • On hold.
        • Open (active) fills.
        • Current therapy (defined as drug therapy that, based upon the most recent fill date, quantity and instructions, should still be active).
        • Allowed to be transferred by law/regulation.
      • If multiple specific prescriptions are to be transferred, but not all prescriptions, a separate RxTransferRequest must be sent for each specific prescription.
    • RxTransferResponse: The response from the transferring pharmacy to the requesting pharmacy to the RxTransferRequest, which includes the prescription(s) being transferred or a rejection of the transfer request.
    • RxTransferConfirm: Used by the pharmacy receiving (originally requesting) the transfer to confirm that the transfer prescription has been received and the transfer is complete.
  • The RxFill Transaction <FillStatus><Transferred> is originated by the transferring pharmacy once the <RxTransferConfirm> is received from the transfer to pharmacy. This transaction is used to notify the prescriber when a prescription has been transferred to another pharmacy and can no longer be filled at the original pharmacy. The RxTransfer transaction will identify if the receiving pharmacy supports RxFill.
  • Both pharmacies 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 Prescriber or a Pharmacy to Request a Patient’s Medication History

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 4
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:
    • RxHistoryRequest: a request from a prescriber or a pharmacy for a list of medications that have been prescribed, dispensed, claimed or indicated (OTCs) by a patient.
      • This patient-specific transaction supplies enough information to uniquely identify the patient.
    • RxHistoryResponse: A response to an RxHistoryRequest containing a patient’s medication history; includes the medications that were dispensed or obtained within a certain timeframe, and also optionally includes the prescriber's name.
      • The receiver must evaluate the Consent for accurate reporting.
      • Returns with loops of Medication, HistorySource, Prescriber, Pharmacy, and Patient elements when appropriate.
      • HistorySource and FillNumber elements are included, when appropriate, so prescribers are able to de-duplicate records from multiple sources that reflect the same medication dispensing, and to help determine patient compliance with a prescription.
        • Helps the prescriber determine if follow-up contact is required regarding the medication records.
  • RxHistoryRequest and RxHistoryResponse may be sent directly or through an intermediary.
  • Medication history transactions may be exchanged among prescribers, pharmacies, or payers, and may include adjudicated claims and/or pharmacy dispensed/point of sale prescription information.
  • It is recommended that prescribers request Medication History from all applicable sources, whenever appropriate, to ensure the most complete view of a patient’s medication history. The Medication History may be reconciled with the prescriber’s patient record for improved medication management and to assist in clinical decision support.

  • Both the sender and receiver 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. This may also include hospitals and/or Accountable Care Organizations (ACOs). 
  • 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 Prescriber to Cancel a Prescription

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 4
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 -
      • CancelRx: a request from the prescriber to the pharmacy to not fill a previously sent prescription.
        • Must contain pertinent information for the pharmacy to be able to find the prescription in their system (patient, medication (name, strength, dosage form, prescriber, prescription number if available).
        • Changes can be indicated in the MessageRequestCode in the CancelRx transaction.
      • CancelRxResponse: a response from the pharmacy to the prescriber to acknowledge a CancelRx.
        • Used to denote if the cancellation is Approved or Denied.
        • DenialReasonCode should be sent when a CancelRx is denied.
      • When a Long-Term Care (LTC) prescriber has the need to modify an order and notify the pharmacy, the prescriber system will always send a CancelRx and a NewRx, regardless of the type of change.
  • 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 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 Prescriber to Communicate Drug Administration Events

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 1
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 NCPDP SCRIPT Version 2017071 Implementation Guide supports the DrugAdministration transaction communicates drug administration events from a prescriber/care facility to the pharmacy or other entity. It is a notification from a prescriber/care facility to a pharmacy or other entity that a drug administration event has occurred - for example, a medication was suspended or administration was resumed.
  • 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 Prescriber to Communicate with a REMS Administrator

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 1
No
$
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 NCPDP SCRIPT Version 2017071 Implementation Guide supports:
    • REMSInitiationRequest and REMSInitiationResponse
    • REMSRequest and REMSResponse
  • Each transaction supports a particular step in the REMS process:
    • The REMSInitiationRequest transaction is used by the prescriber to initiate the REMS process, by notifying the REMS Administrator of the patient and the medication for which REMS authorization is being requested, along with the prescriber’s information and other related details.
    • In the REMSInitiationResponse transaction, the REMS Administrator indicates the information needed from the prescriber to determine approval or denial of the authorization. In some cases, the REMS Administrator indicates to the prescriber that REMS authorization is not required for the requested medication and patient. The REMSInitiationResponse is for the medication (name, strength, dosage form) indicated in the REMSInitiationRequest. The REMS Administrator should not respond for an equivalent to the medication (e.g., generic product equivalent to brand product) indicated in the REMSInitiationRequest.
    • The prescriber system gathers the requested information by presenting questions for the prescriber to answer and/or by extracting information from the patient’s electronic medical record using the coded references associated to the question. The information is sent to the REMS Administrator in the REMSRequest transaction. This occurs in both the solicited and unsolicited models.
    • The REMS Administrator determines whether authorization can be granted and provides the determination to the prescriber in the REMSResponse transaction. In some cases the REMSResponse transaction may indicate the REMS Administrator needs additional information in order to make a determination.
  • The Food and Drug Administration Amendments Act (FDAAA) of 2007 (Public Law 110-85) enables the Food and Drug Administration (FDA) to require a REMS from a pharmaceutical manufacturer if the FDA determines that a REMS is necessary to ensure the benefits of a drug outweigh the risks associated with the drug. The currently approved REMS programs vary in levels of complexity. Typically, a Med Guide and Communication Plan is required, but some also require Elements to Assure Safe Use (ETASU). The large majority of existing REMS programs are for drugs dispensed through specialty pharmacies, clinics, and hospitals, but as REMS become more common, they may ultimately have a greater impact on retail-based products.
  • The impact of REMS is twofold. First, REMS with ETASU may require the pharmacist to verify prescriber, patient, and/or pharmacy enrollment in a registry and, in some cases, verify or check certain information, such as laboratory results. Second, all REMS, including those without ETASU, must fulfill FDA-approved reporting requirements. Each REMS program must also include a program assessment schedule that examines the program’s effectiveness on intervals approved by the FDA as part of the overall REMS program. The results of these assessments are submitted to the FDA as part of the ongoing evaluation of REMS program effectiveness. 
  • Both the prescriber and the REMS Administrator 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 Prescriber to Prescribe Medication Using Weight-Based Dosing

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • Please refer to CMS.gov for more information regarding Medicare Part D electronic prescribing requirements and sign up to receive the latest announcements.
  • Included in the Structured and Codified Sig Format of electronic prescribing transactions are elements, fields and values that are directly related to the prescriber's instructions for use.
  • The following elements of the Sig are required when Structured Sig is sent:
    • Code system
    • Dose
    • Route Of Administration
  • The following elements of the Sig are conditional (only required when prescriber specifies) when Structured Sig is sent:
    • Vehicle
    • Site of Administration
    • Timing
    • Duration
    • Maximum Dose Restriction
    • Indication
  • The following elements of the Sig are required when Structured Sig is sent and when dose is to be calculated:
    • Dose Calculation:
      • Used where a body metric such as metric weight (kg) or surface area (m*2) is used to calculate a dose for a patient.
      • May often be used in conjunction with the Rate within TimingAndDuration and/or the Vehicle.
  • The SCRIPT 2017071 Observation element in the NewRx transaction supports the use of a patient's height, weight and other vital signs:
    • Inclusion of VitalSign (most recent patient's height and weight) and ObservationDate (YYYY-MM-DD height and weight observed/taken) is required for patients 18 years old and younger on all new and renewal prescriptions from a prescriber to a pharmacy.
      • If the height and/or weight have changed and a prescriber is sending an approved renewal response, the response should be coded as Approved with Changes.
    • ObservationDate is now mandatory when Observation Segment Measurement is sent.
    • ObservationNotes may contain other pertinent information pertaining to weight-based calculations.
  • It is recommended that developers adopt logic that results in a prescription that calculates a weight-based dose to suggest a measurable dose (e.g., rounded to the +/- 5-10% of the calculated dose). Measurable dose should be based on home dosing tool precision. For example, a weight-based dose calculation may result in instructions to give a child 4.7mL amoxicillin 400mg//5mL (375mg) when the measurable dose should be 5mL (400 mg is still a safe dose and easier to measure with a 5mL or 10mL oral syringe).
  • 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.

 

Interoperability Need: Allows a Prescriber to Recertify the Continued Administration of a Medication Order

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 1
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 NCPDP SCRIPT Version 2017071 Implementation Guide supports the Recertification transaction; a notification from a facility, on behalf of a prescriber, to a pharmacy recertifying the continued administration of a medication order. An example use is when an existing medication order has been recertified by the prescriber for continued use. Long term or post-acute care use only.
  • 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 Prescriber to Request, Cancel or Appeal Prior Authorization for Medications

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Some of these standards can be used to support workflows for electronic prior authorization, but do not independently enable a prescriber to request, cancel, or appeal prior authorization for medications without the assistance of other standards and technologies.
  • The prescriber system must receive timely Formulary & Benefit file updates from payers/intermediaries, giving group-level formulary and coverage information (including PA flags) for use when ordering medications.
  • The following ASC X12 patient eligibility transactions enhance the PA Request transactions by supplying the prescriber system with the patient’s pharmacy benefit information, and need to be implemented for interoperability purposes:
    • Eligibility Request (ASC X12 270)
    • Eligibility Response (ASC X12 271)  
  • The following NCPDP SCRIPT 2017071 and 2022011 prior authorization transactions need to be implemented for interoperability purposes:
    • PAInitiationRequest and PAInitiationResponse
    • PARequest and PAResponse
    • PAAppealRequest and PAAppealResponse
    • PACancelRequest and PACancelResponse
    • PANotification (only in NCPDP SCRIPT 2022011)
  • Both the prescriber and the payer/processor/pharmacy benefits manager (PBM) must have their systems configured for these transactions in order to facilitate successful exchange, including the ability to send or receive status or error messages.
  • 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 Prescriber to Send a New Prescription to a Pharmacy

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 5
Yes
$
Yes
Implementation Specification
Final
Production
Rating 1
No
$
N/A
Implementation Specification
Final
Feedback requested
Feedback Requested
No
Free
No
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 -
      • NewRx: This transaction is a new prescription sent from the prescriber to the pharmacy electronically so that it can be dispensed to a patient.
      • NewRxRequest: This transaction is a request from a pharmacy to a prescriber for a new prescription for a patient.
        • NewRxResponseDenied: This transaction is a denied response to a previously sent NewRxRequest (If approved, a NewRx would be sent).
          • A NewRxResponseDenied response may occur when the NewRxRequest cannot be processed or if information is unavailable. 
  • 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 Prescriber to Send a Prescription to a Pharmacy for a Controlled Substance

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The following transactions need to be implemented for interoperability purposes:
  • 21 CFR §1311 implements US Drug Enforcement Administration's Electronic Prescription for Controlled Substance regulation. 
  • DEA's EPCS requires additional information satisfied by the following SCRIPT 10.6 elements:
    • Digital Signature Indicator - Use Drug Coverage Status Code - "SI - Signed Prescription".
    • Controlled Substance Indicator - Use DEA Schedule Field to indicate the controlled substance schedule class.
    • Earliest Fill Date - Use Date/Time/Period Qualifier- value= "07 - Effective Date (Begin)".
    • Drug Abuse Treatment Identifier - Use DRU Segment Ø9Ø Free Text - value= “NADEAN:xxxxxxxxx” (Narcotics Addiction DEA Number)".
    • Medication Indication for GHB (Gamma-Hydroxybutyric acid) - Use DRU Segment Ø9Ø Free Text - value="medical need for GHB".
  • The SUPPORT for Patients and Communities Act, once implemented, will require a prescription for a Medicare part D drug be transmitted electronically using NCPDP SCRIPT 10.6, or the latest implemented version.
  • Please note that the NCPDP electronic prescribing test tool currently tests the capabilities of any health IT to conform to the ONC Health IT Certification Program criterion 170.315 (b)(3), but does not test system capabilities to conform to DEA EPCS certification requirements. 
  • 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.

The  DEA's EPCS regulation, 21 CFR §1311, requires additional security considerations that:

  • An individual practitioner must obtain an authentication credential from a credential service provider or certification authority using two of the following three factors:
    • Something only the practitioner knows, such as a password or response to a challenge question.
    • Something the practitioner is, biometric data such as a fingerprint or iris scan.
    • Something the practitioner has, a device (hard token) separate from the computer to which the practitioner is gaining access.
  • The practitioner must submit identity proofing information to the credential service provider or certification authority.
  • The electronic prescription application must be capable of the setting of logical access controls to limit permissions for certain functions.

 

Interoperability Need: Allows a Provider to Request a Patient’s Medication History from a State Prescription Drug Monitoring Program (PDMP)

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 4
No
Free
No
Standard
Final
Production
Rating 3
No
Free
Yes
Standard
Final
Production
Rating 2
No
Free
Yes
Implementation Specification
Final
Production
Rating 2
No
$
No
Standard
Final
Production
Feedback Requested
No
Free
No
Implementation Specification
Balloted Draft
Pilot
Feedback Requested
No
Free
No
Implementation Specification
Final
Feedback requested
Feedback Requested
Yes
Emerging Standard
Final
Production
Feedback Requested
No
Free
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 NCPDP SCRIPT transactions need to be implemented for interoperability purposes:
    • RxHistoryRequest: a request from a prescriber for a list of medications that have been prescribed, dispensed, claimed or indicated (OTCs) by a patient to a state Prescription Drug Monitoring Program (PDMP).
      • This patient-specific transaction supplies enough information to uniquely identify the patient.
    • RxHistoryResponse: a response from a PDMP to an RxHistoryRequest containing a patient’s medication history; includes the medications that were dispensed or obtained within a certain timeframe, optionally it includes the prescriber's name.
      • PDMP must evaluate the Consent for accurate reporting.
      • Returns with loops of Medication, HistorySource (pharmacy), Prescriber, Pharmacy, and Patient elements.
      • HistorySource and FillNumber elements are included, when appropriate, so prescribers are able to de-duplicate records from multiple sources that reflect the same medication dispensing, and to help determine patient compliance with a prescription.
        • Helps the prescriber determine if follow-up contact is required regarding the medication records.
  • The medication history response transaction in SCRIPT Version 2017071 has been enhanced to return data from Prescription Drug Monitoring Program (PDMP) administrators.
  • Please note that the NCPDP electronic prescribing test tool does not currently test the capabilities of any health IT to exchange data with a state PDMP. 
  • RxHistoryRequest and RxHistoryResponse may be sent directly or through an intermediary. 
  • Both the prescriber and the Prescription Monitoring Drug Program (PDMP) must have their systems configured for the transaction in order to facilitate successful exchange, including the ability to send or receive status, or error transactions.
  • The HL7 FHIR Implementation Guide: US Meds STU2 includes US Meds Prescription Drug Monitoring Program (PDMP) mapping.
  • SMART on FHIR defines a mechanism for interoperable “SMART Apps” that can be plugged in to EHRs and other Health IT systems. Each SMART App can expose a user interaction and can access data in the underlying system.  This presents a powerful way to extend EHR capabilities via “pluggable” app functionality. Dozens of SMART apps are available, including apps for medication management, pain management, and PDMP-EHR integration, with more expected in the future. These apps serve many different clinical needs, yet they all use the same underlying FHIR-based API functionality.
  • When using the SMART on FHIR model, the authentication model uses OAuth2. Except for "Secure Communication", the security patterns listed do not apply.
  • The HL7 FHIR® SMART Application Launch Framework Implementation Guide Release 2.0.0 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).

* PMIX is not an ANSI-Accredited Standards Developer. For more information, see www.ansi.org.  

  • 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 for Communication of Prescription Information Between Prescribers and Dispensers

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 5
Yes
$
Yes
Implementation Specification
Final
Production
Rating 1
No
$
N/A
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 NCPDP SCRIPT Version 2017071 Implementation Guide supports the following transactions:
    • Ask the Mailbox if there are any transactions (GetMessage)
      • This transaction is used by the prescriber or pharmacy asking the mailbox if there are any transactions. It is at the heart of the mechanism used by a pharmacy or prescriber system to receive transactions from each other or from a payer or the Risk Evaluation and Mitigation Strategy (REMS) Administrator via a Switch, acting as a Mailbox. Please note that the adoption level of the GetMessage transaction is not reflected above. GetMessage transaction adoption is currently lower than that of the other communication transactions below (Status, Error, and Verify). 
    • Relay acceptance of a transaction back to the sender (Status)
      • This transaction is used to relay acceptance of a transaction back to the sender. A Status in response to any applicable transaction other than GetMessage indicates acceptance and responsibility for a request. A Status in response to GetMessage indicates that no mail is waiting for pickup. A Status cannot be mailboxed and may not contain an error.
    • Respond that there was a problem with the transaction (Error)
      • This transaction indicates an error has occurred, indicating the request was terminated. An Error can be generated when there is a communication problem or when the transaction actually had an error. An error can be mailboxed, as it may be signifying to the originator that a transaction was unable to be delivered or encountered problems in the acceptance. The Error must be a different response than a Status, since the communication between the system and the Mailbox must clearly denote the actions taking place. An Error is a response being delivered on behalf of a previous transaction, and the Status signifies no more mail.
    • Respond that a transaction requesting a return receipt has been received (Verify)
      • This transaction is a response to a pharmacy or prescriber indicating that a transaction requesting a return receipt has been received. Verifications results when a “return receipt requested” flag is set in the original request. Upon receiving a transaction with ReturnReceipt set, it is the responsibility of the receiver to either generate a Verify in response to the request (recommended) or generate a Status in response to this request, followed subsequently by a free standing Verify. This transaction notifies the originator that the transaction was received at the software system. It is not a notification of action taking place, since time may elapse before the ultimate answer to the transaction may take place.
  • 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 for the Exchange of State Prescription Drug Monitoring Program (PDMP) Data

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 5
No
Free
No
Standard
Final
Production
Rating 4
No
Free
No
Standard
Final
Production
Rating 3
No
Free
No
Implementation Specification
Final
Production
Rating 5
No
Free
No
Standard
Final
Production
Rating 3
No
Free
No
Standard
Final
Production
Feedback Requested
No
Free
No
Standard
Final
Production
Feedback Requested
No
$
No
Standard
Final
Pilot
Feedback Requested
No
Free
No
Implementation Specification
Final
Production
Rating 1
No
$
No
Implementation Specification
Final
Production
Feedback Requested
No
$
No
Implementation Specification
Balloted Draft
Pilot
Feedback Requested
No
Free
No
Implementation Specification
Final
Feedback requested
Feedback Requested
Yes
Implementation Specification
Final
Pilot
Feedback Requested
No
$
No
Implementation Specification
Final
Production
Feedback Requested
No
$

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • National Drug Code (NDC)

    • The use of NDC in conjunction with RxNorm can help minimize gaps in representing medications, including compounded products, over -the-counter medications, and herbals.

  • RxNorm

    • RxNorm is often used for the exchange of information; however, it may not be available for export and import by end users.

  • RxNav

    • NDC mappings are available through RxNorm via RxNav.

  • Please note that many of the standards, emerging standards, and implementation specifications outlined above are specific to the in-state and interstate exchange of PDMP data. See the PDMP query ISA page for a working list of standards, emerging standards, and implementation specifications specific to a provider's ability to query a PDMP from health information technology such as an EHR.

  • Data may be exchanged directly or through an intermediary. Prescribers, Dispensers, Prescription Monitoring Drug Program (PDMPs), and other intermediaries and endpoints must have their systems configured for the transaction in order to facilitate successful exchange, including the ability to send or receive status, or error transactions.

  • If a state PDMP requests either ASAP 4.2, 4.2A, or 4.2B, these versions of the standard includes the Zero Reports and Error Reports standard. ASAP 4.2, 4.2A, 4.2B, and the Zero Reports and Error Reports are also available as separate standards.

  • All of the ASAP standards are free to non-commercial and non-profit entities such as state PDMPs. 

  • The HL7 FHIR Implementation Guide: US Meds STU2 includes US Meds Prescription Drug Monitoring Program (PDMP) standards mapping.

* PMIX is not an ANSI-Accredited Standards Developer. For more information, see www.ansi.org.  

  • 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 Pharmacy Benefit Payers to Communicate Formulary and Benefit Information to Prescriber Systems

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Feedback requested.
  • 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.

 

Public Health Reporting

Interoperability Need: Adverse Event Reporting

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
  • Feedback requested.
  • Feedback requested.

 

Interoperability Need: Case Reporting to Public Health Agencies

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Electronic Initial Case Report (eICR) and the Reportability Response are paired together in production implementations to build a complete workflow.
  • Electronic case reporting involves reporting to State, Tribal, Local, and Territorial public health authorities. Electronic case reporting is implemented widely.
  • Some additional implementation guides related to public health reporting follow. Reporting is often captured under a specialized registry with associated standards when not specified as a separate measure. These include:
  • 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.
  • Direct is used as the transport for performing an unsolicited push for Case Reporting to Public Health Agencies in some jurisdictions. See An Unsolicited "Push" of Clinical Health Information to a Known Destination Between Systems
  • The Applicability Statement for Secure Health Transport Version 1.3 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).
  • 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.
  • FHIR Security Labels support compliance with laws, policies, and consent directives governing HIPAA PHI and specially protected information (SPI).

 

Interoperability Need: Data Submission for Title X Family Planning Annual Reporting

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
Implementation Specification
Balloted Draft
Production
Feedback Requested
No

 

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

 

Interoperability Need: Electronic Transmission of Reportable Laboratory Results to Public Health Agencies

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • Stakeholders should refer to the health department in their state or local jurisdiction to determine onboarding procedures, obtain a jurisdictional implementation guide if applicable, and determine which transport methods are acceptable for submitting ELR as there may be jurisdictional variation or requirements.
  • While the names differ, please note the content of the Electronic Laboratory Reporting (ELR)  implementation specification listed above is now handled as a profile in the Laboratory Results Interface (LRI) implementation specification, using the “LRI_PH_COMPONENT – ID: 2.16.840.1.113883.9.195.3.5” Result Profile Component. 
  • Where appropriate, EHRs should consider reporting required public health information directly to public health agencies (PHA) using eCR (electronic case reporting) standards or other appropriate standard from the ISA section “Case Reporting to Public Health Agencies".
  • See FHIR US Lab Report, an emerging standard for electronic lab reporting.

 

Interoperability Need: Exchanging Immunization Data with Immunization Registries

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • 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: Newborn Screening Results and Birth Defect Reporting to Public Health Agencies

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 3
No
Free
No
Implementation Specification
Final
Production
Rating 1
No
Free
Yes
Implementation Specification
Final
Production
Rating 1
No
Free
Yes
Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
No
Emerging Implementation Specification
In Development
Pilot
Feedback Requested
No
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Use of the listed test tool for "Ambulatory Healthcare Provider Reporting to Birth Defect Registries" requires digital certificates. Contact MBDR.Help@altarum.org for digital certification information.
  • There is current work to update the listed "ambulatory" implementation guides to include hospital reporting capabilities and Zika-related information.
  • The "Newborn Admission Notification Information (NANI)" is included here because its functionality directly supports other standards under this heading.
  • HL7 Version 2.5.1 Implementation Guide: Laboratory Orders (LOI) from EHR, Release 1, STU Release 3 and HL7 Version 2.5.1 Implementation Guide: Laboratory Results Interface, Release 1 STU Release contain profiles for newborn dried blood spot testing.
  • Feedback requested.

 

Interoperability Need: Reporting Antimicrobial Use and Resistance Information to Public Health Agencies

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • This is a national reporting system to CDC. Stakeholders should refer to the National Healthcare Safety Network (NHSN) at: https://www.cdc.gov/nhsn/cdaportal/meaningfuluse.html for information on participation.
  • Release 1 of the Healthcare Associated Infections IG is normative and used in ASTP certification. While there are more current releases of the Healthcare Associated Infection Reports IG, they are not valid for AU or AR submissions to NHSN.  These newer releases can be found at the same link as Release 1.
  • The HL7 CDA R2 Implementation Guide: Healthcare Associated Infection (HAI) Reports, Release 3 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).
  • 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: Reporting Birth and Fetal Death to Public Health Agencies

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • State vital records offices have been working with The National Center for Health Statistics (NCHS) to implement FHIR for birth and fetal death reporting. The balloted version of the HL7 Birth and Fetal Death FHIR Implementation Guide 2.0 - STU 2 is supporting this effort.
  • Active pilot project reporting births from an EHR to a jurisdiction is currently underway using the BFDR FHIR IG 1.1 and SMART on FHIR.

    The following standards have been deprecated:

  • HL7 Version 2.6 Implementation Guide: Birth and Fetal Death Reporting, Release 1 STU Release 2 (US Realm - Standard for Trial Use)
  • HL7 CDA® R2 Implementation Guide: Birth and Fetal Death Reporting, Release 1, STU Release 2 - US Realm
  • Feedback requested. 

 

Interoperability Need: Reporting Cancer Cases to Public Health Agencies

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Stakeholders should refer to the health department in their state or local jurisdiction to determine onboarding procedures, obtain a jurisdictional implementation guide if applicable, and determine which transport methods are acceptable for submitting cancer reporting date as there may be jurisdictional variation or requirements. Some jurisdictions may not support cancer case reporting at this time.
  • Note that the NAACCR specification listed has not been vetted through a Voluntary Consensus Standards Body (VCSB), however it references the HL7 V 2.5.1 standard and LOINC, and has been sponsored by a number of organizations working in the cancer registry space.

  • The NAACCR standards are used by grantees funded by CDC’s National Program of Cancer Registries (NPCR). Additional detail on the NPCR standards, for both interoperability and programmatic requirements can be found here: https://www.cdc.gov/cancer/npcr/standards.htm.”

  • 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: Reporting Death Records to Public Health Agencies

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Since November 2023 The National Center for Health Statistics (NCHS) has been onboarding State vital records offices in FHIR This effort includes the transmission of FHIR messages using HL7 Vital Records Death Reporting (VRDR) FHIR Implementation Guide 2.2.0 - STU 2.
  • The following standards have been deprecated:
    • HL7 Version 2.6 Implementation Guide: Vital Records Death Reporting, Release 1 STU R2.1 - US Realm
    • HL7 CDA® R2 Implementation Guide: Vital Records Death Reporting, Release 1 STU 2.1 - US Realm
  • The HL7 Medicolegal Death Investigation (MDI) FHIR implementation guide (IG) provides guidance on the exchange of information with medical examiner and coroners offices. This guide provides MDI case management system developers with the technical details and best practices to standardize MDI fields and interfaces.
  • The Vital Records Common Library is a US Realm specific framework that provides common data elements between the birth and fetal death reporting and birth defects reporting FHIR® implementation guides. The purpose of this library is to avoid defining the same profiles multiple times within respective implementation guides.
  • Feedback requested. 

 

Interoperability Need: Reporting Syndromic Surveillance to Public Health (Emergency Department, Inpatient, and Urgent Care Settings)

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Stakeholders must refer to the health department in their state or local jurisdiction to determine onboarding procedures, obtain a jurisdictional implementation guide if applicable, and determine which transport methods are acceptable for submitting syndromic surveillance data as there may be jurisdictional variation or requirements.
  • The PHIN Messaging Guide for Syndromic Surveillance Release 2.0 and its errata are referenced in the 2015 Edition Health Information Technology (Health IT) Certification Criteria, 2015 Edition and are currently used for certification. In addition see the "NIST Clarifications and Validation Guidelines (Version 1.6)" listed above.
  • The PHIN Messaging Guide for Syndromic Surveillance Release 1.1 and its "testing clarification" document are referenced in the Health Information Technology: Standards, Implementation Specifications, and Certification Criteria for Electronic Health Record Technology, 2014 Edition and were previously used for certification.
  • Additional information can be found at the NSSP Resource Center.
  • 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 Health Care Survey Information to Public Health Agencies

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • 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.

 

Research

Interoperability Need: Data Collection for Submission to Registries and Reporting Authorities

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
Implementation Specification
Final
Production
Rating 1
No
Free
N/A

 

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

 

Interoperability Need: Prepopulation of Research Forms from Electronic Health Records

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
Standard
Final
Production
Rating 3
No
Free
N/A
Standard
Final
Production
Feedback Requested
No
Free
No
Standard
Balloted Draft
Pilot
Feedback Requested
No
Free
No
Implementation Specification
Final
Production
Rating 3
No
Free
N/A
Implementation Specification
Final
Production
Rating 2
No
Free
N/A
Implementation Specification
Final
Production
Rating 1
No
Free
N/A
Implementation Specification
Final
Pilot
Rating 1
No
Free
N/A
Implementation Specification
Balloted Draft
Production
Rating 2
No
Free
N/A
Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
N/A
Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
No
Emerging Standard
Balloted Draft
Production
Rating 3
No
Free
N/A
Emerging Standard
Balloted Draft
Pilot
Feedback Requested
No
Free
N/A
Emerging Standard
In Development
Pilot
Feedback Requested
No
Free
No
Emerging Standard
Balloted Draft
Pilot
Feedback Requested
No
Free
No
Emerging Standard
In Development
Feedback requested
Feedback Requested
No
Free
No
Emerging Standard
In Development
Feedback requested
Feedback Requested
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • 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.

 

Interoperability Need: Registering a Clinical Trial

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The CDISC Clinical Trial Registry (CTR-XML) is used internationally, but in the US, the primary area for registering Clinical Trials is via ClinicalTrials.gov.
  • CTR-XML standard is based on CDISC ODM. It is an extension of the ODM standard.
  • Feedback requested.

 

Interoperability Need: Submission of Clinical Research Data Contained in EHRs and Other Health IT Systems for General Purpose or Preserving Specific FDA Requirements

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Standard
Final
Production
Rating 5
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 1
No
Free
Yes
Standard
Final
Production
Rating 1
No
Free
N/A
Standard
Final
Production
Rating 1
No
Free
N/A
Standard
Final
Feedback requested
Feedback Requested
No
Free
No
Implementation Specification
Balloted Draft
Production
Rating 4
No
Free
N/A
Implementation Specification
Balloted Draft
Production
Rating 2
No
Free
N/A
Implementation Specification
Final
Feedback requested
Feedback Requested
No
Free
No
Implementation Specification
Final
Feedback requested
Feedback Requested
No
Free
No
Emerging Standard
Balloted Draft
Feedback requested
Feedback Requested
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Stakeholders should review 21CFR11 for more details.
  • Feedback requested.

 

Interoperability Need: Submission of Clinical Research Data to FDA to Support Product Marketing Applications

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

 

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

 

Interoperability Need: Submit Adverse Event Report from an Electronic Health Record to Drug Safety Regulators

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • MedDRA was created to manage clinical information about pharmaceuticals, biologics, vaccines and drug-device combinations for the entire lifespan of products. 
  • Feedback requested.

 

Security Tags for Sensitive Information

Interoperability Need: Security Tags for Sensitive Information

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
Standard
Final
Production
Rating 3
No
Free
Standard
Final
Production
Rating 3
No
Free
Implementation Specification
Final
Production
Rating 2
No
Free
Yes
Implementation Specification
Final
Pilot
Rating 1
No
Free
No
Implementation Specification
In Development
Pilot
Rating 2
No
Free
No
Standard
Final
Feedback requested
Feedback Requested
No
Free

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The 2015 Edition Cures Update Health IT Certification Criteria includes two optional criteria for Security Tags - Summary of Care (§ 170.315(b)(7) and § 170.315(b)(8)). Health IT certified to these criteria use the HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1.
  • HL7 FHIR v3 Implementation Guide for DS4P provides CDA® templates to enable privacy and segmentation markings at the document, section and entry (data element) levels:
    • CDA Privacy Markings Section - specifies how a document, section, or entry may be constrained to specify privacy and security markings.
    • CDA Privacy Segmented Section - may apply to any section of a C-CDA document if that section's metadata (sensitivity, confidentiality) is different than the metadata of the overall document.
    • Privacy Metadata Templates - support the exchange of protected information by annotating specific entries with several observations, policies and constraints. Examples include:
      • CDA Privacy Annotation - a set of security observations that allow for specific privacy metadata for an entry that overrides that of a document or section.
      • CDA Protected Problem - combines a mandatory provenance and privacy annotations with the default constraints applied to a ProblemObservation.
      • CDA Security Observation - a class of abstract templates to indicate a security classification, control, category, or integrity criterion. Subclasses include Obligation, Confidentiality, Refrain Policy, and Purpose-of-Use Security Observations.
  • US Realm CDA documents are required to include a Confidentiality code in the document header, taken from the HL7 BasicConfidentialityKind value set defined by the DS4P standard. Therefore, adoption levels may be higher for document-level tagging (vs. section level).
  • HL7 v2.9 adopted HL7 Healthcare Privacy and Security Classification System syntax for assigning security labels in the ARV (Access Restrictions), BHS (Batch Header), FHS (File Header), and MSH (Message Header) segments.
  • Feedback requested.
  • Additional information about security patterns can be found in Appendix 1.
  • ISO/IEC 27000 - Information security management systems
  • NIST SP 800-53 Rev. 5Security and Privacy Controls for Information Systems and Organizations

 

Summary Care Record

Interoperability Need: Support a Transition of Care or Referral to Another Health Care Provider

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 5
Yes
Free
Yes
Implementation Specification
Balloted Draft
Production
Rating 5
Yes
Free
Yes
Standard
Final
Production
Rating 5
No
Free
Yes
Emerging Implementation Specification
Balloted Draft
Pilot
Rating 2
No
Free
No
Implementation Specification
Final
Production
Rating 1
No
$
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
Implementation Specification
Balloted Draft
Feedback requested
Feedback Requested
No
Free
No
Implementation Specification
Final
Production
Rating 1
Yes
$
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • There are several specific document templates within the C-CDA implementation specification. Trading partners will need to ensure that their systems are capable of supporting specific document templates.
  • HL7 provides a C-CDA Example repository which contains a set of example C-CDA files that have undergone a review and vetting process to ensure completeness and rigor. 
  • The IHE 360X specification listed is designed to track and manage referrals across health IT platforms. 
  • The NCPDP Specialized Standard supports request/referral for Medication Therapy Management services. 
  • Implementers should explore use of emerging CDA on FHIR and C-CDA on FHIR to support this interoperability need. 
  • 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.

 

Unique Device Identification

Interoperability Need: Defining a Globally Unique Device Identifier

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
Implementation Specification
Final
Production
Rating 2
No
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Per the FDA, Unique Device Identification system will be phased in over several years, with the initial final compliance date of September 24, 2020. In an update published on June 30, 2020, FDA announced a Immediately in Effect Guidance for Industry and Food and Drug Administration Staff, updating its policy regarding compliance dates for class I and unclassified devices that are not implantable, life-supporting, or life-sustaining. The guidance explains that, at this time, the FDA does not intend to enforce UDI labeling (21 CFR 801.20 & 801.50), Direct Mark (21 CFR 801.45), GUDID Data Submission (21 CFR 830.300), and Standard Date Format (21 CFR 801.18) requirements before September 24, 2022.
  • Compliance date for UDI of implantable, life supporting and life sustaining devices was 9/24/2015.  These data are available at http://accessgudid.nlm.nih.gov.
  • The HL7 Harmonization Pattern for UDIs is currently in development, with the next revision release anticipated in February 2018.
  •  Feedback requested.

 

Interoperability Need: Representing Unique Implantable Device Identifiers

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
Feedback Requested
No
$
Standard
Final
Production
Feedback Requested
No
$
Yes
Implementation Specification
Final
Production
Rating 2
No
Free
N/A
Implementation Specification
Final
Production
Feedback Requested
No
$
No
Emerging Implementation Specification
In Development
Feedback requested
Feedback Requested
No
Free
No
Emerging Implementation Specification
Balloted Draft
Production
Feedback Requested
No
Free
Implementation Specification
Final
Feedback requested
Feedback Requested
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Per the FDA, Unique Device Identification system will be phased in over several years, with the initial final compliance date of September 24, 2020. In an update published on June 30, 2020, FDA announced a Immediately in Effect Guidance for Industry and Food and Drug Administration Staff, updating its policy regarding compliance dates for class I and unclassified devices that are not implantable, life-supporting, or life-sustaining. The guidance explains that, at this time, the FDA does not intend to enforce UDI labeling (21 CFR 801.20 & 801.50), Direct Mark (21 CFR 801.45), GUDID Data Submission (21 CFR 830.300), and Standard Date Format (21 CFR 801.18) requirements before September 24, 2022.
  • Compliance date for UDI of implantable, life supporting and life sustaining devices was 9/24/2015.  These data are available at http://accessgudid.nlm.nih.gov.
  • HL7 Cross-Paradigm Implementation Guide: UDI Pattern, Release 1 - will be updated with HL7 FHIR Releases.
  •  Feedback requested.

 

Interoperability Need: Transmitting a Unique Device Identifier

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
Implementation Specification
Final
Production
Rating 2
No
Free
N/A
Implementation Specification
Final
Pilot
Feedback Requested
No
$
No
Implementation Specification
Final
Pilot
Rating 1
Yes
$
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Per the FDA, Unique Device Identification system will be phased in over several years, with the initial final compliance date of September 24, 2020. In an update published on June 30, 2020, FDA announced a Immediately in Effect Guidance for Industry and Food and Drug Administration Staff, updating its policy regarding compliance dates for class I and unclassified devices that are not implantable, life-supporting, or life-sustaining. The guidance explains that, at this time, the FDA does not intend to enforce UDI labeling (21 CFR 801.20 & 801.50), Direct Mark (21 CFR 801.45), GUDID Data Submission (21 CFR 830.300), and Standard Date Format (21 CFR 801.18) requirements before September 24, 2022.
  • Compliance date for UDI of implantable, life supporting and life sustaining devices was 9/24/2015.  These data are available at http://accessgudid.nlm.nih.gov.
  • The HL7 Harmonization Pattern for UDIs is currently in development, with the next revision release anticipated in February 2018.
  • Support of the full length of the UDI-DI will be available in the NCPDP SCRIPT Standard Implementation Guide, Version 2017071, and the NCPDP Telecommunication Standard Implementation Guide, Version F6. Today, these numbers are reformatted to support the field size limitations.
  • Feedback requested.

 

Work Information

Interoperability Need: Work Information Templates

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
Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
Yes
Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
Yes

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • These standards are intended to transmit data that are part of the medical record and must be protected accordingly.

 

Services/Exchange

“Push” Exchange

Interoperability Need: An Unsolicited "Push" of Clinical Health Information to a Known Destination and Information System User

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • This interoperability need also includes transport for the following purposes, primarily using the Direct Standard: The Direct Standard is based upon the underlying Simple Mail Transfer Protocol (SMTP) RFC 5321 and for security uses Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification, RFC 5751.
    • Transport for Transition of Care or Referral to Another Health Care Provider.
    • Transport for a Notification of a Patient’s Admission, Discharge and/or Transfer Status to Other Providers.
  • For Direct, interoperability may depend on establishing “trust” between two parties and vary based on the trust community(ies) to which parties belong. DirectTrust is a trust community which facilitates Direct communication among users for provider messaging and consumer-mediated exchange.
  • The Direct Standard was approved as American National Standard ANSI/DS 2019-01-100-2021-Applicability Statement for Secure Health Transport Version 1.3.
  • The ITU implementation specifications are Continual Design Guidelines, developed to provide a suite of open industry standards and specifications that provide several means to end-to-end interoperability between personal medical devices and health information systems.  Unrestricted access to the implementation specification: http://www.pchalliance.org/continua-design-guidelines .
  • The DirectTrust Trusted Instant Messaging Plus standard provides secure instantaneous communication via the XMPP standard between servers allowing for federated trust communities and cross-platform communication. The draft standard supports text-based communication, file transfers, group messaging, and "presence". Future versions of the Standard are expected to support audio and video communications. As of  September 30, 2012, ANSI/DS 2019-02-100-2021 the Trusted Instant Messaging Plus (TIM+) Applicability Statement was approved as an ANSI Standard version 1.1.1. 
  • IHE-MHD is very similar to IHE-XDR, but uses FHIR. The typical use case for MHD in this mode is when documents are known to be needed by a recipient. Such as a patient referral in the use case given in XDR. In addition, the MHD can be used as a push API to a system that ultimately delivers the content. For example, MHD initiating a push to an Intermediary. In this use case the MHD push request could be handled by the intermediary that further pushes the content using XDR or an e-mail carrying XDM (e.g., the Direct Project).
  • On the recipient side, the MHD could be used by an intermediary to forward a XDR or XDM push content. MHD could also be used on the recipient side as a query/retrieve where the intermediary has cached content addressed to that recipient. This Intermediary is an example of a Direct Project HISP with the added functionality provided by MHD, enabling FHIR based push with end-to-end interoperability between three different transport stacks in MHD, XDR, and e-mail XDM.
  • The Applicability Statement for Secure Health Transport Version 1.3 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).
  • The implementation guide for expressing context in Direct has been incorporated into the widely adopted Event Notifications via Direct Standard® and some organizations are sending metadata utilizing this model to communicate context according to the guide.
  • System Authentication – The information and process necessary to authenticate the systems involved.
  • Recipient Encryption – The message and health information are encrypted for the intended user.
  • Sender Signature – Details that are necessary to identity of the individual sending the message.
  • 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.
  • Patient Consent Information - Identifies the patient consent information that may be required before data can be accessed.
    • May be required to authorize any exchange of patient information.
    • May be required to authorize access and use of patient information.
    • May be required to be sent along with disclosed patient information.
    • Advise the receiver about policies to which end users must comply.
  • Security Labeling – The health information is labeled with security metadata necessary for access control by the end user.

 

Interoperability Need: An Unsolicited “Push” of Clinical Health Information to a Known Destination Between Systems

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The IHE-XDR implementation specification is based upon the underlying standards: SOAP v2, and OASIS ebXML Registry Services 3.0
  • The eHealth Exchange Specification: Authorization Framework implementation specification is based upon the underlying standards: SAML v1.2, XSPAv1.0, and WS-1.1.
  • “The Direct Standard” is based upon the underlying standard: Simple Mail Transfer Protocol (SMTP) RFC 5321 and for security uses Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification, RFC 5751.
  • For Direct, interoperability may depend on establishing “trust” between two parties and vary based on the trust community(ies) to which parties belong. DirectTrust is a trust community which facilitates Direct communication among users for provider messaging and consumer-mediated exchange.
  • The reference to FHIR for this interoperability need is in relation to the transport services that are conformant to the “RESTful FHIR API
  • The DirectTrust Trusted Instant Messaging Plus standard provides secure instantaneous communication via the XMPP standard between servers allowing for federated trust communities and cross-platform communication. The draft standard supports text-based communication, file transfers, group messaging, and "presence". Future versions of the Standard are expected to support audio and video communications.
  • The Applicability Statement for Secure Health Transport Version 1.3 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).
  • 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.
  • Security Labeling – The health information is labeled with security metadata necessary for access control by the end user.
  • Purpose of Use – Identifies the purpose for the transaction.

 

Interoperability Need: Medical Device Communication 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 1
No
Free
Yes
Implementation Specification
Balloted Draft
Production
Feedback Requested
No
Free
Yes

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • These ITU standards are Continua Design Guidelines, developed to provide a suite of open industry standards and specifications that provide several means to end-to-end interoperability between personal medical devices and health information systems.  Unrestricted access to the implementation specification: http://www.pchalliance.org/continua-design-guidelines 
  • 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.

 

Interoperability Need: Push Communication of Vital Signs from Medical Devices

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • ISO/IEEE 11073 is a family of standards for various medical devices.
  • The IEEE1073 Nomenclature is recognized in the IHE/HL7 record set
  • The ITU implementation specifications are Continua Design Guidelines, developed to provide a suite of open industry standards and specifications that provide several means to end-to-end interoperability between personal medical devices and health information systems.  Unrestricted access to the implementation specification: http://www.pchalliance.org/continua-design-guidelines
  • Feedback requested.

 

Interoperability Need: Remote Patient Monitoring to Support Chronic Condition Management, Patient Education and Patient Engagement

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • These ITU standards are Continua Design Guidelines, developed to provide a suite of open industry standards and specifications that provide several means to end-to-end interoperability between personal medical devices and health information systems.  Unrestricted access to the implementation specification: http://www.pchalliance.org/continua-design-guidelines
  • 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.

 

Interoperability Need: Representing Path Traversal Expressions

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

 

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

 

Clinical Decision Support Services

Interoperability Need: Immunization Decision Support Forecast

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
  • ONC Certification Criteria § 170.315 (f)(1) Transmission to immunization registries (https://www.healthit.gov/test-method/transmission-immunization-registries) requires that:
    • (i) The Health IT Module can create immunization information according to the IG IM Release 1.5, and the July 2015 Addendum, using CVX codes for historical vaccines and NDC codes for newly administered vaccines.
    • (ii) Enable a user to request, access, and display a patient's evaluated immunization history and the immunization forecast from an immunization registry in accordance with  HL7 2.5.1 standard, the HL7 2.5.1. IG IM Release 1.5, and July 2015 Addendum.
  • The Immunization Decision Support Forecast (ImmDS) use case covers the exchange of data between a system seeking a patient evaluated history and forecast and the clinical decision support engine capable of providing that history and forecast. Today, this layer is not standardized and leads to several unique/proprietary interfaces which are costly to implement. The scope of this implementation guide is to create a standard interface layer between the initiating system and the CDS engine.
  • The initiating system in this exchange is typically a system being used (either directly or indirectly) by a clinician to provide care to the patient. This can be a jurisdictional level Immunization Information System (IIS) which collates the patient’s immunization history from a variety of sources or an EHR which is being used to provide point of care support for clinicians. However other systems such as HIEs, school medical records, etc may also play this role.
  • Feedback requested.

 

Interoperability Need: Providing Patient-Specific Assessments and Recommendations Based on Patient Data for Clinical Decision Support

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • 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.

  • System Authentication  The information and process necessary to authenticate the systems involved.
  • Recipient Encryption – The message and health information are encrypted for the intended user.
  • Sender Signature – Details that are necessary to identity of the individual sending the message.
  • 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.
  • Security Labeling – The health information is labeled with security metadata necessary for access control by the end user.

 

Interoperability Need: Retrieval of Contextually Relevant, Patient-Specific Knowledge Resources from Within Clinical Information Systems to Answer Clinical Questions Raised by Patients in the Course of Care

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

 

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

 

Consumer Access/Exchange of Health Information

Interoperability Need: Collection and Exchange of Patient-Reported Outcomes

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
Implementation Specification
In Development
Pilot
Rating 1
No
Free
No
Implementation Specification
Final
Feedback requested
Feedback Requested
No
Free
No
Implementation Specification
Balloted Draft
Feedback requested
Feedback Requested
No
Free
Yes
Yes

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The FHIR Patient Reported Outcomes (PRO) Implementation Guide is included with the balloted, standard for trial use (STU) implementation guide and a link to the continuous build of the same. The latter, as a continuous integration build, may at any point in time be unavailable or undergoing change.
  • The creation/generation and scoring of PRO measure instruments and interpretation of the PRO data is dictated by the organizations/institutions that created, tested, and validated them.
  • The HL7 FHIR PRO IG is not intended to be used to define or generate PRO measure instruments or interpret PRO data. 

 

  • PROM Instrument and Meta Data Security Conformance:
    • SHALL support the Communication security mechanisms outlined in FHIR Security Specification.
    • SHALL support the Authentication security mechanisms outlined in FHIR Security Specification.
    • SHOULD support other security recommendations outlined in FHIR Security as appropriate.
  • EHR or Care Delivery IT System Security Conformance:
    • SHALL support the Communication security mechanisms outlined in FHIR Security Specification.
    • SHALL support the Authentication security mechanisms outlined in FHIR Security Specification.
    • SHOULD support other security recommendations outlined in FHIR Security as appropriate.
  • External Pro Administration System Security Conformance:
    • SHALL support the Communication security mechanisms outlined in FHIR Security Specification.
    • SHALL support the Authentication security mechanisms outlined in FHIR Security Specification.
    • SHOULD support other security recommendations outlined in FHIR Security as appropriate.
  • Patient Facing Administration App System Security Conformance:
    • SHALL support the Communication security mechanisms outlined in FHIR Security Specification.
    • SHALL support the Authentication security mechanisms outlined in FHIR Security Specification.
    • SHOULD support other security recommendations outlined in FHIR Security as appropriate.
    • MAY have to comply with other security requirements to interact with the External Assessment Center.
  • External Assessment Center Security Conformance:
    • SHALL support the Communication security mechanisms outlined in FHIR Security Specification.
    • SHALL support the Authenitication security mechanisms outlined in FHIR Security Specification.
    • SHOULD support other security recommendations outlined in FHIR Security as appropriate.
    • MAY have to comply with other security requirements to interact with the External Assessment Center.
  • Feedback requested, as security is at the discretion of the implementing organization based on the ecosystem and operational considerations within each organization.

 

 

Interoperability Need: Patient Exchanging Secure Messages with Care Providers

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
Standard
Final
Production
Rating 5
Yes
$
N/A
Implementation Specification
Final
Production
Rating 4
Yes
Free
Yes
Implementation Specification
Final
Production
Rating 3
Yes
Free
Yes

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • To learn more about Secure Messaging, Patient Portals and their usage, see the Patient Engagement Playbook.  
  • “Direct” standard is based upon the underlying standard: Simple Mail Transfer Protocol (SMTP) RFC 5321 and for security uses Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification, RFC 5751.
  • For Direct, interoperability may depend on establishing “trust” between two parties and vary based on the trust community(ies) to which parties belong. DirectTrust is a trust community which facilitates Direct communication among users for provider messaging and consumer-mediated exchange.
  • As of March 2019, DirectTrust received accreditation as an ANSI SDO. A new division of the organization, DirectTrust Standards has convened a consensus body to update and maintain the Direct Standard (TM) going forward and to seek ANSI approval for the Standard.
  • Current Procedural Terminology (CPT) Consumer Friendly Descriptors (CFDs) may be used when data is being exchanged between patients and providers.
  • The SMART® on FHIR Project is working in this area, and may have additional implementation guidance, as well as a list of applications supporting this interoperability need. 
  • When using the SMART on FHIR model, the authentication model uses OAuth2. Except for “Secure Communication”, the security patterns listed do not apply.
  • The Applicability Statement for Secure Health Transport Version 1.3 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).
  • 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.                
  • Security Labeling – The health information is labeled with security metadata necessary for access control by the end user.  
  • 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.                
     

 

Interoperability Need: Push Patient-Generated Health Data into Integrated EHR

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
Implementation Specification
Final
Production
Rating 3
Yes
Free
Yes
Implementation Specification
Final
Production
Rating 1
Yes
Free
Yes
Standard
Final
Production
Rating 1
Yes
$
N/A
Implementation Specification
Balloted Draft
Feedback requested
Feedback Requested
No
Free
Yes
Yes
Emerging Implementation Specification
Balloted Draft
Feedback requested
Feedback Requested
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • To learn more about Patient-Generated Health Data and its usage, see the Patient Engagement Playbook, as well as ASTP's Patient-Generated Health Data webpage
  • ASTP published a White Paper and a Practical Guide  to better understand and illustrate the opportunities, challenges, and best practices for using patient generated health data. 
  • Current Procedural Terminology (CPT) Consumer Friendly Descriptors (CFDs) may be used, as appropriate, when pushing patient-generated health data into integrated EHRs.
  • The SMART® on FHIR Project is working in this area, and may have additional implementation guidance, as well as a list of applications supporting this interoperability need. 
  • When using the SMART on FHIR model, the authentication model uses OAuth2. Except for “Secure Communication”, the security patterns listed do not apply. 
  • “Direct” standard is based upon the underlying standard: Simple Mail Transfer Protocol (SMTP) RFC 5321 and for security uses Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification, RFC 5751.
  • For Direct, interoperability may be dependent on the establishment of “trust” between two parties and may vary based on the trust community(ies) to which parties belong. The leading trust communities to enable communication amongst the most users include DirectTrust (for provider messaging and consumer-mediated exchange) and NATE (for consumer-mediated exchange).
  • As of March 2019, DirectTrust received accreditation as an ANSI SDO. A new division of the organization, DirectTrust Standards has convened a consensus body to update and maintain the Direct Standard (TM) going forward and to seek ANSI approval for the Standard.
  • The MHD profile provides methods of expressing the medical data (document), the Provenance of that document (metadata), and the reason for submitting (submission Set).
  • The Applicability Statement for Secure Health Transport Version 1.3 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).
  • 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.            
  • Security Labeling – The health information is labeled with security metadata necessary for access control by the end user.                
  • Query Request ID – Query requesting application assigns a unique identifier for each query request in order to match the response to the original query.    
  • 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.                
     

 

Interoperability Need: Remote Patient Authorization and Submission of EHR Data for Research

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
Implementation Specification
Final
Production
Rating 1
No
Free
Yes
Implementation Specification
Balloted Draft
Feedback requested
Feedback Requested
No
Free
Yes
Emerging Implementation Specification
In Development
Pilot
Feedback Requested
No
$
Emerging Implementation Specification
In Development
Pilot
Feedback Requested
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • See Sync for Science and Sync for Genes for more details about the research project use case that pertains to this interoperability need. 
  • To learn more about how APIs can help patients participate in research, see the Patient Engagement Playbook
  • The Kantara Initiative's UMA (User Managed Access) Work Group project's use case is designed to develop specifications that allow individual control of authorized data sharing and service access to promote interoperability in support of this interoperability need.  
  • Current Procedural Terminology (CPT) Consumer Friendly Descriptors (CFDs) may be used when data is being exchanged between patients and providers.
  • The SMART® on FHIR Project is working in this area, and may have additional implementation guidance, as well as a list of applications supporting this interoperability need. 
  • When using the SMART on FHIR model, the authentication model is OAuth2. The other security patterns listed do not apply. 
  • The IHE Basic Patient Privacy Consents (BPPC) profile provides a means for recording the ceremony of patient consenting to a policy. The BPPC profile will use terms consistent with ISO 22600 - Privilege Management and Access Control (PMAC), but is not restricted to systems that implement PMAC. See the IHE white paper Enabling Document Sharing Health Information Exchange Using IHE Profiles (http://profiles.ihe.net/ITI/HIE-Whitepaper/index.html.
  • The IHE Advanced Patient Privacy Consents (APPC) profile is used when additions or deviations from a "Basic" consent policy are needed. The APPC mechanism provides for deeper coded consents beyond what BPPC supports. BPPC continues to be used to capture the ceremony and overall policy, where APPC provides the specific additions or deviations.
  • 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.
  • Patient Consent Information – Identifies the patient consent information that may be required before data can be accessed.
    • May be required to authorize any exchange of patient information
    • May be required to authorized access and use of patient information
    • May be required to be sent along with disclosed patient information to advise the receiver about policies to which end users must comply
  • Purpose of Use - Identifies the purpose for the transaction.
  • Security Labeling – The health information is labeled with security metadata necessary for access control by the end user.

 

Interoperability Need: View, Download and Transmit Data from EHR

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • To learn more about Patient Portals and their usage, see the Patient Engagement Playbook
  • For a consumer-facing resource on this interoperability need, see ONC's Guide to Getting & Using Your Health Records.  
  • “Direct” standard is based upon the underlying standard: Simple Mail Transfer Protocol (SMTP) RFC 5321 and for security uses Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification, RFC 5751.
  • For Direct, interoperability may depend on establishing “trust” between two parties and vary based on the trust community(ies) to which parties belong. DirectTrust is a trust community which facilitates Direct communication among users for provider messaging and consumer-mediated exchange.
  • As of March 2019, DirectTrust received accreditation as an ANSI SDO. A new division of the organization, DirectTrust Standards has convened a consensus body to update and maintain the Direct Standard (TM) going forward and to seek ANSI approval for the Standard.
  • Current Procedural Terminology (CPT) Consumer Friendly Descriptors (CFDs) may be used when data is being exchanged between patients and providers.
  • The SMART on FHIR Project is working in this area, and may have additional implementation guidance, as well as a list of applications supporting this interoperability need. 
  • When using the SMART on FHIR model, the authentication model uses OAuth2. Except for “Secure Communication”, the security patterns listed do not apply. 
  • The IHE Mobile Access to Health Documents (MHD) profile provides a simple API for document discovery and download. This API may be used in many settings including by Patient managed applications. See -- https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html
  • The IHE Query for Existing Data for mobile (QEDm) profile provides for a simple query for a subset of clinical FHIR Resources. This subset is consistent with USCDI.
  • The HL7 FHIR® SMART Application Launch Framework Implementation Guide Release 2.0.0 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).
  • 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.
  • Patient Consent Information – Identifies the patient consent information that may be required before data can be accessed.
    • May be required to authorize any exchange of patient information
    • May be required to authorized access and use of patient information
    • May be required to be sent along with disclosed patient information to advise the receiver about policies to which end users must comply
  • Security Labeling – The health information is labeled with security metadata necessary for access control by the end user.
  • Query Request ID - Query requesting application assigns a unique identifier for each query request in order to match the response to the original query.
  • 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.            

 

Healthcare Directory, Provider Directory

Interoperability Need: Listing of Providers for Access by Potential Exchange Partners

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The IHE IT Infrastructure Technical Framework Supplement, Healthcare Provider Directory (HPD), Trial Implementation was proposed, but not adopted for CEHRT 2015. The Health IT community has recognized the value of the underlying data elements and structure of that standard. However, this implementation specification has met with limited adoption due to several concerns. 
  • 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.
  • See IHE White Paper for use-case analysis and recommendations on how to use mCSD.
  • Security Labeling – The health information is labeled with security metadata necessary for access control by the end user.

 

Image Exchange

Interoperability Need: Exchanging Images Outside a Specific Health Information Exchange Domain

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
Production
Rating 5
No
Free
No
Implementation Specification
Final
Production
Rating 4
No
Free
Yes
Yes
Yes
Implementation Specification
Final
Pilot
Rating 1
No
Free
Yes

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The IHE XCA-I profile can be found in Section 2.1.27 of the IHE Radiology (RAD) linked above.
  • IHE-PIX and IHE-XCPD are used for the purposes of patient matching and to support this interoperability need.
  • For IHE-PDI, network transfers are preferable to digital media transfers, though the latter may be used when network solutions are not in place
  • 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).

 

Interoperability Need: Exchanging Images Within a Specific Health Information Exchange Domain

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
Implementation Specification
Final
Production
Rating 4
No
Free
Yes
Yes
Implementation Specification
Final
Production
Rating 4
No
Free
Yes
Yes
Implementation Specification
Final
Production
Rating 2
No
Free
Yes
Yes
Implementation Specification
Final
Feedback requested
Rating 1
No
Emerging Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
No
Emerging Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • IHE-PIX and IHE-PDQ are used for the purposes of patient matching and to support this interoperability need.
  • To survey implementations of RESTful DICOMweb services to store, query, retrieve, an internet search for the relevant service (STOW-RS, QIDO-RS, WADO-RS) and the phrase “DICOM Conformance Statement” will typically return links to specific products.
    • STOW-RS "dicom conformance statement"
    • QIDO-RS "dicom conformance statement"
    • WADO-RS "dicom conformance statement"
  • 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.

 

Infrastructure

Interoperability Need: Client Application Management

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Emerging Standard
Final
Production
Feedback Requested
No
Free
Yes
Emerging Implementation Specification
Balloted Draft
Feedback requested
Feedback Requested
No
Free
No
Emerging Implementation Specification
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
Feedback requested
Feedback Requested
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The HL7 FHIR SMART Application Launch Framework Implementation Guide Release 2.0.0 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).
  • Since FHIR transactions require the use of a FHIR client, client application registration and management is an integral component for apps using FHIR. 
  • UDAP Dynamic Client Registration provides an extension to RFC 7591 to better scale the registration and use of FHIR client apps. This profile has seen interest from numerous industry stakeholders as an alternative to manually re-registering apps at every different datasource and as a way to enable sharing of information about apps among datasources. 
  • Trusted Dynamic Client Registration provides a path for verification of attributes for apps holding valid digital certificates and the communication of these attributes (e.g. privacy policy) to the end user, increasing confidence in valid FHIR clients within the ecosystem and facilitating the connection of apps to clinical FHIR servers without manual pre-registration. This can be used together with UDAP JWT-based Client Authentication to support reusable client identity for authentication and authorization, to help scale the use of client credentials or authorization code flow, and UDAP JWT-based Client Authorization Grants can be used to transmit Purpose of Use and Consent Information.    
  • UDAP is an open collaborative developing profiles to increase scalability, confidence, security, and trust in Open API ecosystems, and allows the re-use of identity proofing and credentialing processes already in place in existing national health information networks. These profiles are in draft status and are in pilot stage. UDAP DCR and Authentication/Authorization have been tested successfully at several HL7 FHIR connectathons and have received positive feedback from multiple stakeholders, including national health information networks, EHR vendors, patient privacy rights advocates, and app developers. These profiles are also compatible with SMART App Launch and UMA.
  • The Security FHIR IG has been established upon the recommendations of ASTP's FHIR at Scale Taskforce (FAST) Security Tiger Team, and has been adapted from IGs previously published by UDAP.org. The objective of the IG is to harmonize workflows for both consumer-facing and B2B applications to facilitate cross-organizational and cross-network interoperability. 
  • System Authentication – The information and process necessary to authenticate the systems involved.
  • User Authentication – The information and process necessary to authenticate the end user.
  • User Details – Identifies the end user who is accessing the data.
  • User Role – Identifies the roles and clearances asserted by the individual initiating the transaction for purposes of authorization. E.g., the system must verify the initiator’s claims and match them against the security labels for the functionalities that the user attempts to initiate and the objects the user attempts to access.
  • Purpose of Use – Identifies the purpose for the transaction, and for the purposes for which the end user intends to use the accessed objects.
  • Patient Consent Information – Identifies the patient consent information that may be required before data can be accessed.
    • May be required to authorize any exchange of patient information
    • May be required to authorized access and use of patient information
    • May be required to be sent along with disclosed patient information to advise the receiver about policies to which end users must comply
  • Query Request ID - Query requesting application assigns a unique identifier for each query request in order to match the response to the original query.
  • Security Labeling – The health information is labeled with security metadata necessary for access control by the end user.

 

Patient Identity/Identification Management

Interoperability Need: Exchanging Patient Identification Within and Between Communities

Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Production
Rating 5
No
Free
Yes
Yes
Yes
Implementation Specification
Final
Production
Rating 5
No
Free
Yes
Yes
Yes
Implementation Specification
Final
Production
Rating 5
No
Free
Yes
Yes
Implementation Specification
Balloted Draft
Production
Feedback Requested
No
Free
Yes
Yes
Implementation Specification
Balloted Draft
Production
Feedback Requested
No
Free
Yes
Yes
Implementation Specification
Balloted Draft
Feedback requested
Feedback Requested
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
  • Feedback requested.

 

Public Health Exchange

Interoperability Need: Transport for Immunization Submission and Query/Response

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

 

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

 

Publish and Subscribe

Interoperability Need: Publish and Subscribe Message Exchange

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
Standard
Balloted Draft
Pilot
Rating 1
No
Free
No
Emerging Implementation Specification
Balloted Draft
Pilot
Rating 2
No
Free
Yes
Yes
Emerging Implementation Specification
In Development
Pilot
Feedback Requested
No
Free
N/A

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The listed eHealth Exchange Specification will be deprecated in the future in favor of the emerging IHE DSUB specification and/or the equivalent FHIR profile.
  • 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.

 

Query

Interoperability Need: Data Element Based Query for Clinical Health Information

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
Implementation Specification
Final
Production
Feedback Requested
Yes
Free
Yes – Open
Implementation Specification
Balloted Draft
Production
Rating 1
No
Free
No
Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
No
Implementation Specification
Balloted Draft
Pilot
Rating 1
No
Free
No
Implementation Specification
Final
Production
Feedback Requested
No
Free
Yes
Implementation Specification
Final
Production
Feedback Requested
No
Free
Yes
Implementation Specification
Final
Production
Feedback Requested
No
Free
Yes
Emerging Implementation Specification
Balloted Draft
Pilot
Feedback Requested
No
Free
No
Emerging Implementation Specification
Balloted Draft
Pilot
Feedback Requested
No
Free
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The reference to FHIR for this interoperability need is in relation to the transport services that are conformant to the “RESTful FHIR API
  • 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 combination of mXDE and QEDm provide for Provenance evidence between the FHIR Resources made available via QEDm and the documents from which that data was decomposed. In this way the client application using FHIR Resource data can ask for Provenance. For each Provenance record given there is a unique document that contained that information. Thus the client can know how many documents stated the medical information, and can navigate to those documents. See IHE whitepaper section consuming data as FHIR resources.
  • The HL7 FHIR Bulk Data Access (Flat FHIR) (v2.0.0: STU 2) 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).
  • The HL7 FHIR US Core Implementation Guide STU 4.0.0 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).
  • The HL7 FHIR US Core Implementation Guide STU 5.0.1 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).
  • 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.
  • Patient Consent Information – Identifies the patient consent information that may be required before data can be accessed.
    • May be required to authorize any exchange of patient information.
    • May be required to authorize access and use of patient information.
    • May be required to be sent along with disclosed patient information to advise the receiver about policies to which end users must comply.
  • Security Labeling – The health information is labeled with security metadata necessary for access control by the end user.
  • Query Request ID – Query requesting application assigns a unique identifier for each query request in order to match the response to the original query.

 

Interoperability Need: Query for Documents Outside a Specific Health Information Exchange Domain

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • IHE-PIX and IHE-XCPD are used for the purposes of patient matching and to support this interoperability need.
  • While IHE-PIX and IHE-XCPD are best-available standards at this time, the current best-available standards may be insufficient to meet interoperability needs with sufficient accuracy.
  • The FHIR DocumentReference reference includes the Patient/$match operation, which allows for patient matching using MPI-based logic.
  • The Document Sharing exchange family of specifications from IHE fit this use-case well. This includes FHIR-based exchanges as specified in the Mobile access to Health Documents (MHD) and Mobile Health Documents Sharing (MHDS)
  • System Authentication – The information and process necessary to authenticate the systems involved.
  • User Authentication – The information and process necessary to authenticate the end user.
  • User Details – Identifies the end user who is accessing the data.
  • User Role – Identifies the roles and clearances asserted by the individual initiating the transaction for purposes of authorization. E.g., the system must verify the initiator’s claims and match them against the security labels for the functionalities that the user attempts to initiate and the objects the user attempts to access.
  • Purpose of Use – Identifies the purpose for the transaction, and for the purposes for which the end user intends to use the accessed objects.
  • Patient Consent Information – Identifies the patient consent information that may be required before data can be accessed.
    • May be required to authorize any exchange of patient information.
    • May be required to authorize access and use of patient information.
    • May be required to be sent along with disclosed patient information to advise the receiver about policies to which end users must comply.
  • Query Request ID - Query requesting application assigns a unique identifier for each query request in order to match the response to the original query.
  • Security Labeling – The health information is labeled with security metadata necessary for access control by the end user.

 

Interoperability Need: Query for Documents Within a Specific Health Information Exchange Domain

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • IHE-PIX and IHE-PDQ are used for the purposes of patient matching and to support this interoperability need along with IHE-XDS.
  • The MHD Supplement Revision 2.2 published in April 2016 is based on FHIR DSTU2.
  • IHE-PIXm and IHE-PDQm are used for the purposes of patient matching and to support this interoperability need along with MHD.
  • The Document Sharing exchange infrastructure is a family of implementation guides specifically designed to support this setting. This includes the FHIR based Mobile Health Document Sharing (MHDS) comprehensive community exchange. Both XDS and MHDS enable the automation of discovery and retrieve of document content by more advanced health information systems.
  • 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.

 

Resource Location

Interoperability Need: Care Service Discovery Within the U.S.

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
No

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • 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.

 

Interoperability Need: Finding and Retrieving Human 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
Free
N/A

 

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

 

Administrative

Administrative Transactions - Non-Claims

Interoperability Need: Administrative Transaction Acknowledgements

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The Administrative Simplification provisions of HIPAA apply to the adoption of electronic transaction standards and operating rules for use in the health care industry.  Information about the HIPAA regulations regarding standards and operating rules can be found at https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/HIPAA-ACA/index.html. Readers can find information about requirements for covered entities and their business associates and enforcement from this link.
  • The acknowledgement transactions have not been adopted under HIPAA but may be used voluntarily between willing trading partners. 
  • Access to the information about the Acknowledgement Transaction and Implementation Specification on the X12 website is available under the Communications & Controls Workgroup. X12 offers several licensing agreements to obtain copies of this and all other X12 standards, which can be viewed at https://x12.org/products/licensing-program.  Since access to the implementation specifications is available only through a licensing agreement, X12 has made additional options for limited views of the specifications through Glass, the X12 on-line viewer. 
  • Feedback requested.

 

Interoperability Need: Enrollment and Disenrollment in a Health Plan

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
Production
Feedback Requested
No
$
Yes

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The Administrative Simplification provisions of HIPAA apply to the adoption of electronic transaction standards and operating rules for use in the health care industry. Information about HIPAA regulations, standards and operating rules can be found at https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/HIPAA-ACA/index.html
  • This standard and the transaction were adopted under the Health Insurance Portability Act of 1996 (HIPAA) to increase efficiency in the health care system by reducing the use of paper and increasing the exchange of health care information electronically.  This information is often maintained in provider practice management and billing systems but duplicates information in electronic health records.
  • Before implementation of a new version of a standard, end to end testing should be conducted with vendor systems and between trading partners to ensure changes have been accommodated.
  • There are two versions of the enrollment transaction in use by industry today. One is the adopted transaction exchanged between a covered health plan and an employer, which is not a covered entity. The other version, referred to as the HIX, is used by issuers participating in the federal marketplace or health insurance exchanges.  
  • For a description of the functionality of each transaction, visit the X12 website.
  • ASETT is the HHS compliance tool to enable testing and complaint filing for all X12 and NCPDP® transactions. To test transactions, visit the HHS compliance page
  • Operating rules have not been adopted for the enrollment transaction standard. 
  • NCPDP operating rules are in the NCPDP Telecommunication Standard, Implementation Guide, Version D.0.  Additional operating rules are not developed by any entity outside of NCPDP for the pharmacy standards.
  • All covered entities and their business associates are required to comply with the HIPAA Privacy and Security Rules. Health and Human Services has partnered with the Office of the National Coordinator and the National Institutes of Standards and Technology to publish comprehensive guidance for Security specific to electronic protected health information. A self-assessment tool kit is available to support integrating privacy and security into practices.

 

Interoperability Need: Health Care Eligibility Benefit Inquiry and Response

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The Administrative Simplification provisions of HIPAA apply to the adoption of electronic transaction standards and operating rules for use in the health care industry.  Information about the HIPAA regulations regarding standards and operating rules can be found at https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/HIPAA-ACA/index.html. Readers can find information about requirements for covered entities and their business associates and enforcement from this link.
  • This standard and the transaction were adopted under the Health Insurance Portability Act of 1996 (HIPAA) to increase efficiency in the health care system by reducing the use of paper and increasing the exchange of health care information electronically. This version was adopted in 2009 and mandatory use was required in January 2012. 
  • Before implementation of a new version of a standard, end to end testing should be conducted with vendor systems and between trading partners to ensure changes have been accommodated.
  • Additional information is available on testing, and the full cost on any of the X12 transactions.  ASETT is the HHS compliance tool to enable testing and complaint filing for all X12 transactions.
  • The HL7 FHIR Implementation Specifications are for use building APIs to support interoperability to support ASTP, HHS and CMS priorities.
  • All covered entities and their business associates are required to comply with the HIPAA Privacy and Security Rules. Health and Human Services has partnered with the Office of the National Coordinator and the National Institutes of Standards and Technology to publish comprehensive guidance for Security specific to electronic protected health information. A self-assessment tool kit is available to support integrating privacy and security into practices.

 

Interoperability Need: Health Care Eligibility Benefit Inquiry and Response for Retail Pharmacy Coverage

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The Administrative Simplification provisions of HIPAA apply to the adoption of electronic transaction standards and operating rules for covered entities, which includes health plans, health care clearinghouses and certain health care providers. Information about the HIPAA regulations and enforcement can be found at https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/HIPAA-ACA/index.html.
  • Costs to access the NCPDP standards are based on membership status. NCPDP's Standards Matrix is available as a reference providing a high-level overview of the latest version/release and/or the most commonly used of NCPDP standards and implementation guides, as well as NCPDP’s Data Dictionary and External Code List.
  • NCVHS made a recommendation to HHS to adopt the Telecommunication Standard Implementation Guide Version F6 and Subrogation Version 15 in 2019, requesting adoption through rulemaking in CY 2020.  Find the history for this recommendation information on the NCVHS website.  
  • All covered entities and their business associates are required to comply with the HIPAA Privacy and Security Rules. Health and Human Services has partnered with the Office of the National Coordinator and the National Institutes of Standards and Technology to publish comprehensive guidance for Security specific to electronic protected health information. A self-assessment tool kit is available to support integrating privacy and security into practices.

 

Administrative Transactions to Financial Exchanges

Interoperability Need: Electronic Funds Transfer for Payments to Health Care Providers

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • File testing is done between the banks and their originators of the ACH files, between the banks and the ACH Operators and for the software vendors with the ACH Operators. Testing for a new originator is done with the bank before they originate their first file. Testing between the banks and the ACH Operators is done when there is a new application – currently a lot of testing is being done between the banks and the ACH Operators for Same Day ACH Debits (to be implemented in September 2017). If a bank changes ACH processing software or hires a third-party vendor, testing will be done between the bank and the ACH Operator.
  • Because only the current version of an ACH file format is allowed through the ACH Network, the originating bank reviews all files to make sure that the formatting is correct before they send the files to the ACH Operators. The ACH Operators also review all files to make sure that the mandatory fields within the ACH file are formatted correctly – if they are not the files are returned to the originating bank. Both the originating bank and the ACH Operators are looks at the files to make sure that the files are syntactically correct.
  • ACH Network is an electronic funds transfer system governed by the NACHA Operating Rules, which provides for interbank clearing of electronic entries for participating financial institutions.

 

Interoperability Need: Health Care Payment and Remittance Advice

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The Administrative Simplification provisions of HIPAA apply to the adoption of electronic transaction standards and operating rules for use in the health care industry. HIPAA has some different requirements for information exchange than EHRs, but there is hope for convergence in the future. Information about the HIPAA regulations regarding standards and operating rules can be found at https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/HIPAA-ACA/index.html. Readers can find information about requirements for covered entities and their business associates and enforcement from this link.
  • Adoption of standards to increase the efficiency of the health care system was required by the Health Insurance Portability Act of 1996 (HIPAA). This version of the standard was adopted in 2009, and compliance was required by January 2012. The purpose of the electronic standard transactions was to improve efficiency in the health care system by reducing the use of paper and increasing the electronic exchange of health care information.   
  • Challenges with this transaction may occur when the remittance information does not match the claim or the payment.
  • Additional information is available on testing, and the full cost on any of the X12 transactions. ASETT is the HHS compliance tool to enable testing and complaint filing for all X12 transactions.
  • For a description of the functionality of each transaction, visit the X12 website. Click on a transaction set name to toggle the display of the purpose and scope of that transaction set.
  • Pharmacy providers will receive the X12 835 remittance advice transaction with their payments, and NCPDP® offers specific guidance on how the X12 835 remittance advice should be mapped in response to the NCPDP D.0 claim transaction to maximize reconciliation.
  • All covered entities and their business associates are required to comply with the HIPAA Privacy and Security Rules. Health and Human Services has partnered with the Office of the National Coordinator and the National Institutes of Standards and Technology to publish comprehensive guidance for Security specific to electronic protected health information. 

 

Interoperability Need: Health Plan Premium Payments for Covered Members

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
Production
Feedback Requested
Yes
$
Yes

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The Administrative Simplification provisions of HIPAA apply to the adoption of electronic transaction standards and operating rules for use in the health care industry. HIPAA has some different requirements for information exchange than EHRs, but there is hope for convergence in the future. Information about the HIPAA regulations regarding standards and operating rules can be found at https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/HIPAA-ACA/index.html. Readers can find information about requirements for covered entities and their business associates and enforcement from this link.
  • This standard and the transaction were adopted under the Health Insurance Portability Act of 1996 (HIPAA) to increase efficiency in the health care system by reducing the use of paper and increasing the exchange of health care information electronically.  This information is often maintained in provider practice management and billing systems but duplicates information in electronic health records.
  • Before implementation of a new version of a standard, end to end testing should be conducted with vendor systems and between trading partners to ensure changes have been accommodated.
  • Additional information is available on testing, and the full cost on any of the X12 transactions. ASETT is the HHS compliance tool to enable testing and complaint filing for all X12 transactions.
  • For a description of the functionality of each transaction, visit the X12 website. Click on a transaction set name to toggle the display of the purpose and scope of that transaction set.
  • All covered entities and their business associates are required to comply with the HIPAA Privacy and Security Rules. Health and Human Services has partnered with the Office of the National Coordinator and the National Institutes of Standards and Technology to publish comprehensive guidance for Security specific to electronic protected health information. A self-assessment tool kit is available to support integrating privacy and security into practices.

 

Administrative Transactions to Support Clinical Care

Interoperability Need: Health Care Attachments to Support Claims, Referrals and Authorizations

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The HIPAA legislation requires adoption of a standard for health care attachments; the Affordable Care Act of 2010 reiterated this requirement.  HHS has not proposed adoption of a standard for attachments to support claims and other administrative transactions to date (11/2021).  Willing trading partners may exchange attachments through methods agreed upon by those organizations, including through different means of electronic exchange, and the use of standards.
  • Pilots to test new standards for consideration to be adopted under HIPAA is permissible using the exception process under 162.940.  
  • CMS provides additional information about the HIPAA administrative simplification provisions on its website. 
  • HL7 DaVinci is testing an exception to the x12 278 with an API and submitted its report in July 2024.
  • Feedback requested.

 

Interoperability Need: Referral Certification and Authorization for Pharmacy Transactions

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Updated referral transactions are published in the NCPDP SCRIPT Standard Version 2022011. These transactions are currently available for use by trading partner agreement.
  • In 2019, NCVHS recommended that HHS adopt the Telecommunication Standard Implementation Guide Version F6 and Subrogation (as HIPAA Standards). Adoption of this updated standard is pending HHS rulemaking.
  • NCPDP requested that HHS adopt the NCPDP SCRIPT standard for prior authorization under HIPAA.  This standard has since been adopted under the Medicare Part D program. Check the Federal Register for current rules.
  • Costs for access to the NCPDP standards are based on membership. NCPDP's Standards Matrix is available as a reference providing a high-level overview of the latest version/release and/or the most commonly used of NCPDP standards and implementation guides, as well as NCPDP’s Data Dictionary and External Code List.
  • All operating rules are incorporated as part of the NCPDP standards and separate operating rules are not adopted under HIPAA for pharmacy standards; including for the NCPDP SCRIPT standard. 
  • Feedback requested.

 

Interoperability Need: Referral Certification and Authorization Request and Response for Dental, Professional and Institutional Services

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The Administrative Simplification provisions of HIPAA apply to the adoption of electronic transaction standards and operating rules for use in the health care industry.  Information about the HIPAA regulations and enforcement may be found at https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/HIPAA-ACA/index.html
  • Adoption of standards to increase the efficiency of the health care system was required by the Health Insurance Portability Act of 1996 (HIPAA). The most recent versions of the medical and pharmacy standards were adopted in 2009, with a January 2012 compliance date. The purpose of the electronic standard transactions is to improve efficiency in the health care system by reducing the use of paper and increasing the electronic exchange of health care information. 
  • Before implementation of a new version of a standard, end to end testing should be conducted with vendor systems and between trading partners to ensure changes have been accommodated.
  • ASETT is the HHS compliance tool to enable testing and complaint filing for X12 and NCPDP® transactions.
  • For a description of the functionality of each transaction, visit the X12 website. Click on a transaction set name to toggle the display of the purpose and scope of that transaction set.
  • HL7 Da Vinci Burden Reduction HL7 FHIR IGs for Prior Authorization were recommended for Use in the February 2024 CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) 
    • Coverage Requirements Discovery (CRD).  The goal of the CRD use case is to give providers real-time access to payer approval requirements, documentation, and rules at point of service to reduce provider burden and support treatment planning. 
    • Documentation Templates and Payer Rules (DTR).  The goal of the DTR use case is to reduce provider burden and simplify process by establishing electronic versions of administrative and clinical requirements that can become part of the providers workflow.
    • Prior Authorization Support (PAS). The goal of the PA use case is to define FHIR based services to enable provider, at the point of service, to request authorization (including all necessary clinical information to support the request)  and receive immediate authorization.
    • Da Vinci use cases are piloted and tested during connectathons hosted by HL7 and approved professional affiliates throughout the year.  To learn more about connectathons and other Da Vinci use cases or FHIR accelerator programs, visit www.HL7.org or http://www.hl7.org/about/davinci/use-cases.cfm.
  • The HL7 Dental Data Exchange STU Implementation Guide provides both FHIR-based and CDA-based sets of templates defining the Dental Referral Note and Dental Consultation Note. These standardized documents are intended to support bi-directional information exchange between a medical and a dental provider or between dental providers. This publication provides the data model, defined data items, and their corresponding code and value sets, specific to a dental referral note and dental consultation note intended for exchange.
  • All covered entities and their business associates are required to comply with the HIPAA Privacy and Security Rules. Health and Human Services has partnered with the Office of the National Coordinator and the National Institutes of Standards and Technology to publish comprehensive guidance for Security specific to electronic protected health information. A self-assessment tool kit is available to support integrating privacy and security into practices.

 

Administrative Transactions: Price Transparency

Interoperability Need: Advanced Estimates for Patient Costs from Providers & Payers

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • This IG is not required for use at this time. Its development is informed by the No Surprises Act (see Division BB, Title I, Sections 111 and 112), which was enacted as part of the Consolidated Appropriations Act, 2021. The No Surprises Act specifically requires that a provider share GFEs with a payer and that a payer make an AEOB available to a patient in advance of service. The initial scope of this IG was inspired by this general requirement.
  • This IG provides detailed guidance to support providers and payers exchanging financial information for specific services and items using FHIR-based standards.
  • The exchange involves a provider submitting a Good Faith Estimate (GFE) to a payer, and the payer generating an Advanced Explanation of Benefits (AEOB) for a patient (which may optionally be returned to the submitting provider). This information about the cost of healthcare items or services could enable better decision making by the patient in consultation with the provider. Note: This exchange will be triggered via a “request” or “scheduled service”. The AEOB will also include the GFE used to inform the AEOB generation.
  • This specification is a Standard for Trial Use. It is expected to continue to evolve and improve through HL7® FHIR® Connectathon testing and feedback from early adopters.
  • Criteria regarding what payers must verify in a good faith estimate (GFE) will be evaluated during the next phase of the project after the project stakeholders receive feedback on error handling during testing and implementation.
  • Feedback is welcome and may be submitted through the FHIR change tracker indicating "US Da Vinci PCT" as the specification.
  • This implementation guide (IG) is dependent on other specifications. Please submit any comments you have on these base specifications as follows:
    • Feedback on the FHIR core specification should be submitted to the FHIR change tracker with "FHIR Core" as the specification.
    • Feedback on the US core profiles should be submitted to the FHIR change tracker with "US Core" as the specification.
  • The sharing of information from provider to payer for determining an Advanced Explanation of Benefits (AEOB) is subject to the Health Insurance Portability and Accountability Act’s (HIPAA) “minimum necessary” regulations (specifically 45 CFR 164.514(d)(3) and (d)(4)). Payers are responsible for ensuring that only information necessary to create an AEOB is solicited, and providers are responsible for ensuring that only data that is reasonably relevant to creating an AEOB is transmitted.

 

Health Care Claims and Coordination of Benefits

Interoperability Need: Health Care Claim Status Request and Response

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The Administrative Simplification provisions of HIPAA apply to the adoption of electronic transaction standards and operating rules for use in the health care industry. HIPAA has some different requirements for information exchange than EHRs, but there is hope for convergence in the future. Information about the HIPAA regulations regarding standards and operating rules can be found at https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/HIPAA-ACA/index.html. Readers can find information about requirements for covered entities and their business associates and enforcement from this link.
  • This standard and the transaction were adopted under the Health Insurance Portability Act of 1996 (HIPAA) to increase efficiency in the health care system by reducing the use of paper and increasing the exchange of health care information electronically.  This information is often maintained in provider practice management and billing systems but duplicates information in electronic health records.
  • Before implementation of a new version of a standard, end to end testing should be conducted with vendor systems and between trading partners to ensure changes have been accommodated.
  • Additional information is available on testing, and the full cost on any of the X12 transactions.
  • For a description of the functionality of each transaction, visit the X12 website. Click on a transaction set name to toggle the display of the purpose and scope of that transaction set.
  • All covered entities and their business associates are required to comply with the HIPAA Privacy and Security Rules. Health and Human Services has partnered with the Office of the National Coordinator and the National Institutes of Standards and Technology to publish comprehensive guidance for Security specific to electronic protected health information. A self-assessment tool kit is available to support integrating privacy and security into practices.

 

Interoperability Need: Health Care Claims or Equivalent Encounter Information for Dental Claims

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The Administrative Simplification provisions of HIPAA apply to the adoption of electronic transaction standards and operating rules for use in the health care industry. HIPAA has some different requirements for information exchange than EHRs, but there is hope for convergence in the future. Information about the HIPAA regulations regarding standards and operating rules can be found at https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/HIPAA-ACA/index.html. Readers can find information about requirements for covered entities and their business associates and enforcement from this link.
  • This standard and the transaction were adopted under the Health Insurance Portability Act of 1996 (HIPAA) to increase efficiency in the health care system by reducing the use of paper and increasing the exchange of health care information electronically. This information is often maintained in provider practice management and billing systems but duplicates information in electronic health records.
  • This transaction is also used to conduct coordination of benefits (COB) between organizations that agree to do so.
  • Before implementation of a new version of a standard, end to end testing should be conducted with vendor systems and between trading partners to ensure changes have been accommodated.
  • Additional information is available on testing, and the full cost on any of the X12 transactions. ASETT is the HHS compliance tool to enable testing and complaint filing for all X12 and NCPDP® transactions.
  • For a description of the functionality of each transaction, visit the X12 website. Click on a transaction set name to toggle the display of the purpose and scope of that transaction set.
  • The May 2020 CMS Patient Access and Interoperability Rule enables patients in Medicaid, Medicaid Managed Care, Medicare Advantage and Qualified Health Plans on the Federally Facilitated Exchanges to request that their payer allow them to have their data sent to a health app of their choice upon request through an API. CMS has recommended the use of certain HL7 based Implementation Guides. The HL7 FHIR Consumer Directed Payer Data Exchange (CARIN IG for BlueButton®) STU 2 is one of those IGs, and enables the exchange of dental claims.
  • All covered entities and their business associates are required to comply with the HIPAA Privacy and Security Rules. Health and Human Services has partnered with the Office of the National Coordinator and the National Institutes of Standards and Technology to publish comprehensive guidance for Security specific to electronic protected health information. A self-assessment tool kit is available to support integrating privacy and security into practices.

 

Interoperability Need: Health Care Claims or Equivalent Encounter Information for Institutional Claims

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The Administrative Simplification provisions of HIPAA apply to the adoption of electronic transaction standards and operating rules for use in the health care industry. Information about the HIPAA regulations regarding standards and operating rules can be found at https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/HIPAA-ACA/index.html
  • Before implementation of a new version of a standard, end to end testing should be conducted with vendor systems and between trading partners to ensure changes have been accommodated.
  • Additional information is available on testing, and the full cost on any of the X12 transactions. ASETT is the HHS compliance tool to enable testing and complaint filing for all X12 and NCPDP® transactions.
  • For a description of the functionality of each transaction, visit the X12 website. Click on a transaction set name to toggle the display of the purpose and scope of that transaction set.
  • The HL7 FHIR Consumer Directed Payer Data Exchange (Carin IG for BlueButton) STU 1 was recommended for use in the May 2020 CMS Interoperability and Patient Access final rule to enable the Patient Access API policy, specifically to support patients access to data held by their payers, enabling them to request data to be sent to a third party app. 
  • STU 2 of the HL7 FHIR Consumer Directed Payer Data Exchange (Carin IG for BlueButton) will include the ability to exchange dental claim information.
  • All covered entities and their business associates are required to comply with the HIPAA Privacy and Security Rules. Health and Human Services has partnered with the Office of the National Coordinator and the National Institutes of Standards and Technology to publish comprehensive guidance for Security specific to electronic protected health information. A self-assessment tool kit is available to support integrating privacy and security into practices.

 

Interoperability Need: Health Care Claims or Equivalent Encounter Information for Professional Claims

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The Administrative Simplification provisions of HIPAA apply to the adoption of electronic transaction standards and operating rules for use in the health care industry.  Information about the HIPAA regulations regarding standards and operating rules can be found at https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/HIPAA-ACA/index.html. Readers can find information about requirements for covered entities and their business associates and enforcement from this link.
  • This standard and the transaction were adopted under the Health Insurance Portability Act of 1996 (HIPAA) to increase efficiency in the health care system by reducing the use of paper and increasing the exchange of health care information electronically. The current version was adopted in 2009 and required for use in 2012. Content from the transactions is often maintained in provider practice management and billing systems but duplicates information in electronic health records.
  • Before implementation of a new version of a standard, end to end testing should be conducted with vendor systems and between trading partners to ensure changes have been accommodated.
  • Additional information is available on testing, and the full cost on any of the X12 transactions. ASETT is the HHS compliance tool to enable testing and complaint filing for all X12 and NCPDP® transactions.
  • Information about the CMS May 2020 Interoperability and Patient Access final rule and the implementation guides recommended to comply with the FHIR based APIs included in that rule may be found on the CMS Interoperability website. The HL7 FHIR Consumer Directed Payer Data Exchange (CARIN IG for BlueButton) STU 1 was recommended to comply with the Patient Access API requirement. 


 

 

  • All covered entities and their business associates are required to comply with the HIPAA Privacy and Security Rules. Health and Human Services has partnered with the Office of the National Coordinator and the National Institutes of Standards and Technology to publish comprehensive guidance for Security specific to electronic protected health information. A self-assessment tool kit is available to support integrating privacy and security into practices. 

 

Interoperability Need: Health Care Claims or Equivalent Encounter Information for Retail Pharmacy Claims

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • NCPDP submitted request in February 2018 to have updated standards adopted under HIPAA: NCPDP Telecommunication Standard Implementation Guide Version F2 and Subrogation standard Version 10. Pending rulemaking 10/2021. 
  • The pharmacy telecommunication standard provides a standard format for the electronic submission of third party drug claims and other transactions between pharmacy providers, health plans (payers, insurance companies), third-party administrators, and others with financial responsibility.
  • Under the Health Insurance Portability and Accountability Act of 1996 (HIPAA), all covered entities – health plans, clearinghouses and covered health care providers are required to use the telecommunication standard for claim and service billing, as well as eligibility verification, predetermination of benefits, and prior authorization. The standard can perform a variety of other functions as well.
  • The Medicare Part D program may require use of different NCPDP standards per statute.
  • Costs for access to the NCPDP standards are based on membership. NCPDP's Standards Matrix is available as a reference providing a high-level overview of the latest version/release and/or the most commonly used of NCPDP standards and implementation guides, as well as NCPDP’s Data Dictionary and External Code List.
  • All covered entities and their business associates are required to comply with the HIPAA Privacy and Security Rules. Health and Human Services has partnered with the Office of the National Coordinator and the National Institutes of Standards and Technology to publish comprehensive guidance for Security specific to electronic protected health information. A self-assessment tool kit is available to support integrating privacy and security into practices.

 

Interoperability Need: Health Care Claims or Equivalent Encounter Information for Retail Pharmacy Supplies and Professional Services

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The Administrative Simplification provisions of HIPAA apply to the adoption of electronic transaction standards and operating rules for use by covered health care organizations - all health plans, covered health care providers and clearinghouses.  Information about the HIPAA regulations regarding standards and operating rules can be found at https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/HIPAA-ACA/index.html
  • The NCPDP pharmacy telecommunication standard provides a standard format for the electronic submission of third party drug claims and other transactions between pharmacy providers, health plans (payers, insurance companies), third-party administrators, and others with financial responsibility.
  • Under the Health Insurance Portability and Accountability Act of 1996 (HIPAA), covered entities are required to use the telecommunication standard for eligibility verification, claim and service billing, predetermination of benefits, and prior authorization for retail pharmacy transactions. 
  • Before implementation of a new version of a standard, end to end testing should be conducted with vendor systems and between trading partners to ensure changes have been accommodated.
  • Costs to access the NCPDP standards is based on membership. NCPDP's Standards Matrix is available as a reference providing a high-level overview of the latest version/release and/or the most commonly used NCPDP standards and implementation guides, as well as NCPDP’s Data Dictionary and External Code List.
  • Additional information is available on testing, and the full cost on any of the X12 transactions. 
  • For issues related to enforcement of the HIPAA standards and operating rules, ASETT is the HHS compliance tool to enable testing and complaint filing. 
  • The NCPDP Telecommunication Standard Implementation Guide Version F2 and subrogation Version 10 have  been requested for adoption under HIPAA by NCVHS.  NCVHS recommendation letters to HHS may be viewed on the NCVHS website.    
  • For a description of the functionality of each X12 transaction, visit the X12 website. Click on a transaction set name to toggle the display of the purpose and scope of that transaction set. 
  • All covered entities and their business associates are required to comply with the HIPAA Privacy and Security Rules. Health and Human Services has partnered with the Office of the National Coordinator and the National Institutes of Standards and Technology to publish comprehensive guidance for Security specific to electronic protected health information. A self-assessment tool kit is available to support integrating privacy and security into practices.

 

Operating Rules to Support Administrative Transactions

Interoperability Need: CAQH CORE Operating Rules for Benefit Enrollment and Maintenance

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Operating rules for HIPAA standard transactions were added as a requirement of the Patient Protection and Affordable Care Act of 2010, under section 1104, Administrative Simplification.
  • Operating rules are intended to support and enhance the use of standard transactions. They may include certain requirements to help implement the transaction in a more uniform way between health plans and providers, and to ensure a more complete set of information in the response. 
  • CORE has developed operating rules for Benefit Enrollment and Maintenance which are available for voluntary use by covered entities. These have not yet been adopted through rulemaking by HHS. 
  • In 2023, new and updated CORE Benefit Enrollment and Maintenance Operating Rules were developed and approved by CORE Participants to facilitate the secure and standard collection and exchange of member socio-demographic information at the point of member enrollment into a health plan, or during maintenance of member data.
  • Testing or certification with operating rules is voluntary and available through CORE.  CORE maintains free tools to support operating rule implementation. Additionally, CAQH CORE offers educational webinars on its website.
  • Feedback requested.

 

Interoperability Need: CAQH CORE Operating Rules for Claim Status

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Operating rules for HIPAA standard transactions were added as a requirement of the Patient Protection and Affordable Care Act of 2010, under section 1104, Administrative Simplification.
  • Operating rules are intended to support and enhance the use of standard transactions.  They may include certain requirements to help implement the transaction in a more uniform way between health plans and providers, and to ensure a more complete set of information in the response.
  • In 2012 HHS adopted CORE Operating Rules for Claim Status, which were incorporated by reference at §162.920.
  • Prior versions of the adopted operating rules are available on the CAQH CORE Mandated Operating Rules website and incorporated by reference at §162.920.
  • Updated and new CORE Operating Rules for Claim Status were recommended for Federal adoption by the National Committee of Vital Health and Statistics (NCVHS) to the Department of Health and Human Services (HHS) in June 2023
  • Testing, or certification with the operating rules is voluntary and available through CORE, however, CORE maintains free tools to support operating rule implementation.  Additionally, CORE offers educational webinars on its website.
  • Feedback requested.

 

Interoperability Need: CAQH CORE Operating Rules for Connectivity

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Operating rules for HIPAA standard transactions were added as a requirement of the Patient Protection and Affordable Care Act of 2010, under Section 1104, Administrative Simplification.
  • Operating rules are intended to support and enhance the use of standard transactions. They may include certain requirements to help implement the transaction in a more uniform way across health plans and ensure a more complete set of information in the response.
  • The CORE Operating Rules for Connectivity support the adoption and implementation of transaction-based operating rules by establishing key requirements to maintain the secure exchange of health care information.
  • In 2012 and 2013 HHS adopted two versions of the CORE Connectivity Rules, which were incorporated by reference at §162.920.
  • Prior versions of the CAQH CORE Operating Rules for Connectivity are available on the CAQH CORE Mandated Operating Rules website.
  • In 2020, CAQH CORE updated its Operating Rules for Connectivity to version C4.0.0 to enhance security protocols, and to support REST and SOAP. The updated Rule is available for voluntary use by covered entities.
  • CORE Connectivity Rule vC4.0.0 was recommended for Federal adoption by the National Committee of Vital Health and Statistics (NCVHS) to the Department of Health and Human Services (HHS) in June 2023.
  • Testing or certification with operating rules is voluntary and available through CORE. CORE maintains free tools to support operating rule implementation. Additionally, CORE offers educational webinars on its website.
  • Portions of the CORE Connectivity Rule are mandated for the Eligibility, Claim Status, ERA and EFT operating rules. Others may be adopted at a future date.
  • Feedback requested.

 

Interoperability Need: CAQH CORE Operating Rules for Electronic Funds Transfer (EFT) & Electronic Remittance Advice (ERA)

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

 

Limitations, Dependencies, and Preconditions for Consideration Applicable Value Set(s) and Starter Set(s)
  • Operating rules for HIPAA standard transactions were added as a requirement of the Patient Protection and Affordable Care Act of 2010 (ACA), under section 1104, Administrative Simplification.
  • Operating rules are intended to support and enhance the use of standard transactions.  They include requirements to help implement the transaction in a more uniform way between health plans and providers and ensure a more complete set of information in the response. 
  • The EFT/ERA rules support the uniform use of combinations for certain Claim and Remark Codes (CARCs and RARCs), as well as use of certain standard data elements for enrolling providers
  • In 2013, HHS adopted CORE Operating Rules for EFT and ERA, which were incorporated by reference at §162.920.
  • Prior versions of the adopted operating rules for EFT and ERA Enrollment are available on the CAQH CORE Mandated Operating Rules website and are incorporated by reference at § 162.920.
  • Updated and new CORE Operating Rules for ERA were recommended for Federal adoption by the National Committee of Vital Health and Statistics (NCVHS) to the Department of Health and Human Services (HHS) in June 2023.
  • Testing or certification with the operating rules is voluntary and available through CORE. CORE maintains free tools to support operating rule implementation. Additionally, CORE offers educational webinars on its website.
  • Feedback requested.

 

Interoperability Need: CAQH CORE Operating Rules for Eligibility & Benefits

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Operating rules for HIPAA standard transactions were added as a requirement of the Patient Protection and Affordable Care Act of 2010, under section 1104, Administrative Simplification.
  • Operating rules are intended to support and enhance the use of standard transactions.  They may include certain requirements to help implement the transaction in a more uniform way between health plans and providers, and to ensure a more complete set of information in the response. 
  • In 2012 HHS adopted CORE Operating Rules for Eligibility and Benefits, which were incorporated by reference at  §162.920. 
  • Prior versions of the adopted operating rules for Eligibility and Benefits are available on the CAQH CORE Mandated Operating Rules website and are incorporated by reference at § 162.920.  
  • In 2022, The CAQH CORE Operating Rules for Eligibility & Benefits were updated to align with current industry business requirements to better support complex benefit design, telehealth, and support for the implementation of value-based payment initiatives.
  • These updates also support the identification of prior authorization requirements for services queried during eligibility verifications in real-time, at the point of care.
  • Updated and new CORE Operating Rules for Eligibility & Benefits were recommended for Federal adoption by the National Committee of Vital Health and Statistics (NCVHS) to the Department of Health and Human Services (HHS) in June 2023.   
  • Testing, or certification with the operating rules is voluntary and available through CORE. CORE maintains free tools to support operating rule implementation. Additionally, CORE offers educational webinars on its website. 
  • Feedback requested.

 

Interoperability Need: CAQH CORE Operating Rules for Health Care Claims

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Operating rules for HIPAA standard transactions were added as a requirement of the Patient Protection and Affordable Care Act of 2010, under section 1104, Administrative Simplification.
  • Operating rules are intended to support and enhance the use of standard transactions. They may include certain requirements to help implement the transaction in a more uniform way between health plans and providers and ensure a more complete set of information in the response.
  • The CAQH CORE Health Care Claims Operating Rules are available for voluntary use by covered entities.
  • In 2023, CORE Operating Rules for Health Care Claim Submission (837) and Claim Acknowledgment (277CA) Data Content were developed and approved by CORE Participants. The rules standardize the information included on a claim and the information health plans include that communicates claim submission errors. Both rules are available for voluntary use by covered entities.
  • HHS has adopted operating rules for Eligibility and Benefits and Claim Status (2011), and Electronic Funds Transfer and Electronic Remittance Advice (2013). 
  • HHS has not adopted Operating Rules for other HIPAA transaction standards, including Health Care Claims, Prior Authorization, Premium Billing, and Enrollment/Disenrollment.
  • Testing or certification with operating rules is voluntary and available through CORE. CORE maintains free tools to support operating rule implementation. Additionally, CORE offers educational webinars on its website.
  • NCPDP operating rules are incorporated as part of the NCPDP standard and separate operating rules are not adopted under HIPAA for pharmacy standards.
  • Feedback requested.

 

Interoperability Need: CAQH CORE Operating Rules for Premium Payments

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Operating rules for HIPAA standard transactions were added as a requirement of the Patient Protection and Affordable Care Act of 2010, under Section 1104, Administrative Simplification.
  • Operating rules are intended to support and enhance the use of standard transactions. They may include certain requirements to help implement the transaction in a more uniform way between health plans and providers, and to ensure a more complete set of information in the response. 
  • CORE has developed operating rules for Premium Payments which are available for voluntary use by covered entities.
  • HHS has adopted operating rules for Eligibility and Benefits and Claim Status (2011), and Electronic Funds Transfer and Electronic Remittance Advice (2013). 
  • As of 2023, HHS had not adopted Operating Rules for other HIPAA transaction standards, including Benefits Enrollment and Disenrollment, Premium Billing, Health Care Claims, and Prior Authorization.  
  • Testing or certification with operating rules is voluntary and available through CORE. CORE maintains free tools to support operating rule implementation. Additionally, CAQH CORE offers educational webinars on its website.
  • Feedback requested.

 

Interoperability Need: CAQH CORE Operating Rules for Prior Authorization & Referrals

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Operating rules for HIPAA standard transactions were added as a requirement of the Patient Protection and Affordable Care Act of 2010, under Section 1104, Administrative Simplification.
  • Operating rules are intended to support and enhance the use of standard transactions. They may include certain requirements to help implement the transaction in a more uniform way between health plans and providers, and to ensure a more complete set of information in the response.
  • The CORE Prior Authorization and Referrals Operating Rules are available for voluntary use by covered entities.
  • In 2022, the CORE Operating Rules for Prior Authorization and Referrals were updated to support the electronic exchange of attachments and medical information.
  • CORE Operating Rules for Eligibility & Benefits further support streamlined prior authorization by requiring health plans and their agents to indicate whether a service requires prior authorization during eligibility verification in real-time, at the point-of-care.
  • Testing or certification with operating rules is voluntary and available through CORE. CORE maintains free tools to support operating rule implementation. Additionally, CORE offers educational webinars on its website.
  • Feedback requested.

 

Interoperability Need: CAQH CORE Operating Rules for the Exchange of an Attributed Patient Roster

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • Operating rules for HIPAA standard transactions were added as a requirement of the Patient Protection and Affordable Care Act of 2010, under Section 1104, Administrative Simplification.
  • Operating rules are intended to support and enhance the use of standard transactions. They may include certain requirements to help implement the transaction in a more uniform way across health plans, and to ensure a more complete set of information in the response.
  • In 2023, the CORE Operating Rules for Exchange of an Attributed Patient Roster were updated to facilitate the secure, standardized exchange of member socio-demographic information collected during enrollment to a health plan.
  • Operating rules for the electronic exchange of a roster of patients attributed to the provider under a value-based contract are available for voluntary use by covered entities. 
  • Testing or certification with operating rules is voluntary and available through CORE. CORE maintains free tools to support operating rule implementation.  Additionally, CORE offers educational webinars on its website.
  • Feedback requested.

 

Interoperability Need: Operating Rules to Support Electronic Prescribing Transactions

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

 

Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • These operating rules are not related to the HIPAA standards, but rather to electronic prescription standards adopted under a different statutory authority.
  • NCPDP operating rules are incorporated as part of the NCPDP SCRIPT Standard, Implementation Guide Version 2022011.
  • Feedback requested.

 

Appendix III - Educational and Informational Resources

Interoperability Need: Understanding Emerging API-Based Standards