FHIR Chat · Are search parameters like filters? · implementers

Stream: implementers

Topic: Are search parameters like filters?

Josh Mandel (May 14 2019 at 15:59):

On my reading: if a FHIR search returns a specific set results, then adding search parameters would filter these down to a subset of those results. For example, searching for Condition?patient=123 returns all conditions, and Condition?patient=123&clinicalStatus=resolved returns a subset of all conditions.

However, some implementation have different/special "default" rules, so that Condition?patient=123 returns a restricted set of results. This behavior has surprised me, and caused me to miss out on relevant data in my "fetch all" queries. I've heard similar experiences from @Dan Gottlieb and from @Pascal Pfiffner, with respect to default rules in open.epic.

My take: an app developer following the FHIR spec, or Argonaut / US Core, expects to see all available conditions (and meds, etc) when searching without a status filter. Indeed, the spec and the IGs seem to require it.

e.g. in US Core,

GET /Condition?patient=[id]
Example: GET [base]/Condition?patient=1032702
Support: Mandatory to support search by patient.

I'd like to discuss here. Would someone make a case that it's good for interoperability or patient safety for different EHRs to set different default rules on this kind of search?

Cc @Grahame Grieve @Isaac Vetter @Michele Mottini

Paul Church (May 14 2019 at 16:33):

With default rules, does the search bundle's link.url indicate what search query the server is actually returning?

Josh Mandel (May 14 2019 at 17:08):

Let's assume for the moment that these are reflected in the self link. Does that change your assessment?

Josh Mandel (May 14 2019 at 17:08):

