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

Aus Hl7wiki
Wechseln zu: Navigation, Suche
K (→‎Änderung der EFAv2.0-Spezifikation (Kommunikationsmuster "Invalidieren eines Dokuments"))
(→‎Änderung der EFAv2.0-Spezifikation (Kommunikationsmuster "Invalidieren eines Dokuments"): Bild-Auflösung korrigiert)
 
(11 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 26: Zeile 26:
 
|Datum der Veröffentlichung im EFAv2.0 Wiki||09.04.15
 
|Datum der Veröffentlichung im EFAv2.0 Wiki||09.04.15
 
|-
 
|-
−
|Change Proposal Status||Eingereicht
+
|Change Proposal Status||Angenommen
 
|-
 
|-
 
|Abhängigkeit zum IHE Technical Framework<sup> </sup>||Nein
 
|Abhängigkeit zum IHE Technical Framework<sup> </sup>||Nein
Zeile 34: Zeile 34:
 
|Auswirkungen auf bestehende Implementierungen<sup> </sup>||'''Ja'''
 
|Auswirkungen auf bestehende Implementierungen<sup> </sup>||'''Ja'''
 
|-
 
|-
−
|Datum der letzten Aktualisierung des Change Proposal||09.04.15
+
|Datum der letzten Aktualisierung des Change Proposal||30.10.15
 
|-
 
|-
−
|Zugewiesener Bearbeiter||''Wird per Telefnkonferenz von der 7er-Gruppe festgelegt''
+
|Zugewiesener Bearbeiter||Jörg Caumanns
 
|-
 
|-
 
|}
 
|}
Zeile 65: Zeile 65:
 
'''Anwendungsszenario: Invalidieren von Daten in einer Fallakte'''
 
