FHIR Chat · search on several resource types? · implementers

Stream: implementers

Topic: search on several resource types?

Jose Costa Teixeira (Sep 11 2017 at 15:27):

Hi. Can i search for (example) "patients or staff whose ID is 007" ? Or do I have to issue different GETs?
In other words, the cardinality of [type] in a GET, is it 1..1 ?

John Moehrke (Sep 11 2017 at 16:02):

There are ways.. but they would be very specific to a full-featured FHIR server. Why do you not want to use a simple solution, that just requires two search? So I am asking for clarification on the desire that is behind your question so as to point at the best solution.

Grahame Grieve (Sep 11 2017 at 16:12):

see here:

Grahame Grieve (Sep 11 2017 at 16:12):

http://hl7.org/fhir/searchparameter-registry.html

Grahame Grieve (Sep 11 2017 at 16:12):

identifier is not common across Patient, RelatedPerson, and Practitioner, but it should be.

Jose Costa Teixeira (Sep 11 2017 at 16:18):

Ok so if i take the Type out to search any resource, is this the right query?
http://test.fhir.org/r3?identifier=444222222

Jose Costa Teixeira (Sep 11 2017 at 16:19):

that should give me all the resources that have one identifier whose value is 444222222. I'm getting lots of other stuff.

Grahame Grieve (Sep 11 2017 at 16:20):

really you need this:

http://test.fhir.org/r3?_type=Patient,RelatedPerson,Practitioner&identifier=44422222222

Chris Grenz (Sep 11 2017 at 16:21):

Wonder how many servers support this...I'd be surprised if many/any other that Grahame's

Grahame Grieve (Sep 11 2017 at 16:21):

well, right now, none will - even mine.

Grahame Grieve (Sep 11 2017 at 16:22):

but cross research search absolutely is an important thing, and may servers will support it

Chris Grenz (Sep 11 2017 at 16:23):

language from the spec: All resource types: GET [base]?parameter(s) (parameters common to all types only)

Chris Grenz (Sep 11 2017 at 16:23):

In other words, the spec actually forbids this...

Jose Costa Teixeira (Sep 11 2017 at 16:23):

Use case is simple, possibly misplaced: I just scanned a barcode. Who is this?

Grahame Grieve (Sep 11 2017 at 16:24):

@Chris Grenz : In this case, the only parameters that can be used are those defined for both Condition and Observation (using SearchParameter.base - see Cross-resource Search Parameters), or the parameters defined for all resources.

Christiaan Knaap (Sep 11 2017 at 16:25):

On Vonk we actually only check whether the parameter by the same name and searchparametertype is supported across the requested resourcetypes, and then accept it.
Try http://vonk.furore.com?_type=Patient,RelatedPerson,Practitioner&identifier=jElTRIDQrgnesGVo

Jose Costa Teixeira (Sep 11 2017 at 16:25):

or other use case: I just scanned a barcode. What is this?

Chris Grenz (Sep 11 2017 at 16:26):

@Christiaan Knaap So you use the _type list to interrogate SearchParameter?

Chris Grenz (Sep 11 2017 at 16:28):

@Grahame Grieve can't find that language?

Chris Grenz (Sep 11 2017 at 16:28):

Found the language I referenced in the list here: http://build.fhir.org/search.html#2.21.1.2

Christiaan Knaap (Sep 11 2017 at 16:29):

@Chris Grenz Yes. And I just found an exception if no _type is provided at all :-)

Chris Grenz (Sep 11 2017 at 16:30):

That's clever...maybe should be standard/required: if _type is provided, then all other parameters SHALL be common to all types listed

John Moehrke (Sep 11 2017 at 16:30):

you would also need to manually handle query of multiple FHIR servers. so querying multiple resources is just one spread

Jose Costa Teixeira (Sep 11 2017 at 16:30):

@Chris Grenz the top of the page shows the common parameters incl _type

Grahame Grieve (Sep 11 2017 at 16:31):

it's actually like this:

• if you include _type, then all parameters must be explicitly identified as common to the listed resources, or common to all resources
• if you don't include type, all parameters must be for all resources

Christiaan Knaap (Sep 11 2017 at 16:33):

I second - I already implemented it that way...

Chris Grenz (Sep 11 2017 at 16:34):

Yes, sounds great. Language needs to change.

Jose Costa Teixeira (Sep 11 2017 at 16:35):

