Close
Search

Change log OML/ORM LFDv2 vs OML/ORM V3

Important note:

This is a draft specification. Together with a few XIS vendors, we will run pilot implementations of the new ORM/OML V3 messages at a small number of customers. As soon a these pilot implementations have proven to be successful, the ORM V3 and OML V3 messages will be released as the preferent HL7 messages. If you would like to participate in this pilot please contact us.

Introduction

Using an interface with ZorgDomein based on HL7v2 messages a XIS can receive and process requests for diagnostic research automatically. ZorgDomein currently supports OML en ORM messages for these communication flows. The last major revision of these messages was in 2016. Since that moment ZorgDomein has implemented many improvements and adjustments to its order module. Additionally, several customers and XIS vendors have suggested improvements for the implementation of the ORM and OML messages. Therefore, ZorgDomein has composed a new specification for the ORM and OML messages that implements most of these improvements and suggestions. This new specification is based on the existing OML LFDv2 and ORM LFDv2 message specifications. The new ORM and OML messages are based on HL7 v2.5.1 and stick to the existing trigger events (note that the ORM message is upgraded from HL7 v2.4 to v2.5.1):

  • OML: OML_O21 - Laboratory Order
  • ORM: ORM_O01 - Order message

This page lists the changes that have been applied to the original LFDv2 messages.

Change 1: Include details of problem-based test groups for all tests

ZorgDomein offers the ability to group multiple tests in a problem-based test group (“probleemgestuurd pakket”). Each test in this test group can be either required, recommended or optional. The details of this test group (test group name and code) are only supplied in the LFDv2 messages if all tests within the group are required, using a separate ORC-OBR combination for the group and omitting ORC-OBR combinations for the individual tests. This has appeared to cause problems if the test group codes are required for processing tests groups that have optional tests. Therefore, the new ORM and OML messages will always include the test group details, no matter if the included tests are required or not. Each test group will be included in the new messages with an individual ORC-OBR combination, containing the details of the test group in the following fields:

  • OBR-4.1: Code of diagnostic test group.
  • OBR-4.2: Name of diagnostic test group.
  • OBR-4.3: If OBR-4.1 contains a local code: “L”.
    Else: Global standard code (see table 0396 of the international HL7 V2.5.1 specifications).

Additionally, the selected tests for a problem based test group are included as OBX-segments under the ORC-OBR combination of the test group (regardless of the question if it concerns a required test or not):

  • OBX-1: Sequence number unique within the combination of respective ORC, OBR, and OBX segments. Initial value: “1”.
  • OBX-2: Fixed value: “CE”.
  • OBX-3.1: Fixed value: “REQUESTED_TESTS”
  • OBX-3.2: Fixed value: “Aangevraagde onderzoeken”.
  • OBX-3.3: Fixed value: “L”.
  • OBX-4: Sequence number of included test (identical to OBX-1).
  • OBX-5.1: Code of included diagnostic test.
  • OBX-5.2: Name of included diagnostic test.
  • OBX-5.3: If OBX-3.1 contains a local code: “L”.
    Else: Global standard code (see table 0396 of the international HL7 V2.5.1 specifications).
  • OBX-11: Fixed value: “O”.

Change 2: Always include all tests

ZorgDomein offers the ability to group multiple tests in a problem-based test group (“probleemgestuurd pakket”). Each test in this test group can be either required, recommended or optional. The details of this test group (test group name and code) are only supplied in the LFDv2 messages if all tests within the group are required, using a separate ORC-OBR combination for the group and omitting ORC-OBR combinations for the individual tests. This is problematic when sending MMB orders where a test groups contains tests based on different materials. When all tests within this group are required, the HL7 message would contain only one ORC segment, which leaves no room for specifying different specimen and relating them to the individual tests. Additionally, this approach may cause problems in scenario’s where the individual test codes are required for processing the request. Therefore, the new messages will always contain an individual ORC-OBR combination for all requested tests, even if they are part of a test group that consist only of required tests.

Change 3: Requester’s address- and contact details

The new messages will contain the address and contact details of the requester and his/her location.

