access control for openEHR 'resources'

[damoca (David Moner)]

None that I’m aware of. Videos 2 to 5 were the presentations, that might be the most interesting (just 1h 15m ). The rest of the time were discussions.

[joostholslag]

@thomas.beale

Is there anything wrong with querying a lab panel and extracting just the serum K and not the other analytes?

No, there isn’t. But there is something wrong with an access policy that lets you query lab result analyte value, but not lab result point of care test.

@ian.mcnicoll

It is generally good advice that a query should at least take account of te ENTRY context, but that is different from saying that the SELECT should only return ENTRY-level data. I don’t think that is what is being argued but it might be mis-understood.

Sorry if I expressed myself badly. I indeed argue for the first, not the second.

[joostholslag]

@ian.mcnicoll

That is an example of where at some level, this might seem respectful of a patient’s privacy need but my feeling now is that trying to meet this level of expectation (rarely required or wanted by the majority) is just going to tie us in knots. Better to work at composition level in the main, with occasional exceptions.

This is already having a bit of design impact on the way we put together template compositions trying to keep the scope of the content fairly tight. e.g .do not mix housing information with safeguarding information, even through both are ‘social circumstances’. Better to use 2 different templates/compositions.

Yes, I’m trying to argue for limiting acces control scope at the composition level and the entry level (depending on context like read/write, AQL/GET composition, others?). Which is different from the current smart on openEHR spec, which supports authorising specific AQLs.
I also recognise there are niche use cases where more granular acces control is implemented. But I’d like to update the spec (both the smart and the entry and the ehr access) to make general recommendations.
(Currently I’m only in the orientation phase, I may sound convinced of a position, but this is mostly to challenge to show me where I’m wrong. Already I’m confined there should be exceptions allowed).

And also yes, I think we should take these access control principles into account when designing archetypes and templates.

I’ve found in designing templates for a (problem-goal-action) care plan this adds some complexity initially. Because it forces you to split it at a composition (instance) per problem (and tying those together using an indexing compositon with DV_EHR_URIs). But in the longer term I’m convinced it adds many benefits, other than just access control.

[ian.mcnicoll]

@joostholslag

Sorry if I expressed myself badly. I indeed argue for the first, not the second.

It is actually the specs that are potentially a bit misleading here, not you!!

@joostholslag

Yes, I’m trying to argue for limiting acces control scope at the composition level and the entry level (depending on context like read/write, AQL/GET composition, others?). Which is different from the current smart on openEHR spec, which supports authorising specific AQLs.

I think there is room for all of these, including AQL authorisation, but I agree life is a hack of a lot easier if we can largely use compositions as the basis for access control, especially for create/update/delete.

[pablo (Pablo Pazos)]

@joostholslag

Yes, I’m trying to argue for limiting acces control scope at the composition level and the entry level (depending on context like read/write, AQL/GET composition, others?). Which is different from the current smart on openEHR spec, which supports authorising specific AQLs.

I also think access control / permission checking should be limited by component (we need to define what a component is), and consider the whole architecture to provide a full solution, while defining the scope for the openEHR specs (we might not be able to define a full access control architecture).

When I say components, an example could be:

• end user application
• middleware (stuff in the middle of the end user app and the openEHR API implementation)
• openEHR API
  • normal GET methods
  • query
  • POST/PUT/DELETE methods
• repository / backend / archive (stuff behind the API)

Then we can say, at the end user application we should be able to say “this user, role or group doesn’t have access to this patient or EHR” or “has access” or “has access under certain conditions”, or “has access to partial information, like compositions of certain types or with certain setting code”, or “has access to information defined by certain archetype (compo, entry, cluster, element)”.

We know the application could just do all the filtering since it knows the user, it’s role/group, etc. but should also know openEHR. That will leave all the scope for RBAC outside openEHR. Even if the checks and filters are done in the middleware. Then we can put some of the checks at the API level, there the API needs to know more about the user/role/group and might be able to keep the openEHR functionality and the RBAC checks quite separated, but we need to add those checks to the spec somewhere. Lastly if the RBAC is at the CDR / backend, we might need a full RM for that, how that is constrained by ADL, and how permission are checked, so those are also fully modeled and managed by openEHR.

My personal preference would be to avoid the backend level and try to not depend on access permissions at the CDR / backend. Another personal preference would be to make the RBAC totally independent from the RM, and have a strict spec we can replicate in different implementations, even if we actually use different systems for implementing those checks. Though I’m not sure how much of openEHR the permission checking will need to implement the rules I mentioned above.

Anyway, I would like to analyze requirements and start documenting something concrete that can serve for further discussion and definition. Maybe the SMART thing is enough and I might be over complicating things, or maybe not, hehe