Skip to main content
Previous sectionNext section

Introduction

This chapter introduces ASTM and InterSystems support for ASTM.

Introduction to ASTM

The American Society for Testing and Materials (ASTM) established standards for transferring information between clinical instruments and computer systems. Specification ASTM E1394–97 covers the two-way digital transmission of remote requests and results between clinical instruments and computer systems. It specifies the conventions for structuring the content of the document and for representing the data elements contained within those structures. It does not specify conventions for low-level communications protocols and data transfer requirements. A separate specification, ASTM E1381–02 details a standard for low-level data transfer communications. The InterSystems ASTM package supports both of these standards. For further details, see the web site http://www.astm.org/.

ASTM has since transferred the responsibility for maintaining these standards to the Clinical and Laboratory Standards Institute (CLSI). You can find more information on these standards at the web site http://www.clsi.org. InterSystems healthcare products support the following listed standards from both organizations.

The originating standards from ASTM:

  • ASTM E1381-02 Standard Specification for Low-Level Protocol to Transfer Messages Between Clinical Laboratory Instruments and Computer Systems (Withdrawn 2002)

  • ASTM E1394-97 Standard Specification for Transferring Information Between Clinical Instruments and Computer Systems (Withdrawn 2002)

The successor standards from CLSI:

  • LIS01-A2 Specification for Low-Level Protocol to Transfer Messages Between Clinical Laboratory Instruments and Computer Systems;Approved Standard - Second Edition

  • LIS02-A2 Specification for Transferring Information Between Clinical Instruments and Computer Systems; Approved Standard- Second Edition

Note:

For simplicity, the remainder of this book uses the term ASTM to refer to all forms of the supported standards.

InterSystems Support for ASTM Documents

InterSystems healthcare products support ASTM documents as virtual documents. A virtual document is a kind of message that InterSystems products parse only partially. This kind of message has the standard production message header and the standard message properties such as ID, Priority, and SessionId. The data in the message, however, is not available as message properties; instead it is stored directly in an internal-use global, for greater processing speed.

InterSystems provides tools so that you can access values in virtual documents, for use in data transformations, business rules, and searching and filtering messages. For background information, see Using Virtual Documents in Productions.

ASTM Communication Details

ASTM uses half-duplex, asynchronous communication, similar to a citizen’s band radio. Only one party can communicate over the line at a time, but either party can initiate communication over that line. As an exchange begins, if there is contention, the parties negotiate to decide which should send data first. Generally the laboratory device goes first. A device that uses ASTM uses a single TCP socket to communicate with a business service. This single TCP socket is used for communication in both directions between InterSystems products and the device.

For all of these reasons, an ASTM business service must be able to do both of the following:

  • Receive transmissions (and send their associated replies) over TCP

  • Initiate transmissions (and receive their associated replies) over TCP

This is a departure from the architectural role of a business service, which is only to receive documents and return the associated replies. The typical production architecture prohibits a business service from initiating transmissions outside InterSystems products. Replies to received documents are fine, but there is no provision for a business service to initiate an exchange with an entity outside InterSystems products.

To adapt this restriction to ASTM conventions, InterSystems products provide a special-purpose business operation for use with ASTM business services. This business operation identifies the incoming ASTM business service as its partner service. Whenever any member of the production needs to initiate communication to the external device, it invokes this business operation, which sends the transmission out via its partner service. This preserves the production conventions for internal messaging (a business service may send messages to a business process or business operation only) while leaving room for ASTM conventions (there is only one TCP socket available on the device, and at the other end of this TCP connection is a business service).

The following sections describe how these conventions for business services and business operations work in two situations. Both are useful as you work with ASTM and InterSystems products:

Connecting to a Device Using ASTM Over TCP

InterSystems products can communicate via TCP with a device that uses the ASTM protocol in scenarios like the following (all of which can occur in the same production):

  • Scenario 1: Receiving and replying to an incoming transmission. This scenario requires a business service and a business process.

    An incoming document arrives from the device and enters a production via a TCPServiceTwoWay business service. The business service forwards the document to its configured business process, WorkAndRouteProcess. As in other business productions, the business process may invoke routing rules, data transformations, business operations, or other business processes. Eventually, as a result of this work a response comes to the business process. WorkAndRouteProcess relays this response to the TCPServiceTwoWay business service, which in turn relays it to the device.

    It is possible to set up the production so that the business service does not wait for the response to return from the business process as shown in this scenario. Instead, the request from TCPServiceTwoWay to WorkAndRouteProcess could be asynchronous and both configuration items could be free to do other work while the activities triggered by WorkAndRouteProcess take place. When a reply is finally ready as a result of these activities, WorkAndRouteProcess could initiate communication as described in scenario 3 to return the response document to the device.

  • Scenario 2: Archiving the received documents as external files. This scenario requires a business service and a business operation.

    InterSystems products automatically archive all incoming and outgoing message data, but sometimes, especially for testing purposes, it can useful to capture the documents as external files, outside InterSystems products. A TCPServiceTwoWay business service could send incoming documents to the FileOperationArchive business operation over a simple pass-through interface. The FileOperationArchive would then store the documents as files in its configured directory on the local system. This scenario could easily coexist with either or both of the other scenarios described in this list.

  • Scenario 3: Sending an outgoing transmission to the device and receiving a reply. This scenario requires a business service, a business process, and a business operation.

    Depending on the conventions expected by the device, it might be important for the InterSystems product, rather than the device, to initiate a connection and send the device data before the device can formulate a transmission. Suppose the logic for initiating the message begins at a business process, WorkAndRouteProcess. This configuration item sends an internal production message to the TCP business operation, TCPOperationInitiate, which uses its partner service, TCPServiceTwoWay, to send the payload document from this message to the device. If there is a reply from the device, it arrives via TCPServiceTwoWay, which directs the reply appropriately. One possibility is that the reply might trigger further activities by the WorkAndRouteProcess, but the details are up to the developer.

Testing an ASTM Interface Without a Device

You can test ASTM interfaces without having a device connected. You would need to save some of the ASTM documents that you expect to flow to and from your device as text files. Then you can use them to test throughput as follows:

  • To simulate a document arriving from the device (and to test a TCP business service), you can use a file business service and a TCP business operation.

    This business service should look for a text file in its configured inbound directory and forward that to the TCP business operation. Then the TCP business operation can send the message to the TCP business service.

  • To simulate processing the document, you can use a business service (TCPServiceListen) to receive the incoming ASTM document. This configuration item should send the document to a business process (GenerateReplyProcess). Because this test is a simulation, the business process can be an ordinary BPL business process that uses simple statements to generate a generic ASTM reply document. The business process then returns that response to the business service.

  • To simulate a reply to the device, you can use a business service (TCPServiceListen) to send replies to a business operation (TCPServiceConnect, representing the device). Because this is a test and we want to see the results clearly, TCPServiceConnect forwards the reply to a file business operation for output to a text file in its configured outbound directory.