Versions Compared

Old Version 113

changes.mady.by.user Rimke Postel

Saved on

compared with

New Version Current

changes.mady.by.user Alicia Venter

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

6.1 Embedded

...

blocks 

6.1.1 Embedded Meta block

The additional meta-information "blocks" are added to ensure the receiving registry is aware of:

  • A message identifier
  • A timestamp
  • What Which registry sent the information (sending registry)
  • What type of response is provided by the WMDA Match Connect system
  • Any failed validations detected by the Match Connect system
  • A sequence number, so that the receiving registry knows if any message is missing. 
DetailsFieldstring systems the type of message just sent by calling this
metaInformation*
Expand
title...
Field
referenceMessageId*string($uuid)
deliveredAtUtc*string($date-time)

Server-supplied timestamp showing UTC time of Message delivery to receiving registry's inbox queue.

sendingRegistry*integer
maximum: 9999
minimum:
 
1000
maxLength: 4
minLength: 4
example: 5678

4-digit ION of the sending registry

responseType

string

Enum:
Array [ Warning]

wmdaRemarks

One or more remarks, each in its own object


Expand
title...
remarkType
DetailsremarkType

string 
Array [ InvalidHLA ]

descriptionstring
messageSequenceNumber*

integer
example:12345

Incrementing integer set by WMDA MatchConnect

system that indicates the order in which the messages were received by the WMDA and therefore the order in which messages should be processed. Each receiving registry has its own unique sequence.

messageType*

string

Array [ attachment, alert, updatedPatient, ping, textMessage, genericRequest, extendedTypingRequest, extendedTypingResponse, sampleRequest, sampleInfo, sampleArrival, sampleResponse, infectiousDiseaseMarkerRequest, infectiousDiseaseMarkerResult, reservationRequest, reservationResponse, reservationRelease, requestCancellation, requestRejected, resultReminder, messageResponse, cordBloodUnitReportRequest, cordBloodUnitReportResponse ]

the type of message just sent by calling this endpoint

6.1.2 Embedded Address block (NEW_ADD)

