Versions Compared

Old Version 12

changes.mady.by.user Erik Nielsen

Saved on

compared with

New Version Current

changes.mady.by.user malthe lange

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Excerpt

Technical description of how to enroll enrol a patient in an episode of care.

Info

Use Case: https://docs.ehealth.sundhed.dk/latest-released/sparx/EARoot/EA2/EA2/EA25.htm

Table of Contents

Establishing a Citizen as a Patient

The Patient resource is a central resource in the eHealth Infrastructure. It plays a number of several different roles:

  • Conveys basic information about the patient (name, address, birth date, gender, civil registration number, demographics information, etc.)

  • Conveys extended information about the patient

    • Contact information

    • Language / Need for an interpreter

    • Temporary addresses

    • General practitioner

Info

A Patient is considered a 'singleton' in the eHealth Infrastructure. The patient is primarily a container for demographic information. While it is allowed according to the FHIR specification to have multiple different logical

...

Patients for the same person, it does not fit the case for the infrastructure and the Danish modelling of patient information. As such, the patient resource is shared across different

...

episodes of

...

care and other clinical resources.

Ensuring a Match Between CRN and Citizen

In order to To verify the correspondence between the Citizen name and CRN, a lookup can be made with a Person name lookup, based on the CRN given in the input Person resource.

...

Expand
titleExample Create Patient Request in HAPI FHIR Client Framework
Code Block
languagejava
Parameters in = new Parameters().addParameter()
  .setName("crn").setValue(new Identifier().setSystem("urn:oid:1.2.208.176.1.2").setValue("2810887020"));
Parameters result = client.operation().onType(Patient.class).named("createPatient").withParameters(in).execute();

