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)