'''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. <ins>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.</ins><del>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).</del>  
+
In eine Fallakte eingestellte Daten (siehe Interaktionsmuster Einstellen von Datenobjekten) sind für alle EFA-Teilnehmer sichtbar und abrufbar. <ins>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.</ins>
 +
 
 +
<ins>Einwilligungsdokumente DÜRFEN NICHT invalidiert werden. EFA-Teilnehmer können Einwilligungsdokumente mit den Interaktionsmustern [[cdaefa:CIM_Anpassen_des_Teilnehmerkreises|Ändern der Einwilligung]] und [[cdaefa:CIM_Schließen_einer_Fallakte|Schließen der Fallakte]] administrieren.</ins><del>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).</del>
  
 
==Änderung der EFAv2.0-Spezifikation (Kommunikationsmuster "Invalidieren eines Dokuments")==
 
==Änderung der EFAv2.0-Spezifikation (Kommunikationsmuster "Invalidieren eines Dokuments")==
Zeile 75: Zeile 77:
 
<del>Das EFA-Teilnehmersystem invalidiert ein Datenobjekt, indem es das Datenobjekt mit dem Invalidierungsdokument [[cdaefa:EFA_Business_Informationsmodell#docRelationship|ersetzt]]. Es wird im IHE-D Cookbook  definiert werden.</del>
 
<del>Das EFA-Teilnehmersystem invalidiert ein Datenobjekt, indem es das Datenobjekt mit dem Invalidierungsdokument [[cdaefa:EFA_Business_Informationsmodell#docRelationship|ersetzt]]. Es wird im IHE-D Cookbook  definiert werden.</del>
  
−
'''''GRAFIK ANPASSEN UND P2P-WEITERLEITUNG BERÜCKSICHTIGEN'''
+
[[Datei:PIM_SEQ_Dokumente-invalidieren.png|417px]]
  
 
Dieses Muster ist abhängig von:
 
Dieses Muster ist abhängig von:
Zeile 88: Zeile 90:
 
# Das EFA-Document-Registry
 
# Das EFA-Document-Registry
 
## markiert das <del>ersetzte</del><ins>referenzierte</ins> Dokument als ungültig<ins>, sofern dieses in der lokalen Affinity Domain registriert ist</ins>
 
## markiert das <del>ersetzte</del><ins>referenzierte</ins> Dokument als ungültig<ins>, sofern dieses in der lokalen Affinity Domain registriert ist</ins>
−
## <ins>oder ruft die Operation ''invalidateData'' des Document Registry in der für das Dokument zuständigen Affinity Domain auf.</ins>
 
 
## <del>gibt dem EFA-Document-Repository eine Status-Meldung.</del>
 
## <del>gibt dem EFA-Document-Repository eine Status-Meldung.</del>
 
# Das EFA-Document-Repository gibt dem TNS eine Status-Meldung.
 
# Das EFA-Document-Repository gibt dem TNS eine Status-Meldung.
Zeile 100: Zeile 101:
 
}}
 
}}
  
−
 
+
== Änderung der EFAv2.0-Spzifikation (EFA Anwendungsdienste: Logische Spezifikation)==
 
{|class="wikitable" style="background-color:#FFE4C4;"
 
{|class="wikitable" style="background-color:#FFE4C4;"
 
|[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation) http://wiki.hl7.de/index.php?title=cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)]
 
|[http://wiki.hl7.de/index.php?title=cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation) http://wiki.hl7.de/index.php?title=cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)]
 
|}
 
|}
−
Für das Setzen des Status eines Dokuments auf ''invalidiert'' sollte eine entsprechende logische Spezifikation als Funktionalität des EFA Document Registry definiert werden. Es sollte festgelegt werden, dass die Invalidierung eines Dokuments nur durch die Organisation erfolgen kann, die das zu invalidierende Dokument in die EFA eingestellt hat. Die die Invalidierung durchführende Person ist dafür verantwortlich, zu prüfen, ob auch mit dem Dokument in Zusammenhang stehende Dokumente invalidiert werden sollen.
+
 
 +
''' EFA Anwendungsarchitektur: Service Functional Model '''
 +
 
 +
Die nachfolgende Tabelle listet zu den [[cdaefa:EFA_Kommunikationsmuster|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.
 +
 
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Kommunikationsmuster
 +
!Operation (logisch)
 +
!Umsetzender Dienst (logisch)
 +
|-
 +
|[[cdaefa:EFA_Kommunikationsmuster#Anlegen_einer_Fallakte|Anlegen einer Fallakte]]
 +
|createECR
 +
|EFA Ressource Manager
 +
|-
 +
|[[cdaefa:EFA_Kommunikationsmuster#Anlegen_einer_Partition_zu_einer_bestehenden_Fallakte|Anlegen einer Partition zu einer bestehenden Fallakte]]
 +
|createPartition
 +
|EFA Ressource Manager
 +
|-
 +
|[[cdaefa:EFA_Kommunikationsmuster#Schließen_einer_Fallakte|Schließen einer Fallakte]]
 +
|closeECR
 +
|EFA Ressource Manager
 +
|-
 +
|[[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Partitionen|Auflisten von Partitionen]]
 +
|listPartitions
 +
|EFA Ressource Manager
 +
|-
 +
|[[cdaefa:EFA_Kommunikationsmuster#Registrierung_einer_neuen_Einwilligung|Registrierung einer neuen Einwilligung]]
 +
|registerConsent
 +
|EFA Ressource Manager
 +
|-
 +
|[[cdaefa:EFA_Kommunikationsmuster#Verteilen_einer_Einwilligung_im_EFA-Verbund|Verteilen einer Einwilligung im EFA-Verbund]]
 +
|notifyOfConsent
 +
|EFA Ressource Manager
 +
|-
 +
|[[cdaefa:EFA_Kommunikationsmuster#Anfordern_eines_Berechtigungstoken|Anfordern eines Berechtigungstoken]]
 +
|issueAccessToken
 +
|EFA Ressource Manager
 +
|-
 +
| rowspan="3"| [[cdaefa:EFA_Kommunikationsmuster#Einl.C3.B6sen_eines_Berechtigungstoken|Einlösen eines Berechtigungstoken]]
 +
|redeemAccessToken
 +
|EFA Ressource Manager
 +
|-
 +
|listRecordLocations
 +
|EFA Ressource Manager
 +
|-
 +
|registerRecordLocation
 +
|EFA Ressource Manager
 +
|-
 +
| rowspan="2"| [[cdaefa:EFA_Kommunikationsmuster#Einstellen_von_Dokumenten|Einstellen von Dokumenten]]
 +
|provideData
 +
|EFA Document Repository
 +
|-
 +
|registerData
 +
|EFA Document Registry
 +
|-
 +
|[[cdaefa:EFA_Kommunikationsmuster#Auflisten_von_Dokumenten|Auflisten von Dokumenten]] (einer Partition)
 +
|listPartitionContent
 +
|EFA Document Registry
 +
|-
 +
|[[cdaefa:EFA_Kommunikationsmuster#Abrufen_von_Dokumenten|Abrufen von Dokumenten]]
 +
|retrieveData
 +
|EFA Document Repository
 +
|-
 +
|<ins>[[cdaefa:EFA_Kommunikationsmuster#Invalidieren_eines_Dokuments|Invalidieren eines Dokuments]]</ins>
 +
|<ins>invalidateData</ins>
 +
|<ins>EFA Document Registry</ins>
 +
|}
 +
 
 +
Das Zusammenspiel von Diensten und Operationen ist in der folgenden Darstellung noch einmal im Überblick dargestellt.
 +
 
 +
[[Datei:cdaefa_SFM_Operationen.png|639px]]
 +
 
 +
<hr>
 +
 
 +
''Der folgende Abschnitt wird neu eingefügt''
 +
 
 +
<ins>'''invalidateData'''</ins>
 +
 
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!Operation
 +
| colspan="2"|invalidateData
 +
|-
 +
!Funktionalität
 +
| colspan="2"|Invalidieren eines Dokuments in einer Fallakte.
 +
|-
 +
!Aufrufer
 +
| colspan="2"|
 +
*EFA-Teilnehmersystem der gleichen EFA-Provider-Domäne,
 +
|-
 +
! rowspan="2"|Eingabe
 +
|[[cdaefa:EFA_Security_Informationsmodell#context|context]]
 +
|Gibt den Sicherheitskontext vor, in dem die Operation ausgeführt wird. Bezugsquelle: EFA Kontext Manager [[cdaefa:EFA_Context_Manager_SFM#Operation:_OpenContext|''openContext'']].
 +
|-
 +
|[[cdaefa:EFA_Business_Informationsmodell#documentID|documentID]]
 +
|Eindeutige Identifizierung des zu invalidierenden Dokuments. Das zu invalidierende Dokument DARF NICHT vom Typ [[cdaefa:EFA_Business_Informationsmodell#consentInfo|consentInfo]] oder [[cdaefa:EFA_Business_Informationsmodell#consentDoc|consentDoc]] sein.
 +
|-
 +
! rowspan="1"|Rückgabe
 +
|statusInfo
 +
|Informationen zur Durchführung der Operation (z.B. aufgetretene Fehler oder für die weitere EFA-Nutzung potenziell relevante Warnungen)
 +
|-
 +
!Vorbedingungen
 +
| colspan="2"|
 +
|-
 +
!Ablauf
 +
| colspan="2"|
 +
Das Document Registry
 +
# ... ändert den Wert des Attributs ''[[cdaefa:EFA_Business_Informationsmodell#docMetadata|Status]]'' des Dokuments auf ''ungültig''.
 +
# ... sendet eine Information zum Ausführungsstatus der Operation an den Nutzer zurück.
 +
|-
 +
!Fehler und Warnungen
 +
| colspan="2"|
 +
Folgende Fehler müssen erkannt und rückgemeldet werden:
 +
* [[cdaefa:EFA Fehlermeldungen und Warnungen|Gemeinsame Fehlermeldungen und Warnungen]]
 +
|}
 +
 
 +
== Änderung der EFAv2.0-Spzifikation (EFA XDS Document Registry: Binding)==
  
 
{|class="wikitable" style="background-color:#FFE4C4;"
 
{|class="wikitable" style="background-color:#FFE4C4;"
 
|[http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_DocumentRegistry http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_DocumentRegistry]
 
|[http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_DocumentRegistry http://wiki.hl7.de/index.php?title=cdaefa:EFA_XDS_DocumentRegistry]
 
|}
 
|}
−
Auf dieser Seite sollte ein XDS-Bindings für das Invalidieren eines Dokuments mittels ITI-52 MetadataUpdate eingefügt werden.
+
 
 +
'''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:
 +
 
 +
{|class="wikitable" style="text-align: left; cellpadding: 10;"
 +
!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
 +
|[[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#registerData|registerData]]
 +
|Register Document Set ITI-42
 +
|-
 +
!Transaction
 +
|[[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#listPartitionContent|listPartitionContent]]
 +
|Registry Stored Query ITI-18
 +
|-
 +
!<ins>Transaction</ins>
 +
|<ins>[[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#invalidateData|invalidateData]]</ins>
 +
|<ins>Update Document Set ITI-57 </ins>
 +
|}
 +
 
 +
''Das nachfolgende Unterkapitel wird komplett neu eingefügt''
 +
 
 +
'''EFA XDS Binding: invalidateData'''
 +
 
 +
This binding realizes SFM operation ''[[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#invalidateData|invalidateData]]''.
 +
 
 +
This binding conforms to IHE-ITI ''Update Document Set [ITI-57]'' and constrains it.
 +
 
 +
''' Constraints on the Request Message '''
 +
 
 +
The request message SHALL conform to the metadata update operation ''Update DocumentEntry Status''.
 +
 
 +
The request message SHALL contain an [[cdaefa:EFA_Identity_Assertion_SAML2_Binding|EFA Identity Assertion]]. It relates to parameter ''context'' of [[cdaefa:EFA_Anwendungsdienste_(logische_Spezifikation)#invalidateData|SFM invalidateData]].
 +
 
 +
The SFM parameter ''documentID'' is bound to the target object of the document relationship indirectly. Note: SFM ''documentID'' relates to DocumentEntry.uniqueID. Therefore, prior to invalidateData, an EFA Document Administrator must:
 +
# query the document entry by uniqueID, and
 +
# use DocumentEntry.entryUUID as the reference to the target object.
 +
 
 +
The value of slot ''NewStatus'' shall be ''urn:oasis:names:tc:ebxml-regrep:StatusType:Deprecated''.
 +
 
 +
''' Expected Actions '''
 +
 
 +
Any metadata update operation other than ''Update DocumentEntry Status'' SHALL cause the entire transaction to fail, returning an [[cdaefa:EFA_Error_Codes_and_Warning_Codes|Registry Error]] of type ''4109: Policy Violation''.
 +
 
 +
The EFA Document Registry SHALL enforce the access control policy of the EFA to which the to-be-invalidated document belongs to prior to updating its metadata.
 +
 
 +
''' Response Message (Full Success Scenario) '''
 +
 
 +
No constraints.
 +
 
 +
''' Response Message (Failure or Partial Failure Scenario) '''
 +
 
 +
No constraints.
 +
 
 +
''' Security Audit Considerations '''
 +
 
 +
See [[cdaefa:EFA_XDS_SecurityConsiderations|Security Considerations]].
 +
 
 +
== Änderung der EFAv2.0-Spzifikation (EFA XDS/XDR Bindings)==
  
 
{|class="wikitable" style="background-color:#FFE4C4;"
 
{|class="wikitable" style="background-color:#FFE4C4;"

Aktuelle Version vom 16. Februar 2016, 16:01 Uhr

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.

Einwilligungsdokumente DÜRFEN NICHT invalidiert werden. EFA-Teilnehmer können Einwilligungsdokumente mit den Interaktionsmustern Ändern der Einwilligung und Schließen der Fallakte administrieren.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.

PIM SEQ Dokumente-invalidieren.png

Dieses Muster ist abhängig von:

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.


Information icon.svg Invalidieren eines Dokuments bei einem benachbarten EFA-Provider

Das Dokument, Invalidierungsdokument und Dokument-Beziehung müssen beim selben EFA-Provider registriert sein. Der Grund ist, dass andernfalls die Invalidierung unerkannt bleibt, wenn der jeweilige benachbarte EFA-Provider zum Anfrage-Zeitpunkt nicht verfügbar ist.

Das Invalidieren eines Dokuments bei einem benachbarten EFA-Provider kann technisch realisiert werden. Es muss zumindest ein organisatorischer Prozess aufgesetzt werden.

Ä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.

Cdaefa SFM Operationen.png

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,
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. Das zu invalidierende Dokument DARF NICHT vom Typ consentInfo oder consentDoc sein.
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

  1. ... ändert den Wert des Attributs Status des Dokuments auf ungültig.
  2. ... 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:

Ä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

This binding realizes SFM operation invalidateData.

This binding conforms to IHE-ITI Update Document Set [ITI-57] and constrains it.

Constraints on the Request Message

The request message SHALL conform to the metadata update operation Update DocumentEntry Status.

The request message SHALL contain an EFA Identity Assertion. It relates to parameter context of SFM invalidateData.

The SFM parameter documentID is bound to the target object of the document relationship indirectly. Note: SFM documentID relates to DocumentEntry.uniqueID. Therefore, prior to invalidateData, an EFA Document Administrator must:

  1. query the document entry by uniqueID, and
  2. use DocumentEntry.entryUUID as the reference to the target object.

The value of slot NewStatus shall be urn:oasis:names:tc:ebxml-regrep:StatusType:Deprecated.

Expected Actions

Any metadata update operation other than Update DocumentEntry Status SHALL cause the entire transaction to fail, returning an Registry Error of type 4109: Policy Violation.

The EFA Document Registry SHALL enforce the access control policy of the EFA to which the to-be-invalidated document belongs to prior to updating its metadata.

Response Message (Full Success Scenario)

No constraints.

Response Message (Failure or Partial Failure Scenario)

No constraints.

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.

Abgerufen von „https://wiki.hl7.de/index.php?title=cdaefa:CP-004-00&oldid=28805“