How do you comply with the unexplained authorization? This is the challenge for payers. Only a few months can meet the current deadline for the payer-to-payer data exchange in January 2022. This is another part of the CMS/ONC interoperability rules. CMS and ONC did not provide direct requirements, and part of the reference to the directive was severely scattered in the 900-page regulations, and lacked important details and much-needed clarity.
Before examining the rules in detail, the payer should avoid confusion about the proposed changes to this part of the rules. In December 2020, CMS published the proposed rule CMS-9123-P. Recognizing the shortcomings of the current (eventually) interoperability rules surrounding exchanges, the rules proposed in December outline clearer and more actionable requirements and postpone the deadline to 2023. Unfortunately, the proposal was issued after the 2020 election and did not survive the changes in the administration. Payers should not expect any possible delays, but should act on the information they have today to comply with the rules.
What is clarity
Some elements of the final rule are very clear.Starting from January 1, payers regulated by CMS (Medicare Advantage, Managed Medicaid, CHIP and Federal Exchange QHP) must exchange USCDI v1 data setTon, In electronic form, in the patient’s [member’s] Require. This is a one-time rather than continuous data exchange. The goal is to allow members to carry their data with them when transferring from the sender (the insurance company with the data) to the recipient, thereby creating a cumulative data set.[USCDI[USCDI[USCDI[USCDI
As members move across plans over time and request data between sending and receiving payers, they create a “chain” of data transmission, and the plan becomes a “link in the chain.” CMS expects data to become cumulative records as it moves between plans.
What is unclear
Creating requirements based on this rule will be a challenge. There is a lot of unsaid that may prevent successful compliance efforts from achieving CMS goals.
CMS clearly prefers to use it as an extension of the technology mandatory for patient access to APIs. The rule states that APIs are the ideal method of payer-to-payer transmission; CMS sees the value of reusing patient access to APIs.
How is Exchange implemented through API? If the CMS designated member makes a request to the recipient of the payer (rather than the sender of the payer), this will be simple. But the member request will be sent to the sender who has the authorization of the mobile data. The obstacle lies in the technology: it is not clear how to establish streaming or publish/subscribe (asynchronous messaging) in our many-to-many node payer industry (without additional federal standards) to meet the requirements.
We know that CMS is designed to use APIs. Specifically, when the sender is a link in the chain and receives data from the previous plan through the FHIR API, the rules require the data to be sent down the chain in the same format to the next recipient. If the payee cannot accept it in the API, the sender only needs to access the API shared data through the patient that the sender has maintained and is ready to share via the FHIR-based API.
If there is no more guidance, the industry cannot be asked to “figure it out.”
- There is no standard for what method members should use to request the sender to initiate an exchange.
- It is not clear whether the payer can request members to access the portal and/or provide their member ID to initiate the request.
- Do not understand any timing requirements.
- Should any plan be communicated with members during and after the implementation of any plan? If so, so what?
- If the API cannot be easily used, what coordination method should the sender and receiver use?
- If the payee does not have a registered member, how do they handle the data?
The most important thing is, what are the limitations on the form or delivery method of the data? This rule only specifies that the transmission is electronic and covers data elements in USCDI. But how should the plan be sent? Should they use digital endpoints like Direct Address and/or FHIR API endpoints? Without guidance, each sender can create his own method of sending data, and each receiver must have the ability to process it.
What should the payer do?
The payer must decide whether they want to comply with the spirit of the rules or take the shortest path to comply with the rules. The latter involves the following:
- Sender
- Create a basic physical representation of USCDI for a single member from the data set used to satisfy the patient access API for sending the data created by the payer-a simple XML or CSV file
- Assign employees to manually meet the requirements of members:
- Create a file that sends the data created by the payer
- Check whether the member has previously sent the data as a link in the chain to the sender (so this is a serial data transmission); if so, please copy the electronic product used by the sender when receiving the electronic product
- Contact the payee to arrange delivery in a safe HIPAA manner, and transmit the sender’s files including any “link in the chain” data
- Payee
- Designate staff as the designated receiving point for any incoming documents:
- Determine the best way to store within the payee to meet the requirements of “consolidation”
- Keep the original file so that it can be resent during serial data transmission
- Designate staff as the designated receiving point for any incoming documents:
Such a manual workflow will certainly not fulfill the CMS’s vision of creating a cumulative data set. However, the number may be low, and the program compliance team may consider this approach to be appropriate.
For the plan to realize the CMS vision, despite the above-mentioned challenges, it still needs to use the FHIR format and API methods to express and transmit USCDI data. The sender and receiver can coordinate with each other, allowing the receiver to call the sender’s Patient Access API.
Is this rule even needed?
If the member wants to record vertically, or if the payer wants to access historical member data, there is now a patient access API, and it is far superior to the payer-to-payer data exchange. It includes USCDI, but also includes a large amount of administrative data. This is good standardization. Although both methods are based on member operations, using the patient access API will allow the payer to organize work to obtain large-scale consent, resulting in a meaningful inbound data stream, which will be more useful to the payer and demonstrate efforts to exploit Inbound data.
The healthcare industry is in a transition period; from a world of data isolation to a world of data flow. When planning efforts to decide how to comply with the poorly worded part of the final rules on interoperability, they should consider the broader changes in their work and whether their choices are now ready for the future world.
