FHIR Chat · patient search

Stream: implementers

Topic: patient search

Jayashree Surnar (Jun 15 2017 at 06:04):

hello all, we are using HAPI-Fhir server,present i'm trying to test RESTful API Operation in fhir. as part of patient operations i looked at the $match. when i send a request to server like this

url : http://fhirtest.uhn.ca/baseDstu3/Patient/$match
json body:

{
"resourceType": "Parameters",
"id": "example",
"parameter": [
{
"name": "resource",
"resource": {
"resourceType": "Patient",
"identifier": [
{
"use": "usual",
"type": {
"coding": [
{
"system": "http://hl7.org/fhir/v2/0203",
"code": "MR"
}
]
},
"system": "urn:oid:1.2.36.146.595.217.0.1",
"value": "12345"
}
],
"name": [
{
"family": [
"Chalmers"
],
"given": [
"Peter"
]
}
],
"gender": "male",
"birthDate": "1974-12-25"
}
},
{
"name": "count",
"valueInteger": "3"
},
{
"name": "onlyCertainMatches",
"valueBoolean": "false"
}
]
}

i'm getting this error .

{
"resourceType": "OperationOutcome",
"text": {
"status": "generated",
"div": "<div xmlns="http://www.w3.org/1999/xhtml"><h1>Operation Outcome</h1><table border="0"><tr><td style="font-weight: bold;">ERROR</td><td>[]</td><td><pre>Invalid request: The FHIR endpoint on this server does not know how to handle PUT operation[Patient/$match] with parameters [[]]</pre></td> </tr> </table> </div>"
},
"issue": [
{
"severity": "error",
"code": "processing",
"diagnostics": "Invalid request: The FHIR endpoint on this server does not know how to handle PUT operation[Patient/$match] with parameters [[]]"
}
],
}

i dont know what params should i need to pass here.

Grahame Grieve (Jun 15 2017 at 06:07):

does it work on test.fhir.org/r3?

Jayashree Surnar (Jun 15 2017 at 06:08):

i didn't check there

Grahame Grieve (Jun 15 2017 at 06:22):

that would be a good next step

Jayashree Surnar (Jun 15 2017 at 06:23):

okay, i will check.

Jayashree Surnar (Jun 15 2017 at 06:31):

@Grahame Grieve , i'm not getting how to perform $match operation here. so please help.

Jayashree Surnar (Jun 15 2017 at 07:22):

Jayashree Surnar (Jun 16 2017 at 06:10):

@Grahame Grieve

i'm getting 500 internal server error

i did like this

POST http://test.fhir.org/r3/Patient/$match

Jayashree Surnar (Jun 16 2017 at 06:11):

Jayashree Surnar (Jun 16 2017 at 08:23):

hello all,we are using HAPI-FHIR server and developing the client(mobile app)i want to know whether HAPI-FHIR server supports $match operation, and whether it handles patient empi and mpi or not? if yes. how? any help
Thank you

Lloyd McKenzie (Jun 16 2017 at 14:33):

@James Agnew

Jeremy R (Oct 21 2020 at 15:02):

Hi,

TL;DR: What is the suggested practise of searching for a patient understanding the normal issues with encounter selection (does this apply using FHIR?) - do you need to select a patient and their correct/active encounter for the med list query to work accurately?

I am figuring out some use cases and matching them to current clinical workflows (based on system design). Say, you want to search for a patient, and obtain the list of their current medications.
Obtaining a list of medications is easy.

What are the ways (or best way) you can search for a patient?

Noting that in the current eMR (Cerner in this case), correct encounter selection determines a lot of things that are recorded at the encounter level -- does this same requirement apply when obtaining a meds list using FHIR?
-> IF yes, how do you select the patient + encounter combination correctly?
Can you find a patient through patient lists/location lists that a user has configured under eMR profile, or would it be a patient name query then an active encounter filter?

-> IF no, is the usual suggested practice of searching for a patient via name query with a filter of admission status +/- location filter?

Apologies in advance if you find the structure of this post to be confusing/substandard.
thanks!

René Spronk (Oct 21 2020 at 16:34):

Obtaining a list of medications is easy, obtaining a list of current medications is usually a notoriously hard thing to do.
A 2 step process to search for all encounters of a given patient, followed by a search for all medications (prescriptions, supplies, administrations) associated with an encounter is certainly possible.

