This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Proposal: Patient Registry Request Add Patient

From HL7Wiki
Jump to navigation Jump to search
  • Committee: PAFM, see GForge Feature Request Tracker item 1722 [1]
  • Timing: WGM Vancouver, September 2008. Updated in May 2011 (see tail end of page)
  • Author: René Spronk, on behalf of Helse Vest, Norway

Summary

A project in the western healthcare region of Norway uses a number of HL7v3 interactions (from the Normative Edition 2008, a.k.a. NE20008) for the management of person and patient identifiers/demographics information (Patient & Person registry: find candidates, get demographics; Patient Registry: notifications for new registration, update, nullification, duplicates resolved). The entire healthcare region has one single patient registry.

The region has a use-case for a service wehereby an application submits a set of demographics data, and where the patient registry returns a patient identifier. This interaction (and its responses) are missing in NE2008. This proposal seeks to add these interactions, along with suppoprting artefacts (e.g. storyboards, trigger events).

Storyboards

This storyboard demonstrates a local application (not a patient registry) sending a request to the enterprise patient registry to add a new record to the enterprise patient registry. The enterprise patient registry system will respond with a confirmation and the enterprise identifier for the new patient record, or it will respond with a rejection and the reason for the rejection.

Notes:

  1. This existing storyboard (from NE2008) is "close", but not the same.
  2. there are two storyboards. The distinction is that for one request a person identifier is know prior to excuting the request. In the other storyboard the person identifier isn't known.

Narrative Storyboard #1

Astrid Everywoman, daughter of Eve Everywoman, has just been born. As a person Astrid isn't yet known in the nationwide person registry. Nurse Nancy uses the hospital's clinical application and sends a request (containing such things as name, birth date, gender and address) to the enterprise Patient Registry to get hold of a temporary patient identifier. The Patient Registry responds with a patient identifier and the set of demographics detail as provided in the request. (The request to add the patient will fail if a patient record for Astrid Everywoman did already exists). Nancy uses the patient identifier of Astrid in all subsequent copmmunications.

Narrative Storyboard #2

Adam Everyman is admitted at the emergency ward. Peter Peterson, the admitting physician, checks the the nationwide person registry and gets hold of the national person identifier. Dr. Peterson uses the hospital's clinical application and sends a request (containing such things as the person identifier, name, birth date, gender and address) to the enterprise Patient Registry to get hold of a patient identifier. The Patient Registry responds with a patient identifier and the set of demographics detail as provided in the request. (The request to add the patient will fail if a patient record for Adam Everyman did already exists). The patient identifier of Adam is used in all subsequent copmmunications.

Interactions

Note: temporary artefact identifiers have been used. This proposal doesn't request nor envision that these artefact IDs be used in thze standard.

Interaction List

  • Patient Registry Request Add Patient (PRPA_IN201314UV02)
  • Patient Registry Patient Added (PRPA_IN201912)
  • Patient Registry Patient Not Added (PRPA_IN201913)
    • The payload model will be equal to that of the PRPA_IN201911 interaction: it is a copy of the request that has been refused.

Discussion

  • 20080918, WGM, Vancouver: PA was waiting for use-case and storyboard, but in principle this was already anticipated. Can also be solved by making patient.id[0..*] instead of [1..*] in the (payload MT of) the current Patient registry Add request interaction.
  • Depending on whether Norwegians need just the identifiers in the response or the full model, an update may be needed for the application response as well.
  • 20080918. Motion: to accept this proposal (with mod) and create a new (non-backwards compatible) version of the current Patient Registry Add Request and associated receiver responsibility interactions. Depending on whether the Norwegian stakeholder needs just the identifiers in the response or the full model, an update may be needed for the application response model as well. (Rene/Irma, 4-0-2)
  • 2009-01-14, WGM, PA: it is now known that the use-case calls for a full response model

Changes to existing published material

This section contains the additional content above and beyond what is current published.

Note: temporary artefact identifiers have been used. This proposal doesn't request nor envision that these artefact IDs be used in thze standard.

Storyboard

  • Storyboard PRPA_ST201314UV01

