New item


diff: yes

typenameCompositionConditionCoverageCoverageValueSet
idcomposition-blutdruckconditioncoverageGesetzlichcoveragePrivatdiagnoses-sct
namediagnoses-sct

status
system1..Fixed Value
code1..Fixed Value
policyHolder..0
displayS1..
subscriberId..0
referenceS1..
payorSReference(ISiKPatient | ISiKAngehoeriger)
order..0
network..0

FeldnameKurzbeschreibungHinweise
RelatedPerson.address:Strassenanschrift.type
RelatedPerson.address:Strassenanschrift.line
RelatedPerson.address:Strassenanschrift.city
RelatedPerson.address:Strassenanschrift.postalCode
RelatedPerson.address:Strassenanschrift.country
RelatedPerson.address:Postfach.type
RelatedPerson.address:Postfach.line
RelatedPerson.address:Postfach.city
RelatedPerson.address:Postfach.postalCode
Bundle.type
Bundle.timestamp
Bundle.entry
Bundle.entry:Composition
Composition.text
Composition.text.status
Composition.text.div
Composition.subject
Composition.subject.reference
Composition.encounter
Composition.encounter.reference
Composition.date
Composition.author.display
Composition.title
Composition.section
Composition.section.title
Composition.section.text
Composition.section.section
Condition.id
Condition.extension:ReferenzPrimaerdiagnose
Condition.extension:ReferenzPrimaerdiagnose.value[x].reference
Condition.clinicalStatus
Condition.code
Condition.code.coding
Condition.code.coding:ICD-10-GM
Condition.code.coding:ICD-10-GM.extension:Mehrfachcodierungs-Kennzeichen
Condition.code.coding:ICD-10-GM.extension:Seitenlokalisation
Condition.code.coding:ICD-10-GM.extension:Diagnosesicherheit
Condition.code.coding:Alpha-ID
Condition.code.coding:Alpha-ID.system
Condition.code.coding:Alpha-ID.code
Condition.code.coding:SNOMED-CT
Condition.code.coding:SNOMED-CT.system
Condition.code.coding:SNOMED-CT.code
Condition.code.coding:Orphanet
Condition.code.coding:Orphanet.system
Condition.subject
Condition.subject.reference
Condition.encounter
Condition.recordedDate
Condition.note
DocumentReference.masterIdentifierVersionsspezifische OID des Dokumentes
DocumentReference.masterIdentifier.systemNamensraum des Identifiers

Fix: urn:ietf:rfc:3986

DocumentReference.masterIdentifier.valueWert des Identifiers

OID mit URI-Präfix "urn:oid:". Es sei darauf hingewiesen, dass OIDs auf Basis von UUIDs generiert werden können, ohne einen eigenen Namesraum zu beantragen. Zunächst müssen hierzu alle 128 Bit der UUID in einen Integer-Wert umgerechnet werden. Das Ergebnis muss ohne Bindestriche an die Root-OID '2.25' angehängt werden. Siehe IHE International - Creating Unique IDs - OID and UUID.

DocumentReference.identifier

Abweichend zu MHD V4.0.1 ist die Angabe eines Identifiers in ISiK nicht erforderlich. Ein solcher kann bei Bedarf (z.B. zur Weitergabe des Dokumentes per XDS) erzeugt werden.

[Konsens der Arbeitsgruppe vom 12.11.2021]

Update für Stufe 3: In MHD 4.2.0 wurde die Verpflichtung zur Angabe eines Identifiers gelockert, das ISiK-Profil ist damit in diesem Punkt wieder kompatibel zu IHE MHD.

DocumentReference.statusStatus des Dokumentenmetadatensatzes

Der Status des Dokumentes wird in DocumentReference.docStatus gesetzt.

DocumentReference.docStatusBearbeitungsstatus des Dokumentes

Abweichend zu MHD V4.0.1 ist die Verwendung von docStatus im ISiK-Kontext erlaubt. Die Verwendung von docStatus bleibt jedoch optional, da nicht alle dokumentenerzeugenden Systeme einen expliziten Freigabe-Workflow haben.

  • Dokumentenserver müssen jedoch in der Lage sein:
    • den Dokumentenstatus (sofern vorhanden) zu persistieren,
    • anzuzeigen, und
    • zu reproduzieren.

