Introduction to the FHIR Standard and CMS Rules

The growing level of technology in use today has drastically changed the way the healthcare industry works. Nowadays, health information systems face challenges like these:

• Implementing fast and standardized communication between subsystems in one system. This allows you to increase performance and shorten the time and costs of system improvements and support.

• The implementation of standardized communication between different systems for efficient healthcare data exchange.

• Providing API access to members to allow them to share medical data with new practitioners and track medical records using third-party applications like Apple’s Health.

• Providing integration with a wide number of EMRs systems to operate patients’ medical data from multiple sources.

In this article, we're going to get right down to the brass tacks of what is the FHIR standard, CMS rules, and corresponding FHIR Implementation Guides. This article will be useful for CTOs, CIOs, technical managers, and consultants in healthcare organizations and IT companies working with health information systems that face the necessity of meeting CMS rules or just want to start integration with FHIR. 

FHIR Standard

Before talking about the CMS rules, we need to understand what FHIR is and why it’s important for the modern healthcare industry.

The Fast Healthcare Interoperability Resource (FHIR) is an interoperability standard created by HL7 to facilitate the exchange of healthcare data between patients, healthcare providers, payers, researchers, and other members of the healthcare ecosystem. The standard is divided into two parts — content models in the form of FHIR resources and a specification for the exchange of the resources in the form of RESTful interfaces. HL7 built a base set of resources that satisfy the majority of common use cases.

FHIR Resources

Health data can be split into different categories, such as providers, patients, claims, encounters, and others. In FHIR, each of these categories is represented by an FHIR resource. It defines data elements, data types, constraints, and relationships with other resources. Each resource contains elements necessary for its specific use cases. E.g., the patient resource contains demographics, addresses, contact information, and a link to the primary care provider that is represented as a practitioner or an organization resource.

Resources define what inner elements are required to have values. But the biggest part of elements is optional to have values. This methodology helps to improve systems and version compatibility. Also, every resource and every element in a resource can have extension elements to represent additional information that is not part of the basic definition of the resource.

A fragment of the Patient FHIR resource in JSON format is displayed below:

