Versionen im Vergleich

Schlüssel

  • Diese Zeile wurde hinzugefügt.
  • Diese Zeile wurde entfernt.
  • Formatierung wurde geändert.


# Lesehilfe zum Informationsmodell

<!-- Ziel: ersetzt den Einleitungsblock "Erläuterungen zum Informationsmodell" auf infomodell.html.
     Begriffe in `Code-Schrift` sind so geschrieben, wie sie in der Detailansicht erscheinen. -->

Das Informationsmodell beschreibt die fachlichen Inhalte, die bei einem Wechsel des
Praxisverwaltungssystems übertragen werden können. Es ist die fachliche Grundlage der
FHIR-Profile dieses Leitfadens: Jedes Element benennt eine Information, beschreibt ihre
Bedeutung und verweist auf die Stelle im FHIR-Profil, an der sie umgesetzt ist.

Das Modell wird in ART-DECOR gepflegt. Die Darstellung auf dieser Seite wird aus einem
Export des ART-DECOR-Datensatzes erzeugt; maßgeblich ist das Modell in ART-DECOR.

## Aufbau

Das Modell ist ein Baum. Auf oberster Ebene stehen thematische Abschnitte:

- Personen, Orte und Einrichtungen
- Administrative Patientendaten
- Behandlungskontakte
- Diagnosen, Messwerte und Befunde
- Medikation und Arzneimittel
- Versorgung und Maßnahmen
- Aufträge, Verordnungen, Leistungsanfragen, Leistungsgenehmigungen
- Behandlung im Auftrag / Überweisung
- Geräte, Heilmittel, Hilfsmittel, Materialien
- Laboruntersuchungen und Befunde
- Abrechnungen und Abrechnungsnachweise
- Technik und Datenaustausch
- MIOs/ePA/KBV-Spezifikationen

Daneben gibt es Abschnitte, die noch nach Arbeitspaketen benannt sind (Arbeitspaket 6 bis 9).
Sie enthalten Inhalte, die noch nicht in die thematische Gliederung überführt wurden,
zum Beispiel Termin, Kur, Impfung, die Laborstruktur und Systeminformationen.> **Offen (vor Veröffentlichung klären):** Sollen die Arbeitspaket-Abschnitte im IG
> erläutert oder bis zur Überführung als „in Bearbeitung“ gekennzeichnet werden?

Unterhalb eines thematischen Abschnitts folgen die fachlichen Konzepte (z. B. „Krankenversicherungsverhältnis“)
und darunter ihre Bestandteile. Ein Element ist entweder

- eine ** Gruppe**: fasst andere Elemente zusammen und trägt selbst keinen Wert, oder
- ein ** Item**: trägt einen Wert mit einem Datentyp.##

Elementnamen und Zusätze

...

...

Referenzen

Viele Konzepte werden an mehreren Stellen benötigt, etwa Patient:in, Begegnung oder
behandelnde Person. Sie sind im Modell nur einmal definiert. An den Stellen, an denen sie
gebraucht werden, steht eine **Referenz**:

```
Referenz Patient [1..1]                ← Kontext: hier wird auf eine Patient:in verwiesen
   └─ Patient:in (KBV-Basis) (Referenz) ← Ziel: das einmal definierte Konzept
```

So lesen Sie eine Referenz:

Image Added

So wird eine Referenz gelesen:

- Die übergeordnete Gruppe - Die **übergeordnete Gruppe** (hier „Referenz Patient“) gehört zum aktuellen Konzept. Ihre
  Kardinalität Ihre Kardinalität sagt, wie oft an dieser Stelle verwiesen werden darf.
- Das ** Referenzelement ** darunter zeigt, * worauf * verwiesen wird. Sein Name und seine
  Kardinalität stammen vom Zielkonzept, nicht von der Verweisstelle. Ein `[0..*]` am
  Referenzelement bedeutet daher nicht, dass hier beliebig viele Verweise erlaubt sind.
  Maßgeblich ist die Kardinalität der Verweisstelle.
- Stehen mehrere Referenzelemente unter einer Gruppe, sind das ** Alternativen**. Zum Beispiel
  verweist „Referenz Leistungsgenehmigungen“ entweder auf eine Leistungsanfrage/-genehmigung
  Psychotherapie oder auf eine für Heilmittel.
- Die Inhalte des Ziels (Name, Geburtsdatum …) werden an der Verweisstelle ** nicht ** erneut
  beschrieben. Sie stehen beim Zielkonzept.

Im FHIR-Mapping entspricht eine Referenz in der Regel einem `Reference(...)`-Element. Das
Mapping Das Mapping der Referenzstelle nennt das Zielprofil.

Image Added

...

Detailansicht

Ein Klick auf ein Element im Baum öffnet die Details. Nicht jedes Element hat alle Angaben.| Feld | Inhalt |
|---|---|
| Name | Bezeichnung des Elements einschließlich Kardinalität |
| Beschreibung | Bedeutung des Elements und womit es befüllt wird.

