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.participant
exists where theCareTeam.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.participant
is added, theCareTeam.participant.period
is set with aPeriod.start
of date/time at update. ThePeriod.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 thePractitionerRole.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:
The
ServiceRequest.ehealth-sharingPolicy
must specify sharing is allowed and, currently, that this is sharing with a national health archive as the destinationThere must exist a ClinicalImpression referring to the measurement with
ClinicalImpression.ehealth-clinicalimpression-decision
set to a Coding forapproved-for-sharing
The measurement must be an Observation or QuestionnaireResponse
For a QuestionnaireResponse it must be a response to a Questionnaire:
for which a representation as the Danish profile of the CDA Questionnaire Form Definition Document (QFDD) exists
for which the location of the QFDD is known in the infrastructure.
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 representationComposition.section.entry
which is a reference to a DocumentReference (theReference.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:
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.The
Appointment.ehealth-releasebleResource
must, if present, be set to true.The Appointment has exactly one Patient as a participant
No shared document representing the appointment has been manually deprecated.