<title>

<Narrative>

<Swagger - API reference>

<temporary - document any differences needing implementation in swagger>

<Specific rules / expectations>

6.0 Responsibilities of the Match Connect System / Broker

The Match Connect system acts as a central broker of information exchange between registries participating in the Match Connect ecosystem, also called central hub from here on.  The central hub bears responsibility to:

1. Route information from the sending registry to the receiving registry and maintain information integrity
   1. Provide meta information to aid in the investigation of message failures or data synchronization problems
   2. Provide meta information for traceability 
2. Ensure integrity of the data in the Search & Match Service
   1. Perform syntactic validation of the information (e.g. appropriate information structure, allowable values, valid dates, etc)
   2. Validate the data for fields which are contained in the Search & Match Service and update these accordingly. This applies to 
      1. Patient data, in particular HLA

In performing these duties, the Match Connect system will inspect the contents of messages to determine who to route messages to and to perform basic validation.  This content is not intended to be reviewed by administrators of the system except in cases of investigating message failures or data synchronization problems.  Original message contents will never be modified by the central system but additional meta information "blocks" will be added to ensure the receiving registry is aware of:

• What registry sent the information
• What type of information is contained
• A message identifier
• A timestamp
• Any failed validations detected by the Match Connect system

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 Institution contained in Donor Requests. 

• Hubs are required to keep this contact information up to date.
• It’s not only useless but forbidden to give a postbox (POB) in a LAB address since this address is used for delivery of samples. For the same reason ZIP code, City and Country are required in the address block.

In the Match-Connect system, the addresses will be embedded in the donor requests. See chapter Requests for details.

Address block structure (HP's suggestion, requires discussion regarding the accreditation):

https://hapifhir.io/hapi-fhir/apidocs/hapi-fhir-structures-r4/org/hl7/fhir/r4/model/Address.html

• 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

This is a purely machine-to-machine type of message, as compared to EMDIS where such responses can be user generated. 

Note: The concept of the REF_CODE field used in EMDIS is replaced by the GUID assigned by the central system to each message. The Message Response is supposed to be using the GUID of the original message as the Reference ID in its structure.

Message structure:

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.

Note: Since Warnings are going to be automated, we must keep Text Messages as the only means for user communication left.

Message structure:

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:

6.5 Alert Update message

The Alert  Update message is used to broadcast an update about some previous alert. Messages are generated centrally by WMDA. Members are expected to display them to the users.

Message structure: