Just to share some info on a potential problem.
As an example, lets say that you’re POSTing a FHIR patient resource into OpenMRS. Now, a Patient resource may be linked to other resources (etc. location) In most cases, the Patient resource will have a link to the location resource. basically, we’ll capture the patient resource, identify the location its pointing to using its UUID, and then store the patient.
Now, problem is, what to do if the UUID is for a Location that doesn’t already exist in OpenMRS? HAPI doesn’t provide any in built functionality to make a return call on the client server, and ask it to POST the missing location to us.
At this point, we have the following options:
- (a) make sure that these resources are sent as contained resources within the parent resource, and not as references
- (b) post references only to sub resources that already exist in OpenMRS
- © inform our clients to post resources in proper order, so that they don’t encounter any missing data
As a system administrator, I would not expect the granting someone the
authority to post to the patient resource would also allow them to create
locations in my database.
I would be opposed to letting a post to the patient resource automatically
create any supporting metadata.
So I guess that means B or C as you describe it.
Hi @darius, in this case, locations were just an example - there can be a large number of different use cases. I agree that locations would be metadata - but there are other examples that aren’t. For example, consider a diagnostic report. If we are sent a patients lab testing report, this will basically include a number of Obs. In such a case, the diagnostic report and the obs that it contains are basically a single “unit” or work, and not “metadata”. In instances such as this, the established process is to send the obs as contained resources within a DiagnosticReport resource.
@surangak, this is why you need to pick good illustrative examples.
If in the real-world the resource being POSTed “contains/owns” other
resources (like your diagnostic report containing obs for each of the lab
test results), then yes, I would expect these to be sent as contained
resources, and this POST should create all of them.
If in the real-world the resource being POSTed “refers to” an independent
resource, I would not expect the POST to create the referred-to resources.
E.g. POSTing a transfer-in patient should not create a new location to
represent the health center they come from. POSTing an Observation that is
the result of a particular referenced Lab Order should not create the order.
In the obs + order scenario, I presume there’s a mechanism to POST these
both as a Bundle that would have the effect of creating both. But I
wouldn’t expect a POST to the Observation resource to create the Order that
the Observation is responding to.
Thanks @darius, this sounds right. And the ‘contains/owns’ vs. ‘refers to’ variation seems to be a nice way to differentiate between the two approaches. FHIR doesn’t seem to specifically identify the difference between the two approaches, but I think your suggestion is a fine way to identify these differences, and to plan how we’d support each.