Address details of the requester’s location:

  • ORC-22.1.1: Combination of 22.1.2, 22.1.3, 22.2
  • ORC-22.1.2: The street name of the placer’s location.
  • ORC-22.1.3: The dwelling number of the placer’s location.
  • ORC-22.2: The other designation of the placer’s location.
  • ORC-22.3: The city name of the placer’s location.
  • ORC-22.5: The postal code of the placer’s location.
  • ORC-22.6: The country code of the placer’s location.

Requester’s contact details:

  • Phone number:
    • ORC-23.1: Phone number of the placer’s location.
    • ORC-23.2: “WPN”
    • ORC-23.3: “PH”
  • Fax-number:
    • ORC-23.1: Fax number of the placer’s location.
    • ORC-23.2: “WPN”
    • ORC-23.3: “FX”

Change 4: AGB-code of the requester’s location

The new messages will contain the AGB-code of the requester’s location in ORC-13.10. In the LFDv2 messages, ORC-13 is used for the requester’s organization name and AGB-code, and the name of the requester’s location. That implies that this field contains both details about the organization and location, which is not very consistent, especially given the fact that the organization details are also available in ORC-17. Therefore, ORC-13 will only be used for details about the requester’s location in the new messages:

  • ORC-13.9: Name of the acting referrer’s location.
  • ORC-13.10.1: AGB-code of the acting referrer’s location.
  • ORC-13.10.2: “VEKTIS”

Change 5: More details about the intended recipient of a copy of the test result

In a request form in ZorgDomein, a requester can specify the details of a person who should receive a copy of the test results. The LFDv2 messages only specify the last name and AGB-code of this person. It appears that these details are not always entered correctly by the requester; especially the AGB-code is missing in most cases. To make these details more specific, in the near future the new messages will also contain the initials, name of the related organization and the specialism of that person:

  • OBR-28.1: AGB-code of person to send copy to as entered by the acting referrer.
  • OBR-28.2.1: Full surname of person to send copy to as entered by the acting referrer.
  • OBR-28.3 (reserved for future use): Initials of person to send copy to as entered by the acting referrer.
  • OBR-28.9.1: If OBR-28.1 contains a value: “VEKTIS”.
  • OBR-28.16.2 (reserved for future use): Organization name to send copy to as entered by the acting referrer.
  • OBR-28.21 (reserved for future use): Specialism of person to send copy to as entered by the acting referrer.

NB: OBR-28 is explicitly intended for the details of persons who should receive a copy of the test results, but the data type XCN offers no components to specify details of the related organization. The specification above uses OBR-28.16 (“Name Context”) for this detail. Strict interpretations of the HL7 specifications might consider this abuse of the component, although the use of that component is not defined very explicitly.

Change 6: Collect location name

In some request or collect forms in ZorgDomein the name of the collect location can be entered if a sample has been collected from the patient. The new messages will contain the collect location name in OBR-10.16.2. OBR-10.16 actually only offers room for person details (not for organization or location details), but a better solution is not available.

Change 7: Improved specimen details

ZorgDomein has recently improved the possibilities for specifying specimen details for in request forms for lab research (especially relevant for medical microbiology). The LFDv2 messages contain the specimen details as OBX-segments (and in some cases SPM-4), while both the OML and ORM messages offer better solutions for this. This concerns the following specimen details:

  • Specimen material: name and code
  • Specimen source site: name and code
  • Specimen laterality: name and code
  • Specimen collection method: name and code
  • Collected specimen count
  • Research method: name (this detail is only used for request for medical microbiology)

