ISiKNachricht (Communication)


Motivation

Die Communication-Ressource dient als Datenobjekt für den bidirektionalen Austausch von Nachrichten zwischen einem Leistungserbringer und einem Patienten. Es können sowohl Textnachrichten als auch Binärdateien ausgetauscht werden.

Zu einer Liste angrenzender Use Cases siehe Abschnitt zur Benachrichtigung unter Anwendungsfälle (Use Cases) - hier wird der spezifische Use Case für dieses Profil von anderen abgegrenzt.

Es liegt in der Verantwortung des bestätigungsrelevanten Systems, eine dem Schutzbedarf der ausgetauschten Nachrichten angemessene Sicherheit in Bezug auf Vertraulichkeit, Integrität und Verfügbarkeit herzustellen. Die Vorgaben des BSI, z. B. aus der TR-03161, sind zu beachten. Grundsätzlich liegen der vorliegenden Definition von ISiKNachricht die folgenden Annahmen zugrunde, die auch eine Nutzung einfach umsetzbarer Sicherheitsmaßnahmen ermöglichen:

  • ISiKNachricht SOLL ausschließlich für den Austausch administrativer, nicht personenbezogener Informationen im Kontext der Terminbuchung verwendet werden, z. B. zur Übermittlung von Coronahinweisen oder Lageplänen.
  • Der Austausch personenbezogener medizinischer Daten SOLL ausschließlich über die dafür vorgesehenen sicheren Dienste der Telematikinfrastruktur, wie z. B. ePA und zukünftig auch den TI-Messenger, erfolgen.

Normativer Status und Bestätigung

Dieses Profil MUSS im Rahmen der Bestätigung NICHT unterstützt werden. Falls das Profil unterstützt werden soll, MÜSSEN die hier definierten Festlegungen greifen (auch im Bestätigungsverfahren; in diesem Sinn sind auch die SHALL-Vorgaben im CapabilityStatement als bedingte zu verstehen).


Kompabilität

Siehe Kompabilität.


FHIR-Profil

NameCanonical
ISiKNachrichthttps://gematik.de/fhir/isik/StructureDefinition/ISiKNachricht

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
text0..1Narrative
contained0..*Resource
extensionI0..*Extension
modifierExtension?! I0..*Extension
identifierΣ0..*Identifier
instantiatesCanonicalΣ0..*canonical(PlanDefinition | ActivityDefinition | Measure | OperationDefinition | Questionnaire)
instantiatesUriΣ0..*uri
basedOnΣ I0..*Reference(Resource)
partOfΣ I0..*Reference(Resource)
inResponseToS I0..*Reference(Communication)
statusS Σ ?!1..1codeBinding
statusReasonΣ0..1CodeableConcept
category0..*CodeableConcept
priorityΣ0..1codeBinding
medium0..*CodeableConcept
subjectS Σ I1..1Reference(Patient)
topic0..1CodeableConcept
aboutI0..*Reference(Resource)
encounterΣ I0..1Reference(Encounter)
sentS0..1dateTime
received0..1dateTime
id0..1string
extensionI0..*Extension
referenceΣ I0..1string
typeΣ0..1uriBinding
identifierS Σ0..1Identifier
displayS Σ1..1string
id0..1string
extensionI0..*Extension
referenceS Σ I1..1string
typeΣ0..1uriBinding
identifierΣ0..1Identifier
displayΣ0..1string
id0..1string
extensionI0..*Extension
referenceS Σ I0..1string
typeΣ0..1uriBinding
identifierS Σ0..1Identifier
displayS Σ1..1string
reasonCodeΣ0..*CodeableConcept
reasonReferenceΣ I0..*Reference(Condition | Observation | DiagnosticReport | DocumentReference)
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
contentReferenceReference(Resource)
contentStringS0..1string
id0..1string
extensionI0..*Extension
contentTypeS Σ1..1codeBinding
languageΣ0..1codeBinding
data0..0base64Binary
urlS Σ1..1url
sizeΣ0..1unsignedInt
hashΣ0..1base64Binary
titleΣ0..1string
creationS Σ1..1dateTime
note0..*Annotation

Folgende FHIRPath-Constraints sind im Profil zu beachten:


