I agree. When I’ve been thinking of authorities in the PR I think we have have these at multiple levels of granularity depending on implementation needs. It also gives us a maturity model as we more from simple authorities to more complex/granular authorities as time goes on.
···
On Thu, Oct 17, 2013 at 1:40 PM, Hannes Venter hannes@jembi.org wrote:
Derek, I do think that it would be beneficial to try and look at finer-granularity at the HIE level, specifically when it comes to the SHR.
I’m sure we’ll run into use-cases where we need to be able to say “entity A should only be allowed access to documents of type X”.
It seems to me that various IHE profiles are very well catered towards the handling confidentiality/privacy-consent at a document-level, and I think it’d be good to try and make use of this.
(XDS for example specifies that a confidentialityCode field needs to be specified in the document metadata).
Finer granularity would fit in with the model outlined in the slides I think: I can imagine a scenario where we allocate confidentiality/permission codes at a provider level
and have the IL enforce it for queried documents from the SHR (rather than at the transaction level).
Not to imply that this would be an alternative to transaction level restrictions, generally speaking, but in addition to it.
Just a $0.01 to add to the discussion 
Cheers
Hannes
–
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org
On 17 October 2013 09:54, Ryan Crichton ryan@jembi.org wrote:
Thanks Derek, that slideshow is a great resource. What you have portrayed there is also my understanding of what we have been iterating towards.
I’ve added your slideshow to the wiki page on the design of the interoperability layer: https://wiki.ohie.org/display/SUB/OpenHIE+Interoperability+Layer+design+document. I will continue to update this page as these discussions continue.
Cheers,
Ryan
–
You received this message because you are subscribed to the Google Groups “OpenHIE Architecture” group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Software Developer, Jembi Health Systems | SOUTH AFRICA
–
Hannes VenterMobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org
On Thu, Oct 17, 2013 at 5:01 AM, Derek Ritz derek.ritz@gmail.com wrote:
I hope that this short PPT (attached) will help describe the preferred authentication and authorization pattern (#2, below). Re: the concerns about authority – it is entirely untenable to try to establish a definitive circle of care in each clinical instance and use the PR to enforce transaction processing authority to this level of granularity. In practice, authority will be much more generically defined than this and enforcements will be much coarser. As an example, think of a PRE (IHE prescription) transaction which is submitted to the Interoperability Layer (IL) by a Point of Service (PoS) application. The germane attribute for authority for this transaction might simply be the provider “type”. In the case of a PRE transaction, the IL might process all inbound transactions where provider type in [“physician”, “nurse practitioner”] and throw an exception otherwise. (I know this isn’t proper WHO-conformant type coding, but you get the idea). 
As another point, the “identity” of a nurse doesn’t change when his or her role changes. Role-based access control (RBAC) at the PoS application level could possibly vary depending on the data entry screen or time of day, etc. At the level of the HIE, however, RBAC is more likely to vary by provider type or by transaction type or perhaps by facility, etc.; at this level, these are the things we know. At some future time, we may also use patient consent directives to drive RBAC logic (altho I would heartily recommend we go for a simple opt-in/opt-out flag at the client registry when we eventually decide to support client consent directive management).
This is not an easy topic. I hope this PPT helps.
Derek.
On Wednesday, October 16, 2013 3:36:05 PM UTC-4, r.fri...@mindspring.com wrote:
My understanding from our call was that: (1) within the data center, a registry’s maintenance application would handle authorization for human users and there would be no authentication; (2) all service users would be authenticated through the IL, and each service request would be made on behalf of an identified user whose identity would be trusted and whose privileges would be maintained by the PR; (3) outside the data center, human users would be authenticated through the IL and their messages would be passed through to the appropriate registry’s maintenance application.
We should encourage all registry products to use a SOA even for their maintenance application so that (3) could eventually be eliminated and (1) could be reduced to address only deep sysadmin functions.
I am still concerned that this is not flexible enough to accommodate role assignments within the facility. For example, the identity of the emergency room triage nurse could change depending on personnel availability (and possibly day/time). Suppose one authority for the emergency room triage nurse is to access a patient’s records at another facility without patient consent. A nurse might be brought in from another facility to cover for a missing triage nurse, and we don’t want to have to do a personnel reassignment before she starts. Or the Head of Nursing might cover and we don’t want her to perform her normal functions (which might include approving unconsented record requests) while she is acting as triage nurse.
–
You received this message because you are subscribed to the Google Groups “Provider Registry” group.
To unsubscribe from this group and stop receiving emails from it, send an email to provider-registry+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
–
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org