Blog Post

Healthcare and Life Sciences Blog
4 MIN READ

Supporting the CMS Interoperability and Patient Access Final Rules with the Azure API for FHIR

livaz's avatar
livaz
Icon for Microsoft rankMicrosoft
Jun 07, 2021

This article has been authored by Caitlin Voegele, Sr Program Manager, Microsoft Health & Life Sciences

 

On May 1, 2020, the Center for Medicare and Medicaid Services (CMS) announced the Interoperability and Patient Access final rule, which aims to help move the healthcare ecosystem towards interoperability. The Interoperability and Patient Access final rule requires free and secure data flow between all parties involved in patient care (patients, providers, and payers) to allow patients to access their health information when they need it. The Azure API for FHIR now has new features that will help our customers achieve compliance with this rule.  

Starting on July 1st, CMS regulated payers will need to meet the requirements for the Patient Access API and Provider Directory API. These APIs enable patients to easily access their claims and encounter data and find providers for specific care needs through third-party applications.  

 

The Patient Access API and Provider Directory API reference several HL7 Fast Healthcare Interoperability Resources (FHIR®) Implementation Guides, which set the context for how to use FHIR in a standard and consistent way. Below is a high-level overview of the various implementation guides:  

 

  • CARIN IG for Blue Button® - Payers are required to make patients’ claims and encounters data. This implementation guide provides a set of resources that payers can display to consumers via a FHIR API and includes the details required for claims data in the Interoperability and Patient Access API.  

 

  • HL7 FHIR Da Vinci PDex IG – Describes how payers can provide all relevant patient clinical data to meet the requirements for the Patient Access API. While this data may be available in FHIR format, it may also come from other systems in the format of claims data, HL7 V2 messages, and C-CDA documents.  

 

  • HL7 US Core IG - Backbone for the PDex implementation guide described above. 

 

  • HL7 FHIR Da Vinci - PDex US Drug Formulary IG - Part D Medicare Advantage plans have to make formulary information available via the Patient Access API. This implementation guide defines a FHIR interface to a health insurer’s drug formulary information, helping patients to understand if there are alternative drugs available besides one that has been prescribed to them and to compare drug costs. 

 

  • HL7 Da Vinci PDex Plan Network IG - Defines a FHIR interface to a health insurer’s insurance plans, their associated networks, and the organizations and providers that participate in these networks. 

 

Core technology available at your fingertips 

 

The Microsoft Azure API for FHIRwas released to general availability in November 2019 with support for FHIR R4, and Azure was the first cloud with a managed, enterprise-grade service for health data in the FHIR format. To help our customers achieve compliance and work through the requirements laid down by the regulation, we have developed a set of tutorials that outline how to configure the Azure API for FHIR to adhere to these implementation guides.  

 

The specific capabilities that the Azure API for FHIR supports are below: 

 

 

  • Total flexibility over what you can search in the system. The Azure API for FHIR supports the standard search parameters defined in the implementation guides along with allowing you to define your own search parameters 

 

  • Leverage industry profiles, or bring in your own profiles, to further define how data is stored and validate the data to ensure it confirms to the CMS context. While FHIR has been designed to drive interoperability, the context in which FHIR is used can have a big impact on how easily that interoperability can be achieved.  

 

  • Various FHIR operations called out in the CMS implementation guides. This includes the $member-match operation to assist in data sharing between payers and the Patient/$everything* operation to get all data related to a patient.  

 

* Some items are available now while others will roll out between now and the July 1st deadline. 

 

Use SMART on FHIR to connect to your FHIR server 

Once you have the Azure API for FHIR configured for the CMS mandate, you will need to be able to let SMART on FHIR applications from third-party developers access the data. The Azure API for FHIR has a SMART on FHIR proxy built in that can be enabled for basic SMART on FHIR scenarios. In addition, our health architects have developed a more robust FHIR proxy that can be extended for more complex scenarios.  

 

Flexibility to meet future mandates 

As a trusted partner in your journey towards making health data more accessible, Microsoft is committed to working with our customers to assist them not only in meeting the current CMS guidelines, but enabling future readiness for going beyond the baselines in order to unlock the potential of health data.  

 

The Azure API for FHIR has created the framework to continue to expand your FHIR server as the CMS mandate evolves, setting you up to meet the payer-to-payer requirement that recommends use of FHIR data starting January 1, 2022. As the proposed Interoperability and Prior Authorization rule is finalized, these tools can extend to that scenario as well. 

 

FHIR® is the registered trademark of HL7 and is used with the permission of HL7   

Updated Jun 07, 2021
Version 1.0
  • rmharrison's avatar
    rmharrison
    Copper Contributor

    livaz 

    Thanks so much to you, @CaitlinV39 and @SteveWohl for putting together the CMS guidance for configuring Azure FHIR.

     

    While technically correct, I'm afraid this statement will be misleading to business stakeholders new to FHIR.

    The Azure API for FHIR has a SMART on FHIR proxy built in that can be enabled for basic SMART on FHIR scenarios. In addition, our health architects have developed a more robust FHIR proxy that can be extended for more complex scenarios.

    The CMS patient access API requires the use of the SMART on FHIR stand alone launch sequence.
    * "Tutorial: Azure Active Directory SMART on FHIR proxy"only supports the EHR launch sequence.
    * For fhir-proxy, the SMART capability statement isn't listed in the README.md so I cannot tell at a glance whether stand-alone launch (launch-standalone) is supported (along with the other capabilities required for Patient Access). I already opened a ticket [link].
     
    Without a tutorial on SMART as it applies to the CMS rule (Patient Access API), the CMS tutorial is incomplete (even for an MVP).
     
    Secondarily, it may be unclear from this announcement that Azure FHIR is not an "out of the box" solution for CMS rule FHIR compliance; but rather, CMS compliant APIs can be built on-top of Azure FHIR. The tutorials lower the knowledge barrier of understanding the details of the IGs, but are by themselves insufficient.
  • SignalPoint's avatar
    SignalPoint
    Copper Contributor

    This seems like valuable and valid commentary. It is surprising there is no reply from Microsoft. I am being pushed into an AWS solution but want to understand the Azure options and this was interesting. I would have appreciated reading a response.

     

  • Hi,

     

    Thanks for your comment and for opening the ticket, we will look into that as well. Appreciate you sharing your thoughts. 

     

    The built in SMART Proxy in our service does not directly support the SMART scenarios in the ONC (g)(10) Standard API Certification. However, the fhir-proxy https://github.com/microsoft/fhir-proxy in concert with Azure Active Directory supports the following ONC (g)(10) test scenerios:

    1 Standalone Patient App - Full Access (Non-Session Scoping)

    2 Standalone Patient App - Limited Access (Non-Session Scoping)

     

    In addition, you are right that our service does not automatically give CMS compliance but only allows organizations to build on top of it in order to be compliant with CMS mandates. We provide the tools and support IG specified API calls (e.g.. $member-match) etc. but is not an out of the box solution.

     

    Hope this helps clarify!

  • fhirdev's avatar
    fhirdev
    Copper Contributor

    livaz, you mentioned the fhir-proxy with Azure AD supports the standalone limited access scenario for ONC g10 certification. I'm trying to implement this now, and have hit a snag:

     

    The Azure AD consent prompt is an all or nothing question (app asks user to consent to a list of permissions, user can either accept or deny all). The limited access scenario (g)(10)(v)(A)(10,11,12) seems to require that the user is presented a list of permissions with the ability to accept or deny each one. To my knowledge this is not possible using Azure AD.

     

    Has anyone successfully used this architecture to fully pass the certification tests for SMART on FHIR? Any suggestions?