I would like to get a list of all the patients in the ICU. I don’t think I can’t do that in “patient” resource directly. Upon searching and reading the fhir documentation, I found out that “encounter” resource can help me with that. However, I don’t know which property of encounter to use to do that. Any suggestions?
encounter.class has a defined value as “emergency”, can this be it ?
There isn’t good agreement about how to represent patient location in encounter. There’s too many decades of deeply embedded patient management practice in existing systems and instutions, which mean that this question can only be answered with certainty by asking how patients are managed at a particular institution.
but the most likely answer here is class = inpatient, and location points to a resource for ICU
Hi Lloyd, this is actually a scenario I’m having a little trouble with at the moment, just wondering whether it’s an implementation issue with the CDR we’re using or an issue with the query.
Where we know the location id of e.g. the ICU and want to find Encounter’s that are at that location now. I found this blog post, Getting a list of patients in a Ward, while written 10 years ago the logic still appears sound.
The issue we’re having is using a query like the following, GET Encounter/?location=1234&location-period=gt2023-01-09T09:10:23.578+00:00 the results include an Encounter which had previously been at that location but has since moved to a new location. Example of one of the Encounter’s location details:
It is behaving as though the location id and location-period parameters are being used independently rather than being combined, that is used with an OR rather than AND if it were sql.
I’m just wondering if this sounds like the expected behavior or whether it could be an implementation issue with our CDR?
location-period is actually badly defined. It requires ‘magic’ to work the way it’s specified.
In general, all search parameters are interpreted independently. A search is essentially an intersection of the results of searching with each search parameter. So when a ‘non-magic’ server sees the definition of location and location-period, it first says “find encounters where there’s a match on location.location”. Then it says “find encounters where there’s a match on location.period”. Then it intersects the results.
In order to check both location and period at the same time, for the same location repetition, you’d need to define a composite search parameter that passed both the location and the period as a single search parameter.