Vital Signs Cross-Country Cross-Language Cross-Paradigm (Demo) IG
0.6.0 - ci-build
Vital Signs Cross-Country Cross-Language Cross-Paradigm (Demo) IG
0.6.0 - 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.6.0 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.6.0 | |||
| Draft as of 2024-12-08 | 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 first following three. The others are mentioned for completeness:
Per OO discussion on Dec. 6th, 2024 the blood pressure, body weight and body height information models and implementation guides have been moved into individual IGs.
This guide is NOT intended to discuss what aretefact is to be considered being a vital sign although the discussion in some groups demand that. As demonstrated with the following drawing, on some yet considered observations are real vital signs. Why? Some measurements like body weight are good to know and to consider when examining the vital status of a person, but are definitely not an indication for being a vital and living person. Good examples are body weight and height. Others, like blood pressure, contain a lot of different measurements, for example doing some excercising, so that only a subset can be considered a vital sign.
Therefore, a different profile hierarchy must be established! But this is another discussion.
So, the panel is the collection of vital sign eligible measurements. In other words, for example, not all possible blood pressure measurements are good to express a vital sign. For example, 24h or 1w average measurements are also bp values, so is under exertion, but not good for vital signs. Therefore, they denote a subset of all possible bp measurements:
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 - and primary purpose - behind this (small) 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 (arrows) guides you:
Domain experts have to provide the necessary domain knowledge which has to be formalized accordingly. The mindmap is just a high-level means to summarize all details that are somehow relevant. Because complex models (in a formal representation) are not that easy to understand, a better way has to be found. Therefore, the domain experts have to equip the mindmap with additional details that are best represented in form of simple natural language sentences. For example, "every value is measured a certain single point in time." Or "each measured value has a unit."
Both, the mindmap and the explanation, must be translated into a set of related classes in an information model, ideally using formal representations like BPMN. This information model should not only influence the data model and application 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.
Note: Different versions of the same standard has to be treatened as different standards.
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.
Another word on these two terms: In principle are they used interchangeably, ie. with the same intent. However, most probably they are not quite equivalent because information models help with an overarching collection of details that may be lost within meta-models.
Another question is about managing and structuring the different IGs! Currently, we only have a single "FHIR Core" that is assumed to be the base for all other similar IGs. However, obviously this is not the case. More or less all countries are developing their own set of profiles that are - more or less - identical to each other. Of course with the caveat, that due to their identification (as a profile) the may look identical but are definitely not.
A solution may be to devide the profiles - including the aforementioned details - into individual IGs so that additions and modifications may be easier - although more guides have to be maintained. It will result in the following structure:
This hierarchy has been enhanced mmeanwhile because different expectations arose from discussions in some groups. The implementation guide can only support and help to clarify it by enhancing the hierarchy to cover different dimensions: