You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 29 Next »



A register_patient message will be sent together with all requests. This message contains both wmdaId and patientId of the patient.

/post_api_v1_PatientRegistration

Provision of the donor ID in every request must be changed.

Current structure is:

donor*

{

description:

Supply one node from the following

gridstring
nullable: true

maxLength: 19

minLength: 19

example: 9991012070433202000
adcu

{

id*string
maxLength: 13

N/A in EMDIS

}

cbu

{

id*string
maxLength: 17

CBU Identification2 CB_ID Opt 17

}

}

ADCU and CBU have similar structure, but adult donor has the ID (GRID) right away.

Suggested structure for the adult donors:

scd or adult

{

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

}

5.0 - DONOR_CB message

It was agreed that we must implement DONOR_CB message API to preserve the original EMDIS logic. 

S&M APIs have the DONOR_CB message split into 

https://apispecs.wmda.info/?urls.primaryName=Search%20%26%20Match#/searches/retrieveFullReportDonors

and

https://apispecs.wmda.info/?urls.primaryName=Search%20%26%20Match#/searches/retrieveFullReportCBUs

In the future another message for ADCUs may come to play.

Proposal: change the Semantics by requesting an "updated donor" message instead of DONOR_CB.

  • WMDA will implement the endpoints to POST the mentioned reports for each donor type.
  • Participating registries will have to implement the above mentioned reports for both GET and POST (instead of DONOR_CB)
  • Here is the comparison of the DONOR_CB and the API endpoints: EMDIS vs API.xlsx

5.1 - Extended Typing Request

This message is used to request an extended typing of a donor (adult, adcu, cbu?). It will primarily contain information about what to type and for which donor.
Added to that a patient block (ref) containing up-to-date information about the patient, and an address block (6.1) containing up-to-date contact-information about the needed institution(s). 
Expected return message is 'typing result' (5.2) or 'request rejected' (5.14).
Check paragraph '5.16 Generic' and '5.16 Extended Typing' for the related message flows.

SendRetrieve
TypingRequestTypingRequestRetrieve
  • Donor 
  • Typing info
  • Patient Block
  • Address Block
  • Meta Block (ref?)
  • Donor
    • type (adult, adcu, cbu)
    • id (grid, id)
  • Typing info
    • requestDate
    • resolutionRequired
    • urgent
    • remark
  • Patient Block (ref?)
  • Address Block (6.1)

Rules

Intermediate resolution (M) translates to the non-high resolution.

The coding schema theoretically allows more combinations than the previous bitstring (e.g. non-high DRB1 typing). The actually valid combinations have to be published in the national rules of each registry. The local user interfaces will have to take care that no invalid or previously undefined requests are issued.

Combinations are possible, i.e. several loci may be requested in one message.

?Only one SMP_REQ can be open for a patient / donor pair (please see also the General section about duplicate requests).

Several distinct requests for the same patient / donor pair at a time are possible, for example, a DRB1 high and a class I DNA, but each request has to be answered by a TYP_RES message. It is not allowed to ”concatenate” / ”summarize” results in a single result message. Multiple typing requests for the same patient / donor pair have to be disjoint (i.e. may not contain the same locus or allele). The occurrence of multiple requests should be an exception. Usually, all loci or alleles required should be requested within one message. 

The appropriate action if the typing request cannot be accepted or has to be changed by the recipient, e.g. due to national rules, is to inform the requesting side what was done. If only the resolution was changed (the sender will receive something different than ordered - either more or less) or only a part of the requested loci were accepted (the sender will only receive parts of what was ordered): send a MSG_RSP containing the warning.

5.2 - Extended Typing Results

This message is used to send the results of the initial ET request back to the requesting registry. 
Check paragraph '5.16 Generic' and '5.16 Extended Typing' for the related message flows.

SendRetrieve
TypingResponseTypingResponseRetrieve
  • Extended Typing Result 
  • Donor Diff Block
  • Extenede Typing Result
    • patient (wmdaId)
    • referenceCode 
    • hlaNomenclatureVersion
    • etSampleType
    • remark
  • Meta Block (ref?)
  • Donor Diff  Block (ref)

Rules

After the TYP_RES message, a DONOR_CB with the updated donor data is mandatory to ensure up-to-date master data. See 4.0 above.

5.3 - Sample Request

The SampleRequestRequest (and SampleRequestRetrieve) is used to request a VT for a specific donor/product for a patient. The message, as all requests, has an embedded 'register_patient' part. Next to the actual request informations the institutions needed are sent explicitly as an embedded 'addressBlock' (6.1).

The message ID (correlationGUID) of this message will be used as 'referenceCode' for the rest of the request related message flow.

