Rapporto sui risultati

«It has been specified for the Document Registries to act as Policy Enforcing Service Providers in terms of a XACML PEP» quanto segue: Where has this been specified? How do we deal with the situation that someone, who knows all the identifiers relevant to a document can retrieve this document with the REG PEP intercepting this transaction? Example: A primary system that was authorized in the past, stored this information. It can access the document even after the authorization expired.

Essi ritengono inoltre che questo tipo di prescrizioni rende difficile l’attuazione di soluzioni proprie dei diversi fornitori. IG eHealth propone: Do not specify HOW something must be implemented. Specify the desired result instead.

2 Volume 1 – Integration Profiles

IG eHealth e Posta scrivono riguardo al numero 2.2 quanto segue:

- 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. Proposta: 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. Proposta: 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-NIP: This assumes that there will never be any cross-patient use cases. This appears to be not very future proof. Proposta: Do not require org text and org ID attributes for patients. Drop electronic patient dossier-NIP as resource attribute.

Per Integic la durata di validità di 10 minuti è troppo breve per la prassi e dovrebbe essere prolungata a 30 - 60 minuti. Riguardo al numero 2.3.2, Posta e IG eHealth segnalano: 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 e Posta osservano riguardo al numero 3.1.10: «urn:e-health-suisse:2015:error:not-holderof-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. Questo ha ripercussioni dirette sull’implementazione e la performance. Proposta: Drop the attribute. Esprimo inoltre il seguente parere sul numero 3.1.5: 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. Anche questo ha ripercussioni dirette sull’implementazione e la performance. Proposta: Add trigger event «RetrieveDocumentSetRequest». Integic segnale riguardo al numero 3.1.6.1 che «ADR due to XDS Register Document Set-b» dovrebbe essere il numero 3.1.6.2. IG eHealth e Posta osservano sul numero 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 evidenzia riguardo al numero