FHIR Implementation Guide: Patient Corrections 0.1.0

Uit informatiestandaarden
Versie door Ahenket (overleg | bijdragen) op 9 dec 2021 om 16:27 (Server response - XIS)
Ga naar: navigatie, zoeken

Naar medmij.nl

1 Introduction

This page describes the process of filing correction requests on medical records within MedMij. A correction request is executed by a patient on an existing medical record and received by a known healthcare provider.

This information standard is inspired by the international HL7 Patient Corrections IG and tries to follow it where possible. However, the first version of this information standard is more restricted than Patient Corrections; specifically, the possibility of doing follow up on a correction request is omitted in this first version. Also, contrary to most other use cases for MedMij, no specific HCIM model has been identified for exchanging communication between patient (PHR) and practitioner (XIS).

This IG is a technical representation of the functional design and follows the principles of the general MedMij FHIR IG.

2 Actors involved

The table shows the relevant actors, systems and FHIR CapabilityStatements. The CapabilityStatements demonstrate the minimum conformance requirements for the described use cases.

Actors Systems FHIR CapabilityStatements
Name Description Name Description Name Description
Client The user of a personal healthcare environment PHR Personal health record
  • sends a PatientCorrectionsCommunication
  • receives a confirmation of receipt (OperationOutcome)
coming soon FHIR Client requirements
Healthcare professional The user of a XIS XIS Healthcare information system
  • receives a PatientCorrectionsCommunication
  • spawns a Task
  • returns a confirmation of receipt (OperationOutcome)
coming soon FHIR Server requirements

TODO: is the Healthcare professional actually an actor in this use case?

3 Boundaries and relationships

Go to Afsprakenstelsel

This FHIR implementation guide assumes that the PHR system is able to make a connection with the XIS and search/create resources. It does not provide information on finding the right XIS nor does it provide information about security. These infrastructure and interface specifications are described in the 'MedMij Afsprakenstelsel'.

The MedMij use case for Patient Corrections overlaps partially with the uses cases described in the HL7 Patient Corrections IG. Therefore, this IG tries to align as closely as possible to the HL7 Patient Corrections IG. However, there are key differences that prevent the verbatim use:

  • The current use case is more restricted.
  • The profiles for the MedMij use case reference HCIM based profiles for common resources like Patient, Practitioner, PractitionerRole and Organization.
  • This IG uses the OperationOutcome resource as a confirmation of receipt

TODO: to be completed

4 Use case: send correction request on medical record

TODO: refine introduction according to the functional design

4.1 Client sends PatientCorrectionsCommunication - PHR

Because sending a correction request can consist of one or more Communication resources along with supporting resources, a batch interaction is used. This allows for creating a set of resources in a single interaction and makes it possible to include referenced secondary resources if needed. Querying resources on the server before submitting the transaction Bundle (for instance: to be able to reference a Patient resource on the server) is not part of this FHIR IG, nor is it expected that a client is able to reuse previously requested resources from use cases outside this IG.

A batch interaction is performed by an HTTP POST command as shown:

POST [base]

