FHIR & Relational Data Model


AFAIK, process to release FHIR compatible dataset is:

  1. Create some profiles that define how you use FHIR ressources (ressources used, relations, cardinalities, extensions used…)
  2. Instanciate the profiled ressources with your data

Please confirm me if FHIR can be understood as a relational model (ie: the FHIR UMLs are actually equivalent to Relational Database Physical Data Model). By eg, if i choose to create csv files that respect profiled ressources, I won’t have any problem in the futur with FHIR mecanisms.

Thanks for your answers,

FHIR’s purpose is not to define a persistence layer - it’s to define a data exchange layer. It exists to define data structures used to pass information from one system to another. That doesn’t mean that you can’t use FHIR models to define how you store data, only that FHIR isn’t designed for that purpose and doesn’t provide any guidance about how to do that.

CSV files will likely have a challenge representing FHIR resources because FHIR resources are hierarchical data models which may have multiple (and occasionally recursive) levels of nesting components, some of which may repeat. So in a relational data base design, one resource may need to be represented using multiple tables.

As well, FHIR is still in the Trial Use phase - that means that resources may be changed in non-backwards compatible ways in future resources.

The main use case for me to base a persistance layer on FHIR, is in case of analytical purpose. One can base it’s anaystics programs on FHIR and profiles. Have you heard of any similar project ?

Sure a resource (say specimen https://www.hl7.org/fhir/specimen.html ) would be represented as multiple tables (specimen, collection, processing, container). Recursive table is not incompatible with csv, or RDBMS table. By example specimen has the parent that point to an other specimen. In a RDBMS representation, the foreign key parent would point to the same table (called recursive table).
Can you please share a resource example that would be a problem in such relational representation ?

Do you mean JSON is a better choice ? A resource would be a JSON object instead of X tables. But that’s all the benefits isn’t ?

In my understanding, a set resource is always associated with a set of profiles. So any system that would exploit that set of resource would base on profiles. This does not solve all the backward compatibility problems, but many of them. A persistance layer based on FHIR would be defined with a set of profiles.

Thanks a lot

So long as you’re planning to use multiple table entries per resource instance, you should be fine. As I said, the FHIR spec provides no guidance. However, there are lots of people who are using FHIR for persistance in a variety of architectures (relational, nosql, tripple-store, etc.) I’d suggest you describe what you’re wanting to do on chat.fhir.org and you’ll probably get several responses.

In the world of NOSQL and Document based databases…FHIR becomes natural choice for persistence as well. It solves the problem very nicely.
Using RDBMS for FHIR persistence layer…Please see http://hapifhir.io/
It has a test server as well so you can play there.
The concept is called JPA server as it uses Java ORM methodology.

Also, look at FHIRbase that is postgres based implementation. http://fhirbase.github.io/

As Lloyed said, FHIR is designed for exchange but it can be used for API, Logical Model and Storage Model with careful considerations of implementation technologies.

Hope this helps.

1 Like