Konsens der Arbeitsgruppe vom 10.12.2021

DocumentReference.typeDokumententyp

Im ISiK-Kontext ist die Typisierung eines Dokumentes mit Hilfe eines KDL-Codes und des IHE-XDS-Type-Codes erforderlich und ein Server MUSS beide Kodierungen bereitstellen - trotz der Kardinalität DocumentReference.type.coding:XDS 0..1 -, jedoch ist der IHE-XDS-Type-Code bei Übermittlung für Clients nicht verpflichtend (s.u. zu XDS). Während KDL-Codes eine feingranulare Dokumentenklassifikation für die gezielte Suche nach medizinischen und Administrativen Dokumenten ermöglichen, sind IHE-XDS-Type-Codes für den einrichtungsübergreifenden Dokumentenaustausch maßgeblich. Der XDS-Type-Code kann mit Hilfe der bereitgestellten ConceptMaps aus dem KDL-Code ermittelt werden. Weitere Typisierungen (z.B. nach SNOMED oder LOINC) sind uneingeschränkt erlaubt. [Konsens der Arbeitsgruppe vom 18.02.2022]. Im Falle, dass der Code 'UNK' entsprechend der ConceptMap verwendet werden soll, MUSS das System 'http://terminology.hl7.org/CodeSystem/v3-NullFlavor' verwendet werden.

DocumentReference.type.coding:KDLDokumenttyp gem. KDL-Terminologie
DocumentReference.type.coding:KDL.systemKodiersystem

Fix: "http://dvmd.de/fhir/CodeSystem/kdl"

DocumentReference.type.coding:KDL.codeCode

Der KDL-Code

DocumentReference.type.coding:KDL.displayAnzeigetext

Der Anzeigetext zum KDL-Code

DocumentReference.type.coding:XDSDokumenttyp gem. IHE-De-Terminologie

Die Übermittlung des XDS-Type-Codes ist im Rahmen der Dokumentenbereitstellung für Clients nicht verpflichtend, MUSS jedoch vom Server bei der Entgegennahme ggf. ergänzt und bei der Dokumentenabfrage zurückgegeben werden. Der XDS-Type-Code kann über die im Rahmen der KDL-Spezifikation publizierten ConceptMaps aus dem KDL-Code ermittelt werden

DocumentReference.type.coding:XDS.systemKodiersystem
DocumentReference.type.coding:XDS.codeCode

Der XDS-Type-Code

DocumentReference.type.coding:XDS.displayAnzeigetext

Der Anzeigetext zum XDS-Type-Code

DocumentReference.categoryDokumentklasse/-Kategorie

Die Kategorisierung von Dokumenten erfolgt mittels der von IHE Deutschland publizierten XDS-Class-Codes. Die übermittlung des XDS-Class-Codes ist im Rahmen der Dokumentenbereitstellung für Clients nicht verpflichtend, muss jedoch vom Server bei der Entgegennahme ggf. ergänzt und bei der Dokumentenabfrage zurückgegeben werden. Der XDS-Class-Code kann mit Hilfe der bereitgestellten ConceptMap aus dem KDL-Code ermittelt werden.

DocumentReference.category.coding:XDS
DocumentReference.category.coding:XDS.systemKodiersystem
DocumentReference.category.coding:XDS.codeCode

Der XDS-Class-Code

DocumentReference.category.coding:XDS.displayAnzeigetext

Der Anzeigetext zum XDS-Class-Code

DocumentReference.subjectPatientenbezug
DocumentReference.subject.referencePatienten-Link

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.

DocumentReference.authorAutor des Dokumentes

In dieser Ausbaustufe ist die Nennung des Namens oder Kürzels des Autors ausreichend. Eine darüber hinaus gehende Verlinkung auf einen Practitioner (auflösbar auf dem Server) ist möglich aber nicht erforderlich.

DocumentReference.author.display
DocumentReference.relatesTo

Inbesondere relevant im Kontext von Updates. Bei inhaltlichen Updates MUSS eine replaces-Relation angegeben werden.

