Page History

Table of Contents

<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 a hubs the hub's institutions, namely EMDIS hub, Financial institutions, Transplant Centers and Laboratories are shared with the partner hubs. Thus a partner hub has all the required contact information to for the Institute ID’sIDs, ”INST_ID”, contained in EMDIS Requests. Hubs Donor Requests. 

Hubs are required to keep this contact information up to date and to broadcast any updates to their partner hubs.

Assumption:

1. not all institutions listed in EMDIS are necessary (any more)
2. strictly speaking only  the address to send samples to is necessary.
3. hpe, 2023-02-02: changed my mind: in the spirit of "only change what's really necessary", we should stick with the existing NEW_ADD semantics.

options: 

• centralized store of addresses? i.e. Database
• registries are responsible for sending addresses to other members 
  • using special destination address? 

6.2 Message denial [MSG_DEN]

The message denial is intended as an immediate response in the event that a particular message will be not acted upon. The reasons for such a response are variable. Some examples include: 

• The message submitted is not supported by the responding hub. 
• The message submitted or the associated action violates a house rule of the responding hub. 
• The message submitted or the associated action violates the EMDIS semantics.

While the MSG_DEN is a critical part of the EMDIS semantics, care should be taken to avoid scenarios in which a MSG_DEN is routine or expected. The MSG_DEN should largely be reserved for exception scenarios. A proliferation of MSG_DEN messages may indicate a system defect either on the part of the submitting or responding hub.

Assumption:

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

6.3 Warning message [WARNING]

A warning has an informational character. The affected message was processed at the recipient’s side i.e. the message has not to be resent. The sender of the affected message should check the ”warned” items and correct them if necessary. The message has to be presented to the responsible user (search coordinator) by the local EMDIS administrator in an appropriate manner. The optional REF_CODE should be present if it is a required field in the message referenced by MSG_CODE. A WARNING should be issued if not.

Proposal:

1. remove

...

.

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]

...