Stream: implementers
Topic: Model view of FHIR resources
Øyvind Aassve (Jul 08 2020 at 10:38):
Hi, do anyone know of publicly available high-level models of the FHIR resource landscape? Goal is to communicate to stakeholders the fact that the resources also have defined relations among them and constitutes a quite impressive information model, and give an idea of these relations through a visualized model.
René Spronk (Jul 08 2020 at 11:23):
At one time we had a auto-generated UML diagram showing all resource types and references between them. But it's huge and cluttered, so of very limited value. You'd need some hand crafted / curated graph of resource types. We use such graphs in our FHIR training courses, but only for parts of the set of resources types, never for FHIR as a whole - which would still be a fairly large/complex diagram.
Rik Smithies (Jul 08 2020 at 12:06):
there is an "ad hoc" one for the Medication Definition resources that you were enquiring about, in the resource proposal for these resources e.g. here https://wiki.hl7.org/MedicinalProductDefinition_FHIR_Resource_Proposal (direct link here https://wiki.hl7.org/File:Resources_sketch.png)
Øyvind Aassve (Jul 08 2020 at 12:27):
Thank you Rik, good one for those contexts. There are some on the category level also in the spec, even though not for all categories. What I was looking for was a model that shows a broader view also across categories. All resources with all relations might be an interesting view but in general be too busy, so ideally more a highlevel model with a set of easily recognizible resources that shows stakeholders in an easy way that all these resources also are building a beautiful web :)
Lloyd McKenzie (Jul 08 2020 at 14:25):
If you figure out how to build one, be sure to share :) So far, we haven't found a way.
Vassil Peytchev (Jul 08 2020 at 14:27):
Although not directly representing FHIR resources, would the RIM be helpful here?
Øyvind Aassve (Jul 08 2020 at 14:36):
Thanks @Lloyd McKenzie, I think I will settle for creating a smiple manual version in the first round then :). @Vassil Peytchev - the idea was to create a recognition among the stakeholders also for the FHIR resources, so RIM is not ideal.
René Spronk (Jul 08 2020 at 15:00):
If I were to create something like this (and as a trainer I can see the use) I'd first create a list of the 80% most commonly implemented resources, and group them by functional area (like the modules on the main page of the FHIR spec). Build graphs per group (using different colors for different groups), add some key references within a group, add key references between groups. However, readers will be most interested in clinical and administrative resources, and not in conformance or infrastructural resources (Bundle, Binary, ..). So that'd also impact the visualization and the level of detail (=number of different resource types) shown for each grouping.
Øyvind Aassve (Jul 08 2020 at 21:54):
Thanks @René Spronk - that is good input.
Peter Jordan (Jul 08 2020 at 21:55):
@Øyvind Aassve you can use ClinFHIR to create FHIR Resource Models based on a Bundle. An example of one for an electronic prescription, including dispensing, can be found here https://terminz-itp.azurewebsites.net/Content/NZePStoFHIR.jpg
Øyvind Aassve (Jul 08 2020 at 21:58):
@Peter Jordan - neat diagram. I will check that out.
Jose Costa Teixeira (Jul 08 2020 at 22:25):
If this becomes a popular request, I'd start with capturing a graphml definition of the resource graph. From there, selection and visualization should be easier
René Spronk (Jul 09 2020 at 06:13):
I think you'll find that this specific purpose requires one to have quite a bit of artistic freedom in selecting what resource types to use, what references to show, how to group/display them on a slide, and e.g. whether or not to collapse multiple resources types into 1. The graph doesn't have to represent the full truth - the overall message that such a graph conveys is much more important than its correctness.
Jose Costa Teixeira (Jul 09 2020 at 06:22):
Yes, agree. I was thinking that we could handle selection, clustering and layout on the visualisation layer.
René Spronk (Jul 09 2020 at 06:59):
I'm just afraid that a standard visualization layer wouldn't support the artistic freedom required for such a graph ;-)
Last updated: Apr 12 2022 at 19:14 UTC