Image Added

Bedeutung der Eigenschaften

Auszug
AngabeBedeutungBeispiel
Name

benennt das Element.

Ein Element ist entweder eine Gruppe, die andere Elemente zusammenfasst und selbst keinen Wert trägt, oder ein Item, das einen Wert trägt.

Zusätze im Namen:

  • (KBV-Basis): Das Konzept stammt aus den KBV-Basisprofilen und wird an mehreren Stellen im Modell verwendet.
  • (Referenz): Das Element verweist auf ein Konzept, das an anderer Stelle im Modell beschrieben ist. 
VersichertenID_GKV [0..1]
Patient:in (KBV-Basis) [0..*]
Beschreibung

beschreibt den Inhalt des Elementes. Die Beschreibung ist die fachliche Definition

...

: was gemeint ist und womit das Element befüllt wird. Bei Gruppen beschreibt sie, was zusammengefasst wird.

„Unveränderlicher Teil der einheitlichen Krankenversicherungsnummer der GKV gemäß § 290 SGB V.“
Rationale

enthält in besonderen Fällen eine Begründung, warum das Element in der vorliegenden Form in das Informationsmodell aufgenommen wurde, z. B. durch Referenzen auf externe Spezifikationen.

Häufige Quellen sind die Technische Anlage zu Anlage 4a (BMV-Ä)

...

,

...

der HL7®-

...

Leitfaden Basis DE oder

...

## Kardinalität

