cdaefa:CP-004-00

CP-004-00: Invalidieren von Dokumenten (Inkonsistenz zum IHE-Cookbook)

Titel des Change Request	Invalidieren von Dokumenten (Inkonsistenz zum IHE-Cookbook)
Einreicher des Change Proposal	Jörg Caumanns, Fraunhofer FOKUS joerg.caumanns@fokus.fraunhofer.de
Datum der Einreichung des Change Proposal	09.04.15
Betroffene Revision der EFA-Spezifikation	1 (Release Januar 2015)
EFAv2.0 Wiki Perspective	Logical / Implementable
EFAv2.0 Wiki Dimension	Computational
Akteur / Klasse / Transaktion	Invalidieren eines Dokuments
Change Proposal ID	CP-004-00
Datum der Veröffentlichung im EFAv2.0 Wiki	09.04.15
Change Proposal Status	Angenommen
Abhängigkeit zum IHE Technical Framework	Nein
Abhängigkeit zum IHE-D Cookbook	Ja
Auswirkungen auf bestehende Implementierungen	Ja
Datum der letzten Aktualisierung des Change Proposal	30.10.15
Zugewiesener Bearbeiter	Jörg Caumanns

Motivation für den Change Request

In der EFA-Spezifikation wird beschrieben, dass die Invalidierung eines Dokuments durch das Ersetzen dieses Dokuments mit einem Invalidierungsdokument erfolgt (siehe http://wiki.hl7.de/index.php?title=cdaefa:EFA_Kommunikationsmuster). Es folgt der Hinweis, dass näheres hierzu im IHE Cookbook spezifiziert wird. Im IHE Cookbook gibt es keine generellen Vorgaben zu dem Thema. Im Kapitel zur pEPA wird jedoch definiert, dass zur Invalidierung eines Dokuments die IHE-Transaktion ITI-62 deleteDocumentSet zu verwenden ist (siehe http://wiki.hl7.de/index.php?title=IHE_DE_Cookbook). Die uns bekannten EFAv2.0-Implementierungen hingegen erlauben ergänzend zur Spezifikation auch das Setzen des Status eines Dokuments auf deprecated mittels der IHE-Transaktion ITI-52 MetadataUpdate. Diese Variante ist auch konform zur IHE-Umsetzung in der österreichischen ELGA. Es ist unklar, was nun gilt:

• Ersetzen durch ein Invalidierungsdokument,
• Setzen des Status auf deprecated über ITI-52 oder
• Löschen des Dokuments über ITI-62?

Es wird vorgeschlagen, sich an den Implementierungen zu orientieren und neben dem Ersetzen des Dokuments auch das Setzen des Dokumentenstatus auf deprecated mittels ITI-52 zuzulassen.

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. Folgende Festlegungen wurden von der 7er-Gruppe getroffen:

• Ein EFA-Teilnehmer kann Dokument per MetadataUpdate" auf den Status deprecated setzen. Dies soll auch über Affinity Domains hinweg möglich sein.
• Das Löschen durch Ersetzen mit einem leeren Dokument wird aus der Spezifikation gestrichen.

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

Änderung der EFAv2.0-Spezifikation (Interaktionsmuster "Invalidieren von Datenobjekten")

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

Anwendungsszenario: Invalidieren von Daten in einer Fallakte

In eine Fallakte eingestellte Daten (siehe Interaktionsmuster Einstellen von Datenobjekten) sind für alle EFA-Teilnehmer sichtbar und abrufbar. Die Pflege der Inhalte einer EFA ist die gemeinsame Aufgabe aller EFA-Teilnehmer; daher kann jeder Teilnehmer jedes in der EFA befindliche Dokument deaktivieren oder ersetzen, wenn dieses nicht mehr aktuell ist oder zur Erreichung des Zwecks der Akte nicht mehr benötigt wird.Zuweilen kann es passieren, dass ein zuvor in eine EFA eingestelltes Dokument invalidiert werden muss, z.B. da es im Nachhinein als falsch erkannte Informationen enthält oder versehentlich ein falsches Dokument eingestellt wurde (z.B. aufgrund einer intern falsch aufgelösten Patientenidentität).

Änderung der EFAv2.0-Spezifikation (Kommunikationsmuster "Invalidieren eines Dokuments")

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

Invalidieren eines Dokuments

Das EFA-Teilnehmersystem invalidiert ein Datenobjekt, indem es das Datenobjekt mit dem Invalidierungsdokument ersetzt. Es wird im IHE-D Cookbook definiert werden.

Dieses Muster ist abhängig von:

• Auflisten von Dokumenten.

Um ein Dokument zu invalidieren:

1. Das EFA-Teilnehmersystem (TNS) wählt das zu ersetzende Dokument aus.
2. Das TNS ruft die Operation invalidateData des EFA-Document-Registry auf. des EFA-Document-Repository auf. Es wird das Invalidierungsdokument und die ersetzt-docRelationship übermittelt.
3. Das EFA-Document-Repository
   1. speichert das Invalidierungsdokument (docData),
   2. ruft die Operation registerData des EFA-Document-Registry auf.
4. Das EFA-Document-Registry
   1. markiert das ersetztereferenzierte Dokument als ungültig, sofern dieses in der lokalen Affinity Domain registriert ist
   2. gibt dem EFA-Document-Repository eine Status-Meldung.
5. Das EFA-Document-Repository gibt dem TNS eine Status-Meldung.

Änderung der EFAv2.0-Spzifikation (EFA Anwendungsdienste: Logische Spezifikation)

http://wiki.hl7.de/index.php?title=cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)

EFA Anwendungsarchitektur: Service Functional Model

Die nachfolgende Tabelle listet zu den EFA-Kommunikationsmustern die zu deren Umsetzung benötigten Operationen auf. Die Gesamtheit dieser Operationen bildet das Service Functional Model der EFA-Anwendungsarchitektur, d.h. liefert eine vollständige plattformunabhängige Beschreibung der technisch umzusetzenden EFA-Funktionalität.

Kommunikationsmuster	Operation (logisch)	Umsetzender Dienst (logisch)
Anlegen einer Fallakte	createECR	EFA Ressource Manager
Anlegen einer Partition zu einer bestehenden Fallakte	createPartition	EFA Ressource Manager
Schließen einer Fallakte	closeECR	EFA Ressource Manager
Auflisten von Partitionen	listPartitions	EFA Ressource Manager
Registrierung einer neuen Einwilligung	registerConsent	EFA Ressource Manager
Verteilen einer Einwilligung im EFA-Verbund	notifyOfConsent	EFA Ressource Manager
Anfordern eines Berechtigungstoken	issueAccessToken	EFA Ressource Manager
Einlösen eines Berechtigungstoken	redeemAccessToken	EFA Ressource Manager
	listRecordLocations	EFA Ressource Manager
	registerRecordLocation	EFA Ressource Manager
Einstellen von Dokumenten	provideData	EFA Document Repository
	registerData	EFA Document Registry
Auflisten von Dokumenten (einer Partition)	listPartitionContent	EFA Document Registry
Abrufen von Dokumenten	retrieveData	EFA Document Repository
Invalidieren eines Dokuments	invalidateData	EFA Document Registry

Das Zusammenspiel von Diensten und Operationen ist in der folgenden Darstellung noch einmal im Überblick dargestellt.

ERGÄNZEN DER GRAFIK

---

Der folgende Abschnitt wird neu eingefügt

invalidateData

Operation	invalidateData
Funktionalität	Invalidieren eines Dokuments in einer Fallakte.
Aufrufer	EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne, EFA Document Registry einer benachbarten EFA-Provider-Domäne
Eingabe	context	Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager openContext.
	documentID	Eindeutige Identifizierung des zu invalidierenden Dokuments
Rückgabe	statusInfo	Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
	Vorbedingungen
Ablauf	Das Document Registry ... prüft, ob das zu invalidiernde Dokument in der eigenen Affinity Domain verwaltet wird: falls dies der Fall ist, invalidiert das Document Registry das angegebene Dokument ansonsten leitet das Document Registry die Anfrage an das Document Registry der Affinity Domain weiter, in der das angegebene Dokument verwaltet wird. ... sendet eine Information zum Ausführungsstatus der Operation an den Nutzer zurück.
Fehler und Warnungen	Folgende Fehler müssen erkannt und rückgemeldet werden: Gemeinsame Fehlermeldungen und Warnungen

Änderung der EFAv2.0-Spzifikation (EFA XDS Document Registry: Binding)

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

EFA Document Registry XDS Binding

Within EFA the actors and transactions of the IHE XDS integration profile are mapped onto EFA Document Registry actors and operations as follows:

Role	EFA Document Registry Service	IHE XDS
Actor	EFA Client	Document Consumer
Actor	EFA Document Registry	XDS Document Registry
Actor	EFA Document Repository	XDS Document Repository
Transaction	registerData	Register Document Set ITI-42
Transaction	listPartitionContent	Registry Stored Query ITI-18
Transaction	invalidateData	Update Document Set ITI-57

Das nachfolgende Unterkapitel wird komplett neu eingefügt

EFA XDS Binding: invalidateData

While medical data is received and stored by the XDS Document Repository it is the responsibility of the Document Registry to register that data in a way that it can be queried through search and browse operations.

Such registration of a document to an ECR provider's registry service is bound to the IHE Register Document Set transaction (ITI-42). This EFA binding introduces minor extensions and restrictions on the respective XDS actor and transaction definitions in order to properly cover the EFA use cases and to align with the EFA security framework:

• Documents must be associated with folders in order to reflect that each ECR data element must be placed within a partition which in turn is part of a case record that carries the permissions for accessing data
• The requestor must be capable to register documents to the ECR provider that is targeted by this request. The ECR partition the provided document is associated with must be registered at this ECR provider.
• Additional error messages are defined that cover specific failure conditions of the EFA use cases
• The availability of data fields is aligned to EFA privacy requirements
• The application of security measures and the contents of the SOAP security header are specified normatively

Constraints on the Request Message

The RegisterDocument request message is issued by an ECR Document Repository actor for registering a medical document to an existing folder which is bound to an EFA instance. Each transmission carries metadata and associations for one or more documents. All referenced documents will be registered with the same folder within the same logical EFA.

The request message implements the IHE Register DocumentSet transaction (ITI-42) request message as profiled in [IHE ITI TF-2b] considering the following constraints:

• Each registered document SHALL be associated with a folder.
• The target folder SHALL be available in advance to this transaction. All documents SHALL be associated with the same folder (these restrictions ensure the proper implementation of the EFA Document Repository SFM which implies the existence of a partition and only allows for a single partitionID to be included with the request).
• The requestor (ECR Document Repository) SHOULD embrace the provided documents as a single IHE XDS submission set acc. to [IHE ITI TF-2a].
• The EFA provider SHOULD ignore this grouping and MUST ignore all associations between documents and submission sets.
• The XDS Document Registy MUST NOT process any metadata assigned to the submission set, it MUST solely rely on the document metadata.

Expected Actions

The EFA Document Registry Service provider MUST verify that the requesting service is trustworthy in a way that the registry service can rely on the access control decision that has already been performed by the document repository in advance to this request. The EFA Document Registry Service SHALL respond to an RegisterDocumentSet request message with the RegisterDocumentSet response message containing a success indicator.

Response Message (Full Success Scenario)

If the EFA Document Registry Service provider is able to decode the received message and to properly register all documents it responds with an ebXML Registry Response with its status set to "urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"

Response Message (Failure or Partial Failure Scenario)

If the EFA Document Registry Service provider is able to decode the received message but the registration of one or more documents failed, it responds with an ebXML Registry Response that contains a respective status indicator (see below).The response MUST contain a RegistryErrorList element that indicates the failure condition.

If none of the documents was processed succesfully, the response status MUST be set to “urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure”. If at least one document was processed successfully, the response status MUST be set to “urn:ihe:iti:2007:ResponseStatusType:PartialSuccess”. A failure location MUST be provided if the error does not apply to all documents. It MUST NOT be given if the error applies to all documents.

The severity of each registry error message MUST be set to ”urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error”. Multiple registry error messages MAY be included within a single <rs:RegistryErrorList> element. For a list of valid error codes and message see Table 4.1-11 of [IHE ITI TF-3].

Security Audit Considerations

See Security Considerations.

Änderung der EFAv2.0-Spzifikation (EFA XDS/XDR Bindings)

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

Bei Umsetzung des Change Request müssten auf dieser Seite noch Verwiese auf das neue XDS-Binding eingestellt werden.