isp.healthit.gov

Introduction to the 2026 Interoperability Standards Advisory Reference Edition
The Interoperability Standards Advisory (ISA) process represents the model by which the Assistant Secretary for Technology Policy/Office of the National Coordinator (ASTP/ONC) 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/ONC encourages all stakeholders to implement and use the standards and implementation specifications identified in the ISA as applicable to the specific interoperability needs they seek to address. Furthermore, ASTP/ONC encourages further pilot testing and industry experience to be sought with respect to standards and implementation specifications identified as “emerging” in the ISA.
The 2026 ISA Reference Edition reflects the numerous changes made across the ISA throughout 2025. To learn more about updates from previous editions, 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
SNOMED CT® U.S. Edition
Final
Production
Yes
Free
N/A
Standard for observations
LOINC®
Final
Production
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 hierarchy.
Allergy and Intolerance Type
(2.16.840.1.113883.3.88.12.3221.6.2) contains SNOMED CT
U.S. Edition
findings representing classes of reactions and intolerances.
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
SNOMED CT® U.S. Edition
Final
Production
No
Free
N/A
Standard
LOINC®
Final
Production
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
Feedback requested.
SNOMED CT U.S. Edition Allergic disposition (finding) hierarchy
(includes but is not limited to environmental allergies)
Common Environmental Substances for Allergy and Intolerance Documentation
(2.16.840.1.113762.1.4.1186.4)
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
SNOMED CT® U.S. Edition
Final
Production
No
Free
N/A
Standard
LOINC®
Final
Production
No
Free
N/A
Standard
Unique Ingredient Identifier (UNII)
Final
Production
Feedback Requested
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.
SNOMED CT U.S. Edition Allergic disposition (finding) hierarchy
(includes but is not limited to food allergies)
Food allergy (disorder)
(SNOMED CT U.S. Edition 414285001)
Food intolerance (disorder)
(SNOMED CT U.S. Edition 235719002)
SNOMED CT U.S. Common dietary substances for allergy and intolerance documentation
(2.16.840.1.113762.1.4.1186.3)
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
RxNorm
Final
Production
Yes
Free
N/A
Standard
SNOMED CT® U.S. Edition
Final
Production
Yes
Free
N/A
Standard
National Drug Code (NDC)
Final
Production
Feedback Requested
No
Free
Standard
Medication Reference Terminology (MED-RT)
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:
Clinical Drug Ingredient
(2.16.840.1.113762.1.4.1010.7) (RxNorm ingredient codes)
Representing Drug Classes for Allergy and Intolerance documentation:
SNOMED CT U.S. Edition Pharmaceutical / biologic product (product) hierarchy
SNOMED CT U.S. Edition substance and product concepts
Representing Adverse Reactions/Intolerances:
SNOMED CT U.S. Edition Allergy to drug (finding) hierarchy
Biologics
Interoperability Need: Representing Biological Products
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
ISBT 128
Final
Production
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
LOINC®
Final
Production
Yes
Free
N/A
Standard for observations
National Drug Code (NDC)
Final
Production
Yes
Free
N/A
Standard for observations
IHE FormatCode Vocabulary
Final
Production
Feedback Requested
No
Free
N/A
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.
NDC:
FDA labeling rules require NDC as stated in 21 CFR Part
201s
and
610
IHE:
See also
Integrating the Healthcare Enterprise (IHE) IT Infrastructure White Paper: Enabling Document Sharing Health Information Exchange Using IHE Profiles
LOINC:
Consult note
(LOINC code 11488-4)
Discharge summary note
(LOINC code 18842-5)
History and physical note
(LOINC code 34117-2)
Progress note
(LOINC code 11506-3)
IHE:
IHE FormatCode CodeSystem
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
LOINC®
Final
Production
Feedback Requested
No
Free
Standard
CPT®
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.
USCDI Clinical Tests Minimum Set
This value set represents a sampling of several specialty specific tests including cardiology and ophthalmology, and is not the entire universe of possible clinical test codes that may be needed for these or other specialties.
Current Procedural Terminology (CPT)
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
SNOMED CT® U.S. Edition
Final
Production
Yes
Free
N/A
Standard for observation values
LOINC®
Final
Production
Yes
Free
N/A
Standard for observation values
The Unified Code for Units of Measure
Final
Production
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
LOINC®
Final
Production
No
Free
N/A
Emerging Implementation Specification
HL7® FHIR® US Core R.4.0 – Cognitive Status
In Development
Feedback requested
Feedback Requested
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® US Core Implementation Guide (US Core IG)
This implementation specification defines minimum constraints on FHIR Resources aligning with data elements specified in USCDI. Built on FHIR R4, it is the foundation of all US Realm implementation specifications. A foundational FHIR specification, US Core uses other specifications, such as the FHIR Structured Data Capture IG and the FHIR SMART App Launch IG, to optimize existing workflows.
There are multiple versions of the US Core IG, with each version corresponding to a specific annual release of USCDI. Historically, ASTP adopted different versions of the US Core IG based on publication timing. Currently, ASTP has identified US Core Version 6.1.0 as ready for adoption in Certified Health IT in the ASTP HTI-1 Final Rule. Certified Health IT developers typically adopt the version of the US Core IG that is specified in regulation or the version approved by the National Coordinator through ASTP’s
Standards Version Advancement Process (SVAP)
For use cases that rely on data elements defined in USCDI, the US Core IG often provides the simplest and most cost-effective solution for data exchange. Additionally, the US Core IG benefits from extensive support and expertise within the standards community and among health IT developers, ensuring successful implementation and accommodating modifications when necessary.
Referenced in Federal Rulemaking:
ASTP HTI-1 Final Rule
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
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.
Cognitive Status Implementation Guide
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
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
ITU–T E.123 (02/2001) International Telecommunication Union E.123: Notation for national and international telephone numbers, e-mail addresses and web addresses
Final
Production
Yes
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
Telecom Data Elements:
Phone Number, Phone Number Type — For
§170.315 (b)(
1) Transitions of care and
§170.315 (b)(4) &
Common Clinical Data Set summary record – create
patient matching data must represent phone number (home, business, cell) in accordance with the above standards. All phone numbers must be included when multiple phone numbers are present.
Email Address — Per ITU–T E.123 (02/2001), an electronic mail address, if present, should be printed in SMTP format below the telephone number information and labeled as “E-mail,” “email,” or an easily recognized equivalent in the appropriate language. Implementations may support multiple email addresses per patient (e.g., work, personal, social).
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 Diet and Nutrition
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
Current Procedural Terminology (CPT®)
Final
Production
No
No
Standard
LOINC®
Final
Production
No
Free
N/A
Standard
NCPT (Nutrition Care Process Terminology)
Final
Production
No
N/A
Standard
SNOMED CT® U.S. Edition
Final
Production
Feedback Requested
No
Free
N/A
Standard
ICD-10-CM
Final
Production
Feedback Requested
No
Free
N/A
Standard
HCPCS
Final
Pilot
Feedback Requested
No
Free
N/A
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 insecurity.
Refer to
Allergies and Intolerances-Representing Patient Allergies and Intolerances; Food Substances
for detail on identifying allergies and intolerances related to food substances.
The Academy of Nutrition and Dietetics maintains value sets related to Nutrition.
Adult Enteral Formulas SNOMED CT
(2.16.840.1.113762.1.4.1095.5)
Food and Nutrient Delivery SNOMED CT U.S. Edition
(2.16.840.1.113762.1.4.1095.2)
Food and Nutrition Related History SNOMED CT U.S. Edition
(2.16.840.1.113762.1.4.1095.84)
Food and Nutrition Related History LOINC
(2.16.840.1.113762.1.4.1095.78)
Diet
(2.16.840.1.113883.4.642.3.255)
hl7VS-dietType
(2.16.840.1.113883.21.89)
ActDietCode
(2.16.840.1.113883.1.11.10376)
Nutrition Diagnosis Grouping
(2.16.840.1.113762.1.4.1095.85)
Encounter for screening for nutritional disorder
(Z13.21)
Nutritional anemia, unspecified
(D53.9)
CPT 97802 – 97804
: identify patient assessment and intervention of medical nutrition therapy
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
RxNorm
Final
Production
Yes
Free
N/A
Standard
National Drug Code (NDC)
Final
Production
Yes
Free
N/A
Standard
NEMSIS Version 3.4
Final
Production
No
Free
Yes
Standard
NEMSIS Version 3.5
Final
Production
No
Free
Yes
Standard
Current Procedural Terminology (CPT®)
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
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
LOINC®
Final
Production
Feedback Requested
No
Free
N/A
Standard for observation values
SNOMED CT® U.S. Edition
Final
Production
Feedback Requested
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
Many EHR systems repurpose a field originally intended for diagnosis comments to capture assessment and plan information for workflow efficiency. This practice reduces the interoperability and clinical utility of problem lists by introducing lengthy narrative summaries into problem list entries.
Problem lists are most effective when entries remain concise and problem-focused rather than serving as case summaries.
To support improved problem-oriented medical records, emphasis should be placed on the Diagnosis Comment Field, with clear guidance on its intended purpose and appropriate content as described in this interoperability need.
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
SNODENT®
Final
Production
No
Free
N/A
Standard
ICD-10 Dental Diagnosis Codes
Final
Production
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.
SNODENT is incorporated into SNOMED CT
ICD-10-CM dental codes primarily fall within the "K" chapter for diseases of the digestive system, including specific codes for conditions like gingivitis, pulpitis, dental caries, and other disorders of teeth and supporting structures.
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
SNOMED CT® U.S. Edition
Final
Production
Yes
Free
N/A
Standard
ICD-10-CM
Final
Production
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 hierarchies: 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:
ICD-9-CM Diagnostic Codes to SNOMED CT U.S. Edition
ICD-9-CM Procedure Codes to SNOMED CT U.S. Edition
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
SNOMED CT® U.S. Edition
Final
Production
Yes
Free
N/A
Standard
ICD-10-CM
Final
Production
Yes
Free
N/A
Standard
LOINC®
Final
Production
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
Implementation information for Family Health History exchange can be found in
Content/Structure: Representing Family Health History
For more information about observations and observation values, see Appendix III for an
informational resource
developed by the Health IT Standards Committee.
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 family relationships and roles:
Personal Relationship Role Type
: 2.16.840.1.113883.1.11.19563 (HL7 Terminology)
Family Member
: 2.16.840.1.113883.1.11.19579 (HL7 Terminology)
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
LOINC®
Final
Production
Yes
Free
N/A
Standard for observation values
SNOMED CT® U.S. Edition
Final
Production
No
Free
N/A
Standard for observation values
International Classification of Functioning, Disability and Health (ICF)
Final
Production
No
Free
N/A
Implementation Specification
HL7® FHIR® US Core R.4.0 – Functional Status
In Development
Feedback requested
Feedback Requested
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® US Core Implementation Guide (US Core IG)
This implementation specification defines minimum constraints on FHIR Resources aligning with data elements specified in USCDI. Built on FHIR R4, it is the foundation of all US Realm implementation specifications. A foundational FHIR specification, US Core uses other specifications, such as the FHIR Structured Data Capture IG and the FHIR SMART App Launch IG, to optimize existing workflows.
There are multiple versions of the US Core IG, with each version corresponding to a specific annual release of USCDI. Historically, ASTP adopted different versions of the US Core IG based on publication timing. Currently, ASTP has identified US Core Version 6.1.0 as ready for adoption in Certified Health IT in the ASTP HTI-1 Final Rule. Certified Health IT developers typically adopt the version of the US Core IG that is specified in regulation or the version approved by the National Coordinator through ASTP’s
Standards Version Advancement Process (SVAP)
For use cases that rely on data elements defined in USCDI, the US Core IG often provides the simplest and most cost-effective solution for data exchange. Additionally, the US Core IG benefits from extensive support and expertise within the standards community and among health IT developers, ensuring successful implementation and accommodating modifications when necessary.
Referenced in Federal Rulemaking:
ASTP HTI-1 Final Rule
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
Resources for this interoperability need include:
Social Security Association’s Disability Determination Process
American College of Occupational and Environmental Medicine
additional resources on Functional Status/Disability.
American Medical Association's “
Guides to the Evaluation of Permanent Impairment, Sixth Edition
ICF
is a World Health Organization (WHO) framework to measure health and disability for individual and population levels and supports classification of health and health-related domains.
The
CMS Data Element Library
(DEL) also 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 and Evaluation Data Set (LCDS)
Resident Assessment Instrument -
Minimum Data Set (MDS)
Outcome and Assessment Information Set (OASIS)
Functional Assessment Standardized Items (FASI)
The
PACIO Project
has developed HL7 FHIR implementation guides for the exchange of functional status and cognitive status information.
PACIO’s
Functional Status Implementation Guide (IG)
has been officially published as Standard for Trial Use specifications by HL7.
For more information about observations and observation values, see Appendix III for an
informational resource
developed by the Health IT Standards Committee.
The interoperability need is directed to cover people's functional activities at the level of the individual, including activity limitations, the ability to participate in or be involved in all areas of life, and any participation restrictions as a person or member of society.
Functional Status data elements were developed by CMS and are integrated in CMS Post Acute Care (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.
Genomics
Interoperability Need: Representing Patient Family Genomic History
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard for observations
Human Phenotype Ontology (HPO)
Final
Production
No
Free
No
Standard for observations
HGVS Nomenclature
Final
Production
No
Free
No
Standard for observations
HUGO Gene Nomenclature Committee
Final
Production
No
Free
No
Standard for observations
LOINC®
Final
Production
No
Free
No
Standard for observations
SNOMED CT® U.S. Edition
Final
Production
No
Free
No
Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
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 aligned 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:
Family Health History Genetics
Sequencing Quality and Regulatory Genomics
Activities with Global Alliance for Genomics and Health (
GA4GH
) is an international community dedicated to advancing human health through genomic data. They build technical standards and policy frameworks and tools that will expand responsible, voluntary, and secure use of genomic and other related health data.
Categorical Variation Representation Specification (Cat-VRS)
Variant Annotation Specification (VA-Spec)
The
Monarch Initiative
maintains the
Human Phenotype Ontology (HPO)
which provides a standardized vocabulary of phenotypic abnormalities encountered in human disease. Each term in the HPO describes a phenotypic abnormality.
The Human Genome Organization
(HUGO)
Gene Nomenclature Committee
maintains the HUGO Gene Nomenclature and approves gene names and symbols (short-form abbreviation) for each known human gene.
The
Human Genome Variation Society
(HGVS) Variant Nomenclature Committee (HVNC), under the auspices of the HUGO Gene Nomenclature committee maintains the
HGVS Nomenclature
The National Library of Medicine National Center for Biotechnology Information (NLM NCBI) maintains the
Reference Sequence Database
- a comprehensive, integrated, non-redundant, well-annotated set of reference sequences including genomic DNA, transcripts, and proteins.
NLM NCBI maintains
dbVAR
, a database of human genomic structural variation.
Implementation information for Family Genomic History exchange can be found in
Content/Structure
For genomic data: Specified data elements of genomics include the following:
Gene Studied
Variant Data
Variant Interpretation
Variant Type
Molecular Consequence
Variant Clinical Significance
For family relationships and roles:
Personal Relationship Role Type
: 2.16.840.1.113883.1.11.19563 (HL7 Terminology)
Family Member
: 2.16.840.1.113883.1.11.19579 (HL7 Terminology)
Interoperability Need: Representing Personal Genomic History
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard for observations
Human Phenotype Ontology (HPO)
Final
Production
No
Free
No
Standard for observations
HGVS Nomenclature
Final
Production
No
Free
No
Standard for observations
HUGO Gene Nomenclature Committee
Final
Production
No
Free
No
Standard for observations
LOINC®
Final
Production
No
Free
No
Standard for observations
SNOMED CT® U.S. Edition
Final
Production
No
Free
No
Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
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 aligned 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:
Family Health History Genetics
Sequencing Quality and Regulatory Genomics
Activities with Global Alliance for Genomics and Health (
GA4GH
) is an international community dedicated to advancing human health through genomic data. They build technical standards and policy frameworks and tools that will expand responsible, voluntary, and secure use of genomic and other related health data.
Categorical Variation Representation Specification (Cat-VRS)
Variant Annotation Specification (VA-Spec)
The
Monarch Initiative
maintains the
Human Phenotype Ontology (HPO)
which provides a standardized vocabulary of phenotypic abnormalities encountered in human disease. Each term in the HPO describes a phenotypic abnormality.
The Human Genome Organization
(HUGO)
Gene Nomenclature Committee
maintains the HUGO Gene Nomenclature and approves gene names and symbols (short-form abbreviation) for each known human gene.
The
Human Genome Variation Society
(HGVS) Variant Nomenclature Committee (HVNC), under the auspices of the HUGO Gene Nomenclature committee maintains the
HGVS Nomenclature
The National Library of Medicine National Center for Biotechnology Information (NLM NCBI) maintains the
Reference Sequence Database
- a comprehensive, integrated, non-redundant, well-annotated set of reference sequences including genomic DNA, transcripts, and proteins.
NLM NCBI maintains
dbVAR
, a database of human genomic structural variation.
Implementation information for Personal Genomic History exchange can be found in
Content/Structure
For genomic data: Specified data elements of genomics include the following:
Gene Studied
Variant Data
Variant Interpretation
Variant Type
Molecular Consequence
Variant Clinical Significance
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 observation values
SNOMED CT® U.S. Edition
Final
Production
No
Free
N/A
Standard for observations
LOINC®
Final
Production
No
Free
N/A
Standard
International Classification of Functioning, Disability and Health (ICF)
Final
Production
Feedback Requested
No
Free
No
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)
Eating - Functional Goal
89409-7
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
National Plan and Provider Enumeration System National Provider Identifier (NPI)
Final
Production
Yes
Free
N/A
Standard
National Uniform Claim Committee (NUCC) Health Care Provider Taxonomy
Final
Production
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.
NUCC Provider Codes: 2.16.840.1.113883.6.101
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
SNOMED CT® U.S. Edition
Final
Production
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
Feedback requested.
Pharmacy e-Health Information Technology Collaborative Occupations of Providers SNOMED CT U.S. Edition value set 2.16.840.1.113762.1.4.1096.129
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
HL7® V3 Vocabulary
Final
Production
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
".
Personal And Legal Relationship Role Type (VSAC OID 2.16.840.1.113883.11.20.12.1)
This value set can be used to record relationships based on personal or family ties or through legal assignment of responsibility.
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
LOINC®
Final
Production
No
Free
N/A
Standard for observation values
SNOMED CT® U.S. Edition
Final
Production
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.
Health Concern Document
(LOINC® code 75310-3)
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
LOINC®
Final
Production
Yes
Free
N/A
Standard
Current Procedural Terminology (CPT®)
Final
Production
Yes
No
Standard
RadLex®
Final
Feedback requested
Feedback Requested
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
The Radiological Society of North America (RSNA) and Regenstrief Institute completed a project in 2018 to harmonize terms for radiology procedures represented in the
LOINC and RadLex
Current Procedural Terminology
(CPT)
is a code system maintained by the American Medical Association (AMA) used to bill outpatient and office procedures.
RadLex LOINC Imaging Document Codes
Immunizations
Interoperability Need: Representing Immunizations
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
Clinical Vaccines Administered (CVX)
Final
Production
Yes
Free
N/A
Standard
National Drug Code (NDC)
Final
Production
Yes
Free
N/A
Standard
Manufacturing Vaccine Formulation (MVX)
Final
Production
No
Free
N/A
Standard
Current Procedural Terminology (CPT®)
Final
Production
No
No
Standard
RxNorm
Final
Production
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:
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.
CVX: Vaccines Administered
MVX: entire code set
NDC concepts used to represent vaccines
NDC to CVX, MVX, and CPT: Consolidated Lookup Crosswalk
NDC to Units: Table Access with NDC Unit of Use and NDC Unit of Sale
CPT®: CPT® Codes Mapped to CVX Codes
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
LOINC®
Final
Production
Feedback Requested
No
Free
N/A
Standard
SNOMED CT® U.S. Edition
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.
Laboratory identification:
Include the performing laboratory’s
CLIA ID
to support traceability and regulatory oversight.
Representing Units of Measure
Interoperability Need: Representing Laboratory Test Ordered
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
LOINC®
Final
Production
Yes
Free
N/A
Standard
CPT® Proprietary Laboratory Analyses (PLA)
Final
Production
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
LOINC®
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.
LOINC Code Rankings for Top 20,000 codes
where
the
Order/Observation attribute is
not
order only
Interoperability Need: Representing Laboratory Test Specimen
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
SNOMED CT® U.S. Edition
Final
Production
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
RxNorm
Final
Production
Yes
Free
N/A
Standard
National Drug Code (NDC)
Final
Production
Yes
Free
N/A
Standard
SNOMED CT® U.S. Edition
Final
Production
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 are 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
LOINC®
Final
Production
No
Free
N/A
Standard for observation values
SNOMED CT® U.S. Edition
Final
Production
No
Free
N/A
Standard for observation values
Unified Codes for Units of Measure (UCUM)
Final
Production
Feedback Requested
No
Free
Yes
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 hierarchies: 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.
Quantitative clinical or nursing assessment results (e.g., LOINC {Score} or other measured values) should use UCUM to represent units consistently.
For more information about observations and observation values, see Appendix III for an
informational resource
developed by the Health IT Standards Committee.
Inpatient Rehabilitation Facility Patient Assessment Instrument (IRF-PAI) - Version 2.0 [CMS Assessment]
LOINC 88329-8
Long-Term Care Hospital Continuity Assessment Record & Evaluation (CARE) Data Set (LCDS) v.4.0 [CMS Assessment]
LOINC 87509-6
Resident Assessment Instrument (RAI) Minimum Data Set (MDS) v.1.16 Nursing Home Comprehensive (NC) item set [CMS Assessment]
LOINC 88954-3
Outcome and Assessment Information Set (OASIS) - Version D - Start of Care [CMS Assessment]
LOINC
88373-6
Interoperability Need: Representing Nursing Interventions
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
SNOMED CT® U.S. Edition
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 hierarchy of SNOMED CT U.S. Edition is the terminology used for Nursing Interventions.
A resource available is a
map set from ICNP to SNOMED CT U.S. Edition
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
LOINC®
Final
Production
Feedback Requested
No
Free
N/A
Standard for observation values
SNOMED CT® U.S. Edition
Final
Production
Feedback Requested
No
Free
N/A
Standard for observation values
Unified Codes for Units of Measure (UCUM)
Final
Production
No
Free
Yes
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
SNOMED CT® U.S. Edition
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 hierarchies: 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.
Starter Set:
Nursing Problem List Subset of SNOMED CT U.S. Edition
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
SNOMED CT® U.S. Edition
Final
Production
Yes
Free
N/A
Standard
ICD-10-CM
Final
Production
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 hierarchies: Clinical finding, Situation with explicit context, and Event.
SNOMED CT U.S. Edition supports post-coordination to represent more granular clinical meaning; however, to ensure semantic interoperability, post-coordinated expressions should conform to the
SNOMED CT Compositional Grammar Specification
and the
Machine Readable Concept Model (MRCM)
For more information about observations and observation values, see Appendix III for an
informational resource
developed by the Health IT Standards Committee.
PHINVADS Problem Value Set 2.16.840.1.113883.3.88.12.3221.7.4
CORE Problem List Subset urn:oid: 2.16.840.1.113762.1.4.1018.240
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
Request for Comment (RFC) 5646
Final
Production
Feedback Requested
Yes
Free
N/A
Standard
LOINC®
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.
PHIN VADS PHVS_Language_ISO_639-2_Alpha3 (OID 2.16.840.1.114222.4.11.831)
The following questions are collected on CMS Assessments:
What is your preferred language?
LOINC 54899-0
Do you need or want an interpreter to communicate with a doctor or health care staff?
LOINC 54588-9
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
LOINC®
Final
Production
No
Free
No
Standard for observation values
SNOMED CT® U.S. Edition
Final
Production
No
Free
No
Standard
Longitudinal Maternal and Child Health Information for Research FHIR R4 Implementation Guide
Balloted Draft
Feedback requested
Feedback Requested
No
Free
No
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.
LOINC code:
82810-3 Pregnancy status
SNOMED CT U.S. Edition answer codes:
Patient currently pregnant (finding), 77386006
Not pregnant (finding), 60001007
Possible pregnancy (finding), 102874004
LOINC code:
86645-9 Pregnancy intention in the next year
LOINC Answer List
LL4053-6
Yes, I want to become pregnant, LA26438-4
I'm OK either way, LA26439-2
No, I don't want to become pregnant, LA26440-0
Unsure, LA14072-5
LOINC code:
11778-8 Estimated Delivery Date
or
21299-3 Gestational age method
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
Code on Dental Procedures and Nomenclature (CDT®)
Final
Production
No
N/A
Standard
SNODENT®
In Development
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 Medical Procedures Performed
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
SNOMED CT® U.S. Edition
Final
Production
Yes
Free
N/A
Standard
CPT®
Final
Production
Yes
N/A
Standard
HCPCS
Final
Production
Yes
Free
N/A
Standard
ICD-10-PCS
Final
Production
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
ICD-10-PCS concepts are used to report procedures in inpatient settings.
CPT and HCPCS are codes used to report procedures and services in outpatient procedures.
CPT and HCPCS concepts are used to report procedures in outpatient settings.
Feedback requested
Interoperability Need: Representing Social Care Procedures Performed
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
211 Human Services Indexing System
Final
Production
No
N/A
Standard
SNOMED CT® U.S. Edition
In Development
Feedback requested
No
Free
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
C2PA Technical Specification
In Development
Production
No
Free
Implementation Specification
HL7® FHIR® Provenance Resource
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
LOINC®
Final
Production
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.
Healthcare personnel status (LOINC 95892-6 prerelease)
Quantitative observations within this panel require units of measure and should use
UCUM
(Unified Code for Units of Measure) to ensure interoperable representation of measurement values.
Minimum Data Set (MDS) for Public Health Emergency Operations Centers (EOC) [CDC Emergency Operations Centers] (89724-9)
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
US Situational Awareness for Novel Epidemic Response (SANER)
Balloted Draft
Feedback requested
Feedback Requested
No
Free
N/A
Implementation Specification
US Situational Awareness Framework for Reporting (SAFR)
Balloted Draft
Feedback requested
Feedback Requested
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
US Situational Awareness Framework for Reporting (SAFR)
The US Situational Awareness Framework for Reporting (SAFR) establishes a standardized, FHIR-based approach to support public health decision-making during emergencies by standardizing public health organization FHIR interfaces and endpoints, automating data collection and enabling real-time data exchange, and providing a comprehensive view of health care capacity and trends.
Implementers will be able exchange information with health care facilities and report data and metrics to public health authorities and federal agencies. Implementers who are interested in the US Situational Awareness for Novel Epidemic Response (SANER) should review the US SAFR implementation guidance.
Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
Feedback requested
Feedback requested
Interoperability Need: Representing Public Health Emergency Surveillance and Situational Awareness Data
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
LOINC®
Final
Production
Yes
Free
N/A
Standard
SNOMED CT® U.S. Edition
Final
Production
Yes
Free
N/A
Standard
ICD-10-CM
Final
Production
Yes
Free
N/A
Standard
Current Procedural Terminology (CPT®)
Final
Production
Yes
N/A
Standard
HCPCS
Final
Production
Yes
Free
N/A
Standard
Clinical Vaccines Administered (CVX)
Final
Production
Yes
Free
N/A
Standard
National Drug Code (NDC)
Final
Production
Yes
Free
N/A
Implementation Specification
HL7 Version 2.5.1 Implementation Guide for Immunization Messaging, Release 1.5 2018 Update
Final
Production
No
Free
Yes
Standard
Manufacturing Vaccine Formulation (MVX)
Final
Production
No
Free
N/A
Standard
RxNorm
Final
Production
Feedback Requested
No
Free
N/A
Implementation Specification
US Situational Awareness for Novel Epidemic Response (SANER)
Final
Feedback requested
Feedback Requested
No
Free
N/A
Emerging Implementation Specification
Logica COVID-19 (FHIR v4.0.1) Implementation Guide CI Build
In Development
Feedback requested
Feedback Requested
No
Free
N/A
Implementation Specification
US Situational Awareness Framework for Reporting (SAFR)
Balloted Draft
Feedback requested
Feedback Requested
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
US Situational Awareness Framework for Reporting (SAFR)
The US Situational Awareness Framework for Reporting (SAFR) establishes a standardized, FHIR-based approach to support public health decision-making during emergencies by standardizing public health organization FHIR interfaces and endpoints, automating data collection and enabling real-time data exchange, and providing a comprehensive view of health care capacity and trends.
Implementers will be able exchange information with health care facilities and report data and metrics to public health authorities and federal agencies. Implementers who are interested in the US Situational Awareness for Novel Epidemic Response (SANER) should review the US SAFR implementation guidance.
Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
The following artifacts provide additional guidance on adopting codes, terminologies and coding guidance:
CDC Official FY2022 Coding and Reporting Guidelines for ICD-10-CM
Logica (FHIR v4.0) Implementation Guide: COVID-19
SNOMED CT U.S. Edition Coding for COVID-19 Data
Guidance for mapping to SARS-CoV-2 LOINC terms
LOINC In Vitro Diagnostic Test Code Mapping
NCPDP® Emergency Preparedness Guidance document
– This document provides guidance to the pharmacy industry for resources available during the pandemic.
The FHIR profiles in the Logica IG: COVID-19 contains FHIR profiles representing COVID-19 related data elements to support patient care, billing, research, or public reporting. The goal is to create consistent and reusable data and FHIR profiles for different COVID-19 implementation guides.
The HL7 Situational Awareness for Novel Epidemic Response (SANER) Implementation Guide enables transmission of high- level situational awareness information from inpatient facilities to centralized data repositories to support the treatment of novel influenza-like illness.
The
COVID-19 Interoperability Alliance
stewards more than 600 value sets on behalf of collaborators that include SNOMED International, Regenstrief, Logica Health, the National Association of Community Health Centers, MITRE and more. These value sets support data aggregation, analytics, population cohort identification, clinical trials, and medical research.
CDC and FDA maintain mapping of all current US approved SARS-CoV-2 invitro diagnostic lab and their corresponding specimen types and results.
CMS Press Release on HCPCS Codes for Coronavirus Lab Testing
CMS COVID-19 Vaccine Policies & Guidance
CDC COVID-19 Vaccine Data Systems
COVID-19 Related Value Sets in NLM Value Set Authority Center
LOINC terms for SARS-CoV-2 and COVID-19 related concepts
CDC Immunization Information Systems (IIS) Code Sets
AMA CPT coding and guidance for COVID-19
AMA CPT New SARS-CoV-2 Vaccine Codes
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
OMB standards for Maintaining, Collecting, and Presenting Federal Data on Race and Ethnicity, Statistical Policy Directive No. 15, Oct 30, 1997
Final
Production
Yes
Free
N/A
Standard
CDC Race and Ethnicity Code Set Version 1.3
Final
Pilot
Feedback Requested
No
Free
No
Standard
CDC Race and Ethnicity Code Set Version 1.2
Final
Production
Yes
Free
Yes
Standard
CDC Race and Ethnicity Code Set Version 1.0
Final
Production
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 update from CDC Race and Ethnicity Code Set Version 1.0 to 1.2 was a concept name correction to one concept.
The CDC Race and Ethnicity Code Set Version 1.3 updates the American Indian or Alaska Native (AIAN) category using data from the Department of the Interior, Bureau of Indian Affairs’ federally recognized tribes directory and the Department of Commerce, U.S. Census Bureau’s 2020 Census National Redistricting Data Summary File (Appendix F: Hispanic and Race Code List).
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.
Race (Category):
PHINVADS Race Category Excluding Nulls
VSAC Race Category Excluding Nulls
Race
(Note, the use of “Other Race” is discourage)
Race (Detailed):
PHINVADS Race Value Set
VSAC Race Value Set
Ethnicity (Category)
PHINVADS Ethnicity Group Value Set
VSAC Ethnicity
Ethnicity (extended set, 43 codes):
PHINVADS Detailed Ethnicity Value Set
VSAC Detailed Ethnicity
Interoperability Need: Representing Tribal Affiliation
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Implementation Specification
HL7 TribalEntityUS
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
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:
NativeEntityAlaska
NativeEntityContiguous
TribalEntityUS
urn:oid:2.16.840.1.113883.5.140
Research
Interoperability Need: Representing Data for Biomedical and Health Services Research
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
International Council for Harmonisation of Technical Requirements for Pharmaceuticals for Human Use (ICH) Medical Dictionary for Regulatory Activities (MedDRA)
Final
Production
Yes
N/A
Standard
Clinical Data Interchange Standards Consortium (CDISC) Terminology Hosted by NCI Enterprise Vocabulary Services (EVS)
Final
Production
Feedback Requested
No
Free
N/A
Standard
Observational Health Data Sciences and Informatics (OHDSI) Standardized Vocabularies
Final
Production
No
Free
Yes
Implementation Specification
HL7® FHIR® US Public Health Profiles Library Implementation Guide (USPHPL IG)
Balloted Draft
Pilot
No
Free
No
Implementation Specification
HL7® FHIR® mCODE (minimal Common Oncology Data Elements) Implementation Guide (mCODE IG)
Balloted Draft
Pilot
Feedback Requested
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® US Public Health Profiles Library Implementation Guide (USPHPL IG)
This implementation specification defines FHIR resources that represent a public health-specific dataset of common data elements required to support key public health data exchange use cases.
The FHIR resources specified in the USPHPL IG, in conjunction with the US Core IG, enable advanced data exchange capabilities, including more granular sharing of patient data. This approach reduces the implementation and maintenance burden for data exchange between healthcare organizations and public health agencies.
Health IT developers interested in adopting a FHIR-based method for electronic data transmission, using the SMART App Launch IG as an alternative to manual reporting processes, should consider implementing the USPHPL IG.
HL7® FHIR® mCODE (minimal Common Oncology Data Elements) Implementation Guide (mCODE IG)
This implementation specification defines FHIR resources specifically for oncology-related healthcare and research. It represents a significant step toward capturing a core set of structured data elements from the treatment of all cancer patients, facilitating data sharing between oncology information systems and other health IT systems.
The mCODE IG will serve as the base for future IGs, such as the published Enhancing Oncology Model, to support collecting data elements for the alternative payment model developed by the Center for Medicare and Medicaid Innovation (CMMI).
IT developers and members of the standards community interested in capturing research-quality data and improving interoperability for oncology use cases are encouraged to adopt the mCODE IG.
Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
National Cancer Institute's Enterprise Vocabulary Services
provides terminology content, tools, and services to accurately code, analyze and share cancer and biomedical research, clinical and public health information.
Common data models supporting research include but are not limited to:
Observational Medical Outcomes Partnership Common Data Model
(OMOP CDM) (supports systematic analysis of disparate observational databases)
Sentinel Common Data Model
(SCDM) (supports medical product safety and effectiveness studies)
PCORnet(R) Common Data Model
(supports capture of data insights for PCORnet participants)
Clinical Data Interchange Standards Consortium
(CDISC)
Analysis Data Model (ADaM) (analysis-ready data for research and clinical trials, required for FDA submission)
CDISC Study Data Tabulation Model (SDTM) (organizes study data into standardized domains, required for FDA submission)
Informatics for Integrating Biology and the Bedside (i2b2)
(clinical studies and trials)
Implementation information for Food Insecurity exchange can be found in
Content/Structure: Research
ResearchStudyPartyRole
(2.16.840.1.113883.4.642.3.3075)
ResearchStudyPrimaryPurposeType
(2.16.840.1.113883.4.642.1.1250)
ResearchStudyPhase
(2.16.840.1.113883.4.642.1.1247)
ResearchStudyStatus
(2.16.840.1.113883.4.642.3.819)
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
HCPCS Level II
Final
Production
No
Free
N/A
Standard for observations
LOINC®
Final
Production
Yes
Free
N/A
Standard for observation values
SNOMED CT® U.S. Edition
Final
Production
No
Free
N/A
Standard
CPT®
Final
Production
No
N/A
Standard for observation values
The Unified Code for Units of Measure
Final
Production
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.
AUDIT-C Panel:
LOINC 72109-2
AUDIT Panel: LOINC code
72110-0
HTI-1 Requirements
Interoperability Need: Representing Depression
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
LOINC®
Final
Production
Yes
Free
N/A
Standard for observation values
The Unified Code for Units of Measure
Final
Production
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.
Patient Health Questionnaire 2 (PHQ-2):
LOINC 55757-9
PHQ-9 Quick Depression Assessment Panel:
LOINC 44249-1
Patient Health Questionnaire - Somatic, Anxiety, and Active Depressive Symptoms:
LOINC
69729-2
Beck Depression Inventory Fast Screen [BDI]:
LOINC 89211-7
Beck Depression Inventory:
LOINC 89210-9
Resident mood interview (PHQ-9:)
LOINC 54635-8
HTI-1 Requirements
Interoperability Need: Representing Educational Attainment
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
LOINC®
Final
Production
Yes
Free
N/A
Standard
SNOMED CT® U.S. Edition
Final
Production
No
Free
No
Standard
ICD-10-CM
Final
Production
No
Free
No
Standard
CPT®
Final
Production
No
No
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 a LOINC code for exchanging information about the highest grade or level of school, or highest degree a person has completed. This criterion was not changed in
HTI-1
Educational attainment is defined by the
HL7® Gravity Project
as
failing to meet academic criteria for high school diploma or equivalent.
The scope of the
HL7 Gravity Project
Educational Attainment 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.
Implementation information for SDOH 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.
Less Than High School Education Screening Assessments
(LOINC)
Less Than High School Education Screening Assessments Questions
(LOINC)
Less Than High School Education Screening Assessments Answers
(LOINC)
Less Than High School Education Diagnoses
(ICD-10-CM, SNOMED CT)
Less Than High School Education Goals
(SNOMED CT)
Less Than High School Education Procedures
(CPT, SNOMED CT)
Less Than High School Education Service Requests
(CPT and SNOMED CT)
HTI-1 Requirements
Interoperability Need: Representing Elder Abuse
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
LOINC®
Final
Production
No
Free
N/A
Standard
SNOMED CT® U.S. Edition
Final
Production
No
Free
No
Standard
ICD-10-CM
Final
Production
No
Free
No
Standard
CPT®
Final
Production
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.
Elder Abuse Screening Assessments
(LOINC)
Elder Abuse Screening Assessments Questions
(LOINC)
Elder Abuse Screening Assessments Answers
(LOINC)
Elder Abuse Diagnoses
(ICD-10-CM, SNOMED CT)
Elder Abuse Goals
(SNOMED CT)
Elder Abuse Procedures
(CPT, SNOMED CT)
Elder Abuse Service Requests
(CPT, SNOMED CT)
Interoperability Need: Representing Employment Status
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
LOINC®
Final
Production
No
Free
N/A
Standard
SNOMED CT® U.S. Edition
Final
Production
No
Free
No
Standard
ICD-10-CM
Final
Production
No
Free
No
Standard
CPT®
Final
Production
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.
Unemployment Screening Assessments
(LOINC)
Unemployment Screening Assessments Questions
(LOINC)
Unemployment Screening Assessments Answers
(LOINC)
Unemployment Diagnoses
(ICD-10-CM, SNOMED CT)
Unemployment Goals
(SNOMED CT)
Unemployment Procedures
(CPT, SNOMED CT)
Unemployment Service Requests
(CPT, SNOMED CT)
Interoperability Need: Representing Financial Insecurity
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
LOINC®
Final
Production
Yes
Free
N/A
Standard
SNOMED CT® U.S. Edition
Final
Production
No
Free
No
Standard
ICD-10-CM
Final
Production
No
Free
No
Standard
CPT®
Final
Production
No
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 a LOINC code for exchanging information about a person's financial resource strain. This criterion was not changed in
HTI-1
Financial insecurity is defined by the
HL7 Gravity Project
as
a state of being wherein a person has difficulty fully meeting current and/or ongoing financial obligations and/or does not feel secure in their financial future.
The scope of the
HL7 Gravity Project
Financial Insecurity 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.
Implementation information for Financial 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.
Financial Insecurity Screening Assessments
(LOINC)
Financial Insecurity Screening Assessments Questions
(LOINC)
Financial Insecurity Screening Assessments Answers
(LOINC)
Financial Insecurity Diagnoses
(ICD-10-CM, SNOMED CT)
Financial Insecurity Goals
(SNOMED CT)
Financial Insecurity Procedures
(CPT, SNOMED CT)
Financial Insecurity Service Requests
(CPT, SNOMED CT)
HTI-1 Requirements
Interoperability Need: Representing Food Insecurity
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
LOINC®
Final
Production
No
Free
No
Standard
SNOMED CT® U.S. Edition
Final
Production
No
Free
No
Standard
ICD-10-CM
Final
Production
No
Free
No
Standard
CPT®
Final
Production
No
N/A
Standard
HCPCS Level II
Final
Production
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.
Food Insecurity Screening Assessments
(LOINC)
Food Insecurity Screening Assessments Questions
(LOINC)
Food Insecurity Screening Assessments Answers
(LOINC)
Food Insecurity Diagnoses
(ICD-10-CM, SNOMED CT)
Food Insecurity Goals
(SNOMED CT)
Food Insecurity Procedures
(CPT, HCPCS, SNOMED CT)
Food Insecurity Service Requests
(CPT, HCPCS, SNOMED CT)
Interoperability Need: Representing Health Insurance Coverage
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
LOINC®
Final
Production
No
Free
N/A
Standard
SNOMED CT® U.S. Edition
Final
Production
No
Free
No
Standard
ICD-10-CM
Final
Production
No
Free
No
Standard
CPT®
Final
Production
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.
Health Insurance Coverage Status Screening Assessments
(LOINC)
Health Insurance Coverage Status Screening Assessments Questions
(LOINC)
Health Insurance Coverage Status Screening Assessments Answers
(LOINC)
Health Insurance Coverage Status Diagnoses
(ICD-10-CM, SNOMED CT)
Health Insurance Coverage Status Goals
(SNOMED CT)
Health Insurance Coverage Status Procedures
(CPT, SNOMED CT)
Health Insurance Coverage Status Service Requests
(CPT, SNOMED CT)
Interoperability Need: Representing Homelessness
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
LOINC®
Final
Production
No
Free
No
Standard
SNOMED CT® U.S. Edition
Final
Production
No
Free
No
Standard
ICD-10-CM
Final
Production
No
Free
No
Standard
CPT®
Final
Production
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 r
esiding 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.
Homelessness Screening Assessments
(LOINC)
Homelessness Screening Assessments Questions
(LOINC)
Homelessness Screening Assessments Answers
(LOINC)
Homelessness Diagnoses
(ICD-10-CM, SNOMED CT)
Homelessness Goals
(SNOMED CT)
Homelessness Procedures
(CPT, SNOMED CT)
Homelessness Service Requests
(CPT, SNOMED CT)
Interoperability Need: Representing Housing Instability
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
LOINC®
Final
Production
No
Free
No
Standard
SNOMED CT® U.S. Edition
Final
Production
No
Free
No
Standard
ICD-10-CM
Final
Production
No
Free
No
Standard
CPT®
Final
Production
No
N/A
Standard
HCPCS Level II
Final
Production
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.
Housing Instability Screening Assessments
(LOINC)
Housing Instability Screening Assessments Questions
(LOINC)
Housing Instability Screening Assessments Answers
(LOINC)
Housing Instability Diagnoses
(ICD-10-CM, SNOMED CT)
Housing Instability Goals
(SNOMED CT)
Housing Instability Procedures
(CPT, HCPCS Level II, SNOMED CT)
Housing Instability Service Requests
(CPT, HCPCS Level II, SNOMED CT)
Interoperability Need: Representing Inadequate Housing
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
LOINC®
Final
Production
No
Free
No
Standard
SNOMED CT® U.S. Edition
Final
Production
No
Free
No
Standard
ICD-10-CM
Final
Production
No
Free
No
Standard
CPT®-4
Final
Production
No
N/A
Standard
HCPCS Level II
Final
Production
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
Inadequate housing is defined by the
HL7 Gravity Project
as having housing that does not meet habitability standards.
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 Inadequate Housing 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.
Inadequate Housing Screening Assessments
(LOINC)
Inadequate Housing Screening Assessments Questions
(LOINC)
Inadequate Housing Screening Assessments Answers
(LOINC)
Inadequate Housing Diagnoses
(ICD-10-CM, SNOMED CT)
Inadequate Housing Goals
(SNOMED CT)
Inadequate Housing Procedures
(CPT, HCPCS Level II, SNOMED CT)
Inadequate Housing Service Requests
(CPT, HCPCS Level II, SNOMED CT)
Interoperability Need: Representing Intimate Partner Violence
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
LOINC®
Final
Production
Yes
Free
N/A
Standard
SNOMED CT® U.S. Edition
Final
Production
No
Free
No
Standard
ICD-10-CM
Final
Production
No
Free
No
Standard
CPT®
Final
Production
No
N/A
Standard
The Unified Code for Units of Measure
Final
Production
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 information about exposure to violence (intimate partner violence). This criterion was not changed in
HTI-1
Intimate partner violence is defined by the
HL7 Gravity Project
as
physical violence, sexual violence, or psychological harm by a current or former partner or spouse. Often including a pattern of methods and tactics to gain and maintain power and control over the other person.
The scope of the
HL7 Gravity Project
Intimate Partner Violence 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 Intimate Partner Violence 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.
Intimate Partner Violence Screening Assessments
(LOINC)
Intimate Partner Violence Screening Assessments Questions
(LOINC)
Intimate Partner Violence Screening Assessments Answers
(LOINC)
Intimate Partner Violence Diagnoses
(ICD-10-CM, SNOMED CT)
Intimate Partner Violence Goals
(SNOMED CT)
Intimate Partner Violence Procedures
(CPT, SNOMED CT)
Intimate Partner Violence Service Requests
(CPT, SNOMED CT)
HTI-1
Requirements
Interoperability Need: Representing Material Hardship
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
LOINC®
Final
Production
No
Free
N/A
Standard
SNOMED CT® U.S. Edition
Final
Production
No
Free
No
Standard
ICD-10-CM
Final
Production
No
Free
No
Standard
CPT®
Final
Production
No
N/A
Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
Material hardship is defined by the
HL7 Gravity Project
as
the lack of specific socially perceived basic physical necessities.
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 Material Hardship 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.
Material Hardship Screening Assessments
(LOINC)
Material Hardship Screening Assessments Questions
(LOINC)
Material Hardship Screening Assessments Answers
(LOINC)
Material Hardship Diagnoses
(ICD-10-CM, SNOMED CT)
Material Hardship Goals
(SNOMED CT)
Material Hardship Procedures
(CPT, SNOMED CT)
Material Hardship Service Requests
(CPT, SNOMED CT)
Interoperability Need: Representing Medical Cost Burden
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
LOINC®
Final
Production
No
Free
N/A
Standard
SNOMED CT® U.S. Edition
Final
Production
No
Free
No
Standard
ICD-10-CM
Final
Production
No
Free
No
Standard
CPT®
Final
Production
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.
Medical Cost Burden Screening Assessments
(LOINC)
Medical Cost Burden Screening Assessments Questions
(LOINC)
Medical Cost Burden Screening Assessments Answers
(LOINC)
Medical Cost Burden Diagnoses
(ICD-10-CM, SNOMED CT)
Medical Cost Burden Goals
(SNOMED CT)
Medical Cost Burden Procedures
(CPT, SNOMED CT)
Medical Cost Burden Service Requests
(CPT, SNOMED CT)
Interoperability Need: Representing Physical Activity
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
LOINC®
Final
Production
Yes
Free
N/A
Standard
The Unified Code for Units of Measure
Final
Production
Yes
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 a person's physical activity. This criterion was not changed in
HTI-1.
SAMHSA adopted a two-question screen aligned with the LOINC codes referenced in
HTI-1
The
HL7® FHIR® Physical Activity Implementation Guide
contains value sets to represent physical activity questions, answers, interventions and measurements.
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.
HL7 FHIR Physical Activity Implementation Guide
HTI-1
Requirements
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
211 Human Services Indexing System
Final
Production
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
LOINC®
Final
Production
Yes
Free
N/A
Standard
SNOMED CT® U.S. Edition
Final
Production
No
Free
No
Standard
ICD-10-CM
Final
Production
No
Free
No
Standard
CPT®
Final
Production
No
N/A
Standard
The Unified Code for Units of Measure
Final
Production
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.
Social Connection Screening Assessments
(LOINC)
Social Connection Screening Assessments Questions
(LOINC)
Social Connection Screening Assessments Answers
(LOINC)
Social Connection Diagnoses
(ICD-10-CM, SNOMED CT)
Social Connection Goals
(SNOMED CT)
Social Connection Procedures
(CPT, SNOMED CT)
Social Connection Service Requests
(CPT, SNOMED CT)
HTI-1 Requirements
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
SNOMED CT® U.S. Edition
Final
Production
Yes
Free
Standard
ICD-10-CM
Final
Production
Yes
Free
Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
Social Determinants of Health (SDOH) conditions and diagnoses are SDOH-related problems, concerns, conditions, or diagnoses, often determined by screening assessments of an SDOH-related risk.
The
HL7 Gravity Project
defined value sets to represent SDOH Problems and Health Concerns.
SNOMED CT U.S. Edition
is used for SDOH conditions.
ICD-10-CM
is used for SDOH diagnoses.
Implementation information for SDOH conditions and diagnoses exchange can be found in
Structure and Exchange of Social Determinants of Health Information
A white paper developed by National Council for Prescription Drug Programs (NCPDP),
Collecting and Exchanging Social Determinants of Health Data in the Pharmacy
provides guidance on the use of ICD-10-CM and SNOMED CT US Edition codes within the NCPDP SCRIPT and Telecommunication Standards, as well as the Pharmacist eCare Plan.
Social Determinants of Health Conditions
(SNOMED CT and ICD-10-CM)
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
SNOMED CT® U.S. Edition
Final
Production
Yes
Free
N/A
Standard for observations
LOINC®
Final
Production
Yes
Free
N/A
Standard
International Classification of Functioning, Disability and Health (ICF)
Final
Production
Feedback Requested
No
Free
No
Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
Social Determinants of Health (SDOH) Goals are the desired future state for an identified SDOH-related concern, condition, or diagnosis.
The
HL7 Gravity Project
established and maintains value sets representing SDOH Goals.
SNOMED CT
U.S. Edition
is used to represent SDOH Goals.
Implementation information for SDOH goals exchange can be found in
Structure and Exchange of Social Determinants of Health Information
Social Determinants of Health Goals
(SNOMED CT)
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
SNOMED CT® U.S. Edition
Final
Production
Yes
Free
N/A
Standard
CPT®
Final
Production
Yes
Standard
HCPCS Level II
Final
Production
Yes
Free
Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
Social Determinants of Health (SDOH) Interventions are actions or services to address an identified SDOH-related concern, condition, or diagnosis.
The
HL7 Gravity Project
established and maintains current value sets which represent SDOH Interventions.
Implementation information for SDOH interventions exchange can be found in
Structure and Exchange of Social Determinants of Health Information
SNOMED CT
U.S. Edition
CPT
and
HCPCS Level II
are used to represent procedures and interventions.
Social Determinants of Health Service Requests
(SNOMED CT, CPT, HCPCS Level II)
Social Determinants of Health Procedures
(SNOMED CT, CPT, HCPCS Level II)
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
LOINC®
Final
Production
Yes
Free
No
Standard
SNOMED CT® U.S. Edition
Final
Production
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.
Social Determinants of Health Screening Assessments
(LOINC)
Interoperability Need: Representing Stress
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
LOINC®
Final
Production
Yes
Free
N/A
Standard
SNOMED CT® U.S. Edition
Final
Production
No
Free
No
Standard
ICD-10-CM
Final
Production
No
Free
No
Standard
CPT®
Final
Production
No
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 a LOINC code for exchanging information about the level of stress a person is experiencing. This criterion was not changed in
HTI-1
Stress is defined by the
HL7 Gravity Project
as occurring when a person perceives the demands of environmental stimuli to be greater than their ability to meet, mitigate, or alter those demands.
The scope of the
HL7 Gravity Project
Stress 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.
Implementation information for Stress 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.
Stress Screening Assessments
(LOINC)
Stress Screening Assessments Questions
(LOINC)
Stress Screening Assessments Answers
(LOINC)
Stress Diagnoses
(ICD-10-CM, SNOMED CT)
Stress Goals
(SNOMED CT)
Stress Procedures
(CPT, SNOMED CT)
Stress Service Requests
(CPT, SNOMED CT)
HTI-1 Requirements
Interoperability Need: Representing Substance Use
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
ICD-10-CM
Final
Production
No
Free
No
Standard
HCPCS Level II
Final
Production
No
Free
No
Standard
LOINC®
Final
Production
Yes
Free
No
Standard
SNOMED CT® U.S. Edition
Final
Production
No
Free
No
Standard
CPT®
Final
Production
No
No
Standard
The Unified Code for Units of Measure
Final
Production
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
LOINC®
Final
Production
No
Free
No
Standard
ICD-10-CM
Final
Production
No
Free
No
Standard
SNOMED CT® U.S. Edition
Final
Production
No
Free
No
Standard
HCPCS Level II
Final
Production
No
Free
Standard
CPT®
Final
Production
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.
Transportation Insecurity Screening Assessments
(LOINC)
Transportation Insecurity Screening Assessments Questions
(LOINC)
Transportation Insecurity Screening Assessments Answers
(LOINC)
Transportation Insecurity Diagnoses
(ICD-10-CM, SNOMED CT)
Transportation Insecurity Goals
(SNOMED CT)
Transportation Insecurity Procedures
(CPT, HCPCS, SNOMED CT)
Transportation Insecurity Service Requests
(CPT, HCPCS, SNOMED CT)
Interoperability Need: Representing Veteran Status
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
LOINC®
Final
Production
No
Free
N/A
Standard
SNOMED CT® U.S. Edition
Final
Production
No
Free
No
Standard
ICD-10-CM
Final
Production
No
Free
No
Standard
CPT®
Final
Production
No
N/A
Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
A “veteran” is defined by statute as an individual who served and completed active military, naval, air, or space service, which includes:
Active duty;
Any period of active duty for training during which the individual was disabled or died from a disease or injury incurred or aggravated in line of duty; and
Any period of inactive duty training during which the individual was disabled or died
from an injury incurred or aggravated in line of duty; or
from an acute myocardial infarction, a cardiac arrest, or a cerebrovascular accident occurring during such training
38 U.S.C. § 101(24)
).
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 SNOMED CT are used for SDOH interventions and procedures.
Implementation information for Veteran Status exchange can be found in
Structure and Exchange of Social Determinants of Health Information
The
HL7® FHIR® Implementation Guide: Military Service History and Status, Release 1 – US Realm (STU1)
provides a FHIR extension to support exchange of Veteran Status, including the Patient profile (
US Veteran
) and the
USVeteranStatus
extension.
For more information about observations and observation values, see Appendix III for an
informational resource
developed by the Health IT Standards Committee.
Veteran Status Screening Assessments
(LOINC)
Veteran Status Screening Assessments Questions
(LOINC)
Veteran Status Screening Assessments Answers
(LOINC)
Veteran Status Diagnoses
(ICD-10-CM, SNOMED CT)
Veteran Status Goals
(SNOMED CT)
Veteran Status Procedures
(CPT, SNOMED CT)
Veteran Status Service Requests
(CPT, SNOMED CT)
HL7 FHIR Implementation Guide: Military Service History and Status Release 1 - US Realm | STU1
US Veteran Status
Veteran Status
Military Service Episode
Deployment History Episode
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
SNOMED CT® U.S. Edition
Final
Production
No
Free
N/A
Standard for observation values
LOINC®
Final
Production
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.
SmokingStatusComprehensive:
2.16.840.1.113762.1.4.1267.3
SmokingStatusType:
2.16.840.1.113762.1.4.1267.6
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
LOINC®
Final
Production
No
Free
N/A
Standard for observation values
SNOMED CT® U.S. Edition
Final
Production
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.
SmokingStatusComprehensive:
2.16.840.1.113762.1.4.1267.3
SmokingStatusType:
2.16.840.1.113762.1.4.1267.6
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
LOINC®
Final
Production
No
Free
N/A
Standard for observation values
SNOMED CT® U.S. Edition
Final
Production
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.
SmokingStatusComprehensive:
2.16.840.1.113762.1.4.1267.3
SmokingStatusType:
2.16.840.1.113762.1.4.1267.6
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
The Unified Code for Units of Measure (UCUM)
Final
Production
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
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
LOINC®
Final
Production
Yes
Free
N/A
Standard
SNOMED CT® U.S. Edition
Final
Production
No
Free
N/A
Standard
International Standards Organization/Institute of Electrical and Electronics Engineers (ISO/IEEE) 11073-00101-2008
Final
Production
No
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 result values.
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.
The IEEE Personal_Health_Device Working Group (under the
IEEE 11073 Standards Committee
, EMB/11073) develops and maintains standards for personal health device communication, including standardized nomenclature.
Vital Sign Result urn: oid:2.16.840.1.113883.3.88.12.80.62
LOINC standard applies to USCDI required vital signs:
Systolic Blood Pressure
Diastolic Blood Pressure
Average Blood Pressure
Heart Rate
Respiratory Rate
Body Temperature
Body Height
Body Weight
Pulse Oximetry
Inhaled Oxygen Concentration
BMI Percentile (2 - 20 years)
Weight-for-length Percentile (Birth - 24 Months)
Head Occipital-frontal Circumference Percentile (Birth - 36 Months)
Work Information
Interoperability Need: Representing Occupation and Occupation Industry
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard for observations
LOINC®
Final
Production
No
Free
N/A
Standard for observation values
Occupational Data for Health (ODH) Code System
Final
Production
Yes
Free
No
Implementation Specification
HL7 EHRS-FM Release 2: Functional Profile; Work and Health, Release 1 – US Realm
Balloted Draft
Feedback requested
Feedback Requested
No
Free
No
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.
Representing Industry:
PHVS_Industry_NAICS_Detail_ODH (urn:oid: 2.16.840.1.114222.4.11.7900)
Representing Occupation:
PHVS_Occupation_CDC_ONETSOC_Detail_ODH (urn: oid: 2.16.840.1.114222.4.11.7901
Representing Employment Status:
PHVS_EmploymentStatus_ODH (urn:oid: 2.16.840.1.114222.4.11.7129)
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
HL7® 2.5.1 (or later) ADT message
Final
Production
No
Free
No
Standard
NCPDP Specialized Standard, Implementation Guide, Version 2017071
Final
Production
No
No
Standard
NCPDP Specialized Standard, Implementation Guide, Version 2023011
Final
Production
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-server 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
HL7® 2.5.1 (or later) ADT message
Final
Production
No
Free
No
Implementation Specification
IHE Patient Administration Management (PAM) Integration Profile
Final
Feedback requested
Feedback Requested
No
Free
No
Implementation Specification
HL7 FHIR® DaVinci Unsolicited Notifications Implementation Guide
Balloted Draft
Pilot
No
Free
No
Implementation Specification
ANSI/DS 2020-03-100-2022 - Event Notifications via the Direct Standard™ Release Version 1.0
Final
Production
No
Free
No
Emerging Implementation Specification
Carequality Subscription Implementation Guide for Push Notifications
Balloted Draft
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
IHE-PDQ (Patient Demographics Query)
Final
Production
Feedback Requested
No
Free
Yes
Yes
Yes
Implementation Specification
IHE-XCPD (Cross-Community Patient Discovery)
Final
Production
Feedback Requested
No
Free
Yes
Yes
Implementation Specification
Carequality Query-Based Document Exchange Implementation Guide
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
HL7® CDA® R2 Implementation Guide: ePOLST: Portable Medical Orders About Resuscitation and Initial Treatment, Release 1 - US Realm
Balloted Draft
Pilot
No
Free
No
Emerging Implementation Specification
PACIO Advance Directive Interoperability Implementation Guide
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
HL7® Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Release 2.1
Balloted Draft
Production
Feedback Requested
No
Free
Yes
Implementation Specification
HL7 CDA R2 IG: C‐CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2 ‐ US Realm
Balloted Draft
Production
Feedback Requested
No
Free
No
Implementation Specification
HL7 CDA R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 3 - US Realm
Balloted Draft
Production
Feedback Requested
No
Free
No
Emerging Implementation Specification
360X and Long Term Care Transfers
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
HL7® Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Release 2.1
Balloted Draft
Production
Yes
Free
Yes
Implementation Specification
HL7 CDA R2 IG: C‐CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2 ‐ US Realm
Balloted Draft
Production
Feedback Requested
No
Free
No
Implementation Specification
HL7 CDA R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 3 - US Realm
Balloted Draft
Production
Feedback Requested
No
Free
No
Emerging Implementation Specification
IHE Patient Care Coordination Technical Framework Supplement: 360 Exchange - Closed Loop Referral (360X) Rev. 1.1 – Trial Implementation
Balloted Draft
Production
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
HL7® FHIR® R4: Observation Resource
Final
Production
No
Free
No
Emerging Standard
HL7 FHIR R4: Messaging
Balloted Draft
Feedback requested
Feedback Requested
No
Free
No
Emerging Standard
HL7 FHIR R4: ServiceRequest Resource
Balloted Draft
Feedback requested
Feedback Requested
No
Free
No
Emerging Standard
HL7 FHIR R4: Task Resource
Balloted Draft
Feedback requested
Feedback Requested
No
Free
No
Emerging Implementation Specification
HL7 Bidirectional Services eReferrals (BSeR) FHIR IG
In Development
Feedback requested
Feedback Requested
No
Free
No
Emerging Implementation Specification
360X and Social Determinants of Health (SDoH) Referrals
In Development
Pilot
Feedback Requested
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® Release 4.0.1 (R4)
The baseline FHIR standard version provides foundational FHIR Resources that are stable, mature, and backwards compatible, referred to as “Normative”. These resources form the base standard and are constrained into FHIR Profiles by implementation specifications, ensuring consistent implementation necessary for interoperability.
While a newer version, FHIR Release 5 (FHIR R5), has been balloted, all current implementation specifications adopted by federal regulations are based on FHIR R4.
The standards community is actively working towards releasing FHIR Release 6 (FHIR R6) in 2026. FHIR R6 is expected to include more FHIR Resources designated as Normative.
Unless there is a compelling need for a use case that requires functionality exclusive to FHIR R5, it is recommended that any new standards development activities and implementations continue to be based on FHIR Release 4.0.1 to ensure alignment with current federal regulations.
Referenced in Federal Rulemaking:
ASTP Cures Act Final Rule
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
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
here
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
HL7® FHIR® US Core R.3.0 - Care Plan Profile
Final
Production
No
Free
N/A
Implementation Specification
Argonaut Data Query Implementation Guide v1.0.0 (based on FHIR R2)
Final
Production
Yes
Free
Implementation Specification
HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Release 2.1
Balloted Draft
Production
Yes
Free
Yes
Implementation Specification
HL7 C-CDA on FHIR Care Plan
Final
Production
No
Free
No
Implementation Specification
HL7 CDA R2 IG: C‐CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2 ‐ US Realm
Balloted Draft
Production
Feedback Requested
No
Free
No
Implementation Specification
HL7 CDA R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 3 - US Realm
Balloted Draft
Production
Feedback Requested
No
Free
No
Emerging Implementation Specification
HL7 FHIR US Core R.4.0 - Care Plan Profile
In Development
Feedback requested
Feedback Requested
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® US Core Implementation Guide (US Core IG)
This implementation specification defines minimum constraints on FHIR Resources aligning with data elements specified in USCDI. Built on FHIR R4, it is the foundation of all US Realm implementation specifications. A foundational FHIR specification, US Core uses other specifications, such as the FHIR Structured Data Capture IG and the FHIR SMART App Launch IG, to optimize existing workflows.
There are multiple versions of the US Core IG, with each version corresponding to a specific annual release of USCDI. Historically, ASTP adopted different versions of the US Core IG based on publication timing. Currently, ASTP has identified US Core Version 6.1.0 as ready for adoption in Certified Health IT in the ASTP HTI-1 Final Rule. Certified Health IT developers typically adopt the version of the US Core IG that is specified in regulation or the version approved by the National Coordinator through ASTP’s
Standards Version Advancement Process (SVAP)
For use cases that rely on data elements defined in USCDI, the US Core IG often provides the simplest and most cost-effective solution for data exchange. Additionally, the US Core IG benefits from extensive support and expertise within the standards community and among health IT developers, ensuring successful implementation and accommodating modifications when necessary.
Referenced in Federal Rulemaking:
ASTP HTI-1 Final Rule
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
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
here
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
HL7® FHIR® US Core R.3.0 - Care Plan Profile
Final
Production
No
Free
No
Implementation Specification
HL7 C-CDA on FHIR Care Plan
Final
Production
No
Free
No
Implementation Specification
HL7 CDA® R2 Implementation Guide: Pharmacist Care Plan Document, Release 1 - US Realm, Volume 1
Final
Production
No
Free
Yes
Implementation Specification
NCPDP® Pharmacist eCare Plan Version 1.0 Guidance on the Use of the HL7 CDA Consolidated Templates for Clinical Notes R2.1 Care Plan
Final
Production
No
No
Implementation Specification
HL7 Implementation Guide for CDA Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Release 2.1
Balloted Draft
Production
Yes
Free
No
Implementation Specification
HL7 CDA R2 IG: C‐CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2 ‐ US Realm
Balloted Draft
Production
Feedback Requested
No
Free
No
Implementation Specification
HL7 CDA R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 3 - US Realm
Balloted Draft
Production
Feedback Requested
No
Free
No
Emerging Implementation Specification
HL7 FHIR Pharmacist Care Plan Implementation Guide, US Realm
Balloted Draft
Pilot
Feedback Requested
No
Free
No
Emerging Implementation Specification
HL7 FHIR US Core R.4.0 - Care Plan Profile
In Development
Production
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® US Core Implementation Guide (US Core IG)
This implementation specification defines minimum constraints on FHIR Resources aligning with data elements specified in USCDI. Built on FHIR R4, it is the foundation of all US Realm implementation specifications. A foundational FHIR specification, US Core uses other specifications, such as the FHIR Structured Data Capture IG and the FHIR SMART App Launch IG, to optimize existing workflows.
There are multiple versions of the US Core IG, with each version corresponding to a specific annual release of USCDI. Historically, ASTP adopted different versions of the US Core IG based on publication timing. Currently, ASTP has identified US Core Version 6.1.0 as ready for adoption in Certified Health IT in the ASTP HTI-1 Final Rule. Certified Health IT developers typically adopt the version of the US Core IG that is specified in regulation or the version approved by the National Coordinator through ASTP’s
Standards Version Advancement Process (SVAP)
For use cases that rely on data elements defined in USCDI, the US Core IG often provides the simplest and most cost-effective solution for data exchange. Additionally, the US Core IG benefits from extensive support and expertise within the standards community and among health IT developers, ensuring successful implementation and accommodating modifications when necessary.
Referenced in Federal Rulemaking:
ASTP HTI-1 Final Rule
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
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
HL7® FHIR® Electronic Long-Term Services and Supports (eLTSS) Release 1 - US Realm
Balloted Draft
Pilot
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
HL7® FHIR® US Core R.3.0 - Care Plan Profile
Final
Production
No
Free
No
Implementation Specification
HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Release 2.1
Balloted Draft
Production
Yes
Free
Yes
Implementation Specification
HL7 C-CDA on FHIR Care Plan
Final
Production
No
Free
Implementation Specification
IHE Quality, Research, and Public Health Technical Framework Supplement, Early Hearing Detection and Intervention (EHDI), Rev 2.1 Trial Implementation
Balloted Draft
Pilot
No
Free
No
Implementation Specification
HL7 CDA R2 Implementation Guide: Personal Advance Care Plan Document, Release 1 - US Realm
Balloted Draft
Pilot
No
Free
No
Implementation Specification
HL7 CDA R2 IG: C‐CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2 ‐ US Realm
Balloted Draft
Production
Feedback Requested
No
Free
No
Implementation Specification
HL7 CDA R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 3 - US Realm
Balloted Draft
Production
Feedback Requested
No
Free
No
Emerging Implementation Specification
HL7 FHIR US Core R.4.0 - Care Plan Profile
In Development
Feedback requested
Feedback Requested
No
Free
No
Emerging Implementation Specification
MCC eCare Plan Implementation Guide
Balloted Draft
Pilot
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® US Core Implementation Guide (US Core IG)
This implementation specification defines minimum constraints on FHIR Resources aligning with data elements specified in USCDI. Built on FHIR R4, it is the foundation of all US Realm implementation specifications. A foundational FHIR specification, US Core uses other specifications, such as the FHIR Structured Data Capture IG and the FHIR SMART App Launch IG, to optimize existing workflows.
There are multiple versions of the US Core IG, with each version corresponding to a specific annual release of USCDI. Historically, ASTP adopted different versions of the US Core IG based on publication timing. Currently, ASTP has identified US Core Version 6.1.0 as ready for adoption in Certified Health IT in the ASTP HTI-1 Final Rule. Certified Health IT developers typically adopt the version of the US Core IG that is specified in regulation or the version approved by the National Coordinator through ASTP’s
Standards Version Advancement Process (SVAP)
For use cases that rely on data elements defined in USCDI, the US Core IG often provides the simplest and most cost-effective solution for data exchange. Additionally, the US Core IG benefits from extensive support and expertise within the standards community and among health IT developers, ensuring successful implementation and accommodating modifications when necessary.
Referenced in Federal Rulemaking:
ASTP HTI-1 Final Rule
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
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
HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Release 2.1
Balloted Draft
Production
Yes
Free
No
Implementation Specification
HL7® FHIR® US Core R.3.0 - Care Plan Profile
Final
Production
No
Free
No
Implementation Specification
HL7 C-CDA on FHIR Care Plan
Final
Production
No
Free
Implementation Specification
IHE Dynamic Care Planning (DCP), Rev 1.2 Trial Implementation
Balloted Draft
Pilot
No
Free
No
Implementation Specification
IHE Dynamic Care Team Management (DCTM), Rev 1.1 Trial Implementation
Balloted Draft
Pilot
No
Free
Implementation Specification
HL7 CDA R2 IG: C‐CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2 ‐ US Realm
Balloted Draft
Production
Feedback Requested
No
Free
No
Implementation Specification
HL7 CDA R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 3 - US Realm
Balloted Draft
Production
Feedback Requested
No
Free
No
Emerging Implementation Specification
HL7 FHIR US Core R.4.0 - Care Plan Profile
In Development
Feedback requested
Feedback Requested
No
Free
No
Emerging Implementation Specification
MCC eCare Plan Implementation Guide
Balloted Draft
Pilot
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® US Core Implementation Guide (US Core IG)
This implementation specification defines minimum constraints on FHIR Resources aligning with data elements specified in USCDI. Built on FHIR R4, it is the foundation of all US Realm implementation specifications. A foundational FHIR specification, US Core uses other specifications, such as the FHIR Structured Data Capture IG and the FHIR SMART App Launch IG, to optimize existing workflows.
There are multiple versions of the US Core IG, with each version corresponding to a specific annual release of USCDI. Historically, ASTP adopted different versions of the US Core IG based on publication timing. Currently, ASTP has identified US Core Version 6.1.0 as ready for adoption in Certified Health IT in the ASTP HTI-1 Final Rule. Certified Health IT developers typically adopt the version of the US Core IG that is specified in regulation or the version approved by the National Coordinator through ASTP’s
Standards Version Advancement Process (SVAP)
For use cases that rely on data elements defined in USCDI, the US Core IG often provides the simplest and most cost-effective solution for data exchange. Additionally, the US Core IG benefits from extensive support and expertise within the standards community and among health IT developers, ensuring successful implementation and accommodating modifications when necessary.
Referenced in Federal Rulemaking:
ASTP HTI-1 Final Rule
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
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
IHE: Clinical Decision Support Order Appropriateness Tracking (CDS-OAT)
Balloted Draft
Pilot
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
HL7® FHIR® CDS Hooks Implementation Guide (CDS Hooks IG)
Balloted Draft
Production
No
Free
Yes
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® CDS Hooks Implementation Guide (CDS Hooks IG)
This implementation specification describes a “hook”-based pattern for invoking or triggering an external decision support from within a health IT solution, including Certified Health IT. This pattern enables clinicians to integrate results from a clinical decision support (CDS) tool directly into their workflow or to launch an interactive application for clinical decision support.
The CDS Hooks IG provides a more advanced interaction than simply invoking a third-party application, making it an advanced use of FHIR APIs. Implementing CDS Hooks requires clients, typically Certified Health IT systems, to support "hooks" at specific points within the electronic health record (EHR) workflow to facilitate seamless integration.
Organizations interested in implementing CDS Hooks should evaluate the CDS Hooks IG to enable native or third-party applications, provided their Certified Health IT system supports CDS Hooks as a client and includes the necessary "hooks" within the workflow.
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
HL7® Standard: Clinical Quality Language Specification, Release 1, R5 (CQL 1.5)
Final
Production
No
Free
Yes
Standard
HL7 FHIR® Clinical Reasoning Module, FHIR STU Release 4B
Final
Production
No
Free
Yes
Standard
HL7 FHIR CDS Hooks Implementation Guide (CDS Hooks IG)
Balloted Draft
Production
No
Free
Yes
Emerging Standard
HL7 FHIR 5 Clinical Reasoning Module
Balloted Draft
Pilot
No
Free
N/A
Standard
HL7 FHIR Profile: Quality (QI Core), STU 4
Balloted Draft
Pilot
No
Free
Yes
Standard
HL7 FHIR QI-Core Implementation Guide 4.1.0
Final
Production
No
Free
N/A
Emerging Standard
HL7 FHIR QI-Core Implementation Guide 5.0.0 - STU5
Final
Production
No
Free
N/A
Implementation Specification
Clinical Practice Guidelines, STU 2
Balloted Draft
Pilot
No
Free
Yes
Emerging Implementation Specification
Common CQL Artifacts for FHIR (US-Based)
Balloted Draft
Pilot
Feedback Requested
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7 FHIR CDS Hooks Implementation Guide (CDS Hooks IG)
This implementation specification describes a “hook”-based pattern for invoking or triggering an external decision support from within a health IT solution, including Certified Health IT. This pattern enables clinicians to integrate results from a clinical decision support (CDS) tool directly into their workflow or to launch an interactive application for clinical decision support.
The CDS Hooks IG provides a more advanced interaction than simply invoking a third-party application, making it an advanced use of FHIR APIs. Implementing CDS Hooks requires clients, typically Certified Health IT systems, to support "hooks" at specific points within the electronic health record (EHR) workflow to facilitate seamless integration.
Organizations interested in implementing CDS Hooks should evaluate the CDS Hooks IG to enable native or third-party applications, provided their Certified Health IT system supports CDS Hooks as a client and includes the necessary "hooks" within the workflow.
HL7 FHIR Quality Improvement Core Implementation Guide (QI-Core IG)
This implementation specification provides requirements and guidance for using FHIR in quality measurement and decision support. It defines standardized profiles derived from FHIR resources described in the US Core IG, creating a consistent data set for use across various quality measures.
Each annual version of the QI-Core IG builds upon the corresponding version of the US Core IG, which aligns with updates to USCDI.
The QI-Core IG serves as a foundational resource for Certified Health IT developers and the broader quality improvement community. It is particularly valuable for those interested in leveraging FHIR for applications focused on quality measurement and reporting.
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
Note that the FHIR Maturity Model and each of the levels is described
here
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
HL7® Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Release 2.1
Final
Production
Feedback Requested
Yes
Free
Yes
Implementation Specification
HL7 CDA R2 IG: C‐CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2 ‐ US Realm
Balloted Draft
Production
Feedback Requested
Yes
Free
Yes
Implementation Specification
HL7 CDA R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 3 - US Realm
Balloted Draft
Production
Feedback Requested
No
Free
Yes
Implementation Specification
HL7 FHIR® US Core Implementation Guide (US Core IG)
Balloted Draft
Feedback requested
Feedback Requested
Yes
Free
Yes
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® US Core Implementation Guide (US Core IG)
This implementation specification defines minimum constraints on FHIR Resources aligning with data elements specified in USCDI. Built on FHIR R4, it is the foundation of all US Realm implementation specifications. A foundational FHIR specification, US Core uses other specifications, such as the FHIR Structured Data Capture IG and the FHIR SMART App Launch IG, to optimize existing workflows.
There are multiple versions of the US Core IG, with each version corresponding to a specific annual release of USCDI. Historically, ASTP adopted different versions of the US Core IG based on publication timing. Currently, ASTP has identified US Core Version 6.1.0 as ready for adoption in Certified Health IT in the ASTP HTI-1 Final Rule. Certified Health IT developers typically adopt the version of the US Core IG that is specified in regulation or the version approved by the National Coordinator through ASTP’s
Standards Version Advancement Process (SVAP)
For use cases that rely on data elements defined in USCDI, the US Core IG often provides the simplest and most cost-effective solution for data exchange. Additionally, the US Core IG benefits from extensive support and expertise within the standards community and among health IT developers, ensuring successful implementation and accommodating modifications when necessary.
Referenced in Federal Rulemaking:
ASTP HTI-1 Final Rule
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
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
HL7® Clinical Document Architecture (CDA®), Release 2.0, Final Edition
Final
Production
No
Free
No
Standard
HL7 FHIR R4 Clinical Reasoning STU Release 4
Balloted Draft
Production
No
Free
Yes
Implementation Specification
CMS Implementation Guide for Quality Reporting Document Architecture: Category III; Eligible Clinicians Programs; Implementation Guide for 2023
Final
Production
Yes
Free
Yes
Implementation Specification
HL7 CDA R2 Implementation Guide: Quality Reporting Document Architecture - Category III (QRDA III) STU Release 2.1
Balloted Draft
Production
Yes
Free
Yes
Implementation Specification
HL7® FHIR® Data Exchange for Quality Measures Implementation Guide
Balloted Draft
Pilot
No
Free
Yes
Implementation Specification
HL7® FHIR® National Healthcare Safety Network (NHSN) Digital Quality Measure (dQM) Reporting
Balloted Draft
Production
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® Data Exchange for Quality Measures Implementation Guide
This specification aims to reduce the burden of reporting, improve the accuracy, quality, and validity of submitted data, and enhance the speed and efficiency of the reporting process.
HL7® FHIR® National Healthcare Safety Network (NHSN) Digital Quality Measure (dQM) Reporting
To support CDC’s data modernization effort, the HL7® FHIR® National Healthcare Safety Network (NHSN) Digital Quality Measure (dQM) Reporting IG specifies the electronic submission of digital quality measures to the NHSN, a CDC infection tracking surveillance system.
The NHSN dQM builds on previous work from the Quality Measure Implementation Guide and the Data Exchange for Quality Measures Implementation Guide. By implementing this specification, users will minimize the burden of reporting; improve reporting accuracy, quality and validity; and increase speed and efficiency. The specification focuses on leveraging data from existing Certified Health IT APIs, including the HL7® FHIR® US Core IG.
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
CMS Implementation Guide for Quality Reporting Document Architecture: Category I; Hospital Quality Reporting; Implementation Guide for 2022
Final
Production
Feedback Requested
Yes
Free
Yes
Implementation Specification
HL7® CDA® R2 Implementation Guide: Quality Reporting Document Architecture I (QRDA I) Release 1, STU Release 5.1 with Errata (US Realm)
Balloted Draft
Production
Yes
Free
Yes
Implementation Specification
HL7 CDA R2 Implementation Guide: Quality Reporting Document Architecture I (QRDA I) Release 1, STU Release 5.2 with Errata (US Realm)
Balloted Draft
Production
Yes
Free
Yes
Implementation Specification
HL7® FHIR® Data Exchange for Quality Measures Implementation Guide
Balloted Draft
Pilot
Yes
Free
No
Implementation Specification
HL7® FHIR® National Healthcare Safety Network (NHSN) Digital Quality Measure (dQM) Reporting
Balloted Draft
Production
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® Data Exchange for Quality Measures Implementation Guide
This specification aims to reduce the burden of reporting, improve the accuracy, quality, and validity of submitted data, and enhance the speed and efficiency of the reporting process.
HL7® FHIR® National Healthcare Safety Network (NHSN) Digital Quality Measure (dQM) Reporting
To support CDC’s data modernization effort, the HL7® FHIR® National Healthcare Safety Network (NHSN) Digital Quality Measure (dQM) Reporting IG specifies the electronic submission of digital quality measures to the NHSN, a CDC infection tracking surveillance system.
The NHSN dQM builds on previous work from the Quality Measure Implementation Guide and the Data Exchange for Quality Measures Implementation Guide. By implementing this specification, users will minimize the burden of reporting; improve reporting accuracy, quality and validity; and increase speed and efficiency. The specification focuses on leveraging data from existing Certified Health IT APIs, including the HL7® FHIR® US Core IG.
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
Testing tools for FHIR and QRDA-based quality reporting are available:
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
HL7® V3: Representation of the Health Quality Measures Format (eMeasure), DSTU Release 2.1
Final
Production
No
Free
Yes
Standard
HL7 Standard: Clinical Quality Language Specification, Release 1, R5 (CQL 1.5)
Final
Production
No
Free
Yes
Standard
HL7 Cross-Paradigm Specification: CQL Release 1 STU 4
Balloted Draft
Production
No
Free
Yes
Standard
HL7 FHIR® Clinical Reasoning STU Release 3
Balloted Draft
Production
No
Free
Yes
Standard
HL7 CQL-based HQMF Implementation Guide STU 4 based on HQMF R1
In Development
Production
No
Free
Yes
Standard
HL7 FHIR Clinical Reasoning STU Release 4
In Development
Pilot
Feedback Requested
No
Free
Implementation Specification
HL7 CQL-based HQMF, Release 2 DSTU 3 (based on HQMF 2.1 - US Realm
Balloted Draft
Production
No
Free
Yes
Implementation Specification
HL7® FHIR® Quality Improvement Core Implementation Guide (QI-Core IG)
Balloted Draft
Production
No
Free
Yes
Implementation Specification
HL7® FHIR® Quality Measure Implementation Guide
Balloted Draft
Production
No
Free
Yes
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® Quality Improvement Core Implementation Guide (QI-Core IG)
This implementation specification provides requirements and guidance for using FHIR in quality measurement and decision support. It defines standardized profiles derived from FHIR resources described in the US Core IG, creating a consistent data set for use across various quality measures.
Each annual version of the QI-Core IG builds upon the corresponding version of the US Core IG, which aligns with updates to USCDI.
The QI-Core IG serves as a foundational resource for Certified Health IT developers and the broader quality improvement community. It is particularly valuable for those interested in leveraging FHIR for applications focused on quality measurement and reporting.
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
here
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
HL7® FHIR® Provenance Resource
Balloted Draft
Production
No
Free
No
Implementation Specification
IHE IT Infrastructure Technical Framework
Final
Production
No
Yes – Open
Implementation Specification
HL7 FHIR US Core IG - Provenance Profile
Final
Production
Feedback Requested
Yes
Free
Yes
Implementation Specification
HL7 C-CDA Companion Guide: Provenance Author Participation Template
Final
Production
Feedback Requested
Yes
Free
Implementation Specification
HL7 CDA® Release 2 Implementation Guide Data Provenance, Release 1 - US Realm
Balloted Draft
Pilot
No
Free
Yes – Open
Emerging Implementation Specification
Basic Provenance Implementation Guide
Balloted Draft
Pilot
Feedback Requested
No
Free
No
Emerging Implementation Specification
C2PA Technical Specification
In Development
Production
No
Free
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® US Core Implementation Guide (US Core IG)
This implementation specification defines minimum constraints on FHIR Resources aligning with data elements specified in USCDI. Built on FHIR R4, it is the foundation of all US Realm implementation specifications. A foundational FHIR specification, US Core uses other specifications, such as the FHIR Structured Data Capture IG and the FHIR SMART App Launch IG, to optimize existing workflows.
There are multiple versions of the US Core IG, with each version corresponding to a specific annual release of USCDI. Historically, ASTP adopted different versions of the US Core IG based on publication timing. Currently, ASTP has identified US Core Version 6.1.0 as ready for adoption in Certified Health IT in the ASTP HTI-1 Final Rule. Certified Health IT developers typically adopt the version of the US Core IG that is specified in regulation or the version approved by the National Coordinator through ASTP’s
Standards Version Advancement Process (SVAP)
For use cases that rely on data elements defined in USCDI, the US Core IG often provides the simplest and most cost-effective solution for data exchange. Additionally, the US Core IG benefits from extensive support and expertise within the standards community and among health IT developers, ensuring successful implementation and accommodating modifications when necessary.
Referenced in Federal Rulemaking:
ASTP HTI-1 Final Rule
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
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
here
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:
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
HL7® Version 3 Standard: Diet and Nutrition, STU Release 1
Balloted Draft
Pilot
No
Free
Yes
Implementation Specification
HL7 CDA® R2 Implementation Guide: C-CDA R2.1 Supplemental Templates for Nutrition, Release 1 (US Realm)
Balloted Draft
Pilot
No
Free
No
Emerging Standard
HL7 FHIR® Nutrition Order Resource
Balloted Draft
Pilot
No
Free
Yes
Emerging Standard
HL7 FHIR Nutrition Intake Resource
In Development
Pilot
Feedback Requested
No
Free
No
Emerging Standard
HL7 FHIR Nutrition Product Resource
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
Interoperability Need: Representing Patient Family Health History
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Implementation Specification
HL7® FHIR® R4 - Resource FamilyMemberHistory
Balloted Draft
Feedback requested
No
Free
No
Implementation Specification
HL7 FHIR R4 Implementation Guidance: Genomics
Final
Production
No
Free
No
Implementation Specification
Consolidated CDA (C-CDA) 5.0.0-ballot - STU5 - Ballot 1
Balloted Draft
Feedback requested
No
Free
No
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
The Family Health History Data Class was added to USCDI v6 with the inclusion of the
Family Health History Data Element
. This data element is defined as Family member health condition(s) that are relevant to a patient's care. (
Standard Bulletin 2025-2
The
HL7 Clinical Genomics Work Group
has a Project Scope Statement (PSS) that was approved to develop a
FHIR IG for Family Health History
HL7 Version 3 Implementation Guide: Family History/Pedigree Interoperability, Release 1
is an informative document for the exchange of Family History/Pedigree information.
Feedback Requested
Genomics
Interoperability Need: Representing Patient Family Genomic History
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Implementation Specification
Molecular Definition Implementation Guide for Molecular Data Types
In Development
Feedback requested
No
Free
No
Implementation Specification
HL7® FHIR® Genomics Reporting Implementation Guide (Genomics Reporting IG)
Final
Feedback requested
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® Genomics Reporting Implementation Guide (Genomics Reporting IG)
HL7® FHIR® Genomics Reporting Implementation Guide (Genomics Reporting IG) is an implementation specification for reporting genomic data in an interoperable manner using FHIR standard.
The Genomics Reporting IG aims to provide standardized guidance by providing examples of genomic data reporting including:
Simple, structural, complex, and gross genomic variations
Well known and de novo genomic variations
Germline and somatic genomic variations
Genomic variations in disease pathology
Genomic variations for pharmacology purposes
Genomic variations for transplant suitability
Full and partial genome sequencing
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
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 aligned 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:
Family Health History Genetics
Sequencing Quality and Regulatory Genomics
Activities with Global Alliance for Genomics and Health (
GA4GH
) is an international community dedicated to advancing human health through genomic data. They build technical standards and policy frameworks and tools that will expand responsible, voluntary, and secure use of genomic and other related health data.
Categorical Variation Representation Specification (Cat-VRS)
Variant Annotation Specification (VA-Spec)
HL7 Version 3 Implementation Guide: Family History/Pedigree Interoperability, Release 1
is an informative document for the exchange of Family History/Pedigree information.
Any use/sharing of genomic data must follow processes in line with:
The Genetic Information Nondiscrimination Act (GINA,
The Health Insurance Portability and Accountability Act (HIPAA,
Interoperability Need: Representing Personal Genomic History
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Implementation Specification
Molecular Definition Implementation Guide for Molecular Data Types
In Development
Feedback requested
No
Free
No
Implementation Specification
HL7® FHIR® Genomics Reporting Implementation Guide (Genomics Reporting IG)
Final
Feedback requested
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® Genomics Reporting Implementation Guide (Genomics Reporting IG)
HL7® FHIR® Genomics Reporting Implementation Guide (Genomics Reporting IG) is an implementation specification for reporting genomic data in an interoperable manner using FHIR standard.
The Genomics Reporting IG aims to provide standardized guidance by providing examples of genomic data reporting including:
Simple, structural, complex, and gross genomic variations
Well known and de novo genomic variations
Germline and somatic genomic variations
Genomic variations in disease pathology
Genomic variations for pharmacology purposes
Genomic variations for transplant suitability
Full and partial genome sequencing
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
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 aligned 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:
Family Health History Genetics
Sequencing Quality and Regulatory Genomics
Activities with Global Alliance for Genomics and Health (
GA4GH
) is an international community dedicated to advancing human health through genomic data. They build technical standards and policy frameworks and tools that will expand responsible, voluntary, and secure use of genomic and other related health data.
Categorical Variation Representation Specification (Cat-VRS)
Variant Annotation Specification (VA-Spec)
The
HL7 Clinical Genomics Work Group
has a Project Scope Statement (PSS) that was approved to develop a
FHIR IG for Family Health History
Any use/sharing of genomic data must follow processes in line with:
The Genetic Information Nondiscrimination Act (GINA,
The Health Insurance Portability and Accountability Act (HIPAA,
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
IHE Quality, Research and Public Health Technical Framework Supplement – Healthy Weight (HW)
Balloted Draft
Pilot
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
Human Services Data Specification (HSDS)
Final
Production
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.
Interoperability Need: Structure and Exchange of Social Determinants of Health Information
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Implementation Specification
HL7 FHIR® US Core Implementation Guide
Final
Production
Yes
Free
Yes – Open
Implementation Specification
HL7 CDA® R2 IG: C-CDA Templates for Clinical Notes STU Companion Guide Release 4.1
Final
Production
Yes
Free
Yes – Open
Implementation Specification
HL7 FHIR Social Determinants of Health Clinical Care Implementation Guide (SDOH CC IG)
Final
Production
Feedback Requested
No
Free
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
Gravity Project
Social Determinants of Health (SDOH) seeks to identify data elements and associated value sets to represent SDOH information documented in electronic health records (EHRs) across four clinical activities: screening, diagnosis, goal setting, and intervention activities. Data elements and value sets are created and curated through a consensus
HL7 FHIR Accelerator™
Project, with the charter to develop the data standards to address SDOH. For more details about the Gravity Project see the
Gravity Project Confluence site
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
Digital Imaging and Communications in Medicine (DICOM®)
Final
Production
No
Free
Yes
Implementation Specification
PS3.20 Digital Imaging and Communications in Medicine (DICOM) Standard – Part 20: Imaging Reports using HL7® Clinical Document Architecture®
Final
Production
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-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: 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
DICOM® PS3.3 2017e A.35.8 X-Ray Radiation Dose SR IOD
Final
Production
No
Free
Yes – Open
Implementation Specification
IHE Radiation Exposure Monitoring (REM)
Final
Production
No
Free
Yes – Open
Implementation Specification
DICOM PS3.3 2017e A.35.14 Radiopharmaceutical Radiation Dose SR IOD
Final
Pilot
No
Free
Yes – Open
Implementation Specification
IHE Radiation Exposure Monitoring for Nuclear Medicine (REM-NM)
Balloted Draft
Pilot
No
Free
No
Implementation Specification
DICOM PS3.3 2017e A.35.18.1 Patient Radiation Dose SR IOD
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 6
For 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
IHE Results Distribution (RD)
Balloted Draft
Pilot
No
Free
Yes
Implementation Specification
IHE Management of Radiology Report Templates (MRRT)
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
Digital Imaging and Communications in Medicine (DICOM®)
Final
Production
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
CLSI AUTO 16 - Next-Generation In Vitro Diagnostic Interface, 1st Edition
Final
Pilot
No
Yes
Standard
IVD Industry Connectivity Consortium: LIVD – Digital Format for Publication of LOINC to Vendor IVD Test Results V2.0
Final
Production
Yes
Free
No
Implementation Specification
IHE LAW – Laboratory Analytical Workflow Profile
Final
Production
No
Free
Yes
Implementation Specification
HL7® FHIR® Implementation Guide - LOINC/IVD Mapping (LIVD) R1 (STU 1)
Balloted Draft
Pilot
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:
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.
LIVD
provides guidance for representing in vitro diagnostic test orders
See ISA section
Units of Measure
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
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
Final
Production
Yes
Free
Yes
Implementation Specification
HL7 Version 2.5.1 Implementation Guide: Laboratory Results Interface, Release 1 STU Release 4 - US Realm
Final
Pilot
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.
HL7 Version 2 Implementation Guide: Laboratory Value Set Companion Guide, Release 2 - US Realm
provides cross-implementation guide value set definitions and harmonized requirements.
See ISA section
Representing Laboratory Result Values
Interoperability Need: Order Laboratory Test
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Implementation Specification
HL7® Version 2.5.1 Implementation Guide: Laboratory Orders from EHR (LOI) Release 1, STU Release 4 - US Realm
Final
Pilot
No
Free
No
Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
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.
It is used as a resource by laboratories when setting up their catalog and order messages.
HL7 Version 2 Implementation Guide: Laboratory Value Set Companion Guide, Release 2 - US Realm
This companion guide provides cross-implementation guide value set definitions and harmonized requirements.
See ISA section
Representing Laboratory Test Ordered
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
HL7® Version 2.5.1 Implementation Guide: S&I Framework Laboratory Test Compendium Framework, Release 2, DSTU Release 3 (also referred to as eDOS (Electronic Directory of Service)
Final
Production
No
Free
No
Implementation Specification
HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Test Compendium Framework (eDOS) Release 2, STU Release 3.1 (US Realm) (Also referred to as eDOS (Electronic Directory of Service))
Final
Production
No
Free
No
Implementation Specification
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
Final
Pilot
No
Free
No
Emerging Implementation Specification
HL7 FHIR® Order Catalog Implementation Guide/Laboratory Services 0.1.1
Balloted Draft
Pilot
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.
HL7 Version 2 Implementation Guide: Laboratory Value Set Companion Guide, Release 2 - US Realm
provides cross-implementation guide value set definitions and harmonized requirements.
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
IHE-PCD (Patient Care Device Profiles)
Final
Production
No
Free
Yes
Implementation Specification
ITU H.810, H.811, H.812, H.812.5, and H.813
Final
Production
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 guidance 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
HL7® Version 3 Standard: Context Aware Knowledge Retrieval Application. (“Infobutton”), Knowledge Request, Release 2.
Final
Production
Yes
Free
No
Implementation Specification
HL7 Implementation Guide: Service-Oriented Architecture Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain, Release 1.
Final
Production
Yes
Free
No
Implementation Specification
HL7 Version 3 Implementation Guide: Context-Aware Knowledge Retrieval (Infobutton), Release 4.
Final
Production
Yes
Free
No
Emerging Implementation Specification
HL7® FHIR® CDS Hooks Implementation Guide (CDS Hooks IG)
Balloted Draft
Pilot
No
Free
Yes
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® CDS Hooks Implementation Guide (CDS Hooks IG)
This implementation specification describes a “hook”-based pattern for invoking or triggering an external decision support from within a health IT solution, including Certified Health IT. This pattern enables clinicians to integrate results from a clinical decision support (CDS) tool directly into their workflow or to launch an interactive application for clinical decision support.
The CDS Hooks IG provides a more advanced interaction than simply invoking a third-party application, making it an advanced use of FHIR APIs. Implementing CDS Hooks requires clients, typically Certified Health IT systems, to support "hooks" at specific points within the electronic health record (EHR) workflow to facilitate seamless integration.
Organizations interested in implementing CDS Hooks should evaluate the CDS Hooks IG to enable native or third-party applications, provided their Certified Health IT system supports CDS Hooks as a client and includes the necessary "hooks" within the workflow.
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
HL7® 2.9.1 (or later) ADT message
Final
Production
No
Free
Yes
Implementation Specification
IHE-PDQ (Patient Demographic Query)
Final
Production
No
Free
Yes
Yes
Yes
Implementation Specification
IHE-PIX (Patient Identifier Cross-Reference)
Final
Production
No
Free
Yes
Yes
Standard
IHE Cross-Community Patient Discovery (XCPD)
Final
Production
No
Free
Yes
Emerging Implementation Specification
IHE-PDQm (Patient Demographics Query for Mobile)
Balloted Draft
Pilot
No
Free
Yes
Yes
Emerging Implementation Specification
IHE-PIXm (Patient Identifier Cross-reference for Mobile)
Balloted Draft
Pilot
No
Free
Yes
Yes
Emerging Implementation Specification
Implementation Guide for Expressing Context in Direct™ Messaging
Balloted Draft
Pilot
No
Free
No
Emerging Implementation Specification
HL7® FHIR® FAST Interoperable Digital Identity and Patient Matching Implementation Guide
Balloted Draft
Feedback requested
Feedback Requested
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® FAST Interoperable Digital Identity and Patient Matching Implementation Guide
This implementation guide is designed to establish best practices and standards for digital identity and person matching. This specification provides detailed guidance on defining the match operation used in cross-organizational FHIR data exchanges, supporting accurate identity management and person matching.
Health IT developers and those that are interested in scaling FHIR are encouraged to follow the work being conducted by the
FAST Accelerator
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
Chapter 3 of the HL7 Standard 2.9.1 named "Patient Administration" is the relevant chapter for Clinical and Administrative Domains.
The Implementation Guide for Expressing Context in Direct Messaging is 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-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: Representing Patient Address
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Implementation Specification
Project US@ Technical Specification, Version 1.0
Final
Production
Feedback Requested
Yes
Free
No
Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
In-scope:
United States domestic and military patient addresses.
Out-of-scope:
addresses related to healthcare providers, facilities, and most international locations, except for some guidance on Canadian addresses.
Project US@ leverages the USPS Publication 28 address standard as a foundation with the addition of specific constraints and metadata for improved patient matching in healthcare.
Project US@ does not obligate health care systems to modify or update existing data in any way.
For guidance and best practices on the capture and management of patient addresses to support conformance to Project US@, see the
AHIMA Project US@ Companion Guide.
Feedback requested
Interoperability Need: Representing Patient Names
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
AHIMA Naming Policy Framework 2023: Enhancing Person Matching with Essential Demographic Data Elements
Final
Pilot
No
Free
No
Limitations, Dependencies, and Preconditions for Consideration
Applicable Value Set(s) and Starter Set(s)
HL7® product families define standardized data types for representing person names: Version 2 specifies Extended Person Name (XPN) and Person Name (PN); CDA defines PersonName (PN); and FHIR defines the HumanName data type.
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
IHE Basic Patient Privacy Consents (BPPC)
Final
Production
No
Free
Yes
Implementation Specification
HL7® Implementation Guide for CDA®, Release 2: Consent Directives, Release 1
Final
Pilot
No
Free
N/A
Emerging Standard
HL7 FHIR® Consent Resource
In Development
Pilot
No
Free
Yes
Emerging Standard
HL7 FHIR Contract Resource
In Development
Pilot
No
Free
Yes
Emerging Implementation Specification
IHE Advanced Patient Privacy and Consents (APPC)
Balloted Draft
Pilot
No
Free
Yes
Implementation Specification
Specialty Medication Enrollment FHIR IG
Final
Pilot
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
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-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).
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
NCPDP® SCRIPT Standard, Implementation Guide, Version 2017071
Final
Production
Yes
Yes
Implementation Specification
NCPDP SCRIPT Standard, Implementation Guide, Version 2023011
Final
Pilot
Feedback Requested
No
No
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
NCPDP SCRIPT Standard, Implementation Guide, Version 2017071
Final
Production
Yes
Yes
Implementation Specification
NCPDP SCRIPT Standard, Implementation Guide, Version 2023011
Final
Pilot
Feedback Requested
No
No
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
NCPDP® SCRIPT Standard, Implementation Guide, Version 2017071
Final
Production
Yes
Yes
Implementation Specification
NCPDP SCRIPT Standard, Implementation Guide, Version 2023011
Final
Pilot
Feedback Requested
No
No
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
NCPDP® SCRIPT Standard, Implementation Guide, Version 2017071
Final
Production
Yes
Yes
Implementation Specification
NCPDP SCRIPT Standard, Implementation Guide, Version 2023011
Final
Pilot
Feedback Requested
No
No
Implementation Specification
HL7® FHIR® Medication Request
Final
Feedback requested
Feedback Requested
No
Free
No
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
NCPDP® SCRIPT Standard, Implementation Guide, Version 2017071
Final
Production
Yes
Yes
Implementation Specification
NCPDP SCRIPT Standard, Implementation Guide, Version 2023011
Final
Pilot
Feedback Requested
No
No
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
NCPDP SCRIPT Standard, Implementation Guide, Version 2017071
Final
Production
No
Yes
Implementation Specification
NCPDP SCRIPT Standard, Implementation Guide, Version 2023011
Final
Pilot
Feedback Requested
No
No
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 is originated by the transferring pharmacy once the 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
NCPDP® SCRIPT Standard, Implementation Guide, Version 2017071
Final
Production
Yes
Yes
Implementation Specification
NCPDP SCRIPT Standard, Implementation Guide, Version 2023011
Final
Pilot
Feedback Requested
No
No
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
NCPDP® SCRIPT Standard, Implementation Guide, Version 2017071
Final
Production
Yes
Yes
Implementation Specification
NCPDP SCRIPT Standard, Implementation Guide, Version 2023011
Final
Pilot
Feedback Requested
No
No
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
NCPDP® SCRIPT Standard, Implementation Guide, Version 2017071
Final
Production
Yes
Yes
Implementation Specification
NCPDP SCRIPT Standard, Implementation Guide, Version 2023011
Final
Pilot
Feedback Requested
No
No
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
NCPDP® SCRIPT Standard, Implementation Guide, Version 2017071
Final
Production
No
Yes
Implementation Specification
NCPDP SCRIPT Standard, Implementation Guide, Version 2023011
Final
Pilot
Feedback Requested
No
No
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
NCPDP Structured and Codified Sig Format Implementation Guide Version 2.2
Final
Production
No
No
Implementation Specification
NCPDP® SCRIPT Standard, Implementation Guide, Version 2017071
Final
Production
Yes
Yes
Implementation Specification
NCPDP SCRIPT Standard, Implementation Guide, Version 2023011
Final
Pilot
Feedback Requested
No
No
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.
LOINC® 2.63 codes supporting SCRIPT 2017071 segment:
8302-2 Body height, measured [LOINC]
3141-9 Body weight, measured [LOINC]
3140-1 Body surface area, derived [LOINC]
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
NCPDP® SCRIPT Standard, Implementation Guide, Version 2017071
Final
Production
Yes
Yes
Implementation Specification
NCPDP SCRIPT Standard, Implementation Guide, Version 2023011
Final
Pilot
Feedback Requested
No
No
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 t
he 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
ASC X12®
Final
Production
No
No
Implementation Specification
NCPDP® SCRIPT Standard, Implementation Guide Version 2017071
Final
Production
Yes
Yes
Implementation Specification
NCPDP Formulary and Benefits Standard, Version 3
Final
Production
Yes
No
Implementation Specification
NCPDP SCRIPT Standard, Implementation Guide, Version 2023011
Final
Pilot
Feedback Requested
No
No
Implementation Specification
NCPDP Formulary and Benefits Standard, Version 60
Final
Pilot
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 2023011 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 2023011)
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
NCPDP® SCRIPT Standard, Implementation Guide, Version 2017071
Final
Production
Yes
Yes
Implementation Specification
NCPDP SCRIPT Standard, Implementation Guide, Version 10.6
Final
Production
No
N/A
Implementation Specification
HL7® FHIR® Medication Request
Final
Feedback requested
Feedback Requested
No
Free
No
Implementation Specification
NCPDP SCRIPT Standard, Implementation Guide, Version 2023011
Final
Pilot
Feedback Requested
No
No
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
HL7®, Version 2
Final
Production
No
Free
No
Implementation Specification
NCPDP® SCRIPT Standard, Implementation Guide, Version 2017071
Final
Production
No
No
Implementation Specification
NCPDP SCRIPT Standard, Implementation Guide, Version 2023011
Final
Pilot
Feedback Requested
No
No
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
PMIX *, Version 2
Final
Production
No
Free
No
Standard
SMART® on FHIR®
Final
Production
No
Free
Yes
Standard
HL7 FHIR CDS Hooks Implementation Guide (CDS Hooks IG)
Final
Production
No
Free
Yes
Implementation Specification
NCPDP® SCRIPT Standard Implementation Guide Version 2017071
Final
Production
No
No
Standard
HL7®, Version 2
Final
Production
Feedback Requested
No
Free
No
Implementation Specification
HL7 FHIR® Implementation Guide: US Meds STU2
Balloted Draft
Pilot
Feedback Requested
No
Free
No
Implementation Specification
NCPDP SCRIPT Standard, Implementation Guide, Version 2023011
Final
Pilot
Feedback Requested
No
No
Emerging Standard
HL7 FHIR SMART App Launch Implementation Guide (SMART App Launch IG)
Final
Production
Feedback Requested
No
Free
Yes
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® CDS Hooks Implementation Guide (CDS Hooks IG)
This implementation specification describes a “hook”-based pattern for invoking or triggering an external decision support from within a health IT solution, including Certified Health IT. This pattern enables clinicians to integrate results from a clinical decision support (CDS) tool directly into their workflow or to launch an interactive application for clinical decision support.
The CDS Hooks IG provides a more advanced interaction than simply invoking a third-party application, making it an advanced use of FHIR APIs. Implementing CDS Hooks requires clients, typically Certified Health IT systems, to support "hooks" at specific points within the electronic health record (EHR) workflow to facilitate seamless integration.
Organizations interested in implementing CDS Hooks should evaluate the CDS Hooks IG to enable native or third-party applications, provided their Certified Health IT system supports CDS Hooks as a client and includes the necessary "hooks" within the workflow.
HL7® FHIR® SMART App Launch Implementation Guide (SMART App Launch IG)
This implementation specification specifies how applications connect to FHIR APIs by requesting authorization from OAuth 2.0-compliant authorization servers. It outlines the process by which an application requests authorization to access a FHIR resource and subsequently uses that authorization to retrieve the resource.
There are multiple versions of the SMART App Launch IG, all of which are compatible with FHIR Release 4 (R4). Historically, ASTP has adopted different versions of the SMART App Launch IG based on publication timing. Currently, ASTP has identified Version 2.0.0 as ready for adoption in Certified Health IT under the ASTP HTI-1 Final Rule. Certified Health IT developers typically adopt the version specified in program requirements or the version approved by the National Coordinator through ASTP’s Standards Version Advancement Process (SVAP).
The SMART App Launch IG facilitates a persistent application authorization process and adds a security layer to FHIR API deployments, addressing both FHIR server and FHIR application perspectives. This makes the SMART App Launch IG a foundational specification for any FHIR API implementation requiring secure access to FHIR Resources.
Referenced in Federal Rulemaking:
ASTP HTI-1 Final Rule
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
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 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
2015 ASAP Prescription Monitoring Program Web Service Standard 2.1A
Final
Production
No
Free
No
Standard
2011 ASAP Version 4.2 Standard for Prescription Monitoring Programs
Final
Production
No
Free
No
Standard
PMIX,* Version 2
Final
Production
No
Free
No
Standard
2010 ASAP Prescription Monitoring Program Standards Versions 1.0 for PMP Zero Reports and Error Reports
Final
Production
No
Free
No
Implementation Specification
NIEM, Version 3.2
Final
Production
No
Free
No
Standard
2017 ASAP Version 4.2A Standard for Prescription Monitoring Programs
Final
Production
No
Free
No
Standard
HL7®, Version 2
Final
Production
Feedback Requested
No
Free
No
Standard
NCPDP® Telecommunication Standard,Version D.0
Final
Production
Feedback Requested
No
No
Standard
2020 ASAP Version 4.2B Standard for Prescription Monitoring Programs
Final
Pilot
Feedback Requested
No
Free
No
Implementation Specification
NCPDP SCRIPT Standard Implementation Guide Version 2017071
Final
Production
No
No
Implementation Specification
NCPDP Prescription Drug Monitoring Programs Reporting Standard, Implementation Guide, Version 12
Final
Production
Feedback Requested
No
No
Implementation Specification
HL7 FHIR® Implementation Guide: US Meds STU2
Balloted Draft
Pilot
Feedback Requested
No
Free
No
Implementation Specification
NCPDP SCRIPT Standard, Implementation Guide, Version 2023011
Final
Pilot
Feedback Requested
No
No
Implementation Specification
NCPDP Telecommunication Standard, Version F6
Final
Pilot
Feedback Requested
No
No
Implementation Specification
2023 ASAP Version 5.0 Standard for Prescription Drug Monitoring Programs
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 Prescriber Systems to Receive Formulary and Benefit Information from Payers or Their Benefit Managers
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Implementation Specification
NCPDP® Formulary and Benefit Standard Version 3.0
Final
Production
Yes
No
Implementation Specification
NCPDP Real Time Prescription Benefit Standard Version 12
Final
Production
No
No
Implementation Specification
NCPDP Formulary and Benefits (F&B), Version 60
Final
Production
Feedback Requested
No
No
Implementation Specification
NCPDP Real-Time Prescription Benefit (RTPB) Standard, Implementation Guide, Version 13
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-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 Prescriber Systems to Receive Patient-Specific Real-Time Prescription Benefit Information from Payers or Their Benefit Managers
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Implementation Specification
Real-Time Prescription Benefit Standard Implementation Guide Version 13
Final
Pilot
Feedback Requested
Yes
No
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
The following transactions need to be implemented for interoperability purposes:
RTPB v13
RTPBRequest, originated from the prescriber to request:
patient eligibility
product coverage
benefit financials for a chosen product and pharmacy
RTPBResponse, originated from the pharmacy benefit payers/processors to respond:
To a RTPB request from a prescriber.
This communication identifies coverage restrictions, and alternatives when they exist.
Both the prescriber and the payer/processor/pharmacy benefits manager (PBM) must have their systems configured for these transactions to facilitate successful exchange, including the ability to send or receive status or error messages.
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
HL7® FHIR® Profiles for Transfusion and Vaccination Adverse Event Detection and Reporting IG
Balloted Draft
Pilot
No
Free
No
Implementation Specification
HL7® FHIR® Adverse Event Clinical Research R4 Backport IG
Final
Feedback requested
Feedback Requested
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® Profiles for Transfusion and Vaccination Adverse Event Detection and Reporting IG
This implementation specification provides a framework for reporting adverse events following transfusions and vaccinations using FHIR resources. These resources include the necessary information required by the Food and Drug Administration (FDA) for decision-making and have been successfully piloted through the
BEST Innovative Methods Exchange Platform
Health IT developers seeking to adopt a FHIR-based approach to electronically transmit adverse event data should consider implementing the Transfusion and Vaccination AE IG. This specification helps reduce manual reporting processes, streamline data submission, and ensure accurate and timely reporting of adverse events to support regulatory and public health efforts.
HL7® FHIR® Adverse Event Clinical Research R4 Backport IG
The HL7® FHIR® Adverse Event Clinical Research R4 Backport IG is the R4 Backport version. Implementers should refer to this version of the HL7 FHIR specification for the Adverse Event resource if the implementer’s Certified Health IT is configured to HL7 FHIR R4.
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
HL7 CDA R2 Implementation Guide: Reportability Response, Release 1, STU Release 1.1 - US Realm
Balloted Draft
Production
No
Free
Yes – Open
Implementation Specification
IHE-XDR (Cross-Enterprise Document Reliable Interchange)
Final
Production
No
Free
Yes
Implementation Specification
HL7 CDA® R2 Implementation Guide: Public Health Case Report – the Electronic Initial Case Report (eICR) Release 2, STU Release 1.1 – US Realm
Balloted Draft
Production
No
Free
Yes
Implementation Specification
Applicability Statement for Secure Health Transport Version 1.3
Final
Production
No
Free
Yes
Implementation Specification
HL7® CDA® R2 Implementation Guide: Public Health Case Report - the Electronic Initial Case Report (eICR) Release 2, STU Release 3.1 - US Realm
Balloted Draft
Production
No
Free
Yes
Implementation Specification
HL7 FHIR® Implementation Guide: Electronic Case Reporting (eCR) - 2.1.2 - STU 2
Final
Production
Feedback Requested
Yes
Free
Yes
Implementation Specification
HL7® FHIR® Electronic Case Reporting Implementation Guide (eCR IG) - 3.0.0-ballot - STU 3 Ballot
Balloted Draft
Pilot
Feedback Requested
No
Free
Yes
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® Electronic Case Reporting Implementation Guide (eCR IG)
This implementation specification supports the exchange of case data and bidirectional communication of public health information, focusing on a patient’s condition and local disease trends. As part of the
Public Health Data Strategy
, electronic case reporting is prioritized as a key automation to reduce administrative burden and promote more complete and timely data exchange.
The eCR IG enables the use of FHIR-based solutions aligned with FHIR R4 and the US Core IG for transmitting electronic case reports and reportability responses. It also facilitates the consumption and processing of electronic case reporting trigger codes, which are matched against the Reportable Conditions Trigger Code (RCTC) value set specified in the eCR IG.
While there are multiple versions of the eCR IG, ASTP has identified version 2.1.0 as most ready for adoption in Certified Health IT.
Referenced in Federal Rulemaking:
ASTP HTI-1 Final Rule
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:
Early Hearing Detection and Intervention (EHDI
Office of Populations Affairs (OPA) Family Planning Reporting IHE
Profile
Note that the maturity level of FHIR resources may vary. The FHIR Maturity Model and each of the levels is described
here
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
IHE Quality, Research, and Public Health Technical Framework Supplement Family Planning Version 2 (FPv2) Rev. 1.1 – Trial Implementation
Balloted Draft
Pilot
No
Free
No
Implementation Specification
Family Planning Annual Report (FPAR) 2.0
Balloted Draft
Production
Feedback Requested
No
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
Visit the
Office of Population Affairs (OPA) website
for more information about the Family Planning Annual Report.
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
HL7® Version 2.5.1: Implementation Guide: Electronic Laboratory Reporting to Public Health (US Realm), Release 1 with Errata and Clarifications and ELR 2.5.1 Clarification Document for EHR Technology Certification
Final
Production
Yes
Free
Yes
Implementation Specification
HL7 Version 2.5.1 Implementation Guide: Laboratory Results Interface, Release 1 STU Release 4 - US Realm
Final
Production
No
Free
No
Emerging Standard
FHIR® US Lab Report
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.
HL7 Version 2 Implementation Guide: Laboratory Value Set Companion Guide Release 2 - US Realm
provides cross-implementation guide value set definitions and harmonized requirements.
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
HL7 2.5.1 Implementation Guide for Immunization Messaging, Release 1.5
Final
Production
Yes
Free
Yes
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, and obtain a jurisdictional implementation guide if applicable.
There is near universal adoption of the transport standard
CDC-EHR-IIS Interoperability Enhancement Project Transport Layer Protocol Recommendation Formal Specification, Version 1.2
, though stakeholders should still confirm accepted processes with the health department in their jurisdiction.
HL7 Version 2.5.1 Implementation Guide for Immunization Messaging, Release 1.5 2018 Update
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
IHE Quality, Research, and Public Health Technical Framework Supplement Newborn Admission Notification Information (NANI) Rev. 2.1 – Trial Implementation
Final
Production
No
Free
No
Implementation Specification
HL7® Version 2.5.1 Implementation Guide: Laboratory Orders (LOI) from EHR, Release 1, STU Release 3
Final
Production
No
Free
No
Implementation Specification
HL7 Version 2.5.1 Implementation Guide: Laboratory Results Interface, Release 1 STU Release 3
Final
Production
No
Free
No
Implementation Specification
HL7 Version 2.6 Implementation Guide: Critical Congenital Heart Defects (CCHD) pulse oximetry screening results, Release 1
Final
Production
No
Free
Yes
Implementation Specification
HL7 Version 2.6 Implementation Guide: Early Hearing, Detection and Intervention (EHDI) Results Release 1
Final
Production
No
Free
Yes
Implementation Specification
HL7 CDA® R2 Implementation Guide: Ambulatory Healthcare Provider Reporting to Birth Defect Registries, Release 1 - US Realm
Balloted Draft
Pilot
No
Free
No
Emerging Implementation Specification
HL7 v2.6 Diagnostic Audiology Reporting implementation guide
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
HL7® Implementation Guide for CDA® Release 2 – Level 3: Healthcare Associated Infection Reports, Release 1, U.S. Realm.
Final
Production
Yes
Free
Yes
Implementation Specification
HL7 CDA R2 Implementation Guide: Healthcare Associated Infection (HAI) Reports, Release 3 - US Realm
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:
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
IHE Quality, Research and Public Health Technical Framework Supplement Birth and Fetal Death Reporting-Enhanced (BFDR-E) Rev 3.1
Balloted Draft
Pilot
No
Free
Yes
Implementation Specification
HL7® FHIR® Vital Records Birth and Fetal Death Reporting Implementation Guide (BFDR IG) 2.0.0 - STU2
Balloted Draft
Pilot
No
Free
Yes
Implementation Specification
HL7 FHIR Vital Records Birth and Fetal Death Reporting Implementation Guide (BFDR IG) 1.1.0 - STU 1.1
Balloted Draft
Pilot
No
Free
Yes
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® Vital Records Birth and Fetal Death Reporting Implementation Guide (BFDR IG)
This implementation specification defines FHIR resources that represent content used for reporting birth and fetal death information to state electronic birth registration systems (EBRS).
This specification provides the content that can support development in automating the manual process of entering required information dually into Certified Health IT and public health systems.
The specification has undergone multiple formal ballot processes to make important updates but it has not yet been widely implemented.
Users should consider the Vital Records BFDR IG if interested in leveraging a FHIR-based approach using the SMART App Launch IG for transmission.
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 most recent published version of the HL7 Birth and Fetal Death Reporting FHIR Implementation Guide 2.0.0 - STU 2 is supporting this effort.
Active pilot project reporting births from an EHR to a jurisdiction is using the HL7 BFDR FHIR IG 1.1.0 - STU 1.1 and SMART on FHIR.
The
Vital Records Common Library (VRCL)
is a US Realm specific profile library that provides a standard framework for multiple use case specific to vital records and the medicolegal death investigation IGs. The purpose of this library is to avoid defining the same profiles multiple times within respective implementation guides. The
Birth and Fetal Death FHIR IG 2.0.0 STU2
Vital Records Death Reporting FHIR IG 3.0.0 STU3
and
Medicolegal Death Investigation FHIR IG 2.0.0 STU2
have dependencies within the current published VRCL FHIR IG 2.0.0 STU2.
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
North American Association of Central Cancer Registries, Inc. (NAACCR), Standards for Cancer Registries, Volume V, Pathology Laboratory Electronic Reporting, Version 4.0, published April 2011
Final
Production
Yes
Free
Yes
Implementation Specification
Implementation Guide for Ambulatory Healthcare Provider Reporting to Central Cancer Registries, August 2012
Final
Production
Yes
Free
Yes
Implementation Specification
HL7® CDA® Release 2 Implementation Guide: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers, Release 1, DSTU Release 1.1 – US Realm
Balloted Draft
Production
Yes
Free
Yes
Implementation Specification
HL7® FHIR® Central Cancer Registry Reporting Content Implementation Guide
Final
Production
Feedback Requested
No
Free
No
Implementation Specification
HL7® FHIR® Cancer Pathology Reporting IG
Final
Production
Feedback Requested
No
Free
No
Emerging Implementation Specification
IHE Quality, Research, and Public Health Technical Framework Supplement, Structured Data Capture, Trial Implementation
Balloted Draft
Production
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® Central Cancer Registry Reporting Content Implementation Guide
This implementation specification defines FHIR resources for reporting diagnosed cases of cancer, treatments, and demographic information from electronic health records (EHRs) to central cancer registries. Cancer reporting is a critical and mandatory component of cancer control efforts in the United States, as it provides essential data to inform public health interventions and allocate resources to communities and populations with high cancer rates.
This specification offers a FHIR-based approach as an alternative to the previously used CDA-based method identified by ASTP. By leveraging FHIR, the Cancer Reporting IG enables more streamlined, interoperable, and efficient data exchange between healthcare providers and cancer registries, supporting improved cancer surveillance and control efforts.
HL7® FHIR® Cancer Pathology Reporting IG
This specification supports standardized, FHIR-based transmission of cancer pathology laboratory values and results to Central Cancer Registries (CCRs), improving reporting at the point of diagnosis while reducing manual intervention and data cleansing.
It enables timely, accurate, and efficient exchange of pathology data among CCRs, Electronic Health Records (EHRs), and Laboratory Information Systems (LIS), ensuring inclusion of data elements critical for public health action.
It provides best practices for structured data collection and exchange, including common data models, defined data elements, and alignment with relevant ontologies and value sets to support interoperable pathology reporting.
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
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
HL7® FHIR® Vital Records Death Reporting Implementation Guide (VRDR IG) 2.2.0 - STU 2.2
Balloted Draft
Production
No
Free
Yes
Implementation Specification
HL7® FHIR® Vital Records Death Reporting Implementation Guide (VRDR IG) 3.0.0 - STU3
Balloted Draft
Pilot
No
Free
Yes
Implementation Specification
IHE Quality, Research and Public Health Technical Framework Supplement Vital Records Death Reporting (VRDR) R 3.2
Balloted Draft
Pilot
No
Free
Yes
Implementation Specification
HL7® FHIR® Medicolegal Death Investigation Implementation Guide (MDI IG) 1.1.0 - STU 1.1
Balloted Draft
Production
No
Free
Yes
Implementation Specification
HL7® FHIR® Medicolegal Death Investigation Implementation Guide (MDI IG) 2.0.0 - STU2
Balloted Draft
Production
No
Free
Yes
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® Vital Records Death Reporting Implementation Guide (VRDR IG)
This implementation specification defines FHIR resources to enable the bidirectional exchange of mortality data between data collection sites, such as Certified Health IT systems, case management systems, Jurisdictional Vital Records Offices (VROs), and CDC. This specification supports vital public health surveillance and response by facilitating the exchange of critical data elements through vital records.
Implementers interested in leveraging a FHIR-based approach for transmitting mortality data should consider adopting the VRDR IG, which integrates with the SMART App Launch IG for secure and efficient data transmission.
The VRDR IG automates mortality information exchange, connecting data collectors—such as physicians, medical examiners, coroners, funeral directors, and family members—with VROs and other users of mortality data. It also supports the aggregation of vital statistics information, ensuring a streamlined and standards-driven approach to mortality data management.
HL7® FHIR® Medicolegal Death Investigation Implementation Guide (MDI IG)
This implementation specification defines FHIR resources to facilitate the exchange of information between medicolegal death investigation systems and other FHIR-enabled health IT systems. This specification supports data exchange between medical examiner and coroner office case management systems, laboratory information management systems (LIMS), and electronic death registration systems (EDRS).
The MDI IG provides implementation guidance for four key data flows: 1) create, search, and update case records to manage case information; 2) Transmission of diagnostic findings to share laboratory and investigative results; 3) Transmission of MDI PDFs to exchange formatted reports; and 4) transmission of completed U.S. Death Certificates for official documentation.
Additional efforts are underway to further develop MDI-specific terminology, ontological standards, and implementation guidance for other data flows. Tools and testing environments, such as the
Raven Testing Platform
and the
Raven Documentation Platform (GitHub)
, are being developed to support the implementation and adoption of the MDI IG, ensuring robust and reliable data exchange in medicolegal contexts.
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
a U.S. Realm-specific FHIR profile library that provides a shared framework for vital records and medicolegal death investigation use cases, reducing duplication across implementation guides.
Dependencies: Birth and Fetal Death FHIR IG 2.0.0 (STU2), Vital Records Death Reporting (VRDR) FHIR IG 3.0.0 (STU3), and Medicolegal Death Investigation (MDI) FHIR IG 2.0.0 (STU2) depend on
VRCL FHIR IG 2.0.0 (STU2)
Implementer note: The VRDR FHIR IG version 2.2 (STU2) currently used in production is not harmonized with VRCL.
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
PHIN Messaging Guide for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient and Ambulatory Care Settings, Release 2.0
Final
Production
Yes
Free
Yes
Implementation Specification
Erratum to the PHIN Messaging Guide for Syndromic Surveillance: Emergency Department, Urgent Care, Inpatient and Ambulatory Care Settings Release 2.0 (April 21, 2015)
Final
Production
Yes
Free
No
Implementation Specification
Hl7 Version 2.5.1 PHIN Messaging Guide For Syndromic Surveillance, Release 2.0 - NIST Clarifications and Validation Guidelines (Version 1.6)
Final
Feedback requested
Feedback Requested
No
Free
Yes
Implementation Specification
PHIN Messaging Guide for Syndromic Surveillance: Emergency Department and Urgent Care Data Release 1.1
Final
Production
Yes
Free
Yes
Implementation Specification
Testing Clarification for PHIN Messaging Guide for Syndromic Surveillance: Emergency Department and Urgent Care Data (Release 1.1) Release 1.2 (February 15th, 2013)
Final
Production
Yes
Free
No
Implementation Specification
HL7® Version 2.5.1 Implementation Guide: Syndromic Surveillance, Release 1 - US Realm
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
HL7® CDA® R2 Implementation Guide: National Health Care Surveys (NHCS), R1 STU Release 3.1 - US Realm
Balloted Draft
Pilot
No
Free
Yes
Implementation Specification
HL7 CDA R2 Implementation Guide: National Health Care Surveys (NHCS), R1 DSTU Release 1.2 - US Realm
Balloted Draft
Production
Yes
Free
Yes
Implementation Specification
HL7 CDA R2 Implementation Guide: National Health Care Surveys (NHCS), R1 DSTU Release 1.1 - US Realm
Balloted Draft
Pilot
No
Free
No
Implementation Specification
HL7 CDA R2 Implementation Guide: National Health Care Surveys (NHCS), R1 DSTU Release 3.1 - US Realm
Balloted Draft
Pilot
No
Free
No
Emerging Implementation Specification
HL7 FHIR Health Care Surveys Content Implementation Guide
Balloted Draft
Pilot
No
Free
No
Emerging Implementation Specification
HL7 FHIR Health Care Surveys Content Implementation Guide 2.0.0 - STU2
Balloted Draft
Pilot
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® Health Care Surveys Content Implementation Guide
The Health Care Surveys Content Implementation Guide (IG) defines the use of FHIR resources to electronically capture and transmit survey data to public health agencies. These surveys provide valuable information on healthcare utilization, including details about symptoms, diagnoses, and procedures, and cover a wide range of healthcare settings.
This specification was developed to automate the traditionally manual process of submitting survey data, enabling broader participation from hospitals and healthcare organizations while reducing the reporting burden on individuals and institutions.
Health IT developers interested in adopting a FHIR-based approach to streamline the electronic transmission of healthcare survey data should consider implementing the Health Care Surveys Content IG. This specification helps reduce manual processes, improve efficiency, and ensure more comprehensive data collection for public health purposes.
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
Stakeholders should refer to the
National Health Care Surveys Registry
for information on participation.
The HL7 CDA R2 Implementation Guide: National Health Care Surveys (NHCS), R1 STU Release 3.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).
The National Health Care Surveys is currently receiving data in RI DSTU Release 1.2 in production and is prepared to receive data using R1 STU Release 3.1.
The National Health Care Surveys is currently updating
HL7® CDA® R2 Implementation Guide: National Health Care Surveys (NHCS), R1 STU Release 3.1 - US Realm
to align with USCDI V3. This is a major update and will be balloted and published in December 2025 as
HL7® CDA® R2 Implementation Guide: National Health Care Surveys (NHCS), R1 STU Release 4.0 - US Realm
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
HL7 Clinical Document Architecture (CDA®), Release 2.0, Final Edition
Final
Production
Yes
Free
N/A
Standard
CDISC Clinical Data Acquisition Standards Harmonization (CDASH)
Final
Production
No
Free
N/A
Implementation Specification
IHE-RFD (Retrieve Form for Data Capture)
Final
Production
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
CDISC Clinical Data Acquisition Standards Harmonization (CDASH)
Final
Production
No
Free
N/A
Standard
CDISC Shared Health And Research Electronic Library (SHARE)
Final
Production
No
Free
N/A
Standard
HL7® FHIR® Resource Observation-Content
Final
Production
Feedback Requested
No
Free
No
Standard
HL7 FHIR Resource Medication-Content
Balloted Draft
Pilot
Feedback Requested
No
Free
No
Implementation Specification
IHE-XUA (Cross-Enterprise User Assertion)
Final
Production
No
Free
N/A
Implementation Specification
IHE-ATNA (Audit Trail and Node Authentication)
Final
Production
No
Free
N/A
Implementation Specification
IHE-RFD (Retrieve Form for Data Capture)
Final
Production
No
Free
N/A
Implementation Specification
HL7 FHIR Implementation Guide: Structured Data Capture (SDC) Release 1
Final
Pilot
No
Free
N/A
Implementation Specification
IHE-CRD (Clinical Research Document)
Balloted Draft
Production
No
Free
N/A
Implementation Specification
IHE-DEX (Data Element Exchange)
Balloted Draft
Pilot
No
Free
N/A
Implementation Specification
IHE Quality, Research, and Public Health Technical Framework Supplement, Structured Data Capture, Trial Implementation
Balloted Draft
Pilot
No
Free
No
Emerging Standard
HL7 FHIR Audit Event
Balloted Draft
Production
No
Free
N/A
Emerging Standard
HL7 FHIR Questionnaire/Questionnaire Response
Balloted Draft
Pilot
Feedback Requested
No
Free
N/A
Emerging Standard
HL7 FHIR Resource Research Study - Content
In Development
Pilot
Feedback Requested
No
Free
No
Emerging Standard
HL7 FHIR Resource Research Subject - Content
Balloted Draft
Pilot
Feedback Requested
No
Free
No
Emerging Standard
HL7 FHIR Resource Questionnaire Response - Content
In Development
Feedback requested
Feedback Requested
No
Free
No
Emerging Standard
HL7 FHIR AdverseEvent
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
here
Feedback requested.
Interoperability Need: Real-World Data Retrieval for Clinical Research
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Implementation Specification
FHIR to CDISC Joint Mapping Implementation Guide
Balloted Draft
Pilot
No
Free
N/A
Implementation Specification
HL7® FHIR® Retrieval of Real-World Data for Clinical Research
Balloted Draft
Pilot
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® Retrieval of Real-World Data for Clinical Research
The HL7® FHIR® Retrieval of Real-World Data for Clinical Research IG aims to address this need by providing implementation guidance to collect and use real-world data and real-world evidence. This Implementation Guide specifies the retrieval of RWD from Certified Health IT via HL7 FHIR APIs – users should note this specification does not provide guidance on downstream use of RWD once the RWD is obtained from the Certified Health IT.
Implementers should note that this specification uses the HL7® FHIR® International Patient Access (IPA) IG as a baseline. The HL7® FHIR® Retrieval of Real-World Data for Clinical Research IG leverages the IPA IG to access the RWD but provides additional specifications on data elements and HL7 FHIR resources specific to clinical research.
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
The FHIR to CDISC Joint Mapping Implementation Guide defines mappings between FHIR release 4.0 and the following CDISC standards:
Study Data Tabulation Model Implementation Guide (SDTMIG) 3.2
Clinical Data Acquisition Standards Harmonization Implementation Guide (CDASH) 2.1
LAB 1.0.1
The HL7 Retrieval of Real-World Data for Clinical Research implementation guide is dependent on the
International Patient Access (IPA)
for a baseline dataset.
Refer to
FDA’s Data Standards for Drug and Biological Product Submissions Containing Real-World Data
for guidance on the use of real-world data (RWD) to generate real-world evidence (RWE) in regulatory decision-making.
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
CDISC Clinical Trial Registry (CTR-XML)
Final
Pilot
No
Free
N/A
Implementation Specification
IHE-RPE (Retrieve Protocol for Execution)
Balloted Draft
Production
No
Free
No
Implementation Specification
IHE-CPRC (Clinical Research Process Content)
Balloted Draft
Pilot
No
Free
No
Emerging Standard
HL7® FHIR® Resource Research Study - Content
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
HL7 Clinical Document Architecture (CDA®), Release 2.0, Final Edition
Final
Production
No
Free
N/A
Standard
CDISC Clinical Data Acquisition Standards Harmonization (CDASH)
Final
Production
No
Free
N/A
Standard
CDISC Operational Data Model (ODM)
Final
Production
No
Free
N/A
Standard
CDISC Protocol Representation Model (PRM)
Final
Production
No
Free
Yes
Standard
CDISC Study/Trial Design Model (SDM)
Final
Production
No
Free
N/A
Standard
IHE- RFD (Retrieve Form for Data Capture)
Final
Production
No
Free
N/A
Standard
CDISC Study Data Tabulation Model (SDTM)
Final
Feedback requested
Feedback Requested
No
Free
No
Implementation Specification
IHE-RPE (Retrieve Protocol for Execution)
Balloted Draft
Production
No
Free
N/A
Implementation Specification
IHE-CRPC (Clinical Research Process Content)
Balloted Draft
Production
No
Free
N/A
Implementation Specification
CDISC Study Data Tabulation Model Implementation Guide
Final
Feedback requested
Feedback Requested
No
Free
No
Implementation Specification
CDISC Therapeutic Area User Guides
Final
Feedback requested
Feedback Requested
No
Free
No
Emerging Standard
CDISC Pharmacogenomics/genetics (PGx) Implementation Guide
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
CDISC Study Data Tabulation Model (SDTM)
Final
Production
Yes
Free
Yes
Standard
CDISC Define-XML (ODM-Based)
Final
Production
Yes
Free
N/A
Standard
CDISC Analysis Dataset Model (ADaM)
Final
Production
Yes
Free
N/A
Standard
CDISC Standard for the Exchange of Non-clinical Data (SEND)
Final
Production
Yes
Free
N/A
Standard
CDISC Dataset-XML (ODM-Based)
Final
Production
No
Free
N/A
Standard
Therapeutic Area Standards (to complement the aforementioned CDISC foundational standards that apply across various therapeutic areas)
Final
Production
Yes
Free
N/A
Standard
CDISC Operational Data Model (ODM)
Final
Production
Feedback Requested
No
Free
Yes
Standard
CDISC Questionnaires, Ratings and Scales (QRS)
Final
Feedback requested
Feedback Requested
No
Free
No
Standard
CDISC Dataset-JSON
Final
Feedback requested
Feedback Requested
No
Free
Yes
Implementation Specification
Study Data Tabulation Model Implementation Guide for Medical Devices (SDTMIG-MD)
Final
Production
No
Free
N/A
Emerging Implementation Specification
CDISC Pharmacogenomics/genetics (PGx) Implementation Guide
Balloted Draft
Feedback requested
Feedback Requested
No
Free
No
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
FDA published the guidance: Use of EHR Data in Clinical Investigations, in collaboration with ASTP. (
FDA CDER published a FRN focusing on Source Data Capture From Electronic Health Records: Using Standardized Clinical Research Data. (
FDA CDER and CBER encourage the submission of study data in conformance to the data standards listed in the FDA Data Standards Catalog (DSC). Standardized study data will be required in submissions for clinical and non-clinical studies that start on or after December 17, 2016 (December 17, 2017 for INDs). See Data Standards Catalog: (
) and the Data Standards Strategy: (
Although CDISC standards are a requirement for CDER and CBER but not for CDRH, all three Centers promote the use of real-world data (RWD) in EHRs, registries, administrative claims and mobile health technology to generate real-world Evidence regarding the safety and effectiveness of medical products. In addition, FDA collaborates closely with other standards development organizations including but not limited to HL7
, IHE, X12
, and NCPDP
FDA CDRH and CBER published the draft guidance: Use of Real-World Evidence to Support Regulatory Decision-Making for Medical Devices. (see
Therapeutic Area Standards, that apply across a number of therapeutic areas, include a series of IGs at different level of maturity, from development to final.
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
International Council for Harmonisation of Technical Requirements for Pharmaceuticals for Human Use (ICH) Medical Dictionary for Regulatory Activities (MedDRA)
Final
Production
Yes
N/A
Implementation Specification
IHE-RFD (Retrieve Form for Data Capture)
Final
Production
Feedback Requested
No
Free
N/A
Implementation Specification
HL7® FHIR® Profiles for Transfusion and Vaccination Adverse Event Detection and Reporting IG
Balloted Draft
Pilot
No
Free
No
Implementation Specification
IHE-DSC (Drug Safety Content)
Balloted Draft
Pilot
Feedback Requested
No
Free
N/A
Implementation Specification
IHE-CPRC (Clinical Research Process Content)
Balloted Draft
Pilot
Feedback Requested
No
Free
N/A
Emerging Standard
HL7 FHIR Adverse Event Resource
In Development
Feedback requested
Feedback Requested
No
Free
No
Emerging Standard
HL7 FHIR Adverse Event Resource
In Development
Feedback requested
Feedback Requested
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® Profiles for Transfusion and Vaccination Adverse Event Detection and Reporting IG
This implementation specification provides a framework for reporting adverse events following transfusions and vaccinations using FHIR resources. These resources include the necessary information required by the Food and Drug Administration (FDA) for decision-making and have been successfully piloted through the
BEST Innovative Methods Exchange Platform
Health IT developers seeking to adopt a FHIR-based approach to electronically transmit adverse event data should consider implementing the Transfusion and Vaccination AE IG. This specification helps reduce manual reporting processes, streamline data submission, and ensure accurate and timely reporting of adverse events to support regulatory and public health efforts.
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
HL7® Healthcare Privacy and Security Classification System (HCS), Release 1
Final
Production
No
Free
No
Standard
HL7 v2.9
Final
Production
No
Free
Standard
HL7 FHIR® R4 - Security Labels
Final
Production
No
Free
Implementation Specification
HL7 CDA Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1
Final
Production
No
Free
Yes
Implementation Specification
IHE IT Infrastructure Technical Framework Volume 4 - National Extensions – Section 3.1 Data Segmentation for Privacy (DS4P)
Final
Pilot
No
Free
No
Implementation Specification
HL7 FHIR Data Segmentation for Privacy
In Development
Pilot
No
Free
No
Standard
HL7 Version 3 Standard: Privacy, Access and Security Services (PASS); Access Control, Release 1
Final
Feedback requested
Feedback Requested
No
Free
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® Release 4.0.1 (R4)
The baseline FHIR standard version provides foundational FHIR Resources that are stable, mature, and backwards compatible, referred to as “Normative”. These resources form the base standard and are constrained into FHIR Profiles by implementation specifications, ensuring consistent implementation necessary for interoperability.
While a newer version, FHIR Release 5 (FHIR R5), has been balloted, all current implementation specifications adopted by federal regulations are based on FHIR R4.
The standards community is actively working towards releasing FHIR Release 6 (FHIR R6) in 2026. FHIR R6 is expected to include more FHIR Resources designated as Normative.
Unless there is a compelling need for a use case that requires functionality exclusive to FHIR R5, it is recommended that any new standards development activities and implementations continue to be based on FHIR Release 4.0.1 to ensure alignment with current federal regulations.
Referenced in Federal Rulemaking:
ASTP Cures Act Final Rule
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
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. 5
Security 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
HL7 Implementation Guide for CDA Release 2: Consolidated CDA Templates for Clinical Notes (US Realm), Draft Standard for Trial Use, Release 2.1
Final
Production
Yes
Free
Yes
Implementation Specification
HL7 Consolidated CDA Release 1.1 (HL7 Implementation Guide for CDA Release 2: IHE Health Story Consolidation, DSTU Release 1.1 - US Realm)
Balloted Draft
Production
Yes
Free
Yes
Standard
HL7® Clinical Document Architecture (CDA®), Release 2.0, Final Edition
Final
Production
No
Free
Yes
Implementation Specification
HL7 CDA R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 3 - US Realm
Balloted Draft
Production
Feedback Requested
No
Free
No
Implementation Specification
HL7 CDA R2 IG: C‐CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2 ‐ US Realm
Balloted Draft
Production
Feedback Requested
No
Free
No
Standard
Consolidated CDA (C-CDA) STU3
Final
Feedback requested
No
Free
Yes
Standard
Consolidated CDA (C-CDA) STU4
Final
Feedback requested
No
Free
Yes
Emerging Implementation Specification
IHE Patient Care Coordination Technical Framework Supplement 360 Exchange Closed Loop Referral (360X) Rev. 1.1 – Trial Implementation
Balloted Draft
Pilot
No
Free
No
Implementation Specification
NCPDP SCRIPT Standard, Implementation Guide, Version 2023011
Final
Pilot
No
No
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
HL7 provides a
C-CDA Example repository
that contains example C-CDA documents
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.
The
HL7 C-CDA on FHIR Implementation Guide 2.0.0
defines how a C-CDA document may be transformed for exchange using FHIR
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
Unique Device Identifier as Defined by the Food and Drug Administration at 21 CFR 830.3
Final
Production
Yes
Free
N/A
Implementation Specification
HL7® Cross-Paradigm Implementation Guide: UDI Pattern, Release 2
Final
Production
No
Free
N/A
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
Currently, all medical devices subject to the UDI rule are required to be in compliance unless an
exception or alternative
has been granted. These data are available at
Feedback requested.
Interoperability Need: Representing Unique Device Identifiers
Type
Standard / Implementation Specification
Standards Process Maturity
Implementation Maturity
Adoption Level
Federally required
Cost
Test Tool Availability
Standard
Unique Device Identifier as Defined by the Food and Drug Administration at 21 CFR 830.3
Final
Production
Yes
Free
N/A
Standard
NCPDP® Telecommunication Standard Implementation Guide, Version FA
Final
Production
Feedback Requested
No
Standard
NCPDP SCRIPT Standard, Implementation Guide, Version 2025071
Final
Production
Feedback Requested
No
Yes
Implementation Specification
HL7® Cross-Paradigm Implementation Guide: UDI Pattern, Release 2
Final
Production
No
Free
N/A
Implementation Specification
NCPDP Product Identifiers Standard Implementation Guide Version 1.9
Final
Production
Feedback Requested
No
No
Emerging Implementation Specification
HL7 FHIR® US Core - Implantable Device Profile
In Development
Feedback requested
Feedback Requested
No
Free
No
Emerging Implementation Specification
HL7 CDA® R2 Implementation Guide: C-CDA Supplemental Templates for Unique Device Identifier (UDI) for Implantable Medical Devices, Release 1 - US Realm
Balloted Draft
Production
Feedback Requested
No
Free
Implementation Specification
NCPDP SCRIPT Standard, Implementation Guide, Version 2023011
Final
Pilot
Feedback Requested
No
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® US Core Implementation Guide (US Core IG)
This implementation specification defines minimum constraints on FHIR Resources aligning with data elements specified in USCDI. Built on FHIR R4, it is the foundation of all US Realm implementation specifications. A foundational FHIR specification, US Core uses other specifications, such as the FHIR Structured Data Capture IG and the FHIR SMART App Launch IG, to optimize existing workflows.
There are multiple versions of the US Core IG, with each version corresponding to a specific annual release of USCDI. Historically, ASTP adopted different versions of the US Core IG based on publication timing. Currently, ASTP has identified US Core Version 6.1.0 as ready for adoption in Certified Health IT in the ASTP HTI-1 Final Rule. Certified Health IT developers typically adopt the version of the US Core IG that is specified in regulation or the version approved by the National Coordinator through ASTP’s
Standards Version Advancement Process (SVAP)
For use cases that rely on data elements defined in USCDI, the US Core IG often provides the simplest and most cost-effective solution for data exchange. Additionally, the US Core IG benefits from extensive support and expertise within the standards community and among health IT developers, ensuring successful implementation and accommodating modifications when necessary.
Referenced in Federal Rulemaking:
ASTP HTI-1 Final Rule
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
Currently, all medical devices subject to the UDI rule are required to be in compliance unless an
exception or alternative
has been granted. These data are available at
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
Unique Device Identifier as Defined by the Food and Drug Administration at 21 CFR 830.3
Final
Production
Yes
Free
N/A
Implementation Specification
HL7® Cross-Paradigm Implementation Guide: UDI Pattern, Release 2
Final
Production
No
Free
N/A
Implementation Specification
NCPDP Telecommunication Standard, Implementation Guide, Version F6
Final
Pilot
Feedback Requested
No
No
Implementation Specification
NCPDP SCRIPT Standard, Implementation Guide, Version 2023011
Final
Pilot
No
No
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
Currently, all medical devices subject to the UDI rule are required to be in compliance unless an
exception or alternative
has been granted. These data are available at
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
HL7® Version 2.9 Messaging Standard – An Application Protocol for Electronic Data Exchange in Healthcare Environments, Normative. Chapter 3, Patient Administration
Final
Production
Feedback Requested
No
Free
N/A
Implementation Specification
C-CDA R2.1 Supplemental Templates for Occupational Data for Health Release 1, STU Release 1.1 - US Realm. Standard for Trial Use
Balloted Draft
Pilot
No
Free
Yes
Implementation Specification
IHE Patient Care Coordination (PCC) Technical Framework Supplement: CDA Content Modules, Revision 2.8 – Trial Implementation
Balloted Draft
Pilot
No
Free
Implementation Specification
HL7 FHIR® Release 4.0.1 Implementation Guide: Occupational Data for Health (ODH), Release 1.3 (STU)
Balloted Draft
Pilot
No
Free
Yes
Implementation Specification
HL7 EHRS-FM Release 2: Functional Profile; Work and Health, Release 1 – US Realm
Balloted Draft
Feedback requested
Feedback Requested
No
Free
No
Emerging Implementation Specification
IHE FHIR Profile: Occupational Data for Health (ODH) - International 1.0.0 - Trial-Implementation
In Development
Pilot
Feedback Requested
No
Free
No
Emerging Implementation Specification
IHE Patient Care Coordination (PCC) Technical Framework Supplement: Mobile Antepartum Summary (FHIR IG)
In Development
Pilot
Feedback Requested
No
Free
No
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
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
The ODH structures for specific data elements are reflected in several implementation guides. These include:
US Core FHIR Implementation Guide, 6.1.0—STU6
(USCDI V3.1)
HL7 CDA® R2 Implementation Guide: C-CDA Templates for Clinical Notes STU Companion Guide, Release 4.1 – US Realm, Standard for Trial Use
(USCDI V3.1)
All ODH sections/profiles are optional in these implementation specifications:
IHE Patient Care Coordination (PCC) Technical Framework Supplement to Volume 1, CDA Occupational Data Options (XDS-MS, XHPR, EDR), Revision 1.1 – Trial Implementation
IHE Patient Care Coordination (PCC) Technical Framework Supplement: Query for Existing Data for Mobile (QEDm), Revision 2.3 – Trial Implementation
IHE PCC TF Supplement: International Patient Summary (IPS), Revision 1.2 – Trial Implementation
IHE Quality, Research and Public Health Technical Framework Supplement: Healthy Weight (HW), Revision 2.5 – Trial Implementation
IHE FHIR Profile: Occupational Data for Health (ODH) - International
The ODH Usual Work section/profile is required in these implementation specifications:
HL7 CDA R2 Implementation Guide: Reporting to Public Health Cancer Registries from Ambulatory Healthcare Providers, Release 1 – DSTU Release 1.1
HL7 CDA R2 Implementation Guide: Vital Records Death Reporting, Release 1 STU 2.1
Vital Records Death Reporting (VRDR) FHIR Implementation Guide v2.2.0: STU 2
The ODH Employment Status, Job, and Usual Work sections/profiles are options in these implementation specifications:
HL7 CDA R2 Implementation Guide: Public Health Case Report – the Electronic Initial Case Report (eICR), Release 2, STU Release 3.1 - US Realm
HL7 FHIR Implementation Guide: Electronic Case Reporting (eCR), Release 2.1 - US Realm
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.
These standards are used to transmit data that are part of the medical record. Those data must be protected as defined in regulation.
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
Applicability Statement for Secure Health Transport Version 1.2
Final
Production
Yes
Free
Yes
Standard
HL7® 2.5.1 (or later) ADT message
Final
Production
No
Free
No
Standard
HL7 FHIR® RESTful API
Final
Production
Yes
Free
Yes
Implementation Specification
Implementation Guide for Delivery Notification In Direct Version 1.0
Final
Production
Yes
Free
Yes
Implementation Specification
NCPDP® SCRIPT Standard, Implementation Guide, Version 2017071
Final
Production
Yes
Yes
Implementation Specification
Implementation Guide for Direct Edge Protocols Version 1.1
Final
Production
Yes
Free
Yes
Implementation Specification
XDR and XDM for Direct Messaging Specification Version 1.0
Final
Production
Yes
Free
Yes
Implementation Specification
Applicability Statement for Secure Health Transport Also known as the Direct Standard® Version 1.3
Final
Production
Yes
Free
Yes
Implementation Specification
IHE-XDR (Cross-Enterprise Document Reliable Interchange)
Final
Production
No
Free
Yes
Yes
Yes
Implementation Specification
ITU H.810, H.811, H.812, and H.813
Final
Production
No
Free
Yes
Implementation Specification
Implementation Guide for Expressing Context in Direct Messaging Version 1.1
Final
Production
No
Free
No
Implementation Specification
IHE-MHD (Mobile access to Health Documents)
Final
Production
Feedback Requested
No
Free
Yes
Yes
Implementation Specification
Specialty Medication Enrollment HL7 FHIR
Final
Production
No
Free
No
Emerging Standard
ANSI/DS 2019-02-100-2021 - Trusted Instant Messaging Plus (TIM+) Applicability Statement Version 1.1.1
Final
Pilot
Feedback Requested
No
Free
No
Implementation Specification
NCPDP SCRIPT Standard, Implementation Guide, Version 2023011
Final
Pilot
Feedback Requested
No
No
Standard
NCPDP Pharmacist eCare Plan Version 1.0: Guidance on the Use of the HL7 CDA Consolidated Templates for Clinical Notes R2.1 Care Plan
Final
Production
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:
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-server 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
Direct™ (Applicability Statement for Secure Health Transport v1.2)
Final
Production
Yes
Free
Yes
Standard
HL7® FHIR® RESTful API
Final
Production
Yes
Free
Yes
Implementation Specification
eHealth Exchange Specification: Messaging Platform
Final
Production
No
Free
Yes
Implementation Specification
eHealth Exchange Specification: Authorization Framework
Final
Production
No
Free
Yes
Implementation Specification
eHealth Exchange Specification: Document Submission
Final
Production
No
Free
Yes
Implementation Specification
IHE-XDR (Cross-Enterprise Document Reliable Interchange)
Final
Production
No
Free
Yes
Implementation Specification
NCPDP® SCRIPT Standard, Implementation Guide, Version 2017071
Final
Production
Yes
Yes
Implementation Specification
Applicability Statement for Secure Health Transport Version 1.3
Final
Production
Yes
Free
Yes
Implementation Specification
NCPDP SCRIPT Standard, Implementation Guide, Version 2023011
Final
Pilot
Feedback Requested
No
No
Emerging Standard
Specialty Transaction HL7 FHIR
Balloted Draft
Pilot
No
No
Emerging Standard
DirectTrust™ Trusted Instant Messaging Plus (TIM+)
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
ITU H.810, H.811, H.812, and H.813
Final
Production
No
Free
Yes
Implementation Specification
Continua Design Guidelines
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:
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
IEEE 11073-10101-2004 - Health informatics -- Point-of-care medical device communication -- Part 10101: Nomenclature
Final
Production
No
Yes
Implementation Specification
IHE-PCD (Patient Care Device Profiles)
Final
Production
No
Free
Yes
Yes
Implementation Specification
ITU H.810, H.811, H.812, H.812.5 and H.813
Final
Production
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:
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
ITU H.810, H.811, H.812, H.812.5, and H.813
Final
Production
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:
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.
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
HL7® 2.5.1 Implementation Guide (IG) for Immunization Messaging (IM), Release 1.5
Final
Production
Yes
Free
Yes
Emerging Implementation Specification
HL7 Immunization Decision Support Forecast (ImmDS) Implementation Guide
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
) 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
HL7® Standard: Clinical Quality Language Specification, Release 1, R5 (CQL 1.5)
Final
Pilot
No
Free
Yes
Standard
HL7 FHIR® CDS Hooks Implementation Guide (CDS Hooks IG)
Balloted Draft
Production
No
Free
Yes
Standard
HL7 FHIR Quality Improvement Core Implementation Guide (QI-Core IG)
Balloted Draft
Pilot
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® CDS Hooks Implementation Guide (CDS Hooks IG)
This implementation specification describes a “hook”-based pattern for invoking or triggering an external decision support from within a health IT solution, including Certified Health IT. This pattern enables clinicians to integrate results from a clinical decision support (CDS) tool directly into their workflow or to launch an interactive application for clinical decision support.
The CDS Hooks IG provides a more advanced interaction than simply invoking a third-party application, making it an advanced use of FHIR APIs. Implementing CDS Hooks requires clients, typically Certified Health IT systems, to support "hooks" at specific points within the electronic health record (EHR) workflow to facilitate seamless integration.
Organizations interested in implementing CDS Hooks should evaluate the CDS Hooks IG to enable native or third-party applications, provided their Certified Health IT system supports CDS Hooks as a client and includes the necessary "hooks" within the workflow.
HL7® FHIR® Quality Improvement Core Implementation Guide (QI-Core IG)
This implementation specification provides requirements and guidance for using FHIR in quality measurement and decision support. It defines standardized profiles derived from FHIR resources described in the US Core IG, creating a consistent data set for use across various quality measures.
Each annual version of the QI-Core IG builds upon the corresponding version of the US Core IG, which aligns with updates to USCDI.
The QI-Core IG serves as a foundational resource for Certified Health IT developers and the broader quality improvement community. It is particularly valuable for those interested in leveraging FHIR for applications focused on quality measurement and reporting.
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
here
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-server 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
HL7® Version 3 Standard: Context Aware Knowledge Retrieval Application. (“Infobutton”), Knowledge Request, Release 2.
Final
Production
Yes
Free
No
Implementation Specification
HL7 Implementation Guide: Service-Oriented Architecture Implementations of the Context-aware Knowledge Retrieval (Infobutton) Domain, Release 1.
Final
Production
Yes
Free
No
Implementation Specification
HL7 Version 3 Implementation Guide: Context-Aware Knowledge Retrieval (Infobutton), Release 4.
Final
Production
Yes
Free
No
Implementation Specification
HL7 FHIR® Implementation Guide Clinical Reasoning Module, FHIR R4 STU
Balloted Draft
Pilot
No
Free
No
Standard
HL7 FHIR CDS Hooks Implementation Guide (CDS Hooks IG)
Balloted Draft
Production
No
Free
Yes
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® Release 4.0.1 (R4)
The baseline FHIR standard version provides foundational FHIR Resources that are stable, mature, and backwards compatible, referred to as “Normative”. These resources form the base standard and are constrained into FHIR Profiles by implementation specifications, ensuring consistent implementation necessary for interoperability.
While a newer version, FHIR Release 5 (FHIR R5), has been balloted, all current implementation specifications adopted by federal regulations are based on FHIR R4.
The standards community is actively working towards releasing FHIR Release 6 (FHIR R6) in 2026. FHIR R6 is expected to include more FHIR Resources designated as Normative.
Unless there is a compelling need for a use case that requires functionality exclusive to FHIR R5, it is recommended that any new standards development activities and implementations continue to be based on FHIR Release 4.0.1 to ensure alignment with current federal regulations.
Referenced in Federal Rulemaking:
ASTP Cures Act Final Rule
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
HL7® FHIR® CDS Hooks Implementation Guide (CDS Hooks IG)
This implementation specification describes a “hook”-based pattern for invoking or triggering an external decision support from within a health IT solution, including Certified Health IT. This pattern enables clinicians to integrate results from a clinical decision support (CDS) tool directly into their workflow or to launch an interactive application for clinical decision support.
The CDS Hooks IG provides a more advanced interaction than simply invoking a third-party application, making it an advanced use of FHIR APIs. Implementing CDS Hooks requires clients, typically Certified Health IT systems, to support "hooks" at specific points within the electronic health record (EHR) workflow to facilitate seamless integration.
Organizations interested in implementing CDS Hooks should evaluate the CDS Hooks IG to enable native or third-party applications, provided their Certified Health IT system supports CDS Hooks as a client and includes the necessary "hooks" within the workflow.
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
HL7 FHIR Patient Reported Outcomes Implementation Guide
Balloted Draft
Pilot
No
Free
No
Implementation Specification
HL7 FHIR Patient Reported Outcomes Implementation Guide (Continuous Integration Build)
In Development
Pilot
No
Free
No
Implementation Specification
HL7® FHIR® Argonaut Questionnaire Implementation Guide
Final
Feedback requested
Feedback Requested
No
Free
No
Implementation Specification
IHE Mobile Access to Health Documents (MHD) Profile
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.
The FHIR PRO IG leverages the Structured Data Capture Implementation Specification and the profiles listed below to capture and exchange patient-reported outcome data:
SDC Questionnaire
SDC QuestionnaireResponse
SDC Adaptive Questionnaire
SDC Adaptive QuestionnaireResponse
See the PRO project in the:
ONC Health IT Scientific Initiatives Realm
The IHE-MHD profile can include data in the form of CDA, FHIR-Documents, or FHIR Bundles.
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
HL7® FHIR® RESTful API
Final
Production
Yes
Free
Yes
Standard
Current Procedural Terminology (CPT®) Consumer Friendly Descriptors (CFDs)
Final
Production
Yes
N/A
Implementation Specification
Applicability Statement for Secure Health Transport v1.2 (Direct™)
Final
Production
Yes
Free
Yes
Implementation Specification
Applicability Statement for Secure Health Transport Version 1.3 (Direct)
Final
Production
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
HL7® FHIR® RESTful API
Final
Production
Yes
Free
Yes
Implementation Specification
Applicability Statement for Secure Health Transport Version 1.3 (Direct™)
Final
Production
Yes
Free
Yes
Implementation Specification
Direct (Applicability Statement for Secure Health Transport v1.2)
Final
Production
Yes
Free
Yes
Standard
Current Procedural Terminology (CPT® ) Consumer Friendly Descriptors (CFDs)
Final
Production
Yes
N/A
Implementation Specification
IHE Mobile Access to Health Documents (MHD) Profile
Balloted Draft
Feedback requested
Feedback Requested
No
Free
Yes
Yes
Emerging Implementation Specification
HL7 FHIR Patient Reported Outcomes Implementation Guide
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
HL7® FHIR® RESTful API
Final
Production
Yes
Free
Yes
Implementation Specification
IHE Basic Patient Privacy Consents (BPPC) Profile
Final
Production
No
Free
Yes
Implementation Specification
IHE Advanced Patient Privacy Consents (APPC) Profile
Balloted Draft
Feedback requested
Feedback Requested
No
Free
Yes
Emerging Implementation Specification
HL7 FHIR Patient Reported Outcomes Implementation Guide
In Development
Pilot
Feedback Requested
No
Emerging Implementation Specification
Health Relationship Trust (HEART) 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 (
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
Current Procedural Terminology (CPT®) Consumer Friendly Descriptors (CFDs)
Final
Production
Yes
N/A
Standard
HL7® FHIR® RESTful API
Final
Production
Yes
Free
Yes
Standard
Direct™(Applicability Statement for Secure Health Transport v1.2)
Final
Production
Yes
Free
Yes
Implementation Specification
IHE Query for Existing Data for mobile (QEDm) Profile
Balloted Draft
Pilot
No
Free
No
Implementation Specification
IHE Mobile Access to Health Documents (MHD) Profile
Balloted Draft
Feedback requested
Feedback Requested
No
Free
Yes
Yes
Implementation Specification
UDAP Security for Scalable HL7® FHIR® FAST UDAP Security for Scalable Registration, Authentication, and Authorization Implementation Guide
In Development
Production
Feedback Requested
No
Free
Yes
Emerging Standard
HL7 FHIR SMART App Launch Implementation Guide (SMART App Launch IG)
Final
Production
Feedback Requested
No
Free
Yes
Implementation Specification
HL7 FHIR SMART Health Cards and Links Implementation Guide
Balloted Draft
Pilot
No
Free
Yes
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
UDAP Security for Scalable HL7® FHIR® FAST UDAP Security for Scalable Registration, Authentication, and Authorization Implementation Guide
This implementation specification extends OAuth 2.0 to standardize and automate the application registration process using digital certificates, while securely authenticating participants within health information networks. This specification is compatible with the SMART App Launch IG and aligns with the security requirements of the Bulk Data IG.
ASTP has identified Version 1.0.0 of the FAST UDAP Security IG as ready for adoption in Certified Health IT. While its use is currently optional within the Trusted Exchange Framework and Common Agreement™ (TEFCA™), it is expected to become a requirement in the future.
The FAST UDAP Security IG provides a standardized method for dynamically registering applications through secure FHIR APIs. Implementers should consider adopting this specification for use cases requiring scalable trust among participants who agree to follow common policies, eliminating the need for individual agreements between organizations to establish trust.
ASTP anticipates that this specification will continue to evolve and mature based on implementation experience within TEFCA™.
HL7® FHIR® SMART App Launch Implementation Guide (SMART App Launch IG)
This implementation specification specifies how applications connect to FHIR APIs by requesting authorization from OAuth 2.0-compliant authorization servers. It outlines the process by which an application requests authorization to access a FHIR resource and subsequently uses that authorization to retrieve the resource.
There are multiple versions of the SMART App Launch IG, all of which are compatible with FHIR Release 4 (R4). Historically, ASTP has adopted different versions of the SMART App Launch IG based on publication timing. Currently, ASTP has identified Version 2.0.0 as ready for adoption in Certified Health IT under the ASTP HTI-1 Final Rule. Certified Health IT developers typically adopt the version specified in program requirements or the version approved by the National Coordinator through ASTP’s Standards Version Advancement Process (SVAP).
The SMART App Launch IG facilitates a persistent application authorization process and adds a security layer to FHIR API deployments, addressing both FHIR server and FHIR application perspectives. This makes the SMART App Launch IG a foundational specification for any FHIR API implementation requiring secure access to FHIR Resources.
Referenced in Federal Rulemaking:
ASTP HTI-1 Final Rule
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
HL7® FHIR® SMART Health Cards and Links Implementation Guide
This implementation specification will provide a secure, standards-based method for patients to share their health data with entities of their choice, simplifying data exchange scenarios and reducing complexity and burden. SMART Health Links is a FHIR-based standard designed to enhance the portability and shareability of health information. It allows individuals to store a limited amount of information in a secure QR code while also supporting larger and more dynamic health records.
Implementers interested in enabling patients to share electronic health information should consider adopting the SMART Health Cards and Links IG. This specification supports various modalities for accessing electronic health information (EHI), including limited-time access, long-term access, and password/PIN-protected access, providing flexibility and security in data sharing.
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 --
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
HL7® FHIR® Argonaut Provider Directory Implementation Guide Version 1.0.0
Balloted Draft
Production
No
Free
Yes
Implementation Specification
HL7 FHIR Da Vinci Payer Data Exchange Implementation Guide (PDex IG)
Balloted Draft
Production
No
Free
Yes
Implementation Specification
HL7 FHIR Da Vinci Payer Data Exchange Plan Net Implementation Guide (PDex Plan Net IG)
Balloted Draft
Production
No
Free
Yes
Implementation Specification
HL7 FHIR Validated Healthcare Directory Implementation Guide Home
Balloted Draft
Pilot
No
Free
Yes
Implementation Specification
IHE IT Infrastructure Technical Framework Supplement, Healthcare Provider Directory (HPD), Trial Implementation
Balloted Draft
Pilot
No
Free
Yes
Yes
Yes
Implementation Specification
IHE Mobile Care Services Discovery (mCSD)
Balloted Draft
Pilot
Feedback Requested
No
Free
No
Implementation Specification
FHIR Human Services Directory IG
Balloted Draft
Pilot
No
Free
No
Implementation Specification
HL7 FHIR FAST National Directory of Health Implementation Guide (NDH IG)
Balloted Draft
Pilot
No
Free
No
Implementation Specification
HL7 FHIR Da Vinci – Member Attribution (ATR) List
Balloted Draft
Pilot
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® Da Vinci Payer Data Exchange Implementation Guide (PDex IG)
This implementation specification provides a framework for payers and health plans to create a member’s health history using clinical resources based on the US Core IG. This health history can be shared with providers in a format that is understandable and can be integrated into their Certified Health IT systems. The PDex IG includes components for both payers and providers, enabling providers to access timely and comprehensive clinical information. This supports more informed treatment decisions, better adherence to care plans, and improved quality of care for patients.
ASTP and the Centers for Medicare & Medicaid Services (CMS) have identified PDex IG version 2.0 as ready for adoption in Certified Health IT. Developed by the Da Vinci Project Accelerator, the PDex IG is available for implementation without licensing requirements.
Payers and providers should consider adopting the PDex IG for use cases that involve exchanging clinical information between payers and providers, as well as enabling patients to access their clinical information from their payers.
Referenced in Federal Rulemaking:
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
HL7® FHIR® Da Vinci Payer Data Exchange Plan Net Implementation Guide (PDex Plan Net IG)
This implementation specification provides a framework for payer health IT systems to publish information about their insurance plans, providers, participating organizations, and associated networks via a FHIR API. This specification is designed to help patients and providers understand which providers, facilities, and pharmacies are covered by a healthcare insurance plan, ensuring that coverage and clinical information are both useful and actionable. Using the PDex Plan Net IG, third-party developers can create applications that allow patients and providers to search for participants in a payer’s network who can deliver requested or needed healthcare services.
CMS has identified PDex Plan Net IG Version 1.1.0 as ready for adoption in Certified Health IT. Developed by the Da Vinci Project Accelerator, the IG is available for implementation without licensing requirements, making it accessible to payers and health IT developers.
Referenced in Federal Rulemaking:
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
HL7® FHIR® FAST National Directory of Health Implementation Guide (NDH IG)
This implementation specification establishes a standardized national directory infrastructure in the United States to facilitate the lookup, discovery, and validation of data exchange partners. It aims to streamline the process by enabling API-based sharing of information about providers, organizations, services, and existing healthcare directories.
The specification addresses key challenges related to the availability and discovery of FHIR endpoints, including endpoint discovery, referrals and transitions of care, health plan enrollment, provider and service selection, and provider credentialing. By defining and resolving these issues, the NDH IG supports a more efficient and reliable health IT data exchange ecosystem.
Implementers are encouraged to consider adopting the NDH IG to build a scalable infrastructure for identifying health IT data exchange partners.
This specification was developed by combining insights from three predecessor specifications: the
FHIR National Healthcare Directory Exchange IG
, the
FHIR National Healthcare Directory Query IG
, and the
FHIR National Healthcare Directory Attestation and Verification IG
HL7® FHIR® Da Vinci – Member Attribution (ATR) List
This implementation specification provides a framework for data exchange between providers and payers to support risk-based contracts, value-based contracts, care gap closures, and quality reporting. It defines workflows for managing member attribution lists, which are essential for aligning patients with providers and organizations under specific healthcare plans or contracts. The IG supports exchange of full member attribution lists; updates to existing member attribution lists; and notifications of member attribution list updates.
The ATR IG outlines data exchange mechanisms, data structures, and value sets for commonly found information in member attribution lists, including plan/contract information, patient information, attributed individual provider information, attributed organization information, and member and subscriber coverage.
While the ATR IG does not directly leverage other FHIR Da Vinci specifications, it complements them by enabling use cases described in related guides, such as the FHIR Da Vinci Payer Data Exchange (PDex) and FHIR Da Vinci Clinical Data Exchange (CDex) IGs.
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
here
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
Digital Imaging and Communication in Medicine (DICOM®)
Final
Production
No
Free
No
Implementation Specification
IHE Portable Data for Imaging (PDI)
Final
Production
No
Free
No
Implementation Specification
The combination of IHE-XCPD (Cross-Community Patient Discovery)
Final
Production
No
Free
Yes
Yes
Yes
Implementation Specification
IHE Cross Community Access for Imaging (XCA-I)
Final
Pilot
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
Digital Imaging and Communications in Medicine (DICOM®)
Final
Production
No
Free
No
Standard
DICOMweb Store (STOW) and Query/Retrieve (WADO) - PS3.18 DICOM Standard – Part 18: Web Services
Final
Production
No
Free
No
Implementation Specification
IHE-PDQ (Patient Demographic Query)
Final
Production
No
Free
Yes
Yes
Implementation Specification
IHE-PIX (Patient Identifier Cross-Reference)
Final
Production
No
Free
Yes
Yes
Implementation Specification
IHE Cross Enterprise Document Sharing for Images (XDS-I.b)
Final
Production
No
Free
Yes
Yes
Implementation Specification
RESTful HL7® FHIR® Document Reference-based API Specifications
Final
Feedback requested
No
Emerging Implementation Specification
IHE - Patient Identifier Cross-reference for Mobile (PIXm)
Balloted Draft
Pilot
No
Free
No
Emerging Implementation Specification
IHE – WIA (Web-based Image Access)
Balloted Draft
Pilot
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
HL7® FHIR® SMART App Launch Implementation Guide (SMART App Launch IG)
Final
Production
Feedback Requested
No
Free
Yes
Emerging Implementation Specification
UDAP Security for Scalable HL7® FHIR® FAST UDAP Security for Scalable Registration, Authentication, and Authorization Implementation Guide
Balloted Draft
Feedback requested
Feedback Requested
No
Free
No
Emerging Implementation Specification
UDAP Dynamic Client Registration
Balloted Draft
Feedback requested
Feedback Requested
No
Free
No
Emerging Implementation Specification
UDAP JWT-Based Client Authentication
In Development
Feedback requested
Feedback Requested
No
Free
No
Emerging Implementation Specification
UDAP Client Authorization Grants
In Development
Feedback requested
Feedback Requested
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® SMART App Launch Implementation Guide (SMART App Launch IG)
This implementation specification specifies how applications connect to FHIR APIs by requesting authorization from OAuth 2.0-compliant authorization servers. It outlines the process by which an application requests authorization to access a FHIR resource and subsequently uses that authorization to retrieve the resource.
There are multiple versions of the SMART App Launch IG, all of which are compatible with FHIR Release 4 (R4). Historically, ASTP has adopted different versions of the SMART App Launch IG based on publication timing. Currently, ASTP has identified Version 2.0.0 as ready for adoption in Certified Health IT under the ASTP HTI-1 Final Rule. Certified Health IT developers typically adopt the version specified in program requirements or the version approved by the National Coordinator through ASTP’s Standards Version Advancement Process (SVAP).
The SMART App Launch IG facilitates a persistent application authorization process and adds a security layer to FHIR API deployments, addressing both FHIR server and FHIR application perspectives. This makes the SMART App Launch IG a foundational specification for any FHIR API implementation requiring secure access to FHIR Resources.
Referenced in Federal Rulemaking:
ASTP HTI-1 Final Rule
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
UDAP Security for Scalable HL7® FHIR® FAST UDAP Security for Scalable Registration, Authentication, and Authorization Implementation Guide
This implementation specification extends OAuth 2.0 to standardize and automate the application registration process using digital certificates, while securely authenticating participants within health information networks. This specification is compatible with the SMART App Launch IG and aligns with the security requirements of the Bulk Data IG.
ASTP has identified Version 1.0.0 of the FAST UDAP Security IG as ready for adoption in Certified Health IT. While its use is currently optional within the Trusted Exchange Framework and Common Agreement™ (TEFCA™), it is expected to become a requirement in the future.
The FAST UDAP Security IG provides a standardized method for dynamically registering applications through secure FHIR APIs. Implementers should consider adopting this specification for use cases requiring scalable trust among participants who agree to follow common policies, eliminating the need for individual agreements between organizations to establish trust.
ASTP anticipates that this specification will continue to evolve and mature based on implementation experience within TEFCA™.
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
IHE-PDQ (Patient Demographic Query)
Final
Production
No
Free
Yes
Yes
Yes
Implementation Specification
IHE-PIX (Patient Identifier Cross-Reference)
Final
Production
No
Free
Yes
Yes
Yes
Implementation Specification
IHE - XCPD (Cross Community Patient Discovery)
Final
Production
No
Free
Yes
Yes
Implementation Specification
IHE-Patient Identifier Cross-reference PIX for Mobile (PIXm)
Balloted Draft
Production
Feedback Requested
No
Free
Yes
Yes
Implementation Specification
IHE-Patient Demographics Query for Mobile (PDQm) Profile
Balloted Draft
Production
Feedback Requested
No
Free
Yes
Yes
Implementation Specification
IHE-Patient Master Identity Registry (PMIR) Profile
Balloted Draft
Feedback requested
Feedback Requested
No
Free
No
Emerging Implementation Specification
HL7® FHIR® FAST Interoperable Digital Identity and Patient Matching Implementation Guide
Balloted Draft
Feedback requested
Feedback Requested
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® FAST Interoperable Digital Identity and Patient Matching Implementation Guide
This implementation guide is designed to establish best practices and standards for digital identity and person matching. This specification provides detailed guidance on defining the match operation used in cross-organizational FHIR data exchanges, supporting accurate identity management and person matching.
Health IT developers and those that are interested in scaling FHIR are encouraged to follow the work being conducted by the
FAST Accelerator
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
See
Section II: Patient Identification Management
for more information about the HL7 2.5.1 ADT messaging standard and information about patient identity proofing.
Consider use of HL7® FHIR® Patient $match operation for MPI-based query.
The Patient Master Identity Registry
PMIR
Profile is a collaborative community-based system of cooperating patient identity sources maintaining a master identity for each patient.
PMIR
leverages the
FHIR
standard.
See the IHE IT Infrastructure White Paper covering the PMIR Profile -
The
Patient Demographics Query for Mobile (PDQm)
Profile provides similar functionality as PDQ but uses the
FHIR
standard.
PDQm
can be a FHIR API backed by a
PDQ
query or a
Cross-Enterprise Patient Discovery (XCPD)
query.
The PMIR, PDQm, and PIXm Profiles are used within the
MHDS
Profile to manage and find the patient’s identifier in that community as part of the
Centralized Discovery and Retrieve
environment.
MHD, PDQm and PIXm also have test plan pages:
MHD test plan page
PDQm test plan page
PIXm test plan page
See the IHE IT Infrastructure White Paper covering the methods of managing Patient Identities -
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
CDC-EHR-IIS Interoperability Enhancement Project Transport Layer Protocol Recommendation Formal Specification Version 1.2
Final
Production
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
eHealth Exchange Specification: Health Information Event Messaging Production Specification
Final
Production
No
Free
Yes
Implementation Specification
HL7® FHIR® Subscriptions R5 Backport Implementation Guide (Subscriptions IG)
Balloted Draft
Pilot
No
Free
Yes
Emerging Implementation Specification
IHE Document Metadata Subscription (DSUB), Trial Implementation
Balloted Draft
Pilot
No
Free
Yes
Yes
Emerging Implementation Specification
Carequality Subscription Implementation Guide for Push Notifications
Balloted Draft
Pilot
Feedback Requested
No
Free
N/A
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® Subscriptions R5 Backport Implementation Guide (Subscriptions IG)
This implementation specification allows clients to request notifications from FHIR servers when events occur. Once a subscription is established, a FHIR server can proactively notify the client when new information is added or existing information is updated within its system.
ASTP regulation recognizes Subscriptions IG Version 1.1.0 as compatible with FHIR Release 4 (R4) and suitable for addressing health IT needs within the current landscape. The R4 Subscriptions IG includes a subset of the capabilities available in the redesigned R5 version. Implementers interested in these capabilities should consider adopting the R4 specification.
The R5 Subscriptions framework underwent a significant redesign, introducing topic-based subscriptions, enhanced clarity, greater flexibility, and additional notification types. Looking ahead, ASTP anticipates that the Subscriptions framework will become even more advanced with the release of FHIR Release 6 (R6).
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
HL7® FHIR® RESTful API
Final
Production
Yes
Free
Yes
Implementation Specification
FHIR Bulk Data Access Implementation Guide
Final
Production
Feedback Requested
Yes
Free
Yes – Open
Implementation Specification
HL7 FHIR Da Vinci Payer Data Exchange Implementation Guide (PDex IG)
Balloted Draft
Production
No
Free
Yes
Implementation Specification
HL7 FHIR DaVinci Clinical Data Exchange (CDex) Implementation Guide
Balloted Draft
Pilot
No
Free
No
Implementation Specification
HL7 FHIR DaVinci Payer Health Record Exchange (HRex) Implementation Guide
Balloted Draft
Pilot
No
Free
No
Implementation Specification
HL7 FHIR US Core Implementation Guide STU 4.0.0
Final
Production
Feedback Requested
No
Free
Yes
Implementation Specification
HL7 FHIR Bulk Data Access (Flat FHIR) (v2.0.0 STU 2)
Final
Production
Feedback Requested
No
Free
Yes
Implementation Specification
HL7 FHIR US Core Implementation Guide STU 5.0.1
Final
Production
Feedback Requested
No
Free
Yes
Emerging Implementation Specification
IHE Mobile Cross-Enterprise Document Data Element Extraction (mXDE) Profile
Balloted Draft
Pilot
Feedback Requested
No
Free
No
Emerging Implementation Specification
IHE Query for Existing Data for Mobile (QEDm)
Balloted Draft
Pilot
Feedback Requested
No
Free
No
Implementation Specification
HL7 FHIR International Patient Access Implementation Guide (IPA IG)
Balloted Draft
Pilot
No
Free
Yes
Implementation Specification
HL7 FHIR Electronic Case Reporting Implementation Guide (eCR IG)
Balloted Draft
Pilot
Feedback Requested
No
Free
Yes
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® Bulk Data Access Implementation Guide (Bulk Data Access IG)
This implementation specification defines the process for accessing data for a specified group or set of patients from a FHIR server to a pre-authorized client application.
There are multiple versions of the Bulk Data Access IG, all of which are compatible with FHIR Release 4 (R4). Historically, ASTP has adopted different versions of the IG based on publication timing, and it has identified Version 1.0.0 as ready for adoption in Certified Health IT under the ASTP Cures Act Final Rule. While the Bulk Data Access IG serves as the primary specification for bulk data access in HL7 FHIR, other HL7 FHIR IGs may extend its functionality. Certified Health IT developers typically adopt the version specified in program requirements or the version approved by the National Coordinator through ASTP’s Standards Version Advancement Process (SVAP).
The Bulk Data Access IG ensures consistent health IT implementation of API-enabled access services for multiple patients. However, health IT developers have encountered performance and scalability challenges, which may be addressed in the future through use-case-specific development of FHIR Bulk Data Access IG implementations. Consequently, the performance and scalability of the Bulk Data Access IG depend on the specific use case. Developers are advised to consult the latest information from the health IT developer and standards community before adopting the IG to ensure alignment with current best practices and advancements.
Referenced in Federal Rulemaking:
ASTP Cures Act Final Rule
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
HL7® FHIR® Da Vinci Payer Data Exchange Implementation Guide (PDex IG)
This implementation specification provides a framework for payers and health plans to create a member’s health history using clinical resources based on the US Core IG. This health history can be shared with providers in a format that is understandable and can be integrated into their Certified Health IT systems. The PDex IG includes components for both payers and providers, enabling providers to access timely and comprehensive clinical information. This supports more informed treatment decisions, better adherence to care plans, and improved quality of care for patients.
ASTP and the Centers for Medicare & Medicaid Services (CMS) have identified PDex IG version 2.0 as ready for adoption in Certified Health IT. Developed by the Da Vinci Project Accelerator, the PDex IG is available for implementation without licensing requirements.
Payers and providers should consider adopting the PDex IG for use cases that involve exchanging clinical information between payers and providers, as well as enabling patients to access their clinical information from their payers.
Referenced in Federal Rulemaking:
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
HL7® FHIR® Da Vinci Da Vinci Clinical Data Exchange Implementation Guide (CDex IG)
This Implementation specification provides a framework for data exchange between providers and payers, as well as provider-to-provider and payer-to-payer workflows, for patient EHR data. The CDex IG supports query-based, task-based, and documents-based data exchange workflows.
The CDex IG is not intended to replace other HL7 FHIR Da Vinci specifications required by the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F). Instead, it focuses on specific workflows at the provider-payer interface, particularly when there is a need for manual review of received data query requests from external providers or payers. It is important to note that the CDex IG should not be implemented for workflows requiring real-time responses. Instead, it is suitable for scenarios where manual review of data query responses is necessary before delivering the data to partner providers or payers.
Certified Health IT developers, providers, and payers are encouraged to consider the CDex IG as a starting point for supporting data exchange at the provider-payer interface. This specification enables controlled and structured data sharing while allowing manual oversight to ensure accuracy and compliance in data exchange workflows.
HL7® FHIR® US Core Implementation Guide (US Core IG)
This implementation specification defines minimum constraints on FHIR Resources aligning with data elements specified in USCDI. Built on FHIR R4, it is the foundation of all US Realm implementation specifications. A foundational FHIR specification, US Core uses other specifications, such as the FHIR Structured Data Capture IG and the FHIR SMART App Launch IG, to optimize existing workflows.
There are multiple versions of the US Core IG, with each version corresponding to a specific annual release of USCDI. Historically, ASTP adopted different versions of the US Core IG based on publication timing. Currently, ASTP has identified US Core Version 6.1.0 as ready for adoption in Certified Health IT in the ASTP HTI-1 Final Rule. Certified Health IT developers typically adopt the version of the US Core IG that is specified in regulation or the version approved by the National Coordinator through ASTP’s
Standards Version Advancement Process (SVAP)
For use cases that rely on data elements defined in USCDI, the US Core IG often provides the simplest and most cost-effective solution for data exchange. Additionally, the US Core IG benefits from extensive support and expertise within the standards community and among health IT developers, ensuring successful implementation and accommodating modifications when necessary.
Referenced in Federal Rulemaking:
ASTP HTI-1 Final Rule
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
HL7® FHIR® International Patient Access Implementation Guide (IPA IG)
This implementation specification defines a framework for enabling third-party applications to access health information using FHIR APIs across multiple countries. This specification aims to promote consistency for multinational applications and FHIR servers by providing standardized authorization based on the SMART App Launch IG and a common set of FHIR Profiles derived from an analysis of existing national base profiles.
The IPA IG leverages international terminology standards and FHIR R4 Resources, ensuring compatibility and effective data sharing between this specification and the FHIR US Core IG.
While the IPA IG has not yet been widely implemented at scale in the United States, it serves as a strong foundation for regulators and national specification authors interested in developing a national health API ecosystem. ASTP anticipates that the IPA IG will mature as more experience is gained from its implementation.
HL7® FHIR® Electronic Case Reporting Implementation Guide (eCR IG)
This implementation specification supports the exchange of case data and bidirectional communication of public health information, focusing on a patient’s condition and local disease trends. As part of the
Public Health Data Strategy
, electronic case reporting is prioritized as a key automation to reduce administrative burden and promote more complete and timely data exchange.
The eCR IG enables the use of FHIR-based solutions aligned with FHIR R4 and the US Core IG for transmitting electronic case reports and reportability responses. It also facilitates the consumption and processing of electronic case reporting trigger codes, which are matched against the Reportable Conditions Trigger Code (RCTC) value set specified in the eCR IG.
While there are multiple versions of the eCR IG, ASTP has identified version 2.1.0 as most ready for adoption in Certified Health IT.
Referenced in Federal Rulemaking:
ASTP HTI-1 Final Rule
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
here
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
IHE-XCA (Cross-Community Access)
Final
Production
No
Free
Yes
Implementation Specification
IHE-XCPD (Cross-Community Patient Discovery)
Final
Production
No
Free
Yes
Yes
Implementation Specification
Carequality Query-Based Document Exchange Implementation Guide
Final
Production
No
Free
N/A
Implementation Specification
eHealth Exchange Specification: Patient Discovery
Final
Production
No
Free
Yes
Implementation Specification
eHealth Exchange Specification: Messaging Platform
Final
Production
No
Free
Yes
Implementation Specification
eHealth Exchange Specification: Authorization Framework
Final
Production
No
Free
Yes
Implementation Specification
eHealth Exchange Specification: Query for Documents
Final
Production
No
Free
Yes
Implementation Specification
eHealth Exchange Specification: Retrieve Documents
Final
Production
No
Free
Yes
Implementation Specification
HL7® FHIR® DocumentReference resource
Final
Production
No
Free
No
Implementation Specification
IHE-PIX (Patient Identifier Cross-Reference)
Final
Production
No
Free
Yes
Yes
Yes
Implementation Specification
CommonWell Health Alliance Specification Services
Balloted Draft
Production
No
Free
N/A
Implementation Specification
HL7 FHIR Da Vinci Da Vinci Clinical Data Exchange Implementation Guide (CDex IG)
Balloted Draft
Pilot
No
Free
No
Emerging Implementation Specification
IHE - MHDS (Mobile Health Document Sharing)
Balloted Draft
Pilot
Feedback Requested
No
Free
No
Implementation Specification
HL7 FHIR Da Vinci Payer Data Exchange Implementation Guide (PDex IG)
Balloted Draft
Production
No
Free
Yes
Implementation Specification
HL7 FHIR International Patient Summary Implementation Guide (IPS IG)
Balloted Draft
Pilot
No
Free
Yes
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® Da Vinci Da Vinci Clinical Data Exchange Implementation Guide (CDex IG)
This Implementation specification provides a framework for data exchange between providers and payers, as well as provider-to-provider and payer-to-payer workflows, for patient EHR data. The CDex IG supports query-based, task-based, and documents-based data exchange workflows.
The CDex IG is not intended to replace other HL7 FHIR Da Vinci specifications required by the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F). Instead, it focuses on specific workflows at the provider-payer interface, particularly when there is a need for manual review of received data query requests from external providers or payers. It is important to note that the CDex IG should not be implemented for workflows requiring real-time responses. Instead, it is suitable for scenarios where manual review of data query responses is necessary before delivering the data to partner providers or payers.
Certified Health IT developers, providers, and payers are encouraged to consider the CDex IG as a starting point for supporting data exchange at the provider-payer interface. This specification enables controlled and structured data sharing while allowing manual oversight to ensure accuracy and compliance in data exchange workflows.
HL7® FHIR® Da Vinci Payer Data Exchange Implementation Guide (PDex IG)
This implementation specification provides a framework for payers and health plans to create a member’s health history using clinical resources based on the US Core IG. This health history can be shared with providers in a format that is understandable and can be integrated into their Certified Health IT systems. The PDex IG includes components for both payers and providers, enabling providers to access timely and comprehensive clinical information. This supports more informed treatment decisions, better adherence to care plans, and improved quality of care for patients.
ASTP and the Centers for Medicare & Medicaid Services (CMS) have identified PDex IG version 2.0 as ready for adoption in Certified Health IT. Developed by the Da Vinci Project Accelerator, the PDex IG is available for implementation without licensing requirements.
Payers and providers should consider adopting the PDex IG for use cases that involve exchanging clinical information between payers and providers, as well as enabling patients to access their clinical information from their payers.
Referenced in Federal Rulemaking:
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
HL7® FHIR® International Patient Summary Implementation Guide (IPS IG)
This implementation specification defines an interoperable set of FHIR resources that contain a patient summary for sharing health information between patients and clinicians, primarily across countries. This specification uses international terminology standards and FHIR R4 resources, ensuring compatibility and effective data sharing between the IPS IG and the FHIR US Core IG.
Many European countries and members of the Global Digital Health Partnership—including the Netherlands, Estonia, the United Kingdom, Canada, Brazil, and New Zealand—are piloting the IPS FHIR IG and have expressed intentions to adopt it for projects within their countries. While the IPS IG is primarily designed for cross-border data sharing, it also supports domestic data exchange use cases, making it versatile for various healthcare scenarios.
Although the specification is still in the early stages of adoption, it provides a solid foundation for use cases requiring cross-border health data exchange. When combined with the International Patient Access (IPA) IG, the IPS IG creates a robust environment for digital innovation in healthcare.
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
IHE-XDS (Cross-enterprise document sharing)
Final
Production
No
Free
Yes
Yes
Implementation Specification
IHE-PDQ (Patient Demographic Query)
Final
Production
No
Free
Yes
Yes
Implementation Specification
IHE-PIX (Patient Identifier Cross-Reference)
Final
Production
No
Free
Yes
Yes
Implementation Specification
HL7® FHIR® Da Vinci Da Vinci Clinical Data Exchange Implementation Guide (CDex IG)
Balloted Draft
Pilot
No
Free
No
Implementation Specification
HL7 FHIR Da Vinci Payer Data Exchange Implementation Guide (PDex IG)
Balloted Draft
Pilot
No
Free
Yes
Emerging Implementation Specification
IHE – MHD (Mobile Access to Health Documents
Balloted Draft
Pilot
No
Free
Yes
Emerging Implementation Specification
IHE-PIXm (Patient Identifier Cross-Reference for Mobile)
Balloted Draft
Pilot
No
Free
No
Emerging Implementation Specification
IHE-PDQm (Patient Demographics Query-Reference for Mobile)
Balloted Draft
Pilot
No
Free
No
Emerging Implementation Specification
IHE - MHDS (Mobile Health Document Sharing)
Balloted Draft
Pilot
Feedback Requested
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® Da Vinci Da Vinci Clinical Data Exchange Implementation Guide (CDex IG)
This Implementation specification provides a framework for data exchange between providers and payers, as well as provider-to-provider and payer-to-payer workflows, for patient EHR data. The CDex IG supports query-based, task-based, and documents-based data exchange workflows.
The CDex IG is not intended to replace other HL7 FHIR Da Vinci specifications required by the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F). Instead, it focuses on specific workflows at the provider-payer interface, particularly when there is a need for manual review of received data query requests from external providers or payers. It is important to note that the CDex IG should not be implemented for workflows requiring real-time responses. Instead, it is suitable for scenarios where manual review of data query responses is necessary before delivering the data to partner providers or payers.
Certified Health IT developers, providers, and payers are encouraged to consider the CDex IG as a starting point for supporting data exchange at the provider-payer interface. This specification enables controlled and structured data sharing while allowing manual oversight to ensure accuracy and compliance in data exchange workflows.
HL7® FHIR® Da Vinci Payer Data Exchange Implementation Guide (PDex IG)
This implementation specification provides a framework for payers and health plans to create a member’s health history using clinical resources based on the US Core IG. This health history can be shared with providers in a format that is understandable and can be integrated into their Certified Health IT systems. The PDex IG includes components for both payers and providers, enabling providers to access timely and comprehensive clinical information. This supports more informed treatment decisions, better adherence to care plans, and improved quality of care for patients.
ASTP and the Centers for Medicare & Medicaid Services (CMS) have identified PDex IG version 2.0 as ready for adoption in Certified Health IT. Developed by the Da Vinci Project Accelerator, the PDex IG is available for implementation without licensing requirements.
Payers and providers should consider adopting the PDex IG for use cases that involve exchanging clinical information between payers and providers, as well as enabling patients to access their clinical information from their payers.
Referenced in Federal Rulemaking:
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
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
IHE IT Infrastructure Technical Framework Supplement, Care Services Discovery (CSD), Trial Implementation
Balloted Draft
Pilot
No
Free
Yes
Implementation Specification
IHE IT Infrastructure Technical Framework Supplement 10 Mobile Care Services Discovery (mCSD) Trial Implementation
Balloted Draft
Pilot
Feedback Requested
No
Free
No
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
See
Human Services Data Specification and API Protocols
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
Alliance of Information and Referral Systems (AIRS™) Standards and Quality Indicators for Professional Information and Referral
Final
Production
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
ASC X12®C/005010X231 Implementation Acknowledgment for Health Care Insurance (999), June 2007 as an ASC X12 Standards for Electronic Data Interchange Technical Report Type 3 and
Final
Production
No
No
Implementation Specification
ASC X12N/006020X290 Implementation Acknowledgment for Health Care Insurance (999), September 2013 as an ASC X12 Standards for Electronic Data Interchange Technical Report Type 3
Final
Pilot
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
. 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
.  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
ASC X12®N/005010X220 Benefit Enrollment and Maintenance (834), August 2006 as an ASC X12 Standards for Electronic Data Interchange Technical Report Type 3 and
Final
Production
Yes
Yes
Implementation Specification
ASC X12N/005010X307 Health Insurance Exchange: Enrollment (834), January 2013, as an ASC X12 Standards for Electronic Data Interchange Technical Report Type 3
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
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
ASC X12®N/005010X279 Health Care Eligibility Benefit Inquiry and Response (270/271), April 2008 as an ASC X12 Standards for Electronic Data Interchange Technical Report Type 3 and
Final
Production
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
. 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
NCPDP® Telecommunication Standard Implementation Guide, Version D, Release 0 (Version D.0), August 2010 and equivalent Batch Standard Implementation Guide Version 1.2
Final
Production
Yes
Yes
Implementation Specification
NCPDP Telecommunication Standard, Implementation Guide, Version F6, April 2022 and Equivalent Batch Standard Implementation Guide, Version 15
Final
Production
No
No
Implementation Specification
NCPDP Real-Time Prescription Benefit Standard Version 12
Final
Production
No
No
Implementation Specification
NCPDP Real-Time Prescription Benefit (RTPB) Standard, Implementation Guide, Version 13
Final
Feedback requested
Feedback Requested
No
No
Implementation Specification
HL7® FHIR® Da Vinci Payer Data Exchange US Drug Formulary Implementation Guide (PDex Drug Formulary IG)
Balloted Draft
Production
No
Free
Yes
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® Da Vinci Payer Data Exchange US Drug Formulary Implementation Guide (PDex Drug Formulary IG)
This implementation specification provides a framework for payer health IT systems to share drug formulary information with patients via FHIR APIs. The specification supports two types of drug formulary data exchange. Public-facing general plan formulary data, accessible to all users, does not include protected health information (PHI) or personally identifiable information (PII). Access-controlled, personalized formulary data is integrated with PHI or PII and provides specific patients with personalized information based on their medications.
By enabling patients to access a payer’s drug formulary information through FHIR APIs, this specification helps patients find cost-saving alternatives, compare plans more easily, and understand differences between drug tiers and pharmacy benefit types. It also empowers insurers to educate consumers about their options.
CMS has identified PDex Drug Formulary IG Version 2.0.1 as ready for adoption in Certified Health IT. Developed by the Da Vinci Project Accelerator, the IG is available for implementation without licensing requirements, making it accessible to payers and health IT developers.
Referenced in Federal Rulemaking:
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
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
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
NACHA® Operating Rules, Appendix One and Three ACH File Exchange Specifications; ACH Record Format Specifications, Subpart 3.1.8 Sequence of Records for CCD Entries; and
Final
Production
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.
All covered entities are required to meet HIPAA security and privacy requirements in order for Electronic Data Interchange (EDI) to occur.
For Automated Clearing House (ACH) Network risks and enforcement, one can refer to
NACHA’s ACH Network Risk and Enforcement Topics
and
2019 NACHA Operating Rules & Guidelines
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
ASC X12®N/005010X221 Health Care Claim Payment/Advice (835), April 2006 as an ASC X12 Standards for Electronic Data Interchange Technical Report Type 3 and
Final
Production
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
. 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
ASC X12®N/005010X218 Payroll Deducted and Other Group Premium Payment for Insurance Products (820), February 2007 as an ASC X12 Standards for Electronic Data Interchange Technical Report Type 3
Final
Production
Yes
Yes
Implementation Specification
ASC X12N/005010X306 Health Insurance Exchange Related Payments (820), January 2013 as Type 1 Errata to an ASC X12 Standards for Electronic Data Interchange Technical Report Type 3
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
. 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
ASC X12®N/006020X315 Health Care Services Request for Review and Response (278), September 2014 as an ASC X12 Standards for Electronic Data Interchange Technical Report Type 3
Final
Production
No
No
Implementation Specification
ASC X12N/006020X313 Health Care Claim Request for Additional Information (277), September 2014 as an ASC X12 Standards for Electronic Data Interchange Technical Report Type 3
Final
Production
No
No
Implementation Specification
ASC X12N/006020X316 Additional Information to Support a Health Care Services Review (275), September 2014 as an ASC X12 Standards for Electronic Data Interchange Technical Report Type 3
Final
Production
No
No
Implementation Specification
HL7 CDA® R2 Attachment Implementation Guide: Exchange of C-CDA Based Documents, Release 1 - US Realm
Final
Production
No
Free
No
Implementation Specification
HL7 CDA R2 Implementation Guide: Consolidated CDA Templates for Clinical Notes (US Realm) Draft Standard for Trial Use Release 2.1
Final
Production
No
Free
No
Implementation Specification
HL7® FHIR® Da Vinci Da Vinci Clinical Data Exchange Implementation Guide (CDex IG)
Balloted Draft
Pilot
No
Free
Yes
Implementation Specification
NCPDP SCRIPT Standard Implementation Guide Version 2023011
Final
Pilot
Feedback Requested
No
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® Da Vinci Da Vinci Clinical Data Exchange Implementation Guide (CDex IG)
This Implementation specification provides a framework for data exchange between providers and payers, as well as provider-to-provider and payer-to-payer workflows, for patient EHR data. The CDex IG supports query-based, task-based, and documents-based data exchange workflows.
The CDex IG is not intended to replace other HL7 FHIR Da Vinci specifications required by the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F). Instead, it focuses on specific workflows at the provider-payer interface, particularly when there is a need for manual review of received data query requests from external providers or payers. It is important to note that the CDex IG should not be implemented for workflows requiring real-time responses. Instead, it is suitable for scenarios where manual review of data query responses is necessary before delivering the data to partner providers or payers.
Certified Health IT developers, providers, and payers are encouraged to consider the CDex IG as a starting point for supporting data exchange at the provider-payer interface. This specification enables controlled and structured data sharing while allowing manual oversight to ensure accuracy and compliance in data exchange workflows.
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
NCPDP® Telecommunication Standard Implementation Guide, Version D, Release 0 (Version D.0), August 2010
Final
Production
Yes
Yes
Implementation Specification
NCPDP SCRIPT Standard, Implementation Guide, Version 2017071
Final
Production
No
No
Implementation Specification
NCPDP Telecommunication Standard, Implementation Guide, Version F6, April 2022
Final
Production
No
No
Implementation Specification
NCPDP SCRIPT Standard, Implementation Guide, Version 2023011
Final
Pilot
Feedback Requested
No
No
Implementation Specification
HL7® FHIR® Da Vinci Da Vinci Clinical Data Exchange Implementation Guide (CDex IG)
Balloted Draft
Pilot
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® Da Vinci Da Vinci Clinical Data Exchange Implementation Guide (CDex IG)
This Implementation specification provides a framework for data exchange between providers and payers, as well as provider-to-provider and payer-to-payer workflows, for patient EHR data. The CDex IG supports query-based, task-based, and documents-based data exchange workflows.
The CDex IG is not intended to replace other HL7 FHIR Da Vinci specifications required by the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F). Instead, it focuses on specific workflows at the provider-payer interface, particularly when there is a need for manual review of received data query requests from external providers or payers. It is important to note that the CDex IG should not be implemented for workflows requiring real-time responses. Instead, it is suitable for scenarios where manual review of data query responses is necessary before delivering the data to partner providers or payers.
Certified Health IT developers, providers, and payers are encouraged to consider the CDex IG as a starting point for supporting data exchange at the provider-payer interface. This specification enables controlled and structured data sharing while allowing manual oversight to ensure accuracy and compliance in data exchange workflows.
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
Updated referral transactions are published in the NCPDP SCRIPT Standard Version 2023011. 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
ASC X12®N/005010X217 Health Care Services Review—Request for Review and Response (278), May 2006 as an ASC X12 Standards for Electronic Data Interchange Technical Report Type 3
Final
Production
Yes
Yes
Implementation Specification
HL7® FHIR® Da Vinci Coverage Requirements Discovery Implementation Guide (CRD IG)
Balloted Draft
Production
Yes
Free
Yes
Yes
Implementation Specification
HL7® FHIR® Da Vinci Documentation Templates and Rules Implementation Guide (DTR IG)
Balloted Draft
Production
Yes
Free
Yes
Yes
Implementation Specification
HL7® FHIR® Da Vinci Prior Authorization Support Implementation Guide (PAS IG)
Balloted Draft
Production
Yes
Free
Yes
Yes
Implementation Specification
HL7 CDA® R2 Implementation Guide: Dental Data Exchange
Balloted Draft
Production
No
Free
Yes
Implementation Specification
HL7® FHIR® Da Vinci Da Vinci Clinical Data Exchange Implementation Guide (CDex IG)
Balloted Draft
Pilot
No
Free
No
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® Da Vinci Coverage Requirements Discovery Implementation Guide (CRD IG)
This implementation specification provides a framework for payers to share information about coverage requirements with providers, helping facilitate treatment decisions based on a patient’s insurance coverage. This specification is critical for standardizing API-based electronic prior authorization workflows, which aim to reduce delays in patient treatment and alleviate the administrative burden on providers.
CMS has identified CRD IG Version 2.0.1 as ready for adoption in Certified Health IT. Developed by the Da Vinci Project Accelerator, the CRD IG is available for implementation without licensing requirements, making it accessible to payers and providers.
Payers and providers should consider the CRD IG to streamline the prior authorization process. By automating the exchange of coverage requirements and documentation, this specification reduces the administrative workload associated with assembling and reviewing prior authorization materials.
Referenced in Federal Rulemaking:
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
HL7® FHIR® Da Vinci Documentation Templates and Rules Implementation Guide (DTR IG)
This implementation specification provides a framework for payers to define documentation requirements and provider-specific rules, while enabling providers to automatically submit the necessary documentation via FHIR APIs. This specification is essential for standardizing API-based electronic prior authorization workflows, which aim to reduce delays in patient treatment and alleviate the administrative burden on providers.
CMS has identified DTR IG Version 2.0.0 as ready for adoption in Certified Health IT. Developed by the HL7 Da Vinci Project, the DTR IG is available for implementation without licensing requirements, making it accessible to payers and providers.
Payers and providers should consider the DTR IG to streamline the prior authorization process. By automating the submission of required documentation, this specification reduces the administrative workload associated with prior authorization.
Referenced in Federal Rulemaking:
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
HL7® FHIR® Da Vinci Prior Authorization Support Implementation Guide (PAS IG)
This implementation specification defines a framework for payer and provider health IT systems to support the submission, receipt, and response to electronic prior authorization requests. This specification is critical for standardizing API-based electronic prior authorization workflows, helping to reduce patient treatment delays and alleviate the administrative burden on providers. Together with the Coverage Requirements Discovery (CRD) IG and Documentation Templates and Rules (DTR) IG, the PAS IG forms a comprehensive solution for streamlining prior authorization processes.
CMS has identified PAS IG Version 2.0.1 as ready for adoption in Certified Health IT. Developed by the Da Vinci Project Accelerator, the PAS IG is available for implementation without licensing requirements, making it accessible to payers and providers.
Referenced in Federal Rulemaking:
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
HL7® FHIR® Da Vinci Da Vinci Clinical Data Exchange Implementation Guide (CDex IG)
This Implementation specification provides a framework for data exchange between providers and payers, as well as provider-to-provider and payer-to-payer workflows, for patient EHR data. The CDex IG supports query-based, task-based, and documents-based data exchange workflows.
The CDex IG is not intended to replace other HL7 FHIR Da Vinci specifications required by the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F). Instead, it focuses on specific workflows at the provider-payer interface, particularly when there is a need for manual review of received data query requests from external providers or payers. It is important to note that the CDex IG should not be implemented for workflows requiring real-time responses. Instead, it is suitable for scenarios where manual review of data query responses is necessary before delivering the data to partner providers or payers.
Certified Health IT developers, providers, and payers are encouraged to consider the CDex IG as a starting point for supporting data exchange at the provider-payer interface. This specification enables controlled and structured data sharing while allowing manual oversight to ensure accuracy and compliance in data exchange workflows.
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
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
HL7 FHIR Da Vinci Patient Cost Transparency Implementation Guide
Balloted Draft
Feedback requested
No
Free
Yes
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
X12®N/005010X212 Health Care Claim Status Request and Response (276/277), August 2006 as an ASC X12 Standards for Electronic Data Interchange Technical Report Type 3
Final
Production
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
. 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
ASC X12®N/005010X224 ASC X12 Standards for Electronic Data Interchange Technical Report Type 3—Health Care Claim: Dental (837), May 2006 as an ASC X12 Standards for Electronic Data Interchange Technical Report Type 3 and
Final
Production
Yes
Yes
Implementation Specification
HL7® FHIR® Consumer Directed Payer Data Exchange Implementation Guide (CARIN IG for Blue Button®)
Balloted Draft
Pilot
Yes
Free
Yes
Yes
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® Consumer Directed Payer Data Exchange Implementation Guide (CARIN IG for Blue Button®)
This implementation specification provides a framework for payers to enable patient access to their claims information via a standardized FHIR API. It defines the Common Payer Consumer Data Set (CPCDS), which is a set of FHIR resources that payers can make available to patients. In addition to patient access, the profiles in this IG are expected to be reusable for other use cases, such as Provider Access and Payer-to-Payer APIs.
CMS has identified CARIN IG for Blue Button Version 2.0.0 as ready for adoption in Certified Health IT. Developed by the CARIN Alliance, the IG is available for implementation without licensing requirements, making it accessible to payers and health IT developers.
Implementers are encouraged to adopt the CARIN IG for Blue Button for use cases that require payers to provide patients with access to their claims information.
Referenced in Federal Rulemaking:
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
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
. 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
ASC X12®/N005010X223 Health Care Claim: Institutional (837), May 2006 as an ASC X12 Standards for Electronic Data Interchange Technical Report Type 3 and
Final
Production
Yes
Yes
Implementation Specification
HL7® FHIR® Consumer Directed Payer Data Exchange Implementation Guide (CARIN IG for Blue Button®) STU 1
Final
Production
Yes
Free
Yes
Implementation Specification
HL7 FHIR Consumer Directed Payer Data Exchange Implementation Guide (CARIN IG for Blue Button®) STU 2
Balloted Draft
Pilot
Yes
Free
Yes
Yes
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7 FHIR Consumer Directed Payer Data Exchange Implementation Guide (CARIN IG for Blue Button®)
This implementation specification provides a framework for payers to enable patient access to their claims information via a standardized FHIR API. It defines the Common Payer Consumer Data Set (CPCDS), which is a set of FHIR resources that payers can make available to patients. In addition to patient access, the profiles in this IG are expected to be reusable for other use cases, such as Provider Access and Payer-to-Payer APIs.
CMS has identified CARIN IG for Blue Button Version 2.0.0 as ready for adoption in Certified Health IT. Developed by the CARIN Alliance, the IG is available for implementation without licensing requirements, making it accessible to payers and health IT developers.
Implementers are encouraged to adopt the CARIN IG for Blue Button for use cases that require payers to provide patients with access to their claims information.
Referenced in Federal Rulemaking:
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
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
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
ASC X12®N/005010X222 Health Care Claim: Professional (837), May 2006 as an ASC X12 Standards for Electronic Data Interchange Technical Report Type 3
Final
Production
Yes
Yes
Implementation Specification
HL7® FHIR® Consumer Directed Payer Data Exchange Implementation Guide (CARIN IG for Blue Button®) STU 1
Final
Production
Yes
Free
Yes
Implementation Specification
HL7 FHIR Consumer Directed Payer Data Exchange Implementation Guide (CARIN IG for Blue Button®) STU 2
Balloted Draft
Pilot
Yes
Free
Yes
Yes
Federal FHIR Action Plan:
Marks standards for coordinated federal adoption. See Appendix V:
Federal FHIR Action Plan
for more details.
Federal FHIR Action Plan Alignment
HL7® FHIR® Consumer Directed Payer Data Exchange Implementation Guide (CARIN IG for Blue Button®)
This implementation specification provides a framework for payers to enable patient access to their claims information via a standardized FHIR API. It defines the Common Payer Consumer Data Set (CPCDS), which is a set of FHIR resources that payers can make available to patients. In addition to patient access, the profiles in this IG are expected to be reusable for other use cases, such as Provider Access and Payer-to-Payer APIs.
CMS has identified CARIN IG for Blue Button Version 2.0.0 as ready for adoption in Certified Health IT. Developed by the CARIN Alliance, the IG is available for implementation without licensing requirements, making it accessible to payers and health IT developers.
Implementers are encouraged to adopt the CARIN IG for Blue Button for use cases that require payers to provide patients with access to their claims information.
Referenced in Federal Rulemaking:
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
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
. 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
NCPDP® Telecommunication Standard Implementation Guide, Version D, Release 0 (Version D.0), August 2010
Final
Production
Yes
Yes
Implementation Specification
NCPDP Telecommunication Standard, Implementation Guide Version F6, April 2022
Final
Production
No
No
Implementation Specification
NCPDP Batch Standard Medicaid Subrogation Implementation Guide Version 3.0
Final
Production
Yes
No
Implementation Specification
NCPDP Batch Standard Subrogation Implementation Guide Version 10
Final
Production
No
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
NCPDP® Telecommunication Standard Implementation Guide, Version D, Release 0 (Version D.0), August 2010
Final
Production
Yes
Yes
Implementation Specification
ASC X12®N/005010X222 Health Care Claim: Professional (837), May 2006 as an ASC X12 Standards for Electronic Data Interchange Technical Report Type 3 and
Final
Production
Yes
Yes
Implementation Specification
NCPDP Batch Standard Medicaid Subrogation Implementation Guide Version 3.0
Final
Production
Yes
No
Implementation Specification
NCPDP Telecommunication Standard, Implementation Guide Version F6, April 2022 and equivalent Batch Standard Implementation Guide Version 15
Final
Production
No
Yes
Standard
NCPDP Batch Standard Subrogation Implementation Guide Version 10
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
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
CORE Benefit Enrollment & Maintenance (834) Data Content Rule Version BEM.1.0
Final
Production
No
Free
Yes
Operating Rules
ORE Benefit Enrollment and Maintenance (834) Infrastructure Rule Version BE.3.0
Final
Production
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
CAQH CORE Claim Status (276/277) Infrastructure Rule Version CS.1.0
Final
Production
Yes
Free
Yes
Operating Rules
CAQH CORE Claim Status (276/277) Infrastructure Rule Version CS.2.0
Final
Production
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
CAQH CORE Operating Rules for Connectivity
Final
Production
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
CAQH CORE Payment & Remittance ERA Enrollment Data Rule Version PR.1.0
Final
Production
Yes
Free
Yes
Operating Rules
CAQH CORE Payment & Remittance (835) Infrastructure Rule Version PR.2.0
Final
Production
No
Free
Yes
Operating Rules
CAQH CORE Payment & Remittance (835) Uniform Use of CARCs and RARCs Rule Version PR.1.1
Final
Production
Yes
Free
Yes
Operating Rules
CAQH CORE Payment & Remittance (CCD+/835) Reassociation Rule Version PR.1.0
Final
Production
Yes
Free
Yes
Operating Rules
CAQH CORE Payment & Remittance (835) Infrastructure Rule Version PR.1.0
Final
Production
No
Free
Yes
Operating Rules
CAQH CORE Payment & Remittance EFT Enrollment Data Rule Version PR.2.0
Final
Production
No
Free
Yes
Operating Rules
CORE-required Maximum ERA Enrollment Data Set Companion Document
Final
Production
Yes
Free
Yes
Operating Rules
CORE Payment & Remittance ERA Enrollment Data Rule Version PR.2.0
Final
Production
No
Free
Yes
Operating Rules
CAQH CORE – required Maximum EFT Enrollment Data Set Companion Document
Final
Production
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
CAQH CORE Eligibility & Benefits (270/271) Data Content Rule Version EB.1.0
Final
Production
No
Free
Yes
Operating Rules
CAQH CORE Eligibility & Benefits (270/271) Infrastructure Rule Version EB.1.0
Final
Production
Yes
Free
Yes
Operating Rules
CAQH CORE Eligibility & Benefits (270/271) Data Content Rule Version EB.2.0
Final
Production
No
Free
Yes
Operating Rules
CAQH CORE Eligibility & Benefits (270/271) Infrastructure Rule Version EB.2.0
Final
Production
No
Free
Yes
Operating Rules
CAQH CORE Eligibility & Benefits (270/271) Single Patient Attribution Data Content Rule vEB.1.0
Final
Production
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
CAQH CORE Health Care Claim (837) Infrastructure Rule Version HC.2.0
Final
Production
No
Free
Yes
Operating Rules
CAQH CORE Attachments Health Care Claims Data Content Rule Version HC.1.0
Final
Production
No
Free
Yes
Operating Rules
CAQH CORE Attachments Health Care Claims Infrastructure Rule Version HC.1.0
Final
Production
No
Free
Yes
Operating Rules
CORE Claim Acknowledgment (277CA) Data Content Rule Version CA.1.0
Final
Production
No
Free
Yes
Operating Rules
CORE Health Care Claims (837) Data Content Rule Version HC.1.0
Final
Production
No
Free
Yes
Implementation Specification
NCPDP Telecommunication Standard, Implementation Guide, Version F10
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
CAQH CORE Premium Payment (820) Final Infrastructure Rule Version PP.2.0
Final
Production
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
CAQH CORE Prior Authorization & Referrals (278) Data Content Rule Version PA.1.0
Final
Production
No
Yes
Operating Rules
CAQH CORE Prior Authorization & Referrals (278) Infrastructure Rule Version PA.3.0
Final
Production
No
Yes
Operating Rules
CAQH CORE Prior Authorization Web Portal Rule Version PA.1.0
Final
Production
No
Yes
Operating Rules
CAQH CORE Attachments Prior Authorization Data Content Rule Version PA.1.0
Final
Production
No
Yes
Operating Rules
CAQH CORE Attachments Prior Authorization Infrastructure Rule Version PA.1.0
Final
Production
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
CORE Attributed Patient Roster (X12 v5010X318 834) Data Content Rule vAPR.2.0
Final
Production
No
Free
Yes
Operating Rules
CORE Attributed Patient Roster (X12 v5010X318 834) Infrastructure Rule vAPR.3.0
Final
Production
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
NCPDP® Operating Rules for the Formulary and Benefit Standard v10
Final
Pilot
No
No
Implementation Specification
NCPDP® Operating Rules for the Formulary and Benefit Standard v60
Final
Production
No
No
Implementation Specification
NCPDP SCRIPT Standard, Implementation Guide Version 2023011
Final
Pilot
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 2023011.
Feedback requested.
Appendices
Appendix I: Sources of Security Standards and Security Patterns
In the Interoperability Standards Advisory, a structure to capture necessary security patterns associated with interoperability needs is represented. To address public comments that requested a distinct security standards section the list below provides a number of sources to which stakeholders can look in order to find the latest applicable security standards. Note that this list is not meant to be exhaustive, and while every effort is made to ensure links are current, links may become outdated as organizations make changes to their websites.
Security Pattern Catalog
HIPAA Security regulations that are specific to healthcare
HIPAA Security Rule Crosswalk to NIST Cybersecurity Framework
ASTM
ASTM E1384-07 (2013) Standard Practice for Content and Structure of the Electronic Health Record (EHR)
ASTM E1714-07(2013) Standard Guide for Properties of a Universal Healthcare Identifier (UHID)
ASTM E1762 – 95 (2013) Standard Guide for Electronic Authentication of Health Care
ASTM E1985-98(2013) Standard Guide for User Authentica
tion and Authorization
ASTM E1986 – 09 (2013) Standard Guide for Information Access Privileges to Health
ASTM E2017-99 (2010) Standard Guide for Amendments to Health Information
ASTM E2147-01(2013) Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems
ASTM E2212-02a(2010) Standard Practice for Healthcare Certificate Policy
ASTM E2595 - -07 (2013) Standard Guide for Privilege Management Infrastructure
Information Organization for Standardization (ISO) Information Security Standards
ISO/TS 14265:2011 Health Informatics
- Classification of purposes for
processing personal health information:
ISO IT Security techniques
– evaluation criteria for IT security,
ISO/EC 15408 series
ISO 17090-1:2013 Health Informatics
- Public Key Infrastructure - Part 1: Overview of digital certificate services
ISO 17090-2:2015 Health Informatics
- Public key infrastructure -- Part 2: Certificate profile
ISO 17090-3:2008 Health Informatics
- Public key infrastructure - Part 3: Policy management of certification authority
ISO/IS 17090-4 Health Informatics
- Public key infrastructure-Part 4: Digital signatures for healthcare documents
ISO/TS 17975:2015 Health Informatics
- Principles and data requirements for consent in the Collection, Use or Disclosure of personal health information
ISO/TR 21089:2004(en) Health Informatics
— Trusted end-to-end information flows
ISO 21091: 2013 Health Informatics
- Directory services for healthcare providers, subjects of care and other entities
ISO/TS 21298:2008 Health Informatics
-- Functional and structural roles
National Institute for Standards and Technology (NIST) Special Publications 800 Series
NIST’s Federal Information Processing Standards (FIPS)
NIST Special Publication 800-53. Security and Privacy Controls for Federal Information Systems and Organizations Revision 4. April 2013
NIST Privacy Risk Management for Federal Information Systems. NISTIR 8062 Draft. May 2015
NIST Special Publication: 800-63-2. Electronic Authentication Guideline. August 2013.
NIST Digital Authentication Guideline, Special Publication 800-63-3, Public Draft, Q4 2016
NIST FIPS PUB 202. SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions. August 2015
NIST SP 1800-a-e. Securing Electronic Health Records on Mobile Devices. July 2015.
and
NIST Guide for Conducting Risk Assessments, Special Publication 800-30 Revision 1
NIST Framework for Improving Critical Infrastructure Cybersecurity, V1, February 2014
NIST Framework for Improving Critical Infrastructure Cybersecurity, V1.1, April 2018
NIST 800-53 Rev 4: Security & Privacy controls
NIST SP 800-183: Network of 'Things'
NIST SP 800-160: Systems Security Engineering
NIST CSP 500-291: Cloud Computing
NIST SP 1500-1: Big Data Interoperability
OpenID Connect 1.0
OAUTH 2.0
OAuth 2.0 Dynamic Client Registration
User-Managed Access (UMA) Profile of OAuth 2.0
Integrating the Healthcare Enterprise (IHE)
Cybersecurity Standards
Consistent Time
Enterprise User Authentication
Cross-Enterprise User Assertion (XUA)
Document Digital Signature
Basic Patient Privacy Consents
Advanced Patient Privacy Consents (APPC)
Document Encryption
Access Control
Audit Trail and Node Authentication (ATNA)
Template for XDS Affinity Domain Deployment Planning
Mobile Care Services Discovery (mCSD)
Internet User Authorization (IUA)
Secure Retrieve (SeR)
Enabling Document Sharing Health Information Exchange Using IHE Profiles Whitepaper
HL7 CDA® R2 Implementation Guide: Patient-Friendly Language for Consumer User-Interfaces, Release 1
HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1
HL7 Healthcare Privacy and Security Classification System (HCS), Release 1
HL7 Implementation Guide for CDA®, Release 2: Privacy Consent Directives, Release 2
HL7 FHIR Security
HL7 Version 3 Standard: Security and Privacy Ontology, Release 1Category: Privacy and Consent
HL7 Version 3 Standard: Healthcare (Security and Privacy) Access Control Catalog, Release 3
HL7 Version 3 Standard: Privacy, Access and Security Services (PASS) Access Control Services Conceptual Model, Release 1
HL7 Version 3 Standard: Privacy, Access and Security Services; Security Labeling Service, Release 1 (SLS)
Structured Threat Information Expression (STIX)
Trusted Automated Exchange of Indicator Information (TAXII)
SMART App Launch Framework
Unified Data Access Profiles (UDAP)
JWT-Based Client Authentication
Tiered OAuth for User Authentication
Dynamic Client Registration
Mutual TLS Client Authentication
Client Certifications and Endorsements
Client Authorization Grants using JWTs
UDAP Implementation Guide for Registration and Authorization of Consumer Facing Health Apps
UDAP Implementation Guide for Registration and Authorization of Business-To-Business Health Apps
Appendix II: Models and Profiles
The Interoperability Standards Advisory includes a structure for capturing relevant data models and profiles that support identified interoperability needs. In response to public comments requesting a dedicated section for data models, the list below offers a selection of sources where stakeholders can find the most current and applicable data models.
Please note that this list is not exhaustive. While every effort is made to ensure that links remain up to date, they may become outdated as organizations update their websites.
The ISA is intended to serve as an informational resource for available standards, specifications, profiles, and related materials that support interoperability. Stakeholders are responsible for ensuring compliance with applicable federal, state, and local laws or regulations, which may mandate the use of specific standards or specifications. In cases where such requirements conflict with information in the ISA, those legal or regulatory requirements take precedence.
HL7 Standards - Section 1: Primary Standards
Section 1 Primary standards are the most popular standards integral for system integrations, and interoperability. Most frequently used and in-demand standards are in this category. (This section also includes the Version 2 and Version 3 solution sets, which encompass all standards relative to that version. HL7's primary standards and other select products are licensed at no cost. Additional information can be found at
HL7's licensing cost update.
HL7 Standards - Section 2: Foundational Standards
Foundational standards define the fundamental tools and building blocks used to build the standards, and the technology infrastructure that implementers of HL7 standards must manage.
HL7 Standards - Section 3: Clinical and Administrative Domains
Messaging and document standards for clinical specialties and groups are found in this section. These standards are usually implemented once primary standards for the organization are in place.
HL7 Standards - Section 4: EHR Profiles
These standards provide functional models and profiles that enable the constructs for management of electronic health records.
HL7 Reference Information Model
The Reference Information Model (RIM) is the cornerstone of the HL7 Version 3 development process. An object model created as part of the Version 3 methodology, the RIM is a large, pictorial representation of the HL7 clinical data (domains) and identifies the life cycle that a message or groups of related messages will carry. It is a shared model between all domains and, as such, is the model from which all domains create their messages. The RIM is an ANSI approved standard.
IHE Profiles
IHE Profiles describe specific solutions to integration problems. A profile documents how standards will be used by each system's actors to address the problem.
IHE Profiles for Health Information Exchange
“IHE Profiles for Health Information Exchange” acts as a comprehensive resource that aggregates the disparate IHE profiles and support tools and points developers directly towards the insights and materials that are relevant to their particular implementations.
IHE Technical Frameworks
The IHE Technical Frameworks are a resource for users, developers and implementers of healthcare imaging and information systems. They define specific implementations of established standards to achieve effective systems integration, facilitate appropriate sharing of medical information and support optimal patient care.
IHE Document Sharing
The IHE Document Sharing is a framework in multiple architectures.
OMG Healthcare
The suite of healthcare standards developed by the Object Management Group (OMG), in collaboration with Health Level Seven (HL7), provides a comprehensive framework that supports the coexistence of legacy integration strategies while aligning with current industry best practices. These standards draw on proven technical approaches and solutions from other vertical markets.
X12
X12, chartered by the American National Standards Institute, develops and maintains EDI standards and XML schemas which drive business processes globally.
FHIM
Federal Health Information Model program coordinates the efforts of the partner agencies with the development of Electronic Medical Records, information and terminology standards, including the coordination of agency efforts at relevant Standards Development Organizations (SDOs).
HIMSS - Types of Standards
A wide range of standards exist to drive interoperability of electronic health information. Health data standards can be grouped into four specific categories: transport, vocabulary, content, privacy/security, and identifier standards. This site provides links to more information on the specific standards within each category, and additional resources to better understand their implementation and use.
IEEE 7000-2021 Standard
The IEEE SA platform is open to people and communities from around the world working at every stage of technological development. The IEEE 7000-2021 Standard provides a system engineering standard approach for integrating human and social values into traditional systems engineering and design.
NCPDP
NCPDP is an ANSI-accredited, not-for-profit standards development organization representing a broad range of stakeholders in the pharmacy services sector. It has facilitated the development of standards and guidance to support the electronic exchange of healthcare information.
Appendix III: Educational and Informational Resources
Various educational and informational resources have been provided to help stakeholders better understand health IT concepts within the ISA. Initial resources have been drafted by the 2017 Interoperability Standards Advisory Task Force, part of the Health IT Standards Committee.
ASTP welcomes additional recommendations for educational resources to be included on this page. Please provide links to resources in the comments below.
General Educational Resources
Understanding Observations and Observation Values
Understanding Emerging API-Based Standards
Enabling Document Sharing Health Information Exchange Using IHE Profiles
(IHE whitepaper)
Additional resources from the whitepaper
SDO-Specific Educational Resources
DICOM Certification (CDIP) Package
HL7 Training and Education
IHE Certified Professional Program
NCPDP Resources
SNOMED CT Resources
Understanding Emerging API-Based Standards
A new generation of API-based interoperability standards is emerging. In contrast to traditional interface specifications, these new approaches focus on reuse of standardized APIs and other “building blocks” which can often be re-combined to address new high-level use-cases without requiring a “start from scratch” for each new use-case.
API access to Health IT systems is not new, but following the
JASON report
and the
JASON Task Force recommendations to the HIT Standards and Policy Committees
, there is growing interest into a standards-based API that could become widely supported across many kinds of Health IT. One particular emerging standard,
HL7’s Fast Healthcare Interoperability Resources (FHIR)
shows promise as becoming a widely supported standard. Vendors and some large provider groups have created the
Argonaut Project
to define and publish implementation guides in an effort to standardize FHIR implementations across the Health IT community. The FHIR standard specifies many low-level data access services that can be used as “building blocks” to assemble more complex interoperability functionality.
API-based approaches to interoperability have the advantage that APIs can be assembled to rapidly create different kinds of aggregate functions. However, API-based interoperability still requires attention to important implementation details, similar to traditional interoperability specifications. In particular, given the flexibility of APIs, an API-based approach will need to address many required and optional constraints that are necessary to support a desired use-case. For example, if using FHIR as the base API specification, here are some of the constraints that should be considered:
Which specific data resources are required for the intended interoperability use-case (e.g., patient, encounter, observation)?
For each resource, what constraints are placed on the values that are allowed for the resource’s data elements (e.g., LOINC, SNOMED)?
What transport will be used to move the resources back and forth (e.g., HTTP, batch files)?
Which API operations (e.g. GET (read), PUT (write)) are required?
For each operation, what operational parameters are required (e.g., supported query parameters for GET)?
What security model is used to handle authentication, authorization, and encryption (e.g., OAuth, TLS)?
What other standards are necessary for the overall use-case to be deployed (e.g., HTML, JSON, etc.)?
A specific API-based interoperability use-case will probably need to specify, in the form of an implementation specification, most of the above categories. Some API standards, such as FHIR, contain formal mechanisms (Profiles, Conformance Statements) for specifying constraints, though even a comprehensive specification like FHIR will require that some of the constraints are documented outside of the standard’s formal tools.
To give a more concrete example, consider the “
SMART on FHIR
” interoperability specification. 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, with more expected in the future. These apps serve many different clinical needs, yet they all use the same underlying FHIR-based API functionality. However, even though SMART apps are all based on the FHIR standard, it’s not sufficient to simply say “use FHIR”. Here are some of the additional specifications that are needed:
Resources
– Which FHIR resources are available to the App developer? Many EHR vendors are choosing to expose some of the resources defined in ONC’s
2015 Edition Health IT Certification Criteria
API requirement. Typical resources available include: Patient, Encounter, Condition, Observation, etc. Not all vendors will elect to expose the exact same set of resources, and some apps may require resources that are not contained in the 2015 Certification list, such as Schedule.
Resource Profiles
– For each supported resource, the FHIR implementation will follow some Profile that specifies how the data fields in the resource will be populated. The Profile will usually define the cardinality of the data (zero, one, or many instances allowed) as well as the Value Sets supported (e.g., LOINC, SNOMED, RxNorm, etc.) Note that formal use of FHIR Profiles is not widely supported at present, so the data constraints are often documented via spreadsheet or other informal means.
Transport
– SMART Apps use HTTP as the transport since they are designed to be interactive and need real-time access to EHR data. The FHIR specification contains a clear mapping of standard data operations (read, write, update, etc.) to the standard HTTP verbs (PUT, GET, etc.)
API Operations
– The 2015 Certification specification currently requires that EHRs support “read only” operations, using the HTTP GET operation. Some vendors have begun to support selected “write” operations using POST, PUT, or UPDATE. Note that the supported write operations may apply only to certain resources. For example, an app might be able to PUT a new Observation, but not be allowed to PUT a new Encounter.
Parameters
– for each resource and operation, the interoperability specification will need to specify which data access parameters are supported. Typically, these include the types of query functions supported by the GET operation. For example, some implementation will support “GET Patient” using the patient’s medical record number, but might not support a “GET Patient” using the SSN or a hospital room number.
Security Model
– The SMART on FHIR specification makes heavy use of the OAuth 2 security standard to orchestrate the HTTP transactions. OAuth may be combined with OpenID Connect in order to cover both authentication and authorization. HTTPS (TLS) is required for on-the-wire encryption. Note that the OAuth 2 standard (which is managed by the IETF) requires its own implementation guide to constrain it for healthcare uses.
Other Standards
– SMART Apps can use HTML5 to control the visual expression of the app, so in some sense, HTML5 is part of the overall specification for SMART on FHIR.
Trust Relationship
– For interoperability using FHIR to work, a trust relationship must be established between entities (ie an EHR/clinical system and an app). This is currently being accomplished by establishing siloed ecosystems. Without an established trust relationship, access to information is not possible regardless of the standards used.
This example illustrates that even though API-based interoperability enables powerful new approaches, there is still a need to carefully specify and constrain each layer of the overall interface orchestration in order to achieve the desired degree of standardization and interoperability.
Text developed by the Health IT Standards Committee as part of the 2017 ISA Task Force
NCPDP Connectivity Operating Rules Implementation Guide an API Application Programming
NCPDP Connectivity Operating Rules Implementation Guide - “An API – application programming interface – at its most basic level, allows your product or service to talk to other products or services. In this way, an API allows you to open up data and functionality to other developers and to other businesses. It is increasingly the way in which agencies and companies exchange data and services, both internally and externally”. There are common technical and practical choices companies need to be aware of when using APIs. This document lays out some of the requirements to ensure the NCPDP Standards employ the API standards appropriately.
For details, refer to the Connectivity Operating Rules Implementation Guide at NCPDP Standards (https://standards.ncpdp.org/Access-to-Standards.aspx).
Understanding Observations and Observation Values
Many kinds of health data are represented as
observations
. A laboratory test result, a vital sign measurement, a pain scale rating, or recording the kind of exercise activity that a patient engaged in (e.g. running, walking, swimming, etc.) can all be considered observations. In this context, we use observation as a generic term. Depending on the domain of interest, you might call these tests, variables, or data elements, etc.
Within and among health IT systems, observations are communicated with a structure that has two key structural elements. The first element identifies
what the observation is
, e.g. diastolic blood pressure, hematocrit, tobacco smoking status, or pain intensity on a 0 to 10 scale. The second element carries
the result value of the observation
, e.g. 80 (mmHg), 40 (%), “current every day smoker”, or 5. When used together, these two elements carry the instance of specific test result for a given patient.
Another way to think about this model is as questions and answers. This first element of the structure (the
observation)
is like the question, and the second element (the
observation value
) is like the answer. For example, the question might be:
What is this patient’s blood type?
The answer then, might be
O Positive
When identifying Vocabulary/Code Sets/Terminology Standards for health data represented as
observations
, the ISA lists separately the different standards for the
observation
and the
observation value
because they fulfill different roles. Quantitative results don’t need a standard code for the value: the observation value is simply a number (with its associated units of measure). On the other hand, nominal or ordinal results benefit from having a standard code.
A common pairing for many domains is to use LOINC as the standard code for the
observation
(that’s what the O in LOINC stands for), and SNOMED CT as the standard code for the
observation value
when needed. This approach is
endorsed by the developers of both of these terminologies
and fits their design purpose. Yet, the choice of which vocabulary standard to use for these roles varies by domain. For example, when reporting the results of a validated patient assessment (e.g. the Morse Fall Scale), you may choose to use the LOINC Answer Codes as the
observation value
because they represent the exact text as it appears in that instrument. In contrast, a different approach may be needed when reporting genetic variant results. For example, when reporting a simple genetic variant you could pair the LOINC
observation
code [
81252-9
] for “Discrete genetic variant” with an
observation value
using an identifier from
NCBI's ClinVar
. Reporting a complex genetic variant may instead pair the LOINC
observation
code [
81262-8
] for “Complex variant HGVS name” with an
observation value
expressed in the
HGVS nomenclature
There are some situations where the structure of health IT system removes the need for the two-part observation structure. If an EHR has a “Problem” table where the records are instances or assertions of patient problems (conditions), then there is no need for an observation code. On the other hand, if the structure of the health IT system or the exchange format lacks such a structural element, the patient’s problem list could be represented using the observation and observation value pattern.
Text developed by the Health IT Standards Committee as part of the 2017 ISA Task Force
Appendix IV: State and Local Public Health Readiness for Interoperability
State and Local Public Health Agencies (PHAs) support interoperability efforts and data exchange with electronic health records, many of which have been utilized by the
Centers for Medicare & Medicaid Services (CMS) Promoting Interoperability Programs
. This appendix points to PHA websites at the jurisdictional level where interested parties can obtain information such as the local implementation guides, which programs and implementation guides are supported, contact information etc.
While every attempt is made to keep this appendix up to date, at any given time there may be errors or omissions. This appendix is for informational purposes only. Please contact the PHA to determine their capacity to receive information.
Alabama Department of Public Health
Alaska Department of Health
Arizona Department of Health Services
Arkansas Department of Health
California Department of Public Health
Los Angeles County
Colorado Promoting Interoperability | Department of Public Health & Environment (colorado.gov)
Connecticut Department of Public Health
Delaware Health and Social Services
DC Department of Health
Florida Health Information Exchange (HIE) Services
Georgia Department of Public Health
Hawaii Department of Health
Idaho Department of Health and Welfare
Illinois Department of Public Health
Indiana Health: Meaningful Use
Iowa Department of Public Health
Kansas Department of Health and Environment
Kentucky Promoting Interoperability - Kentucky Health Information Exchange
Louisiana Department of Health, Promoting Interoperability and Public Health Reporting in Louisiana
Maine Department of Health and Human Services
Maryland Meaningful Use Resource Center
Massachusetts Meaningful Use and Public Health Objectives | Mass.gov
Michigan Department of Community Health
Minnesota Department of Health
Mississippi State Department of Health
Missouri Department of Health and Senior Services
Montana Meaningful Use (mt.gov)
Nebraska Department of Health and Human Services
Nevada Department of Health and Human Services
New Hampshire Department of Health and Human Services
New Jersey Department of Health
New Mexico Department of Health
New York State Meaningful Use (MU) Public Health Reporting (ny.gov)
New York City Department of Health and Mental Hygiene
North Carolina Department of Health and Human Services
North Dakota Electronic Reporting | Department of Health (nd.gov)
Ohio Department of Health
Oklahoma State Department of Health
Oregon Health Authority
Pennsylvania Meaningful Use (pa.gov)
Rhode Island Department of Health
South Carolina Department of Public Health
South Dakota
Tennessee Department of Health
Texas
Texas (Houston)
Utah Department of Health and Human Services
Vermont Department of Health
Virginia
Washington State Department of Health
West Virginia Office of Epidemiology & Prevention Services
Wisconsin Department of Health Services
Wyoming Department of Health - Promoting Interoperability
This page contains numerous links to other state and/or federal agencies and to private organizations. You are subject to these sites’ privacy policies when you access them. HHS is not responsible for Section 508 compliance (accessibility) on other federal or private sites. HHS is not responsible for the contents of any "off-site" web page referenced from this page.
Appendix V: Federal FHIR Action Plan (FFAP)
The Federal Fast Healthcare Interoperability Resources® (FHIR®) Action Plan (“action plan”) is intended to inform federal investment in and adoption of the
Health Level 7 (HL7®) International®
FHIR
standard. In 2019, the Assistant Secretary for Technology Policy/Office of the National Coordinator for Health IT (formerly ONC and hereafter ASTP) convened a FHIR Work Group under the Federal Health IT Coordinating Council (FHITCC); this work group gathered knowledge and insights to support implementation and decision-making of FHIR. The action plan builds upon considerations developed by the work group and provides strategic direction for using a mature FHIR standard across federal agencies to enhance shared decision-making, improve care coordination, and deepen patient engagement.
The following recent publications by ASTP and the Centers for Medicare & Medicaid Services (CMS) further outline the path for advancing FHIR capabilities:
CMS/ASTP Request for Information: Health Technology Ecosystem
ASTP Health, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing Final Rule (
HTI-1 Final Rule
); and
CMS Interoperability and Prior Authorization Final Rule (
CMS-0057-F
).
The action plan was developed with input from federal agencies, the standards development community, and subject matter experts (SMEs). It will be updated periodically based on future investments and interests of the federal agencies
GOALS
The action plan’s primary goal is to align federal agencies’ adoption and use of FHIR around a set of essential components and capabilities that agencies have implemented or are planning to implement in the next two years. Many of these components are mature and are already used in production. ASTP designed the action plan to provide clear, consistent, and predictable information regarding the standards and implementation specifications prioritized by federal agencies.
In publishing the action plan, ASTP seeks to identify federal use cases and areas needing additional development and investment.
Federal agencies and implementation partners are encouraged to use the action plan to help:
Identify and address common needs across agencies;
Coordinate requests and focus areas for the FHIR standards community and implementation partners; and
Optimize investments by reusing and advancing widely adopted capabilities, avoiding duplication in federal use cases.
WHO SHOULD READ
The action plan is intended primarily for federal partner agencies and their industry partners. Interested parties who administer government programs that involve clinical health information technology interoperability components should review this action plan to help inform any technical decisions.
We hope the action plan can also serve as a valuable resource for organizations and users outside the federal sphere. For example, Standards Development Organizations (SDOs) can use the action plan to identify areas of federal interest that require development of new or improved specifications. This insight helps them align their efforts with federal priorities and address emerging interoperability needs. Health IT developers can gain greater clarity and certainty regarding the FHIR components prioritized by federal agencies to better plan and build technical solutions that align with federal agency needs. A wide range of users – including providers, payers, researchers, public health entities, laboratories, State, Tribal, Local, and Territorial (STLT) health departments, clearinghouses, and integrators – can benefit from the transparency provided by the action plan. By understanding the baseline FHIR components that federal partners are investing in, they can make more informed decisions about capabilities that are currently in the works.
CONTENTS
The core of the action plan lies in the component tables found within the FHIR Ecosystem section, in which the “unit of measure” is largely FHIR Implementation Guides (IGs). These tables organize FHIR specifications into six distinct categories:
Core Components
These foundational FHIR specifications have broad applicability across health care services. They support fundamental operations and are reusable building blocks for multiple use cases.
Network Components
Network specifications focus on FHIR capabilities for accessing and exchanging data securely between health information networks, in service of nationwide data sharing.
Payment and Health Quality Components
FHIR specifications in this category aim to alleviate reporting burden for clinicians and caregivers.
Care Delivery and Engagement Components
These FHIR specifications are designed to enhance patients’ access to their health data and to the health care system. They also reduce provider burden and assist providers in areas such as decision support.
Public Health and Emergency Response Components
FHIR specifications in this category aim to modernize public health infrastructure and data needs.
Research Components
Research specifications drive toward a fully digital health system that uses FHIR to support access to data for research activities and innovation.
The individual specifications described in the component tables represent those that ASTP has identified as best suited to meet current agency needs and that they can use with confidence. These selections are based on several factors, including agency interest, implementation, maturity level, and reusability.
RELATIONSHIP TO INTEROPERABILITY STANDARDS ADVISORY (ISA)
Both the action plan and the
Interoperability Standards Advisory (ISA)
are part of ASTP’s Interoperability Standards Platform (ISP) and share the common goal of advancing health information interoperability using standards and implementation specifications developed by SDOs. Specifically, the information contained in the action plan tables have been collected from and integrated into the ISA, in consultation with federal agency partners who track the IGs.
With the focus on FHIR and federal agency needs, our aim is to provide the public with a curated list of FHIR specifications that supports U.S. federal agency goals. Therefore, this list can be found in two places in the ISA - first, altogether with background information in "Appendix V: Federal FHIR Action Plan (FFAP)”. Individual FHIR specifications can also be found in Interoperability Need sections, marked with a “FFAP” icon.
The action plan does not include the many non-FHIR standards used in healthcare, nor does it specifically call out terminology standards that are referenced in the FHIR specifications. We acknowledge that these standards are critical for ensuring consistent and accurate communication of clinical data and anticipate users continue to leverage the ISA to cover the breadth of interoperability needs – over 75 different standards areas in the latest edition – that are supported by various standards, not limited to FHIR.
UPDATES
ASTP will regularly update the action plan through established federal activities and coordination efforts. These updates will ensure the action plan remains aligned with advancements in the FHIR standard and changing federal agency priorities. Mechanisms for update include ongoing coordination with agencies, evolution of FHIR, and public feedback on the ISA. Regular updates will indicate the progress of FHIR specification maturity, adoption trends across federal agencies and programs, and federal activities supporting interoperability and data exchange. This will ensure the action plan remains responsive to community input and reflects the latest developments in interoperability standards.
HOW TO COMMENT ON THE FEDERAL FHIR® ACTION PLAN
The action plan is integrated into the ISA and will follow the ISA comment and update process. Comments on the action plan are accepted year-round.
An Interoperability Standards Platform (ISP) site account is required to comment on the action plan.
If you already have an account, click
here
or click the “LOG IN” button at the top right of the ISP and enter your log in information.
To create an account, click
here
or click the “LOG IN” button, then “Create new account” tab above the log in window. Account approval is required and is generally completed within 24 hours.
ASTP will review comments with SMEs and consider suggested revisions.
This site contains numerous links to other federal agencies and to private organizations. You are subject to these sites’ privacy policies when you access them. HHS is not responsible for Section 508 compliance (accessibility) on other federal or private sites. HHS is not responsible for the contents of any “off-site” web page referenced from this site.
HL7® and FHIR® are the registered trademarks of Health Level Seven International, and use of these trademarks does not constitute endorsement by HL7®.
Introduction
Health Level 7 (HL7) Fast Healthcare Interoperability Resources (FHIR) is an open standard widely used to exchange health information, using modern internet technology approaches such as RESTful APIs and structured data formats. Through significant efforts by technology developers and the HL7 standards development community, FHIR has reached a level of maturity that makes it ready for widespread adoption. It has been incorporated into the ASTP Health IT Certification Program to support key provisions of the
21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program Final Rule (Cures Act Final Rule)
. Enacted in 2016 with strong bipartisan support, this legislation has driven the adoption of FHIR-based application programming interfaces (APIs), which now serve as a foundational standard for accessing and exchanging electronic health information across the nation.
FHIR enhances efficiency and interoperability in healthcare by offering a standardized framework for data exchange, which simplifies integration with modern technologies and enables the use of advanced computing capabilities, such as artificial intelligence. By utilizing FHIR-based application programming interfaces (APIs), organizations can reduce technical complexity and ease implementation burden. The FHIR standard offers more granular data specifications leading to a shared foundation for data exchange. Its versatility supports multiple workflows through a unified approach to interoperability. The interoperable exchange of health data facilitated by FHIR minimizes operational challenges and fosters innovation, ultimately supporting more effective healthcare delivery, empowering patients with access to their information, and improving overall patient outcomes.
Federal agencies are uniquely positioned to capitalize on the successes of FHIR and harness its capabilities to realize the full potential of a truly digital health ecosystem. By embracing FHIR and fostering collaboration within the health IT community, agencies can strengthen health data interoperability, enable the development of innovative applications, and drive improvements in health outcomes nationwide.
Aligned with the agency’s mission to develop and oversee implementation of HHS’ strategies and policies for data, technology, interoperability, and artificial intelligence (AI), the Federal FHIR Action Plan informs federal alignment, development, and investment in FHIR specifications. These specifications are essential for clinical care and extend to other healthcare use cases, including public health, research, and policy initiatives.
FEDERAL AGENCY INTERESTS AND HEALTH IT ALIGNMENT ACTIVITIES
Federal agencies, including ASTP, CMS, the Centers for Disease Control and Prevention (CDC), the Health Resources and Services Administration (HRSA), and the Department of Veterans Affairs (VA) have played instrumental roles in advancing FHIR as a foundational standard to reduce implementation costs and improve health outcomes. The graphic below depicts federal agency initiatives, regulatory actions, and FHIR development milestones since passage of the Cures Act Final Rule that have led to progress and opportunities available today. These actions culminated in the establishment of FHIR Release 4 (R4) as the current, mature foundational version widely adopted by Certified Health IT developers in the United States. Released in 2018, FHIR R4 has become a stable and reliable standard for federal programs. Until the release of FHIR Release 6 (R6), all new standards development activities and implementations should continue to be based on FHIR R4, at which point the action plan will undergo re-evaluation.
The action plan complements ongoing interagency efforts within the Department of Health and Human Services (HHS) to harmonize data-related initiatives:
New, mission-critical data elements are structured through ASTP’s United States Core Data for Interoperability (
USCDI
) initiative and its extension program, United States Core Data for Interoperability Plus (
USCDI+
). USCDI is a standardized set of health data classes and constituent data elements for nationwide, interoperable health information exchange. Collaborating with partners such as National Institutes of Health (NIH), the National Cancer Institute (NCI), CMS, CDC, HRSA, the Food and Drug Administration (FDA), VA, and other federal agencies, USCDI and USCDI+ promote greater consistency and semantic interoperability for priority use cases identified by federal agencies, addressing multiple needs across federal programs.
To further promote and commit to nationwide interoperability, HHS launched the
HHS Health IT Alignment Policy
in 2023. This policy fosters greater alignment of health IT-related activities and encourages the use of health IT that comply with standards and implementation specifications adopted under section 3004 of the Public Health Service Act.
Coordinated federal involvement in FHIR is vital to ensure the development and implementation of FHIR-based capabilities that address the shared priorities and needs of federal agencies. The action plan marks a major advancement in this effort, using existing federal policies and investments to further promote the adoption and advancement of FHIR and its related technical specifications.
FHIR Ecosystem
VISION
The capabilities specified in the action plan serve as building blocks for creating a more interoperable and seamless healthcare ecosystem, enabling better interaction and integration for all. While some federal agencies have made more progress in implementing FHIR capabilities than others, the adoption of common components will establish a strong foundation for accelerating the use of next-generation HL7 FHIR specifications.
The continued development and implementation of the
Trusted Exchange Framework and Common Agreemen™ (TEFCA™)
based on FHIR specifications will further enhance nationwide exchange of healthcare data for clinical, public health, and research purposes.
IGs developed by HL7’s
Da Vinci Project Accelerator
will play a critical role in reducing prior authorization burden for both payers and providers, improving payers’ ability to share data with patients, reducing reporting burden, and providing greater continuity for patients transitioning between insurance plans.
Emerging FHIR specifications are set to enable patients to access their health information while travelling internationally. Other specifications will focus on improving nationwide public health reporting, providing real-time insights into disease trends to support timely and informed decision-making. New standards will work to standardize cancer data collection and enhance the quality of data provided to disease registries. These advancements will also establish a foundation for expanding the use of FHIR in generating real-world evidence for clinical trials and advancing applications in genomics, further driving innovation in healthcare and research.
As emerging FHIR specifications achieve widespread adoption and become the de facto standard, they will pave the way for transformative innovations in healthcare. These advancements have the potential to significantly improve clinical decision-making, enhance patient outcomes, streamline administrative processes, and bolster public health surveillance. Continuous improvements to FHIR will facilitate this transition, leading to faster data exchange, improved care coordination, and more personalized experiences across diverse systems and applications. The coordinated development, adoption, implementation, and use of FHIR standards will support breaking down the data silos that currently exist in the health IT ecosystem. These data silos hinder patients, providers, payers, public health experts, and researchers from accessing a comprehensive dataset. By addressing these barriers, FHIR will help create a more connected and interoperable healthcare environment.
ABOUT THE COMPONENTS
The FHIR specifications listed in the component tables will form the basis for the next generation of healthcare interoperability. Components have been referenced in federal regulations or initiatives, are in active development in FHIR Accelerators, or are highly anticipated by industry partners. The 31 components are organized into six distinct sections:
Core Components
These foundational FHIR specifications have broad applicability across health care services. They support fundamental operations and are reusable building blocks for multiple use cases.
Network Components
Network specifications focus on FHIR capabilities for accessing and exchanging data securely between health information networks, in service of nationwide data sharing.
Payment and Health Quality Components
FHIR specifications in this category aim to alleviate reporting burden for clinicians and caregivers.
Care Delivery and Engagement Components
These FHIR specifications are designed to enhance patients’ access to their health data and to the health care system. They also reduce provider burden and assist providers in areas such as decision support.
Public Health and Emergency Response Components
FHIR specifications in this category aim to modernize public health infrastructure and data needs.
Research Components
Research specifications drive toward a fully digital health system that uses FHIR to support access to data for research activities and innovation.
FHIR specifications were included in the action plan based on four criteria – agency interest, implementation, maturity, and reusability. Inclusion determinations were made based on discussions with ASTP and federal agency partner SMEs, public feedback submitted during the open feedback period, and review of public information. The questions below are representative of the type of information used to determine specification inclusion.
Agency Interest.
Is the specification referenced in agency publications, initiatives, or regulations? To what extent have agencies invested funds or staff resources on the specification?
Implementation.
How actively is the specification being used or required by a federal agency?
Maturity.
What is the maturity level of the specification? Has there been recent development activity to advance or refine the specification?
Reusability.
How widely is the specification implemented in across different use cases? Is it referenced or used by other specifications?
Agencies should review the capabilities, requirements, and dependencies of these components before investing in new efforts that may duplicate their functions. An appendix table lists all the specifications referenced in the component tables with their “home” areas and the other areas in which they could have been included.
Each specification entry includes its name, assessments of its current maturity level, and development and implementation information. Maturity assessments align with the ASTP Interoperability Standards Advisory (ISA) where available; Standard Process Maturity refers to its development stage (from most to least: Final, Balloted, In Development), while Implementation Maturity refers to its implementation state (Production, Pilot).
Federal agencies are encouraged to:
Use Balloted or Final components that are in Production;
Advance specifications that are In Development or in a Pilot phase; and
Identify “new” areas for future federal investment.
This approach promotes consistency and helps alleviate development and implementation burden, fostering smooth, efficient collaboration in the pursuit of shared goals.
CORE COMPONENTS
The HL7 FHIR specifications categorized as Core Components serve as the foundation for developing and implementing nearly all FHIR capabilities. These Core Components are designed to be use-case agnostic, providing the flexibility to support a wide range of applications across various healthcare scenarios. The modular nature of the FHIR standard allows elements, such as IGs and Profiles, to be combined in different ways to address diverse needs. Many federal agency initiatives rely on these Core Components, which have undergone extensive testing and are widely utilized in production systems, ensuring their reliability and effectiveness in real-world applications.
ASTP collaborates closely with HL7 to ensure coordination, awareness, and insight into significant activities and advancements in FHIR standards. This partnership covers the full range of use cases that FHIR is designed to address, with ASTP placing particular emphasis on the Core Components that are applicable across the broadest range of subject matter areas. Developers and users of FHIR are encouraged to consult ASTP before committing resources to Core Component specifications to ensure alignment with federal priorities and guidance.
Many of these specifications interface with other essential standards and policies including
USCDI
USCDI+
, the
ISA
, and the
Health IT Alignment Policy
. In addition, several of them are also used in federal programs or initiatives including the
ASTP Certification Program
ASTP’s Inferno tool
, and
CMS’ Electronic Clinical Quality Measures (eCQMs)
Interested parties should use the latest version of the listed specification if a version is not referenced in the specification description.
Standard / Specification:
HL7® FHIR® Release 4.0.1 (R4)
Standard Process Maturity: Balloted
Implementation Maturity: Production
The baseline FHIR standard version provides foundational FHIR Resources that are stable, mature, and backwards compatible, referred to as “Normative”. These resources form the base standard and are constrained into FHIR Profiles by implementation specifications, ensuring consistent implementation necessary for interoperability.
While a newer version, FHIR Release 5 (FHIR R5), has been balloted, all current implementation specifications adopted by federal regulations are based on FHIR R4.
The standards community is actively working towards releasing FHIR Release 6 (FHIR R6) in 2026. FHIR R6 is expected to include more FHIR Resources designated as Normative.
Unless there is a compelling need for a use case that requires functionality exclusive to FHIR R5, it is recommended that any new standards development activities and implementations continue to be based on FHIR Release 4.0.1 to ensure alignment with current federal regulations.
Referenced in Federal Rulemaking:
ASTP Cures Act Final Rule
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
Standard / Specification:
HL7® FHIR® US Core Implementation Guide (US Core IG)
Standard Process Maturity: Multiple balloted versions available
Implementation Maturity: Production
This implementation specification defines minimum constraints on FHIR Resources aligning with data elements specified in USCDI. Built on FHIR R4, it is the foundation of all US Realm implementation specifications. A foundational FHIR specification, US Core uses other specifications, such as the FHIR Structured Data Capture IG and the FHIR SMART App Launch IG, to optimize existing workflows.
There are multiple versions of the US Core IG, with each version corresponding to a specific annual release of USCDI. Historically, ASTP adopted different versions of the US Core IG based on publication timing. Currently, ASTP has identified US Core Version 6.1.0 as ready for adoption in Certified Health IT in the ASTP HTI-1 Final Rule. Certified Health IT developers typically adopt the version of the US Core IG that is specified in regulation or the version approved by the National Coordinator through ASTP’s
Standards Version Advancement Process (SVAP)
For use cases that rely on data elements defined in USCDI, the US Core IG often provides the simplest and most cost-effective solution for data exchange. Additionally, the US Core IG benefits from extensive support and expertise within the standards community and among health IT developers, ensuring successful implementation and accommodating modifications when necessary.
Referenced in Federal Rulemaking:
ASTP HTI-1 Final Rule
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
Standard / Specification:
HL7® FHIR® SMART App Launch Implementation Guide (SMART App Launch IG)
Standard Process Maturity: Multiple balloted versions available
Implementation Maturity: Production
This implementation specification specifies how applications connect to FHIR APIs by requesting authorization from OAuth 2.0-compliant authorization servers. It outlines the process by which an application requests authorization to access a FHIR resource and subsequently uses that authorization to retrieve the resource.
There are multiple versions of the SMART App Launch IG, all of which are compatible with FHIR Release 4 (R4). Historically, ASTP has adopted different versions of the SMART App Launch IG based on publication timing. Currently, ASTP has identified Version 2.0.0 as ready for adoption in Certified Health IT under the ASTP HTI-1 Final Rule. Certified Health IT developers typically adopt the version specified in program requirements or the version approved by the National Coordinator through ASTP’s Standards Version Advancement Process (SVAP).
The SMART App Launch IG facilitates a persistent application authorization process and adds a security layer to FHIR API deployments, addressing both FHIR server and FHIR application perspectives. This makes the SMART App Launch IG a foundational specification for any FHIR API implementation requiring secure access to FHIR Resources.
Referenced in Federal Rulemaking:
ASTP HTI-1 Final Rule
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
Standard / Specification:
HL7® FHIR® Bulk Data Access Implementation Guide (Bulk Data Access IG)
Standard Process Maturity: Multiple balloted versions available
Implementation Maturity: Production
This implementation specification defines the process for accessing data for a specified group or set of patients from a FHIR server to a pre-authorized client application.
There are multiple versions of the Bulk Data Access IG, all of which are compatible with FHIR Release 4 (R4). Historically, ASTP has adopted different versions of the IG based on publication timing, and it has identified Version 1.0.0 as ready for adoption in Certified Health IT under the ASTP Cures Act Final Rule. While the Bulk Data Access IG serves as the primary specification for bulk data access in HL7 FHIR, other HL7 FHIR IGs may extend its functionality. Certified Health IT developers typically adopt the version specified in program requirements or the version approved by the National Coordinator through ASTP’s Standards Version Advancement Process (SVAP).
The Bulk Data Access IG ensures consistent health IT implementation of API-enabled access services for multiple patients. However, health IT developers have encountered performance and scalability challenges, which may be addressed in the future through use-case-specific development of FHIR Bulk Data Access IG implementations. Consequently, the performance and scalability of the Bulk Data Access IG depend on the specific use case. Developers are advised to consult the latest information from the health IT developer and standards community before adopting the IG to ensure alignment with current best practices and advancements.
Referenced in Federal Rulemaking:
ASTP Cures Act Final Rule
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
Standard / Specification:
HL7® FHIR® CDS Hooks Implementation Guide (CDS Hooks IG)
Standard Process Maturity: Balloted
Implementation Maturity: Production
This implementation specification describes a “hook”-based pattern for invoking or triggering an external decision support from within a health IT solution, including Certified Health IT. This pattern enables clinicians to integrate results from a clinical decision support (CDS) tool directly into their workflow or to launch an interactive application for clinical decision support.
The CDS Hooks IG provides a more advanced interaction than simply invoking a third-party application, making it an advanced use of FHIR APIs. Implementing CDS Hooks requires clients, typically Certified Health IT systems, to support "hooks" at specific points within the electronic health record (EHR) workflow to facilitate seamless integration.
Organizations interested in implementing CDS Hooks should evaluate the CDS Hooks IG to enable native or third-party applications, provided their Certified Health IT system supports CDS Hooks as a client and includes the necessary "hooks" within the workflow.
Standard / Specification:
HL7® FHIR® Subscriptions R5 Backport Implementation Guide (Subscriptions IG)
Standard Process Maturity: Balloted
Implementation Maturity: Pilot
This implementation specification allows clients to request notifications from FHIR servers when events occur. Once a subscription is established, a FHIR server can proactively notify the client when new information is added or existing information is updated within its system.
ASTP regulation recognizes Subscriptions IG Version 1.1.0 as compatible with FHIR Release 4 (R4) and suitable for addressing health IT needs within the current landscape. The R4 Subscriptions IG includes a subset of the capabilities available in the redesigned R5 version. Implementers interested in these capabilities should consider adopting the R4 specification.
The R5 Subscriptions framework underwent a significant redesign, introducing topic-based subscriptions, enhanced clarity, greater flexibility, and additional notification types. Looking ahead, ASTP anticipates that the Subscriptions framework will become even more advanced with the release of FHIR Release 6 (R6).
Standard / Specification:
HL7® FHIR® SMART Health Cards and Links Implementation Guide
Standard Process Maturity: Balloted
Implementation Maturity: Pilot
This implementation specification will provide a secure, standards-based method for patients to share their health data with entities of their choice, simplifying data exchange scenarios and reducing complexity and burden. SMART Health Links is a FHIR-based standard designed to enhance the portability and shareability of health information. It allows individuals to store a limited amount of information in a secure QR code while also supporting larger and more dynamic health records.
Implementers interested in enabling patients to share electronic health information should consider adopting the SMART Health Cards and Links IG. This specification supports various modalities for accessing electronic health information (EHI), including limited-time access, long-term access, and password/PIN-protected access, providing flexibility and security in data sharing.
NETWORK COMPONENTS
Network specifications are FHIR capabilities for exchanging and discovering data across extensive, multi-nodal networks. Currently, these specifications are most prominently seen in the evolution of the Trusted Exchange Framework and Common AgreementTM (TEFCATM) infrastructure to a FHIR-based system, though they are expected to play a significant role in future advancements in network applications. Given ASTP's involvement in TEFCA™, Network Component developers are encouraged to coordinate and consult with ASTP to ensure alignment in standards development and adoption efforts.
Interested parties should use the latest version of the listed specification if a specific version is not referenced in the specification description.
Standard / Specification:
HL7® FHIR® FAST UDAP Security for Scalable Registration, Authentication, and Authorization Implementation Guide
Standard Process Maturity: Balloted
Implementation Maturity: Production
This implementation specification extends OAuth 2.0 to standardize and automate the application registration process using digital certificates, while securely authenticating participants within health information networks. This specification is compatible with the SMART App Launch IG and aligns with the security requirements of the Bulk Data IG.
ASTP has identified Version 1.0.0 of the FAST UDAP Security IG as ready for adoption in Certified Health IT. While its use is currently optional within the Trusted Exchange Framework and Common Agreement™ (TEFCA™), it is expected to become a requirement in the future.
The FAST UDAP Security IG provides a standardized method for dynamically registering applications through secure FHIR APIs. Implementers should consider adopting this specification for use cases requiring scalable trust among participants who agree to follow common policies, eliminating the need for individual agreements between organizations to establish trust.
ASTP anticipates that this specification will continue to evolve and mature based on implementation experience within TEFCA™.
Standard / Specification:
HL7® FHIR® FAST National Directory of Health Implementation Guide (NDH IG)
Standard Process Maturity: Balloted
Implementation Maturity: Pilot
This implementation specification establishes a standardized national directory infrastructure in the United States to facilitate the lookup, discovery, and validation of data exchange partners. It aims to streamline the process by enabling API-based sharing of information about providers, organizations, services, and existing healthcare directories.
The specification addresses key challenges related to the availability and discovery of FHIR endpoints, including endpoint discovery, referrals and transitions of care, health plan enrollment, provider and service selection, and provider credentialing. By defining and resolving these issues, the NDH IG supports a more efficient and reliable health IT data exchange ecosystem.
Implementers are encouraged to consider adopting the NDH IG to build a scalable infrastructure for identifying health IT data exchange partners.
This specification was developed by combining insights from three predecessor specifications: the
FHIR National Healthcare Directory Exchange IG
, the
FHIR National Healthcare Directory Query IG
, and the
FHIR National Healthcare Directory Attestation and Verification IG
PAYMENT AND HEALTH QUALITY COMPONENTS
FHIR-based Payment and Health Quality specifications are designed to streamline processes and reduce the reporting burden for clinicians, caregivers, patients, and payers. These specifications focus on enabling efficient claims data exchange and improving interoperability in payment and quality reporting workflows. Many of these specifications have been developed through the
Da Vinci Project
, an HL7 FHIR Accelerator that focuses on creating FHIR-based solutions for value-based care and payment models. The Da Vinci Project's work revolves around capabilities that facilitate claims data exchange, making it easier for healthcare stakeholders to share and process payment and quality-related information. Given the emphasis on claims and payment data, agencies working in this space are encouraged to involve the Centers for Medicare & Medicaid Services (CMS) as a key partner. CMS's expertise and role in healthcare payment systems can help ensure that these specifications align with regulatory requirements.
Several of these specifications are used in federal programs or initiatives including the
CMS electronic Clinical Quality Improvement (eCQI) electronic Clinical Quality Measures (eCQMs) Program
and ASTP’s Inferno tool.
Interested parties should use the latest version of the listed specification if a specific version is not referenced in the specification description.
Standard / Specification:
HL7® FHIR® Da Vinci Payer Data Exchange Implementation Guide (PDex IG)
Standard Process Maturity: Balloted
Implementation Maturity: Production
This implementation specification provides a framework for payers and health plans to create a member’s health history using clinical resources based on the US Core IG. This health history can be shared with providers in a format that is understandable and can be integrated into their Certified Health IT systems. The PDex IG includes components for both payers and providers, enabling providers to access timely and comprehensive clinical information. This supports more informed treatment decisions, better adherence to care plans, and improved quality of care for patients.
ASTP and the Centers for Medicare & Medicaid Services (CMS) have identified PDex IG version 2.0 as ready for adoption in Certified Health IT. Developed by the Da Vinci Project Accelerator, the PDex IG is available for implementation without licensing requirements.
Payers and providers should consider adopting the PDex IG for use cases that involve exchanging clinical information between payers and providers, as well as enabling patients to access their clinical information from their payers.
Referenced in Federal Rulemaking:
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
Standard / Specification:
HL7® FHIR® Consumer Directed Payer Data Exchange Implementation Guide (CARIN IG for Blue Button®)
Standard Process Maturity: Multiple balloted versions available
Implementation Maturity: Production
This implementation specification provides a framework for payers to enable patient access to their claims information via a standardized FHIR API. It defines the Common Payer Consumer Data Set (CPCDS), which is a set of FHIR resources that payers can make available to patients. In addition to patient access, the profiles in this IG are expected to be reusable for other use cases, such as Provider Access and Payer-to-Payer APIs.
CMS has identified CARIN IG for Blue Button Version 2.0.0 as ready for adoption in Certified Health IT. Developed by the CARIN Alliance, the IG is available for implementation without licensing requirements, making it accessible to payers and health IT developers.
Implementers are encouraged to adopt the CARIN IG for Blue Button for use cases that require payers to provide patients with access to their claims information.
Referenced in Federal Rulemaking:
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
Standard / Specification:
HL7® FHIR® Da Vinci Coverage Requirements Discovery Implementation Guide (CRD IG)
Standard Process Maturity: Balloted
Implementation Maturity: Production
This implementation specification provides a framework for payers to share information about coverage requirements with providers, helping facilitate treatment decisions based on a patient’s insurance coverage. This specification is critical for standardizing API-based electronic prior authorization workflows, which aim to reduce delays in patient treatment and alleviate the administrative burden on providers.
CMS has identified CRD IG Version 2.0.1 as ready for adoption in Certified Health IT. Developed by the Da Vinci Project Accelerator, the CRD IG is available for implementation without licensing requirements, making it accessible to payers and providers.
Payers and providers should consider the CRD IG to streamline the prior authorization process. By automating the exchange of coverage requirements and documentation, this specification reduces the administrative workload associated with assembling and reviewing prior authorization materials.
Referenced in Federal Rulemaking:
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
Standard / Specification:
HL7® FHIR® Da Vinci Documentation Templates and Rules Implementation Guide (DTR IG)
Standard Process Maturity: Balloted
Implementation Maturity: Production
This implementation specification provides a framework for payers to define documentation requirements and provider-specific rules, while enabling providers to automatically submit the necessary documentation via FHIR APIs. This specification is essential for standardizing API-based electronic prior authorization workflows, which aim to reduce delays in patient treatment and alleviate the administrative burden on providers.
CMS has identified DTR IG Version 2.0.0 as ready for adoption in Certified Health IT. Developed by the HL7 Da Vinci Project, the DTR IG is available for implementation without licensing requirements, making it accessible to payers and providers.
Payers and providers should consider the DTR IG to streamline the prior authorization process. By automating the submission of required documentation, this specification reduces the administrative workload associated with prior authorization.
Referenced in Federal Rulemaking:
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
Standard / Specification:
HL7® FHIR® Da Vinci Prior Authorization Support Implementation Guide (PAS IG)
Standard Process Maturity: Balloted
Implementation Maturity: Production
This implementation specification defines a framework for payer and provider health IT systems to support the submission, receipt, and response to electronic prior authorization requests. This specification is critical for standardizing API-based electronic prior authorization workflows, helping to reduce patient treatment delays and alleviate the administrative burden on providers. Together with the Coverage Requirements Discovery (CRD) IG and Documentation Templates and Rules (DTR) IG, the PAS IG forms a comprehensive solution for streamlining prior authorization processes.
CMS has identified PAS IG Version 2.0.1 as ready for adoption in Certified Health IT. Developed by the Da Vinci Project Accelerator, the PAS IG is available for implementation without licensing requirements, making it accessible to payers and providers.
Referenced in Federal Rulemaking:
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
Standard / Specification:
HL7® FHIR® Da Vinci Payer Data Exchange US Drug Formulary Implementation Guide (PDex Drug Formulary IG)
Standard Process Maturity: Balloted
Implementation Maturity: Production
This implementation specification provides a framework for payer health IT systems to share drug formulary information with patients via FHIR APIs. The specification supports two types of drug formulary data exchange. Public-facing general plan formulary data, accessible to all users, does not include protected health information (PHI) or personally identifiable information (PII). Access-controlled, personalized formulary data is integrated with PHI or PII and provides specific patients with personalized information based on their medications.
By enabling patients to access a payer’s drug formulary information through FHIR APIs, this specification helps patients find cost-saving alternatives, compare plans more easily, and understand differences between drug tiers and pharmacy benefit types. It also empowers insurers to educate consumers about their options.
CMS has identified PDex Drug Formulary IG Version 2.0.1 as ready for adoption in Certified Health IT. Developed by the Da Vinci Project Accelerator, the IG is available for implementation without licensing requirements, making it accessible to payers and health IT developers.
Referenced in Federal Rulemaking:
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
Standard / Specification:
HL7® FHIR® Da Vinci Payer Data Exchange Plan Net Implementation Guide (PDex Plan Net IG)
Standard Process Maturity: Balloted
Implementation Maturity: Production
This implementation specification provides a framework for payer health IT systems to publish information about their insurance plans, providers, participating organizations, and associated networks via a FHIR API. This specification is designed to help patients and providers understand which providers, facilities, and pharmacies are covered by a healthcare insurance plan, ensuring that coverage and clinical information are both useful and actionable. Using the PDex Plan Net IG, third-party developers can create applications that allow patients and providers to search for participants in a payer’s network who can deliver requested or needed healthcare services.
CMS has identified PDex Plan Net IG Version 1.1.0 as ready for adoption in Certified Health IT. Developed by the Da Vinci Project Accelerator, the IG is available for implementation without licensing requirements, making it accessible to payers and health IT developers.
Referenced in Federal Rulemaking:
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
Standard / Specification:
HL7® FHIR® Da Vinci Clinical Data Exchange Implementation Guide (CDex IG)
Standard Process Maturity: Balloted
Implementation Maturity: Pilot
This Implementation specification provides a framework for data exchange between providers and payers, as well as provider-to-provider and payer-to-payer workflows, for patient EHR data. The CDex IG supports query-based, task-based, and documents-based data exchange workflows.
The CDex IG is not intended to replace other HL7 FHIR Da Vinci specifications required by the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F). Instead, it focuses on specific workflows at the provider-payer interface, particularly when there is a need for manual review of received data query requests from external providers or payers. It is important to note that the CDex IG should not be implemented for workflows requiring real-time responses. Instead, it is suitable for scenarios where manual review of data query responses is necessary before delivering the data to partner providers or payers.
Certified Health IT developers, providers, and payers are encouraged to consider the CDex IG as a starting point for supporting data exchange at the provider-payer interface. This specification enables controlled and structured data sharing while allowing manual oversight to ensure accuracy and compliance in data exchange workflows.
Standard / Specification:
HL7® FHIR® Da Vinci – Member Attribution List Implementation Guide (ATR IG)
Standard Process Maturity: Balloted
Implementation Maturity: Pilot
This implementation specification provides a framework for data exchange between providers and payers to support risk-based contracts, value-based contracts, care gap closures, and quality reporting. It defines workflows for managing member attribution lists, which are essential for aligning patients with providers and organizations under specific healthcare plans or contracts. The IG supports exchange of full member attribution lists; updates to existing member attribution lists; and notifications of member attribution list updates.
The ATR IG outlines data exchange mechanisms, data structures, and value sets for commonly found information in member attribution lists, including plan/contract information, patient information, attributed individual provider information, attributed organization information, and member and subscriber coverage.
While the ATR IG does not directly leverage other FHIR Da Vinci specifications, it complements them by enabling use cases described in related guides, such as the FHIR Da Vinci Payer Data Exchange (PDex) and FHIR Da Vinci Clinical Data Exchange (CDex) IGs.
Standard / Specification:
HL7® FHIR® Quality Improvement Core Implementation Guide (QI-Core IG)
Standard Process Maturity: Multiple balloted versions available
Standard Process Maturity: Production
This implementation specification provides requirements and guidance for using FHIR in quality measurement and decision support. It defines standardized profiles derived from FHIR resources described in the US Core IG, creating a consistent data set for use across various quality measures.
Each annual version of the QI-Core IG builds upon the corresponding version of the US Core IG, which aligns with updates to USCDI.
The QI-Core IG serves as a foundational resource for Certified Health IT developers and the broader quality improvement community. It is particularly valuable for those interested in leveraging FHIR for applications focused on quality measurement and reporting.
CARE DELIVERY AND ENGAGEMENT COMPONENTS
FHIR-based Care Delivery and Engagement specifications are designed to improve patient access to their health data and interactions with the healthcare system. These specifications aim to empower patients by providing them with easier and more secure access to their medical information while also reducing administrative burdens on healthcare providers. Additionally, they support providers in areas such as clinical decision support, enhancing the quality and efficiency of care delivery. Key agencies involved in advancing these specifications include CMS, HRSA, and CDC.
Interested parties should use the latest version of the listed specification if a specific version is not referenced in the specification description.
Standard / Specification:
HL7® FHIR® International Patient Access Implementation Guide (IPA IG)
Standard Process Maturity: Balloted
Implementation Maturity: Pilot
This implementation specification defines a framework for enabling third-party applications to access health information using FHIR APIs across multiple countries. This specification aims to promote consistency for multinational applications and FHIR servers by providing standardized authorization based on the SMART App Launch IG and a common set of FHIR Profiles derived from an analysis of existing national base profiles.
The IPA IG leverages international terminology standards and FHIR R4 Resources, ensuring compatibility and effective data sharing between this specification and the FHIR US Core IG.
While the IPA IG has not yet been widely implemented at scale in the United States, it serves as a strong foundation for regulators and national specification authors interested in developing a national health API ecosystem. ASTP anticipates that the IPA IG will mature as more experience is gained from its implementation.
Standard / Specification:
HL7® FHIR® International Patient Summary Implementation Guide (IPS IG)
Standard Process Maturity: Balloted
Implementation Maturity: Pilot
This implementation specification defines an interoperable set of FHIR resources that contain a patient summary for sharing health information between patients and clinicians, primarily across countries. This specification uses international terminology standards and FHIR R4 resources, ensuring compatibility and effective data sharing between the IPS IG and the FHIR US Core IG.
Many European countries and members of the Global Digital Health Partnership—including the Netherlands, Estonia, the United Kingdom, Canada, Brazil, and New Zealand—are piloting the IPS FHIR IG and have expressed intentions to adopt it for projects within their countries. While the IPS IG is primarily designed for cross-border data sharing, it also supports domestic data exchange use cases, making it versatile for various healthcare scenarios.
Although the specification is still in the early stages of adoption, it provides a solid foundation for use cases requiring cross-border health data exchange. When combined with the International Patient Access (IPA) IG, the IPS IG creates a robust environment for digital innovation in healthcare.
PUBLIC HEALTH & EMERGENCY RESPONSE COMPONENTS
Public Health and Emergency Response HL7 FHIR specifications seek to modernize public health data systems and infrastructure enabling more efficient and effective data exchange and management. With its responsibilities to public health, CDC plays a key role in the development of new FHIR capabilities in this area.
Several of these specifications are used in federal programs or initiatives including the
ASTP Certification Program
CDC NCHS National Vitals Statistics System (NVSS)
CDC National Health Care Surveys Registry
CDC National Program of Cancer Registries
CDC Public Health FHIR Playbook (2023)
Interested parties should refer to the latest version of the listed specification if a specific version is not referenced in the specification description.
Standard / Specification:
HL7® FHIR® Electronic Case Reporting Implementation Guide (eCR IG)
Standard Process Maturity: Balloted
Implementation Maturity: Pilot
This implementation specification supports the exchange of case data and bidirectional communication of public health information, focusing on a patient’s condition and local disease trends. As part of the
Public Health Data Strategy
, electronic case reporting is prioritized as a key automation to reduce administrative burden and promote more complete and timely data exchange.
The eCR IG enables the use of FHIR-based solutions aligned with FHIR R4 and the US Core IG for transmitting electronic case reports and reportability responses. It also facilitates the consumption and processing of electronic case reporting trigger codes, which are matched against the Reportable Conditions Trigger Code (RCTC) value set specified in the eCR IG.
While there are multiple versions of the eCR IG, ASTP has identified version 2.1.0 as most ready for adoption in Certified Health IT.
Referenced in Federal Rulemaking:
ASTP HTI-1 Final Rule
Standard / Specification:
HL7® FHIR® Vital Records Birth and Fetal Death Reporting Implementation Guide (BFDR IG)
Standard Process Maturity: Balloted
Implementation Maturity: Pilot
This implementation specification defines FHIR resources that represent content used for reporting birth and fetal death information to state electronic birth registration systems (EBRS).
This specification provides the content that can support development in automating the manual process of entering required information dually into Certified Health IT and public health systems.
The specification has undergone multiple formal ballot processes to make important updates but it has not yet been widely implemented.
Users should consider the Vital Records BFDR IG if interested in leveraging a FHIR-based approach using the SMART App Launch IG for transmission.
Standard / Specification:
HL7® FHIR® Vital Records Death Reporting Implementation Guide (VRDR IG)
Standard Process Maturity: Balloted
Implementation Maturity: Production
This implementation specification defines FHIR resources to enable the bidirectional exchange of mortality data between data collection sites, such as Certified Health IT systems, case management systems, Jurisdictional Vital Records Offices (VROs), and CDC. This specification supports vital public health surveillance and response by facilitating the exchange of critical data elements through vital records.
Implementers interested in leveraging a FHIR-based approach for transmitting mortality data should consider adopting the VRDR IG, which integrates with the SMART App Launch IG for secure and efficient data transmission.
The VRDR IG automates mortality information exchange, connecting data collectors—such as physicians, medical examiners, coroners, funeral directors, and family members—with VROs and other users of mortality data. It also supports the aggregation of vital statistics information, ensuring a streamlined and standards-driven approach to mortality data management.
Standard / Specification:
HL7® FHIR® Medicolegal Death Investigation Implementation Guide (MDI IG)
Standard Process Maturity: Balloted
Implementation Maturity: Production
This implementation specification defines FHIR resources to facilitate the exchange of information between medicolegal death investigation systems and other FHIR-enabled health IT systems. This specification supports data exchange between medical examiner and coroner office case management systems, laboratory information management systems (LIMS), and electronic death registration systems (EDRS).
The MDI IG provides implementation guidance for four key data flows: 1) create, search, and update case records to manage case information; 2) Transmission of diagnostic findings to share laboratory and investigative results; 3) Transmission of MDI PDFs to exchange formatted reports; and 4) transmission of completed U.S. Death Certificates for official documentation.
Additional efforts are underway to further develop MDI-specific terminology, ontological standards, and implementation guidance for other data flows. Tools and testing environments, such as the
Raven Testing Platform
and the
Raven Documentation Platform (GitHub)
, are being developed to support the implementation and adoption of the MDI IG, ensuring robust and reliable data exchange in medicolegal contexts.
Standard / Specification:
HL7® FHIR® Health Care Surveys Content Implementation Guide
Standard Process Maturity: In Development
Implementation Maturity: Pilot
The Health Care Surveys Content Implementation Guide (IG) defines the use of FHIR resources to electronically capture and transmit survey data to public health agencies. These surveys provide valuable information on healthcare utilization, including details about symptoms, diagnoses, and procedures, and cover a wide range of healthcare settings.
This specification was developed to automate the traditionally manual process of submitting survey data, enabling broader participation from hospitals and healthcare organizations while reducing the reporting burden on individuals and institutions.
Health IT developers interested in adopting a FHIR-based approach to streamline the electronic transmission of healthcare survey data should consider implementing the Health Care Surveys Content IG. This specification helps reduce manual processes, improve efficiency, and ensure more comprehensive data collection for public health purposes.
Standard / Specification:
HL7® FHIR® Profiles for Transfusion and Vaccination Adverse Event Detection and Reporting Implementation Guide (Transfusion and Vaccination AE IG)
Standard Process Maturity: Balloted
Implementation Maturity: Pilot
This implementation specification provides a framework for reporting adverse events following transfusions and vaccinations using FHIR resources. These resources include the necessary information required by the Food and Drug Administration (FDA) for decision-making and have been successfully piloted through the
BEST Innovative Methods Exchange Platform
Health IT developers seeking to adopt a FHIR-based approach to electronically transmit adverse event data should consider implementing the Transfusion and Vaccination AE IG. This specification helps reduce manual reporting processes, streamline data submission, and ensure accurate and timely reporting of adverse events to support regulatory and public health efforts.
Standard / Specification:
HL7® FHIR® Central Cancer Registry Reporting Content Implementation Guide
Standard Process Maturity: Final
Implementation Maturity: Production
This implementation specification defines FHIR resources for reporting diagnosed cases of cancer, treatments, and demographic information from electronic health records (EHRs) to central cancer registries. Cancer reporting is a critical and mandatory component of cancer control efforts in the United States, as it provides essential data to inform public health interventions and allocate resources to communities and populations with high cancer rates.
This specification offers a FHIR-based approach as an alternative to the previously used CDA-based method identified by ASTP. By leveraging FHIR, the Cancer Reporting IG enables more streamlined, interoperable, and efficient data exchange between healthcare providers and cancer registries, supporting improved cancer surveillance and control efforts.
Standard / Specification:
HL7® FHIR® US Public Health Profiles Library Implementation Guide (USPHPL IG)
Standard Process Maturity: Balloted
Implementation Maturity: Pilot
This implementation specification defines FHIR resources that represent a public health-specific dataset of common data elements required to support key public health data exchange use cases.
The FHIR resources specified in the USPHPL IG, in conjunction with the US Core IG, enable advanced data exchange capabilities, including more granular sharing of patient data. This approach reduces the implementation and maintenance burden for data exchange between healthcare organizations and public health agencies.
Health IT developers interested in adopting a FHIR-based method for electronic data transmission, using the SMART App Launch IG as an alternative to manual reporting processes, should consider implementing the USPHPL IG.
RESEARCH COMPONENTS
Research specifications aim to advance the development of a fully digital health system that leverages FHIR for research-related activities. Given the open-ended nature of research, these specifications have the potential to create multiple downstream impacts across healthcare and scientific domains. Key agencies within the HHS —including NIH and its component institutes, CDC, and FDA — play significant roles in shaping the development of FHIR capabilities. Their input ensures that these specifications are optimized for future implementation and use, supporting robust and interoperable research processes across the healthcare ecosystem.
Interested parties should refer to the latest version of the listed specification if a specific version is not referenced in the specification description.
Standard / Specification:
HL7® FHIR® mCODE (minimal Common Oncology Data Elements) Implementation Guide (mCODE IG)
Standard Process Maturity: Balloted
Implementation Maturity: Pilot
This implementation specification defines FHIR resources specifically for oncology-related healthcare and research. It represents a significant step toward capturing a core set of structured data elements from the treatment of all cancer patients, facilitating data sharing between oncology information systems and other health IT systems.
The mCODE IG will serve as the base for future IGs, such as the published Enhancing Oncology Model, to support collecting data elements for the alternative payment model developed by the Center for Medicare and Medicaid Innovation (CMMI).
IT developers and members of the standards community interested in capturing research-quality data and improving interoperability for oncology use cases are encouraged to adopt the mCODE IG.
Early-Stage Capabilities
ASTP collaborates with federal agency partners to align health IT initiatives and policies. This coordination occurs through groups like the Federal Health IT Coordinating Council and policies such as the
HHS Health IT Alignment Policy
. As part of its efforts, ASTP worked with agency partners to identify priority initiatives and use cases, which led to the development of early-stage capabilities. Many of these capabilities are being advanced through
HL7 FHIR Accelerators
FHIR Accelerators are collaborative, multi-organization groups focused on advancing the HL7 FHIR standard. These groups are organized around specific use cases and aim to address critical new functionalities required for the continued adoption and implementation of FHIR. By tackling pressing challenges, FHIR Accelerators play a key role in driving innovation and interoperability in health IT systems, ensuring that FHIR evolves to meet the needs of diverse stakeholders in healthcare.
Argonaut
– Focuses on expanding information sharing for electronic health records (EHRs) and other health information technologies, driving interoperability and data exchange in clinical settings.
CARIN Alliance
– Works to advance consumer-directed exchange across the U.S., empowering patients to access and manage their health information securely and efficiently.
CodeX
– Develops guidance on interoperable data modeling and implementation around CodeX FHIR standards,
Da Vinci
– Assists payers and providers in improving clinical, quality, cost, and care management outcomes by creating FHIR-based solutions for value-based care and payment models.
FHIR At Scale Taskforce (FAST)
– Identifies and addresses challenges faced by FHIR implementers when scaling FHIR solutions, ensuring robust and scalable interoperability.
Gravity Project
– Develops standards and technologies to address the social determinants of health (SDOH), aiming to meet individuals' social need and, improve health outcomes.
Helios
– Focuses on developing FHIR-based standards and approaches for public health, enabling better data sharing and decision-making in public health initiatives.
Vulcan
– Accelerates the development, refinement, and use of FHIR standards for clinical and translational research, supporting advancements in healthcare innovation and scientific discovery.
The list of early-stage capabilities highlights key advancements needed to develop the next generation of FHIR functionalities that will drive improvements in healthcare. These capabilities represent foundational steps toward enhancing interoperability, streamlining data exchange, and enabling innovative health IT solutions. ASTP will continue working closely with federal agencies to identify additional capabilities that align with interoperability goals. As new priorities and use cases are identified, they will be added to the list, ensuring that the evolving FHIR standard addresses emerging needs in healthcare and supports the broader vision of a connected and efficient health IT ecosystem.
Capability: Enable import of health information from external sources (FHIR Write)
As consumers increasingly use health-related technologies such as smartphone apps and wearable devices, the data generated by these tools has the potential to enhance clinical decision-making if integrated into a patient’s health record. A standardized "FHIR Write" approach, which allows external health organizations to contribute data to a patient’s record, could also help reduce the administrative burden on healthcare providers.
While the FHIR standard supports "write" operations through RESTful APIs, these capabilities have not been widely implemented in health IT systems. This is largely due to security concerns and the lack of clear guidance for health IT developers on expected behaviors for enabling "write" functionality. Additionally, many health IT developers have created proprietary APIs that are limited to specific use cases, further hindering standardization.
Advancing FHIR Write use cases in alignment with USCDI (United States Core Data for Interoperability) elements would be a significant step toward enabling this capability in a consistent and secure manner. Specifications that define applicable workflows and data types—such as clinical, administrative, and billing data—will be critical for implementing FHIR Write capabilities within existing health IT systems and infrastructure.
The
Argonaut Accelerator
is actively pursuing multiple capabilities and timelines under the umbrella of FHIR Write. Interested parties are encouraged to follow these efforts to stay informed about developments and opportunities to contribute to the advancement of this capability.
Capability: Create and manage digital identities
As interoperability reduces data silos in healthcare, the ability of health IT systems to accurately match individuals' records from external systems becomes increasingly important. Digital identity and identity matching are essential capabilities for advanced data analytics, such as record linkage, which relies on precise identification of individuals across disparate systems.
A key aspect of scaling FHIR is the development of robust digital identity and identity management solutions. The FHIR FAST Accelerator is actively working to create guidance that ensures health IT systems—and, by extension, care providers—can accurately match digital identities, particularly when external data is imported into a health IT system.
The
HL7® FHIR® FAST Interoperable Digital Identity and Patient Matching Implementation Guide
is designed to establish best practices and standards for digital identity and person matching. This specification provides detailed guidance on defining the match operation used in cross-organizational FHIR data exchanges, supporting accurate identity management and person matching.
Health IT developers and those that are interested in scaling FHIR are encouraged to follow the work being conducted by the
FAST Accelerator
Capability: Enhance and ease data exchange between public health institutions and provider organizations
Public health is a critical area for modernizing data exchange, as public health emergencies have highlighted the need for efficient and timely data sharing across the healthcare system, including public health organizations. The capabilities outlined in the Federal FHIR Action Plan’s Public Health & Emergency Response Components table represent significant progress toward achieving this goal. However, further collaboration and coordination between healthcare providers and public health entities, such as state health departments and federal partner agencies, are necessary to scale health data exchange effectively.
Timely access to relevant data enables public health authorities to respond more quickly and appropriately to emerging health threats. Enhancing and simplifying data exchange capabilities for public health use cases, while ensuring data privacy and security, is essential to achieving these improvements. The Helios Accelerator is actively working on initiatives that support these goals, such as Delivering Aggregate Information to Public Health, Making Data in Public Health Systems Accessible in Bulk, and Using Query and Response to Address Public Health Data Needs.
Health IT developers and those that are interested in advancing public health data exchange are encouraged to follow the work being conducted by CDC and by the
Helios Accelerator
Capability: Transmit cancer pathology information
ASTP is monitoring the
HL7® FHIR® Cancer Pathology Reporting IG
, a specification designed to facilitate the creation and transmission of cancer pathology laboratory values and results to central cancer registries (CCRs). Cancer pathology reporting plays a critical role in diagnosing cancer and assessing the progression of cases at the point of diagnosis.
Early pilot results have shown that adopting this IG can significantly reduce the need for manual intervention and data cleansing, enable more timely reporting, and ensure the inclusion of data elements that are essential for public health action. By streamlining the reporting process, the IG supports more efficient and accurate data exchange.
This specification provides best practices for FHIR-based transmission of pathology data, enabling interoperability between CCRs, EHRs, and Laboratory Information Systems (LIS). It focuses on structured data collection and exchange, offering guidance on common data models, defined data items, and relevant ontological standards and value sets.
Capability: Report digital quality measures for health care safety
The
HL7® FHIR® National Healthcare Safety Network (NHSN) Digital Quality Measure (dQM) Reporting IG
supports CDC’s data modernization efforts by enabling the electronic submission of digital quality measures to the NHSN, which is a CDC infection tracking surveillance system. This IG is designed to streamline the reporting process for healthcare facilities participating in NHSN.
Building on previous work from the
Quality Measure IG
and the
Data Exchange for Quality Measures IG
, this specification aims to reduce the burden of reporting, improve the accuracy, quality, and validity of submitted data, and enhance the speed and efficiency of the reporting process. It achieves these goals by leveraging data from existing Certified Health IT APIs, including the US Core IG, ensuring interoperability and alignment with established standards.
NHSN participants are encouraged to review this IG to explore NHSN-specific FHIR Profiles and example digital quality measures. The IG also provides details on terminology and ontological standards relevant to NHSN reporting, helping participants understand and implement the specification effectively.
Capability: Exchange information during public health emergencies
Public health emergencies expose significant gaps in the existing public health reporting infrastructure, particularly in the ability to monitor healthcare system stress and capacity. These challenges underscore the need to enhance capabilities for tracking and reporting public health metrics during emergencies.
The
US Situational Awareness Framework for Reporting (SAFR) IG
establishes a standardized, FHIR-based approach to address these gaps. It supports public health decision-making during emergencies by standardizing FHIR interfaces and endpoints for public health organization; automating data collection to reduce manual effort; enabling real-time data exchange for timely insights; and providing a comprehensive view of healthcare capacity and trends.
By implementing the US SAFR framework, healthcare facilities and public health authorities can exchange critical information and report metrics to federal agencies more efficiently. Implementers interested in the
US Situational Awareness for Novel Epidemic Response (SANER) IG
should review the SAFR implementation guidance.
Capability: Enhance and ease data exchange for research purposes
Enhanced data exchange and interoperability can significantly benefit the federal health research community, much like it does for public health. Provider-sourced healthcare data has the potential to contribute to various research areas, but this is currently complicated by differences in data models. There is a pressing need to bridge the gap between Certified Health IT data formatted in FHIR and research data formatted in Common Data Models (CDMs) such as OMOP and i2b2. Addressing this gap can help researchers tackle challenges related to data granularity, data quality, and missing data.
Advancements in harmonizing terminologies and bindings will further support data exchange in critical research areas, including real-world evidence generation, clinical trials data, and adverse events monitoring. These improvements will enable researchers to leverage healthcare data more effectively for insights and innovation.
Health IT developers and stakeholders interested in FHIR capabilities for research use cases are encouraged to follow the work being conducted by FDA and by the
CodeX
and
Vulcan
Accelerators.
Capability: Retrieve Real-World Data for clinical research
With the adoption of Certified Health IT, researchers are increasingly looking to use Real-World Data (RWD) — data collected outside of controlled clinical settings — for various purposes, including clinical trials, real-world evidence generation, post-market safety surveillance, and training data for machine learning (ML) and artificial intelligence (AI) models. While the potential of RWD is significant, there is a need to define a minimum set of FHIR resources to enable the standardized digital exchange of clinical research data.
The
HL7® FHIR® Retrieval of Real-World Data for Clinical Research IG
aims to address this need by providing guidance for collecting and using RWD and real-world evidence. This IG focuses on retrieving RWD from Certified Health IT systems via FHIR APIs. The specification does not provide guidance on how RWD should be used downstream after it is obtained. The scope of this IG is limited to Certified Health IT, though future iterations may expand to include other data sources such as registries, payer systems, and health information networks.
The Retrieval of Real-World Data for Clinical Research IG uses the International Patient Access (IPA) IG as its baseline. While it leverages the IPA IG to access RWD, it also provides additional specifications tailored to clinical research, including specific data elements and FHIR Resources.
Health IT developers and stakeholders interested in HL7 FHIR capabilities for research use cases are encouraged to follow the work being conducted by the FDA and by the
Vulcan
Accelerator.
Capability: Obtain adverse events data for clinical research
There is a significant opportunity to leverage adverse events from Real-World Data (RWD) sources to support and enhance clinical research studies. The collection and use of adverse event data are critical for clinical research, as they help capture essential information such as cause-and-effect relationships, seriousness, severity, and outcomes of adverse events.
The
HL7® FHIR® Adverse Event Clinical Research IG
aims to establish a baseline standard for the FHIR Adverse Event Resource specifically for clinical research purposes. This IG enables implementers to collect adverse event data from RWD sources, such as Certified Health IT systems and post-market surveillance systems, using FHIR APIs. The collected adverse event data can be used to supplement clinical research studies in various ways, including post-market surveillance, public health emergencies, and clinical trials.
While the specification is developed for FHIR R5, the
HL7® FHIR® Adverse Event Clinical Research R4 Backport IG
is available for implementers whose Certified Health IT systems are configured to FHIR R4. This IG allows implementers to adopt the functionality of the FHIR R5 specification.
Health IT developers and stakeholders interested in FHIR capabilities for research use cases are encouraged to follow the work being conducted by the FDA and by the
Vulcan Accelerator
Capability: Report genomics data
Genomic variations play a critical role in healthcare, as they can significantly impact a patient’s health outcomes. To effectively leverage genomic data in clinical and research settings, there is a need for standardized, consistent, and computable methods for exchanging this data.
The
HL7® FHIR® Genomics Reporting Implementation Guide (Genomics Reporting IG)
provides a framework for reporting genomic data in an interoperable manner using the FHIR standard. This specification offers standardized guidance and examples for reporting multiple types of genomic data.
The Genomics Reporting IG has been piloted through the ASTP-led
Sync for Genes
program, demonstrating its potential for real-world application. While the specification is still in the early stages of adoption, ASTP has identified Version 2.0.0 of the Genomics Reporting IG as ready for consideration by health IT developers. This version is particularly relevant for use cases that require the integration of genomic data with other health data, supporting advancements in personalized medicine, research, and clinical decision-making.
Capability: Harmonize interoperability standards between health and human services
HHS seeks to leverage data safely and effectively to improve the health and well-being of all Americans. A key focus is addressing critical gaps in data interoperability, particularly in human services programs. This includes developing standards, use cases, and tools, as well as establishing minimum system requirements for EHRs to support human services programs and ensure seamless interoperability with healthcare systems.
The FHIR standard is a crucial component for achieving robust data interoperability between health and human services systems. By enabling standardized data exchange, FHIR can help bridge the gap between healthcare and human services, facilitating better coordination and outcomes.
Moving Forward
SEND FEEDBACK TO ASTP
The Federal FHIR Action Plan is designed to be a collaborative and evolving framework that benefits from input and feedback from federal agency partners, the standards development community, and SMEs. Since the FHIR standard is a broad, community-driven effort, there may be federal initiatives or insights that have not yet come to the attention of ASTP.
ASTP encourages interested parties to provide recommendations for additional specifications that should be included in the component tables, as well as suggestions for new capabilities that are in early stages of development. This feedback is essential for ensuring the action plan remains comprehensive, relevant, and aligned with interoperability goals.
ASTP expresses gratitude to federal and industry partners for their contributions, emphasizing that the current final version of the action plan — and future iterations — are made possible through their support and collaboration. This partnership is critical to advancing the adoption and implementation of FHIR standards to improve healthcare interoperability and outcomes.
ADVANCE AND REUSE HL7® FHIR® COMPONENTS
Federal agencies are actively reusing existing FHIR components in their development activities to support interoperability and streamline health IT initiatives. ASTP encourages agencies to collaborate with both ASTP and other relevant federal agencies to refine these existing components, as well as emerging ones, to ensure they align with agency-specific requirements and priorities.
In addition to refining existing components, federal agencies are encouraged to identify any new FHIR specifications that may be necessary to address their unique needs. This proactive identification of gaps or opportunities will help ensure that the FHIR standard evolves to meet diverse use cases across the federal landscape.
ASTP will continue to monitor agency feedback and update the Federal FHIR Action Plan regularly, ensuring it remains an informative framework that supports the interoperability goals of federal agencies and the broader health IT community.
FEDERAL COORDINATION TO ADVANCE THE FHIR STANDARD
Coordinated federal input is essential for shaping the timely advancement of the FHIR standard and guiding the development of new capabilities that address the specific needs of federal agencies. By working together, federal agencies can ensure that FHIR evolves in alignment with interoperability goals and supports the diverse use cases required across the healthcare ecosystem.
Federal agencies are encouraged to use the Federal FHIR Action Plan as a resource to:
Identify and address common needs across agencies;
Coordinate requests and focus areas for the FHIR standards community and implementation partners; and
Optimize investments by reusing and advancing widely adopted capabilities, avoiding duplication in federal use cases.
The network of federal agencies involved in healthcare information technology is extensive, ranging from large departments to smaller agencies. While coordinating efforts at this scale presents challenges, collaboration and alignment of IT initiatives are essential to ensure efficient and cohesive operations across the federal landscape.
Thanks to the coordinated efforts of federal agencies and the willingness of technology developers, FHIR APIs are now
widely available across the United States
. Adoption rates of FHIR among healthcare providers are expected to increase significantly in the coming years as the necessary policies and technical infrastructure for FHIR API-based healthcare delivery systems are established.
As the nation transitions to a fully digital healthcare system, stakeholders are uncovering new opportunities to leverage health information technology to enhance healthcare delivery, public health, and research, ultimately improving people's lives. However, this exciting progress requires proactive alignment and coordination of FHIR-related activities across federal agencies to ensure efficiency and interoperability.
By aligning federal efforts in advancing FHIR standards and requirements, the objective is to reduce barriers to implementation, such as funding challenges and health IT workforce limitations, and improve health IT interoperability. The action plan aims to serve as a common platform for federal coordination and investments, providing the standards community and industry with clear guidance to accelerate the advancement of the FHIR standard.
This approach ensures that the transition to a digital healthcare system is innovative, efficient, and impactful, driving better outcomes for healthcare delivery, public health, and research.
We hope the considerations and approaches described in the draft action plan help provide a common platform for federal coordination and investments and provide the standards community and industry a clear direction to rapidly advance the FHIR standard.
Frequently Asked Questions
What is the purpose of the Federal FHIR Action Plan?
The purpose of the Federal FHIR Action Plan is to drive federal investment in and adoption of the
Health Level 7 (HL7®) Fast Health Interoperability Resources (FHIR)
standard. Its primary goal is to align federal agencies' adoption and use of FHIR around a set of essential components and capabilities that agencies have already promoted, implemented, or plan to implement within the next two years. Many of these components are mature and currently in production, supporting interoperability and advancing health IT initiatives. For more information, you can read the "About the Federal FHIR Action Plan" section, which provides additional details on its objectives and scope.
Who is the action plan for?
The action plan is primarily intended for federal agencies and their industry partners. It serves as a resource to inform agencies in determining which FHIR specifications to implement, include as requirements in funding opportunities, or recommend to their partners. Additionally, the action plan provides valuable insights into federal adoption of FHIR for secondary beneficiaries, such as state, tribal, local, and territorial health departments (STLTs), private sector organizations, non-profits, researchers, and other members of the healthcare ecosystem.
What is in the action plan?
The action plan contains a focused set of interoperability components that address the use of FHIR. Many of the listed specifications are mature, having been thoroughly tested and vetted through the standards process and implementation. These mature specifications do not require further investment and can be confidently used by federal agencies.
The components in the action plan are organized into six categories, which can be found in the "FHIR Ecosystem" tab – Core, Network, Payment and Health Quality, Care Delivery and Engagement, Public Health and Emergency Response, and Research. Additionally, the "Early-Stage Capabilities" section lists IGs, initiatives, and subject areas that are in developmental stages but have generated significant interest. These early-stage capabilities represent emerging opportunities for advancing FHIR-based interoperability in healthcare.
What is not in the action plan?
The action plan is intentionally focused on FHIR specifications, primarily represented by IGs. It does not include guidance on separate but related standards, such as terminologies or non-FHIR exchange standards. Information about these related standards can be found in the
Interoperability Standards Advisory (ISA)
Additionally, the action plan does not provide a comprehensive listing of all FHIR specifications currently in use or under consideration by government agencies. Instead, it focuses on capabilities and specifications that are particularly relevant for cross-agency collaboration and coordination. This ensures the action plan remains targeted and actionable for advancing interoperability across federal agencies.
What criteria were used to select the standards listed in the action plan?
FHIR specifications were included in the action plan based on four criteria – agency interest, implementation, maturity, and reusability. Inclusion determinations were made based on discussions with ASTP and federal agency partner SMEs, public feedback submitted during the open feedback period, and review of public information.
How is the action plan different from the ISA?
The action plan differs from the Interoperability Standards Advisory (ISA) in its scope and target audience. The action plan focuses on a limited set of interoperability needs identified by federal agencies that specifically support the use of FHIR specifications. In contrast, the ISA is designed to address a broader range of interoperability needs, covering over 75 different standards areas in its latest edition, which include standards beyond FHIR.
Will the action plan be updated in the future?
The action plan will be updated on an annual basis as part of the ISA feedback process. Commenting functionality will remain available for registered ISP users at all times.
What specification should I reference?
Interested parties should refer to the latest version of the listed specification if a version is not referenced in the specification description.
How can I comment on the action plan?
An ISP site account is required to comment on the action plan.
If you have an account already, click
here
or click the “LOG IN” button at the top right of the ISP and enter your log in information.
To create an account, click
here
or click the “LOG IN” button, then “Create new account” tab above the log in window. Account approval is required and is generally completed within 24 hours.
Your comments will be reviewed by ASTP and/or other HHS subject matter experts and considered for future updates of the action plan.
Appendix VI: AI for Interoperability
UNDERSTANDING AI STANDARDS IN HEALTH IT
AI capabilities such as decision support, summarization, image analysis, and automation are rapidly becoming embedded within EHRs, health information networks, and consumer-facing applications. In parallel, a new generation of AI-focused interoperability standards is emerging that emphasizes reusable, well-defined building blocks for safely connecting AI agents to clinical data, workflows, and tools, rather than bespoke interfaces for each use case.
As with API-based interoperability, these AI standards seek to enable composable architectures in which common services (for example, data access, identity, consent, and logging) can be orchestrated to support many different AI-enabled workflows without starting from scratch each time. However, because AI systems can autonomously interpret data and trigger actions, AI standards must also address additional dimensions such as explainability, risk management, auditing, and guardrails around model behavior.
Role of HL7® Standards in AI-Enabled Interoperability
HL7® standards, including HL7 Version 2, HL7 C-CDA, and HL7 FHIR®, continue to provide the core “language” for health data exchange that many AI solutions depend on. For example, AI applications often consume or produce patient demographics, encounters, problems, observations, medications, and procedures using HL7 FHIR resources and implementation guides (e.g., US Core profiles), enabling them to participate in workflows such as clinical decision support, quality measurement, and prior authorization.
These HL7-based standards and APIs function as foundational services that can be reused by multiple AI applications, consistent with the building-block approach described for API-based interoperability. Implementers must still define which specific HL7 resources are required, what value sets and profiles are used, which operations are permitted (for example, read-only vs. write), and how security, consent, provenance, and audit are managed for AI use cases that may involve large-scale, longitudinal, or real-time data access.
Model Context Protocol (MCP) as an Emerging AI Integration Standard
The Model Context Protocol (MCP) is an emerging open standard that defines how AI tools and agents can connect to external tools, services, and data sources. MCP standardizes a JSON-RPC pattern for requesting context (“resources” and “prompts”), invoking operations (“tools”), and returning structured results across standard transports such as stdio and HTTP.
In healthcare implementations, MCP can be layered on top of HL7 FHIR interfaces to structure tool calls (e.g., FHIR reads, searches, and write proposals) while enforcing clinical safety constraints, human-in-the-loop validation, and traceable handoffs between humans and AI. Identity, authorization, and delegation are still evolving across the ecosystem (including community extensions such as MCP-I) and active discussions are underway to align these standards with HIPAA, FDA software-as-a-medical-device (SaMD) guidance, and other policy requirements.
For multi-agent scenarios, agent-to-agent standards such as A2A can complement MCP by enabling agent discovery (e.g., Agent Cards), capability negotiation, and task-oriented collaboration across organizational boundaries. These standards too hold promise in the healthcare context.
Key Implementation Considerations for AI Standards
As with API-based interoperability, successful AI-enabled interoperability requires implementers to specify and constrain multiple layers of the stack for a given use case. When deploying AI systems that rely on HL7, MCP, and emerging agentic standards, stakeholders may need to address at least the following:
Data scope and resources
Implementers should define which HL7 resources and data elements are accessible to AI components (for example, limiting to certain FHIR resource types, profiles, or historical time windows) and which code systems (such as LOINC, SNOMED CT, or RxNorm) are in scope for AI processing.
Operations and permissions
It is important to specify whether AI systems can only read data, or may also create, update, or suggest changes, and to constrain MCP tool calls accordingly (for instance, allowing an AI agent to propose an order that still requires human sign-off).
Transport and orchestration
AI components commonly use HTTP-based transports and existing HL7 FHIR RESTful APIs, but MCP orchestration can introduce additional routing and coordination layers between AI agents, EHRs, and ancillary services (including event-driven triggers and subscriptions).
Identity, security, and trust
OAuth2/OpenID-based identity, TLS encryption, and comprehensive audit logging are typically recommended so that AI requests can be tied to specific users, agents, and organizations, with clear records of data access and actions taken. Trust frameworks and governance agreements may be necessary to define how health systems, AI vendors, and content providers establish, monitor, and revoke trust relationships.
Transparency, privacy, and patient expectations
Given concerns about secondary use and sharing of sensitive health information, implementers should ensure that AI deployments include clear privacy notices, transparency mechanisms for how data and outputs are used, and controls to limit redisclosure or profiling beyond the intended clinical or operational purpose.
Looking Ahead
As AI capabilities advance, standards such as HL7 FHIR, MCP, and A2A are likely to evolve in tandem, with new profiles, implementation guides, and best practices focused on safety, governance, and observability—including work like
AI Transparency on FHIR
to document AI-influenced data and processes. Stakeholders deploying AI in Health IT should monitor emerging work by standards development organizations, regulators, and industry collaborations to ensure that AI solutions remain interoperable, trustworthy, and aligned with evolving policy and regulatory frameworks.