FHIR Connectathon 4 Tags

Introduction

This page documents that common tags defined for the purposes of the 4th connectathon. Depending on the outcome of testing these tags, the functionality represented by the tags will be moved into the full specification, while others will remain implementation things that are defined for each connectathon. Any that are migrated into the full specification will be renamed (i.e. get a new URI).

Important Note

These tags are defined only for the purpose of the connectathon. They solve some practical problems relating to security testing at the connectathon, and are intended to stimulate useful discussion about how tags work and which ones should be defined in the specification. There is not expectation that these tags represent the way real applications would work, or that they will automatically make their way into the specification, or that test applications at the connectathon should work this way.

Purpose

Tags are used for the following functionality in connectathon 4:

• Grant users access to patient compartments
• Manage resources in compartments
• Restrict resource accessibility (read & write)
• Review list

Security Assumptions

For the purposes of the connectathon, we define that there are 5 levels of user on the FHIR API:

• patient
• patient's family/designated agent
• healthcare provider
• privileged healthcare provider
• administrator

We assume that the patient and their family are limited to one or more patient compartments based on their identity and pre-defined access rules. We assume that the healthcare provider is unrestricted in regards to record access, but may be limited in terms of their ability to add some tags and/or access some security resources. A privileged healthcare provider may be a staff provider, or a STD care provider - the exact use of this is up to the implementer.

Note that systems are not required to implement security at all, or only parts of this scheme, but should aim towards relating anything they do implement to this simple scheme.

Tag Documentation

Patient Compartment

The following tag grants access to the patient compartment for a user:

 http://fhir.org/connectathon4/patient-compartment-user/[x]

where [x] is the login that the user uses to authenticate to the system. The mode of authentication is irrelevant.

This tag is used on the relevant patient resource

Manage resources in compartments

The following tags explicitly override the assignment of the patient compartment based on the contents of the resource:

 http://fhir.org/connectathon4/patient-compartment/[x]
 http://fhir.org/connectathon4/patient-compartment-not/[x]

where [x] is the identity of the patient compartment. Using the first tag adds the resource to the specified patient compartment in addition to any determined based on it's content, and using the second excludes the resource from a given compartment. The exclusion tag overrides the inclusion tag if both are provided (not that this makes any sense)

These tags can be used on any resource type that has a criteria for inclusion in the patient compartment.

Restrict resource accessibility

These tags function as crude managers of resource availability. The following tags are used:

 http://fhir.org/connectathon4/confidentiality/restricted
 http://fhir.org/connectathon4/confidentiality/secret

These can be used on any resource. If they are used on a patient resource, they also automatically restrict access to the patient compartment too.

• restricted: the resource is only available to the patient themselves, or a privileged provider
• secret: the resource is only available to the patient, or specifically authorised providers. Note that there's no arrangement for this authorisation to occur across the FHIR interface (at this time)

A resource that is not available cannot be seen, or updated. Attempts to create/update/delete the resources are met with access denied.

Review list

This tag marks that a resource has been added to a review list:

 http://fhir.org/connectathon4/review/[x]

Where [x] is the name of the review list. The lists are shared between users.

This can be used on any resource.