Bob Dieterle

Ed Martin

Patrick Murta

Danielle Friend

Alex Kontur

One Pager – Availity (Patrick Murta)

• Availity is primarily a clearinghouse
  • Created to provide single interface to connect payers to the provider community (e.g. for eligibility, claim submission, etc.), rather than requiring providers to go to each individual payer service
• Direct integration to Availity via web services (i.e. HTTP) and/or connection through portal
• Multi-payer platform, however not payer-agnostic (i.e. still have to indicate which payer the transaction is for)
• Clearinghouses have generally started offering value-add services (e.g. Direct messaging, revenue cycle management, medical interoperability) due to lack of growth for core capabilities
  • Availity has a “FHIR framework” – provides the technical capability to use FHIR, but lack of business model to support it (Humana doesn’t use the capability currently)
• Availity is Humana’s “x12 outward facing layer”
  • Humana and Availity transact using X12, Humana does not convert to proprietary format
• Limited support/use for clinical interoperability standards (e.g. v2, FHIR)
  • REST interface for 278 transactions
  • Some FHIR services for providers, but limited adoption
• Member of DirectTrust, but not other national frameworks
  • Availity provides typical security management technologies, e.g. SAML, certificates, etc.
• Availity staff are not currently participating on Tiger Teams, however Patrick does communicate/interact with Availity frequently. Will wait for more mature product before engaging them more fully
• Potential synergies: provider directory, provider data management, transaction intermediary, endpoint resolution, onboarding management

Bob – given that the industry has primarily used x12 as a batch, how does the paradigm change with a more real-time tech like REST?

• Murta – Humana does not typically process batch x12 transactions. Availity converts batches to a series of real-time transactions. Availity can convert responses from Humana back into batches for the receiver

Bob – if you are authenticating to an EHR to obtain a record using FHIR/REST, how do you gain value out of an intermediary?

• Murta – you don’t necessarily, but we should consider the intermediary model anyway. The primary appeal of an intermediary is that it allows payers/providers to offload operational costs. The security model we’re discussing for FHIR is much more sophisticated than x12. The x12 model relies on SOAP headers/SAML; it is a multi-step approach (which breaks the concept of using a token)

Bob – how extensive is Availity’s provider directory?

• Murta – not universal, based on the needs of payers (e.g. doesn’t have endpoints). Availity analyzes transactions over network, matched against data from payers (e.g. provider files) to build out provider directory
  • Humana has their own directory, not necessarily informed by Availity’s directory due to costs of integrating back into core enterprise vs. benefit

One pager – Direct/DirectTrust (Patrick Murta)

• Protocol for interoperability
• Uses SMTP (email protocol) to send data
• Content agnostic, although all EHRs can’t necessarily process all payloads
• Able to run FHIR over Direct
  • Can “invoke” a Direct message over an API à call API to find endpoint, use API to send message, and/or can attach a FHIR resource as the payload of a message
• Credentialing – entities are identity verified and then issued a certificate which is used to encrypt/decrypt messages between endpoints
  • Bob – the certificate typically encrypts data HISP to HISP, not necessarily between the HISP and the endpoint

Direct can function as a non-preferred connectivity model (preferred would be API). Can be used in certain circumstances with particular trusted entities (i.e. that can only or prefer to only receive content via Direct)

• Attachments via FHIR