cdaefa:CP-016-00

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.