3.1 - Patient Identification
A patientId may be provided when registering a new patient. Upon registration, a wmdaId will be assigned and returned. The wmdaId itself is guaranteed to be globally unique, though it cannot guarantee that the patient is not identified with another wmdaId. The wmdaId must be used to identify the patient in all calls to the Search, Match & Connect (SMC) service after the initial patient registration.
Patient Identifiers
| Identifier | Description |
|---|---|
| patientId |
|
| wmdaId |
|
3.2 - Create Patient (Send Patient)
The CreatePatientRequest is used to submit a patient to the Search & Match Service. This call returns a wmdaId for the patient.
CreatePatientRequest (/api/v2/patients)
3.3 - Update Patient
The UpdatePatientRequest is used to update a patient with the Search & Match Service.
UpdatePatientRequest (/api/v2/patients)
3.4 - Register Patient 
The registerPatientRequest is used to register a patient with a partner registry. This message accompanies all requests.
Entire payload may be sent by the sending registry. The central hub can review the contents and update any relevant values that are (already) stored in the Search & Match system. The response of the api will provide results (fields / values) of the updates made.
Same payload as UpdatePatientRequest (/api/v2/patients). Additional fields to be considered:
| Patient Identifier | patientId | string nullable: false |
| Sending Registry | regSend | string nullable: false |
| Receiving Registry | regReceive | string nullable: false |
| Patient First Name | firstName | string nullable: true |
| Patient Last Name | lastName | string nullable: true |
3.5 - Update Registered Patient
The updateRegisteredPatientRequest is used to update a registered patient with a partner registry.
UpdateRegisteredPatientRequest
Same payload as RegisterPatientRequest. Empty / blank fields in the payload will mean deletion. Missing fields will have no effect.
3.6 - Update Patient Status
The updatePatientStatusRequest is used to communicate changes in patient status.
Statuses permitted in EMDIS are PRE, ACT, SUS, STP. PRE / ACT may have some relevance to Search & Match Service. SUS / STP may have relevance to Search, Match & Connect.
From EMDIS semantics:
"After the status has been set to suspended (SUS), the transplant centre is fully responsible for pending requests. If a transplant centre is no longer interested in a certain pending request, the request has to be cancelled by the transplant centre by means of a REQ_CAN message. If the transplant centre does not explicitly cancel a pending request, the request will be processed normally by the requested hub.
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 a PAT_UPD / PAT_STAT message pair. The PAT_UPD is necessary since it cannot be guaranteed that the patient information is still stored at the remote hub. It is up to each hub 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."
Fields for consideration:
| Sending Registry | regSend | string nullable: false |
| Receiving Registry | regReceive | string nullable: false |
| WMDA Patient Identifier | wmdaId | integer nullable: false |
| Old Patient State | priorStat | string nullable: true |
| New Patient State | newStat | string nullable: false |
| Reason For Change | reason | string nullable: true |
3.7 - Request More Patient Info
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.