Implementation in OML-message

  • Material (contained in both the SPM and OBR segments):
    • In SPM-segment:
      • SPM-4.1: Code of the specimen source material
      • SPM-4.2: Name of the specimen source material
      • SPM-4.3: If SPM-4.1 contains a local code: “L”.
        Else if SPM-4.1 contains a HL7 standard code: “HL70487”.
        Else: Global standard code (see table 0396 of the international HL7 V2.5.1 specifications).
    • In OBR-segment:
      • OBR-15.1.1: Code of the specimen source material
      • OBR-15.1.2: Name of the specimen source material
      • OBR-15.1.3: If OBR-15.1.1 contains a local code: “L”.
        Else if OBR-15.1.1 contains a HL7 standard code: “HL70487”.
        Else: Global standard code (see table 0396 of the international HL7 V2.5.1 specifications).
  • Specimen source site (contained in both the SPM and OBR segments):
    • In SPM-segment:
      • SPM-8.1: Code of the specimen source site
      • SPM-8.2: Name of the specimen source site
      • SPM-8.3: If SPM-8.1 contains a local code: “L”.
        Else: Global standard code (see table 0396 of the international HL7 V2.5.1 specifications).
    • In OBR-segment:
      • OBR-15.4.1: Code of the specimen source site
      • OBR-15.4.2: Name of the specimen source site
      • OBR-15.4.3: If OBR-15.4.1 contains a local code: “L”.
        Else: Global standard code (see table 0396 of the international HL7 V2.5.1 specifications).
  • Laterality (contained in both the SPM and OBR segments):
    • In SPM-segment:
      • SPM-9.1: Code of the specimen source site modifier
      • SPM-9.2: Name of the specimen source site modifier
      • SPM-9.3: If SPM-9.1 contains a local code: “L”.
        Else: Global standard code (see table 0396 of the international HL7 V2.5.1 specifications).
    • In OBR-segment:
      • OBR-15.5.1: Code of the specimen source site modifier
      • OBR-15.5.2: Name of the specimen source site modifier
      • OBR-15.5.3: If OBR-15.5.1 contains a local code: “L”.
        Else: Global standard code (see table 0396 of the international HL7 V2.5.1 specifications).
  • Specimen collection method: (contained in both the SPM and OBR segments):
    • In SPM-segment:
      • SPM-7.1: Code of the specimen collection method
      • SPM-7.2: Name of the specimen collection method
      • SPM-7.3: If SPM-7.1 contains a local code: “L”.
        Else if SPM-7.1 contains a HL7 standard code: “HL70488”.
        Else: Global standard code (see table 0396 of the international HL7 V2.5.1 specifications).
    • In OBR-segment:
      • OBR-15.3: Name of the specimen collection method
  • Collected specimen count: SPM-13
  • Research method: The OML message does not offer a place for this detail. Since it does not concern an observation about the test (which would make a case for an OBX-segment), but rather an annotation for the test, an NTE-segment on OBR-level is the best solution.
    • NTE-1: Sequence number unique for NTE segment. Initial value: “1”.
    • NTE-2: Fixed value: “P”
    • NTE-3: Name of research method
    • NTE-4.1: Fixed value: “RESEARCH_METHOD”
    • NTE-4.2: Fixed value: “Onderzoeksmethode”
    • NTE-4.3: Fixed value: “L”

Implementation in ORM-message

  • Material:
    • OBR-15.1.1: Code of the specimen source material
    • OBR-15.1.2: Name of the specimen source material
    • OBR-15.1.3: If OBR-15.1.1 contains a local code: “L”.
      Else if OBR-15.1.1 contains a HL7 standard code: “HL70487”.
      Else: Global standard code (see table 0396 of the international HL7 V2.5.1 specifications).
  • Specimen source site:
    • OBR-15.4.1: Code of the specimen source site
    • OBR-15.4.2: Name of the specimen source site
    • OBR-15.4.3: If OBR-15.4.1 contains a local code: “L”.
      Else: Global standard code (see table 0396 of the international HL7 V2.5.1 specifications).
  • Laterality:
    • OBR-15.5.1: Code of the specimen source site modifier
    • OBR-15.5.2: Name of the specimen source site modifier
    • OBR-15.5.3: If OBR-15.5.1 contains a local code: “L”.
      Else: Global standard code (see table 0396 of the international HL7 V2.5.1 specifications).
  • Specimen collection method: OBR-15.3
  • Collected specimen count: OBX segment on order (OBR) level:
    • OBX-1: Sequence number unique within the combination of respective ORC, OBR, and OBX segments. Initial value: “1”.
    • OBX-2: “NM”
    • OBX-3.1: “SPM_COUNT_[ContainerTypeCode]”
    • OBX-3.2: “Aantal weefselstukjes”
    • OBX-3.3: “L”
    • OBX-5: Collected specimen count
  • Research method: NTE-segment on order (OBR) level (identical to the OML message)

