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 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.
Patient Identifiers
Identifier
Description
patientId
Provided by the local registry system.
Should be worldwide unique.
Should follow the construct of ION + local patient id.
The ION to be used is the ION of the patient registering registry (PR).
Should be provided as a user-friendly (displayable) id for use on screens and on documentation.
connectPatientId
Provided by the local registry system
Must be worldwide unique
Must follow the construct of ION + local patient id.
The ION to be used is the IONn of the patient registering registry (PR).
Should be provided as a user-friendly (displayable) id for use on screens and on documentation
Should be the same as patientId whenever possible, assuming the patientId followed the construct of ION + local patient id
If the original patientId did not follow the construct of ION + local patient id, then this the connectPatientId must follow that construct, and will therefore be different than the patient id.
wmdaId
Generated by the central (SMC) system.
Must be globally unique.
Must be used for all system-to-system patient identification after the initial patient registration.
3.2 - Create Patient
A POST to the patients endpoint is used to submit a patient to the Search & Match Service. This call returns a wmdaId for the patient, please be aware that in the current implementation a new wmdaId is assigned to a patient. When a patient was created before and stopped/anonymized (see Patient status), when this patient is created again, a new wmdaId will be assigned. Implementation tip: it might be valuable to save the wmdaId (old and new) in this specific use case.
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) example:1961-05-27
diagnosis
{...}
diseasePhase
string
ethnicity
string
poolCountryCode
string example:NL
ISO 3166-1 alpha-2 Country Code (capitalized)
transplantCentreId
string example:TC X
abo
string
rhesus
string
weight
integer example:76
sex
string
legalTerms
boolean example:true
If not set to true, then patientId will not be stored.
Field
Details
wmdaId
integer example:123456
3.3 - Update Patient
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.
Organisation unique identifier for patient. Cannot be set unless "legalTerms" is set to "true". Do not use real names here.
A patient ID can only be updated when it was not set before.
hla*
{...}
idm
{...}
dateOfBirth
string($date) example:1961-05-27
diagnosis
{...}
diseasePhase
string
ethnicity
string
poolCountryCode
string example:NL
ISO 3166-1 alpha-2 Country Code (capitalized)
transplantCentreId
string example:TC X
abo
string
rhesus
string
weight
integer example:76
sex
string
legalTerms
boolean example:true
If not set to true, then patientId will not be stored.
wmdaId*
integer example:123456
None specified
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 (with the search ids).
The diagram below displays the full logic of which patient state changes are allowed and the effect on automatic updating of search results.
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.
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.
In order to prevent unnecessary storage of search results and other patient related information, there are automated processes in place to automatically clean up patients that are not in use.
After a patient has not been viewed in any way (patient or search results), the patient will be moved to the "Inactive" state in Search & Match. You can see how much time is left until a patient is moved to the "Inactive" (STP) state by going to the patient list.
Simply clicking on the patient or its search result will reset the timer and will provide you with another 42 days until the patient is automatically moved to the "Inactive" state.
A patient that has been in the "Inactive" (STP) state for more than 6 months is anonymised and cannot be recovered any more.
Below are two diagrams that further explain the life cycle of patients in Search & Match with different levels of details