Thank you all!

Grahame Grieve (Sep 11 2017 at 16:37):

someone want to create a task?

Chris Grenz (Sep 11 2017 at 16:38):

will do

Grahame Grieve (Sep 11 2017 at 16:38):

thx

Chris Grenz (Sep 11 2017 at 16:43):

GF#13836

John Moehrke (Sep 11 2017 at 16:43):

Back to @Jose Costa Teixeira If you are setting operational requirements, then this is one that would need to be mandated. Although this will provide an optimal way, you must have a fallback (robust design) when the server you have doesn't support this. Right?

Jose Costa Teixeira (Sep 11 2017 at 16:48):

for the changes in documentation: if I search for
_type=X,Y,Z;&attribute=VAL
and if type Z does not have "attribute", then the search will
a)fail
b)only return resources of type X and Y
?

Chris Grenz (Sep 11 2017 at 16:49):

Fail

Chris Grenz (Sep 11 2017 at 16:50):

Otherwise you'll silently not get resources you explicitly requested

Christiaan Knaap (Sep 11 2017 at 16:51):

Actually, search is allowed to ignore parameters it cannot support, so at least in Vonk you'll get all parameters of the types X,Y and Z. And an operationoutcome stating that 'attribute' is not supported across all types.

Chris Grenz (Sep 11 2017 at 16:51):

That does limit some use cases where you have 2+ parameters with some of them applying to some mix of resources. But, I'm not sure that's common/wise enough to outweigh the potential for silent error

Chris Grenz (Sep 11 2017 at 16:51):

Vonk will give results + OperationOutcome?

Chris Grenz (Sep 11 2017 at 16:51):

or just OperationOutcome

Jose Costa Teixeira (Sep 11 2017 at 16:51):

i requested but they don't meet my query criteria. So I would not find any problem with returning types X and Y

Christiaan Knaap (Sep 11 2017 at 16:51):

Both, OO as last item in the bundle

Chris Grenz (Sep 11 2017 at 16:52):

Sounds risky to me.

Jose Costa Teixeira (Sep 11 2017 at 16:53):

this triggers a question just for discussion: is it possible to do logical ORs in a GET search?
name=smith or age=90

Grahame Grieve (Sep 11 2017 at 16:53):

note that the client can have it's say about this in the preference header

Chris Grenz (Sep 11 2017 at 16:53):

only via _query

Jose Costa Teixeira (Sep 11 2017 at 16:54):

ok.

Jose Costa Teixeira (Sep 11 2017 at 16:54):

@John Moehrke good point. I'm still not there, but I would rather rely on this being core behaviour

Christiaan Knaap (Sep 11 2017 at 16:55):

"In general, servers SHOULD ignore unknown or unsupported parameters for the following reasons", that's why Vonk does it this way. Support for the preference header is not implemented yet though.

Chris Grenz (Sep 11 2017 at 16:57):

Yes, but that would imply you just didn't include the partially support parameter, NOT that you selectively applied it

Grahame Grieve (Sep 11 2017 at 16:57):

not only via _query. See http://hl7.org/fhir/search.html#errors

Christiaan Knaap (Sep 11 2017 at 16:58):

Indeed, I don't apply it selectively, it's all or none

Chris Grenz (Sep 11 2017 at 16:59):

So for [base]?_type=Patient,Practitioner,Encounter&name=Knaap, what would you return?

Grahame Grieve (Sep 11 2017 at 16:59):

error on my server

Grahame Grieve (Sep 11 2017 at 16:59):

at least, that's what I would expect, and would think of anything else as a bug

Chris Grenz (Sep 11 2017 at 17:00):

Vonk seems cool with it?"

{
    "resourceType": "Bundle",
    "id": "5db83841-88e6-46c1-bcc6-93396faacc51",
    "meta": {
        "versionId": "5a1703ea-cec8-4f03-8ee2-c1fe80604764",
        "lastUpdated": "2017-09-11T17:00:18.615+00:00"
    },
    "type": "searchset",
    "total": 0,
    "link": [
        {
            "relation": "self",
            "url": "http://vonk.furore.com/?_type=Patient,Practitioner,Encounter&name=Knaap"
        }
    ]
}

Chris Grenz (Sep 11 2017 at 17:02):

James doesn't like it.

Chris Grenz (Sep 11 2017 at 17:03):

Grahame actually:

