<title>
<Narrative>
<Swagger - API reference>
<temporary - document any differences needing implementation in swagger>
<Specific rules / expectations>
6.1 Embedded Address block
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 Institute IDs, ”INST_ID”, contained in Donor Requests.
Hubs are required to keep this contact information up to date.
In the Match-Connect system, the addresses will be embedded in the donor requests. See chapter Requests for details.
Address block structure:
- Institution Type INST_TYPE Req 3
- Institution Identification INST_ID Req 10
- Address Line 1 ADDR_1 Req 40
- Address Line 2 ADDR_2 Opt 40
- Address Line 3 ADDR_3 Opt 40
- Contact person PERSON Opt 40
- ZIP code ZIP Req 10
- City CITY Req 40
- Country COUNTRY Req 2
- Phone Number PHONE Req 20
- Fax Number FAX Opt 20
- Email address EMAIL Opt 60
- Accreditations obtained ACCREDITATION Opt 5
- Position 1: NetCord-FACT
- Position 2: AABB
- Position 3: to be defined
- Position 4: to be defined
- Position 5: to be defined
6.2 Message Response
The message response is intended as an automated response to every user generated message. It serves three purposes:
- message acknowledgment
- warning
- message denial
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.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.
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?