Lloyd McKenzie (Oct 21 2020 at 19:01):

There are a few different ways to grab medication information. One is to just search the MedicationStatement, MedicaitonRequest and similar resources. That gives you an 'unfiltered' view which, in some EHRs, might give you just the current meds, but in others might give you a whole lot of stuff that isn't necessarily current/authoritative. You can also search List to retrieve a curated medication list - either the 'current' list or an admitting list/discharge list/reconciled list, etc.

René Spronk (Oct 22 2020 at 06:34):

@Lloyd McKenzie Do you know of implementations that have used List ins such a manner (i.e. as a grouper for active medications) ?

Lloyd McKenzie (Oct 22 2020 at 18:07):

I know the US EHR implementers have pushed back against using List in this way, though Grahame and I both think that's going to fall down at some point as it becomes necessary to expose and manipulate allergies, meds, conditions, etc. that aren't appropriate for inclusion on the global EHR lists. (Also the need to expose and manage provider-specific lists)

René Spronk (Oct 23 2020 at 06:36):

That's what I thought of, the use case where one could have multiple 'current medications lists', created by various different parties, for different purposes, at different times. If one manages one single list in the EHR, then List serves no real purpose, one could simply (e.g.) search for all MedicationUsage resources with an active status.

Jose Costa Teixeira (Oct 23 2020 at 06:38):

That is if MedicationList consists only of MedicationUsages, right?

René Spronk (Oct 23 2020 at 07:13):

That's why I used "e.g." - if you only have 1 single List of MedicationUsages, you might as well omit the List resource. If you have multiple Lists (and there may be good reasons for doing so), then using List makes sense.

Jose Costa Teixeira (Oct 23 2020 at 07:17):

right

Jeremy R (Oct 25 2020 at 14:17):

Hi all, Is there a best practice approach to searching for a patient given potential issues with multiple active encounters in different facilities or no active encounters?
Thanks!

Jeremy R said:

Hi,

TL;DR: What is the suggested practise of searching for a patient understanding the normal issues with encounter selection (does this apply using FHIR?) - do you need to select a patient and their correct/active encounter for the med list query to work accurately?

I am figuring out some use cases and matching them to current clinical workflows (based on system design). Say, you want to search for a patient, and obtain the list of their current medications.
Obtaining a list of medications is easy.

What are the ways (or best way) you can search for a patient?

Noting that in the current eMR (Cerner in this case), correct encounter selection determines a lot of things that are recorded at the encounter level -- does this same requirement apply when obtaining a meds list using FHIR?
-> IF yes, how do you select the patient + encounter combination correctly?
Can you find a patient through patient lists/location lists that a user has configured under eMR profile, or would it be a patient name query then an active encounter filter?

-> IF no, is the usual suggested practice of searching for a patient via name query with a filter of admission status +/- location filter?

Apologies in advance if you find the structure of this post to be confusing/substandard.
thanks!

Lloyd McKenzie (Oct 25 2020 at 15:04):

Searching for patients isn't impacted by whether they have encounters or not - the Patient resource is a distinct resource from the Encounter resource. It's certainly probably that multiple systems will have information about the same individual patient, so if you need to search multiple servers but want to present unique patients, you'll have to figure out a matching algorithm. What constitutes and appropriate algorithm will depend on the nature of the patients you're retrieving and the nature of the systems you're retrieving them from

Jeremy R (Oct 25 2020 at 17:14):

Lloyd McKenzie said:

Searching for patients isn't impacted by whether they have encounters or not - the Patient resource is a distinct resource from the Encounter resource. It's certainly probably that multiple systems will have information about the same individual patient, so if you need to search multiple servers but want to present unique patients, you'll have to figure out a matching algorithm. What constitutes and appropriate algorithm will depend on the nature of the patients you're retrieving and the nature of the systems you're retrieving them from

Thanks, Lloyd, so more of a trial and error approach to curate the returned results?

Lloyd McKenzie (Oct 25 2020 at 19:44):

I don't know about trial & error, but you'd have to have knowledge of the specific data. Do the resources have shared identifiers? Are there other markers you can use to link? What are the costs/risks associated with combining the wrong patients vs. not combining matching patients?

Lloyd McKenzie (Oct 25 2020 at 19:45):

These will vary by environment

Jeremy R (Oct 26 2020 at 11:08):