{
    "resourceType": "Bundle",
    "id": "5b398bf4-eb6e-4cc5-b589-633750b723",
    "meta": {
        "lastUpdated": "2017-09-11T17:02:37Z"
    },
    "type": "searchset",
    "total": 358,
    "link": [
        {
            "relation": "self",
            "url": "http://test.fhir.org/r3/?_format=application/fhir+json&search-id=3fb0c0f3-fa9a-44f9-b365-554bc63b4f&&_type=Patient%2CPractitioner%2CEncounter&name=Knaap&_sort=_id"
        },
        {
            "relation": "first",
            "url": "http://test.fhir.org/r3/?_format=application/fhir+json&search-id=3fb0c0f3-fa9a-44f9-b365-554bc63b4f&&_type=Patient%2CPractitioner%2CEncounter&name=Knaap&_sort=_id&search-offset=0&_count=50"
        },
        {
            "relation": "next",
            "url": "http://test.fhir.org/r3/?_format=application/fhir+json&search-id=3fb0c0f3-fa9a-44f9-b365-554bc63b4f&&_type=Patient%2CPractitioner%2CEncounter&name=Knaap&_sort=_id&search-offset=50&_count=50"
        },
        {
            "relation": "last",
            "url": "http://test.fhir.org/r3/?_format=application/fhir+json&search-id=3fb0c0f3-fa9a-44f9-b365-554bc63b4f&&_type=Patient%2CPractitioner%2CEncounter&name=Knaap&_sort=_id&search-offset=350&_count=50"
        }
    ],
    "entry": [
        {
            "fullUrl": "http://test.fhir.org/r3/Practitioner/1",
            "resource": {

...

Grahame Grieve (Sep 11 2017 at 17:03):

pfft. I will try and get to it

Chris Grenz (Sep 11 2017 at 17:05):

I really love working with this group. Best developer community out there.

Christiaan Knaap (Sep 11 2017 at 17:06):

I should at least return myself ;-)
But frankly, since name is not valid for Encounter, I would have expected it to be reported as not supported. What did you expect?

John Moehrke (Sep 11 2017 at 17:06):

Discussion came up that is somewhat related, but very different... that is when the user uses parameters that would be forbidden given their Security/Privacy authorizations. Should these be silent removals (like unknown parameters)? Or should this be a failure?

Grahame Grieve (Sep 11 2017 at 17:06):

failure

Chris Grenz (Sep 11 2017 at 17:06):

I expected an error for malformed search request (since Encounter doesn't have name)

John Moehrke (Sep 11 2017 at 17:07):

I intend to just point it out.. and tell the implementers that they need to look to policy... thus clients must be ready for both

Grahame Grieve (Sep 11 2017 at 17:07):

the idea of ignoring unknown parameters is driven by the many reasons for having extra parameters be added for http stack reasons

Grahame Grieve (Sep 11 2017 at 17:07):

otherwise, errors should be reported

John Moehrke (Sep 11 2017 at 17:07):

Specifically, the parameter is not invalid.. it is just not allowed by that user.

Chris Grenz (Sep 11 2017 at 17:07):

@John Moehrke I'd expect a forbidden failure

Chris Grenz (Sep 11 2017 at 17:08):

I don't think (correct if I'm wrong) its a security risk to expose capability rights failures

John Moehrke (Sep 11 2017 at 17:09):

Yes, it is a risk... but it is a low impact risk. Hence why I want to just point out the risk, and thus deployment environments can choose how important that is. Most will choose to expose it as a failure, because the user is already authorized to do something, so they are not outright hacker.

Christiaan Knaap (Sep 11 2017 at 17:11):

Checked the code: the all-or-none is not actually how it is implemented: if at least one of the types has that searchparameter, it will apply it. Any type that does not have it will return no results, since it won't have any entry for that searchparameter. I should probably change it to return an error on that parameter.

Christiaan Knaap (Sep 11 2017 at 17:12):

@John Moehrke Is there a standard way of expressing users can/cannot use certain search parameters? Or do you mean that in general sense - when there is such a restricting in any form?

Chris Grenz (Sep 11 2017 at 17:31):

My personal assumption would be that a search for SearchParameter would return only those I'm authorized to use. But that's certainly not (and won't be?) in the spec.

John Moehrke (Sep 11 2017 at 18:14):

There are MANY ways of expressing security and/or privacy policy. That is not the focus of the issue. The focus of the issue is what server should do when a security/privacy policy must be enforced that forbids an otherwise valid search parameter. -- One example is when one uses the SMART scope for Patient, and yet the patient includes a patient search parameter on a value other than their own identifier.

John Moehrke (Sep 11 2017 at 18:17):

@Chris Grenz There have been discussions on if a retrieve of the server CapabilityStatement should return a customized CapabilityStatement, customized to the rights that user has. Thus it would not include capabilities that the user would not be allowed to use. I don't know what the result of those discussiions have been

Chris Grenz (Sep 11 2017 at 19:13):

@John Moehrke very interested in that discussion as well

Chris Grenz (Sep 11 2017 at 19:14):

@Christiaan Knaap One more thing to consider - the possibility that a single named query parameter could have different types across resource (may be Token on one and string on another). Is there a reasonable thing to do with this?

Mark Scrimshire (Sep 11 2017 at 19:15):

@Chris Grenz Filtering the CapabilityStatement is something we have done with the CMS BlueButton API. We only show the Resources and Functions that the patient has access to.

Chris Grenz (Sep 11 2017 at 19:20):

@Mark Scrimshire Do you have a link to how this works?

Mark Scrimshire (Sep 11 2017 at 19:26):

@Chris Grenz currently working on updating to add OAuth Extension but python/django code is here: https://github.com/TransparentHealth/hhs_oauth_server/blob/master/apps/fhir/bluebutton/views/home.py - we have a SupportedResourceType Table that identifies the resources and actions that are available to the end user (beneficiary/Patient).

Christiaan Knaap (Sep 12 2017 at 18:17):

@Chris Grenz : We check for that. If the're not all of the same searchparametertype, we discard it.

Jose Costa Teixeira (Sep 14 2017 at 10:16):

Revisiting this for products: I am looking for some harmonization between devices and medications - and any other resources we expect people to come up with like nutritionProduct, or donationOrgan, ...

Jose Costa Teixeira (Sep 14 2017 at 10:18):

i'd want to be able to search for:
1. Gime whatever-this-is, from the code i just scanned.
2. Gimme all the things here that are expiring within a month.
According to this discussion, this is not possible because the attributes are not consistent so the search would fail, right?

Jose Costa Teixeira (Sep 14 2017 at 11:00):

medication has code, device doesn't.
and expirationDate is not at the same level (not sure that matters)

Christiaan Knaap (Sep 14 2017 at 16:27):

Correct. If you want that you indeed have to harmonize the searchparameter(s) for this across the resourcetypes involved. I encourage them being in the spec, but as servers are getting the ability to process custom search parameters, you can try to make it work on one of them first.

Jose Costa Teixeira (Sep 14 2017 at 16:40):

Good. Well, not good, but another argument for doing something about that Kind/instance we spoke in Madrid, and align between Medication, Device, and BiologicallyDerivedProduct. (IMO all of these should be specialization of a base resource called "product".

Jose Costa Teixeira (Sep 14 2017 at 16:42):

pinging @Eric Haas : As just mentioned: One reason to harmonize "instance" across devices - to support searches like the 2 examples above( 1. Get characteristics of an item and 2. Get Expired Items) across different resources.

Jose Costa Teixeira (Sep 14 2017 at 16:44):

and pinging @Lloyd McKenzie although he is ahead of this curve.

Lloyd McKenzie (Sep 14 2017 at 18:43):

We try to avoid deep specialization hierarchies. I can't imagine us having a base resource of Product, though we could have a "pattern" resources might map to. Certainly getting query parameters that are shared across all of those resources would be a good thing

Eric Haas (Sep 14 2017 at 22:03):

I would question whether a pattern is needed consider only 3-4 resources across 2 working groups. Should be easy to be consistent on pattern without the additional overhead of creating and maintaining a Product logical model. I think the search params should be common among the resources that is low hanging fruit

Elliot Silver (Sep 14 2017 at 23:41):

Is there really a need to do a query for "anything expiring in the next month"? How many systems track multiple kinds of resources that can expire, and would want to deal with them all in one list? I recognize that "expiring in the next month" is an example, but my question would apply more widely.

Michael van der Zel (Oct 05 2017 at 10:59):

@Jose Costa Teixeira Did you ever get an answer to your question about barcodes?

Last updated: Apr 12 2022 at 19:14 UTC