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 Anchor3.2 - Create Patient3.2 - Create PatientThe 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

CreatePatientRequest (/api/v2/patients)

3.3 - Update Patient

...

3.3 - Update Patient

The UpdatePatientRequest A PUT to the patients endpoint is used to update a patient with the Search & Match Service.

UpdatePatientRequest (/api/v2/patients)

3.4 - Register Patient   Image Removed

...

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.

RegisterPatientRequest

Same payload as UpdatePatientRequest (/api/v2/patients).  Additional fields to be considered:

...

string

nullable:  false

...

string

nullable: false

...

string

nullable: false

...

string

nullable: true

...

string

nullable: true

.  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

A PUT to the patients/status endpoint is used to update a patient's search status with the Search & Match Service.  Allowable 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.

3.5 - Retrieve Patient

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

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 in the form of an embedded Patient block - described in the Admin chapter. 

3.9 - Update Registered Patient (PAT_UPD)

The updateRegisteredPatient message is used to update a registered patient with a partner registry.

3.10 - Patient Flows

3.11 - Patient Life Cycle

3.5 - Update Registered Patient    Image Removed

...

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 Image Removed

...

UpdatePatientStatusRequest

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:

...

string

nullable: false

...

string

nullable: false

...

integer

nullable: false

...

string

nullable: true

...

string

nullable: false

...

string

nullable: true

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