Ergebnisbericht

Zusammenhang eine Wiki-Link¹⁶⁶ angegeben. Während die BINT zudem auf ein Dokument bezüglich RESTful-ATNA vom 07.08.2015¹⁶⁷ verweist, gibt die medshare ein Dokument mit Datum 27.05.2016¹⁶⁸ an. Die Post schreibt zudem folgendes: The underlying concept seems to be to expose ATNA logs to end users. This concept has been tried in Austria and it has later been changed to support a more human interpretable event log. Since this has already been proven to be a less than ideal solution this should be replaced with a two tiered approach of ATNA logs for legal purposes and some higher abstraction level of event logging for end users.

1.4.2: Die Integic weist darauf hin, dass Actor Document Consumer nicht abfragend in Richtung Audit Record Repository agiere, sondern nur schreibend im Sinne der Record Audit Event (ITI-20) Transaction. Ein Audit Record Repository sei keine XDS-b fähige Actor Komponente. Der Workflow in der beschriebenen Form sei nicht IHE-konform. Eine Präzisierung oder Auflösung dieser Ausführungen werde dringend empfohlen, da eine ITI-18 und eine folgende ITI-43 von Doc Consumer an ARR nicht den genannten IHE-Profilen entsprechen würden. Die HL7 und IHE schreiben folgendes: Registry Stored Query [ITI-18] transaction that uses the parameters described in chapter “1.4.3.1.1 Parameters for stored query FindDocuments” on page 10. Retrieve Document Set [ITI-43] transaction performed against an Audit Record Repository using a document UUID received by a previously executed by a Registry Stored Query mentioned before. Sie fordern die Streichung. Die Post und IG eHealth geben folgendes betreffend Ziffer 1.4.2 zu Protokoll:

- „Combine all Audit Trail Message entries of all Audit Trail Document entries into one single document of type ATNA Audit Trail Document Format (see chapter 1.4.4.2 on page 23)“. This will not scale. The number of audit messages is strictly increasing over time. At a minimum the sorting has to be "newestfirst" and the number of returned records should be capped to a reasonable small number. Otherwise the coordinating server, which is in charge of aggregating the result, has increasingly high and nondeterministic memory requirements. Ideally the service should support server-side pagination and server-side search.

- Translate the coded information into the language preferred by the user when provide it to the user through the UI or other results like reports. What is the purpose of this requirement? The average patient will hardly be able to interpret the contents of the ATNA audit log. In Austria the ATNA log is kept separate from a user compatible event log. The ATNA log is required for legal purposes. The event log is used to make events understandable.

Die IG eHealth fügt zudem folgenden Punkt an: The specifications in EPDV and its appendices seem to prohibit on demand documents as very specific document formats are defined and explicit storage seems to be required. Add the ATNA Document Type to the list of permitted types. Die Integic macht betreffend Ziffer 1.4.2.2 darauf aufmerksam, dass nur der Actor Secure Application angeführt sei. Vor allem Gemeinschaften bzw. Zusammenschlüssen Registry und Repository seien definitiv als Secure Node auszuführen bzw. der Actor sei hier zu ergänzen. Die HL7 und IHE wünschen folgende Umformulierung des Textteiles „These actors […] ATNA Audit Repositories“ von Ziffer 1.4.2.3: „If the parameter $XDSDocumentEntryTypeCode contains the value 60049 (Audit trail), the responding gateway must return an UUID for a subsequent retrieval of an On Demand Document returning the audit messages matched by the filter parameters in the query of the corresponding document UUID in the 1.4.4.1 ATNA Audit Message Format. See also chapter “1.4.3.1.1 Parameters for stored query FindDocuments” on page 10”. Des Weiteren schreiben sie bezüglich Ziffer 1.4.2.4.1, dass nicht verordnet werden müsse, wie die gemeinschaftsinterne Auditabfrage realisiert werde. So könne z.B. auch IHE RESTful ATNA eingesetzt werden. Für Ziffer 1.4.2.5 verlangen sie zudem die Streichung des ersten, des dritten und des vierten der 4 im Text aufgeführten Bullet Points.

1.4.3: Die Integic weist darauf hin, dass ITI-57 nur ConfidentialityCode ändern dürfe, was betreffend Versionierung Fragen hervorrufe. Eine Stornierung eines Dokuments im elektronischen Patientendossier, das im Zuge der Abbildung von Dokumentenlebenszyklen (siehe ITI-41 RPLC) in Document Registry verzeichnet ist müsse erlaubt sein. Die IG eHealth und die Post beantragen bezüglich Ziffer