Stream: implementers
Topic: Resource ID
harsh kumar (Nov 10 2016 at 04:51):
how to manually set resource id of a record in fhir
harsh kumar (Nov 10 2016 at 05:12):
how to manually set resource id of a record in fhir
harsh kumar (Nov 10 2016 at 05:13):
Pls help.URGENT
Paul Knapp (Nov 10 2016 at 07:54):
From a server perspective or froma Clients? Typically the server assigns the id which may be an incrementing value or a GUID or other value.
Lloyd McKenzie (Nov 10 2016 at 20:10):
If you want to control the id on a create, then you need to use PUT rather than POST. (It's up to servers whether they'll let you assign the id of something that doesn't already exist.)
Bapi Behera (May 10 2021 at 16:37):
The Carin & Da Vinci uses the Organization resource in their profile. We use one base FHIR resource for both the profile so having same resource ID. When the API is called with read by ID, how to decide which Organization resource to be returned?
Thanks for your help.
@Kate Dech @Mona O
Michele Mottini (May 10 2021 at 16:47):
I'd say you should have only one resource (matching both profiles)
Bapi Behera (May 10 2021 at 18:44):
Michele Mottini said:
I'd say you should have only one resource (matching both profiles)
Agree. But CARIN & Da Vinci has different extensions in Organization resource.
Paul Church (May 10 2021 at 18:46):
Doesn't matter. A resource can have both sets of extensions and be valid for both profiles.
Kate Dech (May 10 2021 at 19:47):
So for the read interaction, GET base/Resource/id, which profile of the resource is returned?
Some additional context:
At present we don't use a FHIR Server to store the resource the data, we are making real time queries to our data sources.
We have initially built the search type interaction and use includes/rev includes. But we are now looking into separate read interactions for each resource.
We do not have different paths to the base URL for different IGs.
We have two IGs that support a Pharmacy as an Organization:
- C4BB Pharmacy EOB references Organization.
- DaVinci Plannet Pharmacy represented as an Organization.
We may have consumers who are allowed access to one of these or both of these capabilities.
We are also pulled data from different sources for historical claims than for for present/future network search. It is unlikely we would combine into a single representation.
So we are wondering if using the same .id for both profiles is the desired status or if we should be giving distinct IDs per profile.
Jean Duteau (May 10 2021 at 20:06):
I don't think you should be associating the same RESTful ID with two different instances of data. If your C4BB Organization has different data from your DaVinci PlanNet Organization and they aren't stored as the same organization in your system, then they shouldn't have the same RESTful ID.
Lloyd McKenzie (May 10 2021 at 20:46):
If you have one organization and you're trying to meet two sets of requirements, then your one instance should simply meet the constraints of both profiles. When someone does a GET they're not allowed to say "give me this resource, but oh by the way, please make it comply with profile X" - the expectation is that your data simply complies with all profiles you support.
Lloyd McKenzie (May 10 2021 at 20:47):
If the two profiles conflict, then you need to complain to the iG authors and get them to stop over-constraining the resources (e.g. inappropriately tightening cardinalities).
Paul Church (May 10 2021 at 20:50):
It would be nice if we had some kind of enforcement mechanism or at least well known best practices in the IG publication process to prevent that from happening. It is a reasonable follow-up question to say, if the normal practice works as long as profiles don't conflict, what stops the profiles from conflicting?
Lloyd McKenzie (May 10 2021 at 20:54):
We have the http://build.fhir.org/ig/FHIR/ig-guidance IG which is supposed to be a repository of such guidance - and at some point might even get balloted as an informative specification, but there hasn't been a lot of energy put into it in the last year or so...
Michele Mottini (May 10 2021 at 21:10):
As long as profiles do not explicitly prohibit elements it is pretty hard to have incompatibilities I believe? And that is discouraged - exactly for that reason
Michele Mottini (May 10 2021 at 21:10):
(deleted)
Michele Mottini (May 10 2021 at 21:10):
(Even required / extensible binding to different value sets would be ok as long as the element is a CodeableConcept - you just use multiple codings)
Lloyd McKenzie (May 10 2021 at 21:13):
It's fine to prohibit an element that's a genuine error for the use-case. For example, some patient profiles might say that Patient.deceased[x] is prohibited. If you've got a patient who's deceased, that patient instance simply won't be valid against the profile.
Bapi Behera (May 14 2021 at 15:57):
How we will manage when consumer has access to one of the API only (One FHIR Profile - da Vinci)? In that case shall the server returns the data (Organization resource)for both the profiles (Da Vinci & CARIN?
Michele Mottini (May 14 2021 at 15:58):
Yes. There should be only one resource - matching both profiles
Lloyd McKenzie (May 14 2021 at 16:09):
The expectation is that your default interface returns all the data you have and that you filter the data a given recipient isn't allowed to have based on their authentication to the system. The data is expected to be valid against the profiles the system supports, though "what the receiver is allowed to access" trumps that.
Last updated: Apr 12 2022 at 19:14 UTC
