Versions Compared

Old Version 178

changes.mady.by.user Jan Hofmann

Saved on

compared with

New Version 179

changes.mady.by.user Rimke Postel

Saved on

Key

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

...

  • A patient registration embedded block is sent together with each request. This block contains both the wmdaId and the patientId of the patient.

  • Next to the actual request information, whenever the institutions are needed, they are sent explicitly as an Embedded Address Block.

  • (warning) The requested donor has to be reserved at the remote hub and reported back to the requesting registry by an embedded donor block with the donor status reflecting the change (a.k.a. DONOR_CB with D_STATUS = ”RS”).

  • All changes in the donors (change of status, updated typing, or IDMs) resulting from the requests are reported back in an embedded donor block. A separate update must be made to the Search & Match system with the updated donor data to ensure up-to-date master data. More information on how to do so may be found here.
  • ReferenceCode: In order to couple messages to the same request, e.g. Sample Request and its results, all messages following the initial request must have a referenceCode referenceMessageId as part of the message.

    • The message ID (correlationGuidreferenceMessageId) of the request message is used as the referenceCode reference code for the rest of the request related message flow.

  • Next to the technical ReferenceCode referenceMessageId requests might need a "requestTag" that , a human readable reference code (requestingRegistryReferenceCode) is used for end user recognition (communication outside the automated system)
    • The requestingRegistryReferenceCode is optional
    • The requestingRegistryReferenceCode is
    • that TAG will be part of the initial original message not the meta- block
    • it The requestingRegistryReferenceCode will be generated by the sending registry
    • it The requestingRegistryReferenceCode will only be only used for human human commnication communication (e.g. could be used on printed invoices)
    • should it be part of all requests? how about reservation request
    • needs discussion by Buisness group if it should be optional or mandatory 
  • Each field inherited from EMDIS Semantics contains a comment describing its purpose in EMDIS and its original name to assist in the transition from EMDIS to Match-Connect.
  • Paragraph Request + Response Flows depicts the new message flows.

...