careplan Mode SERVER Description Transaction y System History y System Search Resource Type Profile Read V-Read Search Update Patch Create Delete CarePlan http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-careplan y y y y CommunicationRequest http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-communication-request y y y y y y Condition http://hl7.org/fhir/StructureDefinition/Condition y y y y Consent http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-consent y y y y y EpisodeOfCare http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-episodeofcare y y y y Goal http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-goal y y y y y OperationDefinition http://hl7.org/fhir/StructureDefinition/OperationDefinition y Provenance http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-provenance y y y ServiceRequest http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-servicerequest y y y
Search for resources which have the given tag
Activity details defined in specific resource
draft | active | suspended | completed | entered-in-error | cancelled | unknown
The operation modifies the care team assignment of the care plan and all of its sub plans.
Suggest care teams matching the conditions required by the care plan on either a regional or a municipality level. The suggested care teams has reason codes matching all the conditions addressed by the care plan and has a managing organization matching the input region code or municipality code. One of region code or municipality code must be input. If both region code and municipality code is input, then the municipality code is ignored. Return a bundle with matching care teams and their managing organizations.
Search the contents of the resource's data using a fulltext search
Return resources linked to by the given target
Only return resources which were last updated as specified by the given range
Search for resources which have the given profile
Search for resources which have the given security labels
Search the contents of the resource's narrative using a fulltext search
When request transitioned to being actionable
draft | active | suspended | cancelled | completed | entered-in-error | unknown
Resource for the actor (or group, by role)
Classification of the consent statement - for indexing/retrieval
Identifier for this record (external references)
draft | proposed | active | rejected | inactive | entered-in-error
Conditions/problems/diagnoses this episode of care is for
Business Identifier(s) relevant for this EpisodeOfCare
The organization that has assumed the specific responsibilities of this EpisodeOfCare
The patient who is the focus of this episode of care
The current status of the Episode of Care as provided (does not check the status history collection)
The list of practitioners that may be facilitating this episode of care for specific purposes.
Modify the care team assignment of the episode of care and all care plans that has the episode of care as context.
Checks that it is allowed to set an EpisodeOfCare as context. If the user requesting context is a patient, then the patient input parameter should be specified. If the user requesting context is a practitioner, then the careTeam input parameter should be specified. Throws an exception if it is not allowed to select the Episode Of Care context. ## Output For valid Episode of Care is returned references that cause the Episode of Care to be valid context. For a practitioner, two output parameters will be returned on success: - CareTeam: The Careteam that gave access - EpisodeOfCare/CarePlan: The EpisodeOfCare or CarePlan that referenced the CareTeam
Search the contents of the resource's data using a filter
Search for resources which have the given source value (Resource.meta.source)
E.g. Treatment, dietary, behavioral, etc.
proposed | accepted | planned | in-progress | on-target | ahead-of-target | behind-target | sustaining | achieved | on-hold | cancelled | entered-in-error | rejected
Target Reference(s) (usually version specific)
This operation returns an overview of patient activities within a time period and filtered by either EpisodeOfCare or Condition code(s). On success, the returned Bundle contains a Parameters structure detailing the count of measurements received and expected. This is done per ServiceRequest with status active for those part of a CarePlan with status active related to eligible EpisodeOfCare resources. Eligible EpisodeOfCare are those with status active that refer to the given Patient and are either given as EpisodeOfCare reference in input or are referencing a Condition with a condition code that matches at least one of the Condition codes possibly given as input. The measurement regime expressed in ServiceRequest.occurrence[x] is, when possible, resolved to time slot(s) corresponding to datetime/period where an action is supposed to take place, typically performed by the Patient. When the occurrenceTiming variant is used, resolved time slots overlapping with the input time periode are considered. For occurrenceTiming expression which are either adhoc or unresolved, the effective datetime/period of a measurement is considered when checked for overlap with input time period. ## Input The operation has three mandatory inputs, a Patient reference, a start date and an end date. Additionally the operation has three optional inputs: a list of reference(s) to EpisodeOfCare, a list of Codings for Condition and a list of Codings for tags. ### Patient reference Mandatory reference for the Patient which the procedure overview is computed for. ### Start and end datetimes Start and end datetime are both mandatory, and together specify the period of interest in the patient procedure overview. As stated above, for resolvable past and future time slots as well as adhoc and unresolved timings there must overlap with this period. ### EpisodeOfCare list The list of EpisodeOfCare references is optional. If EpisodeOfCare are provided, these will be used to further filter which active EpisodeOfCare, CarePlan and ServiceRequest are considered for the patient procedure overview. ### Condition Coding list The list of Coding for Condition is optional. If Condition Coding are provided, the EpisodeOfCare considered are those referring to a Condition matching at least one of the codes in the list. As above, the EpisodeOfCare (one or more) considered further determines which active EpisodeOfCare, CarePlan and ServiceRequest are considered. ### Tag Coding list The list of Coding for tags is optional. If tag Coding are provided, the EpisodeOfCare considered are those including a tag matching at least one of the codes in the list. As above, both the Condition (one or more) and EpisodeOfCare (one or more) considered further determines which active EpisodeOfCare, CarePlan and ServiceRequest are considered. ### Extra boolean This is an optional parameter that can be set to true if activities allowing 'Extra' submissions should be included in the response. ## Output For valid inputs, the server will compute and return a Bundle. The Bundle contains a Parameters resource with resolved measurement regimes and associated counts of measurement submitted and counts expected. Such counts are also included in the Parameters structure when the measurement regime is either adhoc or unresolved. In addition, the Bundle contains CarePlan and ServiceRequest referenced in the Parameters. The Bundle can contain an OperationOutcome describing any encountered warnings. ### Output Parameters The output contains rows (encoded in parameters) for each matching and active ServiceRequest with resolved timings overlapping with the requested period. Rows are represented as Parameters.parameter with names: item_1, item_2, etc. Columns are represented as Parameters.parameter.part with name and value ``` Example: 'resource': { 'resourceType': 'Parameters', 'parameter': [{ 'name': 'item_1', 'part': [{ 'name': 'CarePlan', 'valueReference': { 'reference': 'https://careplan.devtest.systematic-ehealth.com/fhir/CarePlan/164581' } }] }] } ``` ### Columns - CarePlan: Reference to the CarePlan that the ServiceRequest belongs to. - ServiceRequest: Reference to the ServiceRequest. - ServiceRequestVersionId: The version of the ServiceRequest (version specified at time of submit-measurement or the current version (for expected activities)). - Activity: Description of the planned activity. - ResolvedTimingStart: A planned start time for the activity in the requested period. - ResolvedTimingEnd: A planned end time for the activity in the requested period. May be identical to start if no duration is specified in the measurement regime. - TotalSubmitted: The number of measurements already submitted for this ServiceRequest and resolved timing. - SubmittedTimely: The number of measurements where the measurement time matches the resolved timing. - TimingType: * Resolved: a measurement regime that is supported by the infrastructure and where resolved timing and requested number of measurements can be calculated. * Unresolved: a measurement regime that is not supported by the infrastructure. Resolved Timing Start, end, submitted timely and Occurrences requested will be empty. * Adhoc: A ServiceRequest without a measurement regime or a measurement regime stating ad-hoc. - OccurencesRequested: Expected number of measurements.
This operation persists an EpisodeOfCare based on the transient value of an EpisodeOfCare provided in the input. ## Input The input is a Bundle which must contain exactly one EpisodeOfCare, conditions referenced in diagnosis list and at least one Provenance resource. All Provenances in the input must have the EpisodeOfCare as target. At least one Provenance must be interpreted into a 'Privacy-provenance' (see below). ### The EpisodeOfCare resource The EpisodeOfCare has to have `PLANNED` status The 'id' property of the EpisodeOfCare will be reassigned by the server, but can be referenced by other resources in the same bundle. The 'managingOrganization' property of the EpisodeOfCare references the GDPR Data Controller (Danish: 'Dataansvarlig'). ### The privacy-Provenance resource A privacy-Provenance is a Provenance resource characterized by having at least one entry in Provenance.policy which data are transported, stored, or processed in the system. Possible values are: - 'http://ehealth.sundhed.dk/policy/dk/sundhedsloven' - 'http://ehealth.sundhed.dk/policy/dk/serviceloven' ### Diagnosis referenced Condition resource For any diagnosis listed, the referenced Condition must be concerning the same Patient as the EpisodeOfCare. ## Output For valid inputs, the server will create, persist and return a new EpisodeOfCare, client-supplied provenances, conditions and origin-provenance carrying a server-assigned ids. To get resources bodies in the output the request header has to contain parameter ```Prefer: return=representation```. ### The origin-Provenance resource Whenever an EpisodeOfCare is created, the server automatically creates an 'origin' Provenance resource point to it (in addition to the client-supplied Privacy-Provenance). This Origin-Provenance resource is filled with data from the JWT access token in order to record the origin of the EpisodeOfCare resource. For instance agent.whoReference points to a resource which is created as a shadow identity from the JWT token.
This operation creates a careplan for a specific episodeOfCare using this PlanDefinition as a template.
Accept a FHIR Message Bundle for processing
Forces a single pass of the resource reindexing processor
Provides the number of resources currently stored on the server, broken down by resource type