KBV Design Rules

Die Kassenärztliche Bundesverinigung (KBV) hat Design Rules zur Erstellung von FHIR-Ressourcen definiert, die auch für die hier vorliegenden Ressourcen gelten.

Neben der Benennung von Ressourcen und den Must-Support-Flags 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..*

  • Codings:

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

    • .userSelected: 0..0

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

  • Folgende Elemente müssen mit einer Kardinalität von 0..0 profiliert werden:

    • .meta.source

    • .meta.security

    • .meta.tag

    • .implicitRules

    • .language

    • .contained


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: Alle Elemente, die zugelassen sind (optional und verpflichtend), sind mit Informationen gefüllt.

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


Format für die Ressourcen

Aktuell verarbeiten die Systeme zum Anfordern eines Vermittlungscodes das XML-Format gemäß FHIR-Spezifikation R4.

Das heißt, dass Ressourcen, die an die Systeme zum Anfordern eines Vermittlungscodes übermittelt werden, als XML-Objekte vorliegen müssen, da sie andernfalls vom System abgelehnt werden.

Alle von Systemen zum Anfordern eines Vermittlungscodes zurückgegebenen Ressourcen sind ebenfalls XML-Objekte.