Insbesondere bei Abrechnungen im DRG-Kontext muss eine Diagnose als Hauptdiagnose und ggf. weitere Diagnosen als abrechnungsrelevante Nebendiagnosen klassifiziert werden. Diese Extension ermöglicht es, diese Qualifikation im Abrechnungskontext vorzunehmen, unabhängig von der medizinischen Relevanz, die in Encounter.diagnosis erfolgt.

Im DRG-Kontext werden häufig sämtliche Besuche (Encounter), die unter einen gemeinsamen Abrechnungskontext zusammengefasst werden, unter einer "Fallnummer" geführt. In dieser Konstellation sind die Begriffe "Fallnummer" und "Abrechnungsfallnummer" gleichbedeutend.
Dies ist insbesondere im Kontext des Mappings zwischen HL7 V2 und HL7 FHIR zu beachten, da es in V2 Usus ist, die Fallnummer (eigentlich Identifier des Abrechnungsfalles) im PV1-Segment (Patient Visit) zu übermitteln. Es handelt sich dabei jedoch nicht um den Identifier des Besuchs (Encounter) sondern den des Abrechnungsfalles (Account), da der Identifier oft für die Gruppierung mehrerer Besuche (z.B. vorstationär + stationär + nachstationär) mit gemeinsamem (DRG)-Kontext verwendet wird.
Die Abrechnungsfallnummer in Account.identifier muss identisch sein mit dem Identifier, der bei den Encountern, die unter diesem Account gruppiert werden, unter Encounter.account.identifier angegeben ist.

Hier ist stets der Wert http://terminology.hl7.org/CodeSystem/v2-0203 anzugeben.

Hier ist stets der Wert AN anzugeben.

Hier ist stets der eindeutige Name (URL) des Namensraums anzugeben, aus dem der Identifier stammt. Hinweise zur Festlegung der URLs für lokale Namensräume sind in den Deutschen Basisprofilen beschrieben.
Begründung Pflichtfeld: system stellt in Kombination mit value die Eindeutigkeit eines Identifiers sicher.

Enthält den eigentlichen Wert des Identifiers.
Begründung Pflichtfeld: Ist der Wert nicht bekannt, sollte der gesamte Slice weggelassen werden.

Zeigt den aktuellen Status der Ressource an.
WICHTIGER Hinweis für Implementierer:

• Alle server-seitigen Implementierungen MÜSSEN in der Lage sein, die systemintern möglichen Statuswerte korrekt in FHIR abzubilden, mindestens jedoch active und inactive.
• Alle client-seitigen Implementierungen MÜSSEN in der Lage sein, sämtliche Status-Codes zu interpretieren und dem Anwender in angemessener Form darstellen zu können, beispielsweise durch Ausblenden/Durchstreichen von Ressourcen mit dem status entered-in-error und Ausgrauen von Ressourcen, die einen Plan- oder Entwurfs-Status haben.

Begründung Pflichtfeld: Ein Patientenbezug des Falls muss stets zum Zwecke der Nachvollziehbarkeit und Datenintegrität vorliegen.

Begründung Pflichtfeld: Die Verlinkung auf eine Patienten-Ressource dient der technischen Zuordnung der Dokumentation zu einem Patienten und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.

Auflistung aller Versicherungs- und oder (Selbst-/Fremd-)zahlerverhältnisse, die zur Abrechnung der in diesem Kontext erbrachten Leistungen herangezogen werden können.

Art der Abrechnung, für die das Versicherungsverhältnis herangezogen wird.

Begründung Pflichtfeld: Die Verlinkung auf eine Coverage-Ressource dient der technischen Zuordnung zwischen Abrechnungsfall und Versicherungsverhältnis und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc.

Begründung des MS: Wenn ein Primärsystem mehrere Kostenträger angibt, sollte für lesende Systeme ersichtlich sein, welches der Hauptkostenträger ist.
Historie:
Diskussionstand der ISIK-Arbeitsgruppe vom 28.5.: Die Abbildung über einen Integer ist wünschenswert. Eine binäre Einteilung in Hauptkostenträger (1) und alle anderen (2) wird der Komplexität der Priorisierung zur Kostenträgerschaft nicht gerecht. Eine Ausdifferenzierung ist wünschenswert und sollte angestrebt werden.