DocumentReference.description

Genaue menschenlesbare Beschreibung des Dokumentes, z.B. "Lungenfunktionstest vom 18.02.2022"

DocumentReference.securityLabelVertraulichkeit

Die Bereitstellung der Vertraulichkeitsinformation durch den Ersteller des Dokumentes ist verpflichtend. Ebenso sind Dokumentenserver verpflichtet, diese Information zu persistieren und bei der Dokumentenabfrage zu reproduzieren. Die ISiK-Spezifikation trifft jedoch keine Annahmen darüber, wie sich einzelne Vertraulichkeitsstufen auf die Zugriffsberechtigungen verschiedener benutzer auf ein Dokument auswirken. Im ISiK-Kontext ist die Angabe einer der drei Vertraulichkeitsstufen N | R | V verpflichtend, jedoch ohne Einschränkung der Verwendung zusätzlicher Vertraulichkeits-Flags.

[Konsens der Arbeitsgruppe vom 12.11.2021]

DocumentReference.contentBeschreibung des Dokumenteninhaltes

Die Kardinalität wurde angepasst, um den Vorgaben von IHE MHD zu ensprechen [Änderung im Zuge der Kommentierung Stufe 3].

DocumentReference.content.attachmentAnhang
DocumentReference.content.attachment.contentTypeMimetype des Dokumentes

Mimetype (Dateityp) des Dokumentes (z.B. "application/pdf")

DocumentReference.content.attachment.languageSprache, in der das Dokument verfasst wurde.

Kann bei Systemen, die keine Mehrsprachigkeit unterstützen, fest auf "de" oder "de-DE" gesetzt werden.

DocumentReference.content.attachment.dataBase64-codierte Binärdaten

Um die Suche nach Dokumenten effizient zu gestalten, dürfen die Dokumente selbst nicht in die DocumentReference eingebettet werden, sondern müssen als separates Datenobjekt referenziert werden.

Update für Stufe 3: Die Ausnahme bildet die Interaktion "Dokumentenbereitstellung", bei der die Binärdaten des Dokumentes eingebettet in die DocumentReference an den Server übermittelt und dort dann in eine separate Ressource ausgelagert und über Attachment.url referenziert werden.

Es ist zu beachten, dass diese base64-codierten Daten wiederum ein FHIR-Bundle (z.B. ein MIO oder ein ISiK Bericht aus einem Subsystem) repräsentieren können. Um eine einheitliche Handhabung der Dokumente für Clients zu ermöglichen werden diese trotz strukturiertem Inhalt per base64 abgebildet.

DocumentReference.content.attachment.urlReferenz auf Dokument

Um die Suche nach Dokumenten effizient zu gestalten, dürfen die Dokumente selbst nicht in die DocumentReference eingebettet werden, sondern müssen als separates Datenobjekt referenziert werden.

Wird ein separates Datenobjekt im ISIK-Kontext referenziert, so MUSS dieses konform zum Profil ISIKBinary aus dem Basismodul sein.

Update für Stufe 3: Die Ausnahme bildet die Interaktion "Dokumentenbereitstellung", bei der die Binärdaten des Dokumentes eingebettet in die DocumentReference an den Server übermittelt und dort dann in eine separate Ressource ausgelagert und über Attachment.url referenziert werden.

DocumentReference.content.attachment.creationDokumentendatum

Es obliegt dem erzeugenden System, zu entscheiden, welches Datum als Dokumentendatum geeignet ist, z.B. Datum der Erstellung oder Datum der letzten Änderung

DocumentReference.content.formatFormat des Dokumentes

Sofern das Dokument nicht auf einem standardisierten, strukturierten Austauschformat (z.B. CDA) basiert, für dessen Interpretation ein konkretes Schema herangezogen werden muss, genügt die Angabe des Codes "urn:ihe:iti:xds:2017:mimeTypeSufficient"

DocumentReference.context
DocumentReference.context.encounterAufenthaltsbezug
DocumentReference.context.encounter.referenceEncounter-Link