{
  "resourceType" : "Patient",
  "id" : "2a947681-e2b5-45f5-924a-6fea5f7cc2a8",
  "meta" : {
    "lastUpdated" : "2022-10-30T09:58:01.8512764-05:00",
    "profile" : [
      "http://hl7.org/fhir/us/carin-bb/StructureDefinition/C4BB-Patient"
    ]
  },
  "language": "en-US",
  "identifier" : [
    {
      "type" : {
        "coding" : [
          {
            "system" : "http://terminology.hl7.org/CodeSystem/v2-0203",
            "code" : "MB",
            "display" : "Member Number"
          }
        ]
      },
      "system" : "https://www.healthplan.com/memberidentifier",
      "value" : "232162170257"
    }
  ],
  "active" : true,
  "name" : [
    {
      "family" : "Smith",
      "given" : [
        "John"
      ]
    }
  ],
  "telecom" : [
    {
      "system" : "phone",
      "value" : "4083358853",
      "rank" : 1
    },

The main attributes of this fragment are:

1. ID — FHIR identifier of a patient;
2. meta — metadata about the patient;
3. profile — link to the corresponding FHIR profile documentation page;
4. identifier — business identifiers of a patient, like a member number in the client’s system, Medicaid ID, or Medicare number;
5. name — a name associated with a patient;
6. telecom — a contact detail for a patient.

This fragment contains part of the patient’s demographics — name (first and last name) and phone. It also contains the patient’s identifier in the client’s system, as well as the FHIR resource type, FHIR identifier, and an active flag. Some of the attributes’ values are primitive data types, like ID or active. Others have a complex inner structure like identifier or name. Also, the inner attribute type in identifier has a CodeableConcept data type. This means that the value for this attribute was taken from the predefined Value set. 

FHIR Benefits

The FHIR standard provides certain benefits for all groups of people involved in health information systems. Let’s categorize and list these benefits. 

Benefits for Healthcare Payers and Providers

Data Management

FHIR is a standard for all types of medical data. It means that instead of having multiple systems with their own data storage and data access layers in one organization, there can be one FHIR platform that provides one data storage and unified access to this data. The FHIR standard has the benefit of increasing the system's performance and shortening the costs of the system's future improvements and support.

Data Integration

Using the FHIR standard will ease the process of integrating your health information system with EHR systems. This also has the added benefit of integrating with other medical data providers. It improves the data sharing between payers and providers. E.g., Open Epic provides an FHIR API that can be used for integrating with FHIR platforms. Also, FHIR API provided by an FHIR platform can be used by other systems to integrate with yours.  

Data Mining

Having all your medical data in one storage and in one format gives a great opportunity to integrate training AI/machine learning models into your system. This could then be used to benefit the patient's directly. For example, to diagnose a patient's condition based on vital signs and lab results and recommend the most effective healthcare procedures and medications. It also has the added benefit of reducing the financial burden on healthcare information systems by spotting where health resources are being misused.

All these benefits lead to improving the medical system and the range and quality of services. It means the increasing numbers of your clients and profits.

Benefits for Patients

Medical Data Sharing

The FHIR standard is empowering patients in ways of easing the process of sharing specific data with healthcare providers. Patients will have control over their information and how they are going to share it with the healthcare provider. E.g., a patient can visit a practitioner in a new clinic and provide him access to the previous medical records through a third-party application. This will increase the patient’s faith in the industry and will allow them to make good decisions about their treatment. 

Tracking Medical Records

FHIR is good for patients as it will allow them to track their medical records using any recommended healthcare app or software. They will get a clear-cut picture of their clinical data. For example, Apple’s Health app for iOS pulls the information of the patient from various EHRs and other health organizations using FHIR. Now, the patient can look into his/her data using the phone and have a full picture of the stats. 

For businesses, the benefits that their clients are receiving increases client satisfaction and loyalty, which in turn, leads to higher profits.

Benefits for Developers

Easy Implementation

FHIR uses many modern web technologies and standards that developers are already familiar with, such as HTTP, REST, XML, JSON, and OAuth. Also, the basic units of interoperability in FHIR — resources — are built from standard blocks and can easily be implemented.

Free To Use

FHIR standard is 100% accessible without any restrictions.

Specifications and Community

HL7 provides a concise and easily-understood online specification that can be used to implement FHIR. Also, FHIR is an open-source standard with a community of experts who offer the best solutions for complex problems. The expert team is glad to clarify possible issues in a short amount of time. 

For businesses, these benefits for developers mean the recusing time and costs of moving to the FHIR standard.

CMS Interoperability Rule

The Centers for Medicare & Medicaid Services (CMS) is the organization within the U.S. Department of Health and Human Services (HHS) that supervises the nation’s major healthcare programs. The CMS manages programs, including the Children's Health Insurance Program, Medicare, Medicaid, and the state and federal health insurance marketplaces. CMS gathers and analyses data and produces research reports.

If an organization is working with CMS, it should comply with the new CMS Interoperability and Patient Access final rule (CMS-9115-F). The main goal is to advance interoperability and patient access to health information. Starting July 1, 2021, health plans must share their provider directories, claims, formularies, encounters, and clinical data with their members.

The CMS rules describe what specific healthcare and financial data health plans should share with members within certain timeframes. Moreover, health plans must maintain HIPAA safeguards when sharing information with members. Finally, health plans should be able to send specific healthcare data to another payer at the request of the member.

The healthcare data can be shared with members via API. To make sure that different applications can work with the data that is shared, CMS prescribed a single format that all health plans’ APIs should use. This format is FHIR.

The table below contains the datasets that are needed to be shared with members:

Provider and pharmacy directories are publicly available information and do not require any additional security measures. Members’ claims and clinical data are considered Protected Health Information or PHI and need to be secured. Also, access to clinical data is needed to be provided only if it’s maintained by a health plan. 

Benefits of Following CMS Rules

Benefits for Patients

The CMS rules put patients at the center of their healthcare. It will increase data interoperability and provide the easiest way for patients to get access to their medical data. It will also allow patients to move from one provider to another without losing any piece of their medical data.

Benefits for Payers

Following CMS rules help payers to perform efficient and time-saving data exchange with other payers and benefits coordination or transition in a timely manner. It also helps healthcare providers to offer more coordinated and efficient care. This, in turn, provides a comprehensive picture of the patient's claims and encounters, and this data will help to inform the patient's choice of coverage options with the insurance provider. They can also easily understand the choice of healthcare providers available, allowing them to more effectively manage their patient's health, patient's care, and costs.

FHIR Implementation Guides

An FHIR Implementation Guide (IG) is a set of rules and requirements about ways of using FHIR resources to solve a specific problem, with associated documentation to support and clarify the usage. Basically, it’s a collection of FHIR resources, profiles, value sets, examples, and human-readable documentation. 

Healthcare payers and providers can implement additional functionality in their systems or even create new applications based on the integration of their medical data with FHIR using different FHIR IGs. The most common type of this functionality is providing access to a certain type of medical data to payer’s members or providers. The CMS rules require developers of these applications to use the SMART on FHIR security and app registration protocol to allow members to share their data only with the applications that they authorize. 

FHIR IGs have certain benefits for the implementation of the new functionalities:

• Having all medical data in one storage will reduce the number of queries and backend processing operations. FHIR provides a standard REST API and returns data in standard form. It leads to high performance and a short implementation time of the possible new functionality.

• The connections between FHIR resources were designed to optimize the data search. Also, the FHIR standard has the functionality to extract resources with all connected resources. It means that you can easily extract all information about patients, practitioners, or medications in one query. 

• FHIR standard provides a list of predefined search parameters. You don't need to worry about implementing basic search functionality.

• FHIR standard allows for the creation of custom search parameters that will improve the search functionality.

NB: Integration with any FHIR IG means only transferring medical data to the FHIR storage and providing API access to the data in the FHIR format. The additional functionality, like user portals, provider search, web UI, SMART on FHIR applications, etc., should be implemented separately.

Let’s take a look at the IG that should be used in the CMS rules.

1. DaVinci PDEX Plan Net IG

DaVinci PDEX Plan Net is used for storing provider directory data. This implementation guide defines an FHIR interface for insurance plans, associated networks, organizations, and providers that participate in these networks. FHIR-based API access to this data can be used by third parties to develop applications through which providers and members can query the participants in a payer’s networks. 

The following diagram provides a high-level view of the relationships between resources used in this IG:  

The table below contains FHIR resources that are used in this IG:

Use Case

Payers can improve their health information systems by integrating them with this FHIR IG to develop a provider search on their websites or mobile applications. Members can use this functionality to search through the payer’s provider network to find the most suitable provider. The provider search module can use FHIR REST API to send requests directly to the FHIR platform and receive all necessary data to display in the FHIR format.

2. DaVinci PDEX US Drug Formulary IG

DaVinci PDEX US Drug Formulary IG is used for storing data about medications and drug formularies. It defines an FHIR interface to a health insurer's drug formulary information for members. A drug formulary is a list of brand-name and generic prescription drugs a health insurer agrees to pay for, at least partially, as part of health insurance coverage. This FHIR interface can be used by members to understand the costs and alternatives for drugs that have been prescribed and to compare drug costs across different insurance plans. 

The following diagram provides a high-level view of the relationships between resources used in this IG: 

The table below contains FHIR resources that are used in this IG: 

Use Case

Payers can improve their health information systems using this FHIR IG by implementing a medication dashboard for their members. This dashboard will empower payer’s members by providing them with full information about payer’s drug formularies.

Using this dashboard, members can compare drug coverages of payer’s health plans. It will help them to find the best-estimated cost based on their interests. The dashboard will use FHIR API to query the list of plans and get the plan-level estimated costs specific to the consumer’s medication list from the FHIR storage.

Also, members can get the plan estimated costs for their medications in the current health plans. In this case, the dashboard will use FHIR API to query the cost information of the required medications and provide the estimated cost for each medication under the member’s current health plan.

3. CARIN IG

CARIN IG is used for storing data connected with patients’ Explanations of Benefits and coverages. This implementation guide describes the CARIN for Blue Button Framework and Common Payer Consumer Data Set (CPCDS), providing a set of resources that payers can display to consumers via an FHIR API to meet part of the CMS requirements related to the Patient Access API. This data can be used by third parties to develop applications through which members can get their claims data. 

The following diagram provides a high-level view of the relationships between resources used in this IG:  

The table below contains FHIR resources that are used in this IG: 

Use Case

The CARIN IG can be used by the providers of third-party applications to develop a members portal that provides access to the patient’s EOB data via SMART. This application can be used by patients to receive full information about their EOB data, such as services, providers, insurance coverages, and amounts. For payers, an application that provides useful access to this data can be a tool for collecting statistics and a platform for researching and analysis of medical data like LDA. 

4. US Core IG

US Core IG is used to store patients’ clinical data. This IG is based on FHIR Version R4 and defines the minimum set of constraints on the FHIR resources to create the US Core Profiles. FHIR-based API access to this data can be used by third parties to develop applications to get patients' data. 

The following diagram provides a high-level view of the relationships between some resources used in this IG: 

The table below contains FHIR resources that are used in this IG: 

Use Case

Payers, healthcare providers, and EHR systems can use this FHIR IG to improve their systems by providing access to the members to their clinical data. Each profile in the US Core IG has a corresponding data item in USCDI. It means that members can receive full information about their clinical records, including encounters, diagnoses, procedures, and so on. This access can be implemented by creating a patient dashboard in existing health information systems or developing separate user portals. 

The second usage of  US Core IG for Payers, healthcare providers, and EHR systems is creating a mechanism for exchanging clinical data between different systems. Also, health plans should be able to send members’ clinical data to other health plans at the request of the member (payer-to-payer data exchange). This interaction can be easily implemented if both the request system and the response system provide FHIR API based on this IG. 

And the third case is implementing deep research of the patient's health records using training AI/machine learning models. It will help providers to diagnose conditions based on the vital signs and lab results and to recommend the most effective healthcare procedures or medications that will increase the quality of healthcare services. 

Conclusion

To sum up, the FHIR standard is a powerful tool for implementing data exchange between members of a healthcare ecosystem. It covers all types of medical data and provides benefits for different groups of people involved in health information systems.

If an organization is working with CMS patients, it should be CMS-compliant. This means that it should share consistent medical data with its members via FHIR API according to the certain FHIR IGs. In this case, FHIR integration not only helps to follow the regulator's rules but also benefits healthcare payers and providers. They can use it to implement additional functionality in their systems and create new applications for improving the quality of the patient's services and therefore increasing profits. 

Glossary 

The terms and definitions used in the article are collected here for your convenience:

1. FHIR — the Fast Healthcare Interoperability Resource (FHIR) is an interoperability standard created by HL7 to facilitate the exchange of healthcare data between patients, healthcare providers, payers, researchers, and other members of the healthcare ecosystem. 
2. FHIR resource — FHIR representation of separate categories of medical data. Also, it’s the data packages used to send or receive data from an FHIR repository. 
3. Attributes —it's a set of common and resource-specific fields that are defined for each FHIR resource. 
4. IG — an implementation guide (IG) is a set of rules about how FHIR resources are used (or should be used) to solve a particular problem, with associated documentation to support and clarify the usage. 
5. FHIR profile — customized FHIR resource with additional constraints and/or extensions on the base resource used in Implementation Guides. 
6. CMS — the Centers for Medicare & Medicaid Services (CMS) is the organization within the U.S. Department of Health and Human Services (HHS) that supervises the nation’s major healthcare programs. 
7. EMR — Electronic medical records (EMRs) are a digital version of the paper charts in the clinician’s office. An EMR contains the medical and treatment history of the patients in one practice. 
8. Provider Directory — a listing of healthcare providers who have contracted with a healthcare carrier to provide care to its customers. 
9. Drug formulary — a drug formulary is a list of brand-name and generic prescription drugs that are approved to be prescribed by a particular health insurance policy or in a specific health system or hospital. 
10. Medical Claim — a request for payment that you or your healthcare provider submits to your health insurer when you get items or services you think are covered. 
11. Explanation of benefit — a statement from a health insurance plan describing what costs it will cover for medical care or products received by a patient. 
12. Clinical data — health-related information that is associated with regular patient care or as part of a clinical trial program. 
13. API — Application Programming Interface (API) is a set of definitions and protocols to build and integrate application software. 
14. HTTP — Hyper Text Transfer Protocol (HTTP) is the communications protocol used to connect to Web servers on the Internet. 
15. RESTful interface / REST API — an architectural style for an application program interface (API) that uses HTTP requests to access and use data. 
16. XML — Extensible Markup Language (XML) is a markup language and file format for storing, transmitting, and reconstructing arbitrary data. 
17. JSON — JavaScript Object Notation (JSON) is an open standard file format and data interchange format that uses human-readable text to store and transmit data objects. 
18. OAuth — Open Authorization (OAuth) is an open-standard authorization protocol that gives applications the ability to provide secure designated access. 
19. USCDI — the United States Core Data for Interoperability (USCDI) is a standardized set of health data classes and constituent data elements for nationwide, interoperable health information exchange. 
20. CPCDS — the Common Payer Consumer Data Set (CPCDS) is a standardized dataset that represents patients' claims data. 
21. Open Epic — an open API provided by EHR vendor Epic targeted at developers, more specifically at remote patient monitoring companies and health/wellness apps or portals. 
22. FHIR storage — storage of medical data where all data is represented in the FHIR standard. 
23. FHIR platform — an information system for receiving, processing, storing, and providing access to medical data in the FHIR standard. 
24. HIS — Health Information System (HIS) is a system designed to manage healthcare data, including collecting, storing, managing, and transmitting a patient’s electronic medical record, a hospital’s operational management, or a system supporting healthcare policy decisions. 
25. Data type— in FHIR, it's a characteristic of an attribute that describes a set of possible values and a set of allowed operations on it. 
26. Primitive data type — a set of basic data types from which all other data types are constructed. 
27. CodeableConcept — an attribute's data type that represents a value that is usually supplied by providing a reference to one or more terminologies or ontologies but may also be defined by the provision of text. 
28. Active flag — an attribute that shows whether a record is in active use. 
29. Code Systems define concepts and give them meaning through formal definitions, and assign codes that represent the concepts. 
30. Value Sets — a set of codes defined by code systems that can be used in a specific context. 
31. Training AI/machine learning models — software systems that are able to learn and adapt without following explicit instructions by using algorithms and statistical models to analyze and draw inferences from patterns in data. 
32. Payer’s provider network — a list of healthcare providers the payer contracts with, including individual providers, like physicians and advanced practice professionals, or organizations, like hospitals and health systems. 
33. SMART — Substitutable Medical Applications and Reusable Technologies (SMART) is an open-source, standards-based API that leverages the OAuth standard to provide secure, universal access to the patient’s EHRs. 
34. SMART on FHIR — a workflow that an application can use to securely request access to the patient’s data and then receive and use that data. 
35. Telehealth — use of digital information and communication technologies to access healthcare services remotely. 
36. LDA — Longitudinal Data Analysis (LDA) is the statistical tools and methods used to analyze the results of investigations where participant outcomes and possible treatments or exposures are collected at multiple follow-up times. 
37. HIPAA — the Health Insurance Portability and Accountability Act of 1996 (HIPAA) is a federal law that required the creation of national standards to protect sensitive patient health information from being disclosed without the patient’s consent or knowledge. 
38. PHI — Protected Health Information (PHI), also referred to as personal health information, is the demographic information, medical histories, test and laboratory results, mental health conditions, insurance information, and other data that a healthcare professional collects to identify an individual and determine appropriate care.