Match-Connect is an API-based platform designed to streamline and modernise donor-patient communication across registries.

Match-Connect replaces the older EMDIS system with a more secure, standardised, and future-proof solution for international collaboration.

• Patient API (must be implemented first): Manages patient data and updates.
• Search API (requires Patient API): Initiates and retrieves donor search results.
• Connect API (requires Search API): The third API service that WMDA provides in the secure registry-to-registry communication system. Connect API provides a modern message-based architecture enabling registries to communicate donor exchange requests and responses efficiently, rapidly, and securely.

APIs work behind the scenes and will not change your system’s graphical interface (GUI). You have two options:

1. Use software that already supports Match-Connect APIs (e.g., contact Steiner Ltd, Czech Republic).
2. Integrate the APIs into your own system. This will require:
   • Knowledge of REST APIs.
   • Ability to build connections to Match-Connect.
   • Familiarity with JSON data format.
   • (Optional) Use of Postman or similar tools.

Match-Connect does not currently provide automatic delivery receipts. However:

• Endpoint messageResponseRequest 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-tomachine type of message, as compared to EMDIS where such responses can be user-generated.
• You can use the messageRetrieve endpoint to confirm that a message has been received.
• For critical messages, registries may implement manual confirmation or use the textMessageRequest endpoint for follow-up communication.
• Messages with responseType “success” and “warning” are sent to the receiving registry. Messages with responseType “failed” will not be sent. Appropriate responses are provided by the API:
  • 200 OK for responseType “success” and “warning”;
  • 400 Bad request for responseType “failed”.

No. Match-Connect itself is a pure API-based service, so there’s no standalone demo application available.
However, you can explore the Search & Match sandbox, which includes a web app that works as a demo environment for testing the search and matching process.

If your organisation wants to use Match-Connect, you’ll need to implement the API endpoints and connect your own local system to Match-Connect.

Please see Match-Connect Demo video by Matchis and Gift of Life, showcasing how Match-Connect operates when integrated with local registry software.

Yes, during the transition period (2024–2027), registries may use both systems in parallel. However, the goal is to fully retire EMDIS by the end of 2027.

• Registries can implement specific/recommended sets of API endpoints depending on their use of Match-Connect services.
• Modular Implementation: Registries can enable only the API endpoints relevant to their needs.
• Standardised Platform: Central interface supports consistent search and communication across WMDA registries and transplant centres.
• IT Efficiency: Reduces reliance on separate search tools, potentially lowering maintenance and technical debt.
• Global Data Access: Maintains international visibility of donor records.
• Efficient Matching: Provides search results from 57 countries and 102 organisations through integrated algorithms.
• Secure Infrastructure: Cloud-based system designed for data protection and high availability.
• Privacy Compliance: Meets GDPR and ISO 27001 standards for personal data handling.
• Error Reduction: Automation minimises manual data entry.
• Advanced Algorithms: Hap-E Search and ATLAS matching with optional filters and sorting.
• Open Access: Available to all WMDA members, including non-EMDIS registries.
• Continuity: Supports international coordination if EMDIS use changes.
• Integrated Services: Includes Health Availability Check and Work-Up tools for donor–patient management.

As of September 2025:

Many WMDA members are now exploring and implementing Match-Connect. Leading organisations like DKMS Registry and NMDP plan to migrate their operations in 2026. Canadian Blood Services, Matchis, and Gift of Life have already gone live and are ready to connect with others.  More information can be found here.

• Synchronising registry software with Match-Connect APIs.
• Understanding message flows and API endpoints. However, API implementation is only about 10-15% of the effort according to early implementers.
• It is crucial to assess your local system and determine how to integrate API connections into existing business operations.
• Adapting internal processes and workflows to fit the new platform, leveraging automation and managing operational changes.
• Educating search and transplant coordinators about new and/or different search algorithms (e.g., Hap-E vs ATLAS).
• Transitioning from legacy systems like EMDIS.
• Maintaining and operating both Match-Connect and EMDIS in parallel during the transition period.
• Ongoing features delivery and changes require implementers to update their own systems accordingly.
• Managing the implementation and post-implementation phases like a major software development project where oversight is critical. Structured check-ins with all relevant stakeholders during these phases help address communication gaps early, provide ongoing monitoring to track issues effectively, and create opportunities to recognise progress.

