Rapport sur les résultats

tions est vivement recommandée, vu qu’une ITI-18 et une ITI-43 subséquente du Doc Consumer à l’ARR ne correspondraient pas aux profils IHE mentionnés. HL7 et IHE déclarent : 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. Ils en demandent la suppression. La Poste et IG eHealth consignent les déclarations suivantes à propos du ch. 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 ajoute en outre le point suivant : 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. En ce qui concerne le ch. 1.4.2.2, Integic relève que seul l’acteur Secure Application est mentionné. Ce sont surtout les communautés/fusions de Registry et de Repository qu’il faut clairement exécuter en tant que Secure Node, ou dont il faut compléter l’acteur. HL7 et IHE demandent que le passage « These actors […] ATNA Audit Repositories » au ch. 1.4.2.3 soit reformulé : „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”. Ils ajoutent à propos du ch. 1.4.2.4.1 qu’il n’y a pas besoin de prescrire comment réaliser un audit interne à la communauté. Ainsi, il est possible d’utiliser aussi IHE RESTful ATNA à cette fin. Pour ce qui est du ch. 1.4.2.5, ils demandent en outre la suppression du premier, du troisième et du quatrième des quatre points énumérés dans le texte.

1.4.3 : Integic signale que ITI-57 ne peut modifier que ConfidentialityCode, ce qui pose question pour la création de plusieurs versions. L’annulation d’un document enregistré dans le dossier électronique du patient et inscrit au Document Registry dans le contexte de l’illustration des cycles de vie de documents (voir ITI-41 RPLC) devrait être autorisée. IG eHealth et La Poste demandent la correction suivante au ch. 1.4.3.2 : instead of UUID this should read documentUniqueId. Ils ajoutent à propos du ch. 1.4.3.1.2 : „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 would be: - XCF, - Delayed Document Assembly. Improve the requirement for a more sustainable solution. Avoid to limit the freedom of the implementation and standardize the relevant aspect of the interfaces

1.4.4 : En ce qui concerne l’AuditMessage/ActiveParticipant, Integic recommande d’introduire non seulement l’UserID, mais aussi un nom lisible de la personne intervenant en tant que 1.1 mandatory