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

Compare with Current View Page History

« Previous Version 9 Next »

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.

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?

  • No labels