Change 8: Sub request identifier

When a request for diagnostic research is submitted, ZorgDomein may split the request into multiple parts, yielding multiple HL7 messages. Each sub request has a unique identifier which consists of the ZD-number plus a suffix. The patient message will contain this identifier as a bar code. This identifier is missing in the LFDv2 messages, which can cause problems when scanning the bar code on the patient message in order to retrieve the order from the information system. The new messages will contain the identifier of the sub request in ORC-4.

NB: The LFDv2 messages contain the ZD-number of the overarching request in ORC-4. This ZD-number will not be present on order level in the new messages. This ZD-number remains available as a patient visit number in PID-3 (just as it is in the LFDv2 messages).

Change 9: Receiving cluster details

The messages sent by ZorgDomein are always sent to a so called “cluster” in ZorgDomein (a cluster can be considered as an organizational unit). The new messages will contain the details of this cluster to enable the recipient of a message to process this detail if that is required. The cluster name is supplied in an NTE-segment on MSH level:

  • NTE-1: Sequence number unique for NTE segment. Initial value: “1”.
  • NTE-2: Fixed value: “P”
  • NTE-3: ZorgDomein cluster name
  • NTE-4.1: Fixed value: “ZD_CLUSTER_NAME”
  • NTE-4.2: Fixed value: “ZorgDomein clusternaam”
  • NTE-4.3: Fixed value: “L”

A ZorgDomein request form for diagnostic research can contain several questions that ask for additional details regarding the requested research or the patient. The questions can be divided in two categories:

  • General questions that apply to the request as a whole.
  • Specific questions that only apply to one or more selected examinations/tests.

The LFDv2 messages repeat the answers to all questions for each selected examinations/test as OBX segments under each ORC-OBR combination. This may cause unwanted duplication of OBX segments, and therefore unwanted duplication of data.
To solve this problem, the new messages will include an additional ORC-OBR combination that represents the request as a whole (i.e. the ZorgDomein healthcare product) where all general questions that apply to that request are listed as OBX segments under the corresponding ORC-OBR combination. These OBX-segments will no longer be repeated under the ORC-OBR combinations of the individual examinations/tests. This additional ORC-OBR combination that represents the healthcare product will always be the first order in the order section of the message and it will contain the details of the healthcare product as follows:

  • OBR-4.1: Code of healthcare product.
  • OBR-4.2: Name of healthcare product.
  • OBR-4.3: If OBR-4.1 contains a local code: “L”.
    Else: Global standard code (see table 0396 of the international HL7 V2.5.1 specifications).

Change 11: Logistic blood sampling details for in-patients

A ZorgDomein request form for lab research offers a requester the ability to indicate that a patient is an in-patient and that blood has to be collected at a specific in-patient location, i.e. healthcare organization, department and/or room number. These details are supplied as OBX-segments for all selected tests in the LFDv2 messages. In the future the new messages will contain these details in the PV1-segment:

  • PV1-3.1 (reserved for future use): Name of the department where the patient is located
  • PV1-3.2 (reserved for future use): Number of the room where the patient is located
  • PV1-3.6 (reserved for future use): Fixed value “D”
  • PV1-3.9 (reserved for future use): Full description of the patient location, including the name of the healthcare organization, department and/or room number.

Change 12: Change in coding system names

In the LFDv2 messages, data that is supplied using a coded data type (mostly using the Coded Element data type) is assigned a coding system name of “99zda” or “99zdl” if it concerns a non-standardized code. These coding system names have appeared to cause problems in many implementations. Therefore, only the value “L” will be used in the new messages as a coding system name for coded data that does not use standardized codes.

Change 13: Multiple choice questions

For each diagnostic research or test that is selected in the ZorgDomein request form, the form may include one or more questions that are related to the selected research or test. Some of these questions may be multiple choice. The LFDv2 messages supported multiple answers to a multiple choice question by repeating the OBX-5 field. Although OBX-5 is a repeatable field according to the international HL7 specifications, support for this feature by the XIS’es has appeared to be limited. To eliminate this compatibility issue, the new messages will contain multiple answers on multiple choice questions by repeating the full OBX segment for each selected answer. Each answer will have an incremental index number in OBX-4, starting with the number “1” for the first answer.

