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

Vital Signs

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:

  • global content-oriented profiles, by
  • cross-country specifications
  • cross-standard specifications
  • cross-language specifications

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:

  • the underlying data associated with those items
  • an information model that aggregates the details and established the necessary relationships
  • representation in different data standards, e.g. v2, V3/CDA and FHIR
  • localisation to different countries
  • localisation to more specific use cases
  • mappings in between

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.

Process Model

The following drawing is a rough idea of how the resulting profiles should be created. The red line guides you:

VendorInformation ModelData Setstandard-specific Profile (Hierarchy)Use CaseProduct Owner/DeveloperData ModelApplicationClass(es) and their relationshipsData SetProfile(s)Use CaseDomain ExpertData Standards Expert,eg. FHIR, V3/CDA, v2, ..MindmapStandards Expert/Computer Scientistcollect ideasanddomain knowledgecollect detailsformalizeextract per Use Casecreates for his applicationinfluences/conformantdevelopsusesconformant?

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).

Profiling

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.

Data SetFHIR Profile HierarchyCDA Templatesv2.x OBX Profiles + segment groupOther Standardsderivederivederivederive

Overall Process

The details collected within a mindmap has to be transformed and taken over into the next subsequent model. The following drawing illustrates that:

Process

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.