What is CMS-0057-F? What does the Interoperability and Prior Authorization Rule impose? Who does it apply to? …
VNB Health Solutions
Healthcare IT Services and Solutions | VNB Health Solutions
Final CMS Interoperability Regulation – Summary
The Centers for Medicare & Medicaid Services (CMS) released the Interoperability & Patient Access Final Rule (CMS-9115-F) on March 9, 2020. Initially, the rule was expected to be announced during the HIMSS20 conference. The Final CMS Interoperability Regulation builds on top of MyHealthEData Initiative announced during the HIMSS18 conference and the 21st Century Cures Act.
Key Aspects of the Interoperability & Patient Access Final Rule
The Final CMS Interoperability Regulation focuses on a “Patient First” objective. The rule puts a stress on making patient health information easily accessible when in need. The rule also aims to drive more interoperability and data exchange across the entire healthcare ecosystem.
With this new Final CMS Interoperability Regulation, patients can get better access to their health information. They can always be informed of better care and better outcomes. The improved levels of interoperability between payers, providers and patients; and the data being readily available; the CMS aims to achieve better care, improved health outcomes and reduced costs of treatment.
The Final CMS Interoperability Regulation proposes 7 policies that will take the healthcare system forward to achieve higher levels of interoperability. These policies have certain levels of impact on payers and providers with strict timelines.
CMS Payer Policies
There are 4 new policies for both Medicare and Medicaid payer organizations; along with some implications for the providers.
| Policy | Policy Details | Additional Information | Compliance Date |
| Patient Access Through APIs | CMS regulated Payers should make Claims and Encounter Data readily available to patients through the use of a secure, standards based (HL7 FHIR Release 4.0.1) API. This API should meet the HHS standards that are established by ONC 21st Century Cures Act final rule. | The API should make available the following details –Adjudicated claims, remittances, cost share, encounter details along with clinical data, lab results, preferred drug list, and so on. Patients can access this information through any third-party application and integrate it to their EHR | January 1, 2021. According to the latest update (on April 21, 2020), CMS will not enforce this requirement until July 1, 2021. |
| API access to published provider directory data | CMS regulated Payers should make provider directory information publicly available through a FHIR-based Provider Directory API. | The API should provide the following details – names of providers, addresses, phone numbers and specialty. | January 1, 2021. According to the latest update (on April 21, 2020), CMS will not enforce this requirement until July 1, 2021. |
| Payer-to-Payer Data Exchange | CMS regulated Payers should exchange patient’s clinical data upon the patient’s request as they move from payer to payer to help create a cumulative health record with their current payer. | At a minimum, the data elements specified in United States Core Data for Interoperability (USCDI) v1 should be made available to the patients. Moreover, patients now have a cover of 5 years after the end of their coverage term to submit a request to a payer to share their information. | January 1, 2022 (no changes to this date) |
| Increased Frequency of federal-state data exchanges for dual eligible members | All the states should submit the Medicare and Medicaid enrollment information to CMS daily. Previously, it used to be weekly / monthly. | April 1, 2022 (no changes to this date) |
CMS Provider Policies
There are 3 new provider policies that apply to hospitals and physicians.
| Policy | Policy Details | Additional Information | Compliance Date |
| Public Reporting and Information Blocking | CMS will put up a public list of providers and clinicians who act as information blockers based on their attestation to CMS Promoting Interoperability (PI) Program or the MIPS program. | CMS will also put up an additional list of providers based on their performance in a way to promote the interoperability under the Merit-based Incentive Payment System (MIPS). | Late 2020 |
| Digital Contact Information | CMS will publish a list of names and National Provider Identifier (NPI) of the providers who do not have digital contact information. | The providers need to have the digital contact information included in the National Plan and Provider Enumeration System (NPPES) | Second Half of 2020 |
| Admission, Discharge and Transfer (ADT) Event Notifications | CMS is making modifications to Conditions of Participation (CoP) which requires hospitals to send electronic patient event notifications of the patient’s admission, discharge and transfer to another facility/provider/practitioner. | This event messaging system will help deliver improved care coordination and better patient outcome. | Fall 2020; Changed to Spring 2021. This rule is effective 12 months after the final rule is published in the Federal Register, which will be May 1, 2020. |
COVID-19 Challenge Brings Relief for Payers and Providers
The COVID-19 crisis has crippled the world economy to something that has never been witnessed before. The US Healthcare domain is no different! Healthcare providers and payers are facing an uncertain future in this pandemic situation.
CMS has acknowledged the seriousness of this situation, especially for hospitals (CAHs), and decided to extend the implementation of Admission, Discharge and Transfer (ADT) Event Notifications by 6 months (from Fall 2020 to Spring 2021).
ONC Final Rule
The Office of the National Coordinator for Health IT (ONC) also finalized technical, content and vocabulary standards in the 21st Century Cures Act Final Rule. The rule focuses on advancing interoperability by supporting the access, exchange, and use of electronic health information (EHI) and information blocking.
The ONC final rule identifies 8 exceptions when a healthcare actor will not be considered as an information blocker. These exceptions are divided into two categories –
Exceptions that involve not fulfilling requests to access, exchange, or use EHI
- Preventing Harm Exception
- Privacy Exception
- Security Exception
- Infeasibility Exception
- Health IT Performance Exception
Exceptions that involve procedures for fulfilling requests to access, exchange, or use EHI
- Content and Manner Exception
- Fees Exception
- Licensing Exception
ONC has finalized the transition from Common Clinical Data Set (CCDS) to the United States Core Data for Interoperability (USCDI). USCDI allows for a broader sharing of electronic health information to support patient care.
How VNB Health Can Help?
VNB Health can help payers and providers with best-in-class and easy-to-use interoperability solution. Our solution takes advantage of FHIR API in order to meet the CMS interoperability final rule requirements. As a HL7 Gold Member, VNB Health has been working on HL7 FHIR since its inception. We’ve built a variety of services by leveraging the power of Microsoft Cloud Platform and FHIR resources. Take advantage of our continuous innovation mindset to connect existing health data sources to new devices; and, generate actionable insights across all your health data.
Want to build your interoperability solution to meet the rules and regulations? Contact us to find out how we can help you with your interoperability needs.
Microsoft Azure FHIR API – Health Data in Cloud
What is Microsoft Azure FHIR API?
Microsoft’s Azure API for FHIR is an offering to connect existing data sources like electronic health record systems and research databases. This solution is a long standing need for a simplified data management with a single, consistent solution for protected health information (PHI) in the cloud. This is an onset for new opportunities with analytics, machine learning and actionable intelligence across an Healthcare enterprise’s health data.
Microsoft Azure FHIR API allows rapid exchange data in the HL7 FHIR standard format with a single, simplified data management solution for protected health information (PHI). It brings together health data from disparate systems using industry standard HL7 FHIR. This robust, extensible data model standardizes semantics and data exchange so all systems using FHIR can work together.
Microsoft Azure FHIR API helps relate points of data from across disparate systems to create richer datasets. Using these datasets we can enable advanced analytics scenarios that promote better health outcomes. Thereby we can connect people and health data in intelligent new ways across your infrastructure, productivity applications, business applications and analytics.
It allows to store your PHI data with confidence. Azure security isolates data and provides layered, in-depth defense and advanced threat protection that’s aligned to strict industry compliance standards. Azure covers more than 90 compliance certifications including ISO 27001 and meets HIPAA regulatory requirements.
The robust and extensible data model standardizes semantics and data exchange so all systems using FHIR can work together. Microsoft Azure FHIR API enables rapid exchange of data through Fast Healthcare Interoperability Resources (FHIR®) APIs, backed by a managed Platform-as-a Service (PaaS) offering in the cloud. It makes it easier for anyone working with health data to ingest, manage, and persist Protected Health Information PHI in the cloud.
Some of the detailed feature set of this service are as follows:
- Managed FHIR service, provisioned in the cloud in minutes
- Enterprise-grade, FHIR®-based endpoint in Azure for data access, and storage in FHIR® format
- High performance, low latency
- Secure management of Protected Health Data (PHI) in a compliant cloud environment
- SMART on FHIR for mobile and web implementations
- Control your own data at scale with Role-Based Access Control (RBAC)
- Audit log tracking for access, creation, modification, and reads within each data store
Overall, it allows one to create and deploy a FHIR service in just minutes to leverage the elastic scale of the cloud. We pay only for the throughput and storage we need. The Azure services that power the Azure FHIR API are designed for rapid performance no matter what size datasets you are managing.
Microsoft takes care of the ease of operations of a FHIR Server which takes on the operations, maintenance, updates, and compliance requirements in the PaaS offering. This is an enabler to free an enterprise’s own operational and development resources.
At VNB Health, we did a deep dive into Azure FHIR API. Below is the service blade in Azure in our dev environment.
Benefits and Highlights of Microsoft Azure FHIR API
Securely manage health data in the cloud
The Azure API for FHIR allows for the exchange of data via consistent, RESTful, FHIR APIs based on the HL7 FHIR specification. Backed by a managed PaaS offering in Azure, it also provides a scalable and secure environment for the management and storage of Protected Health Information (PHI) data in the native FHIR format.
Free up your resources to innovate
A health enterprise could invest resources building and running their own FHIR service. With the Azure API for FHIR, Microsoft takes on the workload of operations, maintenance, updates and compliance requirements. This allows you to free up your own operational and development resources.
Enable interoperability with FHIR
Using the Azure API for FHIR enables connect with any system that leverages FHIR APIs for read, write, search, and other functions. It can be used as a powerful tool to consolidate, normalize, and apply machine learning with clinical data from electronic health records, clinician and patient dashboards, remote monitoring programs, or with databases outside of an enterprise’s system that have FHIR APIs.
Control Data Access at Scale
Role-Based Access Control (RBAC) enables managing how the data is stored and accessed. Providing increased security and reducing administrative workload, we determine who has access to the datasets we create, based on role definitions we create for our environment.
Audit logs and tracking
Quickly track where the data is going with built-in audit logs. Track access, creation, modification, and reads within each data store.
Secure your data
We can now Protect PHI with unparalleled security intelligence. The data is isolated to a unique database per API instance and protected with multi-region failover. The Azure API for FHIR implements a layered, in-depth defense and advanced threat protection for the data.
*Image Credits and Reference: www.microsoft.com & www.hl7.org/fhir **Content Credits: DPS Bali
Dynamics 365 Health Azure API integration
What is Dynamics 365 Health?
Dynamics 365 Health Accelerator rapidly develops healthcare solutions using data model and use case templates based on HL7/FHIR. The Microsoft Health Accelerator enables partners and customers to create new use cases and workflows using a FHIR-based data model. It includes the following:
Pre-built entities and forms: Access to a wide range of FHIR-based entities and relationships allowing for rapid development of new healthcare solutions
Compliance: Standard based model built on a foundation of trust within a platform that is fully compliant with industry compliance standards including HIPAA and HITRUST
Care Team Visualization: A connected view of the care team associated with a patient and their roles that can be configured to include family and other related relationships
Patient Timeline: Presentation of clinical information about a patient in chronological order enabling providers to visualize all patient interactions and make informed care decisions
Native CDM Support: Health entities unified with standard CDM entities ensuring consistency across applications which allows rapid and seamless integration to 3rd party EMR and EHR systems
Dynamics 365 Health Entities
The accelerator provides a specific set of primary entities in support of the FHIR HL7 specification. Below are the entities that have been provided in the solution
- Patients
- Practitioners
- Organizations
- Devices
- Locations
- Healthcare Services
- Care Plans
- Allergy Intolerances
- Clinical Impression Problems
- Risk Assessments
- Observations
- Specimens
- Encounters
- Episodes of care
- Medications
- Medication Requests
- Medication Administration
Dynamics 365 Health with Azure API Integration for FHIR
We have created a Dynamics 365 Health with Azure API integration for FHIR and integrated Patients and Care Plan to Azure FHIR API. We are creating and updating Patient and Care Plan on Azure FHIR API on create and Update of Patient and Care Plan records in Dynamics 365 Health via Microsoft Flow. We have created a custom connector that connects to Azure FHIR API and created Actions in that Connector.
How to Create a Patient from Dynamics 365 Health UI into Azure FHIR Server or Azure FHIR API?
- Login to Dynamics 365 Health App and click on Patients
- Click on New
- Fill in the details of the Patient and click Save
- When we save the record in Dynamics 365 Health, this will create Patient in Azure FHIR API. We are checking this by Creating a Canvas App which get list of all Patients in Azure FHIR API.
Update Patients from Dynamics 365 Health UI into Azure FHIR Server or Azure FHIR API
- Open an existing Patient and update Date Of Birth to Sept 1, 2018.
- Click on Save
- When we save the record in Dynamics 365 Health, this will update Patient in Azure FHIR API. We are checking this by Creating a Canvas App which get list of all Patients in Azure FHIR API.
Extend Dynamics 365 Health and Add New Entities
Invoice Management
We have used standard Dynamics 365 CRM Invoice and Invoice Line as Invoice and Charge Item in Dynamics 365 Health.
We have also added few fields not present in Dynamics 365 as per FHIR HL7.
We can use Product, Price List and Price List Item to setup Price of any service or Medication and then generate Invoices based on Product and Services Delivered.
*Image Credits and Reference: www.microsoft.com & www.hl7.org/fhir **Content Credits: DPS Bali
What is FHIR?
FHIR is the latest development that’s gaining ground fast in the healthcare industry. It aims at breaking the barriers of seamless data exchange across various healthcare organizations that a patient typically interacts with. It is aiming at better patient care and enhanced patient engagement.
FHIR stands for Fast Healthcare Interoperability Resources. Developed by Health Level Seven International (commonly known as HL7), it’s an interoperability specification for the exchange of real time health care information electronically. The aim of FHIR is to address the growing digitization of the healthcare industry and the need for patient records to be readily “available, discoverable, and understandable.” Here’s a closer look at FHIR, its potential benefits and challenges.
Purpose of FHIR
FHIR is a standard developed by HL7 in response to the growing use of electronic health records (EHRs) and aims to “simplify implementation without sacrificing information integrity.” FHIR builds on previous data format standards from HL7, like HL7 version 2.x and HL7 version 3.x. But it is easier to implement because it uses a modern web-based suite of API technology, including a HTTP-based RESTful protocol, HTML and Cascading Style Sheets for user interface integration, a choice of JSON, XML or RDF for data representation, and Atom for results.
FHIR provides an alternative to document-centric approaches by directly exposing discrete data elements as services. For example, basic elements of healthcare like patients, admissions, diagnostic reports and medications can each be retrieved and manipulated via their own resource URLs. FHIR was supported at an American Medical Informatics Association meeting by many EHR vendors which value its open and extensible nature. To do this, FHIR “leverages existing logical and theoretical models to provide a consistent, easy to implement, and rigorous mechanism for exchanging data between healthcare applications.” The goal is to build a base set of resources that satisfy the majority of common use cases.
Benefits of using FHIR
FHIR can be used as a stand-alone data exchange standard or in conjunction with existing standards. Essentially, the goal of FHIR is to standardize the exchange of healthcare information, enabling healthcare providers and administrators to easily share patient information even when they’re using different software systems. With FHIR, each resource is associated with a unique identifier. Much like URLs make it easy to find a specific web page regardless of the device or browser you’re using, FHIR makes it possible to access the right information from any application or device.
By creating standard URLs for packets of information, FHIR eliminates the need to exchange individual documents or data back and forth between systems, while ensuring that disparate applications can point to the right information, and the same version of that information, simultaneously. This would allow developers to build more user-friendly applications with web-browser-esque functionality that ensure fast, reliable access to accurate data regardless of the EHR or other application being used, which in turn offers the potential for several benefits, such as:
- Easy implementation
- Improves the speed of healthcare delivery by making data readily accessible
- Standardizes and structures data for automated clinical support and other machine-based processing
- Eliminates the time-consuming document-based exchange of information, feeding information directly into workflows
Challenges in Healthcare and how FHIR solves these challenges?
Healthcare records are increasingly becoming digitized. As patients move around the healthcare ecosystem, their electronic health records must be available, discoverable, and understandable. Further, to support automated clinical decision support and other machine-based processing, the data must also be structured and standardized. (See Coming digital challenges in healthcare)
HL7 has been addressing these challenges by producing healthcare data exchange and information modeling standards for over 20 years. This is a new specification based on emerging industry approaches, but informed by years of lessons around requirements, successes and challenges gained through defining and implementing HL7 v2, HL7 v3 and the RIM, and CDA. It can be used as a stand-alone data exchange standard but can and will also be used in partnership with existing widely used standards.
FHIR aims to simplify implementation without sacrificing information integrity. It leverages existing logical and theoretical models to provide a consistent, easy to implement, and rigorous mechanism for exchanging data between healthcare applications. It has built-in mechanisms for traceability to the HL7 RIM and other important content models. This ensures alignment to HL7’s previously defined patterns and best practices without requiring the implementer to have intimate knowledge of the RIM or any HL7 v3 derivations.
Components of FHIR
The basic building block in FHIR is a Resource. All exchangeable content is defined as a resource. Resources all share the following set of characteristics:
- A common way to define and represent them, building them from data types that define common reusable patterns of elements
- A common set of metadata
- A human readable part
What does FHIR do?
FHIR uses standardized APIs to create plug-and-play applications. This serves to remove the gaps and errors that the current document-based system of information exchange brings with it. An application developed for FHIR can be plugged into any EHR and information can be obtained; there is no scope for information to be lost, and it’s easier to obtain specific details instead of a large volume of data to sift through.
What can FHIR do for Patients and Healthcare Service Providers?
There are a lot of expectations from FHIR with regards to improving patient engagement, seamless data transfer, and developing better care management programs. For patients, FHIR makes it easier to contact healthcare service providers by eliminating the hassle of having multiple portals for the same. This can also be used for obtaining smaller, specific data from eHealth or mHealth apps, wearable devices, monitors, and other sources to perform health analytics and make estimates, thus helping in preventive care. It can also offer a holistic and comprehensive picture of the patient’s health, medications, and episodes.
FHIR for Data Monitoring
FHIR supports a variety of applications and data sources, which makes it easy to access data snippets from various channels. Monitoring the mass of healthcare data is tough. It is possible to save a lot of time by enabling focussed data access, and converting this specific data into actionable insights.
*Image Credits and Reference: www.hl7.org/fhir **Content Credits: DPS Bali