• Like-for-like EMDIS capability was completed in October 2024.
• Review the latest version of the semantics for more current information on API functionality.
• The Available and upcoming features page provides updates on the status of the API and work in progress.
• Most early adopters are currently in various stages of implementation. The Implementation Overview page lists the status of each implementer and their progress.

• WMDA provides Match-Connect documentation, Match-Connect Swagger specs, and sandbox environments for testing API implementation.
• In-person early adopter meetings during WMDA events for peer learning.
• Monthly 1-on-1 meetings with the WMDA IT team for technical support.
• Dedicated support via email and shared forums.
• A free dummy ION for each implementing organisation to use for internal testing.

• Via structured API message endpoints (e.g., extendedTypingRequest, reservationRequest, etc).
• Original EMDIS language uses Request/Result terminology when speaking about donor requests. In API terminology there are also similar words. A combination was made in creation of API endpoints. For example, when sending an Extended Typing Request as a donor request, the registry must make an API request to an endpoint that is called extendedTypingRequestRequest. To receive that response, the receiving registry must make a call to an API endpoint called extendedTypingRequestRetrieve. Then, for the donor registry to send the message Extended Typing Result, it must send an API request to an endpoint that is called extendedTypingResponseRequest. Respectively, the patient registry retrieves the response (result) from the endpoint extendedTypingResponseRetrieve.
• A communication matrix (Match-Connect National/House Rules) is being developed to show which registries support which endpoints. In the future, this information will also be accessible via an API endpoint.
• Alerts and broadcast messages are used for system-wide updates.

No. If your organisation does not support a specific message type, you are not required to respond. However:

• It is recommended to send a denial or requestRejectedRequest (NO_RES) message to inform the sender. requestRejectedRequest (NO_RES) message is used to notify the requesting registry when a request cannot be fulfilled (service cannot be provided).
• WMDA encourages registries to document supported message types in the communication matrix (Match-Connect National/House Rules which is in development).

A donor can have only one open request of the same type at a time. Multiple identical requests for the same patient–donor pair are invalid and must be rejected by the receiving registry.

For example, if an extendedTypingRequest (TYP_REQ) has already been sent for HLA locus A for a specific patient–donor pair, sending the exact same request again would be denied. However, it is valid to send another extendedTypingRequest (TYP_REQ) for the same pair if it is for a different locus. It is also acceptable to have different types of requests in parallel, such as IDM request and VT request, but never two VT requests at the same time.

Searches can be run for 0MM, 1MM, or 2MM. However, there are restrictions:

• A 1MM search is not allowed if a patient has over 40,000 0MM donors.
• A 2MM search is not allowed if a patient has over 40,000 1MM donors.
• API users can start a 0MM and a 1MM search simultaneously, however this is not possible in the web application.
• For more detailed information see Allowed order of starting mismatch searches

• Donor records are uploaded by registries via full or differential uploads to WMDA’s Data Manager. Data Manager supports both manual and automatic data uploads, allowing registries to list donor information in the Search & Match Service. Once data is uploaded and processed, it becomes accessible through the Search & Match service and is also integrated into the Match-Connect.
• Organisations implementing Match-Connect are required to update their donor data daily. See WMDA Standard 5.10.1.
• Any changes to donor data (like HLA typing, status, or IDM results) are returned in the response message and have to also be updated separately in the Search & Match system to ensure an up-to-date master data.
• Data retention policies vary by registry. WMDA provides Recommendation on Data Retention and Destruction, a high-level overview as the member’s policy should be drafted taking into account each one's national legal/regulatory requirements.
• WMDA may collect and retain various types of user data, including but not limited to personal information, medical information, communication history, and donor/patient matching details. Participating organisations ensure that the collection and retention of such data are conducted in compliance with relevant data protection regulations.

