Menu
Mark Scrimshire, Onyx Chief Interoperability Officer, is the CMS Blue Button Innovator and a thought leader in the Interoperability space. In this Executive Interview with Julie Fournier, Onyx Director of Sales, Mark helps payers understand how they can handle consent when implementing the Patient Access API, as required by the CMS Mandate.
—
JF: Thank you for joining us today, Mark! I wanted to take this opportunity to see if you can help payers understand how they can handle consent when implementing the Patient Access API, as required by the CMS Mandate. Help me understand how consent plays into the CMS Interoperability Rule?
MS: The Interoperability and Patient Access Rule is all about giving Members control over their data. Allowing them to share it with apps or services of their choice and to take the data with them when they move from health plan to health plan
JF: Is consent an “all or nothing” choice?
MS: Not quite. The CMS Rule implies that a consumer can choose to share their data via a standards-based API. That is an all or nothing decision. However, the CMS Rule does not override existing regulations. Therefore, there are certain states that enable consumers to limit the access to their data. For example, a teenage child in some states can require their health plan to limit their parent’s access to certain parts of their health information. This creates a patchwork of policy rules that need to be applied based upon Federal, State, Local and Tribal regulations.
A further complication is the regulation relating to behavioral health data. There is a requirement that consumers give specific authorization to share their behavioral health data. This translates to offering that choice as part of the consent or authorization process. The more complex part of this requirement is the flagging of the data to filter out records based upon the content in a record.
JF: Is there a model that payers can follow when implementing the consent process in the Patient Access API?
MS: When we built the Blue Button 2.0 API for CMS, we took the Authorization/Consent process through a review with The CMS Office of the General Counsel and the HHS Office of Civil Rights to get their blessing. That Authorization has been in operation since April 2018. I would suggest to payers that this is a good model to follow since it provides a precedent that has been market tested.
JF: How will payers decide which apps they will grant access to?
MS: Under the ONC Information blocking rule and the CMS Mandate, payers are more or less obligated to connect an application to their API if a member demands it. If payers offer a range of apps, not just their own, but recognizable apps, for example from the range of apps registered with CMS Blue Button 2.0 then consumers may just pick one of the offered apps. The big change will probably come when major apps, like one from a certain major consumer smartphone company, stats appearing in the list of approved apps.
Under the ONC Information blocking rule and the CMS Mandate, payers are more or less obligated to connect an application to their API if a member demands it.
There are only limited grounds on which a payer can refuse to connect an application. It boils down to whether the app puts their API and systems at risk. In addition, if a payer does apply access criteria when reviewing an application, they must apply those criteria to all applications accessing the API. If they make the access criteria too stringent the payer risks falling into the category of “Information Blocker”.
JF: Are payers required to grant access to any app that a member requests to access their data and does the payer need to offer that app to all members?
MS: I personally believe the apps that are given access should be visible to consumers. Granting access but not identifying connected apps leaves consumers open to exploitation from scammers. This was an approach we took with CMS. No app would get hidden access to the API.
If an app is made available, the payer can identify how much they know about an app. For example, has the app self-attested to the CARIN Code of Conduct. If they haven’t, maybe they can use a simple traffic light indicator or similar metaphor to express the level of trust.
JF: How will payers manage app access?
MS: For the Patient Access API apps will need to register. At Onyx, our SAFHIR platform handles that access request process to make it simple for plans to approve or reject access. We based the process on the one developed for the CMS Blue Button2.0 API.
JF: If a member wants to use a certain app and the payer has suspicions that the app is a “bad actor”, does the payer have to grant access?
MS: As I indicated earlier, the payer more or less has to provide access, unless the app is a danger to their API and infrastructure. But the payer can indicate that the app is “untrusted” or unknown.
At Onyx, our SAFHIR platform handles that access request process to make it simple for plans to approve or reject access. We based the process on the one developed for the CMS Blue Button2.0 API.
Because the Consumer is using their HIPAA Right of Access to send their data to an app of their choice. They have a right to their data. As I would often say to the security and privacy people at CMS: “A member is perfectly at liberty to KNOWINGLY share their data with a Russian or Chinese hacker!”
JF: If the payer identifies that the app is suspected to be a “bad actor” what can the payer do?
MS: Assuming that the app does not put the payer’s infrastructure at risk the payer may have to grant access but could identify the app as “risky” so that when a member connects and goes to authorize sharing they would see a warning indicator or notice.
JF: Are there any other considerations around consent payers or members should be aware of?
MS: Whilst CMS issued the Interoperability and Patient Access Rule earlier this year, there have been a series of questions posed to CMS to gain clarification around interpretation of the rule. One area that we are expecting clarification around is relating to protected information, such as Behavioral Health (SAMSHA 42 CFR Part 2). It may transpire that members will have to explicitly confirm that that they want to share their behavioral data.
Another aspect around consent is whether more granular choices need to be made available. The CMS Rule does not require this. Our experience at CMS with Blue Button 2.0 API is that the more choice you provide to the member the more confusing the process becomes. Payers should also remember that many members will be accessing via smartphones. They have limited real estate. So, it is important to present the authorization in clear and simple terms. Members need to realize that they are using their HIPAA Right of Access to share their data. This moves data outside the HIPAA boundary, and they should think about who they are sharing with and how it will be used. Presenting a lot of legalese in small fonts does not help. I would recommend that payers look at how the ONC created the Model Privacy Notice and think about how the consent language can be made available in layers of increasing detail so that people can dive in as dep as they want. But just presenting a lot of complex legal language up front just encourages people to click through without really reading. We all know this to be true. We all (or at least 99.99%) of us have just clicked straight through those long complex terms of service.
Members need to realize that they are using their HIPAA Right of Access to share their data. This moves data outside the HIPAA boundary, and they should think about who they are sharing with and how it will be used.
JF: Thank you again for sharing all of the great information today Mark. We appreciate your insight!
