Rapporto sui risultati

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: Integic segnala che l’Actor Document Consumer non agisce come query in direzione dell’Audit Record Repository, ma solo come scrittura nel senso di Record Audit Event (ITI-20) Transaction. Un Audit Record Repository non è un componente attore capace di supportare XDS-b. Il workflow nella forma descritta non è conforme a IHE. Si raccomanda una precisazione o uno stralcio poiché un ITI-18 e un successivo ITI-43 da Doc Consumer a ARR non corrisponderebbe ai profili IHE menzionati. HL7 e IHE scrivono: 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. Chiedono lo stralcio. Posta e IG eHealth dichiarano quanto segue in riferimento al numero 1.4.2:

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

IG eHealth aggiunge su questo punto: 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. Integic fa notare riguardo al numero 1.4.2.2 che è indicata solo l’Actor Secure Application. Soprattutto le comunità e i raggruppamenti di registry e repository devono essere indicati come Secure Node e si dovrebbe aggiungere qui l’attore. HL7 e IHE desiderano la seguente riformulazione del brano di frase «These actors […] ATNA Audit Repositories» al numero 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». Riguardo al numero 1.4.2.4.1, rilevano che non si debba prescrivere come effettuare la richiesta di audit interna alla comunità. Si potrebbe p. es. utilizzare anche IHE RESTful ATNA. Al numero 1.4.2.5 chiedono inoltre lo stralcio del primo, del terzo e del quarto trattino dei quattro riportati nel testo.

1.4.3: Integic rileva che ITI-57 può modificare solo il ConfidentialityCode, sollevando quindi perplessità sul versionamento. Si dovrebbe consentire la soppressione di un documento nella cartella informatizzata del paziente, visto che secondo la rappresentazione dei cicli di vita dei documenti (vedi ITI-41 RPLC) è contenuto nel Document Registry. IG eHealth e Posta chiedono quanto segue per il numero 1.4.3.2: instead of UUID this should read documentUniqueId. Riguardo al numero 1.4.3.1.2 aggiungono: «Cache all audit messages», this paragraph implies several drawbacks:

- Caching implies that an updated version of the document is not available for another 8 hours. If a user notices that after a log view, subsequent actions (even his own) are no longer presented, he may think that logging is flawed.

- To force a particular implementation makes no sense. It is preferable to specify what the response must contain and maybe allow the option to cache this information for up to 8 hours. The implementation details should be left to the platform.

The method chosen (On demand document) to implement this feature can be discussed. Alternatives