Change 14: Multiple patient addresses

Some ZorgDomein requests forms for lab research offer a requester the ability to provide a home visit address for cases where blood has to be collected at a patient’s home. This address will be supplied as an extra patient address in PID-11 (PID-11.7 = “C”) in addition to the mailing address that is always supplied in PID-11 (PID-11.7 = “M”).

Change 15: List with added attachments

For some request forms, ZorgDomein offers the requester the ability to add attachments to the request form. These attachments may be sent in a separate HL7 message (the specs of this message is beyond the scope of the new messages). To make the presence of potential attachments more explicit, the new messages will contain a list of added attachments in an NTE-segment on MSH level.

  • NTE-1: Sequence number unique for NTE segment. Initial value: “1”.
  • NTE-2: fixed value: “P”
  • NTE-3: Summary of attached files (file name, extension and size)
  • NTE-4.1: “ATTACHMENTS”
  • NTE-4.2: “Toegevoegde bijlagen”
  • NTE-4.3: “L”

Change 16: Additional collection details

A ZorgDomein request form for lab research may offer a requester the ability to specify additional details regarding the collected specimen. The OML LFDv2 messages already contain some data about the collector and the collection date and time. The ORM V3 message will now also include these details: 

  • OBR-10.1: The collect employee’s ZorgDomein health care provider ID or AGB-code.
  • OBR-10.2.1: The collect employee’s full surname.
  • OBR-10.3: The collect employee’s initials.
  • OBR-10.9.1: If OBR-10.1 contains a value: “L” or “VEKTIS”.
  • OBR-10.16.2: Name of the collect location.
  • OBR-39.2: The collect employee’s comment.

The new messages will also include the following additional collection details:

  • Container barcode
  • Indicator for the availability of collection details

The new message will contain these details as follows:

  • Container barcode:
    • OML: SPM-2.1.1.
    • ORM: separate OBX:
      • OBX-1: Sequence number unique within the combination of respective ORC, OBR, and OBX segments. Initial value: “1”.
      • OBX-2: “ST”
      • OBX-3.1: “BARCODE_[ContainerTypeCode]”
      • OBX-3.2: Label of question for barcode (subjected to change)
      • OBX-3.3: “L”
      • OBX-5: container barcode
  • Indicator for the availability of collection details: SPM-20 (only OML). This field will have the value “Y” if the material has been collected, and the message contains collection details. If no specimens have been collected, and the message does not contain any collection details, the field will have the value “N”.

Additionally, the specification of the container type will move to SPM-27:

  • SPM-27.1: code of container type
  • SPM-27.2: name of container type
  • SPM-27.3: “L”

Change 17: Request priority

A ZorgDomein request form for diagnostic research may offer a requester the ability to specify the priority of the request. The new messages will contain the request priority as follows:

  • OML:
    • ORC-7.6: Priority code conform table 0485
    • TQ1-9:
      • TQ1-9.1: Priority code conform table 0485
      • TQ1-9.2: Priority label conform table 0485
      • TQ1-9.3: “HL70485”
  • ORM:
    • ORC-7.6: Priority code conform table 0485

NB: In the LFDv2 messages the priority code “S” was used if the acting referrer wishes the results to be called in or faxed; in the new V3 messages the priority code “C” will be used for this scenario.

Change 18: Unique and persistent placer order number

In the ORM LFDv2 message the placer order number in ORC-2.1 and OBR-2.1 is not unique: its value is equal to the ZD-number for all ORC-OBR combinations. Additionally, the placer order numbers in the OML LFDv2 and ORM LFDv2 are not persisent (placer order numbers of orders in an update message could differ from the placer order numbers of the corresponding orders in the initial message). In the ORM V3 and OML V3 messages the placer order numbers will be a unique and persistent string composed of 10-20 alphanumeric characters. 

Change 19: Time span for specimen collection

The OML LFDv2 message only supports one timestamp for specimen collection (TQ1-7.1). The new OML V3 message will support both a desired start (TQ1-7.1) and end date (TQ1-8.1) for specimen collection. This effectively enables the placer to define a desired time span for specimen collection.