These guidelines are intended to provide a baseline set of Match-Connect administration practices for all Match-Connect participants. Due to the critical nature of business operations facilitated via Match-Connect, it is expected that these guidelines will be followed closely and consistently. This should ensure the ongoing success of message exchange between Match-Connect partners.

• The Match-Connect system architecture is based on privacy and security by design principles. Deviation from these principles has to be justified, documented and approved. Typically, a trade-off has to be made between privacy/security and overall system complexity.
• A Match-Connect administrator should respond to all Match-Connect-related inquiries within 24 hours (excluding weekends), regardless of the content of the inquiry.
• Inquiries that reference system problems (for example, problems with sending/receipt of messages) should be given high priority.
• Sufficient time and care should be devoted to development and testing when establishing a connection with Match-Connect. Close collaboration is often necessary between new Match-Connect partners and WMDA to ensure that business and system expectations are being adequately met on all sides, before exchanging Match-Connect messages in production environments.

• If a new Match-Connect partner does not want to implement the whole set of available message types, reasonable groups of message types should be implemented together. (tbd: reasonable sets of messages, aka known as EMDIS implementation level.

• Generally faxes and emails should be avoided in an electronic communication system. If they become necessary, it’s recommended not to mix channels in message groups, for example, if the TYP_REQ was in Match-Connect, the result should be in Match-Connect as well and not by fax/email (and vice versa). 

The implementation of the central part of the Match-Connect architecture (broker, central hub) is based on these principles

• not storing any data or meta-data of Match-Connect participants after retrieval by the receiving hub
• not changing any data (payload) of Match-Connect messages
• ensure integrity and traceability of the messages exchanged (for details see Chapter 6.0).

To Consider For Documentation:

6.2: Frequency of upload definitions and terms for CBU vs donor (M) - likely already covered in Search & Match (in general) - will also be referenced in the request section (timing of donor diffs in result msgs)*

6.3: Allow for a real-time update for donors with requests (Request update in parallel to database update) - definitions and terms (M) - technical guidelines

6.4: HT Frequency per Registry (C) - out of scope for now

6.5: Data Quality Validation (S) - describe envelope opening concept in general guidelines and specifics of meta-inf in Admin.

6.6: Privacy and Security by design ( M ) - technical guidelines (for credentialing, etc)?  Should be some general write-up in general / business guidelines re: not storing data

6.7: Data Impact Assessment - sub-sections of privacy / security?

6.8: Technical and organizational measures - sub-sections of privacy / security?