FHIR Ecosystem

Include Health Care Clearinghouses as Partners

About the Cooperative Exchange

As representatives of the healthcare clearinghouse industry, we at The Cooperative Exchange are committed to promoting standardization and administrative simplification within the healthcare ecosystem. Our association comprises 23 member companies, collectively representing over 90% of the nation’s clearinghouse organizations. Together, we process over 6 billion healthcare claims annually, reflecting more than 2 trillion dollars in billed services.

The draft Federal FHIR Action Plan, in the section on Vision for 2026, sets out an ambitious vision for the Federal Government.  That vision talks about a number of entities in health care – patients, providers, plans, public health agencies.  However, the vision leaves out a key player – clearinghouses.  Our members play a key role in supporting both plans and providers in their interoperability pathway.

Cooperative Exchange’s Position on FHIR APIs

The Cooperative Exchange fully supports the goal of Fast Healthcare Interoperability Resources (FHIR). We believe that building reusable components that enable real-time transactions and bi-directional conversations between payers and providers at the point of care will improve the healthcare system. Our aim is to achieve this while minimizing industry burden.  We support implementing FHIR for administrative transactions that are not already working at scale and that are best suited to benefit from real-time data exchange, and then systematically updating currently scaled administrative transactions to FHIR as appropriate for each unique use case. We recommend that ASTP work with X12 as well as HL7 to develop FHIR administrative transactions for real-time data exchange.  X12’s vast experience within the administrative transaction space will be vital to ensuring the industry has FHIR standards that work in our current ecosystem. 

The Cooperative Exchange is interested in providing expertise to Federal Agencies in the business processes necessary to make FHIR-based exchanges successful. The following is how intermediaries, in partnership with the Cooperative Exchange, may be able to help implement FHIR at scale:

•            Many mid-size to small payers and providers have opted to use a technology partner to  create or maintain necessary connections to entities with which they exchange data. These organizations frequently cite a preference to outsource that expertise, gaining instant and streamlined access to many diverse connections rather than growing that network in house. While we realize that there will be diverse approaches to implementing the FHIR APIs, clearinghouses will continue to simplify the technical approach for both parties. We feel that as standards and models are developed for implementing FHIR, there should be equal consideration given to provider-to-clearinghouse-payer models as there currently is to provider-to-payer models.

•            FHIR implementation guides do not take into consideration intermediaries, which currently manage administrative traffic for provider and payer organizations, as a significant technology partner for providers and payers. As a stakeholder, we would like the opportunity to offer our recommendations to these guides. 

•            For years, intermediaries have been connecting to various systems and are familiar with the variability and challenges that come along with it. Considering that CMS has announced their plan to build an endpoint directory, we’d like to learn more and be a part of how this type of information is organized and communicated.

•            There is an opportunity to better illustrate how FHIR would operate in the real world, where systems would need to accommodate many-to-many connections concurrently. We propose a collaboration in which intermediaries can assist with building use cases and complex workflows to show successful data interchange through intermediaries.

We suggest that the plan include working with the Cooperative Exchange and our members to achieve its vision.

Public Health & Emergency Response Components

Here are the comments towards the 'Public Health & Emergency Response Components' that Washington State Department of Health recommends for consideration:

• US Situational Awareness Framework for Reporting (SAFR) FHIR IG (currently under development):  The implementation guide is being developed as a framework for the US Situational Awareness capabilities during emergencies and is constrained from Situational Awareness for Novel Epidemic Response (SANER) FHIR IG. The SAFR FHIR IG is recommended to be used referencing to and interacting with the FHIR Measures computational libraries of situational awareness measures relevant to the profiles in the IG VIZ. currently 'Bed Capacity' and 'Hospital Respiratory Data' (HRD) profiles. 
• Childhood development milestones assessment framework: Assessment and Long Term Follow UP (LTFU) of development milestone and hence recording delays in the milestones including those conditions listed in Newborn Screening, that are identified as caused due to metabolic and congenital etiologies are currently not included in the action plan. The assessment may be done with the use of FHIR Structured Data Capture (SDC) IG and harmonized with the Healthcare Surveys IG. 

Research Components

Its exciting to see on the roadmap for further development around research study data, including but not limited to cancer specific data. The third party vendors we exchange research data with from our healthcare EMR use legacy protocols with very limited functionality. It lacks the modularity available with FHIR resources leading to a clunky implementation for exchanging data. 

There has also been a need for custom development to exchange the needed cancer related data between software systems currently in use that we've been hoping could eventually be replaced by using FHIR/USCDI standards.

Standard / Specification: HL7® FHIR® Subscriptions R5 Backport