(it doesn't change mine.)

Josh Mandel (May 14 2019 at 17:11):

Forgot to add from the US Core documentation:

Implementation Notes: Search for all problems and health concerns for a patient.

Michele Mottini (May 14 2019 at 17:23):

I would surely prefer that there were no special rules or defaults. Being things as they are we have vendor-specific configuration in our app that generate searches with the necessary parameters.

Michele Mottini (May 14 2019 at 17:24):

(and no, having that information returned in the self link or in an OperationOutcome would not help - you still need to figure out which kind of search you have to generate to get all the data)

Josh Mandel (May 14 2019 at 17:26):

I think vendor specific configuration isn't great -- though realistically we'll probably never get entirely away from it @Michele Mottini . What scares me the most in this case is that the query is handled but silently (or at least, automatically) altered without an http error response -- so a developer is very likely not to notice what is going on. This happened to me and I've heard reports from others as well.

Michele Mottini (May 14 2019 at 17:31):

One example is Epic MedicationOrder - it automatically filters out non-active ones: 'By default, active medications are returned.' (https://open.epic.com/Clinical/FHIR?whereTo=medication)

Paul Church (May 14 2019 at 17:41):

@Josh Mandel It would push me towards acceptable. There are a lot of situations, such as handling=lenient or the thread about the server's discretion to apply only parts of a PUT request that it thinks are appropriate, where the spec is structured as "the server has broad discretion but reports back to the client what it chose to do".

Based on that pattern, if the extra parameters are in the self link at least the client knows what it got.

Lloyd McKenzie (May 14 2019 at 17:43):

The biggest challenge is: If a client didn't get what it wanted, how can it choose to then get it? It's hard to program in advance to accommodate arbitrary extra filters that get added. It's not as though you can just query again with no filters and say "no, this is what I really want!".

Paul Church (May 14 2019 at 17:47):

Considering this from a different angle, the search is always filtered by "resources the client has access to" which could be very opaque. The client often doesn't know the scope of what is hidden, and there are no query terms that will return more.

Do "default search terms" contain some way to convince the server of what you really want? Is there a magic word to get Epic to give you non-active MedicationOrders?

Josh Mandel (May 14 2019 at 17:49):

Indeed, coping/updating queries in-band is unrealistic for all but the most sophisticated clients. I assume the expected behavior is "1. read the docs, 2. recognize where they might contradict the base spec or any IGs, and 3. update your app's query configuration with special cases." Since the docs are long and largely redundant across vendors, 1 and 2 are hard in practice (and 3 is tedious) especially for apps that want to connect dynamically to a variety of API providers.

Josh Mandel (May 14 2019 at 17:50):

I think the "magic word" is &status=resolved,active,...

Michele Mottini (May 14 2019 at 17:50):

I think the "magic word" is &status=resolved,active,...

Yes

Josh Mandel (May 14 2019 at 17:50):

But that's that same as the documented behavior in the absence of this search parameter.

Josh Mandel (May 14 2019 at 17:51):

If Argonaut or US core wanted to eliminate the "bare" API call and document only the call with a status list, that'd be verbose but at least explicit / less surprising. Then a server could refuse queries that lacked a status.

Josh Mandel (May 14 2019 at 17:52):

(I just can't see how that's an improvement over the standard FHIR definitions.)

Danielle Friend (May 14 2019 at 18:29):

Regarding Epic's support - our intent is to represent data as safetly as possible. For medication searches especially, the thought is if by default you only get the active meds this would make it hard to miss represent what the patient is actively taking and avoid unsafe representations of a patient's meds.

I do realize this behavior is hard to know without reading a given server's documentation and that isn't ideal. Maybe it is something we can more formally adopt in US Core/Argonaut profiles if others feel this scenario makes sense or sees a value in it. I'd be happy to discuss it further on an upcoming Argonaut call @Brett Marquard or @Eric Haas

Danielle Friend (May 14 2019 at 18:29):

In what I would consider a more common scenario - it seems reasonable to me that servers would not return "entered-in-error" statuses by default as this information is no longer valid and maybe not even discoverable without the old reference (such as by FHIR ID). What do others think of that type of defaulting scenario?

Lloyd McKenzie (May 14 2019 at 18:34):

The point of an "entered in error" status is that it's deemed important to let others know that the record existed. (Otherwise, you'd just execute a delete.) I guess the question is whether we trust systems to pay attention to 'modifier' elements in resources they retrieve. If they don't do that, there's no way such a system can be safe period. (If they don't check status, there's little chance that they're looking for modifier extensions or at more esoteric elements such as Resource.implicitRules.) I think the community would be better off with consistent APIs but with some up-front checking that systems you connect to have actually looked at all of the FHIR safety rules and do what they're supposed to do. After all, all of the EHRs have processes they use to determine whether a given client/consumer is 'safe' to access the data. It seems that this is something that could be verified as part of that process.

Josh Mandel (May 14 2019 at 18:42):

I agree with Lloyd on this point-- if an app developer doesn't understand the basic essential properties of a medication resource or a condition resource, there is zero chance that developer is going to build a safe app. Trying to fix this through clever defaults won't really put a dent in this.

Josh Mandel (May 14 2019 at 18:42):

to my mind, it would be better to get agreement about this at the level of the base specification rather than in a particular community like Argonaut, unless we think there's really something community specific about the right answer.

Josh Mandel (May 14 2019 at 18:43):

But wherever the agreement happens, it's particularly important that we have a shared understanding of how to make this work in time for the final US Core publication.

Brett Marquard (May 14 2019 at 19:29):

returning 'entered-in-error' and 'inactive' for a unsophisticated client sounds equally scary to me..

Brett Marquard (May 14 2019 at 19:30):

BUT, I completely agree this has to be more clear that the current searches aren't returning 'all'

Lloyd McKenzie (May 14 2019 at 19:41):

"more clear" isn't really enough. The client has to have some degree of control over what's coming back and it's very difficult for clients (without customizing on a per-server basis - which is the last thing we want) to be able to get what they want if a server applies filters by default. When a server ignores certain filters and tells you, the client can let the user know and/or pick up the slack. However, if a server adds extra stuff, the client can let the user know that they're missing stuff, but (without customization) can't actually get the data.

Brett Marquard (May 14 2019 at 19:42):

We already have more than one example of servers not returning everything when status isn't present. I think it's time we revisit including status in the base US Core/Argonaut Queries

Brett Marquard (May 14 2019 at 19:43):

I trust the servers were thoughtful in how they decided to not return all statuses. We should be equally thoughtful in exposing this is a reality of implementations.

Danielle Friend (May 14 2019 at 19:43):

I agree, I would like to revisit the statuses in our US Core/Argonaut IGs. Especially around meds.

Danielle Friend (May 14 2019 at 19:44):

Regarding Epic's search behavior, I do appreciate all the input and feedback - I plan to bring this back to the rest of the Epic FHIR team to revisit and discuss and will let folks know the outcome.

Grahame Grieve (May 14 2019 at 20:09):

so this has tripped patients up, not just app developers. Making a default behavior not to return inactive or deleted medications unless specifically asked to resulted in inactive or deleted medications appearing in a patient's medication list. I've had 3 reports of that from end-users, for different apps.

Grahame Grieve (May 14 2019 at 20:09):

so to be clear: what this was designed to is exactly what it created.

Lloyd McKenzie (May 14 2019 at 20:09):

Can you explain the pathway by which that happened?

Grahame Grieve (May 14 2019 at 20:11):

more generally, if I was going to identify critical safety risk areas in healthcare it, based on practical experience, the list would be
- misidentifying/mismatching patients (and it's special worst case, tripping up over patient merge)
- not consistently deleting information no longer considered current
- truncating text
- missing important qualifying/scoping elements

Grahame Grieve (May 14 2019 at 20:12):

an application that doesn't manage/display status should not exist - or in this care, be certified. And there are multiple steps in the process to check this

Grahame Grieve (May 14 2019 at 20:14):

all applications assumed that when meds were made inactive, their status would change, and so that when medications were removed from the list and were no longer returned, they were just left on the list. leading to the patients to ask why in some channel that lead to me (because there were kind of insiders anyway, which is scary)

Brett Marquard (May 14 2019 at 22:02):

an application that doesn't manage/display status should not exist - or in this care, be certified. And there are multiple steps in the process to check this

@Danielle Friend, @Jenni Syed, @Christopher Kundra , @Danny Wise , @Kenny Blanchette - Do you review Client applications ability to manage/display statuses when approving for your app stores?

Michele Mottini (May 14 2019 at 22:14):

Do you review Client applications ability to manage/display statuses when approving for your app stores?

There is no (and there cannot be) approval process

Brett Marquard (May 14 2019 at 22:16):

Thanks Michele -- are you aware of any client certifying body that all client apps go through? I am not...

Michele Mottini (May 14 2019 at 22:19):

There is no certifying body
US law is that patient should be able to access their data with an app of their choice - restricting access to certified apps (however the certification is done) risks to breach that

Brett Marquard (May 14 2019 at 22:21):

Great, aligns with my understanding :)

Drew Torres (May 14 2019 at 23:20):

I will clarify a bit.

We validate every application in our app store. Our health care systems expect that of us. Michele is right that patient facing applications cannot be forced through validation. A patient has the right to chose an application of their choosing to access the data. NPRM calls out that health systems have the final authority on connected applications, but vendors cannot force themselves in the middle of that process. Applications that aren't validated are not listed on the app store. The app store is not a requirement to obtain access to the APIs, but some health systems do prefer to know that the app has been validated.

With regards to statuses and safety. There is an oversimplification of the problem, and potentially clarification on what the daily life of an EHR vendor is like. I think there is a level of ambiguity on expectations around client/server query and response behaviors. In the example listed in this thread, we returned all medications that have a statuses. We DO NOT under any circumstances return medications that we do not know the status for even though unknown is in the value set. It is clinically unsafe, and we would be putting patient safety at risk. As an EHR vendor, we have responsibilities and processes in place that require us to to take all preventative measures to mitigate these risks and liability. Another example would be data that has been changed to "entered-in-error". We do not return any fields to mitigates concerns around unintended re-disclosure of health information. We return an ID, a status, and all other required fields return displays of "unknown". This is done to understand state change, but nothing else. We will never expose additional details because of concerns around comments/notes that may lead to someone learning information that they shouldn't have known in the first place.

I would ask that instead of trying to "fix" the behaviors of the different servers, we take a moment to understand scenarios in which EHRs would "hide" data, and why it is done. This would then allow the collective community to propose viable options that both mitigates risks, increase patient safety, and improve the exchange of data.

Drew Torres (May 14 2019 at 23:28):

@Grahame Grieve there is no such certifying body in the US. There are examples in our validation process where we have caught developers not paging across the entire data set, not displaying statuses correctly, and not removing/updating resources that are no longer valid. I would love to be able to not let those developers connect, but that isn't possible the regulatory landscape we operate in.

I think one option I have thought of in the past is actually not supporting queries without status filters. This creates a contract where the API consumer explicitly asks for the status they understand and are interested in. This mitigates concerns servers may have about the consumer not understanding statuses. Until some sort of guidance in provided like this, there will always be business rules applied to protect the implementation from undue liability.

Grahame Grieve (May 14 2019 at 23:42):

@Avinash Shanbhag this is at least partially a regulatory problem

Grahame Grieve (May 14 2019 at 23:44):

@Andrew Torres

We DO NOT under any circumstances return medications that we do not know the status for even though unknown is in the value set. It is clinically unsafe, and we would be putting patient safety at risk

I would have thought that not returning information that could be value was also clearly a safety risk.

Drew Torres (May 14 2019 at 23:45):

Most of the time I would agree. Status is the exception to that rule for us.

Grahame Grieve (May 14 2019 at 23:45):

so you have a record of a medication, but you don't know whether it's current or not, so you won't pass the information on? And then the patient dies because the clinician was not alerted to a medication that they might have been on?

Grahame Grieve (May 14 2019 at 23:46):

note, btw: we detest status = unknown. we didn't add it because we think it's a good idea, but because there are lots of legacy records where the status is unknown, and people still need to communicate it (for reason stated just above)

Drew Torres (May 14 2019 at 23:48):

Who is the logged in user accessing the APIs? If it is a licensed practitioner. We would release that information because they understand how to interrogate that information.

A patient using an application that we have no visibility to? There is no perfect answer. We took the route recommended to us by physicians, and the guiding principles we have in place.

Grahame Grieve (May 14 2019 at 23:52):

hah - treating it differently? well, I can see the sense in that. And I appreciate that whatever you do has trade-offs. In fact, that's kind of my point here. But actually, I'm worried about a longer term point - the tradeoffs that have been chosen scope limit the API to a particular set of uses that will become problematic in the longer term because they assume current information only, and past information - records of past encounters, documents, and decisions made in particular - are going to be a problem given the short term decisions made

Drew Torres (May 14 2019 at 23:56):

That is completely fair. In the race to expose APIs to meet regulations, things like this were left for different systems to figure out along the way. I know I have asked about "defaulting" behavior in the past, but competing priorities and timing are challenging to manage.

Lloyd McKenzie (May 15 2019 at 01:09):

One of the challenges with limiting patient access is that in some cases (e.g. an iPhone), the patient may be the conduit for information to another practitioner.

Michael Lawley (May 15 2019 at 11:17):

I'm also a little confused about the intersection of the patient's right to access their data with an app of their choosing and then the provider deciding that only some of that data will be made available.

Avinash Shanbhag (May 15 2019 at 13:19):

Hi, thanks for tagging me on this thread. If you think this merits any regulatory guidance, then would suggest submitting feedback to the NPRM ( due date is June 3rd). Additionally, just out of curiosity, would like to hear additional insights from App developers, in their expectations of the API response.

Jenni Syed (May 15 2019 at 14:02):

@Grahame Grieve one clarification on the unknown status: in our underlying system, we should always know the status. When Drew said "unknown" that is more of a mapping issue in our system (something unexpected happened and for some reason we couldn't get to a FHIR status). We don't have any state in the underlying system that supports the concept of an unknown. If we hit this unexpected scenario in FHIR, we actually error the whole request - the server has been misconfigured

Jenni Syed (May 15 2019 at 14:03):

And it throws an alert to us to tell us something isn't configured correctly - so we know to go fix it. This is most common when we initially are building out mappings

Jenni Syed (May 15 2019 at 14:06):

As Drew mentioned, we have caught (many times) apps that don't pay attention to any of the statuses on resources. Even though it's part of the safety checklist (most of them have never heard of that). The errors those cause vary and go all the way to extremely scary (showing in error data as if it's accurate), or just slightly less so of showing inactive meds as if they're active.

Jenni Syed (May 15 2019 at 14:07):

But we are not allowed to do similar checks for patient access apps. The reason this is especially worrisome: we catch these with app vendors that have been in the healthcare field as their primary business for a while

Jenni Syed (May 15 2019 at 14:07):

and have all the best intentions

Jenni Syed (May 15 2019 at 14:09):

I think assuming that patient access apps are going to be built by only those with good intentions, or that have been in the healthcare field for a long time is a bad assumption (and putting the burden on patients to determine safety and privacy risks of an app they download is expecting a lot)

Jenni Syed (May 15 2019 at 14:11):

Even expecting providers to be able to do this in depth analysis of a practitioner-facing app means you expect a lot of FHIR-specific knowledge to be built, as well as web security knowledge

Brett Marquard (May 15 2019 at 14:37):

From my view, everything in this chain keeps pointing to explicitly including status in the query.

Lloyd McKenzie (May 15 2019 at 14:38):

You mean making it mandatory to specify the desired statuses?

Jeffrey Danford (May 15 2019 at 14:39):

Putting rules around what data is returned puts us in a "well it depends" scenario that defeats what we're trying to accomplish. The response should be an accurate representation of the data based on what's being asked for in the query. Doing otherwise results in what @Michele Mottini has done - include vendor-specific rules to interpret the results. Conceivably we could end up with a situation where every app developer must code specifically for each service (to account for it's rules) and each server must code specifically for each application (what's "safe" to send to them).

Jeffrey Danford (May 15 2019 at 14:42):

Having said that, Allscripts also incorporates business rules into our results, including filtering by status (e.g. only sending lab Observations whose status is final). We have the same concern that not everything we send out will be properly handled by the receiving app. Which gets back to implementing an app certification process - we'd feel a lot better sending out data if we knew the app would be handling it appropriately.

Jenni Syed (May 15 2019 at 15:02):

I'm not actually sure that requiring the statuses in the request help this. Grahame's example is a common miss: You may not want to show inactive or in error meds, but you sure are going to need to query for them if you're storing or caching data from previous calls. Otherwise, you won't know to remove something from the list.

Jenni Syed (May 15 2019 at 15:04):

S4S and Apple Health are examples of that use case in the wild.

Chris Moesel (May 15 2019 at 15:08):

Just seeing this thread now, but completely agree with @Josh Mandel and will add my name to the list of people who have been bitten by vendors adding their own special rules regarding default queries. More specifically, I had an app for which historical med data was important -- so one vendor's choice to return only active medications caused some confusion in testing. Developers of interoperable applications (like SMART Apps) cannot read the documentation of every Health IT product w/ a FHIR interface. The point of standards is to allow some basic assumptions to be made -- and this specific topic (behavior of search queries) falls into that category for me.

IMO, If we want to allow vendor variance in areas like this, then the FHIR spec should explicitly call out these areas where vendors are allowed to add their own rules. That way responsible app developers who do know and understand the FHIR specification aren't burned and know to program more defensively in those spots. And if this is allowed, then I think there needs to be a mechanism for the client to know that additional non-standard rules have been applied. But my personal preference is that a "standard" should be implemented in a "standard" way across all vendors as much as is possible.

Jenni Syed (May 15 2019 at 15:12):

Note: I'm not against requiring a specific parameter to be set in an implementation (and erring if it's not there) if a server doesn't support the "default get everything" query.

Jenni Syed (May 15 2019 at 15:14):

This is pretty common for the patient or subject parameter, for example. If it's not set, the server will error vs. defaulting

Yunwei Wang (May 15 2019 at 15:52):

developers of interoperable applications (like SMART Apps) cannot read the documentation of every Health IT product w/ a FHIR interface.

I don't agree. developer shall read the documentation of every Health IT that he want to connect to.
My app targets three EHR vendors. I did read all of them. I would be surprised if there's any SMART developer who do NOT read server documents.
My concern is that server may change the "default" behavior in the future release and mess up client implementation logic.

Chris Moesel (May 15 2019 at 18:48):

I don't think that reading documentation of every health IT product scales. Yes, if you're targeting three vendors, sure. But there are way more than three vendors out there that support FHIR -- and part of the point of SMART (I think) is to one day support an App Store paradigm that is at least partially vendor-agnostic. Things are a whole lot easier if we can set some ground rules that allow vanilla apps to work across the widest variety of vendors' products. If vendors have to rely on app-developers specifically targeting their system, I worry that the smaller vendors will have a real hard time surviving in the future marketplace.

Chris Moesel (May 15 2019 at 18:50):

It just reminds me a little of all those websites and web libraries that targeted (and grew to depend on) non-standard quirks in early web browsers. The beauty of the modern web standards is that as a web developer, I can worry a lot less about what browser someone is using (although we're not 100% there yet).

Yunwei Wang (May 15 2019 at 21:08):

In reality, each server has its own capability. You cannot expect all servers support the same set of resources and same set of search parameter. I cannot image how a client developer can get that information w/o reading vendor documents no matter how many system he want to connect. IMHO, the beauty of FHIR is that it sets the framework and certain flexibility at the same time. If we want to one modal for all, why don't we just use CDA?

Lloyd McKenzie (May 15 2019 at 21:12):

Adapting to some servers supporting different bits is something you can do at run-time by hitting the CapabilityStatement. You don't necessarily need to write server-specific code to deal with that. But if servers require that queries be constructed on a custom basis, that's something different.

Chris Moesel (May 15 2019 at 22:00):

Right. Any variation that can be described in the CapabilityStatement is totally fair game.

Chris Moesel (May 15 2019 at 22:00):

That's what it's for.

Yunwei Wang (May 15 2019 at 23:09):

We are already off topic. Again, what I don't agree is that "developer cannot read document of all servers he want connect to". I don't mind to continue our discussion in separate thread

Grahame Grieve (May 15 2019 at 23:10):

@Avinash Shanbhag I think that one part of this is tricky - the question of the safety of apps for the patient. If the US Govt requires patients to be able to choose their apps - for very good reasons - where can a patient turn for a good app that's reliable? if supposedly experienced healthcare developers can't get the basics like checking status correct, what does the govt expect to happen for patients?

Grahame Grieve (May 15 2019 at 23:11):

I know that no one pays attention to the safety checklist. I wonder whether we can extend the application registration process to include some basic declarations that an application must make. @Julie Maas - what if we extended it so that a server could require some specific values somewhere, and document those as linked to the safety checklist?

Michele Mottini (May 15 2019 at 23:12):

we can extend the application registration process

Which registration process?

Grahame Grieve (May 15 2019 at 23:14):

Julie and Luis Maas run a track at the last connectation looking at dynamic application registration. It's applicable for patient apps, and also enterprise/x-enterprise apps

Michele Mottini (May 15 2019 at 23:15):

Thanks - did not know that

Grahame Grieve (May 15 2019 at 23:15):

I'd like to see that approach become much more ubiquitious, and it's basically required for the NPRM but it isn't called out

Julie Maas (May 15 2019 at 23:54):

That makes a lot of sense--this is exactly the type of information that the certifications extension is intended for (http://www.udap.org/udap-dynamic-client-registration.html). An app can already self certify to conforming to a linked privacy policy, redirect URI etc. and server can make policy decisions using that info. Additional self assertions about safety checklist items could easily be added: https://www.hl7.org/fhir/safety.html. Third party validation could be added on with the same mechanism plus a step to validate the endorser when needed.

Grahame Grieve (May 16 2019 at 00:41):

So I should enhance that page to give each of those entries in the list a formal uri then

Julie Maas (May 16 2019 at 01:19):

Maybe yes--if a summary declaration of conformance with the entire checklist is not sufficient/more useful (or applicable subset of list related to clients). Question for the community: Does it always need to be item-by-item? Would relying parties realistically want to parse through 42 of these elements (plus the others already mentioned) or would there be a natural minimum bar that would make sense as a threshold for "safety checklist" compliance for a given checklist version #?

Grahame Grieve (May 16 2019 at 01:25):

I think different kinds of systems would have different concerns, and would want to be specific about the concerns they have. Based on the discussion we’ve had here.

Grahame Grieve (May 16 2019 at 01:25):

It wouldn’t be all of them, I think

Grahame Grieve (May 16 2019 at 01:28):

E.g. for an Argonaut server, I’d be interested in rules 1, 2, 4, 5, 8 and 11 (though we could come up with a more appropriate wording of those for the specific EHR access problem in the US-Core guide)

Grahame Grieve (May 16 2019 at 01:29):

At the least, I propose that we add a safety page with a check list to US-Core R4 before we publish it (though that may be challenging timing wise)

Lloyd McKenzie (May 16 2019 at 03:07):

I think part of the challenge is that servers should not make assumptions about the use-case of their clients. The EHRs created their interface with a presumption that it was going to be used by patient-centric apps and focused on meeting meaningful-use criteria - specifically the ability to share a list of a patient's active medicaitons. But the MedicationRequest query endpoint isn't intrinsicly use-case specific and there are lots of valid use-cases for retrieving things other than the active med list (and for performing queries that aren't patient-centric). It is certainly ok to have limintations in query parameters that focus on the initial use-cases for a first release, but default filtering for a presumed use-case is more problematic. Lack of search parameters doesn't prevent a use-case from being satisfied, it just makes it inefficient. But automatic filters can prevent a use-case from being predictably satisfied at all. Eventually, the EHR MedicaionRequest endpoints will likely need to expose draft ordrs, recommendations that came in as part of a referral response from 5 years ago and all sorts of other MedicationRequest instances that have no relationship to the "active medication list" at all - but for which there's absolutely a valid use-case for exchange. (And as that evolution happens, we'll start to see some of the pain of not having List to filter the sets of records that are truly part of the active med list as opposed to being resources that are part of the record for other reasons.)

Cooper Thompson (May 16 2019 at 12:35):

Chiming in a bit late, but I think we need to recognize the split between FHIR "insiders" vs. "outsiders" as client developers. I'd estimate that ~95%+ of the app vendors we deal with don't know or care about the FHIR spec. They just want data, an if we gave that to them in a CSV, custom JSON/XML, HL7v2, or valid FHIR response, they wouldn't care either way. They will never be parsing CapabilityStatement in a meaningful way. The other ~5% are the insiders like @Michele Mottini and @Josh Mandel who understand both the FHIR spec and the complexities of healthcare data. EHR vendors are in the position where we need to support both sets of users. My experience is overwhelmingly that we cannot expect the majority of clients to handle the complexity of healthcare data on their own.

Jeffrey Danford (May 16 2019 at 12:51):

Speaking from the server/EHR vendor perspective, the basic issue is a lack of comfort about how the data will be used once it leaves our curatorship. Some sort of app certification process or a registration process (dynamic or otherwise) based on an agreed-upon set of rules (no idea how that would work) would go a long way towards increasing that comfort level.

Grahame Grieve (May 16 2019 at 12:52):

the counter point is : it's left your curatorship. So you don't need to be concerned about it

Grahame Grieve (May 16 2019 at 12:52):

it's an interesting problem, since we are taught to worry about this

Cooper Thompson (May 16 2019 at 12:54):

In many ways this is a no-win scenario for the EHR vendors. If we develop our API to support the 5% insiders, then the 95% will end up misusing or misrepresenting the data. If we target the 95% outsiders, then the 5% insiders will be unhappy.

Cooper Thompson (May 16 2019 at 12:55):

@Grahame Grieve I don't understand your comment about curatorship. Don't the (older) MU3 and current ONC NPRM explicitly remove the ability of EHR vendors to act as curators? At least in the US.

Grahame Grieve (May 16 2019 at 12:56):

I think that the split is not so simple as that. Anyway, where we've ended up is... the 5% who know what they're doing end up displaying non-current information as current, while those who don't know any better... will eventually discover they are missing data and they'll ask for it and (probably) still display it wrong

Grahame Grieve (May 16 2019 at 12:57):

that's what i meant: once the patient gets it, what follows is not the EHR vendors responsibiblity

Cooper Thompson (May 16 2019 at 12:59):

At least for the Epic implementation, I don't see the split as current vs. non-current data. It is more about relevant vs. non-relevant. The data we return in our API is the same data we have determined is appropriate to show the user when they are operating within the EHR UI.

Josh Mandel (May 16 2019 at 13:00):

I'll push back really hard on the "insider/outsider" concept @Cooper Thompson. I mean, I agree that most developers on any platform just want to get the data, and they'll jump through whatever hoops necessary. But we're here talking about predictable behavior -- standards for interoperability.

Josh Mandel (May 16 2019 at 13:02):

If a platform is going to offer an interoperable API, I can't see the rationale to tweak it with defaults that will be inconsistent with other implementations.

Josh Mandel (May 16 2019 at 13:02):

I'm not sure what that has to do with the concept of "insiders and outsiders".

Cooper Thompson (May 16 2019 at 13:04):

@Josh Mandel My insider/outsider comments are driven by my real-world experiences to date. I've been on design or troubleshooting calls or e-mail chains with vendors probably ~5-10 times per week for the past several years. I'm just trying to represent the reality of FHIR use today. I'm open to practical and implementable solutions that move the needle, but, for example, the calls with S4S and MyFHR developers go very differently than the calls with most other app developers...

Josh Mandel (May 16 2019 at 13:06):

And can you say something about how your 1000+ email threads relate to the question about default search parameters?

Josh Mandel (May 16 2019 at 13:08):

I'm all and pretty much only about "real world experience". So if there are pervasive developer usability issues, we want to treat those as bugs in the spec.

Cooper Thompson (May 16 2019 at 13:13):

Typically the "default search parameters" are just a way to allow the EHR to make sure the data that is returned in the API matches what is shown to clinical users inside the EHR. Within the EHR, we often have some sort of "more info" or "show all" button that clinicians can use to get the full picture, but a lot of time and effort has gone into determining what data is relevant to show in the primary lists. E.g. if a resident ordered a bunch of labs the the supervisor determined those labs were unnecessary and canceled them (prior to specimen draw), then it normally isn't useful to show those canceled labs to users 6 months later. The way I understand this thread is that we want to replicate the "more info" option that we have in the EHR (which today we support by the documented additional (vendor specific, but spec compliant) search parameters that can be provided).

Cooper Thompson (May 16 2019 at 13:15):

One solution is to return everything by default with some sort of flag to indicate if it should be in the "default" view. However this means we have to just "hope" that clients will understand that flag. And I'm very much pessimistic about that.

Michele Mottini (May 16 2019 at 13:17):

What about instead of filtering by default make the corresponding search parameter required? So the client has to specify what it wants (and for the 95% just tell them 'do the search like this')

Grahame Grieve (May 16 2019 at 13:21):

I follow the logic for matching the system standard view. I feel that matching a no parameters query to the limited system view is where we get into trouble. Given your concerns, I would:
- refuse to answer any query that doesn't explicitly say which status codes to return
- explain in the return error that you either specify the status codes, or use something like argonaut-view=default to request what would be the default view in the system
- support the default-view parameter
- publish a safety check list - preferably through Argonaut
- ask applications to confirm that they've done the checklist on registration

Cooper Thompson (May 16 2019 at 13:23):

I kinda like the idea of pre-defined"views". Let me chew on that.

Josh Mandel (May 16 2019 at 13:25):

On the interaction between "default views" and the meaningful use requirements in, USCDI it's just "medications" as far as I'm aware. Does someone have a reference to a requirement like "active medication list"?

Jeffrey Danford (May 16 2019 at 13:26):

You're seeing years of institutional memory, guidance from clinical SME's and HIPAA-ingrained reflexes in that curatorial(?) instinct that's going to take a lot to overcome. And FWIW I do agree that we shouldn't be applying our own business rules and the query response should be faithful to what was requested. There's just a lot of uneasiness that isn't mollified by being told not to be concerned.

Grahame Grieve (May 16 2019 at 13:29):

I think I might blog about this. There's basically a tension here between safety and access. as a long term HIT person who's seen people die due to bad interop implementations, I understand how absolute the culture is around this and that's completely appropriate.

Grahame Grieve (May 16 2019 at 13:30):

@Dave deBronkart subscribing you to this stream- you should read this thread from start; I'm interested in your perspective on it - the problem is real

Cooper Thompson (May 16 2019 at 13:31):

Do we want to include security filtering in this discussion as well? Or keep that out of scope? E.g. if the requesting user doesn't have authorization to see data in the behavioral health department, so that data is also not returned in the open-ended default query.

Grahame Grieve (May 16 2019 at 13:31):

that data is never returned whatever. even if you ask for it, and you can not find out

Jenni Syed (May 16 2019 at 14:12):

@Grahame Grieve and @Josh Mandel Even though our server defaults to "all statuses" if you don't pass in any status filter (in error etc), I can provide the stat that 0 times has any app made it through our validation without an issue found

Jenni Syed (May 16 2019 at 14:13):

and that crosses both people with experience in the spec and people new, people with experience in healthcare and people new to it

Jenni Syed (May 16 2019 at 14:13):

*without a safety issue found

Josh Mandel (May 16 2019 at 15:04):

That makes sense @Jenni Syed; but how many of these problems do you think are directly attributable to issues with default status parameters?

Josh Mandel (May 16 2019 at 15:04):

(I'm not disputing that developing health apps correctly is hard and important and requires feedback/experience/iteration)

Jenni Syed (May 16 2019 at 15:11):

We have no default status parameter

Jenni Syed (May 16 2019 at 15:12):

if you pass no status, you get everything

Jenni Syed (May 16 2019 at 15:12):

which is what the spec describes

Jenni Syed (May 16 2019 at 15:20):

We have had issues in apps that both define their status list and leave it as the "everything" (in error etc)

Lloyd McKenzie (May 16 2019 at 16:55):

@Cooper Thompson "Relevant" presupposes a known use-case. The API should not do that. The whole point of REST is that the API is use-case independent. It's not supposed to reflect what's on a particular screen or view. It's supposed to reflect all data that fits that resource category that's available from the persistence layer of the system. Consumers of the API then filter to reflect whatever their use-case happens to be. The key is to make sure that app implementers expect the feed to contain non-relevant data - and know that it's their responsibility to filter accordingly.

Lloyd McKenzie (May 16 2019 at 16:55):

(And test sites should ideally include liberal amounts of non-typically-relevant data so they learn early :>)

Josh Mandel (May 16 2019 at 17:53):

We have had issues in apps that both define their status list and leave it as the "everything" (in error etc)

Right, and I think highlights my point: you can't solve deep issues with developer knowledge/attention by tweaking defaults. You'll have issues ether way, so you might as well make defaults that are consistent with the standard.

Julie Maas (May 16 2019 at 18:59):

At the least, I propose that we add a safety page with a check list to US-Core R4 before we publish it (though that may be challenging timing wise)

Is there something I can help with here, or a starting point someone can point to? Thx in advance!

Eric Haas (May 16 2019 at 19:09):

All the trackers from the US Core R4 from the ballot have been applied and it is undergoing QA and just about ready to be published. There is a planned "STU Update" for the Fall closer to the ONC Rulemaking deadline. We will be take up this issue on the Argonaut R4 call.

Grahame Grieve (May 16 2019 at 22:37):

yes please take it up.

Josh Mandel (May 17 2019 at 00:07):

Can you let me know when this will be? I don't generally have the time free but I will try to make it available.

Eric Haas (May 17 2019 at 00:56):

not next week

Dave deBronkart (May 18 2019 at 20:09):

I agree with Lloyd on this point-- if an app developer doesn't understand the basic essential properties of a medication resource or a condition resource, there is zero chance that developer is going to build a safe app. Trying to fix this through clever defaults won't really put a dent in this.

Well observed and well articulated.

Dave deBronkart (May 18 2019 at 20:22):

[Does this branch need to get renamed?]

The following must be read with awareness that I haven't read (and am unlikely to competently absorb) FHIR safety rules or anything else. I don't have the background or bandwidth to claim competence on it. Having said that, I think I understand the issue; I can loosely understand the issue, what's going on in the sample URLs, etc.

[From Grahame]
Dave deBronkart subscribing you to this stream- you should read this thread from start; I'm interested in your perspective on it - the problem is real

Dude, no wonder I had trouble finding this thread from your email - your email cited "patient safety" which is absolutely true but not mentioned verbatim. Hey, this is almost meta: How would I inform you algorithmically that what I queried in your data store (the thread) was not found, even though it's there? (I know that's not the same as inactive rx; work with me here...)

I have a feeling that some queriers basically want to say "Hey system, tell me everything I need to know, and don't screw up." And some servers prefer to be passive-aggressive, saying "If you want a useful response, you can bloody well be explicit about it, or don't blame me." Who's responsible, and what can be done about the dysfunction / lack of accepting responsibility?

Yes, this is real, and it's really really hard for either party to know what datum might blow up in one's face - especially since the answer to that may change as the patient history gets older and as patient circumstances get added. Right?? Is this solvable? So how can one judge who should bear responsibility? Responsibility connotes having the wisdom and facts to avoid danger and to warn at appropriate times.

In clinical reality does the issue get more predictable after N days of a patient encounter? Perhaps not reliably so.

To really handle issues like this well, we should recruit seriously experienced care coordinators (e.g. years-long care managers for elder family members) who have the scars and savvy to help us consider real-world hazards. Names that come to mind are Janice McCallum and Maryanne Sterling. And I bet they'll say they want at LEAST a read-only "view window" to check on the daily chatter ... people like those two could absolutely qualify as competent for that.

In fact, what a hot idea - enrolling "atrics" caregivers (pediatrics and geriatrics). At the other end of the lifespan there are numerous parents of seriously sick kids who have all too much experience with the need for bedside vigilance, having repeatedly rescued their sick kids from accidental harm. Tyson Ortiz is one of these.

All three of them are members of SPM, not surprisingly.

Ricky Bloomfield (May 19 2019 at 21:45):

Hey, folks! Sorry for the late reply here, I'm just catching up. Here are my observations:

• One of the most important principles in safety is consistency. This is the entire point of Atul Gawande's book, The Checklist Manifesto. No matter the intention, we are actively creating and perpetuating a patent safety issue if the standard is inconsistently applied.
  • The example given by @Jenni Syed is perfect: "I can provide the stat that 0 times has any app made it through our validation without an issue found" - this is exactly the outcome I would expect with inconsistent implementations across vendors.
• On the issue of the implementation itself, I don't have a super strong opinion. The current convention of passing along all data if no status is specified seems to be the most logical and future-proof (i.e., if a new status is ever added in the future, it would still work as expected), but explicitly requiring statuses would also be acceptable assuming it was implemented by everyone consistently.
• EHR vendors can't make assumptions about how data will be used by apps that consume the API. We ran into this early because some EHR vendors assumed data would be queried each time and never persisted. As has been mentioned, this is why returning entered-in-error and inactive status is critical vs simply not sending anything anymore.
  • As an example, @Cooper Thompson pointed out that one of their goals is to ensure that the data "returned in the API matches what is shown to clinical users inside the EHR." This is reasonable on its face, but makes the assumption that all apps will behave like their EHR, or has the same access to historical data as their EHR.
• Agree with comments above by @Chris Moesel that reading the documentation of all vendors doesn't scale. Does anyone believe that OAuth 2.0 implementors read the documentation of every site where it has been implemented, or do they refer to the IETF specs? Same should be true here - the US Core or Argonaut IGs should be the source(s) of truth for documentation.
• Data is not the responsibility of health systems or EHR vendors once it leaves the system, assuming the app developer is not a business associate of the covered entity. This question has been laid to rest ages ago and is described in more detail on the OCR FAQ page here.

Where do we go from here? Some thoughts:

• We should align on one approach. I agree with @Josh Mandel that it makes the most sense to do this as part of the base spec, although having the conversation as part of the Argonaut R4 discussions would also be fine, assuming the outcome was applied to the base spec.
• It would be more valuable to provide a comprehensive safety overview/how-to for inexperienced developers along with a consistent API than it would be to attempt to protect developers from themselves in inconsistent and dangerous ways (which is current state). Agree with @Julie Maas that we should try something like this.

Tagging @Grahame Grieve and @Dave deBronkart as well.

Luis Maas (May 20 2019 at 19:24):

This is such an important topic! I fully agree that apps should understand and properly handle the full resource life cycle, especially the entered-in-error status. With regard to apps that locally persist resources, I think we also need to look carefully at other ways resources may become "invalid" with respect to an app's use case where resource status might not communicate this. A few observations:
1. It seems to me that any time a resource element that is a Reference is updated, this could cause resources to no longer be valid for the app's use case, and could also prevent the app from receiving any future updates about status changes. In the simplest example, if an Observation resource is updated to change the subject reference, it will no longer be a valid Observation for the original patient and will simply disappear for an app that only has access to the original subject's Observations (i.e. the app will not receive a status change).
2. I expect some will argue that a server should never allow the subject of an Observation to be updated, and should instead mark the original resource as entered-in-error and create a second resource with the correct subject reference, but I don't think that this part of the formal FHIR spec (? @Grahame Grieve ). It gets more difficult to manage when apps rely on chaining in their searches, so if such a rule were imposed in the interest of safety, it should probably be extended to prohibit changing any element of an existing resource that is a reference. I don't think such a rule would be very popular.
3. It gets even worse if an app is "deauthorized" from a particular resource after it has retrieved it, because if that resource's status is later changed to entered-in-error or the resource is otherwise changed in a clinically relevant way, the app will not receive the update.
4. Patient unmerge/unlink: similar to #1.
5. Given the above, it seems that there is no easy way for an app to be certain it is synchronized with a server's database using only RESTful calls; to be fully protected from the above, it may need to repeat queries for all data it wishes to persist every time and remove or otherwise invalidate any locally persisted resources that had "disappeared" from the search results. It seems like this might be a best practice from a safety perspective. Grahame touched on this earlier in the thread in the context of medication lists.
6. It follows from 5 that apps that use a _lastUpdated parameter in their searches set relative to their last search would have no way to determine that a previously retrieved resource had disappeared, and are vulnerable to persisting data that becomes clinically invalid for one of the above reasons.

Dave deBronkart (May 20 2019 at 19:40):

* As an example, Cooper Thompson pointed out that one of their goals is to ensure that the data "returned in the API matches what is shown to clinical users inside the EHR." This is reasonable on its face, but makes the assumption that all apps will behave like their EHR, or has the same access to historical data as their EHR.

I'd think the word "matches" is a recipe for mischief, true? Both the encoding and the display of data, as perceived and interpreted by the reader, can be substantially affected by context and by user experience, both within that EHR (e.g. Cerner) and within that institution, yes?

Lloyd McKenzie (May 20 2019 at 19:52):

EHR screens are use-case-specific. FHIR APIs should be use-case agnostic. Expecting them to expose exactly the same data isn't appropriate/reasonable.

Grahame Grieve (May 20 2019 at 21:46):

@Luis Maas that's a good list. There's some really tricky stuff there - the app might decide how to proceed differently between the entered-in-error case and the security withdrawn case, but I don't think it can separate them.

I strongly believe that subject should never be changed - if you created something with the wrong subject, you should not just 'fix' it. But in practice, lots of systems do just that

Pascal Pfiffner (May 20 2019 at 22:20):

Adding to Luis' list, data may also become unavailable because of storage policies on the server, e.g. a server only making data available for the past 5 years. So an app is not seeing a resource again doesn't mean that a resource has been deleted or entered-in-error. And who knows what HTTP status such a server can return for data that's no longer available.

Grahame Grieve (May 21 2019 at 02:11):

http://www.healthintersections.com.au/?p=2950

Grahame Grieve (May 24 2019 at 03:24):

GF#22500

Michele Mottini (May 24 2019 at 12:49):

OK...but do we agree that system should _not_ silently add default filters? Like automatically returning only the active medications when the client requested all of the?
And if system are concerned about that they should rather made search parameters mandatory - like you have to always specify the status when searching medication?

Grahame Grieve (May 24 2019 at 12:57):

yes there seems to be general in principle agreement about that in principle, but it's not clear how to transition to an actuaal agreement about that

Grahame Grieve (May 26 2019 at 21:42):

Follow up on this - I added http://build.fhir.org/codesystem-safety-entries.html to support formal computability around the safety checklist. I expect that this list will grow as argonaut etc add their own check list variants. There’s a task for FHIR-I to approve this change. (Use as a URI is explained here: http://build.fhir.org/safety.html)

Last updated: Apr 12 2022 at 19:14 UTC