This chapter introduces ASTM and Ensemble support for ASTM. It contains the following sections:
The American Society for Testing and Materials (ASTM) established standards for transferring information between clinical instruments and computer systems. Specification ASTM E139497 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 E138102 details a standard for low-level data transfer communications. The Ensemble 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
. Ensemble supports the following listed standards from both organizations.
The originating standards from ASTM:
The successor standards from CLSI:
For simplicity, the remainder of this book uses the term ASTM to refer to all forms of the supported standards.
Ensemble supports ASTM documents as virtual documents. A virtual document
is a kind of message that Ensemble parses only partially. This kind of message has the standard Ensemble message header and the standard message properties such as ID
, 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.
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 an Ensemble business service. This single TCP socket is used for communication in both directions between Ensemble and the device.
For all of these reasons, an ASTM business service must be able to do both of the following:
This is a departure from the architectural role of an Ensemble business service, which is only
to receive documents and return the associated replies. The Ensemble architecture prohibits a business service from initiating transmissions outside Ensemble. Replies to received documents are fine, but there is no provision for a business service to initiate an exchange with an entity outside Ensemble.
To adapt this restriction to ASTM conventions, Ensemble provides 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 Ensemble 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 Ensemble 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 an Ensemble 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 Ensemble:
Ensemble 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 Ensemble 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
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.
Ensemble automatically archives all incoming and outgoing message data, but sometimes, especially for testing purposes, it can useful to capture the documents as external files, outside Ensemble. 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 Ensemble, 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 Ensemble 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.
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.
© 1997-2019 InterSystems Corporation, Cambridge, MA