KBV Design Rules

Die Kassenärztliche Bundesverinigung (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 letzten Abschnitt auf dieser Seite beschrieben.

Neben der Benennung von Ressourcen definieren diese 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.6.0" />

    • Beispiel JSON: "baseDefinition": "https://fhir.kbv.de/StructureDefinition/KBV_PR_Base_Patient|1.6.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äten des Basis-Elements muss der Kardinalität dieses Slices 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 Maximal- und ein Minimalbeispiel vorliegen - es sei denn, diese sind identisch (in diesem Fall reicht ein Beispiel).


Erklärung der Beispielarten

Maximalbeispiel: siehe Abschnitt Ausnahmen

Minimalbeispiel: Nur Informationen für die verpflichtenden Elemente (mit einer Kardinalität von 1..1 oder 1..*) sind gefüllt.


Format für die Ressourcen

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

Das heißt, dass Ressourcen, die an die Systeme der Terminsynchronisation des 116117 Terminservices übermittelt werden, als XML-Objekte vorliegen müssen, da sie andernfalls abgelehnt werden.

Alle von Systemen des 116117 Terminservices 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 mit Must Support gekennzeichnet sind (d.h., von den Systemen des 116117 Terminservice tatsächlich verarbeitet werden).