{ "resourceType" : "CapabilityStatement", "id" : "kiola-care-plan-retrieval", "text" : { "status" : "extensions", "div" : "

KIOLA Care Plan Retrieval

Note to Implementers: FHIR Capabilities

Any FHIR capability may be 'allowed' by the system unless explicitly marked as "SHALL NOT". A few items are marked as MAY in the Implementation Guide to highlight their potential relevance to the use case.

FHIR RESTful Capabilities

Mode: server

The retrieval is done in 4 steps:

\n
    \n
  1. A search with the following parameters is sent to the server, eventually including a filter for the patient, if the user has access to more than one patient:\n
      \n
    • status: active
      • \n
    • category: https://fhir.ehealth-systems.at/kiola/careplan/category#kiola-care-plan
      • \n
    • e.g. subject__identifier: [KIOLA_SUBJECT_UUID], if required
      • \n
    \n
    2. \n
  2. Either a single care plan is returned in the result list, or an empty list, if the patient currently does not have an active care plan.
    3. \n
  3. The retrieval is confirmed, by adding the meta tag https://fhir.ehealth-systems.at/kiola/careplan/transient-tag#CONFIRMED to the care plan using the $meta-add operation on the returned care plan instance. The timestamp and userAgent parameters might be appended to the code, to indicate the client and time of retrieval, e.g. {userAgent=Pixel 4a/13 at.ac.ait.dm2/4.12.0(664):36fde7dd,timestamp=2022-11-25T09:28:29.950008}.
    4. \n
  4. The server returns the result of the operation.
    5. \n
\n

Optionally, the returned ETag might be saved in step 2 and sent along in a successive retrieval in step 1 in the If-Modified HTTP header. If the current care plan has not been changed, a 302 HTTP code (not modified) should be returned.

\n

Sequence Diagram:

\n

\"null\"/

\n
Summary of System-wide Interactions

Capabilities by Resource/Profile

Summary

The summary table lists the resources that are part of this configuration, and for each resource it lists:

Resource TypeProfileRSUCSearches_include_revincludeOperations
CarePlanhttps://fhir.ehealth-systems.at/artifacts/StructureDefinition/kiola-care-planyy

Resource Conformance: supportedCarePlan

Base System Profile
https://fhir.ehealth-systems.at/artifacts/StructureDefinition/kiola-care-plan
Profile Conformance
SHALL
Reference Policy

Interaction summary
  • Supports read, search-type.

Extended Operations
ConformanceOperationDocumentation
SHALL$$meta-add
" }, "url" : "https://fhir.ehealth-systems.at/artifacts/CapabilityStatement/kiola-care-plan-retrieval", "version" : "0.1.0", "name" : "KIOLACarePlanRetrieval", "title" : "KIOLA Care Plan Retrieval", "status" : "draft", "date" : "2023-01-10", "contact" : [{ "name" : "AIT Austrian Institute of Technology", "telecom" : [{ "system" : "email", "value" : "mailto:office@ait.ac.at" }] }], "description" : "The currently active KIOLA Care Plan for a patient might be retrieved by a client, using a search with a fixed set of parameters. The retrieval might be confirmed, by adding a meta tag to the instance. ETags might be used to avoid fetching the same resource twice.", "purpose" : "This capability might be used by other systems (e.g. mobile clients) to retrieve the currently relevant care plan for immediate patient care for a specific patient. To ensure that the most current version of the care plan is used across all systems, clients might confirm the successful retrieval.", "kind" : "capability", "software" : { "name" : "KIOLA", "version" : "Bundle 2.5", "releaseDate" : "2023-02-01" }, "fhirVersion" : "4.0.1", "format" : ["application/fhir+json"], "rest" : [{ "mode" : "server", "documentation" : "\nThe retrieval is done in 4 steps:\n1. A search with the following parameters is sent to the server, eventually including a filter for the patient, if the user has access to more than one patient: \n * `status`: `active`\n * `category`: `https://fhir.ehealth-systems.at/kiola/careplan/category#kiola-care-plan`\n * e.g. `subject__identifier`: `[KIOLA_SUBJECT_UUID]`, if required\n2. Either a single care plan is returned in the result list, or an empty list, if the patient currently does not have an active care plan.\n3. The retrieval is confirmed, by adding the meta tag `https://fhir.ehealth-systems.at/kiola/careplan/transient-tag#CONFIRMED` to the care plan using the `$meta-add` operation on the returned care plan instance. The timestamp and userAgent parameters might be appended to the code, to indicate the client and time of retrieval, e.g. `{userAgent=Pixel 4a/13 at.ac.ait.dm2/4.12.0(664):36fde7dd,timestamp=2022-11-25T09:28:29.950008}`.\n4. The server returns the result of the operation.\n\nOptionally, the returned ETag might be saved in step 2 and sent along in a successive retrieval in step 1 in the `If-Modified` HTTP header. If the current care plan has not been changed, a `302` HTTP code (not modified) should be returned.\n\nSequence Diagram:\n\n![](kiola-care-plan-retrieval.drawio.svg)\n", "resource" : [{ "type" : "CarePlan", "profile" : "https://fhir.ehealth-systems.at/artifacts/StructureDefinition/kiola-care-plan", "interaction" : [{ "code" : "read" }, { "code" : "search-type" }], "operation" : [{ "name" : "$meta-add", "definition" : "http://hl7.org/fhir/OperationDefinition/Resource-meta-add" }] }] }] }