Carequality Access

Beyond exchanging with eHealth Exchange’s 300+ health systems, federal agencies, providers and provider collaboratives,  eHealth Exchange also provides Participants the optional ability to also exchange with Carequality’s 35+ networks (e.g. the AthenaNet network, the eClinicalWorks network, CommonWell Health Alliance and many other eHealth Exchange peer networks).

Carequality is a framework, a library of technical and policy agreements, plus a governing structure enabling independent health data networks to exchange patient data. Similar to how the telecommunications industry has a behind the scenes framework allowing Verizon mobile phone users to communicate with T-Mobile and AT&T users, Carequality provides the policies and governance enabling providers on the CommonWell network to exchange with providers on the AthenaNet, Epic CareEverywhere and eHealth Exchange networks.

Obligations to Exchange via Carequality

Current Obligations:

Adhere to the Carequality Connection Terms (https://carequality.org/resources)

  • By not opting-out of exchange with Carequality, eHealth Exchange Operating Policy & Procedure 10 (section II, paragraph 3) binds your organization to adopt and flow-down the Carequality Connection Terms to be legally binding with your Participant Users.

Authorize a response to any and all Carequality directory listings for any Carequality use case (e.g. Query-Based Document Exchange) in which your organization exchanges. ​

  • If you deny requests to organizations not on a list of permitted identifiers (HCIDs), then in order to accomplish this goal, you will need to integrate with eHealth Exchange Extended directory via FHIR, once that directory is available circa Q1 2023.
  • By consuming the eHealth Exchange Extended directory, you will be able to authorize each entry in the directory by the HCID of the entry.
  • Until the eHealth Exchange Extended directory is released, the eHealth Exchange will provide a Carequality directory listing in a tabular format (Excel spreadsheet). Your organization should authorize a response to all the entries in this directory listing.

The Carequality non-discrimination provisions require that organizations MUST respond to all Treatment Use case requests sent by an entity On Behalf Of a Carequality Implementer or its Connections.

  • OBO is defined and described in the Carequality Framework Policies document’s section 3.2.1.3.
  • You may not “pick and choose” which OBO requests to respond to.
  • Carequality will support OBO for all Use Cases, but only the Treatment Use Case is required.
  • An OBO entity may only query for patients corresponding to patient records that exist in the responding system on whose behalf the OBO entity is initiating queries.
  • The OBO Carequality Directory listing must point to the OID of the organization on whose behalf it is initiating queries.
  •  

If your organization requests data from the Carequality community for Treatment purposes, your organization is encouraged (Not Required) to respond to requests from the Carequality community initiated by Individuals.

  • Patient Requests are defined and described in the Carequality Framework Policies document’s section 3.6.
  • Organizations should consider responding to Patient Request queries as appropriate and defined in the Carequality’s content guide.
  • If your organization is interested in offering the service to allow Individuals to request data, the organization MUST partner with a Credential Service Provider (CSP) that has been vetted and approved by a certifying body selected by Carequality.
    • These CSPs capture, verify and then provide patient demographics and PKI keys for authenticity verification.
    • The Patient Request end user MUST be verified to at least IAL2 and authenticated to at least AAL2 as described in NIST SP 800-63.
  • Initiators interested in providing proxy access to patient records MUST utilize Carequality’s FHIR Use Case. Specific validated demographics are listed in the Carequality Framework, Section 3.6.1.

If your organization requests data from the Carequality community for Treatment or Healthcare Operations (HCO) purposes, your organization is encouraged (Not Required) to respond to requests from the Carequality community initiated for HCO Care Coordination purposes.

  • Care Coordination is defined and described in the Carequality Framework Policies document’s section 3.1.
  • If your organization requests data for Treatment or Care Coordination, your organization should consider responding to HCO Care Coordination queries.
  • Carequality defines Care Coordination as a subcategory of HCO. This provides the responder with an understanding of what the data will be used for by the initiator.
  • Only non-provider-covered entities (e.g., payers) or HIPAA Business Associates (e.g., Payer Case Managers & Care Transition Coordinators) may request data using the “CARECOORDINATION” Purpose of Use Code.
    • These requests MAY ONLY be made to determine how to deliver care for a particular patient, group, or community by performing one or more actions to organize the provision and case management of an individual’s healthcare, including:
      1. Monitoring a patient’s goals, needs, and preferences;
      2. Acting as the communication link between two or more parties (e.g., providers or case management companies);
      3. Organizing and facilitating care activities and promoting self-management by advocating for, empowering, and educating a patient;
      4. and ensuring safe, appropriate, non-duplicative, and effective integrated care.

**Note: this is not the NHIN defined Purpose of Use code listed in the Authorization Framework table 3.3.2.6-1.

Maintain directory entries in both the Carequality Production and Stage (non-production) directories by requesting eHealth Exchange make these entries on your behalf.

  • If your organization has not already done so, please email techsupport@sequoiaproject.org to request these directory entries.
  • Please ensure your directory entries in the Carequality Stage directory (non-production) reasonably mirror your production setup.
  • For additional information, see https://carequality.org/wp-content/uploads/2021/07/Query-Based-Document-Exchange-Implementation-Guide-v2.0-Published-07122021-1.pdf.
  • A participant or participant member wishing to assert the Treatment Permitted Purpose must provide one of the following pieces of evidence:
    • Organization-level NPI (Type 2), or Provider-level NPI (Type 1) in cases where an Organization-level NPI is not needed and has not been acquired
    • State-level certification/accreditation/licensure
    • CLIA certification (for labs)

This requirement will be enforced once the FHIR R4 directory is deployed by Carequality.  Some exceptions are allowed as documented by the latest revision of the Carequality Framework Policy 3.2.1.

  • A participant or participant member is permitted to serve ONLY in the role of Query Initiator for the Permitted Purpose of Treatment if that participant or participant member has received authorization from Carequality and:
    • (i) is a provider organization with no clinical information that could reasonably be made available for response as defined by Section 3.2.1.1 of the Carequality Framework Policy.
    • (ii) is an EMS provider with alternative provision of data, as defined in Section 3.2.1.2 below; or
    • (iii) is otherwise prohibited from serving in the Query Responder role by Applicable Law.

The categorization of an initiator only role (one of the three choices above) must be published in the Carequality directory under a new initiator only entry and will be enforced once the FHIR R4 directory is deployed by Carequality.
HIEs and similar non-providers must create sub-participant entries in the eHealth Exchange production directory that represent the providers and/or payers within your organization.
  • Participants must populate the eHealth Exchange directory (which will in turn update the Carequality directory) with each of their locations that might be initiating/triggering a query and each of those locations must include a Home Community Identifier (HCID).
  • There is no eHealth Exchange charge for these supplemental directory entries.
Health Information Exchanges (HIEs) and similar non-provider intermediaries must identify the HIPAA Covered Entities or their Business Associates who originated requests, as well as their originating technology platform and originating individual/username, in SAML headers or FHIR tokens so data holders can track where data has been disclosed for HIPAA Accounting of Disclosures.  Specifically, requests for data must identify:
  1. The HIE or intermediary’s technology platform relaying/forwarding the request in the FHIR token or SAML homeCommunityId attribute. This homeCommunityId attribute must represent the gateway listed in the eHealth Exchange directory that connects the Participant to the eHealth Exchange network.
  2. The Covered Entity or their Business Associate originating (not forwarding) the request, in the FHIR token or SAML subject:organization and subject:organization-id attributes.  The subject:organization-id token/attribute must match an entry in the eHealth Exchange directory and typically represents a Subparticipant entry versus a Participant entry.
  3. The individual/username originating (not forwarding) the request, in the FHIR token or SAML subject-id attribute.
Example: “Springfield Medical Center”, a HIPAA Covered Entity and member of the fictitious eHealth Exchange Participant “Denver Health Information Exchange”, originates a request for data by directing “Denver Health Information Exchange” to relay the request to eHealth Exchange.  “Denver Health Information Exchange” is directly connected to the eHealth Exchange network via the Hub, but “Springfield Medical Center” is not. The originator (“Springfield Medical Center”) must be identified in SAML subject-organization and subject:organization-id attributes or FHIR tokens.  The intermediary and Participant, “Denver Health Information Exchange” must be identified by the SAML homeCommunityId attribute because “Denver Health Information Exchange” provides the technology platform that relayed or forwarded the request for data.
Maintain a test environment with an active certificate authority (CA) issued certificate.
  • At least one synthetic patient with at least one synthetic CDA so the trusted Carequality community can test exchange with your organization at any time.
  • More than one test patient is needed when one test patient is not sufficient to reasonably represent the data in your production environment.
Note: Separately, remember eHealth Exchange requires these non-production certificates be issued specifically by DirectTrust [or by Entrust as long as still permissible in 2021].
HIE and similar participants (“Candidate Implementers” in the Carequality world) must complete a Carequality Application Exhibit 1 form. The Carequality Application Exhibit 1 is a survey designed to document the nature of your requests and responses for the Carequality community and how your share data with other organizations.  The form can be requested by contacting administer@ehealthexchange.org. For example:
  • As an initiator, list the permitted purpose of uses and justification for each purpose of use. As a responder, which purpose of use values do you allow?
  • Document external access to retrieved data
  • Patient/consumer access to retrieve data
  • What triggers your requests?
  • How do you decide which Carequality organizations are targeted for requests?
  • Patient selection approach – for example, patients targeted based on appointment check-in or ED arrival?
  • Do your providers require additional terms and conditions to respond to requests? Do the terms and condition include any limitations to the purpose of use?
HIE participants choosing to exchange with Carequality should populate the Carequality Application Exhibit 1 form and email it to administrator@ehealthexchange.org.

Future Obligations:

None at this time