Scenario 68 - Request Testing Services from Third Party Lab

68.0 Overview

Scenario #67 describes the integration of business software involved with the process of a customer requesting a third party laboratory to perform lab tests on customer provided samples. The request is made via an InspectionOrder and the results of the testing are conveyed to the customer using TestResults. The process through which the customer queries the laboratory about available testing services and their prices to gather the information to properly create an InspectionOrder and the process through which the laboratory invoices the customer for the testing services performed are also illustrated in this scenario using PriceList and Invoice, respectively.

The purpose of this scenario is to describe the participants in a mainstream business process, and to illustrate how the business systems of those participants can be integrated through messages exchange to realize the goals of that business process. This scenario is not meant to be the only model for integrating customer applications to lab information management applications. It is simply one model that may be used to guide one’s own integration efforts.

Since the function and composition of the business software components that might be used to produce or exchange the information described in the scenario vary widely, specific software components will not be described. Software components which might be involved in realizing this scenario include:

  • Purchasing / Procurement Systems
  • Lab Information Management Systems
  • Enterprise Resource Planning / Customer Relationship Management Systems
  • Order Management System

This is not a complete list but is meant to be a representative sample of systems that might be involved in generation or exchange of the information involved in the Request Testing Services from Third Party Lab process.

68.1 Scenario Diagram

The scenario below contains the participants involved in the interaction, the dialog flows or conversation between them, certain assumptions about the sequence of events, and assumptions about the technical approach, for example, whether a publish and subscribe or a query and response model is used for the exchange of information. This is a model to be used as a design recommendation, not a required approach.

This is a model to be used as a design recommendation, not a required approach..

68.2 Assumptions

This scenario assumes a loosely coupled, asynchronous approach with transaction management required but not explicitly defined.

This scenario describes how one or more components of a Customer�s business systems can interact with one or more of the business systems of a Third Party Laboratory for testing services.

The creation of samples labeled in accordance with the associated InspectionOrder is required but not depicted. The manual exchange, from the Customer to the Third Party Laboratory, of the labeled samples upon which testing is to be performed is required but not depicted.

There may be instances where all of the data necessary to accomplish the business goal is contained in the documents and other instances where additional binary information accompanies the InspectionOrder, TestResults, and/or PriceList documents.

This scenario presents two methods through which the TestResults noun is transmitted from the Third Party Laboratory to the Customer. One method follows a Notify-Get-Show pattern of interaction, where the customer receives a notification message when results are available and then submits a requests for the results which are subsequently returned. In the other method, when initial, updated, or final results are available, the laboratory sends them directly to the customer without prompting until all results have been transmitted. Both methods are described in this scenario document. Neither method is required and implementations of this scenario are free to support either or both methods.

This scenario covers approaches for the exchange of information related to the availability and cost of testing services. They are included to provide a complete illustration of the overall business process and to provide context for the focus of the scenario � the part of the business process that involves the exchange of messages to support the request for and performance of testing services. The approaches depicted in this scenario for supplying this functionality are not required. Implementers may choose to adopt these integration approaches or to provide the functionality through other means.

68.3 Participant Definitions

This scenario contains two major components: business operations and manufacturing operations. Business Operations participants are Inventory Management, Quality Management, Production Planning. Manufacturing operations also includes the Lab Management. The definitions and details of these applications are left to the designer but are assumed to contain the functionality as defined by what is commonly sold in the commercial marketplace today. This definition is broadly accepted by the scenario designers and is a direct result of the decision not to define how the processing takes place within any individual application. Typical capabilities of these participants are described:

  • Customer is the participant that requests the testing services
  • The Third Party Lab participant uses an application often referred to a Lab Information Management Systems (LIMS). The LIMS will manage testing services, and collect data off test instruments

Each application must be able perform the services defined by the message BOD (business object document), but the internals of the application are not required or desired to be exposed at this level of standardized abstraction.

The most important factors in defining these participants is to ensure that an integration designer can communicate the requirements precisely enough to specify and design the integration processes needed and their interrelationships.

Note that the evolution of eCommerce has yielded independent trading exchanges and other intermediaries between business operations and inventory management providers. Requirements and operations for intermediaries should be similar to direct links between the two components

68.4 Business Workflow (Sequence)

The business workflow is graphically represented by starting at the Scenario top and reading from top down and from left to right. The arrows in a sequence diagrams shows the message exchanged, and the response to the message. A ConfirmBOD provides an acknowledge to the initial request that the original request was received and understood as a valid. The Acknowledge(noun) message indicates that the transaction was processed (committed), and a business person has reviewed and provided information related to the next step (accepted, rejected, etc.).

The exchange of OAGIS BODs such as the InspectionOrder and TestResults may follow several different workflows depending on the capabilities of the customer submitting the InspectionOrder. The sequence diagram illustrates the data exchanges involved within the business process.

  1. The first business event in the integration scenario is the request for the Customer-specific Price list using the GetPriceList and ShowPriceList BODs.
  2. In second business event the Customer sends the ProcessInspectionOrder BOD to the laboratory, which identifies the samples and tests to be performed on each sample. The Customer manually sends the physical samples to the lab.
  3. Upon receipt of the samples, the LIMS system sends the AcknowledgeInspectionOrder BOD to the Customer. The Lab prepares the (sub)samples (physical movement of samples out of scope for this scenario).
  4. After all tests are performed according to referenced test methods, in implementation approach #1, the NotifyTestResults BOD is sent to the Customer, indicating the availability of the test results.
  5. The Customer uses information in the NotifyTestResults payload to query the Lab using the GetTestResults BOD.
  6. The ShowTestResults BOD is returned to the Customer as a result of the query.

The alternate sequence involves direct publishing the TestResults to the Customer, starting with step #3:

  1. After all tests are performed according to referenced test methods, in implementation approach #1, the ProcessTestResults BOD is send to the Customer.
  2. The Customer responds to the lab they have transacted the test results with the AcknowledgeTestResults BOD.
  3. If test methods take longer to process (e.g., weeks), an updated set of test results can be sent by the lab to the customer using the ChangeTestResults BOD.
  4. In this case, the Customer sends the ChangeAcknowledgeTestResults BOD when that data is processed.

Retests are not shown in this scenario, but are another potential use case, most often requiring a new ProcessInspectionOrder BOD (not a change).

What is not shown in the diagram are the instructions related to the physical movement of the samples to the laboratory or the movement of product from its staging location into inventory. This activity may involve additional logistics related messages that are covered within other OAGIS Scenarios, especially if Inventory Management is a third party (e.g., 3PL).

68.5 Exception Handling

Exception handling is highly localized as the result of how business capabilities are implemented including the deployed infrastructure, management and business rules. As such, this section of the Scenario documentation is planned to be used as a guide to help understand the additional intent of these Scenarios. If no exceptions are noted here, then it can be assumed that the Scenario designers agreed that the Scenario is straightforward and has no additional needs:

  • The Confirm BOD is typically intended to be used by the original receiving application to communicate to the sending application that the information it sent in the message BOD (business object document) was received and understood and can be processed.

  • If the information was not received or understood, or contained errors of any type, it is accepted practice for the OAGIS users to presume that the data was not acted on.

  • In the absence of a Confirm BOD within a previously agreed time limit (e.g., SLA, normally defined in an out-of-band agreement), the originator will resend the original message.

  • As errors and assumptions are the bane of any implementation, it is strongly recommended that the Confirm BOD be used to prevent any potential problem although it is not a requirement by OAGIS use.


OAGi and its members welcome your feedback.