Expand
titleExample Create Patient HTTP Request and Response
Code Block
languagexml
POST /Patient/$createPatient
Content-Type: text/xml; extended-operation-type
Accept: */*
Host: localhost:8080
accept-encoding: gzip, deflate
content-length: 689
<Parameters xmlns="http://hl7.org/fhir">
    <parameter>
        <name value="crn"/>
        <valueIdentifier>
            <system value="urn:oid:1.2.208.176.1.2"/>
            <value value="2810887020"/>
        </valueIdentifier>
    </parameter>
</Parameters>

Example HTTP Response:

Code Block
languagexml
HTTP/1.1 200
status: 200
Date: Wed, 20 Feb 2019 09:00:35 GMT
X-Powered-By: Trifork
Content-Type: application/fhir+xml;charset=utf-8
Content-Encoding: gzip
Transfer-Encoding: chunked
Server: Jetty(9.4.14.v20181114)
<Parameters xmlns="http://hl7.org/fhir">
    <parameter>
        <resource>
            <Patient xmlns="http://hl7.org/fhir">
                <id value="9952"/>
                <meta>
                    <versionId value="1"/>
                    <lastUpdated value="2019-03-29T11:22:34.053+01:00"/>
                    <profile value="http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-patient"/>
                </meta>
                <text>...</text>
                <identifier>
                    <system value="urn:oid:1.2.208.176.1.2"/>
                    <value value="2810887020"/>
                </identifier>
                <name>
                    <family value="Møller"/>
                    <given value="Anne"/>
                    <given value="Holm"/>
                </name>
                <birthDate value="1988-10-28"/>
                <address>
                    <extension url="http://ehealth.sundhed.dk/fhir/StructureDefinition/ehealth-municipality-code">
                        <valueCoding>
                            <system value="urn:oid:1.2.208.176.8.1.100"/>
                            <code value="370"/>
                            <display value="Næstved"/>
                        </valueCoding>
                    </extension>
                    <use value="home"/>
                    <type value="postal"/>
                    <line value="Bjergagervej 110"/>
                    <city value="Karrebæksminde"/>
                    <postalCode value="4736"/>
                    <country value="DK"/>
                </address>
                <generalPractitioner>
                    <reference value="http://organization.exttest.ehealth.sundhed.dk/fhir/Organization/1"/>
                </generalPractitioner>
            </Patient>
        </resource>
    </parameter>
</Parameters>

...

Creating and Maintaining an EpisodeOfCare

Info

See EpisodeOfCare for an introduction to use and elements.

...

The EpisodeOfCare is created by invoking $create-episode-of-care on the CarePlan Service.

Preparing Conditions

An EpisodeOfCare relates to one or more conditions. These must be created as part of the $create-episode-of-care operation by including them in the input bundle.

...

Prerequisite to activating the EpisodeOfCare, the citizen’s consent to undergo/be enrolled to the EpisodeOfCare and comprised CarePlan resources must be registered in a Consent. The Consent is created through Consent Create and must contain details as described in the Consent introduction.

Activating the EpisodeOfCare

...

  • Setting the status to active through an EpisodeOfCare UpdateHTTP-Patch.

  • Setting a status change to active in the EpisodeOfCare.ehealth-statusschedule resulting in an automatic status change in the future.

...

EpisodeOfCare.status can be adjusted in two ways through the use of EpisodeOfCare HTTP-Patch (Update is not exposed):

  • Setting EpisodeOfCare.status directly

  • Setting a scheduled status change by updating EpisodeOfCare.ehealth-statusschedule

Allowed status changes:

  • From planned to active, onhold, waitlist, cancelled, or entered-in-error

  • From waitlist active to planned onhold, active, onhold finished, cancelled, or entered-in-error

  • From waitlist to planned, active to , onhold, finished, cancelled, or entered-in-error

  • From onhold to active, finished, cancelled, or entered-in-error

  • From finished to entered-in-error or active

See implementation guide: EpisodeOfCare.status

Info

Enforced constraints on the duration of scheduled status with value onhold.

When setting scheduled status changes it is automatically enforced how long the EpisodeOfCare can be planned as paused (with status set to onhold). This is done to prevent patient plans from being forgotten in a paused state.

When setting EpisodeOfCare.ehealth-statusschedule:

  • If no further status changes are planned by the user, then the infrastructure will automatically insert a planned change back to active 7 days after the start of onhold

  • Maximum The maximum duration of a planned onhold status is 30 days.

Info

EpisodeOfCare automatically maintains a status history EpiodeOfCare.statushistory:

  • The status history is maintained as a list of ehealth-statusHistory objects each containing:

    • A status.

    • The Period of time period the status was set.

  • The history is automatically updated when the status is (regardless of whether the status is set manually or is a scheduled change):

    • A new entry is added with the new status and an open-ended period that started at the time of the status change.

    • The Period.end in the entry for the previous status is updated to be the same as the start of the new entry.

      • One should consider the period to be exclusive-end to avoid confusion as the Period.end of one historic status and the Period.start of the next have the same timestamp.

...

Over the lifecycle of an EpisodeOfCare, the set of CareTeam involved might change. Adjustment of CareTeam involved can be performed a number of in several ways:

  • Through EpisodeOfCare Patch

    • Setting the EpisodeOfCare.team

    • Setting the scheduled team changes in EpisodeOfCare.ehealth-teamschedule

  • Through EpisodeOfCare$update-care-teams

Note

CareTeam Handover and Unhandled Tasks

The CareTeams involved in an EpisodeOfCare have access to the EpisodeOfCare, all CarePlan related to it, and all measurements related to ServiceRequest related to the CarePlan and so on (provided the appropriate Role-based access privileges are present for a user using the CareTeam). For Task resources currently created automatically by the infrastructure, the set of CareTeam involved in an EpisodeOfCare are not designated as Task responsible.

There might, however, still exist

...

Tasks created by other means, for instance

...

, Tasks created on user initiative in a solution. For these, it should be considered whether a change in the set of CareTeam involved in the EpisodeOfCare should also result in adjusting of Task.taskResponsible (by adding CareTeam added to the EpisodeOfCare).

Adjusting the Period

The period of time in which the EpisodeOfCare is applicable is reflected in the EpisodeOfCare.period. Adjustment of EpisodeOfCare.period is performed through EpisodeOfCare Patch.

...