6 - Administration

• 26.1 Embedded Meta block
• 36.2 Embedded Address block
• 46.3 Embedded Patient Block
• 56.4 Embedded Donor Block
• 66.5 Message Response
• 76.6 Text message [TXT_MSG]
• 86.7 Alert message
• 96.8 Alert Update message

6.1 Embedded Meta block

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

• What registry sent the information (sender)
• What type of information is contained
• A message identifier
• A timestamp
• Any failed validations detected by the Match Connect system

metaInformation{

}

6.2 Embedded Address block

Original message: Address to broadcast [NEW_ADD]

With this message block, the contact information of the hub's institutions, namely Financial institutions, Transplant Centers and Laboratories are shared with the partner hubs. Thus a 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 delivery of samples. For the same reason ZIP code, City and Country are required in the address block.

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

Address block structure (HP's suggestion, requires discussion regarding the accreditation):

https://hapifhir.io/hapi-fhir/apidocs/hapi-fhir-structures-r4/org/hl7/fhir/r4/model/Address.html

• Institution Type INST_TYPE Req 3
• Institution Identification INST_ID Req 10
• Address Line 1 ADDR_1 Req 40
• Address Line 2 ADDR_2 Opt 40
• Address Line 3 ADDR_3 Opt 40
• Contact person PERSON Opt 40
• ZIP code ZIP Req 10
• City CITY Req 40
• Country COUNTRY Req 2
• Phone Number PHONE Req 20
• Fax Number FAX Opt 20
• Email address EMAIL Opt 60
• Accreditations obtained ACCREDITATION Opt 5
  • Position 1: NetCord-FACT
  • Position 2: AABB
  • Position 3: to be defined
  • Position 4: to be defined
  • Position 5: to be defined

6.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:

• Request

• Patient

  wmdaId*	integer nullable: false example: 1234 ID provided by the WMDA
  patientId*	string maxLength: 17 nullable: false example: P1234XX Organisation unique identifier for patient. Cannot be set unless "legalTerms" is set to "true". Do not use real names here.
  hla*	{...}
  idm	{...}
  dateOfBirth	string($date) nullable: true maxLength: 10 example: 1961-05-27
  diagnosis	{...}
  diseasePhase	string nullable: trueEnum: Array [ 48 ]
  ethnicity	string nullable: trueEnum: Array [ 20 ]
  poolCountryCode	string maxLength: 2 pattern: ^[A-Z]{2} nullable: true example: NL ISO 3166-1 alpha-2 Country Code (capitalized)
  abo	string nullable: trueEnum: Array [ 4 ]
  rhesus	string nullable: trueEnum: Array [ 2 ]
  weight	integer nullable: true minimum: 1 maximum: 999 example: 76
  sex	string nullable: trueEnum: Array [ 2 ]
  firstName	string maxLength: 30 nullable: true example: John First (given name) of the patient
  lastName	string maxLength: 30 nullable: true example: Doe Last (family name) of the patient

6.4 Embedded Donor Block

6.5 Message Response

The message response 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-to-machine type of message, as compared to EMDIS where such responses can be user generated. 

Note: The concept of the REF_CODE field used in EMDIS is replaced by the GUID assigned by the central system to each message. The Message Response is supposed to be using the GUID of the original message as the Reference ID in its structure.

Message structure:

6.6 Text message [TXT_MSG]

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

Note: Since Warnings are going to be automated, we must keep Text Messages as the only means for user communication left.

Message structure:

6.7 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.

Message structure:

6.8 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.

Message structure: