In this case we are actually defining a new system that will leverage multiple XDS Actors/Transactions. The IHE use of Actor is context independent. So, although an XDS Registry actor from IHE may seem like the Actor that implements the core of the HIO; it just appears to look this way. The HIO is actually made up of many things. In the terms of HITSP, we are creating compositions out of Actors; but that might be ancient history.
- A System (EHR, PHR, etc) queries the HIO for all longitudinal documents on Patient X.
- The HIO looks in the registry and compiles a response with all the documents matching the query
- The HIO returns the response to the query back to the System that made the request.
- This Policy-Enforcing-Registry will be intercepting the query and
- doing some initial Access Control decisions. Very much like XACML is modeled with a PEP/PDP.
- Of the Access Control decisions that this Policy-Enforcing-Registry does, it needs to
- determine what the current state of consent is. It can do this by it-self becoming a Document Consumer actor, and formulating a very specific query for ‘consent’ documents on Patient X.
- Depending on the response and the information in metadata, and the information cached; it
- might need to also be a Document Consumer actor and pull the consent documents found from the Repository that it exists in, as defined by the metadata.
- Ultimately it will determine what the consent rules are, along with all the other various rules in the HIO (e.g. Role-Based-Access-Control, Break-Glass, Organizational-restrictions, etc).
- At this point the Policy-Enforcing-Registry simply knows if it should reject the original Query, or allow it to partially happen.
- If the patient has not given positive consent, then an audit log should be recorded; and the original query returned with a failure of some kind (Some HIO like to say that consent is missing, other HIOs like to act like the patient doesn’t exist).
- If the query should be allowed, the Policy-Enforcing-Registry will allow the original query to be executed; but intercept the response.
- It now needs to inspect the response to determine if there is specific concerns between the access control rules and the content.
- It might need to remove some or all of the returned metadata entries.
- It can then return the legitimate results to the original clinical system; possibly attaching constraints/obligations.
Key notes for understanding the Diagram
- Yellow circles show sequence of transactions.
- transactions 1 and 5 are broken into two parts simply to show time passing between the time the EHR sends their request and the time they get back their response to that query. This is all just one XDS transaction – “Registry Stored Query”. As far as the EHR is concerned it has just done a simple XDS transaction. It is totally unaware of all the processing happening inside the Policy-Enforcing-Registry.
- Transaction 2 and 4 are also just XDS transaction “Registry Stored Query”.
- Transaction 2, 3, and 4 are shown as double-head arrows because there is no need to show time passing between the request and the response. So for this diagram they are considered combined for simplicity.
- the Repository could exist inside or outside the Policy-Enforcing-Registry box.
Updated Noon March 19th
I left the yellow sequence numbers the same where the transaction didn't change. Clearly they no-longer represent the order of events. There are now two distinct flows:
- Based on a new policy being registered, or some other 'event' the 'Resolve Policy' service would use the #2 "Query (consents)", and #3 "Request Consent Documents"
- Pull the existing policies from the XACML Policy Repository using #6
- Resolve these new policies with the existing policies
- Push the updates back into the XACML Policy Repository using #6
- Query request for clinical content #1
- Access Control engine looks up existing policies from XACML Policy Repository using #7
- If access should be granted then the Query request for clinical content is reflected in #4
- The results is inspected relative to the existing policies
- The results appropriate is returned.