Vital Signs Cross-Country Cross-Language Cross-Paradigm (Demo) IG
0.1.7 - ci-build
Vital Signs Cross-Country Cross-Language Cross-Paradigm (Demo) IG, published by FO. This guide is not an authorized publication; it is the continuous build for version 0.1.7 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/frankoemig/vital-signs-demo/ and changes regularly. See the Directory of published versions
Official URL: http://vitals.oemig.de/fhir/ImplementationGuide/vital-signs | Version: 0.1.7 | |||
Draft as of 2024-05-22 | Computable Name: Vitalsigns |
This IG is a demo to analyse some vital-signs profiles from different FHIR core specifications (in different countries). Therefore this guide focuses on the following three:
This guide is NOT intended to discuss what aretefact is to be considered being a vital sign.
Those three are selected because they are simple, comprehensive and easy to understand. And those are in principle country independent, i.e. they should be the same world-wide. The target of this guide is not to specify a set of complete and correct profiles, but to trigger a discussion aorund profiling, i.e. the way profiles are currently created and maintained. It seems totally unnecessary to profile the same artifacts again and again, although different use cases may guide that way. Comments in the direction of “it is impossible to specify the perfect” reality shows that diverging approaches are also not sufficient or leading to less efforts.
The goal is:
The idea behind this guide is to propose an alternative way to create profiles that enable interoperability on a higher level. The targets are to present:
Caveat: Please keep in mind that everything on these pages is more or less incomplete. Also, esp. the artifacts in this guide are still under development, although they are in parts already more complete or usable than the originating ones.
The following drawing is a rough idea of how the resulting profiles should be created. The red line guides you:
Domain experts have to provide the necessary domain knowledge which has to be formalized accordingly. That results in a set of related classes in an information model. This information model should not only influence the data model and applicatin a vendor is developing, but also the derived data set that is the foundation for the profile (hierarchy).
How to do the profiling?
From the information model use-case specific data sets have to be defined that collects and aggregates the necessary data. Those representations have to be transfered into proper data-standard-specific profiles. This way, all artifacts are considered with the same relationship to each other.
The details collected within a mindmap has to be transformed and taken over into the next subsequent model. The following drawing illustrates that:
After all, it has to be verified that no detail is lost. Also, it must be ensured that specific relationships, esp. the minimum cardinality has been correctly represented in the next (derived) model.
There will be a back and forth between the different phases to improve the content, and to ensure consistency. That helps to align and identify gaps.