The body of the POST submission is a Bundle with Bundle.type=batch. Each entry carries request details (Bundle.entry.request) that provides the HTTP details of the action in order to inform the system processing the batch or what to do for the entry. (Note: .request is optional, but SHALL be present, even for the resources which aren't Communications. See the overarching principles for more information.)

In order for the server to return each created resource in its entire form, the client SHALL include the following HTTP Prefer header: Prefer: return=representation

This use case does not limit the amount of Communication resources send in one transaction, there might be implementation guidelines (like for the Dutch subsidiary programme "VIPP 5") that provide more guidance on frequency and quantity of sending correction requests.

The resources included in the bundle SHALL conform to the profiles listed in the table below.

4.1.1 Guidance on resource contents

TODO: write a brief intro on why we include this PatientCorrectionsCommunication (required)

Every instance of PatientCorrectionsCommunication SHALL contain at least the following elements upon initial creation:

  • identifier: unique identifier for the purpose of data deduplication
  • status: with fixed value completed
  • category: with fixed value medRecCxReq
  • subject: a reference to the patient whose medical record is to be corrected
  • topic: subject line, like the subject of an email
  • sent: the date and time the correction request was sent
  • recipient: the recipient of the correction request, in most cases this will be the healthcare provider (e.g. a hospital), the healthcare professional (e.g. the doctor) MAY be used if known
  • sender: a reference to the sender of the correction request, in most cases this will be the patient
  • payload: the actual correction request message Patient (required)

When included in the Bundle, the Patient instance SHOULD contain at least the following elements:

  • name: the patients birth name
  • gender
  • birthDate
  • address: postal code and house number

This information is neccesary for the receiving XIS to perform an SBV-Z check and make sure the correction request is matched with the right patient.

It is encouraged to include an internal hospital patient number using the identifier element, if known. HealthcareProvider (required)

When included in the Bundle, the HealthcareProvider (Organization) instance SHOULD contain at least the following elements:

  • name: the name of the healthcare provider, in MedMij context this name can be derived from the entry in the ZAL (healthcare providers list, Dutch: Zorgaanbiedeslijst)

It is encouraged to include the organizations unique identifier like AGB or URA using the identifier element, if known. HealthcareProfessional (optional)

When included in the Bundle, the HealthcareProfessional (Practitioner/PractitionerRole) instance SHOULD contain at least the following elements:

  • name: the name of the practitioner

It is encouraged to include a practitioners unique identifier like AGB or BIG using the identifier element, if known.

4.2 Server response - XIS

The server returns an HTTP Status code appropriate to the processing outcome and returns a Bundle, with Bundle.type=batch-response, that contains one entry for each entry in the request, in the same order, with the outcome of processing the entry. Because the client request contains the HTTP Prefer header Prefer: return=representation the server SHOULD return a full version of all created resources.

After receiving one or more Communication resources in the Bundle, the server spawns a Task and returns a reference to this Task in Communication.about. TODO: required usage of the Task profile? Might not make sense for this use case.


<Bundle xmlns="http://hl7.org/fhir">
    <type value="batch-response"/>
                <Communication xmlns="http://hl7.org/fhir">
                    <id value="a9f7a826-fd3f-444a-9457-0d444ee7a966"/><!-- ID assigned by the XIS after receivement -->
                        <profile value="http://nictiz.nl/fhir/StructureDefinition/dwv-PatientCorrectionsCommunication"/>
                        <system value="urn:oid:2.16.840.1.113883."/><!-- Identifier assigned by the PHR upon initial POST -->
                        <value value="123"/>
                        <reference value="http://example.xis/Task/123"/><!-- Reference to the Task assigned by the XIS after receivement -->

A server SHOULD provide additional information on the received correction request by adding an OperationOutcome to the response with OperationOutcome.severity and OperationOutcome.code set to informational and the actual message on the OperationOutcome.details.text element.


<OperationOutcome xmlns="http://hl7.org/fhir">
        <severity value="information"/> 
        <code value="informational"/> 
            <text value="Uw wijzigingsverzoek is ontvangen, neem voor meer informatie contact op met uw zorgaanbieder. Bij levensbedreigende situaties belt u 112."/>     

4.3 RESTful interactions


5 FHIR profiles

TODO: add package notebox

Profile name FHIR Resource HCIM EN Canonical URL
dwv-PatientCorrectionsCommunication Communication n/a coming soon
dwv-PatientCorrectionsTask Task n/a coming soon
nl core Patient Patient Patient http://nictiz.nl/fhir/StructureDefinition/nl-core-Patient
nl core HealthcareProvider Organization HealthcareProvider http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthcareProvider
nl core HealthProfessional Practitioner HealthProfessional http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional
nl core HealthProfessional PractitionerRole PractitionerRole http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-PractitionerRole

6 Release notes

Release notes can be found on the functional design page.