EMDIS Semantic:

Only one SMP_REQ can be open for a patient / donor pair (please see also the General section about duplicate requests).

The fields ”earliest and latest date of sample reception” represent the lower and upper limit of a period of time in which the blood sample has to be received. If the second date is missing the sample may be received any time after the first date.

The field ACC_DAYS is a binary field with position 1 corresponding to Monday and position 7 corresponding to Sunday. A set bit means acceptable day, an unset bit means not acceptable day. For example, 1110000 means acceptable days for reception are Monday, Tuesday and Wednesday, not acceptable days are Thursday, Friday, Saturday and Sunday. The default value is 1111100 (accept all working days).

The address INST_SMP_SENT must not be a P.O. box, since couriers often need a signature upon delivery.

The SMP_REQ is the only request message where the result also comes from the transplant centre.

The quantity for the first product is optional when requesting DNA from a cord blood unit. In all other requests, the quantity fields for any of the corresponding product fields are required if a product is requested.

Number of tubes requested in a sample request or marrow request:

The maximum amount of material, requested in one sample request or pre-collection sample request, is 100 ml, if not stated otherwise in the national rules. If the number of tubes is unassigned, not given in the request, the default value number of tubes is one.

Duplicate requests on the same day: This issue becomes particularly difficult if SMP_REQs are concerned - sometimes users want to ”correct” their previous request (i.e. forgot to request quantity and product). The correct way of doing this is to cancel the erroneous request first and send the second one later. However, this procedure might also confuse if not carried out on the same working day. In doubt a phone call helps sorting things out.


SendRetrieve
SampleRequestRequest (comments reffer to changes to the current API definition)SampleRequestRetrieve
  • Payload
    • patient (in form of an embedded register_patient block)
    • donor (format change see above)
    • referenceCode (not needed anymore see text above)
    • requestDate
    • prod1
    • prod2
    • prod3
    • prod4
    • receptionDate1
    • receptionDate2
    • acceptableReceptionDaysOfWeek
    • institutionToSendSampleTo (as embedded addressBlock)
    • institutionPaying (as embedded addressBlock)
    • urgent
    • acknowledgementId (not needed anymore → MSG_RSP)
    • remark
  • MetaInformation
  • Payload
    • patient (in form of an embedded register_patient block)
    • donor (format change see above)
    • referenceCode (not needed anymore see text above)
    • requestDate
    • prod1
    • prod2
    • prod3
    • prod4
    • receptionDate1
    • receptionDate2
    • acceptableReceptionDaysOfWeek
    • institutionToSendSampleTo (as embedded addressBlock)
    • institutionPaying (as embedded addressBlock)
    • urgent
    • acknowledgementId (not needed anymore → MSG_RSP)
    • remark

5.4 - Sample Information

The SampleInfoRequest (and SampleInfoRetrieve) is used to sent relevant secondary information which may arise in the context of sample request.

The referenceCode is teh 'massageId' from the request message.

EMDIS Semantic:

The SMP_INFO message can only be exchanged in one direction: from donor side to patient side.

Sample information is always referencing a sample request.

Sample information is only valid as long as the referenced sample request is considered as ”open” or the donor is reserved for this patient after the sample request.

A request is considered as ”open” as long as the searching registry has neither reported the sample result nor a ”service cannot be performed (NO_RES)” information nor a request cancellation.

There might be several sample information messages within the context of one sample request. Subsequent sample information is regarded as new or additional information and not as updates.


SendRetrieve
SampleInfoRequest (comments reffer to changes to the current API definition)SampleInfoRetrieve
  • Payload
    • patient (just the wmdaID)
    • donor (format change see above)
    • referenceCode (see text above)
    • informationType
    • remark
  • MetaInformation
  • Payload
    • patient (just the wmdaID)
    • donor (format change see above)
    • referenceCode (see text above)
    • informationType
    • remark

5.5 - Sample Arrival

The SampleArrivalRequest (and SampleArrivalRetrieve) is used to transmit proposed date of sample arrival.

The message ID (correlationGUID) of this message will be used as 'referenceCode' for the rest of the request related message flow.

EMDIS Semantic:

This message is sent in response to a SMP_REQ and indicates the arrival date of the sample.


