Versions Compared

Key

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

...

Table of Content Zone
minLevel1
maxLevel7
locationtop

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 Measurements

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.

Info

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

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

    No shared document representing the appointment

If a registered Appointment Document has been manually deprecated in the document sharing infrastructure, further updates of the Appointment resource are not reflected in new Appointment Documents being registered.