Begründung Pflichtfeld: Die Verlinkung auf eine Encounter-Ressource dient der technischen Zuordnung der Dokumentation zu einem Aufenthalt und ermöglicht wichtige API-Funktionen wie verkettete Suche, (Reverse-)Include etc. Hinweis Kompatibilität: In MHD 4.2.0 wurde das Verbot der Angabe einer Encounter-Referenz gelockert, das ISiK-Profil ist damit in diesem Punkt wieder kompatibel zu IHE MHD.

DocumentReference.context.facilityTypeArt der Einrichtung, aus der das Dokument stammt

Kann, sofern keine abweichende Information bekannt ist auf "KHS" gesetzt werden.

DocumentReference.context.practiceSetting

Binding auf IHE-DE Terminologie hinzugefügt

Encounter.id
Encounter.extension:Aufnahmegrund
Encounter.extension:Aufnahmegrund.extension:ErsteUndZweiteStelle
Encounter.extension:Aufnahmegrund.extension:DritteStelle
Encounter.extension:Aufnahmegrund.extension:VierteStelle
Encounter.identifier
Encounter.identifier:Aufnahmenummer
Encounter.identifier:Aufnahmenummer.type
Encounter.identifier:Aufnahmenummer.type.coding
Encounter.identifier:Aufnahmenummer.type.coding:vn-type
Encounter.identifier:Aufnahmenummer.type.coding:vn-type.system
Encounter.identifier:Aufnahmenummer.type.coding:vn-type.code
Encounter.statusplanned | in-progress | onleave | finished | cancelled +
Encounter.class
Encounter.type
Encounter.type:Kontaktebene
Encounter.type:KontaktArt
Encounter.serviceType
Encounter.serviceType.coding
Encounter.serviceType.coding:Fachabteilungsschluessel
Encounter.subject
Encounter.subject.reference
Encounter.period
Encounter.period.start
Encounter.period.end
Encounter.diagnosis
Encounter.diagnosis.condition
Encounter.diagnosis.use
Encounter.diagnosis.rank
Encounter.hospitalization
Encounter.hospitalization.admitSource
Encounter.hospitalization.dischargeDisposition
Encounter.hospitalization.dischargeDisposition.extension:Entlassungsgrund
Encounter.location
Encounter.location.location
Encounter.location.location.display
Encounter.serviceProvider
Encounter.serviceProvider.display
Encounter.partOf
Patient.id
Patient.identifier
Patient.identifier:Versichertennummer-GKV
Patient.identifier:Versichertennummer-GKV.type
Patient.identifier:Versichertennummer-GKV.system
Patient.identifier:Versichertennummer-GKV.value
Patient.identifier:Patientennummer
Patient.identifier:Patientennummer.type
Patient.identifier:Patientennummer.system
Patient.identifier:Patientennummer.value
Patient.identifier:Versichertennummer_PKV.use
Patient.identifier:Versichertennummer_PKV.type
Patient.identifier:Versichertennummer_PKV.value
Patient.identifier:Versichertennummer_PKV.assigner
Patient.identifier:Versichertennummer_PKV.assigner.identifier.system
Patient.identifier:Versichertennummer_PKV.assigner.identifier.value
Patient.identifier:Versichertennummer_PKV.assigner.display
Patient.active
Patient.name

In order to maintain the differntiations of name parts as given in the VSDM dataset or qualify prefixes as academic titles, vendors can opt to support the extensions specified in the German HumanName Base Profile https://simplifier.net/basisprofil-de-r4/humannamedebasis This is however not required within the scope of this specification.

Patient.name:Name
Patient.name:Name.use
Patient.name:Name.family
Patient.name:Name.family.extension:namenszusatz
Patient.name:Name.family.extension:nachname
Patient.name:Name.family.extension:vorsatzwort
Patient.name:Name.given
Patient.name:Name.prefix
Patient.name:Name.prefix.extension:prefix-qualifier
Patient.name:Geburtsname
Patient.name:Geburtsname.use
Patient.name:Geburtsname.family
Patient.name:Geburtsname.family.extension:namenszusatz
Patient.name:Geburtsname.family.extension:nachname
Patient.name:Geburtsname.family.extension:vorsatzwort
Patient.gender
Patient.gender.extension:Geschlecht-Administrativ
Patient.birthDate
Patient.birthDate.extension:Data-Absent-Reason
Patient.birthDate.extension:Data-Absent-Reason.value[x]
Patient.address

