COGNIZANT CONSULTING

Helping organizations engage people and uncover insight from data to shape the products, services and experiences they offer

Learn More

Contact Us

THANKS FOR YOUR INTEREST IN COGNIZANT.

We'll be in touch soon!

x CLOSE

Refer back to this favorites tab during today's session for access to your selections.
Refer back to this favorites tab during today's session for access to your selections.x CLOSE

Perspectives

Privacy and Consent: Implementing the Cornerstones of Interoperability on a Flexible Foundation

2021-01-13


Healthcare payers must take an adaptable approach to enabling new business rules and workflows.

The Interoperability and Patient Access final rule is about to digitally supercharge patients’ ownership of their health information and how they choose to manage it. Data ownership, protection, access and sharing all were spelled out in the Health Insurance Portability and Accountability Act (HIPAA). Interoperability calls for the digitization of a subset of HIPAA and related privacy rights while preserving all the act’s protections. The Centers for Medicare and Medicaid Services (CMS) explains that interoperability does “not change any payer or provider’s obligations to abide by existing federal and state regulations…” and that “these policies just allow this information to be transmitted via an [application programming interface, or API] with the approval and at the direction of the patient.”

The consequence for payers is that the privacy and consent aspects of interoperability are among the most complex aspects of achieving compliance with the rule, requiring processes and procedures never done before. While CMS deferred certain complexities, such as segmenting data, many requirements arise not just from the interoperability rule but from other federal, state, tribal and local laws. Payers must approach API development and interoperability processes with a great deal of flexibility as they work toward compliance because the requirements of these various jurisdictions likely will change over time. Further, best practices and new data uses will emerge as interoperability unfurls and plan members exercise their access rights. Payers taking a flexible, engine-driven approach to privacy and consent management will be able to swiftly adapt to these opportunities while minimizing expensive rework.

Differences Between Interoperability and the Authorization to Release Medical Information Form

Interoperability digitizes many of the rights underlying the Authorization to Release Medical Information Form. The following compares the two capabilities that payers will offer. The paper-based solution must support all the rights that the HIPAA Privacy Rule and other laws and regulations afford. Interoperability digitizes a specific subset of these rights.

HIPAA and Related Laws and Regulations

  • Covered entities to take reasonable steps to verify the identity of the person requesting access.
  • HHS does not mandate the form of verification, such as a government-issued ID, but leaves it up the covered entity.
  • The identity verification process must not create barriers or unreasonable delay to access PHI.
  • The identity verification may be done via various means — orally or in writing, across channels.

Interoperability Apps and the Patient Access API

HIPAA and Related Laws and Regulations

Interoperability Apps and the Patient Access API

HIPAA and Related Laws and Regulations

  • Individuals have a right to access PHI for as long as the information is maintained by a covered entity, or by their business associate, regardless of when the information was created; whether the information is maintained in paper or electronic systems onsite, remotely, or is archived; or where the PHI originated.
  • Individuals have a right to access PHI in a “designated record set” such as medical and billing records; enrollment, payment, claims adjudication, and case or medical management records; and other records that are used in whole or in part to make decisions about individuals.
  • Individuals can specify types of data to share or not, such as benefit information, claims information, service determination information, premium information, and services from a provider. 
  • Individuals can specify sensitive data segments or not, such as HIV/AIDS, STD, substance abuse, behavioral health, and genetic testing.

Interoperability Apps and the Patient Access API

  • Individuals can access data that is maintained electronically back to date of service Jan. 1, 2016.
  • “If the patient requests their data via the Patient Access API from a payer, the payer must make available all of the data allowed per current law, such as 42 CFR part 2 and relevant state laws.”
  • “Due to limitations in the current availability of interoperability standards for some types of health information, or data, [CMS] notes the API requirement may not be sufficient to support access to all of the PHI subject to the HIPAA right of access because a patient's PHI may not all be transferable through the API.”
  • At this time, CMS is not requiring “data segmentation” for patient access.

HIPAA and Related Laws and Regulations

Interoperability Apps and the Patient Access API

HIPAA and Related Laws and Regulations

  • HHS “recognizes that there may be times when individuals are legally or otherwise incapable of exercising their rights, or simply choose to designate another to act on their behalf with respect to these rights. Under the Privacy Rule, a person authorized (under state or other applicable law) to act on behalf of the individual in making healthcare related decisions is the individual’s “personal representative.”

Interoperability Apps and the Patient Access API

  • CMS states: “We also note that when we discuss patients, we acknowledge a patient's personal representative.”
  • CMS also makes it clear that interoperability is available for personal representatives too: “Policies in this final rule that require a patient's action could be addressed by a patient's personal representative.”

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.

  • Identification and legal documentation: Payers will need to manage identifying documentation for personal representatives and the legal documents that authorize them to act on behalf of patients.

  • 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.

  • Workflow and approval processes: Payers must define and operationalize policies, procedures and processes for review and approval of consents.

  • Compliance auditability: Payers must have clear audit trails showing their organizations have followed these processes and can trace health information accesses and disclosures to the authorizations that have enabled them.

  • 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:

  • All electronic health information (EHI) will have provenance metadata.

  • All EHI will have sensitivity tagging.

  • Data will move externally in multiple ways (e.g., business associate agreements, or BAAs and others under HIPAA as well as via patient consent).

  • Payers will need to journal external data movements, both received and sent, with traceability to consents and authorizations.

  • Patients, personal representatives and many internal users will need visibility into these consents and data movements (“Where have you sent my data in the last 90 days?”).

  • Payers will need to systematically journal B2B data movements.

  • 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.

Related Thinking

Save this article to your folders


Save

PERSPECTIVES

Winning with Digital in Post-COVID-19...

The pandemic’s impact validated the industry’s initial digital investment...

Save View

Save this article to your folders


Save

PERSPECTIVES

AI Regulations Are Coming to Life...

To get out in front of tomorrow’s stricter regulatory environment, we...

Save View

Save this article to your folders


Save

PERSPECTIVES

Taking Charge of Healthcare Change from...

Health insurance payers can build on open, flexible and core...

Save View
Privacy and Consent: Implementing the Cornerstones of Interoperability on a Flexible Foundation