Stream: implementers
Topic: Persistence Layer?
JA (Jan 13 2021 at 21:23):
My team is tasked with implementing https://build.fhir.org/ig/HL7/carin-bb/CapabilityStatement-c4bb.html for CMS interoperability ruling.
The direction that we have taken is building a FHIR facade.
We are assuming that we only need to support Read/Search operations outlined in this CapabilityStatement, and not so much Update/Delete operations.
Our organization does not have a persistence layer for our fhir data. We expose our data internally via microservices.
Without a persistence layer, how would we support the "read" operation?
Do facades really need a persistence layer?
Should we attempt to migrate the data that we need into a single DB?
Michele Mottini (Jan 13 2021 at 21:35):
You need stable ids associated to each FHIR resource you generate. This can be the internal ids of the 'microservices'
Frank Oemig (Jan 13 2021 at 21:41):
Correct, you need to persist the additional FHIR specific data, at least as much is requested in the guide.
René Spronk (Jan 14 2021 at 07:44):
We have to make a distinction between a requirement to support the read operation, and a requirement to support long-lived unique identifiers. If one supports the use of temporary ids only, then read as-such will work, but there won't be anything that one could read. From a formal perspective the system would support a read however.
Microservices typically don't expose any things such as ids or primary keys. Given that this is a read-only facade, one could try and leverage business identifiers, and use a (hashed version of) these identifiers as your id. If the backend is well managed you wouldn't have any duplicates (records with the same business identifier). If patients have .identifier 123, and Patients are known (in Pdex) to have only 1 resource X, then the id of X can also be based on the patient.identifier. If not, one can used contained resources. One SHOULD attempt to support read in the spirit of how it was intended in FHIR, and use long-lived resource.ids. But if one can't, then one just has the strategy to assign temporary urn:uuids and therefore one renders the read operation (for those resources) quite useless.
Josh Mandel (Jan 14 2021 at 14:27):
René is correct from a philosophical and core standards perspective, but as far as the CARIN blue button implementation guide goes, Frank and Michele are correct: you need to support the searches and reads specified in the IG, and following links (via read) needs to work.
Josh Mandel (Jan 14 2021 at 14:27):
(I'm not adding anything new to the conversation, but just explaining why you're hearing a couple of different perspectives and how they in fact do not contradict despite surface appearances.)
Last updated: Apr 12 2022 at 19:14 UTC
