search

highmed / highmed-dsf

HiGHmed Data Sharing Framework funded by the German Federal Ministry of Education and Research (BMBF, grant ids: 01ZZ1802E and 01ZZ1802A)
Apache License 2.0
32 stars 20 forks source link

Rework Resource Authorization Read Access #179

Closed hhund closed 3 years ago

hhund commented 3 years ago

Currently we distinguish between REMOTE and LOCAL access to resources and we also have some special rules determining access by content, Extension or reference to ResearchStudy, Group, Practitioner and PractitionerRole. We should add a FHIR Extension to enable read access for a given Organization similar to the use of Binary.securityContext that could be added to all resource types. This Extension could replace all special rules leaving it to the creator of a resource to define read access.

The Extension could be filtered before serializing the resource to a remote user.

hhund commented 3 years ago

Resources like ActivityDefinition, CodeSystem, NamingSystem, StructureDefinition and ValueSet as well as Organization, Endpoint and Subscription would use the existing authorization-role codes (REMOTE and LOCAL). Resources like Binary, Bundle, Group, HealthcareService, Location, Patient, Practitioner, PractitionerRole, Provenance and ResearchStudy as well as the to be added resources Library, Measure and MeasureReport would use either the existing authorization-role (REMOTE or LOCAL) or LOCAL in combination with the new Extension.

The Extension would be similar in structure and content as highmed-extension-participating-medic. Name/URL could be http://highmed.org/fhir/StructureDefinition/extension-read-access

@wetret and @alexanderkiel any comments or suggestions for the name of the extension?

alexanderkiel commented 3 years ago

AFAIK, the approach with the extension is the best thing we can do. I read the Authorization/Access Control section again and as @hhund already said, the access control mechanisms of FHIR are very patient centric. On the other hand, the DSF centers around organizations. As resources are usually not linked with an organization, we need this extension.

hhund commented 3 years ago

With this change, we should also take a look at the CodeSystem http://highmed.org/fhir/CodeSystem/organization-type. It is currently hard-coded as an Enum at multiple locations and only TTPs and MeDICs are differentiated. We should either try to remove this CodeSystem or extend it short-term with for example ZARS and maybe other types. In the HiGHmed feasibility process we use the MeDIC type to select all organizations from the allow-list to contact. This won't be specific enough if we use a single DSF instance to run HiGHmed, MII and NUM-CODEX processes. Unfortunately Organization.partOf is defined as 0..1 only allowing for a single parent organization. Otherwise we could define HiGHmed, MII and NUM-Codex as parent Organizations and filter target Organizations with a consortium specific CodeSystem for Organization.type. A part-of-consortium extension might be necessary to solve the multiple parents problem.

alexanderkiel commented 3 years ago

@hhund If you think about consortium (use-case) specific organization types, would that mean that one site would have multiple organizations, one per consortium (use-case)?

hhund commented 3 years ago

I'm not sure if I understand your question. But I think we have to solve two problems: (1) Associate roles to organizations and (2) group organizations in consortia/projects.

(1) can be solved by using Organization.type and only specifying the existing HiGHmed organization-type CodeSystem/ValueSet as an "example" within the DSF Organization profile. Every consortium or project could than define its own organization-type CodeSystem/ValueSet with specific roles.

If the roles defined for (1) are specific enough we may not need to solve problem (2) explicitly, but if we want to, we could create a tree structure like this:

The consortium/project specific organisation-types would then also be used within the extension-process-authorization extension to defined the requester-organization-type and recipient-organization-type.

I'm not sure if validation of Organization resources could check Organization.type, but a simple equals match when creating a Task resource to see if your type is ok for the requested process, might be fine.

hhund commented 3 years ago

@patrick-werner just pointed me to the OrganizationAffiliation resource:

[...] The Organization.partOf is used to form a hierarchical relationships within an organization which eventually resolves to a single organization. Each child in the tree is a subdivision of the parent. The OrganizationAffiliation is used to describe the relationship between two distinct organizations. It does not require a hierarchical relationship. A resource instance is for a singular linkage between 2 organizations (it does not contain all members), to create multiple affiliations, create additional resources for the other relationship between other organizations. Each instance contains its own period, and optionally links to specific related services/locations that are available. These referenced locations/services should be associated with the participating organization, and are available to the primary organization. This resource should not be used when the affiliates are part of a single organization. [...]

(https://www.hl7.org/fhir/organizationaffiliation.html#bnr)

Adding another resource to the mix is not my first idea, but OrganizationAffiliation could be a good fit.

alexanderkiel commented 3 years ago

We actually use OrganizationAffiliation in GBA to model Membership in Biobank Network. But we have no direct experience with the resource, because we never came to a point to actually use it.

What I mean with my comment above is the following: Do we like to model each real-world organization only once or do we like to have an Organization resource for each project the real-world organization will participate in? Now with the OrganizationAffiliation, we have a resource to put information of a real-world organization, participating in a particular project, into. With this, Organization.type wouldn't be used anymore. Instead, OrganizationAffiliation.code could be used. In addition to that, with OrganizationAffiliation.active and OrganizationAffiliation.period, we have two additional properties, that can be used to control to which Organization we like to send messages.

Back to authorization. We could allow the read access for a tuple of OrganizationAffiliation.organziation (the consortium/project) and OrganizationAffiliation.code (the role). Doing so would remove the direct dependency to a particular Organization resource. With that, we could say: "Read access is allowed for all organizations with role DIC in the NUM-CODEX project.".

hhund commented 3 years ago

Back to authorization. We could allow the read access for a tuple of OrganizationAffiliation.organziation (the consortium/project) and OrganizationAffiliation.code (the role). Doing so would remove the direct dependency to a particular Organization resource. With that, we could say: "Read access is allowed for all organizations with role DIC in the NUM-CODEX project.".

Sounds good. I guess we should add this together with initially proposed extension, so read access could be defined in multiple ways.

  1. by REMOTE or LOCAL access using tags
  2. by organization identifier for that organization
  3. by organization identifier for "children" of that organization with a specific role

Every resource created would need at least one of these three and a combination would work as well.

hhund commented 3 years ago

I like that OrganizationAffiliation has a reference to Endpoint as well. This would allow us to specify use-case specific FHIR-Servers in case specific Task resources need to be routed to a server other than the organizations default one.

alexanderkiel commented 3 years ago

For the third case we would need a extension containing two extensions, one for the organization reference and one for the role coding?

hhund commented 3 years ago

extension containing two extensions

Yes, that's what I thought too.