cdaefa:CP-016-00: Unterschied zwischen den Versionen

Aus Hl7wiki
Wechseln zu: Navigation, Suche
(Vorschlag für die Änderung der EFAv2.0-Spezifikation)
K (Vorschlag für die Änderung der EFAv2.0-Spezifikation)
 
Zeile 109: Zeile 109:
 
|-
 
|-
 
|Limited Metadata
 
|Limited Metadata
|MAY be used
+
|Not applicable because EFA builds upon IHE XDS for which limited metadata is not permitted.
|EFAv2.0 does not constrain the use of this option.
+
|
 
|}
 
|}

Aktuelle Version vom 14. Februar 2016, 20:54 Uhr

Nutzung von XDS-Optionen explizieren

Titel des Change Request Nutzung von XDS-Optionen explizieren
Einreicher des Change Proposal Jörg Caumanns, Fraunhofer FOKUS

joerg.caumanns@fokus.fraunhofer.de

Datum der Einreichung des Change Proposal 12.07.15
Betroffene Revision der EFA-Spezifikation 1 (Release Januar 2015)
EFAv2.0 Wiki Perspective Implementable
EFAv2.0 Wiki Dimension Computational
Akteur / Klasse / Transaktion XDS Transaktionen
Change Proposal ID CP-016-00
Datum der Veröffentlichung im EFAv2.0 Wiki 12.07.15
Change Proposal Status Eingereicht
Abhängigkeit zum IHE Technical Framework Nein
Abhängigkeit zum IHE-D Cookbook Ja
Auswirkungen auf bestehende Implementierungen Nein
Datum der letzten Aktualisierung des Change Proposal 12.07.15
Zugewiesener Bearbeiter Wird per Telefonkonferenz von der 7er-Gruppe festgelegt


Motivation für den Change Request

Die aktuelle Version des ITI-Frameworks expliziert die semantische Verknüpfung von Dokumenten anhand der Metadaten (RPLC, XFRM, etc.) als XDS-Optionen (ggf. war das auch schon vorher so; ist mir aber erst im Zuge der Diskussionen zur XDS-Semantik im ITI-Forum aufgefallen). In der EFAv2.0-Spezifikation sollte an geeigneter Stelle angegeben werden, welche XDS-Optionen von der EFAv2.0 zwingend genutzt werden und welche optional genutzt werden können. Aktuell sind dies:

  • Document Replacement Option (ITI TF-3: 4.2.2.2.3): Erforderlich, sofern das Invalidieren eines Dokuments durch Ersetzen mit einem leeren Dokument erfolgen können soll.
  • Document Addendum Option (ITI TF-3: 4.2.2.2.1): eigentlich optional, auf der orangen und gelben Ebene ist jedoch die APND-Beziehung als Standard-Beziehung beschrieben. Falls diese Option optional sein soll (in der 7er-Gruppe zu entscheiden), dann müssen auch die Texte auf der konzeptuellen und logischen Ebene angepasst werden.
  • Document Transformation Option (ITI TF-3: 4.2.2.2.2): Erforderlich; Nutzung ist in der Spezifikation für die Verkettung von ConsentInfo und gescanntem Consent-Dokument vorgesehen.
  • Folder Management Option (TF-3:4.2.1.3 and ITI TF-3:4.2.2.1.5): Erforderlich.

Beschluss der 7er-Gruppe

(30.10.2015) Der Änderungsvorschlag wird angenommen. Die Umsetzung soll in die Ende Januar 2016 zu veröffentlichende Revision 2 der EFAv2.0-Spezifikation einfließen und ist Vorgabe für den EFA-Projectathon 2016. Folgende Festlegungen wurden von der 7er-Gruppe getroffen:

  • RPLC ist nur auf eigene Dokumente zulässig. Ansonsten muss das Dokument auf deprecated gesetzt und ein neues Dokument eingestellt werden. Der Bezug zur Vorversion wird in beiden Szenarien über die referenceIdList hergestellt.
  • APPND ist nicht zulässig. Der Bezug zu einem anderen Dokument wird nur über die referenceIdList hergestellt.
  • XFRM ist nicht zulässig. Der Bezug zu einem anderen Dokument wird nur über die referenceIdList hergestellt.
  • Folder Management Option muss implementiert werden.

Ein Vorschlag für die Änderung der Spezifikation wird bis Ende 2015 durch das Fraunhofer FOKUS ausgearbeitet und der 7er-Gruppe zur Freigabe vorgelegt.

Vorschlag für die Änderung der EFAv2.0-Spezifikation

http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS/XDR_Bindings

In das Kapitel "Constraints und Triggers" wird der nachfolgende Abschnitt eingefügt

IHE XDS Options

XDS Option Use for EFA Remarks
Document Replacement SHOULD NOT be used EFA clients may replace documents within any dedicated peer. In order to minimize complexity of peer-to-peer deployments, this option may only be used for replacing own documents. It must not be used for replacing documents that have been provided to EFA by another user.
Document Addendum MUST NOT be used This option does not work for EFA peer-to-peer deployments and therefore must not be used.
Document Transformation MUST NOT be used This option does not work for EFA peer-to-peer deployments and therefore must not be used.
Folder Management SHALL be implemented EFA access control builds upon folders. Therefore the implementation of this option is indispensible for EFA compliant systems.
Basic Patient Privacy Enforcement MUST NOT be used EFA requires full and written consent to be given by the patient. BPPC-style consents must not be used for EFA. Respective requests (e.g. providing or requesting a BPPC document) shall be ignored by all EFA actors.
Asynchronous Web Services Exchange MAY be used EFAv2.0 does not constrain the use of this option.
Reference-ID SHOULD be implemented EFA implementations may use the referenceIDList for linking related documents. In this case the FindDocumentsByReferenceId Query may be used for discovering related documents to a given document.
On-Demand Documents MAY be used EFAv2.0 does not constrain the use of this option.
Persistence of Retrieved Documents MAY be used EFAv2.0 does not constrain the use of this option.
Limited Metadata Not applicable because EFA builds upon IHE XDS for which limited metadata is not permitted.