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 implementation of the central part of the Match-Connect architecture (broker, central hub) is based on these principles

(Moved from chapter 6) 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:


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?