Alix Goss

Bob Dieterle

Rick Geimer

Patrick Murta

Jason Walonoski

Diana Ciricean


Technical Barriers

Scaling – multiple current models for interoperability between providers/payers

  • Bob – Mixed models (hub/spoke, point-to-point connections, and regionally connected hub/spoke) create challenges in implementing consistent approaches to authentication, endpoint discovery, identity matching, end-to-end performance, etc.
  • Existing efforts:
    • Bob – no industry efforts focused on mixed model scaling solutions

Scaling – lack of predictable availability and response times

  • Alix – scaling real-time transactions requires infrastructure that may not be currently available in existing intermediaries
  • Bob – the lack of predictable end-to-end response time limits specific use cases where providers require response prior to proceeding w/diagnosis or treatment; i.e. if I don’t have adequate response time, I won’t use the data and will instead rely on manual methods, which can impact things like patient retention (e.g. if next appointment isn’t scheduled at point of care)
  • Bob – existing intermediary models, in general, do not support synchronous real-time end-to-end applications. Most are asynchronous today (e.g. prior auth determination takes 40 seconds)
    • Murta – (when working with Availity) underlying technology is stateless and asynchronous, however state is held open. E.g. if you submit a prior auth, we hold the connection open until it hits the engines on the Humana side and we render a decision. Just b/c we have an intermediary in the middle, doesn’t mean we lose all of the components of synchronicity
    • Bob - Are you synchronous w/the screen/portal, or with Availity?
    • Murta – the entire stack is held open in state until there is a response; e.g. if you are in an EHR and you do a referral or authorization, you see an hourglass briefly while it hits the Availity service, is relayed to Humana, and the Humana engine processes/returns a response
    • Bob – is that Availity or does every clearinghouse have that capability
    • Geimer – not sure everybody does always…asynchronicity is when the transaction is in somebody’s black box. You may have to wait for a manual process to complete (e.g. phone call). Some intermediaries don’t have the ability to respond in real-time
  • Existing efforts:
    • Bob – efforts in industry to promote specific interaction models that have predictable availability and performance, e.g. Commonwell provides real-time access
    • Geimer – individual entities are establishing SLAs
      • Bob – those are tied to specific interaction models, e.g. Commonwell puts everything in a single repository which provides ability to return a predictable response
      • Geimer – probably won’t have a consistent model for this across the industry, rather can have predictability in specific cases/organizations. We expect this to improve in the industry over time as FHIR moves from pilot to production
      • Alix – anticipating improvements over time as FHIR and its uses in various models mature
      • Geimer – correct, focus on performance, reliability, etc. increases over time

Scaling – lack of unique patient ID

  • Bob – limits real-time positive identification of patients and their associated records
  • Bob – introduces limitations in distributed access to patient records, because if I receive a request and all I have is limited information about the patient, I may not be able to respond because I may have multiple patients that meet the criteria (and I’m not sending all of their records
  • Existing efforts:
    • Bob – ONC patient matching challenges and other industry efforts to improve probabilistic patient matching
      • Geimer – no current government or industry efforts to create a unique patient identifier

Scaling – discovering location of records for a given patient

  • Bob - discovering endpoints for patient records in a distributed environment
    • Murta – Currently No process for universally discovering endpoints in general, not just for a specific patient
  • Bob – lack of a national patient record locator service limits the ability to discover patient records in a distributed service environment. Not a big issue if you get all of your healthcare at a single place, but that is often not the case
  • Existing efforts:
    • Bob – industry efforts within related organizations (e.g. Commonwell) are addressing the problem within their scope of coverage. Carequality/Sequoia is also trying to address it (eHealth Exchange is the underlying technology, Sequoia is the implementation, Carequality is the common agreement)

Scaling – anticipated increase in FHIR transaction volumes presents scaling and performance challenges

  • Geimer - no reasonable model to predict the volume of FHIR transactions; because many transactions will be RESTful, part of the problem will be addressed by using common standards (e.g. HTTP). Not as much of a technical limitation, rather a need to apply what we’ve learned in other industries to scale FHIR
    • Bob – as long as you transacting with an endpoint…different if you are transacting with an intermediary. Industry must adopt RESTful solutions to solve real-time synchronous FHIR scalability
    • Geimer – instead of “RESTful solutions”, should say “real-time solutions.” There are clearinghouses that expose their end to the payers as a FHIR RESTful service, but may have a separate real-time (i.e. proprietary, not RESTful) services for provider systems. May also have “block box synchronous” services (asynchronous things happening in the background, but abstracted from the RESTful interface)
    • Murta – underlying technology may not matter as the long as the interface is RESTful
    • Bob – As an EHR vendor connecting to a payer system through a RESTful synchronous transaction, I don’t care what the payer system is internally b/c it is presented as a RESTful solution and expectation is that it will respond in real-time, maintain state, etc. If I add an intermediary, can I assume the same?
    • Murta – I think you can, based on how transactions happen today
  • Geimer – Adopting synchronous front-end FHIR interfaces and moving toward near real-time backend solutions (whether FHIR or not)…to anybody interacting it looks like real-time FHIR even if the backend isn’t
    • Bob – Agree, but not specific to the question of volume. If I increase my volume by 10x, do I have infrastructure capable of managing the increase
    • [moved statement to the scaling: lack of predictability and response times issue]
  • Bob – need to increase payer and provider services to support significant increase in real-time transactions embedded in clinical workflow. Transformative to have real-time access for certain functions at the point of care, e.g. validate patient eligibility, request authorization, clinical decision support, appropriate use criteria from specialty care, etc. Right now, information is typically batched and sent later
    • Murta – also need to perceive that capabilities are reliable
  • Existing efforts:
    • Bob – none
      • Geimer – technology exists, but no industry effort to apply them or certify that they have been applied
  • No labels