SendRetrieve
SampleArrivalRequest (comments reffer to changes to the current API definition)SampleArrivalRetrieve
  • Payload
    • patient (just the wmdaID)
    • donor (format change see above)
    • referenceCode (see text above)
    • arrivalDate
    • collectionDate
    • acknowledgementId (not needed anymore → MSG_RSP)
    • labelId (is there a usecase for this ID, where it is not the donor ID?)
    • aampleType (missing: was this field dropped by purpose?)
    • remark
  • MetaInformation
  • Payload
    • patient (just the wmdaID)
    • donor (format change see above)
    • referenceCode (see text above)
    • arrivalDate
    • collectionDate
    • acknowledgementId (not needed anymore → MSG_RSP)
    • labelId (is there a usecase for this ID, where it is not the donor ID?)
    • aampleType (missing: was this field dropped by purpose?)
    • remark

5.6 - Sample Results


The SampleRequestRequest (and SampleRequestRetrieve) is used to request a VT for a specific donor/product for a patient. The message, as all requests, has an embedded 'register_patient' part. Next to the actual request informations the institutions needed are sent explicitly as an embedded 'addressBlock' (6.1).

The message ID (correlationGUID) of this message will be used as 'referenceCode' for the rest of the request related message flow.

SendRetrieve
SampleResponseRequest (comments reffer to changes to the current API definition)SampleRequestRetrieve
  • patient (in form of an embedded register_patient block)
  • donor (format change see above)
  • referenceCode (not needed anymore see text above)
  • requestDate
  • prod1
  • prod2
  • prod3
  • prod4
  • receptionDate1
  • receptionDate2
  • acceptableReceptionDaysOfWeek
  • institutionToSendSampleTo (as embedded addressBlock)
  • institutionPaying (as embedded addressBlock)
  • urgent
  • acknowledgementId (not needed anymore → MSG_RSP)
  • remark
  • MetaInformation
  • Payload
    • patient (in form of an embedded register_patient block)
    • donor (format change see above)
    • referenceCode (not needed anymore see text above)
    • requestDate
    • prod1
    • prod2
    • prod3
    • prod4
    • receptionDate1
    • receptionDate2
    • acceptableReceptionDaysOfWeek
    • institutionToSendSampleTo (as embedded addressBlock)
    • institutionPaying (as embedded addressBlock)
    • urgent
    • acknowledgementId (not needed anymore → MSG_RSP)
    • remark

5.7 - Infectious Disease Marker Request

This message is used to request infectious disease marker test results of the selected donor. Expected return message is 'idm result' (5.8) or 'request rejected' (5.14).

SendRetrieve
InfectiousDiseaseMarkerRequestInfectiousDiseaseMarkerRequestRetrieve
  • Donor 
  • IDM info
  • Patient Block
  • Address Block
  • Meta Block (ref?)
  • Donor
    • type (adult, adcu, cbu)
    • id (grid, id)
  • IDM info
    • requestDate
    • marker
    • remark
  • Patient Block (ref?)
  • Address Block (6.1)

Rules

Several distinct requests for the same patient / donor pair at a time are possible, for example, a verification typing and a CMV status, but each request has to be answered by an individual IDM_RES, i.e. results must not be ”concatenated” to a single result message. Multiple IDM requests for the same patient / donor pair have to be disjoint (i.e. may not contain identical markers). The occurrence of multiple requests should be an exception. Usually, all markers required should be requested within one message. 

5.8 - Infectious Disease Marker Results

Needed

https://apispecs.wmda.info/?urls.primaryName=Connect%20API#/Message/post_api_v1_InfectiousDiseaseMarkerResultRequest

After the IDM_RES message, a DONOR_CB with the updated donor data is mandatory to ensure up-to-date master data. See 4.0 above.

5.9 - Reservation Request

Needed

https://apispecs.wmda.info/?urls.primaryName=Connect%20API#/Message/post_api_v1_ReservationRequestRequest

5.10 - Reservation Result

Needed

https://apispecs.wmda.info/?urls.primaryName=Connect%20API#/Message/post_api_v1_ReservationResultRequest

After the RSV_RES message a DONOR_CB with the updated donor status is mandatory to reflect the change. See 4.0 above.

5.11 - Workup Request

Future Phase

5.12 - Workup Status

Future Phase

5.13 - Request Cancellation

Needed

https://apispecs.wmda.info/?urls.primaryName=Connect%20API#/Message/post_api_v1_RequestCancellationRequest

5.14 - Request Rejected (NO_RES)

Needed

https://apispecs.wmda.info/?urls.primaryName=Connect%20API#/Message/post_api_v1_NoResultRequest

If the results cannot be delivered, a NO_RES message followed by a DONOR_CB message is returned which includes the new donor status. See 4.0 above.

5.15 - Result Reminder (RES_REM)

Needed

https://apispecs.wmda.info/?urls.primaryName=Connect%20API#/Message/post_api_v1_ResultReminderRequest

5.16 Request + Response Flows

Generic 

Extended Typing 

Infectious Disease Marker


  • No labels