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