Anmerkungen zu Must-Support-Feldern

Communication.inResponseTo

Bedeutung: Falls die Communication-Ressource in einen zeitlichen Zusammenhang mit weiteren Nachrichten gebracht werden muss, KÖNNEN die Nachrichten miteinander verknüpft werden. Neue Nachrichten MÜSSEN auf die bereits zuvor existierenden Nachrichten zeigen.

Communication.subject

Bedeutung: Patient-Referenz als Aussage für welche Patienten die Communication verfasst wird

Hinweis: Ein Patientenbezug muss stets gegeben sein, soweit möglich.

Communication.recipient

Bedeutung: Empfänger der Communication

Hinweis: Für Practitioner und HealthcareService muss Reference.reference angegeben werden. Für weitere Ressourcen MUSS ein Reference.display angegeben werden.

Communication.sender

Hinweis: Für Patient, Practitioner und HealthcareService muss Reference.reference angegeben werden. Für weitere Ressourcen MUSS ein Reference.display angegeben werden.

Communication.payload

Bedeutung: Inhalt der Communication

Hinweis: Ein bestätigungsrelevantes System MUSS sowohl Freitext, als auch base64-kodierte Inhalte unterstützten. Falls strukturierte Metadaten über das zu übermittelnde Dokument verfügbar sind, KANN ein bestätigungsrelevantes System es als DocumentReference-Ressource ablegen. Für die Anlage einer solchen Ressource wird auf das ISiK Dokumentenaustausch verwiesen. Die erzeugte Ressource SOLL anschließend durch das bestätigungsrelevante System unter dem contentReference-Element als Referenz angegeben werden. Jegliche Funktionalität bezogen auf das Modul Dokumentenaustausch ist nicht bestätigungsrelevant. Dokumente welche als Attachment angegeben werden, MÜSSEN in ihrer URL auf eine ISiKBinary Ressource verweisen. Diese Binary-Ressource SOLL per CREATE-Interaktion angelegt werden im empfangenden System.


Interaktionen

Für die Ressource Communication MÜSSEN die REST-Interaktionen "READ", "CREATE", "UPDATE" implementiert werden.

  1. Der Suchparameter "_id" MUSS unterstützt werden:

    Beispiele:

    GET [base]/Communication?_id=103270

    Anwendungshinweise: Weitere Informationen zur Suche nach "_id" finden sich in der FHIR-Basisspezifikation - Abschnitt "Parameters for all resources".

  2. Der Suchparameter "subject" MUSS unterstützt werden:

    Beispiele

    GET [base]/Communication?subject=Patient/ISiKPatientExample

    Anwendungshinweise: Weitere Informationen zur Suche nach "Communication.subject" finden sich in der FHIR-Basisspezifikation - Abschnitt "reference"

  3. Der Suchparameter "recipient" MUSS unterstützt werden:

    Beispiele

    GET [base]/Communication?recipient=Practitioner/ISiKPractitionerExample

    Anwendungshinweise: Weitere Informationen zur Suche nach "Communication.subject" finden sich in der FHIR-Basisspezifikation - Abschnitt "reference"

  4. Der Suchparameter "sender" MUSS unterstützt werden:

    Beispiele

    GET [base]/Communication?sender=Practitioner/ISiKPractitionerExample

    Anwendungshinweise: Weitere Informationen zur Suche nach "Communication.subject" finden sich in der FHIR-Basisspezifikation - Abschnitt "reference"


Beispiele

{
    "resourceType": "Communication",
    "id": "ISiKNachrichtExample",
    "meta": {
        "profile":  [
            "https://gematik.de/fhir/isik/StructureDefinition/ISiKNachricht"
        ]
    },
    "status": "completed",
    "subject": {
        "reference": "Patient/ISiKPatientExample"
    },
    "recipient":  [
        {
            "display": "Dr. Martina Musterfrau",
            "reference": "Practitioner/ISiKPractitionerExample"
        }
    ],
    "sender": {
        "display": "Dr. Erika Gabler",
        "reference": "Patient/ISiKPatientExample"
    },
    "payload":  [
        {
            "contentString": "Dies ist eine Testnachricht!"
        }
    ]
}