With this message block, the contact information of the hub's institutions, namely Financial institutionsFinancial institutions, Transplant Centers, and Laboratories are shared with the partner hubs. Thus a partner hub partner hub has all the required contact information for the Institution contained in Donor Requests. 

  • Hubs are required to keep this contact information up to date.
  • It’s not only useless but forbidden to give a postbox (POB) in a LAB address since this address is used for the delivery of samples. For the same reason ZIP code, City, and Country are required in the address block.
  • The contactPerson is required if the INST_TYPE is ”LAB”.
  • The EMDIS ID (

    Organisation unique identifier for the institution (formerly known as INST_ID)

    of an institution should

    :

    • Should remain stable over time and
    should
    • must not be assigned to different institutions
    • Is a unique reference to an institution
    • Allows local address management if needed (e.
    • g. for other use cases) by receiving registry and backward compatibility to existing EMDIS implementations. 
    • Provided by the local registry system.  
    • Should be worldwide unique.
      • Should follow the construct of ION + local address id. 
        • The ION to be used is the ION of the patient registering registry (PR).
    • Should be provided as a user-friendly (displayable) id for use on screens and on documentation.


In the Match-Connect systemIn the Match-Connect system, the addresses will be embedded in the donor requests. See Chapter Requests for details.

Message structure:

SendRetrieveaddressRequest

addressRetrieve

Expand
titleRequest...
Field
Field

Details

organisationId
*

string
nullable:

false

true
minLength: 5
maxLength:

10

19

minLength

example:

3

9999123456

Organisation unique identifier for the institution.

  1. Unique reference to an institution
  2. Allows local address management if needed (e.g. for other use cases) by receiving registry and backward compatibility to existing EMDIS implementations. 
  • Provided by the local registry system.  
  • Should be worldwide unique.
    • Should follow the construct of
hub code
    • ION + local address id. 
      • The
hub code usually are the two-character ISO country code of the registry (e.g. NL for Netherlands)  
  • In the case of multiple registries in one country, a replacement code will be assigned.
        • ION to be used is the ION of the patient registering registry (PR).
    • Should
    Should
    • be provided as a user-friendly (displayable) id for use on screens and on documentation.
    line1
    organisation*

    string
    nullable: false

    maxLength: 60

    Address line 1

    line2
    Expand
    title...
    FieldDetails
    name*

    string

    nullable

    maxLength:

     true

    50

    maxLength

    example:

    60

    Address line 2

    line3postalCode*

    string
    nullable: false

    maxLength: 10

    city*

    string
    nullable: false

    maxLength: 40

    country*

    string
    nullable: false

    Institute A

    Name of the destination organisation

    addressLine1*

    string

    nullable: true

    maxLength: 60

    Address line 3

    maxLength: 50
    nullable: false
    example: Schipholweg 57

    First line of address. Generally the street and house number.

    addressLine2

    string
    maxLength: 50
    nullable: true
    example: Second floor

    Second line of address

    addressLine3

    string
    maxLength: 50
    nullable: true
    example: Unit 15

    Third line of address

    postalCode*

    string
    maxLength: 10
    nullable: false
    example: 2316 ZL

    city*

    string
    maxLength: 50
    nullable: false
    example: Leiden

    The name of the city, town, suburb, village or other community or delivery center.

    country*

    string

    minLength: 2
    maxLength: 2
    nullable: false
    example: NL

    2 character ISO country code ( ISO 3166-1 alpha-2)

    type*

    string
    nullable: false

    minLength: 3

    maxLength: 3

    HUB = EMDIS Hub
    DON = Donor centre
    TRA = Transplant centre
    HAR = Harvesting centre
    LAB = Typing laboratory
    FIN = Financial institution
    CBB = Cord Blood Bank

    Array [ node, donorCentre, transplantCentre, collectionCentre, lab, financialInstitution, cordBloodBank ]

    contactPerson*
    Expand
    title...
    FieldDetails
    name*

    string
    maxLength: 50
    example: Jane Doe

    The name of the contact person.

    contactPerson

    string
    nullable: true

    maxLength: 40

    Contact person. Required if type = LAB.

    phone*

    string
    maxLength: 50
    nullable: false

    maxLength: 20

    example: +31 123456789

    The value is a telephone number used for voice calls.

    fax

    string
    maxLength: 50
    nullable:

     

    true

    maxLength: 20

    example: +31 123456790

    The value is a fax machine.

    email

    string
    maxLength: 320
    nullable:

     

    true

    maxLength: 60

    receivingRegistry*string
    maximum: 9999
    minimum: 0
    maxLength: 4
    minLength: 4
    example: 1234

    4 digit ION of the receiving registry

    Expand
    titleResponse...
    FieldDetails
    wmdaResponseEmbedded WMDA Response Block
    Expand
    titleRequest...
    limitinteger
    default: 100
    shouldPeekboolean
    default: false

    Set to true if you want messages to remain available after retrieval

    Expand
    titleResponse...
    FieldDetails
    originalMessage{...}
    metaInformationEmbedded Meta Block

    6.1.3 Embedded Patient Block

    There is no "register patient" endpoint. Instead, an embedded patient block will accompany all requests. The embedded patient block looks as follows:

    The value is an email address.


    6.1.3 Embedded Patient Block

    There is no "register patient" endpoint. Instead, an embedded patient block will accompany all requests. The embedded patient block looks as follows:

    FieldDetails
    wmdaId*integer
    nullable: false
    example: 1234

    ID provided by the WMDA

    patientId*

    string
    maxLength: 17
    minLength:5
    nullable: false
    example: 99991234P

    MUST Start with ION of patient registry. Organisation unique identifier for patient. Cannot be set unless "legalTerms" is set to "true". Do not use real names here.

    emdisPatientIdstring
    maxLength: 17
    minLength: 3
    nullable:true
    example: AU9654021

    MUST start with two letter EMDIS hub code. The value comprises the EMDIS patient identification, where the patient search centre is an EMDIS member, otherwise the value is empty.

    hla*{...}
    idm{...}
    dateOfBirthstring($date)
    nullable: true
    maxLength: 10
    example: 1961-05-27
    diagnosis{...}
    diseasePhase

    string
    nullable: true

    Enum:
    Array [ PF, PI, AP, BC, AD, SD, RD, NA, C0, C1, C2, C3, C4, C5, C6, C7, C8, C9, P0, P1, P2, P3, P4, P5, P6, P7, P8, P9, R0, R1, R2, R3, R4, R5, R6, R7, R8, R9, N0, N1, N2, N3, N4, N5, N6, N7, N8, N9 ]

    ethnicity

    string
    nullable: true

    Enum:
    Array [ UK, AF, AS, CA, HI, AFNA, AFSS, ASSW, ASSO, ASCE, ASSE, ASNE, ASOC, CAEU, CAER, CANA, CAAU, HICA, HISA, MX, OT ]

    poolCountryCodestring
    maxLength: 2
    pattern: ^[A-Z]{2}
    nullable: true
    example: NL

    ISO 3166-1 alpha-2 Country Code (capitalized)

    abo
    FieldDetails
    wmdaId*integer
    nullable: false
    example: 1234

    ID provided by the WMDA

    patientId*string
    maxLength: 17
    nullable: false
    example: XY1234P

    Organisation unique identifier for the patient. Cannot be set unless "legalTerms" is set to "true". Do not use real names here.

    hla*{...}
    idm{...}
    dateOfBirthstring($date)
    nullable: true
    maxLength: 10
    example: 1961-05-27
    diagnosis{...}
    diseasePhase

    string
    nullable: true

    Enum:
    Array [  48  A, B, O, AB ]

    ethnicityrhesus

    string
    nullable: true

    Enum:
    Array [  20  P, N ]

    poolCountryCodeweightintegerstring
    maxLengthnullable: 2true
    patternminimum: ^[A-Z]{2}
    nullable1
    maximum: 999    true
    example: NL

    ISO 3166-1 alpha-2 Country Code (capitalized)

    76
    sexabo

    string
    nullable: true

    Enum:
    Array [  4  M, F ]

    rhesusfirstNamestring
    nullablemaxLength: true

    Enum:
    Array [ 2 ]

    		weightinteger
    50
    nullable: true
    minimumexample: 1
    maximum: 999
    example: 76    		sexJohn

    First (given name) of the patient

    lastNamestringstring
    maxLength:50
    nullable: true
    Enumexample:
    Array [ 2 ]    		firstName Doe

    Last (family

    string
    maxLength: 30
    nullable: true
    example: John

    First (given name) of the patient

    lastNamestring
    maxLength: 30
    nullable: true
    example: Doe

    Last (family name) of the patient

    mic{...}

    6.1.4 Embedded Donor Block

    ...

    In EMDIS, the following messages are linked to the donor updates:

    • IDM_RES
    • TYP_RES
    • NO_RES
    • RSV_RES

    These four and newly two more (SMP_ARR and SMP_INFO) will be replaced with the Match-Connect API endpoints that have the donor details embedded in the message. Respective endpoints of IDM_RES and TYP_RES will deliver new IDM and new typing details, and all the mentioned endpoints will also inform the patient registry of the new donor status.

    These donor updates are for the receiving registry (patient registry) only and will not be updated in the central HUB. So the sending (donor) registry is responsible to send a DIFF upload to the S&M system in parallel to keep information in sync.

    ...

    Expand
    title...

    grid*

    		string
    nullable: true
    maxLength: 19
    minLength: 19
    example: 9991012070433202000

    ...

    Expand
    title...

    id*

    string
    maxLength: 17
    example: CB1234567

    CBU Identification2 (formerly CB_ID)

    ...

    Expand
    title...

    id*

    string
    maxLength: 16
    example: A99991412345612N

    N/A in EMDIS, available in the future

    (donor in request)

    In case the embedded donor block is part of a message type that may not result in updates of donor-related data, the "embedded donor block (donor in request" block is used. 

    Only sending a grid, cordId or adcuId for message types with static donor information enhances privacy and security through data minimization.

    Donor typeDetails
    donor*
    Expand
    title...

    donorType*

    		string
    enum:
    Array [ adult, adcu, cbu ]

    donorId*

    string
    oneOf: 

    grid { "maxLength": 19, "minLength": 19, "example": 9991012070433202000 }

    adcuId { "maxLength": 13, "minLength": 13, "example": "A999916123456" } 

    cordId { "maxLength": 17, "example": "CB1234567" }

    6.1.5 Embedded Donor Block (donor in response)

    In EMDIS, the following messages are linked to the donor updates:

    • TYP_RES
    • IDM_RES
    • RSV_RES

    These three will be replaced with the Match-Connect API endpoints that have the donor details embedded in the message. Respective endpoints of IDM_RES and TYP_RES will deliver new IDM and new typing details, and all the mentioned endpoints will also inform the patient registry of the new donor status.

    The corresponding endpoints in Match-Connect are:

    • extendedTypingResponse
    • infectiousDiseaseMarkerResponse
    • reservationResponse

    These donor updates are for the receiving registry (patient registry) only and will not be updated in the central HUB. So the sending (donor) registry is responsible for sending a DIFF upload to the S&M system in parallel to keep information in sync.

    FieldDetails
    grid*

    string
    nullable:true
    maxLength: 19
    minLength: 19
    example: 9991012070433202000

    dateOfBirth*

    string
    nullable: false
    minLength: 10
    maxLength: 10
    example: 1961-05-27

    sex

    string
    nullable:true
    Enum: [M, F]

    hla*


    Expand
    title...

    a*

    dna* {...}

    description: HLA node with DNA

    b*

    dna* {...}

    description: HLA node with DNA

    c

    dna {...}

    description: HLA node with DNA

    drb1*

    dna* {...}

    description: HLA node with DNA

    drb3

    dna {...}

    description: HLA node with DNA

    drb4

    dna {...}

    description: HLA node with DNA

    drb5

    dna {...}

    description: HLA node with DNA

    dqa1

    dna {...}

    description: HLA node with DNA

    dqb1

    dna {...}

    description: HLA node with DNA

    dpa1

    dna {...}

    description: HLA node with DNA

    dpb1

    dna {...}

    description: HLA node with DNA

    abostring
    nullable:true
    Enum: [A, B, O, AB]
    rhesusstring
    nullable:true
    Enum: [P, N]
    donorRegistryIon*

    integer($int32)
    nullable: false
    minimum: 1000
    maximum: 9999
    example: 1234

    Unique number provided by ICCBBA for the registry that is responsible for the donor/CBU

    status*

    string
    nullable: false
    Enum: [ AV, TU ]

    ethnicity

    string
    nullable: true

    Enum:
    Array [ UK, AF, AS, CA, HI, AFNA, AFSS, ASSW, ASSO, ASCE, ASSE, ASNE, ASOC, CAEU, CAER, CANA, CAAU, HICA, HISA, MX, OT ]

    idm

    [ ... ]

    lastContactDate

    string($date)
    nullable: true
    minimum: 10
    maximum: 10

    marrowDonationsCount

    integer($int32)
    nullable: true
    example: 0

    pbscDonationsCount

    integer($int32)
    nullable: true
    example: 1

    donorAttribute

    string
    nullable: true
    maximum: 3

    weight

    integer
    nullable: true
    minimum: 1
    maximum: 999
    example: 76

    height

    integer($int32)
    nullable: true
    minimum: 1
    maximum: 999
    example: 161

    kir

    [ ... ]

    collectionType

    string
    nullable: true
    Enum: [ M, P, B ]

    Collection type, i.e. the willingness of the donor to donate in a specific manner. M = Marrow P = PBSC B = Both PBSC & Marrow

    transfusionsCount

    integer($int32)
    nullable: true
    example: 1

    pregnanciesCount

    integer($int32)
    nullable: true
    example: 2

    reservedPatientId

    string
    nullable: true
    example: 1234222ss

    statusEndDate

    string($date)
    nullable: true
    maximum: 10

    statusReason

    string
    nullable: true
    Enum: [ DO, DD, MR, PR, TX, MO, UC, OT, TQ, UK ]

    DO = Donor is too old, DD = Donor died, MR = Medical reasons, PR = Personal reasons, TX = After transplantation, MO = Donor has moved, UC = Unable to contact donor, OT = Other reasons, TQ = Typing questionable, UK = Unknown

    mic{...}
    ccr5string
    nullable: true
    Enum: [ DD, DW, WW ]
    lastMedicalCheckupDate

    string($date)
    nullable: true
    minimum: 10
    maximum: 10

    Here is the comparison of the DONOR_CB and the API endpoints: EMDIS vs API.xlsx

    6.1.6 Embedded general information

    Here is the comparison of the DONOR_CB and the API endpoints: EMDIS vs API.xlsx

    6.1.5 Embedded WMDA Response block

    The WMDA will provide a standard response to request messages sent to Match-Connect.  Its structure is as follows:

    FieldDetails
    deliveredAtUtc*string($date-time)

    Server-supplied timestamp showing time of Message delivery to receiving registry's inbox queue

    referenceMessageId*string($uuid)
    responseType*

    stringEnum:
    Array [ Success, Warning, Failed]

    messages can be failed, if the message has a structure or information that prevent delivery to the receiving registry. This could be incorrect JSON structure and non-existent ION or because the receiving registry does not allow messages from your registry. 

    receivingRegistryMessageSequenceNumber

    integer
    example: 12345

    Incrementing integer set by WMDA MatchConnect systems that indicates the order in which the messages were received by the WMDA and therefore the order in which messages should be processed. Each receiving registry has its own unique sequence.

    wmdaRemarks[...]

    ...

    block

    The WMDA will provide a standard response that contains the parameters used to retrieve messages sent to in Match-Connect.  Its structure is as follows:follows:

    generalInformation*
    Expand
    title...
    FieldDetails
    limit*integer($int32)
    default: 100
    shouldPeek
    boolean
    default: false
    totalCount*integer($int32)
    minimum: 0
    example: 1
    remainingCount
    remainingCount*integer($int32)
    minimum: 0
    isSuccessful*

    boolean

    default

    example: true

    summary*
    string
    String
    maxLength: 255
    example: 1 message retrieved successfully. 0 remaining messages.

    6.2 Message Response

    The message response is intended as an automated response to every user generated message. It serves three purposes:

    ...

    Send (Post)Retrieve (Post)
    MessageResponseMessageResponseRequest 

    MessageResponseRetrieve

    Expand
    titleRequest...
    FieldDetails
    organisationResponse
    Expand
    title...
    FieldDetails
    retrievedAtUtc*string($date-time)

    Server-supplied timestamp showing time of Message retrieval and storage in organisation's own systems

    referenceMessageId*string($uuid)
    responseType*

    string

    Enum:
    Array [  3 warning, acknowledge, deny ]

    remark

    string

    maxLength: 1000
    nullable: true

    Expand
    titleResponse...
    FieldDetails
    wmdaResponsemetaInformation*Embedded WMDA Response Meta Block
    Expand
    titleRequest...
    limitinteger
    default: 100
    shouldPeekboolean
    default: false

    Set to true if you want messages to remain available after retrieval

    messageSequenceNumber

    integer
    e    xamplet: 12345

    Optional field to request a message with a specific messageSequenceNumber. If that message (no longer) exists then no message will be returned.

    Expand
    titleResponse...
    FieldDetails
    generalInformation*Embedded General Information Block
    messages*
    Expand
    title...
    FieldDetails
    originalMessage*
    {

    ...

    }


    metaInformation*Embedded Meta Block

    6.3 Text message [TXT_MSG]

    The TXT_MSG is useful to convey notes or comments pertaining to a particular patient, donor, or patient/donor pair.

    ...

    Send (Post)Retrieve (Post)
    textMessageRequest

    textMessageRetrieve

    Expand
    titleRequest...
    Field

    Details

    requestingRegistryReferenceCoderequestId

    string
    maxLength: 1519
    example:XX12345
    nullable: true

    text*

    string
    nullable: true
    example: Would it be possible to also perform IDM test for SARS-CoV-23?

    Text. Message for a human at receiving registry.

    receivingRegistry*string
    maximum: 9999
    minimum: 0
    maxLength: 4
    minLength: 4
    example: 1234

    4 digit ION of the receiving registry

    patient*
    Expand
    title...
    FieldDetails
    wmdaId*

    integer
    nullable: false
    example: 1234

    ID provided by the WMDA

    Patient ID

    donor*Donor IDEmbedded Donor Block (donor in request)
    Expand
    titleResponse...
    FieldDetails
    wmdaResponsemetaInformation*Embedded WMDA Response Meta Block
    Expand
    titleRequest...
    limitinteger
    default: 100
    shouldPeekboolean
    default: false

    Set to true if you want messages to remain available after retrieval

    messageSequenceNumber

    integer
    e    xamplet: 12345

    Optional field to request a message with a specific messageSequenceNumber. If that message (no longer) exists then no message will be returned.

    Expand
    titleResponse...
    FieldDetails
    generalInformation*Embedded General Information Block
    messages*
    Expand
    title...
    FieldDetails
    originalMessage*
    {

    ...

    }


    metaInformation*Embedded Meta Block

    6.4 Alert message

    The Alert message is used to broadcast an important information about the system, like planned service outage. Messages are generated centrally by WMDA. Members are expected to display them to the users.

    ...

    SendRetrieve (Post)

    		AlertRetrieve
    Alerts can only be sent by the WMDA's central system
    Expand
    titleRequest...
    limitinteger
    default: 100
    shouldPeekboolean
    default: false

    Set to true if you want messages to remain available after retrieval

    messageSequenceNumber

    integer
    e    xamplet: 12345

    Optional field to request a message with a specific messageSequenceNumber. If that message (no longer) exists then no message will be returned.

    Expand
    titleResponse...
    string
    maxLength: 1024
    example: WMDA will do maintenance on SMC system on the weekend of 10 march
    FieldDetails
    generalInformation*Embedded General Information Block
    originalMessagemessages*
    Expand
    title...
    FieldDetails
    levelstring

    alert level. enums may change

    Enum:
    Array [ 3 ]
    statusstring

    check later

    Enum:
    Array [ 2 ]
    messageText
    originalMessage*

    ...

    metaInformation*Embedded Meta Block

    6.5 Alert Update message

    The Alert  Update message is used to broadcast an update about some previous alert. Messages are generated centrally by WMDA. Members are expected to display them to the users.

    ...

    SendRetrieve (Post)

    		AlertUpdateRetrieve
    Alert updates can only be sent by the WMDA's central system
    Expand
    titleRequest...
    limitinteger
    default: 100
    shouldPeekboolean
    default: false

    Set to true if you want messages to remain available after retrieval

    messageSequenceNumber

    integer
    e    xamplet: 12345

    Optional field to request a message with a specific messageSequenceNumber. If that message (no longer) exists then no message will be returned.

    Expand
    titleResponse...
    metaInformation
    FieldDetails
    generalInformation*Embedded General Information Block
    originalMessage*
    Expand
    title...
    FieldDetails
    alertReferenceIdentifierstring($uuid)
    levelstring

    alert level. enums may change

    Enum:
    Array [ 3 ]
    statusstring

    check later

    Enum:
    Array [ 2 ]
    messagestring
    maxLength: 1024
    example: WMDA will do maintenance on SMC system on the weekend of 10 march
    generalInformation*Embedded General Information Block
    messages*
    Expand
    title...
    FieldDetails
    originalMessage*

    ...

    metaInformation*Embedded Meta Block

    6.6 Available Messages

    This endpoint allows end users to retrieve an overview of all messages that are ready to be downloaded, including their corresponding sequence numbers. This information can be used to retrieve the messages from their respective *retrieve endpoints.
    The chronological order of processing If desired, the messages should can be arranged in the local system. This can be done by using the timestamps that are provided with the messages, as part of their meta information.pulled in chronological order, given by the sequence numbers. Each "retrieve" endpoint will have the optional parameter "sequenceNumber", that allows for an indivual collection of the corresponding message(s). If that parameter is left empty all available messages are retrieved (according to the limit set in the parameters). 

    GET
    availableMessages
    Expand
    titleResponse...
    FieldDetails
    totalMessages*integer
    example: 6
    Count of messages that are ready for retrieval
    messagesReadyForRetrieval*

    Array:

    attachment*integer
    Expand
    title...
    FieldDetails
    messageResponse

    Count integer, example: 6

    sequenceNumbers integer, List 1, 18


    alert*

    Count integer

    sequenceNumbers integer

    updatedPatient*

    Count integer

    sequenceNumbers integer

    ping*

    Count integer

    sequenceNumbers integer

    textMessage*

    Count integer

    sequenceNumbers integer

    genericRequest*

    Count integer

    example: 1

    sequenceNumbers integer

    extendedTypingRequest*

    Count integer

    example: 3

    sequenceNumbers integer

    typingResponse*

    Count integer

    sequenceNumbers integer

    sampleRequest*

    Count integer

    example: 2

    sequenceNumbers integer

    sampleInfo*

    Count integer

    sequenceNumbers integer

    sampleArrival*

    Count integer

    sequenceNumbers integer

    sampleResponse*

    Count integer

    sequenceNumbers integer

    infectiousDiseaseMarkerRequest*

    Count integer

    sequenceNumbers integer

    infectiousDiseaseMarkerResult*

    Count integer

    sequenceNumbers integer

    reservationRequest*

    Count integer

    sequenceNumbers integer

    reservationResponse*

    Count integer

    sequenceNumbers integer

    reservationRelease*

    Count integer

    sequenceNumbers integer

    requestCancellation*

    Count integer

    sequenceNumbers integer

    requestRejected*

    Count integer

    sequenceNumbers integer

    resultReminder*

    Count integer

    sequenceNumbers integer

    messageResponse
    cordBloodUnitReportRequest*

    Count integer

    cordBloodUnitReportRequest*

    sequenceNumbers integer

    cordBloodUnitReportResponse*

    Count integer

    sequenceNumbers integer

    6.7

    ...

    All Available Messages /* Proposed - not yet implemented */

    This endpoint allows end users to retrieve an array of all messages that are ready to be downloaded, including their content. This would allow a registry to call just one endpoint to collect all messages.

    Limitations:
    This option does not work for all applications/tooling, like defining custom API connectors in the 365 PowerPlatform. In those cases the same static structure for all call responses on a specific endpoint is not only IBP, but also required.

    Retrieve (Post)
    availableMessagesAll
    Expand
    titleRequest

    This endpoint allows end users to retrieve an overview of all messages that are ready to be downloaded, including their corresponding sequence numbers. This information can be used to retrieve the messages from their respective *retrieve endpoints. If desired, the messages can be pulled in chronological order, given by the sequence numbers. Each "retrieve" endpoint will have the optional parameter "sequenceNumber", that allows for an indivual collection of the corresponding message(s). If that parameter is left empty all available messages are retrieved (according to the limit set in the parameters). 

    GETavailableMessages2 Expand
    titleResponse...
    FieldDetailstotalMessages*integer
    example: 6
    Count of messages that are ready for retrieval
    messagesReadyForRetrieval* Expandtitle
    ...
    FieldDetails
    messageResponse
    limit
    Count
    integer
    ,

    default
    example
    :
    6

    sequenceNumbers integer, List 1, 18

    alert*

    Count integer

    sequenceNumbers integer

    updatedPatient*

    Count integer

    sequenceNumbers integer

    ping*

    Count integer

    sequenceNumbers integer

    textMessage*

    Count integer

    sequenceNumbers integer

    genericRequest*

    Count integer

    sequenceNumbers integer

    extendedTypingRequest*

    Count integer

    sequenceNumbers integer

    typingResponse*

    Count integer

    sequenceNumbers integer

    sampleRequest*

    Count integer

    sequenceNumbers integer

    sampleInfo*

    Count integer

    sequenceNumbers integer

    sampleArrival*

    Count integer

    sequenceNumbers integer

    sampleResponse*

    Count integer

    sequenceNumbers integer

    infectiousDiseaseMarkerRequest*

    Count integer

    sequenceNumbers integer

    infectiousDiseaseMarkerResult*

    Count integer

    sequenceNumbers integer

    reservationRequest*

    Count integer

    sequenceNumbers integer

    reservationResponse*

    Count integer

    sequenceNumbers integer

    reservationRelease*

    Count integer

    sequenceNumbers integer

    requestCancellation*

    Count integer

    sequenceNumbers integer

    requestRejected*

    Count integer

    sequenceNumbers integer

    resultReminder*

    Count integer

    sequenceNumbers integer

    cordBloodUnitReportRequest*

    Count integer

    sequenceNumbers integer

    cordBloodUnitReportResponse*

    Count integer

    sequenceNumbers integer

    6.7 Available Messages 3

    ...

    100
    shouldPeekboolean
    default: false

    Set to true if you want messages to remain available after retrieval

    Expand
    titleResponse...
    FieldDetails
    generalInformation*
    Expand
    title...
    FieldDetails
    limit*

    integer

    default: 100

    shouldPeek

    boolean

    default: false

    totalCount*

    integer

    minimum: 0
    example: 1

    remainingCount*

    integer

    minimum: 0

    isSuccessful*

    boolean

    default: true

    summary*

    string

    maxLength: 255
    example: 1 message retrieved sucessully. 0 remaining messages

    messages*
    Expand
    title...
    FieldDetails
    originalMessage*

    oneOf:

    alert
    ping
    textMessageRequest
    genericRequest
    extededTypingRequest
    typingResponse
    sampleRequest
    sampleArrival
    sampleInfo
    sampleResponse
    infectiousDiseaseMarker
    infectiousDiseaseMarkerResult
    reservationRequest
    reservationResponse
    reservationRelease
    requestCancellation
    requestRejected
    resultReminder
    cordBloodUnitReportRequest
    cordBloodUnitReportResponse

    metaInformation*

    {...}

    6.8 Recover Messages

    To recover or "restore" a soft-deleted message, users can call to the "recoverMessages" endpoint. This endpoint allows users to bring back messages that were soft-deleted within a 72 hour timeframe.

    This approach provides an additional safety measure for end users. In case a message was mistakenly deleted during the retrieval process, or if there is a need to recover soft-deleted data, this mechanism allows for data recovery without permanent loss.

    Users should be aware that the functionality to restore messages is limited to 72 hours. After this window, the soft-deleted messages are permanently removed from the system. Also see: section 2.4.7 Message storage retention policies in the Technical Guidelines chapter.

    GETavailableMessages3 Expand
    titleResponse...
    FieldDetailsgeneralInformation*
    Expand
    title...
    FieldDetails
    limit*

    integer

    default: 100

    shouldPeek

    boolean

    default: false

    totalCount*

    integer

    minimum: 0
    example: 1

    remainingCount*

    integer

    minimum: 0

    isSuccessful*

    boolean

    default: true

    summary*

    string

    maxLength: 255
    example: 1 message retrieved sucessully. 0 remaining messages

    messages* Expand
    title...
    FieldDetailsoriginalMessage*

    oneOf:

    alert
    ping
    textMessageRequest
    genericRequest
    extededTypingRequest
    typingResponse
    sampleRequest
    sampleArrival
    sampleInfo
    sampleResponse
    infectiousDiseaseMarker
    infectiousDiseaseMarkerResult
    reservationRequest
    reservationResponse
    reservationRelease
    requestCancellation
    requestRejected
    resultReminder
    cordBloodUnitReportRequest
    cordBloodUnitReportResponse

    metaInformation*{...}
    POST
    recoverMessages
    Expand
    titleRequest...
    FieldDetails
    messageSequenceNumber

    integer
    example: 12345

    Incrementing integer set by WMDA MatchConnect systems that indicates the order in which the messages were received by the WMDA and therefore the order in which messages should be processed. Each receiving registry has its own unique sequence.

    Expand
    titleResponse...
    FieldDetails
    isSuccessful (200 OK)boolean
    error (400 Bad Requst)

    string

    example: Bad request.