Die Kardinalität gibt an, wie oft ein Element **innerhalb seines übergeordneten Elements**
vorkommen darf: `min..max`, z. B. `0..1` (optional, höchstens einmal), `1..1` (genau einmal),
`0..*` (beliebig oft) (siehe [FHIR Cardinality](https://hl7.org/fhir/R4/conformance-rules.html#cardinality)).

Ein Pflichtelement (`1..1`) unterhalb einer optionalen Gruppe (`0..1`) ist nur dann
anzugeben, wenn die Gruppe vorhanden ist.

Die Kardinalität steht an zwei Stellen:

1. **Im Elementnamen**, z. B. `Nachname [1..1]`.
2. **In der Detailansicht** als „Basis-Kardinalitäten“.

Die Kardinalität im Namen ist die fachlich abgestimmte Angabe. Sie wurde aus den
Ausgangsspezifikationen übernommen, aus denen das Element stammt: KBV-Basis 1.8.0 oder AWS 1.3.0
(Regel siehe [Entstehung und Rationale](entstehung.html)). Weicht die Angabe in der Detailansicht ab,
gilt bei Referenzen die Kardinalität der Verweisstelle (siehe „Referenzen“).

> **Offen (vor Veröffentlichung klären):** Welche der beiden Angaben ist im Konfliktfall
> normativ? Im aktuellen Export haben rund 960 Elemente keine Szenario-Kardinalität, aber eine
> im Namen. Bei Nicht-Referenzen kommen außerdem einzelne Abweichungen vor. Empfehlung: eine
> Quelle als maßgeblich benennen und die andere angleichen.

### Bedingte Kardinalitäten

Einige Elemente haben je nach Situation unterschiedliche Kardinalitäten. Sie sind im Namen
mit `C` gekennzeichnet (`[0..1 C]`). In der Detailansicht steht die Bedingung, zum Beispiel:

```
wenn eine Dauer der Zeitspanne vorhanden ist   → 1..1
sonst                                          → 0..0
```

`0..0` bedeutet: Das Element darf in dieser Situation nicht angegeben werden.

### Konformität

<!-- Der bisherige Text erklärt M/R/O/NP ausführlich. Im aktuellen Modell sind keine
     Konformitäten gesetzt; die Spalte "Konformität" in den Szenario-Tabellen ist leer. -->

Das Informationsmodell verwendet derzeit keine Konformitätskennzeichen (M/R/O/NP).
Verbindlichkeit ergibt sich aus der Kardinalität und den Vorgaben (siehe unten).

> **Offen:** Entweder die leere Spalte „Konformität“ aus den Szenario-Tabellen entfernen oder
> die Konformitäten im Modell pflegen. Dann diesen Abschnitt entsprechend anpassen.

## Vorgaben und Hinweise

Über die Kardinalität hinaus können Elemente textliche Anforderungen tragen:

| Angabe | Verbindlichkeit |
|---|---|
| `MUSS`, `Vorgabe` | verpflichtende Anforderung an die Umsetzung |
| `SOLL` | Empfehlung; Abweichung nur begründet |
| `KANN`, Operationalisierungshinweis | Hinweis bzw. Möglichkeit |
| `Requirement` | aus einer anderen Spezifikation übernommene Anforderung (z. B. ePA-Laborbefund) mit Schlüsselwort und Akteur |

## Tabellen „Szenario: …“

Unter dem Baum steht je Abschnitt eine Tabelle. Sie zeigt dieselben Elemente flach mit
Einrückung, Kardinalität und Datentyp und eignet sich zum Drucken und Durchsuchen.
Die vollständigen Angaben stehen in der Baumansicht.

## Beispiele

<!-- Nur aufnehmen, wenn der Beispielkatalog öffentlich erreichbar ist. -->

...

das Valueset, aus dem die Werteliste stammt. Links führen zur Quelle.

Geburtsdatum der Patient:in:
„Technische Anlage zu Anlage 4a (BMV-Ä) V1.12“
Datentyp

gibt den Datentyp an, mit dem das Element befüllt wird. Nur Items haben einen Datentyp, Gruppen nicht.

Die Datentypen sind fachlich gemeint. Wie ein Wert in FHIR® abgebildet wird, steht im FHIR-Mapping. 

identifier
Kardinalität

gibt an, wie häufig in einem bestimmten Anwendungsszenario ein Wert für das Element übermittelt werden darf. Ausgedrückt wird das mit einem minimalen und einem maximalen Wert (min..max).

Die Kardinalität gilt innerhalb des übergeordneten Elements. Das Anwendungsszenario heißt „Basis-Kardinalitäten“. Manche Kardinalitäten hängen von einer Bedingung ab.

Basis-Kardinalitäten : 0..1
Das Element darf fehlen und höchstens einmal vorkommen.
Terminologie-Assoziation / Wertelisten

enthält einzelne oder mehrere Codes, mit denen dieses Element gefüllt werden kann bzw. muss.

  • Werteliste: die zulässigen Werte eines codierten Elements, mit dem Valueset und der Verbindlichkeit der Bindung (z. B. required).
  • Terminologie-Assoziation: ein Code, der die Bedeutung des Elements selbst ausdrückt, etwa die Art einer Kennung.
Terminologie-Assoziation:
GKV „Gesetzliche Krankenversicherung“, http://fhir.de/CodeSystem/identifier-type-de-basis
MUSS/KANN/SOLL-Vorgabe

gibt die Umsetzung des Elements in Primärsystemen vor. Das Schlüsselwort nennt die Verbindlichkeit:

  • MUSS: verbindliche Vorgabe. Sie ist ohne Ausnahme umzusetzen.
  • SOLL: Empfehlung. Sie ist umzusetzen, wenn nicht gewichtige Gründe dagegen sprechen. Wer abweicht, muss die Folgen kennen und abgewogen haben.
  • KANN: freigestellt. Die Vorgabe beschreibt eine zulässige Möglichkeit.

Wann eine Vorgabe gilt, steht in ihrem Text. Die Kardinalität ändert sie nicht.

MUSS, bei Einrichtung/Organisationseinheit (KBV-Basis):
„Für die Abbildung einer Betriebsstätte muss die Gruppe "Betriebsstätte" verwendet werden.“
FHIR-Mappings

gibt an, an welcher Stelle in der technischen FHIR®-Spezifikation das Element umgesetzt ist.

  • Vor dem ersten Punkt steht das Profil, danach der Elementpfad. Der Pfad kann Slices (identifier:KrankenversichertenID) und eine Typauswahl (value[x]:valueBoolean) enthalten.
  • KBV_PR_WEST_… sind Profile dieses Leitfadens, KBV_PR_Base_… unverändert genutzte KBV-Basisprofile, Profile mit dgLP stammen aus dem ePA-Laborbefund.
  • Ein Profil ohne Pfad heißt: Das Element wird als eigene Ressource dieses Profils umgesetzt. Bei einer Referenz ist es das Zielprofil.
  • Mehrere Zeilen heißen: Das Element ist an mehreren Stellen umgesetzt.
  • Gruppen, die nur gliedern, haben teils kein FHIR-Mapping.

Mehr unter Mappings im Informationsmodell.

KBV_PR_WEST_Coverage.identifier:KrankenversichertenID
Weiteres Mapping

mappt auf die zugrundeliegenden Spezifikationen, siehe Darstellung von Mappings.

Für jede Spezifikation gibt es eine eigene Tabelle „Mapping nach …“, u. a. AWS 1.3.0, KBV-Basis 1.8.0, KVDT, BDT, EHDS und ePA-Laborbefund. Die Spalte Overlap sagt, wie gut das Ziel zum WEST-Element passt: deckungsgleich, enger oder weiter.

Die Mappings sind Orientierungshilfen, keine verbindliche Transformationsvorschrift. Wozu sie dienen und wie sie entstanden sind, steht unter Mappings im Informationsmodell.

Mapping nach KVDT:
Feld 3119 „Versicherten_ID“, Satzarten 0101, 0102, 0103, 0104, 0109, deckungsgleich

Mapping nach AWS 1.3.0:
/Krankenversicherung/Versichertennummer/VersichertenID_GKV, deckungsgleich
Weitere Angaben

zusätzliche Informationen zum Element, z. B. die Version eines verwendeten Codesystems, die Herkunft eines Codesystems oder ein zugehöriges Dokument.

Version von UCUM: 2.1