Stream: implementers
Topic: Resources and Documents (SQL and NoSQL?)
Kevin Mayfield (Oct 22 2017 at 09:34):
We're working on an reference implementation that mimicks PAS and EPR implementations. It's based on implementations from the mid 90's to now, so we've naturally gone down the RDBMS SQL route. As expected, mapping FHIR resources to SQL tables has not proved to be an issue - so Patient resource is Patient table, Observation is Observation, etc.
However in a few cases where the FHIR resource/SQL table approach isn't appropiate and doesn't sit fully within the EPR/PAS model. For example Composition, the resources it holsd can be stored in a EPR/PAS model but the Composition itself should also be stored intact as a possibly in a document/NoSQL database as it also records a point in time.
Kevin Mayfield (Oct 22 2017 at 09:40):
The model appears to be a correct representation of how these are currently handled (loosely - as Composition may be in different alternative forms such as PDF, image, Hl7v3/CDA). DiagnosticReport could be handled similarly with Observations entered into the EPR/PAS but is also stored in it's entirety.
Kevin Mayfield (Oct 22 2017 at 09:48):
So if this representation is correct, I would use the EPR/PAS (SQL) to search for Observations, the Document store (NoSQL) to search for Compositions and DiagnosticReports. I wouldn't search the Document store for Observations - that could be done but is a more modern way of working.
Kevin Mayfield (Oct 22 2017 at 09:49):
So if my model is correct, how do I go from the Observation to the Composition or DiagnosticReport?
Kevin Mayfield (Oct 22 2017 at 09:56):
I could use an extension but I was expecting a Reference in Observation to Composition or DiagnosticReport as you would have with the more PAS/EPR focused resources.
Kevin Mayfield (Oct 22 2017 at 10:20):
On a similar note: most PAS/EPR's have the idea of Concept, CodeSystems and ValueSets which is seen in the FHIR (the logical model fits well). Most of EPR/PAS's I worked with have the basics of a resource API on Concept but FHIR has an operations/RPC interface on CodeSystem and no seperate Concept resource. I think I'm seeing three seperate API styles within and some points when the resource I’m working with belongs to a different style - styles being RPC (terminology), Message API (document) and Resource API as defined here http://www.servicedesignpatterns.com/WebServiceAPIStyles
René Spronk (Oct 22 2017 at 11:48):
Why would you need to go from the Observation to the Composition? Composition contains a reference to the Observation it contains. If you're talking about "This Observation was taken from (shredded) from FHIR document X", then in FHIR that would be Provenance. I would hardly expect a legacy system to have a notion about Provenance. But I guess the latter is not your reason for whishing to go from Observation to Composition. Could you elaborate on the reason?
Kevin Mayfield (Oct 23 2017 at 07:44):
Yes it is provenance/audit, it is tracing where an obvservation came from. DiagnosticReport is a better example, on the EPR's I worked with in the 90's the would have link to the report that delivered the Observation. That was represented in the UI, a user had the option of viewing the original report (from Observations). I'd be tempted to code Composition similarly, have a link from Observation's to Document (Composition, DocumentReference, etc).
Kevin Mayfield (Oct 23 2017 at 07:46):
On DB level it's a bit more clearer. After I've normalised the table I would create a link from Observation's to DiagnosticReport table, I would not have a DiagnosticReportObservations link table as per the FHIR Model.
Kevin Mayfield (Oct 23 2017 at 07:59):
p.s. I'm actually looking at what database model to use for resources.
Kevin Mayfield (Oct 23 2017 at 08:01):
and the answer I've got at present would be resources (SQL) and documents (NoSQL) with a few grey areas.
Grahame Grieve (Oct 23 2017 at 10:22):
so we always anticipate that something is able to follow the indexes in reverse; if you build a database where the resources are your master form, then you must also have an index so that you can follow all the links in the reverse direction (from target to source)
Grahame Grieve (Oct 23 2017 at 10:23):
if, in your persistence model, you chose to reverse some or all links... that's your choice. There's engineering optimization issues, and we don't design for them, since we are describing an interface
Kevin Mayfield (Oct 23 2017 at 10:49):
and we can get to the reports via ProcedureRequest (which fits with the model I'm using for an EPR)
Last updated: Apr 12 2022 at 19:14 UTC
