Introduction

Today, registries around the world use a variety of methods to support the donor search process. While some still rely on manual communication channels such as email or fax, others use EMDIS — a system that has served as the electronic standard in our field for many years. However, EMDIS is approaching the end of its lifecycle, and the international community has agreed to move forward with Match-Connect (MC) as the modern, future-ready solution.

Purpose

This document outlines how to establish a new registry-to-registry connection using the Match Connect API.

Scope

It is intended to support a smooth transition from current communication methods — whether digital systems like EMDIS or manual approaches such as email, fax, or phone — to the Match Connect platform. The guidance also covers how to manage individual connections between registries.

Before going live, every registry is expected to test its Match Connect connection with at least one partner in a dedicated test environment.

These recommendations are aligned with the Minimum Viable Product (MVP) defined for Match-Connect and were written with a focus on unrelated adult donors. By the time most registries transition, Match Connect endpoints for cord blood units (CBUs) will also be available. The creation of those endpoints is not expected to affect the current transition guidance.

Set up a new Match-Connect API based connection without former EMDIS connection

Preconditions to establish a new SMC API based connection are:

• Both partner registries must support at least all involved API calls for all mandatory requests. A request is a collection of API calls needed for the registry to registry communication of a functional process. For a complete list of the API calls to be support please see: A - Appendix
• Basic administrative calls must be supported, like: MessageResponseRequest, MessageResponseRetrieve or availableMessages.
• If optional requests shall be included the involved registries must agree on the additional endpoints.
• If old, non-automatic communicated requests exists those requests must be finished in the old, manual fashion. 
• All new requests after Go-Live must be started via the API connection according to registry implementation preferences (donor only, donor & cbu, etc).

Managing Ongoing Patient Requests and Reservations

To prevent the creation of duplicate patient records on the donor registry side, both partners moving to a new Match Connect API-based connection must share a list of relevant patient IDs.

This allows the donor registry to recognize whether a patient included in a new request (via the embedded patient block) already exists in their local system. Fields such as connectPatientID or emdisPatientID within the embedded patient block can be used for this purpose.

Set up a new Match-Connect API based connection with former EMDIS connection

• Preconditions to establish a new Match-Connect API based connection are:

  • Both partner registries must support at least all involved API calls for all mandatory requests. A request is a collection of API calls needed for the registry to registry communication of a functional process. For a complete list of the API calls to be support please see: A - Appendix
  • Basic administrative calls must be supported, like: MessageResponseRequest, MessageResponseRetrieve or availableMessages.
  • If optional requests shall be included the involved registries must agree on the additional content.
  • All new requests after Go-Live must be started via the API connection.
  • For all requests that can not be sent via the APIs directly, e.g. CT+WU, HAC a generic request must be sent to retrieve referenceMessageId for the further communication, e.g. text messages, attachments.
• Handling existing searches and requests
  
  • Old requests that have been started via EMDIS have to be finished in EMDIS and only new requests have to be started via API (yet maintaining one patient search!)
  • Active / formal patient searches running longer than the transition time envisaged should be transferred to Match-Connect together with potentially old requests.
  • All Search & Match relevant EMDIS messages, e.g. PAT_UPD, PAT_STAT, ... must not be sent / processed anymore.
  • After the transition all cases will "lose" there patient status in the local registry system. The old EMDIS patient status is now reflected by the case status in S&M. Patients in Connect don't have a status anymore, only the requests they are connected to have their own status.

Managing Open Requests and Reservations During the Transition

Both open requests and reservations involve the challenge of matching a patient record from the old EMDIS system with a corresponding record in Match Connect — when both actually refer to the same patient.

To support this identification during the transition period, the embedded patient block in Match Connect allows the inclusion of an EMDIS_ID. This field should be used for all patient cases that were created before the transition to Match Connect. For new cases created after the switch, this field should be left empty.

Handling of different communication channels with different partners

As not all registries will be ready to switch to Match-Connect at the same time each registry must be able to maintain both channels: EMDIS and Match-Connect in parallel for a transition period. The local registry system must control the individual communication in order to use the correct channel per partner. The local system must be able to determine:

• for which partner
• for which individual request (for open request at the moment of transition)

a message must be send via API or EMDIS.

Initial Synchronization of Address Data

In the EMDIS system, address information (such as details for financial institutions) was shared separately through a specific message type called NEW_ADD. Any further communication referred to these addresses using an organization ID (INST_ID) defined in that message.

In Match Connect (MC), address information is now included directly within each request as a structured address block. To continue supporting local partner management, these address blocks still include an organization ID (organisationID).

To make the transition smoother, partners switching from EMDIS to Match Connect are encouraged to exchange a translation table that maps old INST_ID values to the new organisationID values.

For partners establishing a new connection via Match Connect (without a previous EMDIS link), it is recommended to exchange a basic set of address blocks to initialize partner data on both sides.

Frequently Asked Questions:

• How to handle open patient cases?
  • Local registry systems must be able to switch the communication channel open patient cases. This is possible by the above discussed introduction of the EMDIS_ID in the embedded patient block in Match-Connect.
• How to handle open requests?
  • The recommendation would be not to switch commnuication channels for open requests but to finish the request workflow in the communication channel the request has been started.
    • this either means that the channel must be controlled on a request level in local registry systems
• How to deal with ongoing reservations?
  • By making use of the EMDIS_ID in the embedded patient block in MC ongoing reservation must be handled by the local registry system accordingly.