Stream: implementers
Topic: Standard DDL for FHIR
Grahame Grieve (Jan 12 2018 at 01:15):
Lots of people have asked me whether there's a standard DDL for FHIR for SQL.
Grahame Grieve (Jan 12 2018 at 01:17):
I'm really negative on the idea: there's so much variation between database servers, between architectural approaches to O/R transforms, between O/R toolkits.... I don't think there's any prospect of agreement. And people using O/R toolkits (majority, I think) wouldn't be at all interested any way
Grahame Grieve (Jan 12 2018 at 01:17):
but the questions I get indicate that people haven't really thought through some of the options they have when they think about how to store their data
Grahame Grieve (Jan 12 2018 at 01:19):
is there any interest in a standard DDL for FHIR? or do people agree with me about the challenges?
Brian Postlethwaite (Jan 12 2018 at 01:34):
I do agree with your notes here, I get the same with folks wanting to use the c# FHIR model classes with EntityFramework, without considering what they are trying to do.
Brian Postlethwaite (Jan 12 2018 at 01:36):
When people ask me, I point them to this slideset I did sometime ago.
https://www.slideshare.net/BrianPostlethwaite1/fhir-server-design-review
Lloyd McKenzie (Jan 12 2018 at 02:07):
Rather than full-blown schemas for everything, would it be worth samples showing different approaches for a subset of the attributes of a couple of resources?
Christiaan Knaap (Jan 17 2018 at 18:31):
I think @Brian Postlethwaite , @Grahame Grieve , HAPI and Vonk all have similar schema's, so we could shed some light on that. In essense what Brian did in his slides, but a bit more elaborate. Mapping the resources as entities directly - yes, I agree on the challenges. Just about every relational model will end up with too much joining.
Grahame Grieve (Jan 19 2018 at 10:12):
well, there's 3 kinds of basic approaches:
- some kind of nosql database of one kind or other
- some kind of indexed tables of blobs
- some kind of relational table with massive join work to build resources (infrastructures exist for this)
Abbie Watson (Jan 21 2018 at 03:19):
On the nosql/javascript side, I recently published fhir-schemas NPM package to standardize across the Node ecosystem. I was getting a lot of similar requests to port the Meteor on FHIR schemas to Node apps, so I published the HL7 JSON Schemas onto NPM with a few edits and changes. Within the Node/Javascript world, this should be a fairly standardized solution, since the library will work on database (Mongo v3.6), server, and client.
Malgorzata Schwab (Feb 16 2018 at 02:21):
There is yet another intriguing idea. We are using Oracle Objects (part of a standard enterprise Oracle license) which is an OO abstraction on top of this powerful relational database. It offers a friendly front end and takes care of managing relational integrity behind the scenes. No JOINS struggle. Capable of depicting a part-whole relationship, including collections, which are implemented by Oracle as nested tables. We successfully stood up several Resources, including Patient, which incorporates every single FHIR pattern, I think. This type of backend enables smooth flow from OO front end, with the same object model, and no transformations.
I don't know how a non-sql database can be of any use, as healthcare apps typically need to be strongly typed and ensure data integrity. Unless it is for event audit, where JSON blobs suffice. Oracle offers a JSON abstraction as well, so a good option for suitable non-sql use cases, with the benefit of a durable relational backing.
Malgorzata Schwab (Feb 16 2018 at 02:28):
@Abigail Watson How is it different from what is on the existing FHIR download site? https://www.hl7.org/fhir/downloads.html
Abbie Watson (Feb 16 2018 at 02:42):
@Abigail Watson How is it different from what is on the existing FHIR download site? https://www.hl7.org/fhir/downloads.html
Well, they're ostensibly the same, in so far as I simply took what was available from the download site and re-packaged it for NPM. However, there are some differences... the download site still contains the JSON schemas broken up as separate files; while the new fhir-schema package uses the all-in-one-file format. The NPM package also exposes the schemas as an ES6 export so Node/Javascript apps can cleanly import them. I'm also still working through how best to export the valuesets, conceptmaps, profiles, etc. from the downloads page. So for the time being, you only get the resource schemas in fhir-schemas.
Last updated: Apr 12 2022 at 19:14 UTC