Continued development of this standard is promising and applauded, In current state with version R4 we don't see developers using this functionality but can see where it could provide the following benefits:

• Improved Data Synchronization: By notifying requesting systems proactively about data changes, the system ensures that clinical data remains synchronized in real-time. This can lead to better decision-making and improved patient outcomes by providing accurate and up-to-date information when needed.
• Reduced API Call Load: Implementing this subscription-based model could significantly reduce the need for repetitive API polling by requesting systems. This minimizes the strain on IT infrastructure, leading to more efficient use of resources and potentially lower operational costs.

Research Components

1. Research would benefit from leveraging the volumes of great work done through the NIH NCI EVS team to curate and maintain controlled terminology for clinical research. This terminology was developed with the CDISC community and is required by FDA and Japan’s PMDA. This body of knowledge has been available since 2008 and has been growing each year, now supporting foundational research needs as well as over 50 therapeutic areas. The terminology was developed through a consensus-based process involving thousands of volunteers from a variety of different organizations around the world to supports research from protocol and data collection through data tabulation, analysis and reporting. These standards are harmonized globally to be synergistic.  It would save significant time and cost to start with this controlled terminology to support research with USCDI and US Core.
2. Connecting previously defined data elements for research (as developed by the CDISC community) and their codes within the NCI EVS Metathesaurus to the healthcare coding systems, codes, and labels (aka healthcare terminology) will streamline the path to using FHIR and to achieving interoperability.
3. In the “FHIR Ecosystem” web page, https://www.healthit.gov/isp/fhir-ecosystem, under the “Care Delivery and Engagement Component” gray bar, the first bullet under “IPS FHIR IG”, – mentions that the FHIR Resources are based on US Core FHIR IG that use well defined international terminologies. This is not correct. The IPS is based on the base FHIR specification (FHIR R4). The US would benefit from aligning the terminologies in the US Core IG to the IPS FHIR IG in addition to the IPA FHIR IG. SNOMED has a US based version. Would it be possible to use the SNOMED International version since this will facilitate global data exchange? There are LOINC codes in the US Core FHIR IG terminologies and many options to choose from for valuesets. In contrast, the IPS FHIR IG valuesets are narrower with specified code systems and codes that will enable data exchange without loss of meaning.  

                                         Aligning with IPS FHIR IG and IPA FHIR IG will enable global interoperability and sharing of health information to enable patient care and secondary use of data.  

4. Currently the only documents mentioned in the draft Federal FHIR Action Plan are the mCode IG and the Genomics Reporting IG.  We recommend adding the following Vulcan FHIR IGs in support of research, there may be additional public health IGs that would be beneficial to highlight.  

• Retrieval of Real World Data for Clinical Research  (Link to Webpage - Real World Data) 
• Adverse Event Clinical Research R4 Backport  (Link to Webpage - Adverse Event Clinical Research R4 Backport)  
• Adverse Event Clinical Research  (Link to Webpage - Adverse Event Clinical Research)  
• Clinical Study Schedule of Activities  (Link to Webpage - Clinical Study Schedule of Activities)  
• FHIR to CDISC Joint Mapping IG   (FHIR to CDISC Joint Mapping IG (Vulcan)) ; (FHIR to CDISC Joint Mapping IG (CDISC))

Submitted by:
Catalysis (Rebecca D. Kush, PhD), CDISC (Rebecca Baker, MS, MHA, BSN, RN), and Piosoft (Filippo Napoli, PMP)
 

Public Health and Emergency Response Components

HL7 FHIR Electronic Case Reporting IG (eCR IG) is noted as pilot. There is an opportunity for leveraging these data elements to align case reports with the CDISC standards case report forms that are used in both public health and pharma trials by NIH centers, CROs, and researchers around the world. They are built into RedCap and OpenClinica, and the specifications are available on the CDISC website for other vendors to use. This would enable data aggregation more efficiently.  Such forms could be used with IHE RFD as mentioned previously.  CDISC has worked with NIH and others on standards for different Therapeutic Areas and sample case report forms have been provided for Ebola, Vaccines, Virology, COVID-19 and others including Oncology (various types of cancers), Asthma and Alzheimer’s and Parkinsons’ Diseases. The work was done through the Coalition For Accelerating Standards and Therapies (CFAST) with many different organizations and SMEs including CPath, FDA, NIH, CDISC, TransCelerate and Oxford. These standards and their terminology are required by FDA for submissions of data to support the approval of new therapies.  Why would these not be leveraged as a starting point to accelerate the development and adoption of FHIR for research?

