Alix Goss

Bob Dieterle

Patrick Murta

Dan Chaput

Diana Ciricean

 

Deliverables

Alix - 3 focus areas for March: define issues, describe regulatory barriers, summary of relevant industry efforts

  • Patrick – will aim to have a rough draft overview of relevant industry efforts by next call (3/21)

 

Issue: Scaling

Bob – multiple current models for interoperability between providers and payers (e.g. hub/spoke, point-to-point) create challenges in adopting standards for scaling FHIR

  • Dan – is it just scaling, or are we talking about something like what do you do if you query 5 endpoints but only hear back from 4? Each node is going to have a set of issues
    • Alix – is this a performance issue?
    • Bob – similar to an SLA…if you are going to participate you have to agree to a certain response time

 

Bob – When we think about intermediaries, they don’t normally deliver real-time responses (b/c they often do data validation, data conversion, etc.). If I’m in an environment where I need data in real-time (e.g. clinical workflow), can I rely on validation/transformation process in the middle and meet my performance requirements?

  • Alix – Then does this fit under the first bullet (about models) or second (about performance)
    • Bob – include it under performance

 

Bob – Real-time interactions involving FHIR require predictable availability and response times.

  • Alix – is the issue that we need to implement standards?
    • Bob – let’s add a second part: scaling real-time transactions requires infrastructure that existing intermediaries may not currently offer
      • Dan – either requires predictable availability/response time, or it needs a business process for dealing with unpredictability
      • Alix – If you can’t be predictable, you need a methodology for communicating lack of predictability
      • Bob – recognize that there are certain things that inherently have unpredictable response times and account for those in design. On the other hand, there are certain things that require real-time responses and a built-in failure mode is unacceptable (e.g. heart monitor in ICU can’t have unpredictable response time).
      • Dan – in tolerance vs. out of tolerance vs. failure
      • Bob – If I’m going to design something that allows for asynchronous response, I’m accepting the fact that I won’t have predictable responses…real-time environments necessitate a predictable response
      • Alix – what about a scenario where an intermediary sends a real-time response indicating that the actual response will be available in a day?
      • Bob – e.g. I’m a provider preparing to order advanced imaging and checking to see if it requires prior auth…if the response time is unpredictable I won’t use the system. Even if human processing is required, I’d expect to receive a response indicating as such within a predictable timeframe

 

Bob – There is no current process for universally determining all endpoints that have information for a specific patient

 

Bob – The lack of a unique patient ID and the probabilistic nature of patient matching create an environment in which positive identification of a patient (and association with their records) is problematic

 

Bob – There is currently no reasonable model to predict the volume of FHIR-based transactions as FHIR is broadly adopted

  • Bob – once we have the ability to do things in real-time, we will start doing things we hadn’t considered before, which will create transactions where none had existed. E.g. when I schedule a patient appointment I’ll ask the payer for gaps in care, or look for data outside my system. Potential to hit a system after virtually every interaction I have. Consider feedback from patients in real-time (e.g. intervening if a patient isn’t taking medications)
  • Alix – are there other scaling challenges we haven’t considered, and is that another issue or did we capture it here?

 

Bob – Increased availability of real-time transactions between payers, providers, patients, and third-party services will exponentially increase transaction volumes.

  • Alix – what is the difference between this and the other volume issue?
    • Bob – we can combine them into one…it’s cause and effect

 

Regulatory Barriers

Bob – initially tried to consider policy for all of FAST, not specific to this Tiger Team.

 

HIPAA minimum necessary – almost impossible to manage when we have real-time access to patient records (and don’t have person in the middle to interpret). “I know it when I see it” can’t be automated.

  • Bob – the problem today is that we can’t satisfy minimum necessary. E.g. as a payer, I have no idea how you’ve recorded things in your record, so I don’t know what to ask for. Instead I ask for things generically. The responding provider then doesn’t know what the payer wants, so they send the whole record or send a part of it and live with the fact that they might get follow-up requests for more info. Real-time access to patient records changes the paradigm, because there is no way to appropriately/consistently build a boundary for determining what to make available
    • Dan – you need HIPAA rules that can be turned into computable logic
    • Bob – recommendation is that “minimum necessary” is essentially replaced with a BAA…you must declare at time of request the purpose for which you are using something, and may not use it for any other purpose w/o permission. The way we record information today isn’t fully structured and we haven’t agreed upon standard terminology for everything we do. E.g. should we be restricting access to information out of a federally funded substance abuse center if it’s nothing more than BMI/blood pressure? No. Where it came from is more “important” than what it is.

 

HIPAA mandatory transactions

  • Bob – have finally started addressing this in the recent NPRMs with language that says you can move to a newer version of a standard as long as it doesn’t break what you’re currently doing. HIPAA transactions still don’t have that (e.g. not allowed to use FHIR to check eligibility in real-time, must use an X12 transaction)

 

Patient identifiers – w/o a unique patient ID, we must rely on probabilistic matching which can cause errors

  • Bob – people using an acceptable probabilistic match shouldn’t be subject to penalties (e.g. lawsuits, disclosure requirements) due to errors

 

Data blocking

  • Bob – if you are going to start creating patient consent around subsets of a record, the provider that receives the record w/o full disclosure about what has been redacted should not be held liable for the outcome of using that record
  • No labels