3.1 - Patient

...

Identification 

A patientId may be provided when registering a new patient in WMDA Search & Match.   Upon registration, a wmdaId will be assigned and returned.   The wmdaId itself is guaranteed to be globally unique, though it cannot guarantee that the same patient is not identified with another wmdaId.  registered by multiple organisations using the same patientId or with different patientId's within the same organisation. The wmdaId must be used to identify the patient in all calls to the Search, Match & Connect (SMC) service after the initial patient registration.

...

3.2 - Create Patient

...

A POST to the patients endpoint The CreatePatientRequest is used to submit a patient to the Search & Match Service.   This call returns a wmdaId for the patient.

Post
patients
Expand title Request..

...

. Field Details patientId string maxLength: 17 nullable: true example: 98761234P Organisation unique identifier for patient. Cannot be set unless "legalTerms" is set to "true". Do not use real names here. hla* {...} idm {...} dateOfBirth string($date) nullable: true maxLength: 10 example: 1961-05-27 diagnosis {...} diseasePhase string nullable: true Enum: Array [ 48 ] ethnicity string nullable: true Enum: Array [ 21 ] poolCountryCode string maxLength: 2 pattern: ^[A-Z]{2} nullable: true example: NL ISO 3166-1 alpha-2 Country Code (capitalized) transplantCentreId string maxLength: 10 nullable: true example: TC X abo string nullable: true Enum: Array [ 4 ] rhesus string nullable: true Enum: Array [ 2 ] weight integer nullable: true minimum: 1 maximum: 999 example: 76 sex string nullable: true Enum: Array [ 2 ] legalTerms boolean nullable: true default: false example: true If not set to true, then patientId will not be stored. Expand title Response... Field Details wmdaId integer example: 123456 nullable: false
Send
CreatePatientRequest
Patient

3.3 - Update Patient

The UpdatePatientRequest A PUT to the patients endpoint is used to update a patient with the Search & Match Service.  An update to search relevant information, such as HLA, ethnicity or pool will result in a refresh of the search.

...

3.4 - Update Patient Status

The UpdatePatientStatusRequest A PUT to the patients/status endpoint is used to update a patient's search status with the Search & Match Service.  Allowable statuses status values are SUS, PRE, ACT and STP.  A new patient is defaulted to the new (NEW) state.  Under the NEW state, searches must be requested explicitly.  When doing so, the patient is moved to the PRE state. Under the ACT state, searches will be kept up to date automatically.  SUS will stop automatic updates to searches, but results will remain for 42 days.  STP will terminate the search and delete all search results.

Image Removed

This endpoint does not affect the patient status at the donor registry or cord blood bank. For that please use endpoint UpdateRegisteredPatientStatus

...

• wmdaId
• newStatus
• changeReason

3.5 - Retrieve Patient

The retrievePatientRequest A GET to the patients endpoint is used to retrieve an individual patient's information from the Search & Match Service.

3.6 - Retrieve Patient

...

(s)

A GET to the patients/list endpoint The listPatientsRequest is used to retrieve multiple patient's information from the Search & Match Service.  You may define a page size, a specific page number, a series of allowable statuses and may limit to only patients assigned to you.

3.7 - Assign User To Patient

The AssignUserToPatient A PUT to the patients/user endpoint is used to assign a particular user name to a patient within the Search & Match Service.

3.8 - Register Patient   

There is no registerPatientRequest endpoint.  A patient is registered with a partner registry at the time of request - see the section on Requests. 

...

• Request
• Patient

...

• MetaInformation
• Sent payload

in the form of an embedded Patient block - described in the Admin chapter. 

3.9 - Update Registered

...

Patient (PAT_UPD)

The updateRegisteredPatientRequest updateRegisteredPatient message is used to update a registered patient with a partner registry.  The central hub will review the contents and update any values that are already stored in the Search & Match system.

3.10 - Update Registered Patient Status    Image Removed

The updatePatientStatusRequest is used to communicate changes in patient status.

(This is separate from the Search & Match updatePatientStatusRequest.  The payload is similar though the status variables may have a different name.  This is intended to be forwarded to the donor registry, not for consumption by Search & Match.  The patient registry is responsible to STP the search w/ Search & Match Service).

Statuses permitted are ACT, STP.

After the status has been set to stopped (STP), all pending requests but WOR_REQ are cancelled automatically at the remote hub. In this case, no REQ_CAN messages have to be sent by the transplant centre. The only way to reactivate the patient is to send a request (generic or other). The request is necessary since it cannot be guaranteed that the patient information is still up-to-data or stored at all at the remote hub. General data retention policies determine, how long patient information is retained after the search was stopped. 

However, it makes no sense to delete a patient who is in workup. Patient searches are sometimes not stopped at remote hubs although the search is not really active any more. This wastes time for matching and gives bad statistics about search length and search counts.

All hubs are strongly encouraged to monitor their international searches closely and stop or suspend them if not longer needed. The searched hub is allowed to send reminder faxes with patients without activities to the patient’s hub.

...

• wmdaId
• newStatus
• changeReason

...

• MetaInformation
• Sent payload

3.10 - Patient Flows

3.11 - Patient Life Cycle

3.11 - Request More Patient Info Image Removed

Allows a donor registry to request more details about a patient from the patient registry, e.g. if that extra information is needed in a VT or later maybe a WU request.  Locally developed and managed national rules should indicate which PII is required at which stage of the process.

If a request is received where patient information is expected, but missing: Acknowledge received message and respond with warning that search is on hold until missing info is received, perhaps with reference to national rules.

TODO:  Design message flow & elaborate semantic detail.

3.12 - Message Flows

Image Removed