Donors are typically reserved when a registry initiates a request (e.g., extended typing, IDM request, sample request, reservation request). The default reservation period is 90 days, but this can vary based on registry policies and donor availability.

reservationResponseRequest (RSV_RES) message informs the requesting patient registry if the donor registry has confirmed the reservationRequestRequest (RSV_REQ) OR if the donor reservation was performed after another request.

When a donor is requested via Match-Connect, they have to be reserved (typically for 90 days) by the responding registry, and the updated donor status is included in the Reservation Response.

Reservation response is an expected return message for:

• extendedTypingRequestRequest (TYP_REQ)
• sampleRequestRequest (SMP_REQ)
• infectiousDiseaseMarkerRequestRequest (IDM_REQ)
• reservationRequestRequest (RSV_REQ)

Donor data is uploaded via full or differential uploads to WMDA's Data Manager system. Match-Connect uses this data for messaging, while Search & Match uses it for matching algorithms. Synchronisation relies on:

• Daily differential uploads by registries.
• Consistent use of GRID and WMDA IDs.
• Refreshing search results to reflect updated donor information.

This is addressed via delta searches. If a donor drops from 10/10 to 9/10, refreshing the search or running a 9/10 search will reveal updated results.

Yes, however WMDA places responsibility on the requesting registry to determine histocompatibility. Match grade validation is implemented to ensure appropriate pairings.

• GRID (Global Registration Identifier for Donors): A standardised donor ID used across registries.
• wmdaId: A globally unique identifier assigned to each patient and donor within WMDA systems.
• patientId & donorRegistryId: local registry IDs used internally by registries to manage their own records.

Usage Guidelines:

• Use wmdaId for API interactions and message flows.
• Use GRID for donor identification in search results and Connect messages.
• Maintain mapping between local IDs and WMDA IDs to ensure synchronisation.

Message order is managed through sequence numbers provided by the central Match-Connect system. Each message includes a unique number to help registries detect missing or out-of-order messages.

To maintain correct order, registries should:

• Always check the sequence number of received messages.
• Retrieve messages using the availableMessages endpoint before calling the specific retrieve endpoint.
• Only process messages if the sequence is complete - otherwise, retrieve the missing message.

Optionally implement local message queues to help maintain sending order and retry logic.

Yes. Messages are soft-deleted after retrieval and remain recoverable for 72 hours. During this time, you can still retrieve them using the appropriate endpoints. WMDA recommends:

• Regularly polling the availableMessages and messageRetrieve endpoints.
• Using recoverMessages endpoint to restore soft-deleted messages within 72h.
• Implementing local logging or archiving on your side.
• Contacting WMDA support if the message is no longer recoverable.

No, donor specific endpoints are not available at this time. WMDA will introduce donor-related endpoints in the future based on user demand.  Feel free to submit a RFC via this link.

Local registry systems must be able to switch the communication channel for open patient cases. This is possible by the introduction of the EMDIS_ID in the embedded patient block in Match-Connect. Please see Transition Recommendation for more details.

The recommendation would be not to switch communication channels for open requests but to finish the request workflow in the communication channel the request has been started. This means that the channel must be controlled on a request level in local registry systems. Please see Transition Recommendation for more details.

By making use of the EMDIS_ID in the embedded patient block in Match-Connect ongoing reservation must be handled by the local registry system accordingly. Please see Transition Recommendation for more details.

The decision on how to handle this scenario ultimately rests with the implementing registry and is more operational than technical. WMDA does not recommend blocking the entire messaging queue. If possible, block only the failed message, while continuing to accept and process other messages.