Replacing paper authorizations with digital capabilities
The interoperability rule essentially digitizes a subset of the provisions within traditional “Authorization to Release Medical Information” forms that payers developed under HIPAA. Yet the digitization of key data, plus interoperability data sharing and security requirements, create a variety of operational and data management challenges. Here are the key issues:
Identity management: Payers must store the identities of members and their personal representatives. Today, when plans receive requests for data from a paper form, member data is not always easily traceable. Misspelled names and incorrect addresses can lead to the same member having multiple identities and records. Payers often manually trace member data in these situations.
Storing personal representative data adds significant operational complexity and risk. While many payers have systems that manage the identities of their members, they do not have a robust, enterprise-wide IT infrastructure to manage the identities of personal representatives, many of whom are not members — either as subscribers or dependents — of their health plans.
Grants, expirations and revocations: Authentication of the identity of the person authorizing data release is being digitally realized through the SMART on FHIR application launch framework. With the paper form, members explicitly identify the party with whom their data will be shared and to what purpose. With interoperability, they don’t spell out a purpose but instead consent to one by agreeing with a third-party app’s privacy policy. Payers must enable members to easily see the information they have shared and to effortlessly revoke access to apps they no longer want to authorize.
Highly sensitive data labeling: Payers need mechanisms for identifying highly sensitive data, such as notes, procedures, medications and more, that relate to behavioral health care, birth control, pregnancy, sexually transmitted disease, testing and treatment for HIV/AIDS, and other conditions. Interoperability does not yet require data segmentation, mainly because CMS decided the technical specs to do so are not yet widely adopted. That said, CMS did indicate payers should anticipate data segmentation, and payers must prepare now for future filtering and masking of data types and highly sensitive data.
Patient education: Payers must inform members of their rights and risks under interoperability, both in general and possibly in the context of specific apps. The rule requires general education. Payers may go beyond that to offer app-specific education. This could be as simple as using SMART on FHIR, which incorporates the OAuth 2.0 workflow, to alert members in real-time that they are encountering an unsafe and/or unregistered third-party application.
It’s critical members understand that data access under interoperability is all or nothing; they cannot withhold specific data elements. CMS recommends that payers use or require app privacy policies that attest to how a patient’s health information may be “accessed, exchanged or used by any person or other entity,” including whether that data may be shared or sold, and that the policy require a member’s express consent before any such access, exchange, share or sale occurs. Members also need to understand that not all electronic health information, such as X-rays, may be shareable.
Experience design: Payers must ensure interoperability delivers a positive experience of new, valuable features, rather than an incomprehensible and risky process. An example would be providing an app or creating features in member portals that show members what apps they have authorized, when those authorizations expire, and what data and when has been accessed by each app.
An engine to digitally power privacy and consent
In addition to the requirements spelled out and implicit in the interoperability rule now, we expect additional amplifications, either to the rule or to best practices, including:
Future, complex consents and authorizations will require the complexity of masking and filtering based on sensitivity labels and more. A member would not need or likely want to share, for example, her mental health data with an orthopedic surgeon to whom she’s referred for ACL repair.
Hard-coding today’s compliance workflows will almost certainly lead to expensive future rework when new requirements and practices emerge after interoperability goes live. A rules-engine-based approach to privacy and consent compliance will give payers more flexibility to adapt to new requirements and best practices.
Instead of using a narrow set of rules and information request scenarios, the engine should have a multilayered decision framework and base decisions on who is requesting the data (member, an app, an authorized representation); whether member consent is on file; and data sensitivity. The engine can then make a yes/no decision — all in real time while capturing a complete audit record. An engine must also support payer configuration requirements to meet federal, state, local, tribal and organization-specific rules. Delivery through a SaaS model helps ensure scalability as demand for data grows. Ideally, an engine can extend consent management workflows to external systems such as customer service platforms and member portals via APIs.
Powering interoperability privacy and consent with an engine should enable payers to turn data access into an engaging, empowering experience for members. Payers that can help members easily manage and secure their data will meet compliance requirements while fulfilling the spirit of the rule, differentiating themselves and earning greater ROI on their interoperability investments.
To learn more, visit the Healthcare section of our website or contact us.
