| Table of Contents |
|---|
<title>
<Narrative>
<Swagger - API reference>
<temporary - document any differences needing implementation in swagger>
<Specific rules / expectations>
6.1 Embedded Address block
...
- message acknowledgment
- warning
- message denial
This is a purely machine-to-machine type of message, as compared to EMDIS where such responses can be user generated.
Message structure:
https://apispecs.wmda.info/?urls.primaryName=Connect%20API#/General/post_api_v1_MessageResponse
Additional fields to be added:
| Field name description | Field name | Nullable | Length |
|---|---|---|---|
| Original message ID | GUID | no | ? |
| Remark (required for warning and denial) | remark | yes | 120 |
| Original message type ??? seems not needed, if we get the original message by its ID |
6.
...
3 Text message [TXT_MSG]
The TXT_MSG is useful to convey notes or comments pertaining to a particular patient, donor, or patient/donor pair.
Proposal:
- remove
6.5 Message acknowledgement [MSG_ACK]
This message serves a confirmation letting your partner hub know that that their message has been received and stored in your system. A MSG_ACK message is explicitly requested by the partner hub.
Assumption:
- A message seems not be the appropriate solution in an API environment. Alternatives?
...
Note: Since Warnings are going to be automated, we must keep Text Messages as the only means for user communication left.
Message structure:
https://apispecs.wmda.info/?urls.primaryName=Connect%20API#/Message/post_api_v1_TextMessageRequest
6.4 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.
Message structure:
| Field name description | Field name | Nullable | Length |
|---|---|---|---|
| Text of the alert, informative message | alert | no | 120? |
6.5 Error Handling
???