|
| 1 | +### The authorization model |
| 2 | + |
| 3 | +<!-- The Shared Care Planning (SCP) authorization model is based on the authority of the Care Plan Service (CPS). This service maintains the Care Plan and is responsible for all the due diligence that is required to build up the required trust for all Care Plan Contributors (CPC) in the network. |
| 4 | +
|
| 5 | +### Scope of the care plan |
| 6 | +
|
| 7 | +#### Bound to the patient |
| 8 | +A Care Plan is bound to a patient, and no more than one patient. A Care Plan (CP) has one single Care Team (CT). Therefore, in CSP the terms Care Plan and Care Team are somewhat interchangeable. |
| 9 | +
|
| 10 | +#### Owned by the Plan Service (CPS) |
| 11 | +A Care Plan is created by the Care Plan Service as the owner of a CarePlan. As the care network of the Patient grows, more organization become part of the Care Team |
| 12 | +```asciidoc |
| 13 | + ┌───────┐ |
| 14 | + │Patient│ |
| 15 | + └───┬───┘ |
| 16 | + │ |
| 17 | + │ |
| 18 | + ┌───┴────┐ |
| 19 | + │CarePlan┼───────────┬────────┐ |
| 20 | + └───┬────┘ │ │ |
| 21 | + │CPS │CPC │CPC |
| 22 | + │ │ │ |
| 23 | +┌────────┴─────────┐ ┌────┴───┐ ┌──┴───┐ |
| 24 | +│General Practioner│ │Hospital│ │Physio│ |
| 25 | +└──────────────────┘ └────────┘ └──────┘ |
| 26 | +``` |
| 27 | +### A single context of care |
| 28 | +A Care Plan is bound to one single context, in the sense that, CSP assumes that all members of the CT are always allowed to access all relevant data. In the case they are not allowed to access all relevant data, they should not be part of the CT. This that case, a different CP should be created. If a patient is referred to another organization that should not have access to all relevant data of the patient, another (nested) CP should be created. |
| 29 | +
|
| 30 | +```AsciiDoc |
| 31 | + ┌───────┐ |
| 32 | +┌───────┼Patient│ |
| 33 | +│ └───┬───┘ |
| 34 | +│ │ |
| 35 | +│ │ |
| 36 | +│ ┌───┴────┐ |
| 37 | +│ │CarePlan┼───────────┬────────┐ |
| 38 | +│ └───┬────┘ │ │ |
| 39 | +│ │CPS │CPC │CPC |
| 40 | +│ │ │ │ |
| 41 | +│ ┌────────┴─────────┐ ┌────┴───┐ ┌──┴───┐ |
| 42 | +│ │General Practioner│ │Hospital│ │Physio│ |
| 43 | +│ └──────────────────┘ └────┬───┘ └──────┘ |
| 44 | +│ │ |
| 45 | +│ │CPS |
| 46 | +│ │ |
| 47 | +│ ┌───────┴───────┐ |
| 48 | +└────────────────────┼Nested CarePlan│ |
| 49 | + └───────┬───────┘ |
| 50 | + │ |
| 51 | + │CPC |
| 52 | + ┌──────┴──────┐ |
| 53 | + │Mental health│ |
| 54 | + │care provider│ |
| 55 | + └─────────────┘ |
| 56 | +``` |
| 57 | +
|
| 58 | +### Model of Patients' consent |
| 59 | +New members can only be added to the Care Team of the Care Plan by with explicit consent of the Patient. This responsibility lies with the Care Plan Service. The CPS must be able to contact the Patient and handle the proces of requesting consent. The same goes for Care Plan Contributors that enter a Care Team with existing data; those must verify with the Patient that the existing data is being shared within the context of the Care Plan and Care Team. |
| 60 | +
|
| 61 | +### Methods of Patients' consent |
| 62 | +The methods of consent must be either in physical interaction with the Patient (at the desk), by physical channels such as mail or with digital methods such as e-mail or SMS notifications to digital consent forms protected by contemporary authentication methods that are already in place. |
| 63 | +
|
| 64 | +#### (Lack of) cryptographic consent |
| 65 | +In the current authentication landscape of the Netherlands, cryptographic proof of end-user consent is not in sight on the short term. The solution we propose is based on a) consent of the user and b) the due-diligence of the CPS and the CPC in some cases. We choose not to put the emphasis on capturing proof of consent with cryptographic methods, knowing that such technology will eventually become part of the EU Digital Identity Wallet infrastructure signing function. |
| 66 | +
|
| 67 | +### Authentication of Organizations |
| 68 | +Organizations are authenticated by their X509 Certificate, that is used to sign a X509Credential. This ensures the identity of the health care organizations in Shared Care Planning. |
| 69 | +
|
| 70 | +
|
| 71 | +### CPS Responsibilities |
| 72 | +The Care Plan Service (SCP) has the role of maintaining the Care Plan and acts as gatekeeper for the Care Plan and Care Team for the Patient. The SCP may only add members to the Care Team with the explicit consent of the user. The CPS may keep track of the consent using the FHIR Consent resources, but is not required to do so. |
| 73 | +
|
| 74 | +### CPC Responsibilities |
| 75 | +The Care Plan Contributor (CPC) only needs to get consent of the Patient when it links pre-existing data of the Patient to the context of the CarePlan. In that case, the CPC must contact the Patient and is required to get consent for sharing the data. |
| 76 | +
|
| 77 | +### The CPS expansion and consent flow |
| 78 | +
|
| 79 | +The core flow of consent works a follows: |
| 80 | +* A Task is created for a new CPC and that CPC is notified about the Task. Both the CPS or CPC roles can do this. The CPC can either be the initiator of recipient of the Task. |
| 81 | +* The CPC either accepts or rejects the Task without knowing the patient. |
| 82 | +* The CPS is notified about the accepted Task. |
| 83 | +* The CPS contacts the Patient about the new CPC and gets consent on expanding the Care Team. |
| 84 | +* The CPS expands the Care Team and notifies the new CPC about the updated CareTeam. |
| 85 | +* The new CPC now can fetch the details of the Patient. |
| 86 | +* (optional) The CPC can determine the pre-existing data about the patient exists in the system and that this data will be shared within the context of the Care Team. In that case, consent of the patient must be acquired. |
| 87 | +
|
| 88 | +#### A more complicated example |
| 89 | +{::nomarkdown} |
| 90 | +{% include authorization.svg %} |
| 91 | +{:/} |
| 92 | +
|
| 93 | +The provided **sequence diagram** illustrates the process of adding three external systems (*OLVG*, *Geboortezorg*, and *Fysio*) to a patient's care team. The interactions are handled by the control system (*Huisarts*) and involve patient approval at various stages. |
| 94 | +
|
| 95 | +--- |
| 96 | +
|
| 97 | +## Key Components in the Diagram: |
| 98 | +
|
| 99 | +1. **Actors and Entities:** |
| 100 | + - **Patient:** The individual whose care team is being managed. |
| 101 | + - **Huisarts (CPS):** A CPS responsible for the care team management. |
| 102 | + - **OLVG (CPC):** An CPC being added to the care team. |
| 103 | + - **Geboortezorg (CPC):** Another CPC being added. |
| 104 | + - **Fysio (CPC):** A third CPC being added to the care team. |
| 105 | +
|
| 106 | +2. **Groups:** |
| 107 | +Each step in the process is organized into groups that represent the task of adding a organization to the care team (*OLVG*, *Geboortezorg*, and *Fysio*). |
| 108 | +
|
| 109 | +--- |
| 110 | +
|
| 111 | +## Process Steps: |
| 112 | +
|
| 113 | +### Step 1: Adding **"OLVG"** to the CareTeam |
| 114 | +- **Huisarts (CPS) initiates a task** with the *OLVG* system (**CPC**). |
| 115 | +- *OLVG* accepts the task and **notifies the Huisarts (CPS)**. |
| 116 | +- **The Huisarts (CPS) consults the patient** for approval by sending an consent request. |
| 117 | +- Upon patient consent: |
| 118 | + - **The Huisarts (CPS) updates the care team** to include *OLVG*. |
| 119 | + - **The Huisarts (CPS) notifies the OLVG system** of the update. |
| 120 | +- *OLVG* then **fetches the patient's details**. |
| 121 | +
|
| 122 | +--- |
| 123 | +
|
| 124 | +### Step 2: Adding **"Geboortezorg"** to the CareTeam |
| 125 | +- A new addition starts from *OLVG* (**CPC**), which triggers a task for *Geboortezorg* (**CPC**). |
| 126 | +- *Geboortezorg* accepts the task, notifies *OLVG*, and *OLVG* subsequently **notifies the Huisarts (CPS)**. |
| 127 | +- **The Huisarts (CPS) consults the patient** for their consent. |
| 128 | +- Upon patient consent: |
| 129 | + - **Huisarts (CPS) updates the care team** to include *Geboortezorg*. |
| 130 | + - Notifications are sent to both *OLVG* and *Geboortezorg*. |
| 131 | +- *Geboortezorg* **fetches the patient's details** at the Huisarts (CPS). |
| 132 | +- If the patient has **existing data**, an additional **consent is required** from the patient. Upon consent, the existing data is handled accordingly. |
| 133 | +
|
| 134 | +--- |
| 135 | +
|
| 136 | +### Step 3: The patient goes to the **Fysio** and names **OLVG** |
| 137 | +- *Fysio* (**CPC**) triggers a task for *OLVG* (**CPC**). |
| 138 | +- *OLVG* accepts the task, sets the `basedOn` value of the Task to the Care Plan of the CPS and **notifies the Huisarts (CPS)**. |
| 139 | +- **The Huisarts (CPS) consults the patient** for consent. |
| 140 | +- Upon patient consent: |
| 141 | + - **The Huisarts (CPS) updates the care team** to include *Fysio*. |
| 142 | + - The Huisarts (CPS) sends **notifications to all involved systems** (*OLVG*, *Geboortezorg*, and *Fysio*). |
| 143 | +- *Fysio* fetches **the patient's details** from the Huisarts (CPS). |
| 144 | +- Additionally: |
| 145 | + - *Fysio* requests **data from *OLVG***. |
| 146 | + - *OLVG* performs an **internal check (CareTeam)** and shares the required **data back to *Fysio***. |
| 147 | +
|
| 148 | +
|
| 149 | +### Main advantages of this approach |
| 150 | +#### Distributed |
| 151 | +As soon as an organization gets assigned a task that is part of SCP, the task refers to the Care Plan with the `basedOn` value. The Care Plan becomes discoverable and the roles in the SCP are implicitly determined by the ownership of the Care Plan. The CPS is the organization hosting the FHIR resource, all the other members are CPC in the Care Plan. |
| 152 | +
|
| 153 | +#### Specific |
| 154 | +Consent is acquired on adding an organization or existing data to a care plan, and not at forehand. --> |
0 commit comments