FHIR Chat · US Core Search Parameters

Does the common search parameters such as _profile, _Tag still applicable for UC Core IG Profiles apart from the mandatory and optional search options already defined in the IG? What is a best practice as there are 26 US Core profiles so is that an expectation that 26 different API end points will be created and its upto the 3rd party app to subscribe to which API endpoint based on their need? Plz suggest.

Lloyd McKenzie (Jul 07 2020 at 21:25):

There will be one endpoint per resource. For example, Observation will have a single endpoint even though there are multiple associated profiles.

Lloyd McKenzie (Jul 07 2020 at 21:26):

Clients can choose what endpoints to pay attention to. Some might choose to just use the $everything operation.

Robert Scanlon (Jul 07 2020 at 21:37):

Those common search parameters (e.g. _profile) are not required to be implemented, so you cannot assume as a client that a server that claims conformance to US Core will have implemented them.

Robert Scanlon (Jul 07 2020 at 21:42):

The $everything operation is not required in US Core either, so the client can only choose to use it if the server chooses to implement it.

Robert Scanlon (Jul 07 2020 at 22:07):

When multiple profiles in US Core derive from a single resource type (e.g. Observation), one of the required search parameters essentially serves a discriminator you can use to determine which profile should apply to the resources returned. For Observation, that is the code= parameter.

SSM (Jul 08 2020 at 14:05):

Lloyd McKenzie said:

There will be one endpoint per resource. For example, Observation will have a single endpoint even though there are multiple associated profiles.

as a follow up question, if we build out the vital signs profile (endpoint) are you suggesting we don't need separate endpoints for BMI and Pediatric Weight profiles?

Josh Mandel (Jul 08 2020 at 14:59):

You definitely don't for each type of observation. In fact there isn't really even a way to do that with FHIR.

Josh Mandel (Jul 08 2020 at 15:00):

The example queries in the US Core guide represent the minimum of what your server needs to be able to support. The Inferno tool knows how to automatically test these queries, so your best bet is to focus on making sure your server works with Inferno (while learning more about how FHIR works overall).

Robert Scanlon (Jul 08 2020 at 15:06):

Right, both of those profiles point to the vital signs 'quick start', which describes what queries must be supported at [base]/Observation to return vital signs generally, as well as those two profiled vital signs specifically (when you pass a code you know which type of vital sign you will get). http://hl7.org/fhir/us/core/STU3.1/vitals-search.html#mandatory-search-parameters

Douglas DeShazo (Jul 08 2020 at 16:16):

So within a FHIR server that supports US Core IG, a query for observation, patient and let's say the Pediatric BMI Loinc code should return the US Core Pediatric BMI profile. The reason Sudhansu is asking is because we have facade layers over legacy data in some instances and have no FHIR server to work with.

Lloyd McKenzie (Jul 08 2020 at 17:47):

When hitting the Observation endpoint in some cases you might get data that doesn't comply with any of the US Core profiles because it isn't covered by any of them (e.g. psychiatric evaluations - which aren't lab, vital signs or smoking related. If you're exposing data that is covered by the scope of one of the profiles, then the instance is expected to comply with the relevant profile

Robert Scanlon (Jul 08 2020 at 18:46):

If you're exposing data that is covered by the scope of one of the profiles, then the instance is expected to comply with the relevant profile

Is this stated explicitly anywhere in US Core (or base FHIR, but it seems like an IG type detail)? Its how we interpret it while testing, otherwise clients wouldn't ever be able to assume any given resource ever conforms to the expectations of a US Core profile. But a line to point to for requirements traceability would be nice.

Lloyd McKenzie (Jul 08 2020 at 19:42):

@Eric Haas

Eric Haas (Jul 08 2020 at 22:25):

Unless I don't understand the question, that is what the must support, QuickStarts and the capstatements are all about. Since we are discouraged from identifying that an instance is conformant to xyz profile using meta.profile I'm not sure what else we can do.

SSM (Jul 10 2020 at 14:03):

@Eric Haas @Lloyd McKenzie @Robert Scanlon @Douglas DeShazo - If the client doesn't have a FHIR server /FHIR repository and all transactions are real time from source system to FHIR API to the requester..in that case, i am not sure how the observation resource with code search will work and how one observation resource can satisfy different other US Core profiles such as BMI, Age & Height etc. As an alternate option, Why cant we have individual API endpoints for each of the 26 US Core Profile, in that way i am not restricting the 3rd part app or dictating which profile needs to be subscribed to get different data?

Josh Mandel (Jul 10 2020 at 14:17):

I think there is a misunderstanding here, but I'm having trouble putting my finger on it.

Josh Mandel (Jul 10 2020 at 14:19):

FHIR defines a standard API that allows a client to ask for many different kinds of data. The overall scope of the FHIR API is broader than US Core, which is part of why it is valuable (indeed, you asked horrible grow over time and it would be unworkable if FHIR needed new features to make that happen). But if a client queries for specific data elements that are part of US Core, then you can satisfy the requirements set out by that dataset.

Josh Mandel (Jul 10 2020 at 14:19):

So there are not 26 different endpoints, but for each element of the US core there is a fhir query that you can issue to retrieve that element.

Josh Mandel (Jul 10 2020 at 14:20):

Several of these elements are captured in the fhir Patient resource (e.g., name, address, race), and so a single query to fetch patient demographics will get a coherent resource that includes all of these.

Josh Mandel (Jul 10 2020 at 14:21):

Another batch of us core elements are represented with the fhir observation resource, so you can do targeted queries to fetch observations of a specific category or code.

Josh Mandel (Jul 10 2020 at 14:21):

The US Core guide lists these queries explicitly on its profile pages.

Josh Mandel (Jul 10 2020 at 14:22):

I don't know if any of this is helpful, because I'm not exactly sure where the "impedance mismatch" is here, but I'm at least trying to frame things the way I think about them :)

Douglas DeShazo (Jul 10 2020 at 16:52):

Thanks @Josh Mandel We may need to educate clients more on FHIR. The expectation is not for query for data elements but for the entire US Core profile/s and that may be where the confusion lies. We always say follow US Core because of the mandate and the defined queries there but always get 'we don't have a fhir server and are not supporting base FHIR, we are only supporting IG's (US Core, Davinci, etc.)