The capabilities specified in this document represent the building blocks for an increasingly interoperable, seamless health care ecosystem that provides better interaction and integration for all parties. While some federal agencies are further along in implementation of FHIR capabilities than others, continued implementation of common, core components will create a foundation for accelerated adoption of the next generation of HL7® FHIR® specifications. Continued development and implementation of the Trusted Exchange Framework and Common AgreementTM (TEFCATM) on FHIR specifications will enhance exchange of health care data nationwide for clinical, public health, and research purposes. Implementation Guides developed by HL7’s Da Vinci Project Accelerator will reduce prior authorization burden on both payers and providers, augment payers’ ability to share data with patients, reduce reporting burden, and provide greater continuity for patients changing insurance coverage. Emerging specifications will take the first steps toward providing access to patients for their health information while travelling internationally. Several specifications will begin to address nationwide public health reporting to enhance real-time knowledge of disease trends, while others will standardize cancer data collection and enhance data provided to disease registries. New specifications will lay a foundation for increased use of FHIR for real-world evidence in clinical trials and in genomics.
When these specifications reach a degree of common implementation such that they become the de facto standard, they will have laid the groundwork for new innovations that have the potential to dramatically alter health care by enabling better clinical decision-making, enhancing patient outcomes, optimizing administrative processes, and bolstering public health surveillance. Ongoing enhancements to FHIR will help facilitate this transition, leading to swift data exchange, improved care coordination, and more personalized experiences across diverse systems and applications.
The following HL7® FHIR® components are specifications that will lay the foundation for the next generation of health care interoperability. They have appeared in regulations, are in active development in FHIR Accelerators, and/or are widely anticipated by industry partners. These components are organized into six sections:
- Core Components
Core FHIR specifications and components are the most foundational and have the broadest applicability across healthcare services. They are used for fundamental operations and serve as reusable building blocks to support many use cases. - Network Components
Network specifications apply to FHIR capabilities for accessing and exchanging data between health information networks for securely sharing on nationwide scale. - Payment and Health Quality Components
FHIR-based Payment and Health Quality specifications have been developed to reduce reporting burden for clinicians and caregivers. - Care Delivery and Engagement Components
Care Delivery and Engagement specifications based on FHIR seek to ease patients’ access to their health data and to the healthcare system. They also seek to reduce provider burden and assist providers in areas such as decision support. - Public Health and Emergency Response Components
Public Health and Emergency Response FHIR specifications seek to modernize public health data and infrastructure. - Research Components
Research specifications are intended to drive toward a fully digital health system that uses FHIR for research activities.
These components range from being in active development and progressing through the maturation cycle to ready to be used to address agency needs. Agencies should review the capabilities, requirements, and dependencies of these components before investing in new efforts that may duplicate their functions.
The tables for each of the sections, below, list the FHIR specifications, assessments of their current maturity, and whether they have been cited in federal regulation.
- Standard/Implementation Specification – lists the name of the specification – an Implementation Guide in most cases –and the hyperlink to the specification.
- Standard Process Maturity – lists the specification’s maturity in terms of its stage within a particular organization’s approval or voting process. Balloted indicates the standard or implementation specification is in an official Draft or Trial Use state, per its organization. In development indicates the standard or implementation specification is currently in development or is in the midst of being balloted. These standards would generally benefit from lessons learned through development and pilots.
- Implementation Maturity – defines the specification’s implementation state. Production indicates the standard or implementation specification is being used in production to meet a health care interoperability need. Pilot indicates the standard or implementation specification is being used on a limited scale or only as part of pilots to meet a health care interoperability need.
Federal agencies are encouraged to use the “balloted” components (by Standard Process Maturity) that are already in production (by Implementation Maturity); work to advance specifications that are “in development” or being piloted (by Standard Process Maturity and Implementation Maturity, respectively); and identify any “new” areas that federal agencies should invest in the future. This approach promotes consistency and helps alleviate development and implementation burden, fostering smoother and more efficient collaboration in the pursuit of our shared healthcare goals.
Information contained in the tables has been collected from ASTP’s Interoperability Standards Advisory, consultation with ASTP and federal agency partner SMEs who track the Implementation Guides (IGs) and/or the HL7 Work Groups responsible for those IGs, and federal regulation.
HL7® FHIR® is modular and is designed so that simple parts can be combined in multiple ways to meet multiple needs. Many federal agency activities reuse existing FHIR core components which have been thoroughly tested and are used broadly in production systems. Federal agencies have also identified additional core components that are use-case agnostic and flexible enough to be used in multiple use cases.
ASTP works collaboratively and maintains close relations with HL7 for coordination, awareness, and insight on major activities and developments in FHIR standards. While this collaboration spans the spectrum of use cases that FHIR evolves to address, ASTP has a particular focus on these Core components used in the widest range of subject matter areas. As such, developers and users of FHIR should consult ASTP before investments are made in a component that could be considered as one of these foundational, versatile components.
Standard / Specification: HL7® FHIR® Release 4.0.1 (R4)| Standard Process Maturity: Balloted | Implementation Maturity: Production |
|---|
- Baseline FHIR standard that provides foundational “FHIR Resources” that are stable and mature. The base standard provides the FHIR Resources that are further constrained into “FHIR Profiles” by implementation specifications that are developed to provide a level of consistent implementation necessary for interoperability.
- While a newer version of the base standard, FHIR Release 5 FHIR R5), has been balloted, all implementation specifications adopted by federal regulations (ASTP’s HTI-1 and CMS’ Interoperability and Prior Authorization Final Rule) are based on FHIR R4.
- Additionally, the standards community is working towards releasing FHIR Release 6 (FHIR R6) in the next two years, which will have many more “base FHIR Resources” that will be identified as “normative”, meaning those FHIR resources will be required to be backward compatible for future releases of the base standard.
- As a result, there is growing consensus that unless there is a strong need for a use case that requires functionality only available in FHIR R5, it is preferable for any new standards development activity and implementations be based on FHIR Release 4.0.1.
|
Standard / Specification: HL7® FHIR® US Core Implementation Guide (US Core IG)| Standard Process Maturity: Multiple balloted versions available | Implementation Maturity: Production |
|---|
- Implementation specification that defines minimum constraints on FHIR Resources corresponding to data elements specified in United States Core Data for Interoperability (USCDI). It is the foundation of all US Realm Implementation Specifications and is based on FHIR R4.
- There are multiple versions of US Core IG; each version corresponding to a specific annual release of USCDI. Different versions of US Core IG have been adopted by ONC regulations, based on the timing of the publication of the regulations.
- Certified health IT developers typically adopt the version of US Core IG that is specified in regulation, or the version approved by the National Coordinator in ASTP’s Standards Version Advancement Process (SVAP).
- If the information required to be exchanged for a use case can be accomplished by USCDI, then using US Core IG will provide the easiest and lowest-cost approach. There is also considerable knowledge of US Core IG and support within the standards community and health IT developers to ensure successful implementation, including any modifications if necessary.
|
Standard / Specification: HL7® FHIR® SMART App Launch Implementation Guide (SMART App Launch IG)| Standard Process Maturity: Multiple balloted versions available | Implementation Maturity: Production |
|---|
- Implementation specification that connects applications to FHIR APIs by requesting authorization from OAuth 2.0-compliant authorization servers. It defines a method through which an application requests authorization to access a FHIR resource, and then uses that authorization to retrieve the resource.
- There are multiple versions of SMART App Launch IG. Different versions of SMART App Launch IG have been adopted by ONC regulations, based on the timing of the publication of the regulations. All the versions are compatible with FHIR R4.
- Certified health IT developers typically adopt the version that is specified in regulation, or the version approved by the National Coordinator in ASTP’s Standards Version Advancement Process (SVAP).
- The SMART App Launch IG enables a persistent application authorization process and provides a security layer with which a FHIR API deployment is being combined from both FHIR server and FHIR application perspectives.
- As a result, SMART App Launch IG should be considered as a foundational specification for any FHIR API implementation that requires secure access to FHIR resources.
|
Standard / Specification: HL7® FHIR® Bulk Data Access (Flat FHIR) Implementation Guide (Bulk IG)| Standard Process Maturity: Multiple balloted versions available | Implementation Maturity: Production |
|---|
- Implementation specification to access data for a defined group or set of patients from a FHIR server to a pre-authorized client application.
- There are multiple versions of Bulk IG. Different versions of this IG have been adopted by ONC regulations, based on the timing of the publication of the regulations. All the versions are compatible with FHIR R4.
- Certified health IT developers typically adopt the version that is specified in regulation, or the version approved by the National Coordinator in ASTP’s Standards Version Advancement Process (SVAP).
- While Bulk IG provides a consistent health IT implementation of API-enabled access service for multiple patients, there are performance and scalability challenges that have been identified that are being addressed by health IT developers.
- As a result, Bulk IG performance and scalability should be considered depending upon the use case application. Developers should review the latest information from the health IT developer and standards community before embarking on adopting the IG.
|
Standard / Specification: HL7® FHIR® CDS Hooks 2.0 (CDS Hooks IG)| Standard Process Maturity: Balloted | Implementation Maturity: Production |
|---|
- Implementation specification that describes a “hook”-based pattern for invoking or triggering an external decision support from within an EHR. This pattern facilitates a clinician’s ability to either pull in results from a third-party decision support tool directly into clinician’s workflow or can be used to launch an interactive application for clinical decision support.
- While there are multiple versions of CDS Hooks IG, ONC regulations identify CDS Hooks Release 2.0 as most ready for adoption in certified health IT.
- CDS Hooks IG provides a “deeper” interaction than simply invoking a third-party application and should be considered as an advanced use of FHIR APIs. The use of CDS Hooks requires clients, typically EHRs, to support “hooks” at appropriate points within the EHR workflow.
- As a result, CDS Hooks IG should be considered for use cases where EHRs are both supporting the CDS Hooks IG as a “client” and appropriate “hooks” are available within the EHR.
|
Standard / Specification: HL7® FHIR® SMART Health Cards Framework (SMART Health Cards)| Standard Process Maturity: Balloted | Implementation Maturity: Production |
|---|
- Implementation specification that provides a framework for issuing health information represented using FHIR Resources (any version of FHIR including FHIR R4) to users that can be verified by another party.
- While there are multiple versions of SMART Health Cards, ONC regulations identify SMART Health Cards Framework Version 1.4.0 as most ready for adoption in certified health IT.
- The SMART Health Cards specification has seen rapid adoption in the past few years as a reliable and easy way for users to receive and share clinical information. Once a SMART Health Card is generated, the information contained in the card becomes verifiable to a point in time, which can then be shared at a patient’s discretion via Quick-Response Code (QR code). One limitation of SMART Health Cards is that only a limited amount of information can be stored in QR codes.
- As a result, SMART Health Cards should be considered for use cases that require portability (i.e., without requiring connectivity to a FHIR server) of the limited amount of data, granular sharing at a user’s discretion, and requiring verification of the holder of the health information.
|
Standard / Specification: HL7® FHIR® Subscriptions R5 Backport Implementation Guide (Subscriptions IG)| Standard Process Maturity: Balloted | Implementation Maturity: Pilot |
|---|
- Implementation specification designed to allow clients to ask for notifications from FHIR servers when data changes based on pre-negotiated criteria. Once a subscription is established, a FHIR server can proactively notify a client when new information has been added or existing information has been updated in its system.
- ONC regulation identifies Subscriptions IG (1.1.0 is the latest version) to be compatible with FHIR R4 and as the best able to meet health IT needs that is implemented in the current health IT landscape
- As a result, Subscriptions IG should be considered only if needed to meet the use cases and, more specifically, consider only the capabilities within the specification that are compatible with FHIR R4 (e.g., Topic-Based Subscriptions – FHIR R4).
- While the overall FHIR Subscriptions framework has undergone significant redesign, several updates are targeted for FHIR R5 and later versions. We anticipate that the FHIR Subscriptions framework to be much more mature once FHIR R6 is adopted in future.
|
Network specifications apply to HL7® FHIR® capabilities for exchanging and discovering data across large, multi-nodal networks. At present, these components are most apparent in the progression of TEFCA infrastructure to a FHIR-based system but can play a role in future developments in network applications. Considering ASTP’s role in TEFCA, also falling under ASTP’s purview, Network Component developers should coordinate and consult with ASTP to align standards and adoption efforts.
Standard / Specification: HL7® FHIR® UDAP Security for Scalable Registration, Authentication, and Authorization (SSRAA IG)| Standard Process Maturity: Balloted | Implementation Maturity: Balloted |
|---|
- Implementation specification that describes the extension of OAuth 2.0 to standardize and automate the application registration process using digital certificates and to authenticate participants securely within health information networks. This specification is compatible with SMART App Launch IG and the security requirements for Bulk IG.
- While there are multiple versions of SSRAA IG, ONC regulations identify SSRAA IG Version 1.0.0 as the most ready for adoption in certified health IT. Its use is currently optional in TEFCA but is anticipated to be required in the future.
- SSRAA IG provides a standardized approach for the dynamic registration of applications via use of secure FHIR APIs. It should be considered for use cases where there is a need to support “scalable” trust among participants that agree to abide by common policies, thereby forgoing the need for individual agreements between organizations to establish trust.
- We anticipate SSRAA IG to mature based on TEFCA implementation experience.
|
HL7® FHIR® based Payment and Health Quality specifications have been developed to reduce reporting burden for clinicians, caregivers, patients, and payers. The components specified below are largely those that have been developed through the Da Vinci Project HL7 FHIR Accelerator, revolving around capabilities that enable claims data exchange. Given this focus, we encourage agencies working in this space to involve CMS as a partner.
Standard / Specification: HL7® FHIR® Da Vinci Payer Data Exchange (PDex) Implementation Guide (PDex IG)| Standard Process Maturity: Balloted | Implementation Maturity: Pilot |
|---|
- Implementation specification for Payers and Health Plans to enable them to create a Member’s Health History using clinical resources (based on US Core IG) which can be understood by providers and committed to their EHR.
- While there are multiple versions of PDex IG, ONC and CMS regulations have identified PDex IG Version 2.0 as most ready for adoption in certified health IT.
- The PDex IG has both payer and provider components, allowing providers to make more timely and informed treatment decisions that will result in better adherence and quality of care for patients. The IG was developed by the Da Vinci Project Accelerator and is available for implementation without any licensing requirements.
- PDex IG should be considered for use cases that require payers and providers to exchange clinical information and to enable patient access to clinical information from their payers.
|
Standard / Specification: HL7® FHIR® Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) Implementation Guide| Standard Process Maturity: Multiple balloted versions available | Implementation Maturity: Pilot |
|---|
- Implementation specification for payers to support patient access to their claims information via a standardized FHIR API. It also describes the Common Payer Consumer Data Set (CPCDS), which provides a set of FHIR Resources that payers can provide to patients via FHIR.
- While there are multiple versions of CARIN IG for Blue Button, ONC and CMS regulations identify CARIN IG for Blue Button Version 2.0.0 as most ready for adoption in certified health IT.
- The IG was developed by the Da Vinci Project Accelerator and is available for implementation without any licensing requirements.
- CARIN IG for Blue Button should be considered by payers for use cases that require payers to enable patient access to claims information from payers.
|
Standard / Specification: HL7® FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide| Standard Process Maturity: Balloted | Implementation Maturity: Pilot |
|---|
- Implementation specification for payers to provide information about coverage requirements required by payers to facilitate treatment decisions based on a patient’s insurance coverage. This is an important component of standardizing API-based electronic prior authorization workflows that aim to reduce patient treatment delays and provider burden.
- While there are multiple versions of CRD IG, ONC and CMS regulations identify CRD IG Version 2.0.1 as most ready for adoption in certified health IT.
- The IG was developed by the Da Vinci Project Accelerator and is available for implementation without any licensing requirements.
- CRD IG should be considered by payers and providers to streamline the prior authorization process and reduce administrative burden on health care providers and payers associated with assembling and reviewing required documentation.
|
Standard / Specification: HL7® FHIR® Da Vinci—Documentation Templates and Rules (DTR) Implementation Guide| Standard Process Maturity: Balloted | Implementation Maturity: Pilot |
|---|
- Implementation specification for payers to express documentation requirements and provider-context rules and for providers to be able to submit the necessary documentation automatically via FHIR APIs. This is an important component of standardizing API-based electronic prior authorization workflows that aim to reduce patient treatment delays and provider burden.
- While there are multiple versions of DTR IG, ONC and CMS regulations identify DTR IG Version 2.0.1 as most ready for adoption in certified health IT.
- The IG was developed by the HL7® Da Vinci Project and is available for implementation without any licensing requirements.
- DTR IG should be considered by payers and providers to streamline the prior authorization process and reducing administrative burden on health care providers and payers associate with submitting required documentation.
|
Standard / Specification: HL7® FHIR® Da Vinci—Prior Authorization Support (PAS) FHIR IG| Standard Process Maturity: Balloted | Implementation Maturity: Pilot |
|---|
- Implementation specification that enables payer and provider health IT systems to support capabilities related to submission, receipt, and response to an electronic prior authorization request.
- This is an important component of standardizing API-based electronic prior authorization workflows; together with CRD and DTR IGs, it aims to reduce patient treatment delays and provider burden.
- While there are multiple versions of PAS IG, ONC and CMS regulations identify PAS IG Version 2.0.1 as most ready for adoption in certified health IT.
- The IG was developed by the Da Vinci Project Accelerator and is available for implementation without any licensing requirements.
|
Standard / Specification: HL7® FHIR® Da Vinci—Payer Data Exchange (PDex) US Drug Formulary Implementation Guide| Standard Process Maturity: Balloted | Implementation Maturity: Pilot |
|---|
- Implementation specification for payer health IT systems to provide their drug formulary information to patients via a FHIR API. The specification includes the exchange of formulary data that is integrated with protected health information (PHI) or personally identifiable information (PII) to enable a payer to provide personalized information to a patient based on their medication. Additionally, this IG supports the exchange of formulary data that is publicly accessible, and which does not contain PHI or PII, via a FHIR API.
- While there are multiple versions of PDex Drug Formulary IG, ONC and CMS regulations identify PDex Drug Formulary IG Version 2.0.1 as most ready for adoption in certified health IT.
- The IG was developed by the Da Vinci Project Accelerator and is available for implementation without any licensing requirements.
- Providing patients access to a payer’s drug formulary information using FHIR APIs will allow patients to find alternatives to reduce their medication costs, easily comparison-shop between plans, and help insurers educate consumers about the differences between various drug tiers and pharmacy benefit types.
|
Standard / Specification: HL7® FHIR® Da Vinci Payer Data Exchange (PDex) Plan Net Implementation Guide| Standard Process Maturity: Balloted | Implementation Maturity: Pilot |
|---|
- Implementation specification for payer health IT systems to publish information regarding their insurance plans, providers, and the organizations that participate in their network, and the associated networks, via a FHIR API.
- For beneficiary coverage and clinical information to be both useful to and utilized by patients and providers, it is necessary for patients to understand which providers, facilities, and pharmacies are covered by their health care insurance plan. Using this IG, third parties can develop applications that enable patients and providers to lookup the participants in a payer’s network that may provide requested or needed health care services.
- While there are multiple versions of PDex Plan Net IG, ONC and CMS regulations identify Pdex Plan Net IG Version 1.1.0 as most ready for adoption in certified health IT.
- The IG was developed by the Da Vinci Project Accelerator and is available for implementation without any licensing requirements.
|
Standard / Specification: HL7® FHIR® Quality Improvement Core (QI-Core) Implementation Guide| Standard Process Maturity: Multiple balloted versions available | Standard Process Maturity: Production |
|---|
- Implementation specification that provides requirements and guidance for using FHIR in quality measurement and decision support.
- The QI-Core Profiles derive from FHIR Resources described in US Core IG and provide a standardized data set across US different quality measures.
- Each annual version of QI-Core builds on the respective version of US Core IG, which in turn addresses updated versions of USCDI.
- While this specification is not currently required in regulation, QI-Core IG Version 7.0.0 represents a reasonable starting point for health IT developers and the broader quality improvement community who are interested in leveraging FHIR for quality-focused applications.
|
Care Delivery and Engagement specifications based on HL7® FHIR® seek to ease patients’ access to their health data and to the healthcare system. They also seek to reduce provider burden and assist providers in areas such as decision support. Relevant agencies working in this space include CMS, HRSA, and CDC.
Standard / Specification: HL7® FHIR® SMART Health Cards: Vaccination and Testing Implementation Guide| Standard Process Maturity: In Development | Implementation Maturity: Pilot |
|---|
- Implementation specification that uses the SMART Health Cards framework for the issuance of verifiable health records for vaccination status and infectious disease-related laboratory testing that are structured as FHIR Resources.
- The SMART Health Cards framework and FHIR standard enables patients to keep a copy of their vaccination status, such as for COVID-19, on hand and to share with others as they choose.
- ONC regulation identifies SMART Health Cards: Vaccination and Testing IG Version 1.0.0 as most ready for adoption in certified health IT.
|
Standard / Specification: HL7® FHIR® International Patient Access Implementation Guide (IPA IG)| Standard Process Maturity: Balloted | Implementation Maturity: Pilot |
|---|
- Implementation specification that enables third party applications to access health information using FHIR APIs across countries.
- This specification aims to promote greater consistency across a growing number of countries for multinational applications and FHIR servers. It provides a consistent authorization based on SMART App Launch IG and a common set of FHIR Profiles that are a result of analysis of existing national base profiles.
- While this specification has not yet been implemented at scale in the United States, it represents a reasonable starting point for regulators and national specification authors who are interested in developing a national health API ecosystem.
- We anticipate that the IPA IG to become more mature based on experience gained from implementation.
|
Standard / Specification: HL7® FHIR® International Patient Summary Implementation Guide (IPS FHIR IG)| Standard Process Maturity: Balloted | Implementation Maturity: Pilot |
|---|
- Implementation specification that defines an interoperable set of FHIR Resources, containing a patient summary, for sharing by patients and clinicians primarily across countries. The FHIR Resources are based on US Core IG that use well defined international terminologies.
- Many European countries and members of the Global Digital Health Partnership are piloting IPS FHIR IG and have declared their intentions for adopting the specification for projects within their countries.
- While the specification is still early in its adoption, it represents a reasonable starting point for use cases that require cross-border data sharing and when paired with IPA IG, will enable an incredible environment for digital innovation in health care.
|
Standard / Specification: HL7® FHIR® At-Home In-Vitro Test Report Implementation Guide| Standard Process Maturity: Balloted | Implementation Maturity: Pilot |
|---|
- Implementation specification that constrains the Resources in US Core IG to support the data needs for use in transmitting at-home in-vitro test results to downstream health systems, including public health systems. This specification addresses the data harmonization requirements for mobile applications that support COVID-19 self-tests.
- Currently, hubs where test results can be sent, and subsequently routed to state and federal public health systems, do not support FHIR-based data exchange. It is expected that these hubs will support FHIR-based data exchange in the future. Longer term, the intent is to leverage FHIR for reporting to public health systems.
- The At-Home In-Vitro Test Report IG version 1.0.0 has been balloted and is a “framework” for future reporting of self-test results into electronic health record (EHR) systems.
|
Public Health and Emergency Response HL7® FHIR® specifications seek to modernize public health data and infrastructure. Given its responsibility involving public health, CDC needs must play a role in development of new FHIR capabilities in this area.
Standard / Specification: HL7® FHIR® Implementation Guide: Electronic Case Reporting Implementation Guide (eCR IG)| Standard Process Maturity: Balloted | Implementation Maturity: Pilot |
|---|
- Implementation specification to support case data and bidirectional communications of public health information in the context of a patient’s condition and local disease trends. The Public Health Data Strategy prioritizes electronic case reporting as an important automation that reduces burden and encourages more complete and timely data exchange.
- eCR IG enables the use of FHIR-based solutions that are aligned with FHIR R4 and US Core IG, for the transmission of electronic case reports and reportability responses, as well as the ability to consume and process electronic case reporting trigger cores based on a match from the Reportable Conditions Trigger Code (RCTC) value set specified in eCR IG.
- While there are multiple versions of eCR IG, ONC regulations identify eCR IG Version 2.1.0 as most ready for adoption in certified health IT.
|
Standard / Specification: HL7® FHIR® Central Cancer Registry Reporting Content Implementation Guide| Standard Process Maturity: In Development | Implementation Maturity: Pilot |
|---|
- Implementation specification that identifies FHIR Resources reporting on diagnosed cases of cancer, treatments, and demographics information from EHRs to central cancer registries.
- Cancer reporting is an important, mandatory component of cancer control efforts in the United States. Such information informs interventions and helps allocate resources in communities and populations affected by high rates of cancer.
- This specification provides a FHIR-based method to serve as an alternative to the CDA-based method that has been previously required by ONC regulations.
- While the specification is still early in its adoption, ONC regulations identify FHIR Central Cancer Registry Reporting Content IG Version 1.0.0 as most ready for adoption in certified health IT.
|
Standard / Specification: HL7® FHIR® Cancer Pathology Data Sharing Implementation Guide| Standard Process Maturity: Balloted | Implementation Maturity: Pilot |
|---|
- Implementation specification using FHIR to create and transmit cancer pathology laboratory values and results to central cancer registries.
- Cancer pathology reporting is an important component of diagnosing cancer and understanding how advanced cases are at the point of diagnosis. Early results of pilots have demonstrated that use of the IG would reduce the need for manual intervention and data cleansing, aid in more timely reporting, and include data elements that are important for public health action.
- While the specification is still early in its adoption, ONC and CDC identify the FHIR Cancer Pathology Data Sharing IG Version 1.0.0 as most ready for adoption in certified health IT.
|
Standard / Specification: HL7® FHIR® Vital Records Birth and Fetal Death Reporting BFDR) Implementation Guide| Standard Process Maturity: Balloted | Implementation Maturity: None |
|---|
- Implementation specification that defines FHIR resources that represent content used for reporting birth and fetal death information to state electronic birth registration systems (EBRS).
- This specification has been developed to automate the manual and duplicative process of entering the required information dually into EHRs and then the state EBRS.
- The specification has undergone the formal ballot process to make important updates, including ensuring inclusion of race and ethnicity, but it has not yet been piloted or widely implemented.
- ONC and CDC identify that Vital Records BFDR IG Version 1.1.0 as most ready for consideration by health IT developers that are interested in leveraging a FHIR standard approach for transmitting data in an automated manner in conjunction with SMART App Launch IG instead of reporting manually.
|
Standard / Specification: HL7® FHIR® Health Care Surveys Content Implementation Guide| Standard Process Maturity: In Development | Implementation Maturity: Pilot |
|---|
- Implementation specification for using FHIR Resources to electronically capture and send survey data to public health agencies that provides information on healthcare utilization and includes information related to symptoms, diagnoses, and procedures. These surveys cover a broad spectrum of healthcare settings.
- This specification has been developed to automate the manual process of submitting surveys, allowing for wider representation from hospitals and healthcare organizations, as well as reduce manual burden on the reporters.
- The specification has undergone the formal ballot process, but it has not yet been piloted nor widely implemented.
- ONC and CDC identify Health Care Surveys Content Guide Version 1.0.0 as most ready for consideration by health IT developers who are interested in leveraging a FHIR standard approach for transmitting healthcare survey data in an automated manner instead of reporting manually.
|
Standard / Specification: HL7® FHIR® US Public Health Profiles Library Implementation Guide (USPHPL IG)| Standard Process Maturity: Balloted | Implementation Maturity: Pilot |
|---|
- Implementation specification that defines FHIR Resources that represent a public health-specific data set of common data elements necessary to support core public health exchange use cases.
- The FHIR Resources specified in USPHPL IG, together with US Core IG, support complex data exchange options including more granular data exchange of patient data and will reduce burden of implementation and maintenance for data exchange between and among healthcare organizations and public health agencies.
- ONC and CDC identify that some of the FHIR Resources in USPHPL IG Version 1.0.0 are most ready for consideration by health IT developers that are interested in leveraging a FHIR standard approach for transmitting data in an automated manner in conjunction with SMART App Launch IG instead of reporting manually
|
Research specifications are intended to drive toward a fully digital health system that uses HL7® FHIR® for research activities. Research is inherently an open-ended subject area that could have multiple downstream effects. NIH, its component institutes, and FDA are among the HHS agencies that will have significant input into how FHIR capabilities are developed for optimal future implementation and use.
Standard / Specification: HL7® FHIR® mCODE (minimal Common Oncology Data Elements) Implementation Guide (mCODE IG)| Standard Process Maturity: In Development | Implementation Maturity: None |
|---|
- Implementation Guide that consists of FHIR resources for oncology related health care and research.
- It is anticipated that mCODE IG will serve as the base for future IGs, such as the Enhancing Oncology Model that has been published to support collecting data elements for the alternative payment model developed by the Center for Medicare and Medicaid Innovation (CMMI).
- mCODE IG is a step toward capturing a core set of structured data elements from the treatment of all cancer patients and facilitates data sharing between oncology information systems and other health IT systems.
- ONC, CMS and the National Cancer Institute (NCI) identify mCODE IG Version 4.0.0 as most ready for consideration by health IT developers and the standards community who are interested in capturing research-quality data and increasing interoperability for oncology electronic health records.
|
Standard / Specification: HL7® FHIR® Genomics Reporting Implementation Guide (Genomics Reporting IG)| Standard Process Maturity: Balloted | Implementation Maturity: Pilot |
|---|
- Implementation specification for reporting genomic data in an interoperable manner using FHIR standard.
- Genomic variations are an important area in healthcare and can affect a patient’s health outcomes. The Genomics Reporting IG covers many aspects of genomic data reporting and has been piloted by the ONC led Sync for Genes program.
- While the specification is still early in its adoption, ONC identifies Genomics Reporting IG, Version 2.0.0 as most ready for consideration by health IT developers who are supporting use cases that require the integration of genomic data with other health data.
|
Submitted by blakenan on
Unrelated to content - Edit of existing comment throws errors
Not sure if this is appropriate for this feedback mechanism, but thought it should be pointed out. Anytime an existing comment is edited, series of cryptic errors are displayed to the user. All seem to center around a custom integration with Jira. Please see attached screen shot for details.
Screenshot 2024-10-16 at 10.46.12 AM.pdf