...
<Specific rules / expectations>
6.
...
1 Embedded Meta block
The additional meta-information "blocks" are
The Match Connect system acts as a central broker of information exchange between registries participating in the Match Connect ecosystem, also called central hub from here on. The central hub bears responsibility to:
- Route information from the sending registry to the receiving registry and maintain information integrity
- Provide meta information to aid in the investigation of message failures or data synchronization problems
- Provide meta information for traceability
- Ensure integrity of the data in the Search & Match Service
- Perform syntactic validation of the information (e.g. appropriate information structure, allowable values, valid dates, etc)
- Validate the data for fields which are contained in the Search & Match Service and update these accordingly. This applies to
- Patient data, in particular HLA
In performing these duties, the Match Connect system will inspect the contents of messages to determine who to route messages to and to perform basic validation. This content is not intended to be reviewed by administrators of the system except in cases of investigating message failures or data synchronization problems. Original message contents will never be modified by the central system but additional meta information "blocks" will be added to ensure the receiving registry is aware of:
- What registry sent the information (sender)
- What type of information is contained
- A message identifier
- A timestamp
- Any failed validations detected by the Match Connect system
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. |
}
6.2 Embedded Address block
Original message: Address to broadcast [NEW_ADD]
...
Institution Type INST_TYPE Req 3Institution Identification INST_ID Req 10Address Line 1 ADDR_1 Req 40Address Line 2 ADDR_2 Opt 40Address Line 3 ADDR_3 Opt 40Contact person PERSON Opt 40ZIP code ZIP Req 10City CITY Req 40Country COUNTRY Req 2Phone Number PHONE Req 20Fax Number FAX Opt 20Email address EMAIL Opt 60Accreditations obtained ACCREDITATION Opt 5Position 1: NetCord-FACTPosition 2: AABBPosition 3: to be definedPosition 4: to be definedPosition 5: to be defined
6.
...
3 Message Response
The message response is intended as an automated response to every user generated message. It serves three purposes:
...
| Send | Retrieve |
|---|---|
| post_api_v1_MessageResponse | |
| MessageResponse payload Meta block |
6.
...
4 Text message [TXT_MSG]
The TXT_MSG is useful to convey notes or comments pertaining to a particular patient, donor, or patient/donor pair.
...
| Send | Retrieve |
|---|---|
| post_api_v1_TextMessageRequest | |
| TextMessage payload Meta block |
6.
...
5 Alert message
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.
...
| Send | Retrieve |
|---|---|
| get_api_v1_AlertRetrieve | |
| Alerts can only be sent by the WMDA's central system | Alert Payload:
Meta block |
6.
...
6 Alert Update message
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.
...