Page tree
Skip to end of metadata
Go to start of metadata

1a. Project Name

PSS for CARIN Blue Button

1b. Project ID


1c. Is Your Project an Investigative Project (aka PSS-Lite)?


1d. Is your Project Artifact being Reaffirmed or proceeding to Normative directly after being either Informative or STU?


1e. Today's Date

1f. Name of standard being reaffirmed

1g. Project Artifact Information

1h. ISO/IEC Standard to Adopt

1i. Does the standard include excerpted text from one or more ISO, IEC or ISO/IEC standards, but is not an identical or modified adoption?

1j. Unit of Measure

2a. Primary/Sponsor WG

Financial Management

2b. Co-Sponsor WG

Community Based Care and Privacy

2c. Co-Sponsor Level of Involvement

Request formal content review prior to ballot

2b. Co-Sponsor WG 2

Payer/Provider Information Exchange

2c. Co-Sponsor Level of Involvement

Request periodic project updates; specify period in text box below (e.g. 'Monthly', 'At WGMs', etc.)

2c. Co-Sponsor 2 Update Periods


2b. Co-Sponsor WG 3


2c. Co-Sponsor Level of Involvement

Request formal content review prior to ballot

2d. Project Facilitator

Amol Vyas, Ryan Howells

2e. Other Interested Parties (and roles)

2f. Modeling Facilitator

2g. Publishing Facilitator

Amol Vyas/Paul Knapp

2h. Vocabulary Facilitator

Amol Vyas/Paul Knapp

2i. Domain Expert Representative

2j. Business Requirements Analyst

2k. Conformance Facilitator

Amol Vyas

2l. Other Facilitators

2m. Implementers

Cambia Health, BCBSA, United Health Care, Kaiser Permanente, BCBS of NC, Humana, Security Health Plan

3a. Project Scope

Develop a FHIR R4 based implementation guide for an API similar to the CMS Medicare Blue Button 2.0 API, FHIR R3 based, that will allow consumer-directed exchange of commercial Health Plan/Payer adjudicated claims data to meet the requirements of the CMS Interoperability and Patient Access proposed rule.

This FHIR Implementation guide will use the US core profiles. If this FHIR Implementation Guide is unable to use a US Core Profile we will request approval from US Realm Steering Committee and provide the US Realm approved rationale for deviation in the Implementation Guide


3b. Project Need

MA, CHIP, Medicaid Managed Care & QHP Plans will have to adopt a standards-based API in the CMS Interoperability and Patient Access proposed rule so beneficiaries can connect an app of their choice to their claims. The rule has a current proposed implementation date of 1/1/2020. Health plans are required to use standards-based API options, including CMS Medicare Blue Button 2.0 and this implementation guide will provide a FHIR R4 means to meet those requirements. This implementation guide will help those plans meet the proposed regulatory requirements.

3c. Security Risk


3d. External Drivers

March 2019 Interoperability and Patient Access Proposed Rule by CMS

3e. Objectives/Deliverables and Target Dates

7/2019 - Draft implementation guide published (complete)
9/2019 - Connectathon
10/2019 - Development and Connectathon outcomes documented and presented to FM Work Group
11/2019 - Ballot material approved by FM Work Group
1/2020 - Ballot

3f. Common Names / Keywords / Aliases:

CARIN, Blue Button 2.0, EOB

3g. Lineage

3h. Project Dependencies


3i. HL7-Managed Project Document Repository URL:

3j. Backwards Compatibility


3k. Additional Backwards Compatibility Information (if applicable)

3l. Using Current V3 Data Types?


3l. Reason for not using current V3 data types?

3m. External Vocabularies


3n. List of Vocabularies

HCPCS, CPT, ICD10-CM, RxNorm, MS-DRG, various NUBC codesets, potentially some X12 codesets.

3o. Earliest prior release and/or version to which the compatibility applies


4a. Products

FHIR Extensions, FHIR Implementation Guide, FHIR Profiles

4b. For FHIR IGs and FHIR Profiles, what product version(s) will the profiles apply to?


4c. FHIR Profiles Version


4d. Please define your New Product Definition

4d. Please define your New Product Family

5a. Project Intent

Implementation Guide (IG) will be created/modified

5a. White Paper Type

5a. Is the project adopting/endorsing an externally developed IG?


5a. Externally developed IG is to be (select one)

5a. Specify external organization

5a. Revising Current Standard Info

5b. Project Ballot Type

STU to Normative

5c. Additional Ballot Info

5d. Joint Copyright


5e. I understand I must submit a Joint Copyright Letter of Agreement to the TSC in order for the PSS to receive TSC approval.


6a. External Project Collaboration

CARIN Alliance

6b. Content Already Developed


6c. Content externally developed?


6d. List Developers of Externally Developed Content

Amol Vyas, Pat Taylor

6e. Is this a hosted (externally funded) project?


6f. Stakeholders

Regulatory Agency, Payors, Other

6f. Other Stakeholders

Consumers, Analytics firms.

6g. Vendors

EHR, PHR, Health Care IT, Other

6g. Other Vendors

Personal Health Record Apps

6h. Providers

Healthcare Institutions (hospitals, long term care, home care, mental health)

6h. Other Providers

6i. Realm

U.S. Realm Specific

7d. US Realm Approval Date

Jun 04, 2019

7a. Management Group(s) to Review PSS


7b. Sponsoring WG Approval Date

May 22, 2019

7c. Co-Sponsor Approval Date

7c. Co-Sponsor 2 Approval Date

7c. Co-Sponsor 3 Approval Date

7c. Co-Sponsor 4 Approval Date

7c. Co-Sponsor 5 Approval Date

7c. Co-Sponsor 6 Approval Date

7c. Co-Sponsor 7 Approval Date

7c. Co-Sponsor 8 Approval Date

7c. Co-Sponsor 9 Approval Date

7c. Co-Sponsor 10 Approval Date

7e. CDA MG Approval Date

7f. FMG Approval Date

May 29, 2019

7g. V2 MG Approval Date

7h. Architecture Review Board Approval Date

Oct 10, 2019

7i. Steering Division Approval Date

Sep 02, 2019

7j. TSC Approval Date


  1. Amol Vyas Needs d

  2. I don't see a timeline for balloting this IG.

    1. At a high level the timeline is as follows:

      9/2019 - Connectathon

      10/2019 - Development and Connectathon outcomes documented and presented to FM Work Group

      11/2019 - Ballot material approved by FM Work Group

      1/2020 - Ballot

  3. Amol Vyas Ryan Howells    CARIN Alliance projects are contingent on CARIN Alliance signing the FHIR Accelerator SOU and paying the necessary fees.  Hence artifacts cannot proceed to ballot until these items are done.

  4. Dave Hamill We have been negotiating our FHIR Accelerator SOU in good faith with HL7 for the last few months. We will be executing the agreement this week. It's important to note (especially for the broader HL7 FHIR community) that advancing our artifacts and proceeding to ballot for both of our projects has never been contingent on signing the agreement. Wayne Kubick can confirm if needed. 

  5. Updated Scope statement to reflect that this project will use the US Core Profile and work with the US Realm Committee to provide any adjustments to US Core and the regional for any changes. Have also updated the PSS to include a timeline.

  6. (Also posted at CARIN Alliance HL7 FHIR Projects)

    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.