<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.  The Match Connect system 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. 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 HLA of patient data for fields which are contained in the Search & Match Service

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

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. 

Message structure:

https://apispecs.wmda.info/?urls.primaryName=Connect%20API#/General/post_api_v1_MessageResponse

Additional fields to be added:

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:

https://apispecs.wmda.info/?urls.primaryName=Connect%20API#/Message/post_api_v1_TextMessageRequest

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: