FHIR Implementation Guide: Patient Corrections 1.0.18

Uit informatiestandaarden
Versie door Niek van Galen (overleg | bijdragen) op 23 jul 2024 om 10:15 (Beveiligde "MedMij:V6/FHIR Patient Corrections": Protect production page from accidental edits ([Bewerken=Alleen beheerders toestaan] (vervalt niet) [Hernoemen=Alleen beheerders toestaan] (vervalt niet)))
(wijz) ← Oudere versie | Huidige versie (wijz) | Nieuwere versie → (wijz)
Ga naar: navigatie, zoeken


Naar medmij.nl

1 Introduction

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

This information standard is inspired by the international HL7 Patient Corrections IG. 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. 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
Patient The user of a personal healthcare environment PHR Personal health record
  • sends a PatientCorrectionsCommunication
  • receives a confirmation of receipt (OperationOutcome)
CapabilityStatement: Send Receive FHIR client/server requirements
Healthcare provider The user of a XIS XIS Healthcare information system
  • receives a PatientCorrectionsCommunication
  • returns a confirmation of receipt (OperationOutcome)

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 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.
  • The use case specific FHIR profiles (like Communication) are not derived but copied in order for them to align with other FHIR materials in the Dutch realm.
  • mustSupport flags are not used in this IG.
  • Bundle.type=transaction and transaction-response are used instead of Bundle.type=collection.

4 Use case: send correction request on medical record

This use case covers the process of sending a correction request on an existing medical record. Other use cases might be added in the future.

4.1 Client sends PatientCorrectionsCommunication - PHR

Because sending a correction request can consist of (one or more) Communication resource(s) along with supporting resources, a transaction 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 required that a client is able to reuse previously requested resources from use cases outside this IG.

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

POST [base]

The body of the POST submission is a Bundle with Bundle.type=transaction. Each entry carries request details (Bundle.entry.request) that provides the HTTP details of the action in order to inform the system processing the transaction of what to do for the entry. (Note: Bundle.request is optional in FHIR, 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 SHOULD include the following HTTP Prefer header: Prefer: return=representation.

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

Examples:

4.1.1 Guidance on resource contents

On top of the guidance in the functional design and the descriptions in the relevant FHIR profiles, the list below provides direction on how to use the elements in the resources used in this information standard.

Examples of the resources can be found in the FHIR package. See the section on FHIR profiles for more information.

4.1.1.1 PatientCorrectionsCommunication

Every instance of PatientCorrectionsCommunication (Communication) 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: the patient that the correction request applies to
  • 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, healthcare provider and optionally (if known) the health professional
  • sender: a reference to the sender of the correction request
  • payload: the actual correction request message as a string

4.1.1.2 Patient

The Patient instance SHOULD contain at least the following elements:

  • name: the patient's birth name

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

4.1.1.3 HealthcareProvider

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: Zorgaanbiederslijst)

It is encouraged to include the organization's unique identifier like AGB or URA using the identifier element, if known.

4.1.1.4 HealthProfessional

The HealthProfessional (Practitioner/PractitionerRole) instance SHOULD contain at least the following elements:

  • name: the name of the practitioner

It is encouraged to include a practitioner's 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=transaction-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.

Example:

<Bundle xmlns="http://hl7.org/fhir">
    <type value="transaction-response"/>
        <entry>
            <resource>
                <Communication xmlns="http://hl7.org/fhir">
                    <id value="a9f7a826-fd3f-444a-9457-0d444ee7a966"/><!-- ID assigned by the XIS after receiving this resource-->
                    <meta>
                        <profile value="http://nictiz.nl/fhir/StructureDefinition/dwv-PatientCorrectionsCommunication"/>
                    </meta>
                    <identifier>
                        <system value="urn:oid:2.16.840.1.113883.2.4.3.11.999.​130.1.40"/>
                        <value value="4c6a73b0-bf86-43f4-bd98-2eed52d7161e"/><!-- Identifier assigned by the PHR upon initial POST -->
                    </identifier>
                    ...
                </Communication>
            </resource>
            ...
</Bundle>

A server SHOULD provide additional information (an acknowledgment of receipt) on the received correction request(s) by adding an OperationOutcome to the response with OperationOutcome.severity=information, OperationOutcome.code=informational and the actual message on the OperationOutcome.details.text element.

Example:

<OperationOutcome xmlns="http://hl7.org/fhir">
    <language value="nl-NL"/>
    <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 belt u 112."/>     
        </details> 
    </issue>
</OperationOutcome>

4.3 RESTful interactions

                                ┌───┐                                                             ┌───┐
                                │PHR│                                                             │XIS│
                                └─┬─┘                                                             └─┬─┘
 ╔═══════════════════════════════╗│                                                                 │  
 ║Send a new correction request ░║│                                                                 │  
 ╚═══════════════════════════════╝│                                                                 │  
                                  │        Create (POST) Bundle containing Communication(s)         │  
                                  │────────────────────────────────────────────────────────────────>│  
                                  │                                                                 │  
                                  │Return Bundle with created Communication(s) and OperationOutcome │  
                                  │<─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ │  
                                ┌─┴─┐                                                             ┌─┴─┐
                                │PHR│                                                             │XIS│
                                └───┘                                                             └───┘

5 FHIR profiles

Profile name FHIR Resource HCIM EN Canonical URL
dwv-PatientCorrectionsCommunication Communication n/a http://nictiz.nl/fhir/StructureDefinition/dwv-PatientCorrectionsCommunication
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-Organization
nl core HealthProfessional Practitioner Practitioner HealthProfessional http://nictiz.nl/fhir/StructureDefinition/nl-core-HealthProfessional-Practitioner
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.


7 Support

For questions and change requests regarding the information on this page, please create a ticket in Servicedesk Portal.