Skip survey header

Consumer Directed Exchange RFP

 

Request For Proposals for a Consumer Directed Exchange Solution

Alliance for Better Health

 

Overview

Alliance for Better Health is a collaborative network of more than 2,000 providers and community-based organizations who are partnering to transform how health care is delivered in our region, with a focus on Medicaid members and uninsured individuals. We serve an estimated 193,000 Medicaid and uninsured members of our communities across a six county area in upstate New York (Albany, Fulton, Montgomery, Rensselaer, Schenectady, and Saratoga counties). Alliance was formed in 2014 in response to a New York State Department of Health initiative called the Delivery System Reform Incentive Payment Program (DSRIP). The goals of DSRIP are to achieve the so-called “Triple Aim” of improving care, improving the overall health and wellness of the communities we serve, and reducing health care costs. Additionally, we are specifically striving to reduce the number of avoidable hospitalizations and emergency department visits by 25% over a five-year period.

 

In the service of this community, we are in the process of implementing unite us. This platform enables care providers to refer clients to community organizations. Many of these organizations are non-covered entities, and these entities therefore cannot execute business associate agreements for fluid exchange of information across the community.  

We seek to bridge this information gap by empowering individuals to share information themselves. We envision a solution that is easy for consumers to use on-site at a community-based organization, or perhaps on a smartphone or PC.  A short outline of the functional requirements is below.  Nothing here is set in stone, and we are open to creative alternative solutions from respondents to this RFP.

 

  1. Problem:  HIPAA Covered Entities (CE) can’t share information with non-covered entities (NCE), because the NCE can’t sign a BAA.

    1. Many community-based organizations (CBOs) that serve medicaid members and the uninsured CBOs are NCEs.

    2. We need the CBOs to share PHI with CEs and we need the CEs to share with NCEs so that folks can have their needs understood and addressed by a connected community of providers.

    3. But the CEs can only share with:

      1. Another CE

      2. The client

    4. So if the CE shares with the client, then the client can share with the NCE.

    5. The client need only “have” their info for a millisecond. So long as it’s > 0 seconds, and the client is the one who takes action, then the NCE can get/see/manage any information – as they received it from the client.

    6. Notice that this isn’t CONSENT. This is true “consumer-directed” information sharing. The consumer directs where the information goes.

  2. Our vision for a workflow:

      1. client on-site at a CBO.  CBO says “can we get your health info?”

      2. client:  “I guess so.  Not sure what you mean – but sure.”

      3. CBO:  “Here is a computing device (tablet, computer, etc).  Type your name and ID proof that you are who you say you are and press “OK.

      4. ID proofing.  How do we know that the client is really the client?

        1. The solution would build an open source way to develop a trusted credential at an IAL Level 2 that follows Section 4.4 in the NIST Digital ID Guidelines (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63a.pdf)

      5. Authentication - How can the client securely log in to the application without the use of a user name and password?

        1. The solution would utilize the FIDO Alliance specifications which would enable a user to securely authenticate into the application and download their health information without the use of a user name and password.

      6. Record-matching - How can an application be able to match a client who has been user-proofed to their existing records?

        1. The application will develop a set of  Knowledge-based verification questions using the user’s personal health information. The source for health information is a CCD or CCD-A found in the FHIR demographic resource for the installed consumer-facing API.

        2. The tool would then ask questions .. based on health info rather than credit history (this is called knowledge - based authentication)

          1. Name of your doctor

          2. A prescription

          3. Age

          4. Etc.

      7. After User Proofing and Authentication, the system can retrieve as much data about the client as it has access to and the client would validate the data is unique to them as an individual.  (note that the system, in this case, managed by our organization - would need access to PHI that is stored by business associates and/or covered entities.  The NCE would never have access to this information, or even be able to validate that it exists, until it is shared with them by the clients.)

      8. Client’s electronic request preferences - The client would then be presented with an authorization screen, with options for where their health information should be shared, for how long, and how it should be used.  

      9. After the client selects who should receive the information, the client takes an action (such as hitting a “send” button) and the information is sent to the recipient organization using the industry standard that is most appropriate for that recipient.  In most cases (especially for an NCE) this will be access to an HTML view of an ephemeral document.  NCEs don’t have the capability to store and/or protect PHI and therefore should not be burdened with this.  The web view may even be best presented in a form that prevents a casual user from copy/paste.

  3. Summary: the RFP is for a set of components, each of which may be addressed together or individually

    1. A core services framework to support a UX and interfaces to a set of services:

    2. A user-proofing service that user proofs an individual to an IAL2 level based on the NIST guidelines

    3. A Knowledge-based record locator service that receives a standard document or set of documents (FHIR resources, CCD, or C-CDA), parses such a document, selects questions and foils to be presented to the user, and scores the responses as affirmative (confirming identity with 99% confidence) or negative.

    4. An authentication service that securely authenticates a client so they have access to an application using the FIDO standard that does not require a user name and password.

    5. Data retrieval service that locates records for an individual, once the individual is identified, aggregates them, eliminates as much redundancy as possible (good-enough is appropriate for a version 0.5)  and identifies what information was found - and where.

    6. Federation of a client’s electronic request for information - System would be able to federate a client’s preferences for how their data should be shared across systems.

    7. An information delivery service that presents a (very) minimal summary of information that was found and portrays that summary (categories of information not the information itself) to the client, with options for selecting an endpoint for information delivery.

    8. BONUS: The system would also develop a way to federate the trusted IAL2 credential across systems using the NIST federation standards.

    9. Services to:

      1. Do client record lookups in the New York SPRL and/or local information exchanges

      2. Do provider lookups in Salesforce and/or Unite us.

      3. Integrate with Unite Us for authentication, client lookup, provider lookup, and services lookups.

 

Considerations and alignment with other national efforts

 

This project will will be Open-source.  All work product will be expected to be posted to Github or another open repository on a regular basis.

 

The CARIN Alliance will be informed re: progress and will be engaged for guidance throughout the project.

 

KBA should be considered (as described above) but if infeasible, alternate methods should be defined and implemented.

Vectors of trust  should be considered.

FIDO standards should be considered.

Digital ID proofing standards from NIST should be considered.
1. Who are you? *This question is required.