The additional meta-information "blocks" are added to ensure the receiving registry is aware of:
metaInformation{
Field name | format | Description |
---|---|---|
messageId | string($uuid) | ID of the originally sent message |
sentAtUtc | string($date-time) | Server-supplied timestamp showing UTC time of Message delivery to recipient's inbox queue. |
sender | string maximum: 9999 minimum: 0 maxLength: 4 minLength: 4 example: 5678 | 4 digit ION of the sender |
messageType | string | To be designed and described. The idea is to help registry's MC admin to analyze possible issues reported in validationDetails field. AM: I think this is an excessive information, as messageId should be sufficient. |
validationDetails | To be designed and described. The idea is to supply the concerns of the central hub validation system that are acceptable but require attention of the receiving registry. |
}
Original message: Address to broadcast [NEW_ADD]
With this message block, the contact information of the hub's institutions, namely Financial institutions, Transplant Centers and Laboratories are shared with the partner hubs. Thus a partner hub has all the required contact information for the Institution contained in Donor Requests.
In the Match-Connect system, the addresses will be embedded in the donor requests. See chapter Requests for details.
Address block structure (HP's suggestion, requires discussion regarding the accreditation field and extension of the use field):
https://hapifhir.io/hapi-fhir/apidocs/hapi-fhir-structures-r4/org/hl7/fhir/r4/model/Address.html
e.g.
The name of the city, town, suburb, village or other community or delivery center. | ||
Country - a nation as commonly understood or generally accepted. | ||
The name of the administrative area (county). | ||
This component contains the house number, apartment number, street name, street direction, P.O. | ||
Time period when address was/is in use. | ||
A postal code designating a region defined by the postal service. | ||
Sub-unit of a country with limited sovereignty in a federally organized country. | ||
Specifies the entire address as it should be displayed e.g. | ||
Distinguishes between physical addresses (those you can visit) and mailing addresses (e.g. | ||
The purpose of this address. |
There is no register patient endpoint. Instead, an embedded patient block will accompany all requests. The embedded patient block looks as follows:
Patient
wmdaId* | integer nullable: false example: 1234 ID provided by the WMDA |
patientId* | string maxLength: 17 nullable: false example: P1234XX 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: trueEnum: Array [ 48 ] |
ethnicity | string nullable: trueEnum: Array [ 20 ] |
poolCountryCode | string maxLength: 2 pattern: ^[A-Z]{2} nullable: true example: NL ISO 3166-1 alpha-2 Country Code (capitalized) |
abo | string nullable: trueEnum: Array [ 4 ] |
rhesus | string nullable: trueEnum: Array [ 2 ] |
weight | integer nullable: true minimum: 1 maximum: 999 example: 76 |
sex | string nullable: trueEnum: Array [ 2 ] |
firstName | string maxLength: 30 nullable: true example: John First (given name) of the patient |
lastName | string maxLength: 30 nullable: true example: Doe Last (family name) of the patient |
In EMDIS, the following messages are linked to the donor updates:
These donor updates are for the receiving registry (patient registry) only and will not be updated in the central HUB. So the sending (donor) registry is responsible to send a DIFF upload to the S&M system in parallel to keep information in sync.
In the future a block for ADCUs may come to play.
Donor type | Payload | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Adult donor |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
CBU |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ADCU |
Here is the comparison of the DONOR_CB and the API endpoints: EMDIS vs API.xlsx
The message response is intended as an automated response to every user generated message. It serves three purposes:
This is a purely machine-to-machine type of message, as compared to EMDIS where such responses can be user generated.
Note: The concept of the REF_CODE field used in EMDIS is replaced by the GUID assigned by the central system to each message. The Message Response is supposed to be using the GUID of the original message as the Reference ID in its structure.
Message structure:
Send | Retrieve |
---|---|
post_api_v1_MessageResponse | |
| MessageResponse payload Meta block |
The TXT_MSG is useful to convey notes or comments pertaining to a particular patient, donor, or patient/donor pair.
Note: Since Warnings are going to be automated, we must keep Text Messages as the only means for user communication left.
Message structure:
Send | Retrieve |
---|---|
post_api_v1_TextMessageRequest | |
| TextMessage payload Meta block |
The Alert message is used to broadcast an important information about the system, like planned service outage. Messages are generated centrally by WMDA. Members are expected to display them to the users.
Message structure:
Send | Retrieve |
---|---|
get_api_v1_AlertRetrieve | |
Alerts can only be sent by the WMDA's central system | Alert Payload:
Meta block |
The Alert Update message is used to broadcast an update about some previous alert. Messages are generated centrally by WMDA. Members are expected to display them to the users.
Message structure:
Send | Retrieve |
---|---|
get_api_v1_AlertUpdateRetrieve | |
Alert updates can only be sent by the WMDA's central system | Alert Update Payload:
Meta block |