Alix Goss

Bob Dieterle

Tim Young

Ed Martin

Tony Little

Danielle Friend

Alex Kontur

One-pager – Commonwell Health Alliance (Tim Young)

Looked at technical specification and spoke with some of the individuals on CHA’s advisory boards

CHA is a HIT messaging network/broker. Services include:

• Person enrollment
• Record location
• Patient identification and linking
• Data query and retrieval

CHA serves as a trust framework

Organization and endpoint registration details are proprietary

Standards supported:

• IHE
• FHIR

Requests use a single org ID, internal directory service to broker request and send to appropriate recipient

Synergies:

• Knowledge of many endpoints
• Identity services/attestation
• Auditing services
• “clearinghouse” activities, such as data transformation (e.g. for patient identity registration)

Would be helpful to speak to individuals from CHA to discuss potential synergies and better understand their internal directory services/endpoint management

• Bob – should consider inviting CHA to a Tiger Team call in the near-term

How would we insert CHA into a solution today?

• Young – envision having a spec/standard for a federated model…CHA could function as a node in the model because they already have knowledge of endpoints
• Martin – one nuance is that CHA is predominately provider-focused
• Bob – do you think of it as a source of endpoints, or a way to route transactions to an endpoint?
  • Young - initially thinking that CHA would be a source of endpoints

Use Case – plan-provider information request

• Post-conditions - 5 “in the event of an error, the information returned does not leave the clinician…”
  • Bob – consider whether we need to have defined errors as part of directory services
  • Bob – the language here needs to be updated to indicate that the information shouldn’t leave the payer
  • ? – can we also revise the language so that it isn’t a double negative (change “in a state of not knowing the path forward”)
• Trigger – “process is triggered by the Payer’s systems”
  • Bob – implies a request rather than a push. If a payer needs information from a provider, they can request it from the provider (therefore the trigger is on the payer) or there could be an automated requirement to send data, e.g. at the end of an encounter (in which the trigger would be on the provider)
    • The trigger may be a payer’s push (e.g. sending out a summary of gaps in care)
• Requirements & primary scenario – all items
  • 1 – “need my system to securely determine the endpoint…”
    • Bob – implies that the payer needs to know which provider has the relevant patient’s information before they can find the endpoint
    • Goss – also implies that a directory includes relationships between providers, locations, organizations, etc. A provider may work in multiple places, which may or may not be the same organization
    • Bob – triggers for an information request: claim (tells you where something has happened), attribution (associates patients/providers), or referral (assuming it requires authorization, creates a record of the providers involved in the referral)...or via a third-party record locator service
      • In advance of having received a claim (which may take up to a year after the service was rendered), the payer wants to understand the status of a patient (e.g. the payer knows about a referral, but hasn’t received a claim for services yet)
      • Should also consider administrative transactions as a source, e.g. eligibility request transaction or prior auth, ADTs
      • 2 – “need to send an appropriate payload to the provider…”
        • Bob – assuming the term “payload” refers to the content/format of the payer’s request for information. Could also be a payload of data for incorporation into a patient’s record (e.g. gaps in care) with a request for an action and response when done
        • 3 – “need my system to be able to send the request for data to the provider’s endpoint in a trusted and secure way…”
        • 4 – “need some interactions to be synchronous and some to be asynchronous…”
          • Bob – does not necessarily need to be bulk data compliant
          • 5 – “need the provider’s system to respond in an agreed upon time frame”
          • 6 – “in the case of an error on the part of the mechanism or provider…”