Rapport sur les résultats

document even after the authorization expired.

Ils sont par ailleurs d’avis que de telles consignes réduisent singulièrement les possibilités pour divers fournisseurs d’implémenter leurs propres solutions. IG eHealth demande : Do not specify HOW something must be implemented. Specify the desired result instead.

2 Volume 1 – Integration Profiles

IG eHealth et La Poste observent à propos du ch. 2.2 :

- Signature: An X.509 signature by a trusted entity (XUA Assertion Provider) to guaranty the confidentiality of the claims being made and unaltered content of the assertion.” A digital signature does not provide confidentiality. implying wrong expectation must be avoided. Demande : Remove “confidentiality of the claims being made and”.

- Subject: The custodian attribute has to be present in addition to the GLN/ electronic patient dossier-ID. Authorization decisions can only be made for GLN/ electronic patient dossier-IDs because those are the entities that are being authorized by patients. The custodian acts in the name of either one of those entities. In other words, the custodian has an existence dependency to a GLN or electronic patient dossier-ID. Demande : Be more specific about which attributes co-exist on a subject.

- Attribute Statement: organization & organization-id: Carrying organization text and ID attributes for patients makes little sense. Resource-id = electronic patient dossier-PID: This assumes that there will never be any cross-patient use cases. This appears to be not very future proof. Demande : Do not require org text and org ID attributes for patients. Drop electronic patient dossier-PID as resource attribute.

Integic estime que la durée de validité de 10 minutes est beaucoup trop courte pour un cabinet médical. Le délai d’attente doit être relevé à 30 à 60 minutes. La Poste et IG eHealth relèvent le point suivant concernant le ch. 2.3.2 : XACML 3.0 was published in Jan. 2013. is there a reason to use an outdated version? It should keep up with current standards.

3 Volume 2 – Transactions

IG eHealth et La Poste apportent la remarque suivante au sujet du ch. 3.1.10 : „urn:e-healthsuisse:2015:error:not-holder-of-patient-policies” is to be set as the result of an “Indeterminate” PDP response. But the PDP will also return this decision value if there was an error during rule evaluation. The two cannot be distinguished based on the XACML response unless one has control over the PDP’s workings. Which one normally does not have as it is part of a XACML library. Cela a des effets directs sur l’implémentation et les performances. Demande : Drop the attribute. Leur prise de position pour le ch. 3.1.5 est la suivante : The list should include document access via the repository. Repository access is mentioned towards the end of the document, but really should be mentioned as an event that requires authorization in its own right. Ce qui a aussi des effets directs sur l’implémentation et les performances. Demande : Add trigger event “RetrieveDocumentSetRequest”. Integic signale à propos du ch. 3.1.6.1 que « ADR due to XDS Register Document Set-b » devrait être le ch. 3.1.6.2. IG eHealth et La Poste font la remarque suivante au sujet du ch. 3.1.6.1 : The approach of “bulk querying the PDP” does not scale for large responses, neither in terms of memory usage nor runtime. This approach requires the PEP to un-marshal the complete registry response into memory, then determine the document subsets and place requests for the subsets. The response can only be forwarded after all PDP responses are received, lest the document order seen by the client is not guaranteed to be the same as generated by the registry. The PEP must be able to operate on the registry response stream in order to scale. The bulk request approach also does not scale if other document attributes become part of the access decision. The number of combinations to bulk-query for grows exponentially with the number of attributes and their values. The paragraph should be seen as an implementation example for small result sets. But as the size of the result is unknown, unless fully un-marshaled into memory, it is rather useless from an implementation perspective. Another example based on response stream filtering should be added. Medshare observe à propos du ch. 3.3 que le format d’échange technique pour la Policy échangée contre CH:PPQ n’est pas mentionné et doit être spécifié. Concernant le ch. 3.3.9, Integic propose que l’on remplace « ACMLPolicyQuery Response » par