KIOLA Implementation Guide
0.1.0 - STU1

KIOLA Implementation Guide - Local Development build (v0.1.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

CapabilityStatement: KIOLA Care Plan Retrieval

Official URL: https://fhir.ehealth-systems.at/artifacts/CapabilityStatement/kiola-care-plan-retrieval Version: 0.1.0
Draft as of 2023-01-10 Computable Name: KIOLACarePlanRetrieval

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.

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.

Raw OpenAPI-Swagger Definition file | Download

KIOLA Care Plan Retrieval

  • Implementation Guide Version: 0.1.0
  • FHIR Version: 4.0.1
  • Supported Formats: application/fhir+json
  • Supported Patch Formats:
  • Published on: 2023-01-10
  • Published by: null

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:

  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:
    • status: active
    • category: https://fhir.ehealth-systems.at/kiola/careplan/category#kiola-care-plan
    • e.g. subject__identifier: [KIOLA_SUBJECT_UUID], if required
  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. 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. The server returns the result of the operation.

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.

Sequence Diagram:

null

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:

  • The relevant profiles (if any)
  • The interactions supported by each resource (Read, Search, Update, and Create, are always shown, while VRead, Patch, Delete, History on Instance, or History on Type are only present if at least one of the resources has support for them.
  • The required, recommended, and some optional search parameters (if any).
  • The linked resources enabled for _include
  • The other resources enabled for _revinclude
  • The operations on the resource (if any)
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