You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

5.1 Address to broadcast [NEW_ADD]

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

options: 

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

5.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?

5.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

5.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

5.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?
  • No labels