KBV Design Rules

Die Kassenärztliche Bundesvereinigung (KBV) hat Design Rules zur Erstellung von FHIR-Ressourcen definiert, die größtenteils auch für die hier vorliegenden Ressourcen gelten – die Ausnahmen sind im Abschnitt Ausnahmen auf dieser Seite beschrieben.

Neben der Benennung von Ressourcen definieren die KBV Design Rules Folgendes:


Allgemeines

  • Im JSON bzw. XML muss die Version des Basisprofils im Wert für baseDefinition mit | angehangen werden.

    • Beispiel XML: <baseDefinition value="https://fhir.kbv.de/StructureDefinition/KBV_PR_Base_Patient|1.7.0" />

    • Beispiel JSON: "baseDefinition": "https://fhir.kbv.de/StructureDefinition/KBV_PR_Base_Patient|1.7.0"

  • Namen von Extensions und Slices innerhalb eines Profils müssen deutsch und in camelCase geschrieben sein.

  • Constraints werden auf oberster Profilebene angeben.

  • Identifier.system muss als pattern oder fixed value gesetzt werden.

  • .mapping soll nicht verwendet werden.

  • Bei Verwendung eines CodeSystems muss der vorgegebene Copyright-Text in den Resource Properties hinterlegt werden.

  • Resource.text muss die vorgegebene Definition enthalten.

  • Resource.text.status muss als fixed value extensions haben.

  • .meta.profile muss (offen) gesliced werden.

    • Es muss ein Slice mit folgendem pattern angelegt werden: <Resource URL>|<Resource Version>
      (Im vorliegenden Projekt heißt dieser Slice immer kvdigitalProfil.)

Kardinalitäten

  • .meta: 1..1

  • .meta.profile: 1..*

  • Coding.system, Coding.code und Coding.display: 1..1

  • Slicing:

    • Die Mindest-Kardinalität des Basis-Elements muss der Summe der Mindest-Kardinalitäten aller Slices entsprechen.

    • Geschlossenes Slicing: Die Maximal-Kardinalität des Basis-Elements muss kleiner oder gleich der Summe der Maximal-Kardinalitäten aller Slices sein.

    • Geschlossenes Slicing mit nur einem Slice: Die Kardinalität des Basis-Elements muss der Kardinalität dieses Slice entsprechen.


Beispieldaten

Es handelt sich bei den Beispieldaten immer um fiktive Inhalte, die inhaltlich nicht aufeinander abgestimmt sein müssen.

Pro Profil sollte mindestens ein Maximalbeispiel und ein Minimalbeispiel vorliegen – sind diese identisch, reicht jedoch ein Beispiel.


Erklärung der Beispielarten

Maximalbeispiel: siehe Abschnitt Ausnahmen

Minimalbeispiel: Nur Informationen für die verpflichtenden Elemente (mit einer Mindest-Kardinalität von 1) sind befüllt. Es gibt jedoch eine Ausnahme, die im Abschnitt Ausnahmen zu finden ist.


Format für die Ressourcen

Aktuell verarbeiten die Systeme des 116117 Terminservice nur das XML-Format gemäß FHIR-Spezifikation R4.

Das heißt, dass Ressourcen, die an die Terminschnittstelle für KVen übermittelt werden, als XML-Objekte vorliegen müssen. Andernfalls wird ein Fehler zurückgegeben.

Alle von den Systemen des 116117 Terminservice zurückgegebenen Ressourcen sind ebenfalls XML-Objekte.


Ausnahmen

  • Aufgrund der offenen Profilierung ...

    • ... werden keine Elemente mit 0..0 profiliert.

    • ... enthalten die Maximalbeispiele nur Elemente, die als Must Support gekennzeichnet sind (das heißt, von den Systemen des 116117 Terminservice tatsächlich verarbeitet werden) oder eine Mindest-Kardinalität von 1 haben.

  • Minimalbeispiele enthalten immer so wenig Daten wie möglich. Das bedeutet, dass im Minimalbeispiel für ein Element, welches mit einer Mindest-Kardinalität von 1 erzwungen wird, auf dem aber die Extension data-absent-reason erlaubt ist, diese Extension (anstelle eines tatsächlichen Wertes) gesetzt ist.