<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:

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:

1. 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:

1. A message seems not be the appropriate solution in an API environment. Alternatives?

6.6 Error Handling