Storyboard diagram: Two (existing) application roles PRPA_AR201305UV (Patient Registry Request Placer) and PRPA_AR201306UV (Patient registry Request Filler). PRPA_IN201314UV01 (Patient Registry AssignId Add Request) interaction is responded to by either Patient Registry Add Request Accepted(PRPA_IN201312UV02) or Patient Registry Add Request Rejected(PRPA_IN201313UV02).

Narrative Storyboard #1: Astrid Everywoman, daughter of Eve Everywoman, has just been born. As a person Astrid isn't yet known in the nationwide person registry. Nurse Nancy uses the hospital's clinical application and sends a request (containing such things as name, birth date, gender and address) to the enterprise Patient Registry to get hold of a temporary patient identifier. The Patient Registry responds with a patient identifier and the set of demographics detail as provided in the request. (The request to add the patient will fail if a patient record for Astrid Everywoman did already exists). Nancy uses the patient identifier of Astrid in all subsequent communications.

Narrative Storyboard #2: Adam Everyman is admitted at the emergency ward. Peter Peterson, the admitting physician, checks the the nationwide person registry and gets hold of the national person identifier. Dr. Peterson uses the hospital's clinical application and sends a request (containing such things as the person identifier, name, birth date, gender and address) to the enterprise Patient Registry to get hold of a patient identifier. The Patient Registry responds with a patient identifier and the set of demographics detail as provided in the request. (The request to add the patient will fail if a patient record for Adam Everyman did already exists). The patient identifier of Adam is used in all subsequent copmmunications.


Application Roles

No new content. Existing application roles PRPA_AR201305UV (Patient Registry Request Placer) and PRPA_AR201306UV (Patient registry Request Filler).

Trigger Event

New trigger event:

  • Patient Registry AssignId Add Request (PRPA_TE201314UV01)
  • Description
  • Structured Name: Patient Livingsubject Event Activate Request
  • Type: User request

A source system sends a patient record to a patient registry with a request to assign a patient identifier and to add the record to the registry.

R-MIM

New R-MIM PRPA_RM201314UV01 (Patient Registry AssignId Add Request): structure is equal tothe PRPA_MT201301UV02 R-MIM without the patient.id attribute. Textual walkthrough: equal to that of the above R-MIM, without a description of patient.id

Change Overview section of the walthrough to:

The Patient Activate R-MIM defines the payload for messages used for requests to assign a new patien identifier, and to add the resulting new record to a patient registry.

Interactions

  • Patient Registry AssignId Add Request (PRPA_IN201314UV01)

A user initiates a request to add a record to a patient registry, and for a new patient id to be assigned to the patient.

Wrappers:

  • Transmission Wrapper: Send Message Payload MCCI_MT000100UV01
  • ControlAct wrapper: Master File / Reg Request Control Act,Role Subject MFMI_MT700721UV01
  • The payload model will be PRPA_RM201314UV01.

Receiver responsibilities: (these are existing interactions)

  • Patient Registry Add Request Accepted(PRPA_IN201312UV02)
  • Patient Registry Add Request Rejected(PRPA_IN201313UV02)

May 2011

Rene: Whilst creating the Norwegian implementation guide for the current DSTU Person registry interaction (see [2], this is a Norwegian nationwide project whereas the above use case was based on one of the 4 Norwegian healthcare regions); the AddPerson operation) some changes [with regard to the UV models] had to made for the Norwegian project which I'd like to share with the WG:

  • PRPA_IN101311UV02
    • id attributes are required in the UV model. In the Norwegian scenario the senders of the interaction don't assign any identifier, it is the explicit intent of the service that it returns an identifier for the person of which the demographic record is being sent. In the Norwegian realm model I removed these attributes from the model.
    • assigningOrganization (scoper) is required (whereas optional in updatepersonrecord) in the UV model. The scoper could be valued, in this context it contains the same information as the author of the request, and the author as present in the ControlAct wrapper.
      • if assigningOrganization has to be present, why does it contain the [contact] CMET flavour instead of just [identified]?
  • The UV interaction has two interactions as the return model, for use in a service environment I'll simplify this by using a single return interaction (2 wrappers - no payload, in case of errors) (2 wrappers and a payload - in case of success). This to fit with a service/WSDL type of exchange scenario.