Generated Narrative: OperationDefinition -s-create-episode-of-care URL: [base]/$create-episode-of-care Parameters Use Name Scope Cardinality Type Binding Documentation IN episodeOfCareAndProvenances 1..1 Bundle 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' OUT return 0..1 Bundle
Den telemedicinske infrastruktur (eHealth Infrastructure)
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 GDPR Data Controller (Danish: 'Dataansvarlig') of the EpisodeOfCare is provided through the 'ehealth-managing-organization' extension (managingOrganizations), where each entry holds the responsible organisation and the period during which it held that responsibility. The standard 'managingOrganization' property is no longer used (cardinality 0..0). ### 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' - 'http://ehealth.sundhed.dk/policy/dk/aeldreloven' ### Diagnosis referenced Condition resource For any diagnosis listed, the referenced Condition must be concerning the same Patient as the EpisodeOfCare. ### Treatment area validation When creating an EpisodeOfCare, the infrastructure validates that all diagnoses (referenced Condition.code) are within the treatment area of the telemedicine solution tied to the EpisodeOfCare.The telemedicine solution is determined by inspecting the incoming security token of the practitioner creating the EpisodeOfCare (coexistence-tag in scope claim).The treatment areas are defined by each telemedicine solution having a ValueSet determining the allowed Condition.code.The treatment area ValueSets are characterized by having a useContext with 'system-treatment-area' context code, and using the coexistence-tag as the value (see https://ehealth.sundhed.dk/fhir/ValueSet-ehealth-usage-context-type.html). ## 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```. ## Validation - Patient.deceased must be false to create episode of care ### 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.
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'