Confluence will be upgraded on January 30th, 2020 beginning at 6 AM EST. Estimated downtime is 2 hrs. Please email with any questions.

Skip to end of metadata
Go to start of metadata

Comments on the CARIN Blue Button FHIR IG PSS

Kathleen Connor - I wasn't able to enter this text into the Confluence Comments likely because of embedded artifacts so posting here for reference.

I recommend that CARIN discuss project co-sponsorship with CBCP and Security WGs because of the extent to which the proposed use cases and workflows could adversely impact a healthcare consumer’s privacy preferences, which has not yet been sufficiently addressed.  In particular, there are numerous privacy/security risks around Bulk Data Transfer (BDT) and Individual Right of Access, and the privacy risks that patient information is exposed to once disclosed without any privacy law protections. I.e., there only consumer privacy protections, which aren't as robust as provided for HIPAA for healthcare information generally, or for sensitive information governed under 42 CFR Part 2, Title 38 Section 7332, and various state laws preempting HIPAA.

CARIN’s BlueButton IG is using SMART on FHIR.  I think it's questionable as to whether the "click agree button" constitutes a signed, written request (aka consent directive) as required for HIPAA Individual Right of Access authorization by a consumer to a third party App.  See CBCP call  discussion 2019-08-13 CBCP Meeting Agenda/Minutes where questions were raised about how consumers can track, update, or revoke such “click ok” consents. 

Consumer-directed health insurance data exchange Consumer-directed exchange occurs when a consumer or an authorized caregiver invokes their HIPAA Individual Right of Access (45 CFR 164.524) and requests their digital health information from a HIPAA covered entity (CE) via an application or other third-party data steward.

Use Case: Consumer Access to their Claims Data


  • Consumer (aka Beneficiary, Patient, or Authorized Caregiver)
  • Payer (aka Health Plan, Commercial Payer, Covered Entity)
  • Consumer-facing application - A digital third-party application selected by and primarily for the Consumer with a consumer-facing user interface

Normal Flow:

  • Consumer downloads or accesses the application of their choice
  • Consumer authorizes the application to access their digital claims data (thereby invoking their Individual Right of Access under HIPAA) via the SMART on FHIR authorization flow
  • Application connects to a FHIR API to download their digital claims data and requests the health plan send the data to the application
  • Application displays or otherwise uses digital claims data to the benefit of the Consumer

OCR FAQ: Right to Have PHI Sent Directly to a Designated Third Party

Can an individual, through the HIPAA right of access, have his or her health care provider or health plan send the individual’s PHI to a third party?

Yes.  If requested by an individual, a covered entity must transmit an individual’s PHI directly to another person or entity designated by the individual.  The individual’s request must be in writing, signed by the individual, and clearly identify the designated person or entity and where to send the PHI.  See 45 CFR 164.524(c)(3)(ii).  A covered entity may accept an electronic copy of a signed request (e.g., PDF or scanned image), an electronically executed request (e.g., via a secure web portal) that includes an electronic signature, or a faxed or mailed copy of a signed request.

From <>

(ii) If an individual's request for access directs the covered entity to transmit the copy of protected health information directly to another person designated by the individual, the covered entity must provide the copy to the person designated by the individual. The individual's request must be in writing, signed by the individual, and clearly identify the designated person and where to send the copy of protected health information.

This topic was also discussed during the Security WG discussion @ 2019-08-06 Security WG Agenda/Minutes.  Security WG has for several years raised issue with SMART on FHIR's lack of support for security labels.  In the last Connectathon, Mohammad Jafari proposed an approach to enforcing patient consents by filtering requested BDT.  See Privacy Aware Bulk Data Transfer.

In its WEDI Price and Transparency presentation slide 8:  CARIN proposes auditable self-attestation by App vendors, which may be an interesting and innovative way to leverage some protection outside of "HIPAA Land", but I have questions:

  • How patients will have recourse for malfeasance? 
  • What are the policies to which vendors would be attesting? How this is being documented?  My suggestion is that CARIN consider creating FHIR Trust Contracts, which follow the Trust Framework for Federated Authorization Conceptual and Behavioral Models, both of which are normative but not yet published HL7 Standards.  HL7 members can ask Security WG Cochairs for a copy ( e.g., email me).
  • What is the extent of the audits and the credentials of the auditor?  Has CARIN set some requirements about the qualifications of such auditors?  Has it considered test procedures for the capability to comply, such as ONC has for certified CEHRIT?

On Slide 8 are details that I think should be included in the proposed IG.

If CARIN endorsed App vendors were contractually required agreed to the CARIN Alliance Trust Framework and Code of Conduct., that would be a huge move in the right direction.  Again, using a FHIR Trust Contract would make each vendor's attestation discoverable, interoperable, standards-based and possibly legally-binding.

Another note of interest is the CARIN Elements of Informed Consent.

This somewhat aged approach to non-standards and non-structured, non-computable Research Informed Consent based on Apple ResearchKit should be migrated to a FHIR Consent, if no signature is required and this is simply the record of Informed Consent, or migrated to FHIR Contract following the approach used by the ONC Patient Choice for Research Technical Project pilot with REACHnet (See EHR Intelligence article for more info).  Nonetheless, it's a step up from "click approve" button in SMART on FHIR and Synch for Science.

For all of the above reasons, I encourage CARIN to begin collaborating with the HL7 CBCP/Security WGs to progress the CARIN Blue Button IG and other efforts around computable, interoperable, and standards based, Consumer Control guidance.

Hoping this comment helps with the CBCP WG call 9/3 with Ryan Howell from CARIN.

  • No labels