| Table of Contents |
|---|
Overview
| Excerpt |
|---|
The |
...
responsibility |
...
model manages different levels |
...
of responsibility and privileges for a patient's episode of care and care plans. |
The Practitioner's CareTeams and the responsibility model control what operations the practitioner can perform on what level.
Managing the practitioner's CareTeams
The practitioner's CareTeams are registered and managed at the municipality and/or regional user management systems (IdP).
The eHealth infrastructure automatically updates a practitioner’s relation to CareTeams when the practitioner logs into the eHealth Infrastructure with information from the token received from the IdP.
Episode of Care responsibilities
The Episode of Careis in the eHealth infrastructure registered with three types of responsibilities:
ManagingOrganization - custodian of the patient's data
CareManagerOrganization - holds formal responsibility
...
for the patient's episode of care
CareTeam - the practitioners who perform actions at the episode of care level.
EpisodeOfCare.managingOrganization
This organization is the custodian of the patient's data on the eHealth infrastructure and is responsible for data control, as GDPR requires.
This top-level organization controls the patient's data, is used for reporting and billing, and does not change. The Managing Organization remains the same even if a patient relocates. If a patient moves to a different region or municipality, a new Episode of Care must be created
...
A Region
A Municipality
...
CareManagerOrganization:
This is the Organization that has the formal responsibility for the Patient's episode of care.
The formal responsibility should only be changed once accepted by the receiving CareManagerOrganization.
Examples include:
A Department in a Hospital. Typically, the ManagingOrganization is a descendent of the top-level ManagingOrganization (1).
A General Practitioner
...
based on their new address.
The Managing Organization is typically a Region or a Municipality.
Usage in the eHealth Infrastructure
The managing organisation is used in e.g. communication resources, when they are created in the eHealth Infrastructure. See https://ehealth-dk.atlassian.net/l/cp/SSX623xA
RBAC - Access Control
The managing organisation is controlled as part of role-based access control for reporting. See https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/1695842461/Access+Control+in+eHealth+Services#Reports
EpisodeOfCare.careManagerOrganization
This organization has formal responsibility for the patient's care. It can change but typically stays within the same managing organisation. See Responsibility with General Practitioner as caremanagerOrganization for an example.
The formal responsibility can only be changed when the receiving CareManagerOrganization accepts it.
Examples are:
A department in a hospital (usually a descendant of the ManagingOrganization)
or a General Practitioner.
EpisodeOfCare.Team
The team is the group of practitioners who perform actions at the episode of care level.
The team consists of practitioners with the authority to e.g. assign new CarePlans to the Patient's EpisodeOfCare.
The Team for an EpisodeOfCare can be changed with the right permissions. See Maintaining the set of CareTeam involved in the EpisodeOfCare for updating the careteam involved in EpisodeOfCare.
The responsibility history is stored when updated in EpisodeOfCare.teamHistory.
The practitioners have roles and are related to the patient's episode of care through a CareTeam. The roles can be "behandlingsansvarlig" or "bestillingsansvarlig"
Practitioners in the Team can work across different CarePlans.
...
Their actions involve:
...
assigning new
...
CarePlans to the
...
patient's episode of care,
closing or pausing
...
existing
...
CarePlans,
...
assigning new CareTeams to an active CarePlan.
RBAC
The EpisodeOfCare.team is used in the access control and has the following consequences for the security model. If the CareTeam Context matches the episodeOfCare.team then the following may be allowed:
Apply PlanDefinition (PlanDefinition$apply)
Create EpisodeOfCare (EpisodeOfCare.create-episode-of-care)
Update CarePlan and ServiceRequest
Read careteam for CarePlan and ServiceRequest
Suggest careteam and update careteam for CarePlan and ServiceRequest
Create, read and update ClinicalImpression
Create, read, update and search Goals
Read and search CarePlan
...
Read ServiceRequest
Read Observation, QuestionnaireResponse, and Media
Create and update QuestionnaireResponse (if QuestionnaireResponse.status is in-progress)
See https://ehealth-dk.atlassian.net/l/cp/sPfabiTK for details and the complete list.
CarePlan responsibilities
The CarePlan has only one type of responsibility:
CareTeam - the practitioners who perform actions at the care plan level.
CarePlan.CareTeam
...
The CareTeam
...
references
...
one or more
...
CareTeams with operational responsibility for the
...
Points of Interest in the example above
EpisodeOfCare.managingOrganization
This Organization is the top level Organization that holds the data controlling for the Patients Episode of Care. In the example above it is Region Midt.
In addition to data separation, this Organization patient's CarePlan.
The CarePlan careteam is responsible for monitoring the execution and progress of the patient's CarePlan.
The team shall include practitioners who adjust plans and approve results for publishing and can also involve practitioners with service and support roles.
CarePlans.CareTeams can change, and the history is recorded in CarePlan.ehealth-teamHistory.
Practitioners with privileges can change the CareTeam at the CarePlan level.
RBAC
The CarePlan.team is used in the access control and has the following consequences for the security model. If the CareTeam Context matches the CarePlan.team then the following may be allowed :
Read careteam for CarePlan and ServiceRequest
Search CarePlan
Suggest careteam and update careteam for CarePlan and ServiceRequest
Create, read, update and search ClinicalImpression
Create, read, update and search Goals
Read Observation, QuestionnaireResponse, and Media
Create and update QuestionnaireResponse (if QuestionnaireResponse.status is in-progress)
Sub plans
Sub plans are defined by referencing parent care plans through the CarePlan.partOf reference. Sub plans are regarded as their own individual care plans, and do not inherit any access or responsibility from the parent care plan. This means the rules and responsibilities stated above should also be consider for each individual sub plan.
Example
The following picture illustrates an example of the responsibility model.
Points of Interest:
EpisodeOfCare.managingOrganization: This top-level organization controls the patient's data, is used for reporting and billing, and
...
remains constant. For example, in the provided example, it's "Region Midt"
EpisodeOfCare.careManagerOrganization
...
: This organization has formal responsibility for the
...
patient's care
...
.
...
It can change
...
but typically stays within the same managing organisation. See Responsibility with General Practitioner as caremanagerOrganization for an example. In the example above the careManagerOrganization is “Lungemedicinsk Afdeling”.
EpisodeOfCare.team
...
: This administrative team
...
consists of practitioners with the
...
authority to assign new CarePlans to the Patient's EpisodeOfCare.
...
The Team can be changed with the right permissions
...
, and the responsibility history is
...
stored in
EpisodeOfCare.teamHistory. Examples are "Behandlingsansvarlig and Administrativt Personale”Careplan.careTeam
...
: This operational team
...
monitors the execution and progress of the
...
patient's CarePlan. It
...
also
...
includes clinical practitioners
...
who adjust plans and approve results for publishing.
...
Operational teams can also involve practitioners with service and support roles.
...
CareTeams on CarePlans can change
...
, and their history is
...
recorded in
CarePlan.ehealth-teamHistory. Examples are “Sundhedsfaglig and Sundhedsfaglig monitoreringsansvarlig”