320
Bearbeitungen
Änderungen
→XDS-I Metadaten für DICOM KOS Objekte
=XDS-I Metadaten für DICOM KOS Objekte=
==XDS Metadaten 1: aus dem DICOM KOS Objekt abgeleitet==
#Die ''authorInstitution'' benötigt einen Namen und eine OID, die aus dem GDA-Index abgleitet werden kann
#*''id'' OID der Organisation aus dem GDA-Index (muss ermittelt werden)
#*''name'' (0008,0080), Institution Name, Name der Organisation als String,
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da sie vom ELGA Berechtigungssystem bei Registrierung geprüft wird.
'''Achtung:''' Das DICOM-Tag (0008,0080), Institution Name, ist vom Type 3 (optional) (General Equipment Module).
'''Achtung:''' Prinzipiell können sich die Werte in der Studie und im KOS unterscheiden. Auch zur Studie können Geräte in verschiedenen Institutionen beitragen. Bei der Ermittlung der Institution ist Sorge zu tragen, dass die maßgeblich an der Erzeugung der Studie beteiligte Institution als Metadatum verwendet wird.
{{EndYellowBox}}
#*Hersteller: Attribut „Manufacturer“, (0008,0070)
#*Modellname: Attribut „ Manufacturer's Model Name“, (0008,1090) ----[[#%20ftnref1|[2]]] Erlaubte Werte siehe <nowiki>http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#sect_C.7.3.1.1.1</nowiki>
{{BeginYellowBox}}
'''Achtung:''' Die Identifikationsdaten und Namen der durchführenden Ärzte können in verschiedenen Serien der Studie unterschiedlich sein. Bei der Ermittlung des Autors ist Sorge zu tragen, dass die Person angegeben wird, die die maßgeblichen Teile der Studie verantwortet.
'''Achtung:''' Zur Studie können mehrere Geräte beitragen. Bei der Ermittlung des Autors ist Sorge zu tragen, dass das maßgeblich an der Erzeugung der Studie beteiligte Gerät als Metadatum verwendet wird.
{{EndYellowBox}}
=====Spezifikation für Personen=====
*„Facharzt für Nuklearmedizin“
======Spezifikation======
Das Datum MUSS immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 20160518 in 20160518000000).
In den XDS Metadaten können keine Zeitzonen abgebildet werden, daher MUSS eine Zeitangabe zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! Dies entspricht einer Transformation auf den HL7 v2 DTM Datentyp gemäß [IHE ITI-TF3]. <br />{{EndYellowBox}}
===eventCodeList (und eventCodeListDisplayName)===
===sourcePatientInfo===
Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten. Die Patienten ID wird wie in Kapitel 3.2.12 sourcePatientId gemappt und verwendet[[#%20ftn1|[5]]].
----[[#%20ftnref1|[5]]] IHE RAD TF vol3 Vorgaben Table 4.68.4.1.2.3-1: XDS-I.b-specific Metadata Requirements {{BeginYellowBox}}
In ELGA werden die Elemente name, administrativeGender, birthTime und addr NICHT zur Identifikation des Patienten benötigt, die Speicherung dieser Daten erhöht aber den Sicherheits- und Schutzbedarf der Registry unnötig. Eine Speicherung in der Registry ist im Sinne der Datenminimierung (DSGVO) NICHT ERLAUBT.
{{EndYellowBox}}
$gender = ""
$addr = "" <br /><pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
</Slot>
</ExtrinsicObject>
</pre><br />
===title===
Das ''title'' Element beschreibt den lesbaren Titel des registrierten Objektes.
#Wenn Study Description nicht angegeben ist, muss ein sprechender Titel aus dem DisplayName des APPC generiert werden, z.B. („CT.Unpaarig.Unbestimmte Proze-dur.Lendenwirbelsäule“
{{BeginYellowBox}} '''Achtung:''' Für den Fall, dass alle Objekte einer Studie mittels IOCM storniert wurden, enthält diese Studie nur noch die Rejection Note. Der Modality Code ist in diesem Fall “KO”.{{EndYellowBox}}<br />
====Spezifikation====
===typeCode (und typeCodeDisplayName)===
Das ''typeCode'' Element beschreibt den DokumententypObjekttyp, dem das Dokument KOS Objekt angehört. Der Dokumententyp Objekttyp ist die Spezialisierung einer DokumentenklasseObjektklasse, jeder Dokumententyp Objekttyp gehört zu genau einer DokumentenklasseObjektklasse.
Unterscheidung typeCode/classCode:
|- style="background:white"
|'''typeCode'''
|'''Dokumentenklasse Objektklasse in feiner Granularität (Spezialisierung).'''
|- style="background:white"
|classCode
|Dokumentenklasse Objektklasse in grober Granularität.<br /> Siehe Kapitel [[ILF:XDS Metadaten 2020#classCode_.28und_classCodeDisplayName.29|classCode]]
|}
====Spezifikation====
'''typeCode (und typeCodeDisplayName)''' wird wird als ebRIM Classification zum DocumentEntry umgesetzt und gemäß folgender Vorschrift zusammengesetzt:
Es wird ein fester Wert gesetzt: '''55113-5''' „Key images Document Radiology“ <span> $code</span> = ClinicalDocument/code/@code"55113-5"<br /><span> $displayName</span> = ClinicalDocument/code/@displayName"Key images Document Radiology"<br /><span> $codeSystem</span> = ClinicalDocument/code/@codeSystem"2.16.840.1.113883.6.1"<br />
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983"
classifiedObject="theDocumentKeyImageObject"
nodeRepresentation="$code">
<Name>
Der contentTypeCode des SubmissionSets wird als ebRIM Classification umgesetzt und soll dieselben Werte wie typeCode des DocumentEntry tragen.
$code = ClinicalDocument/code/@code $displayName = ClinicalDocument/code/@displayName"55113-5"
$codeSystem displayName = ClinicalDocument/code/@codeSystem"Key images Document Radiology"
$codeSystem = "2.16.840.1.113883.6.1"<pre class="ilfbox_code">
<RegistryPackage
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
<Classification
classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500"
classifiedObject="theDocumentKeyImageObject"
nodeRepresentation="$code">
<Name>
</Classification>
</RegistryPackage>
</pre>Jeder Container darf dementsprechend nur 1 Dokument enthalten.
===uniqueId===
Das ''uniqueId'' Element beschreibt den global eindeutigen Identifier des Dokuments. Dieser Identifier wird entweder vom Document Source Actor erzeugt oder im Fall eines evtl. verwendeten Adapters vom Informationssystem des GDA übernommen.uniqueId wird als ebRIM
Im Fall eines CDA R2 Dokuments KOS-Objektes gilt folgende Verknüpfung mit den CDA Header ElementenMetadaten: #Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer ID für das Dokument verpflichtend:##ClinicalDocument/id
(0008,0018) SOP Instance UID (VR:UI, VM:1)
====Spezifikation====
uniqueId wird als ebRIM ExternalIdentifier zum DocumentEntry gemäß folgender Vorschrift zusammengesetzt:<br />
<pre class="ilfbox_code">
===referenceIdList===
Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen.
*'''No other components shall be present.'''
|}
{{BeginYellowBox}}
'''ACHTUNG: '''Aufgrund der Tatsache, dass es bei den entsprechenden Elementen im CDA Dokument keine Einschränkung bezüglich der Länge gibt wird davon ausgegangen, dass in Abänderung der HL7 Vorgaben hier keine Einzel-Längenprüfungen stattfinden. Aus sicherheitstechnischen Überlegungen ist im Rahmen von ELGA als Grenze für das einzelne CXi Element 255 Zeichen vorgeschrieben..
{{EndYellowBox}}
=====Spezifikation=====
ownDocument-SetId wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
Für KOS Objekte kann die ''StudyInstanceUID'' (0020,000D) als SetId verwendet werden.
$id = (0020,000D) VR=UI Study Instance UID, z.B. 1.2.40.0.34.99.111.1.1
$homeCommunityId = OID des lokalen ELGA-Bereiches z.B. 1.2.40.0.34.99.999
concat
(
"urn:elga:iti:xds:2014:ownDocument_setId", "^&amp;",
$homeCommunityId, "&amp;ISO"
)
Wie oben angeführt wird folgender CXi Wert erstellt:
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList> <Value>ZZZZZZZZZZZZZZZZZZZ^^^&amp;amp;1.2.40.0.34.99.111.1.1 <nowiki>&</nowiki>amp;amp;ISO^^^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki> ^&amp;amp;1.2.40.0.34.99.999 <nowiki>&</nowiki>amp;amp;ISO</Value>
</ValueList>
</Slot>
Die homeCommunityId ist die eindeutige OID, unter welcher die ELGA Affinity Domäne registriert ist.
====Referenz zwischen Dokument und Studie ('''Accession Number''')====
Um eine Verknüpfung zwischen den über ein KOS Objekt referenzierten Bilddaten und den zugehörigen Befunden herzustellen, wird ein weiterer Identifier benötigt, der sowohl bei der Aufnahme (''acquisition, store'') als auch bei der Befundschreibung (''report'') verfügbar ist. Dies trifft auf die Accession Number zu (dasjenige Element, das im Workflow zur Verknüpfung von Studie und Befund verwendet wird).
=====Spezifikation=====
Bei der Registrierung von KOS Objekten MUSS eine Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden.
Für Befunde der Bildgebenden Diagnostik (diagnostic image report) kann die Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden, wenn eine Verlinkung gewünscht wird.
Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen (siehe oben).
Accession Number wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
$id = Accession Number z.B. 20201111
$root = OID des lokalen Namensraums der ID, z.B. 1.2.40.0.34.99.111.2.1
concat
(
$id, "^^^", "&amp;"
$root, "&amp;ISO", "^",
)<br /><pre class="ilfbox_code"> <ClinicalDocument xmlnsExtrinsicObject mimeType="text/xml" objectType="<nowiki>urn:hl7uuid:7edca82f-org:v3054d-47f2-a032-9b2a5b5186c1</nowiki>">…<setId root status="2.25<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>" extension id="<nowiki>urn:uuid:19FEE6C31e2ede82-6B358570-4C5B4be2-B1CCbd46-2B5B4001AB2de986a4333be</nowiki>"/> <versionNumber valueSlot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>"> <ValueList> <Value>20201111^^^amp;1.2".40.0.34.99.999 <nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value> </ValueList> … </Slot> </ClinicalDocumentExtrinsicObject></pre>Siehe auch IHE RAD TF3 4.68.4.1.2.4.1 “Linking Report to Set of DICOM Instances” ====Weitere Einträge der referenceIDList====Über die bereits genannten Einträge hinaus sind weitere Einträge in der referenceIdList erlaubt:
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre><br />===intendedRecipient===Für die spätere Verwendung von IHE Cross Enterprise Document Workflow (XDW) ist der ''intendedRecipient'' notwendig. Derzeit wird dieses Element in ELGA nicht verwendet. Sobald IHE XDW für ELGA zugelassen wird, folgt die Spezifikation dieses Elementes. Der intendedRecipient entfällt bei XDS-I.
===intendedRecipientcomments===Für die spätere Das ''comments'' Element enthält Kommentare zum Objekt. Die Verwendung von IHE Cross Enterprise Document Workflow ist in ELGA optional (XDW) ist der intendedRecipient notwendig. Derzeit wird dieses Element in ELGA einigen Implementierungen nicht verwendetangezeigt, z.B. Sobald IHE XDW für ELGA zugelassen wird, folgt die Spezifikation dieses Elementes. Bürgerportal)
====Spezifikation====
Comments wird gemäß folgender Vorschrift zusammengesetzt:
$comment = (0008,1030) Study Description<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Description">
<LocalizedString value = "$comment"/>
</Description>
</ExtrinsicObject>
</pre><br />
==XDS Metadaten 2: explizit zu setzen (ELGA relevant)==
===availabilityStatus===
Das availabilityStatus-Element beschreibt die Aktualität/Sichtbarkeit des eingebrachten DokumentsObjektes.
Mögliche Werte laut IHE sind:
*Deprecated
Dieses Attribut wird im Zuge des Einbringens von neuen Dokumenten Objekten („Submission“) durch die empfangende XDS Registry immer auf “'''Approved'''” gesetzt.
availabilityStatus wird im Attribut @status des ebRIM ExtrinsicObject abgebildet, das das DocumentEntry repräsentiert.
===formatCode (und formatCodeDisplayName)===
Das ''formatCode'' Element beschreibt das Format des Dokuments bezüglich seiner semantischen Interoperabilitätregistrierten Objekts. Es ermöglicht einem empfangenden System (''Document Consumer Actor'') die Identifizierung des für die Weiterverarbeitung zu erwartenden Dokumentenformats und somit die korrekte Darstellung und Verarbeitung des Dokuments.Im CDA-Schema wurde für die HL7-Austria Domäne ein genau entsprechendes Element geschaffen, "hl7at:formatCode".
====Bildungsregel für den formatCodeDisplayNameSpezifikation====TODO'''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt: Prüfen, ob diese Bildungsregel noch gültig ist. Weiters ist FormatCodeDisplayName ist nicht Teil des CDA, allerdings 1..1 M nach IHE XDS.
<pre class="ilfbox_code">
<Classification
===healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)===
Das ''healthcareFacilityTypeCode'' Element beschreibt die Klassifizierung des GDA, z.B. *158 „Fachärztin/Facharzt“*304 „Allgemeine Krankenanstalt“ Es wird der Code aus dem CDA Header Im KOS Objekt steht kein Element "healthCareFacility" genutztfür ein automatisches Mapping in dieses Feld zur Verfügung. (Eine vorgeschlagene Methodik siehe Kapitel zu authorInstitution). {{BeginYellowBox}} Zulässige Werte gemäß Value Set „[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_HealthcareFacilityTypeCode ELGA_ HealthcareFacilityTypeCode]“.{{EndYellowBox}}
====Spezifikation====
'''healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:
<span>$code </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@codeKlassifizierung des GDA (Code)
<span>$displayName </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@displayNameKlartext des angegebenen Codes
<span>$codeSystem </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@codeSystemOID der ausgebenden Stelle
<pre class="ilfbox_code">
===mimeType===
Das ''mimeType'' Element beschreibt den „Internet Media Type“ des Dokuments gemäß dem „Multipurpose Internet Mail Extensions“ (MIME) Standard. Der Standard wird beschrieben in RFC 2045 bis RFC 2049.<ref name="RFC2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [httphttps://tools.ietf.org/html/rfc2045 IETF <nowiki>RFC 2045[6]</refnowiki>] und RFC 2049.<ref name="RFC2046RFC2045">Multipurpose Internet Mail Extensions (MIME) Part Part TwoOne: Media Types Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2046 rfc2045 IETF RFC 20462045]</ref><ref name=Im Fall von KOS-Objekten ist der Mime Type immer fix "RFC2047application/dicom">Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-ASCII Text [http://tools.ietf.org/html/rfc2047 IETF RFC 2047]</ref><ref name="RFC2048">Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures [http://tools.ietf.org/html/rfc2048 IETF RFC 20486]</ref><ref name="RFC2049"nowiki>Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples [http://tools.ietf.org/html/rfc2049 IETF RFC 2049]rfc2045</refnowiki>
====Spezifikation====
'''mimeType''' wird im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, das das DocumentEntry repräsentiert.
Folgende Mime-Types sind für Dokumente zugelassen:<br />CDA R2: '''text/xml'''<br />DICOM/KOSObjekte zugelassen: '''application/dicom'''<br />
*application/dicom<br />
<pre class="ilfbox_code">
<ExtrinsicObject
id="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
mimeType="textapplication/xmldicom"
objectType="urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"/>
</pre>
===practiceSettingCode (und practiceSettingCodeDisplayName)===
Das ''practiceSettingCode'' Element beschreibt die fachliche Zuordnung des Objektes. Es soll den Fachbereich wiedergeben, dem der Inhalt des Objektes am besten entspricht, unabhängig von der Fachrichtung des Autors oder der erstellenden Abteilung, z.B.:
====Spezifikation====
'''practiceSettingCode (und practiceSettingCodeDisplayName)''' wird als ebRIM Classificationgemäß folgender Vorschrift zusammengesetzt:
<span>$code</span> = ClinicalDocument/hl7at:practiceSettingCode/@codeCode aus Value Set ELGA_PracticeSetting<br /><span>$displayName</span> = ClinicalDocument/hl7at:practiceSettingCode/@Klartext des angegebenen Codes (displayName)<br /><span>$codeSystem</span> = ClinicalDocument/hl7at:practiceSettingCode/@codeSystemOID des Codesystems (1.2.40.0.34.5.12)<br />
<pre class="ilfbox_code">
<Classification
Das objectType Element gibt den Typ des XDS DocumentEntry wieder. Entsprechend den IHE XDS Vorgaben wird zwischen den Typen „stabiles Dokument“ (stable document, SD) und „On-demand Dokument“ (on-demand document, ODD) unterschieden. Der objectType ist als ebRIM ExtrinsicObjectist/@objectType Attribut umgesetzt und jeweils durch eine fixe UUID identifiziert.
Für KOS Objekte wird der fixe Wert "[[urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be]]" für "Stable Document" DocumentEntryvorgegeben:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
