Karolinska/Stockholm procurement of Digital health platform (CDR, tools, services, consultants)

joostholslag · 26 April 2024 05:50

Hi Erik, I’m also working on access control for openEHR. Would be great to discuss maybe in a seperate topic?

Design an acces policy language for openEHR ‘resources’ based on nuts verifiable credentials

opened 01:15PM - 23 Apr 24 UTC

Authorization

In order to be flexible in creating many use cases where nuts facilitates trust …in sharing openEHR formatted data, it is useful to define a language to describe access policies for openEHR formatted data based on verifiable credentials (VC). A specific policy could be: all doctors (proven by BIG number VC) have acces to any COMPOSITION.ACP for any patient. The generic (non-openEHR specific) requirement is described by @woutslakhorst in the April 2024 community Meetup. https://www.youtube.com/watch?v=TXS0I7D2GeM This language must be human readable and should be computer interpretable. Computer executable is a nice to have. The policies must be implementable by different openEHR platform vendors in a way that systems from different vendors will work together based on a shared understanding of the policies. One of the key requirements is the language should concisely identify an openEHR ‘resource’ scope. Similar to how HL7 FHIR describes it in smart app launch: https://www.hl7.org/fhir/smart-app-launch/2021May/scopes-and-launch-context.html#clinical-scope-syntax Possible openEHR resource scopes (compartiment X resource expression X permission) are listed here: https://specifications.openehr.org/releases/ITS-REST/latest/smart_app_launch.html#_scopes_for_openehr_rest_api E.g. ‘patient/template-<templateId>.r’ : Permission to read a template with <templateId> The other key requirements is a definition of a VC that gives the access to the resource. E.g. “doctor”, “employee relationship with care organisation” “organisational membership of a network”, “ura” “uzi” etc. In a PDP the following needs to happen: - The "Trust" package from NUTS - The "data" from the resources - Some kind of "shared business logic" to translate the "Trust" info into a decision based on the above. There are multiple attribute types of trust: - The organization: - Membership credential - Role - permission database / dataset / rulebase - The person - Identity (UZI) - Global role (BIG) - Role in organization (URA - rolcode) - The Shared Care Planning information. This implies the following checks on the PDP - The organization is a valid member - This the person identified with the right attributes - Relational checks: 1. Relation: Professional > Organization: The the access profile matches the role of the person _in the organization_ 2. Relation: Patient > Professional > Organization: The Shared Care Planning (Patient > CarePlan >* CareTeam > Member > Professional(Role,Org)) relationship role matches the access_profile. Which might materialize to (Patient > Professional(Role,Org)) The question is if the relational check is done before the call is make, checked by the requester, and materialized as proof or that the check should be done by the PDP? Rego, the language used by Open Policy Agent is a language to describe (AB) access control policy, but it’s generic and it doesn’t natively support identification of openEHR resource scopes nor nuts VCs. Also the language is quite low level (‘if’ statements) so it’s human (other than developers) readability is limited. (Do we need this?). it is interpretable and executable only by (open source) OPA software. The only known (to this project) alternative is XACML. But apparently it’s dead. And it’s not really human readable. So the rules it out as a candidate.

edit: new topic access control for openEHR 'resources'