Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 129 Next »

This page and subpages describe the behavior of services in the infrastructure which are not directly invoked by a client.

What is described here is what happens when a user performs login, how submitted measurements are processed in automated processing, and how citizens' adherence to care plans are monitored and handled. Also described is the periodic importing of organizations.

Sub-pages

Content

Handling at Login

When a user performs login at the eHealth Infrastructure, various checks are performed and security artifacts (such as the security token) are produced. In addition, certain resources are read, created, or possibly updated. The following applies to users of the Practitioner type.

The external security token contains one to many organizational scopes in which the user can have:

  • Zero, one or many different careteams in which the user can have one or many user roles

  • Zero, one or many user roles in the organizational scope

For the recognized user roles bound to a recognized and pre-existing CareTeam, it is ensured that:

  • a CareTeam.participantexists where the CareTeam.participant.member references the Practitioner. A participant can have multiple roles in a CareTeam.

    • If such an entry is not present, or does not contain the current role then the CareTeam is updated.

      • When a CareTeam.participantis added, the CareTeam.participant.period is set with a Period.start of date/time at update. The Period.end is left without value to form an open-ended period.

For all the organizational scopes where the organization identification can be resolved to an Organization in the eHealth Infrastructure, it is ensured that:

  • a PractitionerRole exists where the PractitionerRole.practitioner references the Practitioner and the PractitionerRole.organization references the Organization

Sharing through Registering Documents in National Document Sharing Infrastructure

Some FHIR resources in the eHealth Infrastructure are assembled to volatile FHIR Compositions (as described in https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2242281473/Performing+Document+Query+and+Retrieve+and+Using+Transformations#Preparing-Transformations-by-Assembling-Required-FHIR-Resources), transformed to Danish profiles of Clinical Document Architecture (CDA) documents (as described in https://ehealth-dk.atlassian.net/wiki/spaces/EDTW/pages/2242281473/Performing+Document+Query+and+Retrieve+and+Using+Transformations#Transformation-Details), and registered in the national health document sharing archives. This way, the patient and other healthcare professionals can access the health data registered through other health systems while subjected to various access controls and audit logging.

This description focuses on the criteria for this registration to take place.

Document Registering of Measurement Data

Prerequisites for Document Sharing of Measurement Data


Before release FUT-I 2024.1

Submitted measurements, whether in the form of Observation, QuestionnaireResponse, or Media, are each associated with a ServiceRequest. As part of being evaluated by a Practitioner, each measurement can be approved for sharing in the form of a ClinicalImpression with the element ehealth-clinicalimpression-decision set to a Coding for approved-for-sharing.

The criteria for registering a measurement as a document are:

  1. The ServiceRequest.ehealth-sharingPolicy must specify sharing is allowed and, currently, that this is sharing with a national health archive as the destination

  2. There must exist a ClinicalImpression referring to the measurement with ClinicalImpression.ehealth-clinicalimpression-decision set to a Coding for approved-for-sharing

  3. The measurement must be an Observation or QuestionnaireResponse

  4. For a QuestionnaireResponse it must be a response to a Questionnaire:

    1. for which a representation as the Danish profile of the CDA Questionnaire Form Definition Document (QFDD) exists

    2. for which the location of the QFDD is known in the infrastructure.

  5. For an Observation, it must not specify an absent data reason (.dataAbsentReason). Observations without a value can't be shared with CDA Personal Health Monitoring Report (PHMR).

An Observation is registered as a Danish profile of the CDA Personal Health Monitoring Report (PHMR) document and a QuestionnaireResponse as a Danish profile of the CDA Questionnaire Response Document (QRD) document.

How must the location of externally accessible QFDD be known to the infrastructure? There shall be a:

  • FHIR Composition (profile ehealth-composition) with:

    • Composition.section.entry which is a reference to the FHIR Questionnaire corresponding to the QFDD representation

    • Composition.section.entry which is a reference to a DocumentReference (the Reference.type shall be "DocumentReference")

  • FHIR DocumentReference (profile ehealth-documentreference) referenced as above with:

    • DocumentReference.content.attachment.url which is expected to provide the location of the QFDD


With release FUT-I 2024.1

Submitted measurements, whether in the form of Observation, QuestionnaireResponse, or Media, are each associated with a ServiceRequest. As part of being evaluated by a Practitioner, each measurement can be approved for sharing in the form of a ClinicalImpression with the element ehealth-clinicalimpression-decision set to a Coding for approved-for-sharing.

The criteria for registering a measurement as a document are:

  1. The ServiceRequest.ehealth-sharingPolicy must specify sharing is allowed and, currently, that this is sharing with a national health archive as the destination

  2. There must exist a ClinicalImpression referring to the measurement with ClinicalImpression.ehealth-clinicalimpression-decision set to a Coding for approved-for-sharing

  3. The measurement must be an Observation or QuestionnaireResponse

  4. For a QuestionnaireResponse it must be a response to a Questionnaire:

    1. for which a representation as the Danish profile of the CDA Questionnaire Form Definition Document (QFDD) exists

      1. The QFDD must exist as a DocumentReference in document-transformation (Upload of QFDD is possible through KAM questionnaire editor)

      2. The QFDD must be referenced in the Questionnaire by Questionnaire.identifier with Identifier.system starting with "urn:oid:" and Identifier.value must contain the QFDD unique id

  5. For an Observation, it must not specify an absent data reason (.dataAbsentReason). Observations without a value can't be shared with CDA Personal Health Monitoring Report (PHMR).

It is also possible to allow the infrastructure to automatically approve the sharing of measurements, this is done by setting the ServiceRequest.sharingApprovalPolicy extension to automatic, the criteria for registering the measurement as a document is the same, the infrastructure will just generate the ClinicalImpression referring to the measurement with ClinicalImpression.ehealth-clinicalimpression-decision set to a Coding for approved-for-sharing automatically, when the measurement is submitted.

An Observation is registered as a Danish profile of the CDA Personal Health Monitoring Report (PHMR) document and a QuestionnaireResponse as a Danish profile of the CDA Questionnaire Response Document (QRD) document.


Document Registering of Appointments

A created or updated Appointment (whether of profile ehealth-appointment or ehealth-videoappointment) is registered as the Danish profile of the CDA Appointment Document (APD), provided that criteria are met.

The criteria for registering an Appointment resource are:

  1. The Appointment.ehealth-legalBasis must be present and designate a legal basis for which national document-sharing infrastructure has been established - currently, this is the case for Healthcare Act only.

  2. The Appointment.ehealth-releasebleResource must, if present, be set to true.

  3. The Appointment.serviceType must be regular or video (corresponding to use of the profiles https://docs.ehealth.sundhed.dk/latest-released/ig/StructureDefinition-ehealth-appointment.html or https://docs.ehealth.sundhed.dk/latest-released/ig/StructureDefinition-ehealth-videoappointment.html , respectively)

    1. The Appointment has exactly one Patient as a participant

If a registered Appointment Document has been manually deprecated through the eHealth Infrastructure (see Deprecate document metadata in the national document sharing infrastructure) in the document sharing infrastructure, further updates of the Appointment resource are not reflected in new Appointment Documents being registered for that Appointment.

  • No labels