C_11877_Anlage_V1.0.0
Prereleases:
Motivation
Die gematik hat als zukünftige Digitalagentur Gesundheit die Aufgabe, die Digitalisierung im Gesundheitswesen voran zu bringen.
In der Anwendung KIM besteht ein "blinder" Fleck, da aktuell nicht nachvollzogen werden kann, welche Fachrichtungen welcher Berufsgruppen bereits hoheitliche Vorgaben (z.B. Pflicht zum elektronischen Arztbrief via KIM) umsetzen und welche nicht.
Hierfür wurde in C_11193 eine Anpassung vorgeschlagen, die jedoch zur Sammlung personenbezogener (pseudonymisierte E-Mailadresse mit Postleitzahlbezug) Daten in der gematik-Betriebsdatenerfassung geführt hätte - diese Änderung wurde BfDI-seitig nachvollziehbar abgelehnt.
Dieser Änderungseintrag soll die Ergänzung der Betriebsdaten OHNE Personenbezug umsetzen, in dem ausschließlich je Sender und Empfänger die
- Berufsgruppe professionOID = gemäß [gemSpec_OID#GS-A_4442-*] (Zertifikatsinformationen), sowie
- sofern bekannt, die Fachrichtung gemäß https://wiki.hl7.de/index.php?title=IG:Value_Sets_f%C3%BCr_XDS#DocumentEntry.practiceSettingCode (optionale/freiwillige Angabe im Verzeichnisdienst)
in den Rohdaten übermittelt werden sollen.
Inhaltsverzeichnis
1 Änderung in gemSpec_CM_KOMLE
3.1 Allgemeine Anforderungen
[...]
A_26074 - Clientmodul - Übermittlung von zusätzlichen Header-Informationen
Das Clientmodul MUSS beim Versand einer Nachricht die folgenden X-KIM Header erzeugen.
- X-KIM-FromData: Enthält die Daten aus dem VZD-Eintrag des Senders {<professionOID>,<specialization>}. Wenn mehrere Attribute vorhanden sind, werden sie durch "|" getrennt.
- Beispiel: urn:oid:1.3.6.1.4.1.19376.3.276.1.5.5|urn:oid:1.3.6.1.4.1.19376.3.276.1.5.4
- X-KIM-ToData: Enthält die Daten aus dem VZD-Eintrag des Empfängers (MAIL TO) {<professionOID>,<specialization>}.
- X-KIM-CcData: Enthält die Daten aus dem VZD-Eintrag des Empfängers (MAIL CC) {<professionOID>,<specialization>}
Header-Element | Beschreibung |
---|---|
X-KIM-Message-ID | Enthält die Message-Id der Nachricht |
X-KIM-FromData | Enthält Daten aus dem VZD-Eintrag des Senders. Der Wert specializationOid ist nur bei Vorhandensein zu befüllen (optionales Feld im VZD-Eintrag). Format (JSON-String): { "fromOid": "<professionOID>|<specialization>" } 2 Beispiele: { "fromOid":"1.2.276.0.76.4.50" } { "fromOid":"1.2.276.0.76.4.50|1.3.6.1.4.1.19376.3.276.1.5.5|urn:psc:1.3.6.1.4.1.19376.3.276.1.5.4:ALLG" } |
X-KIM-ToData | Enthält Daten aus dem VZD-Eintrag des Empfängers (MAIL TO). Wenn mehrere professionOID oder specialization Attribute vorhanden sind, werden sie durch "|" getrennt. Der Wert specializationOid ist nur bei Vorhandensein zu befüllen (optionales Feld im VZD-Eintrag). Format (JSON-Array): { "toOid": [ "<professionOID>|<specialization>" ] } Beispiel: { "toOid": [ "1.2.276.0.76.4.50|urn:psc:1.3.6.1.4.1.19376.3.276.1.5.4:ALLG", "1.2.276.0.76.4.50"] } |
X-KIM-CcData | Enthält die Daten aus dem VZD-Eintrag des Empfängers (MAIL CC). Wenn mehrere professionOID oder specialization Attribute vorhanden sind, werden sie durch "|" getrennt. Der Wert specializationOid ist nur bei Vorhandensein zu befüllen (optionales Feld im VZD-Eintrag). Format (JSON-Array): { "ccOid": [ "<professionOID>|<specialization>" ] } 2 Beispiele: { "toOid": [ "1.2.276.0.76.4.50|1.3.6.1.4.1.19376.3.276.1.5.5" ] } { "toOid": [ ] } |
Wenn mehrere Empfänger adressiert wurden, MUSS das jeweilige Header-Element mehrfach angegeben werden. [<=]
=> funkt. Eignung: Test Produkt/FA
2 Änderungen in Steckbriefen
Anmerkung: Die Anforderungen der folgenden Tabelle stellen einen Auszug dar und verteilen sich innerhalb der Tabelle des Originaldokuments [gemProdT_...]. Alle Anforderungen der Tabelle des Originaldokuments, die in der folgenden Tabelle nicht ausgewiesen sind, bleiben unverändert bestehenden.
Änderungen in gemProdT_CM_KOMLE und gemProdT_Basis-Consumer:
Tabelle
Anforderungen zur funktionalen Eignung "Produkttest/Produktübergreifender Test"Afo-ID | Afo-Bezeichnung | Quelle (Referenz) |
---|---|---|
A_26074 |
Clientmodul - Übermittlung von zusätzlichen Header-Informationen | gemSpec_CM |