Healthcare IT facilities must comply with both ethical and IT regulations. When exchanging data with external facilities, it is standard practice to disclose the security standards and procedures used to protect that data and to require the receiving party to adhere to the same basic standards for safeguarding patient information. This practice is legitimate, with the HIPAA BAA agreement serving as the typical framework for such stipulations. An End-User License Agreement (EULA) can be presented online to users, and their responses can be captured and stored electronically.

Submitted by:
Catalysis (Rebecca D. Kush, PhD), CDISC (Rebecca Baker, MS, MHA, BSN, RN), and Piosoft (Filippo Napoli, PMP)

Care Delivery and Engagement Components

The term "Information Blocking" refers to any interference with the access, exchange, or use of electronic health information, making it a broad and inclusive concept. Within the "Consequences and Enforcement" section, it notes the potential for "civil monetary penalties of up to $1 million per violation." A suggestion would be to implement a minimum penalty for first offenses to enhance deterrence for potential violators. For instance, penalties could be structured to begin at $5,000, escalating to a maximum of $1 million per violation, thereby reinforcing the seriousness of compliance from the outset. This stepwise payment structure for offences will help with the education process in the event of unintentional “information blocking” occurrences.

The primary concern regarding the ASTP's policing approach is whether it differentiates between users who are knowingly blocking information for nefarious reasons and those who are unintentionally unable to share data, such as in cases of technical defects that lead to APIs returning blank data. In both instances, the information is effectively blocked. However, without a clear definition of the active role played by users in intentionally blocking data access or sharing, addressing these issues downstream after a complaint has been filed may prove challenging. Additionally, the ASTP should establish reasonable and customary expectations on timeliness. An example is onboarding timelines related to EHR integration with third parties for data sharing, as delays in this process could also be viewed as a form of information blocking.

Submitted by:
Catalysis (Rebecca D. Kush, PhD), CDISC (Rebecca Baker, MS, MHA, BSN, RN), and Piosoft (Filippo Napoli, PMP)

Payment and Health Quality Components

Leveraging other standards work such as that done by ISO, IEEE, OMG, IHE, openEHR, and CDISC to solve the interoperability puzzle will make the work go faster. There has been work done in several spaces such as IHE RFD (used for any form to populate data from the EHR, including Quality data); this work could be updated to use FHIR, and the work can be connected and leveraged in each area for everyone’s benefit. Otherwise, completing this work anew will take substantially more time. Additionally, there are other beneficial HL7 standards still in use (such as CDA). Connecting these and having them fit together and providing the ability to go back and forth between the different data models will yield great benefits. In addition to these standards, the various data models such as OMOP, i2b2/ACT, CDISC SDTM provide another level or layer of data in a different view. See Figure 1 at the end of document. 

Recommend consistent data transformations used standardly to increase the data quality and enhance the data reusability strengthening the meaning and reliability of transformed data.

Submitted by:
Catalysis (Rebecca D. Kush, PhD), CDISC (Rebecca Baker, MS, MHA, BSN, RN), and Piosoft (Filippo Napoli, PMP)

Network Components

To address the challenges faced by API users in connecting with multiple healthcare providers, we propose the establishment of a centralized onboarding facility. This facility would streamline the process by onboarding new users, vetting them, and assigning unique IDs, thereby eliminating the need for individual API integrations with multiple EHR systems. By creating a single point of access, users would gain inherent connectivity to all approved EHRs. This centralized facility can be likened to a “Google Password Manager” service, acting as a secure and trusted gateway that provides API users, with a “single login”, access to a wide range of EHR systems through one seamless onboarding process, eliminating the current multiple login process.

Submitted by:
Catalysis (Rebecca D. Kush, PhD), CDISC (Rebecca Baker, MS, MHA, BSN, RN), and Piosoft (Filippo Napoli, PMP)

Core Components

Core Components

We applaud the efforts to leverage and harmonize the standards to benefit health and human services. The Action Plan states the FHIR standard will be essential, and we agree this is a good start. However, leveraging other available and applicable standards, particularly in the case of terminology, will move us all forward faster and perhaps better. Specifically, in the case of research standards, benefits and efficiencies have been proven over the past 25 years in a global research community, including NIH centers and FDA. These terminologies to support core data elements and data elements for over 50 therapeutic areas are mature and are maintained by NCI Enterprise Vocabulary Services. It is inefficient and will not enable interoperability to allow users a choice of terminologies.   To truly reach the goal in a reasonable timeframe, it will be important to leverage this past consensus-based work that is relevant to billions of patientsworldwide. Otherwise, it could very well take another 20 years to redo work that has already been done.

Submitted by:

Catalysis (Rebecca D. Kush, PhD), CDISC (Rebecca Baker, MS, MHA, BSN, RN), and Piosoft (Filippo Napoli, PMP)