MedMij:Vdraft/FHIR Patient Corrections

Draft version of the FHIR IG for Patient Corrections. Currently in development and therefore not yet suitable for implementation. The repository containing the FHIR conformance materials, also in draft status, can be found on GitHub. The draft version of the functional design can be found here.

This version will be tested in a proof of concept (PoC) and should not be used outside this PoC.

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).

Current active information standards developed for MedMij are based on HL7® FHIR® STU3 and HCIM release 2017. To provide a future proof solution for patient corrections in the Dutch realm and follow the international HL7 Patient Corrections IG, this information standard is based on HL7® FHIR® R4 and HCIM release 2020. This decision has limited impact due to the minor differences between the artifacts compared to HCIM release 2017 and FHIR STU3.

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

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

4.1.1.1 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

4.1.1.2 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.

4.1.1.3 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.

4.1.1.4 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 receivement of 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.

Example:

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

At this point in time, both the server side created Task as well as the reference to the Task in Communication have no functional basis in this use case other than act as a mechanism to link and keep track of resources. A XIS may choose to use the Task to keep track of or follow up incoming correction requests, but is not expected to provide updates to the PHR. It is conceivable that future versions of this information standard will provide more detailed information on further processing and workflow using the Task, thus follow the international HL7 Patient Corrections IG.

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.

Example:

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

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.