In order to differentiate between post box addresses and physical addresses, street names and house numbers, and to add city district names, vendors can opt to support the extensions as suggested in the German Address Base Profile http://fhir.de/StructureDefinition/address-de-basis. Such differentiations are however not required within the scope of this specification.

Patient.address:Strassenanschrift
Patient.address:Strassenanschrift.type
Patient.address:Strassenanschrift.line
Patient.address:Strassenanschrift.line.extension:Strasse
Patient.address:Strassenanschrift.line.extension:Hausnummer
Patient.address:Strassenanschrift.line.extension:Adresszusatz
Patient.address:Strassenanschrift.city
Patient.address:Strassenanschrift.postalCode
Patient.address:Strassenanschrift.country
Patient.address:Postfach
Patient.address:Postfach.type
Patient.address:Postfach.line
Patient.address:Postfach.line.extension:Postfach
Patient.address:Postfach.city
Patient.address:Postfach.postalCode
Patient.address:Postfach.country
Practitioner.id
Practitioner.identifier
Practitioner.identifier:Arztnummer
Practitioner.identifier:EFN
Practitioner.name
Practitioner.name:Name
Practitioner.name:Name.use
Practitioner.name:Name.family
Practitioner.name:Name.given
Practitioner.name:Name.prefix
Practitioner.name:Geburtsname.use
Practitioner.address:Strassenanschrift.extension:Stadtteil
Practitioner.address:Strassenanschrift.line.extension:Strasse
Practitioner.address:Strassenanschrift.line.extension:Hausnummer
Practitioner.address:Strassenanschrift.line.extension:Adresszusatz
Practitioner.address:Postfach.extension:Stadtteil
Practitioner.address:Postfach.line.extension:Postfach
Practitioner.gender
Practitioner.gender.extension:Geschlecht-Administrativ
Practitioner.gender.extension:Geschlecht-Administrativ.value[x]
Practitioner.birthDate.extension:Data-Absent-Reason
Procedure.id
Procedure.extension:Dokumentationsdatum
Procedure.status
Procedure.category
Procedure.category.coding:SNOMED-CT
Procedure.category.coding:SNOMED-CT.system
Procedure.category.coding:SNOMED-CT.code
Procedure.code
Procedure.code.coding
Procedure.code.coding:OPS
Procedure.code.coding:OPS.extension:Seitenlokalisation
Procedure.code.coding:OPS.system
Procedure.code.coding:OPS.version
Procedure.code.coding:OPS.code
Procedure.code.coding:SNOMED-CT.system
Procedure.code.coding:SNOMED-CT.code
Procedure.code.text
Procedure.subject
Procedure.subject.reference
Procedure.encounter
Procedure.performed[x]
Procedure.note
Coverage.identifierPrimärer Identifier der Versicherung
Coverage.identifier:KrankenversichertenID
Coverage.identifier:KrankenversichertenID.system
Coverage.identifier:KrankenversichertenID.value
Coverage.status
Coverage.type

28.07.2017 (zulip): TC Konsens bzgl. Verwendung eines eigenen ValueSets anstelle des im Standrad definierten preferred bindings, da die dortigen Codes nicht passen.

Coverage.type.coding
Coverage.type.coding.system
Coverage.type.coding.code
Coverage.beneficiary

Die Angabe der 10-stelligen Krankenversichertennummer ist verpflichtend. Durch die Referenz auf eine Patient-Resource können weitere Informationen zum Patienten hinterlegt werden.

Coverage.beneficiary.reference
Coverage.payor

Die Angabe der IK-Nummer des Versicherers in payor.identifier ist verpflichtend. Weitere Angaben zum Versicherer (Name, Adresse) können in einer Organization-Resource hinterlegt werden, auf die hier referenziert wird.

Coverage.payor.identifier
Coverage.payor.identifier.system
Coverage.payor.identifier.value
Coverage.payor.display
Coverage.subscriber
Coverage.subscriber.display
Coverage.beneficiary
Coverage.beneficiary.reference
Coverage.payor