By Shobhit Saran - Asst. Vice President, Health Plans Consulting, Gati Patel – Healthcare Business Analyst, FAST+
Our previous blog post talked about the potential impact and possibilities of the CMS Interoperability & Patient Access Rule. The second part of this blog series talks about consent management requirements for data sharing through Patient Access API.
To be compliant with the CMS interoperability and patient access final rule, all CMS regulated payers (i.e. Medicare Organizations, State Medicaid FFS, Medicaid Managed Care, CHIP FFS and CHIP Managed Care) need to implement and maintain a standard-based API to share member Health data starting 1st January 2021.
The API should allow members to access their health data through third party applications of their choice and give physician’s access to member information, if required, with an approval/consent from the member.
Consent Management System
There is an extensive list of data and technology capabilities a payer needs to build to set-up an API infrastructure for the rule’s compliance. Payers need to build a “Consent Management System” to collect member consent for effective use, while sharing data through a third-party application.
The Consent Management System (CMS) obtains digital patient consent and allows members to determine what health data they want to permit through a third-party/ provider facing application for health management.
To obtain, store and manage member consent, it is imperative for payers to implement and maintain a consent management system with the timelines set by CMS within the Interoperability & Patient Access Rule.
There are two major workflows to capture patient consent:
1. Offline informed consent:
- Captures one-time member consent over a given period of time for a list of data attributes and choice of applications
- To provide offline consent, member needs to login to the payer consent management system
- Member can update/revoke the consent, following the above-mentioned procedure if required
2. Consent on-the-go:
- Members download a new third-party health application to access their health data. However, the application does not have an existing consent from member in the consent management system
- In this case, the member will be redirected to the Consent Management System to provide consent and access their information instantly.
Below workflow illustrates a typical offline consent signing and data retrieval process by third party application:
Consent Workflow
|
Step |
Description |
|
1. |
Member logs in to the consent management portal to provide consent for few applications, list of APIs with exceptions (if any) for a given period of time |
|
2. |
Patient consent information is stored into consent management system |
|
3. |
3rd party app makes a call to the authorization server for an authorization token |
|
4. |
Post successful authentication and authorization, the 3rd party app makes a call to the FHIR server |
|
5. |
Authorization server will validate the availability of patient consent for the requesting application |
|
6. |
If patient consent is available (“yes”), data will be shared with 3rd party app |
Read all Blogs in the FHIR Series
Part 1: CMS' Interop & Patient Access Rule - Impact & Opportunities
Part 4: CMS Interoperability & Patient Access Rule - FHIR Bulk Data API
Part 5: CMS Interoperability & Patient Access Rule - FHIR Data Repository
Next in the blog series, Part 6: "Payer to Payer Data Exchange”.
