Laboratory Device Automation (LDA) Integration Profile

Transcription

1 GMSIH, HL7 France H, HL7 Germany, IHE-J, JAHIS, SFIL, IHE Italy Integrating the Healthcare Enterprise IHE Laboratory Technical Framework Supplement Laboratory Device Automation (LDA) Integration Profile October 10, 2005 Draft For Trial Implementation

2 Foreword Integrating the Healthcare Enterprise (IHE) is an initiative designed to stimulate the integration of the information systems which support modern healthcare institutions. Its fundamental objective is to ensure that in the care of patients all required information for medical decisions is both correct and available to healthcare professionals. The IHE initiative is both a process and a forum for encouraging integration efforts. It defines a technical framework for the implementation of established messaging standards to achieve specific clinical goals. It includes a rigorous testing process for the implementation of this framework. And it organizes educational sessions and exhibits at major meetings of medical professionals to demonstrate the benefits of this framework and encourage its adoption by industry and users. The approach employed in the IHE initiative is not to define new integration standards, but rather to support the use of existing standards HL7, DICOM, IETF, and others, as appropriate in their respective domains in an integrated manner, defining configuration choices when necessary. IHE maintain formal relationships with several standards bodies including HL7, DICOM and refers recommendations to them when clarifications or extensions to existing standards are necessary. This initiative has numerous sponsors and supporting organizations in different medical specialty domains and geographical regions. In North America the primary sponsors are the American College of Cardiology (ACC), the Healthcare Information and Management Systems Society (HIMSS) and the Radiological Society of North America (RSNA). IHE Canada has also been formed. IHE Europe (IHE-EUR) is supported by a large coalition of organizations including the European Association of Radiology (EAR) and European Congress of Radiologists (ECR), the Coordination Committee of the Radiological and Electromedical Industries (COCIR), Deutsche Röntgengesellschaft (DRG), the EuroPACS Association, Groupement pour la Modernisation du Système d'information Hospitalier (GMSIH), Société Francaise de Radiologie (SFR), Società Italiana di Radiologia Medica (SIRM), the European Institute for health Records (EuroRec), and the European Society of Cardiology (ESC). In Japan IHE-J is sponsored by the Ministry of Economy, Trade, and Industry (METI); the Ministry of Health, Labor, and Welfare; and MEDIS- DC; cooperating organizations include the Japan Industries Association of Radiological Systems (JIRA), the Japan Association of Healthcare Information Systems Industry (JAHIS), Japan Radiological Society (JRS), Japan Society of Radiological Technology (JSRT), and the Japan Association of Medical Informatics (JAMI). Other organizations representing healthcare professionals are invited to join in the expansion of the IHE process across disciplinary and geographic boundaries. The IHE Technical Frameworks for the various domains (IT Infrastructure, Cardiology, Laboratory, Radiology, etc.) defines specific implementations of established standards to achieve integration goals that promote appropriate sharing of medical information to support optimal patient care. It is expanded annually, after a period of public review, and maintained regularly through the identification and correction of errata. The current version for these Technical Frameworks may be found at or 1

3 60 The IHE Technical Framework identifies a subset of the functional components of the healthcare enterprise, called IHE Actors, and specifies their interactions in terms of a set of coordinated, standards-based transactions. It describes this body of transactions in progressively greater depth. The volume I provides a high-level view of IHE functionality, showing the transactions organized into functional units called Integration Profiles which highlight their capacity to address specific clinical needs. The subsequent volumes provide detailed technical descriptions of each IHE transaction. This supplement to the IHE Laboratory Technical Framework V1.2.1 is issued for Trial Implementation per the schedule announced in February Comments and change proposals arising from Trial Implementation may be submitted to to under the forum: Integrating the Healthcare Enterprise Select the sub-forum IHE Laboratory The IHE Laboratory Technical Committee will address these comments resulting from trail implementation and connect-a-thon testing, and publish the Final Text version in June Document production Principal editor: Yoshimitsu Takagi Hitachi Last update: October 9, 2005 Introduction 80 Version 1 of Laboratory Technical Framework considered the automation within the laboratory as a grouped actor named Automation Manager, receiving Work Orders from the Order Filler, using various automated devices to fulfill the observations for these orders, and sending back the results. Laboratory Technical Framework version 1 did not describe the workflow between the automation manager and the automated device involved in this process. This new Integration Profile, Laboratory Device Automation (LDA) adds the description of this workflow, involving three new actors and four new transactions. This new Integration Profile will be added to Volume I of the IHE Laboratory Technical Framework version 2. The four new transactions will be added to Volume II of the IHE Laboratory Technical Framework version 2. Profile Abstract 90 The Laboratory Device Automation Integration Profile describes the workflow between the Automation Manager and two new actors (Pre/Post-processor and Analyzer) to support the 2

4 100 processing of Work Orders and fulfill their embedded clinical tests on the related specimen. This processing includes the pre-analytical process of the specimen (sorting, centrifugation, aliquoting, transportation, decapping) the analytical process itself (run of the ordered clinical tests on the specimen) and the post-analytical process (recapping, transportation, rerun, dilution, storage and retrieval). The Automation Manager receives a Work Order from the Order Filler, splits it into a sequence of one or more Work Order Steps (WOS), each of which is entrusted to an automated device implementing an actor (Pre/Post-processor, Analyzer). This profile assumes that each LD performs at most one WOS for a specimen. This profile covers various situations such as: Work Order Step downloaded before specimen arrival, Work Order Step obtained by query after specimen recognition on the device, Work Order Step manually entered on the automated device. Except for the robotic transportation of the specimen, this profile does not address the handling of an automated device through an electromechanical interface. It only carries the Work Order Steps related information, the status of these Work Order Steps, and the results obtained. Glossary AM LD LAS WOS AWOS SWOS QC Analyzer Pre/Postprocessor Automation Manager Laboratory Device : A category of actors in LDA profile. A LD actor is either an Analyzer actor or a Pre/Post processor actor. Laboratory Automation System: A system which handles a set of Laboratory Devices (LD). This system implements the Automation Manager actor. Work Order Step: A step of a Work Order performed on one specimen by one LD. Analytical Work Order Step: A WOS performed by an Analyzer actor. Specimen Wok Order Step: A WOS performed by a Pre/Post Processor actor. Quality Control performed by Analyzer actor on a quality control specimen. An actor which is an automated device which fulfills clinical tests on biologic specimen. An Analyzer performs analyzing for a specimen according to AWOS, and return the result to the AM. An actor which provides some pre- and post- processes to the specimen. This actor is categorized to two sub categories, one is pre- 3

5 110 Pre-processor Post-processor Centrifuge Decapper Aliquoter Labeler Conveyor Sorter Dilution System Recapper Specimen Storage System processor and the other one is post-processor. A Pre/Post-processor processes a specimen according to SWOS, and return the result to the AM. An automated device which provides some preparation (decapping, aliquoting, centrifugation, transportation, ) of the specimen before the clinical testing. An automated device which deals with the specimen after clinical tests have been performed on it, making it ready for rerun or for storage, or that conveys it to another automated device. An automated device which divides the blood into a serum ingredient and a blood cell ingredient by centrifugal separation. An automated device which takes off the cap of the specimen container. An automated device which aliquots a parent specimen into one or more child specimen. An automated device which affixes the bar code label to the specimen container. An automated device which transports specimen to the appropriate devices. An automated device which sorts the specimen according to their process type. An automated device which dilutes a specimen by mixing a diluent. An automated device which re-caps a specimen container. An automated storage device which saves and manages processed specimen. 4

6 Volume I Integration Profiles X Laboratory Device Automation Integration Profile X.1 Scope of LDA Integration Profile The LDA Integration Profile supports the workflow for the automated technical section of the clinical laboratory. It provides the transactions between the actors of this section (Automation Managers, Pre/Post-processors, Analyzers) to fulfill the Work Orders sent by the Order Filler, and send back the results produced for these Work Orders. This LDA profile strictly addresses the workflow between Automation Managers and Laboratory Devices (LD) operated by the clinical laboratory staff. Devices operated by the clinical ward staff, are supported by another profile: LPOCT, and are therefore out of scope of LDA. The input to the LDA workflow is a Work Order generated by the Order Filler. The Automation Manager splits this Wok Order into a sequence of one or more Work Order Steps (WOS), sending each one to a particular automated device. Among this sequence, the particular WOS that instructs the Analyzer to fulfill the clinical tests is called the Analytical Work Order Step (AWOS). The transaction carrying this AWOS instructs the analyzer to perform a list of tests on a particular specimen. It does not say how to perform them: The electromechanical handling of an analyzer is out of scope of this profile. The tests are performed on specimen collected from the patients. The specimen may arrive on an automated device before or after the WOS referring to it has been delivered. In both cases, the specimen and the WOS (instruction) must be both present on the device in order for the step to be performed This LDA profile also addresses the testing of QC specimen on an Analyzer, and the upload of QC results from the Analyzer to the AM. An Analyzer can fulfill both patient specimen AWOS and QC specimen AWOS. The LSWF profile supports the upload of QC results from the AM to the Order Filler. Thus the combination of both profiles enables the centralization of QC results of all the Analyzers of the clinical laboratory, on the Laboratory Information System. In some situations, the recognition of the specimen (by its ID or position) or the WOS content can be entered manually on the LD user interface. For the purpose of messaging, the identification of specimen is essential. The primary specimen ID is provided either by the Order Placer or by the Order Filler. In case a Specimen Work Order Step (SWOS) instructs an aliquoter to prepare aliquot specimen, a new ID coded on a new barcode label will be required for each aliquot produced. These IDs and labels may be provided by the Automation Manager or by the aliquoter or by a third party. The organizational details of the labeling process are out of the scope of this profile, which only 5

7 recommends that barcode labels be readable (e.g. format and length of the barcode, label format) by all the LD that will perform a WOS on this specimen. The profile includes the LD s ability to accept or reject a WOS, with the notice of specimen arrival to the Automation Manager. It also includes the ability of an Analyzer to modify the content of an AWOS, for instance adding automatically a new test, depending on the results obtained on the original tests. The ability to automatically create modification of the work order at the AM may be constrained by regulatory requirement. The exchange of code sets and associated rules is supported by another profile: LCSD. Observation results tracking implies the ability of each actor (Analyzer, Automation Manager) to store the raw results, before refining or translating them, automatically or interactively (e.g. during the technical validation). This safe storage is out of the scope of this profile. This LDA profile may enrich its specifications in order to integrate specific types of pre or post processing laboratory devices. The manufacturers of laboratory devices are invited by the IHE Laboratory Committee to bring their contributions to these specifications. X.2 Use cases All the use cases for patient specimen testing defined in this section start with a Work Order sent by the Order Filler to the Automation Manager. The Automation Manager splits this Work Order into a sequence of Work Order Steps, and schedules each step on a LD (aliquoter, robotic conveyer, analyzer ) according to the organization of the laboratory automation. Each WOS contains all the information required by the target device to perform it: container identification, specimen information, target ID, operation to perform, scheduled time ) The Analytical Work Order Step (AWOS) also contains the list of clinical tests to perform, the patient identification, admission and clinical information, the order information The specimen information may include the ID, position, specimen type, volume, date and time of collection, ID of collector, specimen pre-analytical status (e.g. centrifuged, decapped ). For some Analyzers which perform single test (e.g. HbA1c), or a constant panel (Blood culture, Blood cells count ), the AWOS need not mention the tests to be performed. By definition, a Work Order Step is related to a single specimen. The specimen (primary or aliquot) is usually identified with a unique ID printed on a barcode label stuck to the specimen container. The laboratory technical staff supervise the various WOS using the Automation Manager and operating all necessary LD. The technical staff perform the technical validation of the results on the Automation Manager, which then, sends these results back to the Order Filler. Should a specimen be damaged or lost, the Automation Manager will suspend or cancel its Work Order until the replacement specimen arrives. This section also provides two use cases for QC testing. 6

8 X.2.1 WOS downloaded on the LD before specimen arrival Initial part of the scenario: a) The Automation Manager sends the scheduled WOS to the LD. For some LD, many WOS may be grouped into a single work list, which is downloaded within a single message sent to the LD. But still in that case, each WOS part of the work list, is related to a single specimen. 190 b) The LD recognizes the specimen (though barcode ID scanning, position identification on the carrier, or manual entry) and selects the related WOS from its memory c) Optionally, the LD may then send a specimen arrived notification to the Automation Manager. Final part of the scenario: r) The LD performs the ordered step on that specimen. s) The LD notifies the Automation Manager, with the status of the performed step. In the case where the LD is an Analyzer and the WOS is an AWOS, this notification message contains the results and status of the performed clinical tests Exceptions handling: In the case where the WOS has not been downloaded yet by the time the specimen is recognized, then several events may occur depending upon the LD own capabilities and upon the operator s actions: Either the LD skips this specimen or it suspends its process, waiting for the download of the missing WOS, or the LD queries the Automation Manager with the specimen ID (shift to second use case) or the operator manually enters the WOS (shift to third use case). In the time between the WOS first download and the specimen recognition by the LD, the content of the parent order and Work Order may be modified (suppressing some tests, adding some others, shifting the target LD with another LD) or even canceled. Such events will result into the cancellation or the modification of the WOS on the Automation Manager, and therefore, SHALL trigger a message from the Automation Manager to the LD carrying this modification or cancellation. X.2.2 Query for the WOS after specimen arrival on the LD Initial part of the scenario: a) The Automation Manager schedules the WOS but does not send it to the LD. b) In the case where the Automation Manager receives a Work Order update or cancellation, it updates or cancels the related WOS appropriately, and creates new ones if needed. c) The LD recognizes the specimen (barcode scanning, or manual entry), and queries the Automation Manager with the specimen ID. d) The Automation Manager replies to the query with the WOS to perform. 7

9 220 Final part of the scenario: same as in use case X Exceptions handling: In this use case, the step to perform is sent by the Automation Manager just in time, when the LD is ready to perform it on the specimen. Thus there is no need for update WOS and cancel WOS messages. The specimen may be placed on the LD, before the Order Filler has sent the Work Order to the Automation Manager, and before the WOS exist on the latter. In that case the query in step c) is unsuccessful. The answer sent in step d) will be unknown specimen, no pending WOS for it. Then, either the LD skips this specimen and will try a new query later, or (especially in case of an urgent order) the operator manually enters the WOS on the LD(shift to third use case). X.2.3 Manual entry of the WOS on the LD a) The Automation Manager schedules the WOS and prints it on a sheet of paper, with all related information which will be required by the LD. b) The laboratory technical staff enter the WOS manually on the LD, from the paper sheet. c) At specimen recognition, the LD picks up the related WOS. d) Optionally, the LD may then send a specimen arrived notification to the Automation Manager. Final part of the scenario: same as in use case X.2.1 Exceptions handling: In the case where the WOS has not been entered by the time the specimen is recognized, then several events may occur: Either the LD skips this specimen or it suspends its process, waiting for the manual entry of the WOS by the operator, or the LD performs a default WOS. If the LD is an Analyzer, the default AWOS may be a panel of emergency tests which can be performed and reported quickly. In the time between the WOS printing by the Automation Manager and its fulfillment on the LD, the content of the parent order and Work Order may be modified (suppressing some tests, adding some others, shifting the target LD with another LD) or even canceled. Such events will result in the cancellation or the modification of the WOS on the Automation Manager, which must inform the operator of those changes (on its user interface or by printing a new corrected WOS sheet). The operator must then, manually correct the WOS on the LD. X.2.4 Rerun on the Analyzer An AWOS usually needs one analytic run on the Analyzer. In some circumstances the results obtained from this first run need to be controlled by a second run or rerun. The need for a rerun may be decided 8

10 260 - either immediately after the first run on the LD, before uploading the results to the Automation Manager - or during the technical validation of the Work Order with the first run results, on the Automation Manager application. - or later, during the clinical validation of the order with the first run results, on the Order Filler application Thus, three sub cases are to be considered: These use cases take place after the final part of any of the three first scenarios. (i.e. X.2.1, X.2.2 and X.2.3). Initial Part (Scheduling) Middle Part Pre-process, analyze Final Part Rerun Use Case X.2.1 Work Order is downloaded before the sample arrival Automation manager receive the work order from the Order Filler and schedule the work order. Refer to 3.1 Use Case X.2.2 Query the work order when sample arrives Use Case X.2.3 Work order is input at the ME Use Case X.2.4 Rerun (by Technical validation or automatic check by the automation manager) Sample storage or waste Refer to X.2.4 X Rerun decided on the Analyzer immediately after the first run 270 The rerun is decided automatically or manually, at the end of the first run. The reason may be: - Results could not be obtained, due to a flaw on the Analyzer: reagent shortage, needle blocked up, calibration failure - Results out of range, triggering a rerun with automatic dilution of the specimen. This rerun happens before the results upload to the Automation Manager. The results of the first run either does not exist or are improper. 9

11 280 The Automation Manager should be notified of this status change of the AWOS ( First run failed, second run scheduled ), in order to track the LD operations, and to register the reagent consumption. The common final part of the three preceding scenarios is presented in the following sub-case: Final part of the scenario: r) The LD (Analyzer) performs the ordered step on that specimen (first run). s) Considering the results obtained, a second run is scheduled. The Analyzer notifies the AWOS status change to the Automation Manager: First run failed, second run scheduled. t) After the appropriate fix (dilution, reagent refill, needle wash, calibration ) the Analyzer performs the second run. u) The Analyzer notifies the Automation Manager, with the results and status of the second run. 290 X Rerun decided during technical validation on the Automation Manager The control (rerun) is decided during the technical validation of the results of the first run, compared with normal ranges, patient s prior results, and other clinical information, or technical information such as drifting or out of range quality control detected. This decision is taken by the technical staff, or automatically by the Automation Manager application. The common final part of the three preceding scenarios is presented in the following sub-case: Final part of the scenario: r) The Analyzer performs the ordered step on that specimen (first run). s) The Analyzer notifies the Automation Manager, with the results and status of the first run for this AWOS. t) The technical validation of the results is performed on the Automation Manager, resulting in a new run requested with the same tests on the same specimen. This new run may be requested on the same analyzer or on another one (to confirm the results obtained on the first one). 300 The rerun picks up the scenario appropriate to the working mode of the Analyzer chosen for the second run: If the Analyzer targeted for the rerun is working in download mode (at least for reruns) the Automation Manager sends a new AWOS to it, for the same specimen and the same tests. This starts a new X.2.1. scenario (step a). If the Analyzer is working in query mode, the Automation Manager schedules the new AWOS and waits for the query from the Analyzer. This starts a new X.2.2. scenario (step a) If the Analyzer only supports manual entry, the Automation Manager prints out the scheduled rerun. This starts a new X.2.3. scenario (step a) 10

12 310 In addition, the rerun may generate new SWOS entrusted on LDs other than the targeted Analyzer. Here are some examples: - The rerun is scheduled on a new aliquot that needs to be produced by an aliquoter (Pre- Analyzer LD), using a new container. - The rerun needs the transportation of the specimen to a different Analyzer. This involves the Post-Analyzer robotic conveyer. X Rerun decided during clinical validation on the Order Filler 320 The control (rerun) is decided during the clinical validation of the results of the whole order group, considering the clinical consistency of this whole set of results, together with normal ranges, patient s prior results, and other clinical and technical information, or technical information such as drifting or out of range quality control detected. This decision is taken by the laboratory clinical expert, or by an automated expert system assisting the clinical expert. In this situation, the final part of the first three scenarios ends normally. After the clinical validation the Order Filler generates a new Work Order for the same patient, same specimen, requesting the Automation Manager to schedule the tests anew, on one of its Analyzers. This new Work Order may carry some additional tests ordered in the meantime. It may possibly require a new aliquot. This kind of rerun is supported and described by the first three scenarios. X2.5 QC performed on an analyzer 330 In the following use cases, in all exchanged messages, the specimen is playing the role of a QC specimen. X2.5.1 QC downloaded by the Automation Manager 340 a) The Automation Manager schedules (automatically or interactively by the technician) a new QC AWOS to be performed by an Analyzer, for a set of tests on a QC specimen. The AWOS (with the specimen/container ID or specific position, and the tests to perform) is downloaded to the analyzer b) The analyzer recognizes the specimen (scanning the bar-coded ID, or by position) finds the related AWOS and performs the tests. c) The analyzer sends the results obtained for the AWOS to the AM. d) The AM applies its evaluation rules to these QC results (result accepted or out of control, or warning of deviation trend) and stores them into its QC data base. e) Conditionally, the AM may forward the QC results to the Order Filler, using LAB-5 transaction and a reflex QC Work Order. 11

13 X2.5.2 QC scheduled by the Automation Manager, queried by the Analyzer 350 a) The Automation Manager schedules (automatically or interactively by the technician) a new QC AWOS to be performed by an Analyzer, for a set of tests on a QC specimen. The AWOS (with the specimen/container ID and the tests to perform) is prepared for the analyzer b) The analyzer recognizes the specimen (scanning the bar-coded ID) and queries the AM with the specimen/container ID. The AM replies with the appropriate AWOS for this QC specimen. c) The analyzer performs the tests and sends the results obtained for the AWOS to the AM. d) The AM applies its evaluation rules to these QC results (result accepted or out of control, or warning of deviation trend) and stores them into its QC data base. e) Conditionally, the AM may forward the QC results to the Order Filler, using LAB-5 transaction and a reflex QC Work Order. X2.5.3 Unsolicited QC results uploaded to the Automation Manager 360 a) The analyzer recognizes a QC specimen (by position, and/or manual entry of the required information) and performs a pre-configured or manually entered list of tests on this specimen. b) The analyzer sends the results to the AM within a reflex AWOS. c) The AM applies its evaluation rules to these unsolicited QC results (result accepted or out of control, or warning of deviation trend) and stores them into its QC data base. d) Conditionally, the AM may forward the QC results to the Order Filler, using LAB-5 transaction and a reflex QC Work Order. At the end of section X.6 of volume 1, add the following workflows, related to the three above use cases: 370 X.3 Systems interconnection in the laboratory As formerly stated, a clinical laboratory uses an Order Filler (OF) application to manage its orders. It handles its technical automation with the help of one or more Automation Managers (AM), each of which may manage one or more Laboratory Devices (LD). The systems: Laboratory Information System (LIS), Laboratory Automation System (LAS), Devices (Dev) that support the IHE actors, may be interconnected in various ways: 12

14 LIS LIS LIS LAS LAS LAS LAS LAS LAS Dev Dev Dev Dev Dev Dev Dev Dev Dev Dev Dev Dev One level of LAS Two levels of LAS and single path Two levels of LAS and multi-path 380 Each of these architectures of interconnection is valid provided the systems implement the appropriate actors. That is: OF OF OF AM AM AM AM LD AM LD AM LD LD LD LD LD LD LD LD LD LD LD LD One level of LAS Two levels of LAS and single path Two levels of LAS and multi-path The management of multi-path Work Orders is an internal matter of the Order Filler application. These management rules are not part of the scope of IHE profiles. 13

15 X.4 Actors/ Transactions X.4.1 Workflow Diagram Automation Manager LAB-22 Query for WOS LAB-26 SWOS status change LAB-21 WOS download LAB-21 WOS download LAB-22 Query for WOS LAB-23 AWOS status change Pre/Post-processor Analyzer Figure X.4-1. Laboratory Device Automation Diagram X.4.2 Transactions LAB-21 WOS Download: This transaction contains the messages used to download a Work Order Step (WOS) from the Automation Manager to the Analyzer or Pre/Post-processor, according to a push method. It includes new WOS, update WOS, cancel WOS and the related applicative acknowledgements. This transaction is used with Analyzers and Pre/Postprocessor which work in download mode. LAB-22: WOS Query: This transaction contains the message used by the Analyzer or Pre/Postprocessor to query the Automation Manager with one or more specimen (or location) identifiers, and the reply message from the Automation Manager delivering one or more WOS dedicated to each of these specimen. This transaction implements the pull method for requesting WOS. LAB-23: AWOS Status Change: This transaction contains the messages used by the Analyzer to report the status of an AWOS (such as specimen arrived, first run failed, second run 14

16 started, AWOS complete ) and to send the tests results when the AWOS is complete. It also includes the related applicative acknowledgements from the Automation Manager. LAB-26: SWOS Status Change: This transaction contains the messages used by the Pre or Post-Processor to report all the status changes of the SWOS, and the related applicative acknowledgements. Status changes include: specimen arrived, SWOS complete, SWOS failed 410 Table X.4-1 lists the transactions for each actor involved in the LDA Profile. To claim support of this Integration Profile, an implementation of an actor must perform the required transactions (labeled R ). Transactions labeled O are optional and define the profile options explained in the X.5 section below. Table X.4-1. LDA Integration Profile - Actors and Transactions Automation Manager Analyzer Pre/Post-processor Actors Transactions Optionality Section in Vol. 2 LAB-21 : WOS Download R X.8 LAB-22 : WOS Query R X.9 LAB-23 : AWOS Status Change R X.10 LAB-26 : SWOS Status Change O X.11 LAB-21 : WOS Download O X.8 LAB-22 : WOS Query O X.9 LAB-23 : AWOS Status Change R X.10 LAB-21 : WOS Download O X.8 LAB-22 : WOS Query O X.9 LAB-26 : SWOS Status Change R X.11 X.5 LDA Integration Profile Options Options which may be selected for this Integration Profile are listed in the table X.5-1 along with the Actors to which they apply. Table X.5-1 Laboratory Device Automation - Actors and Options Actor Options Vol & Section Automation Manager Management of Pre/Post-processor Analyzer 1 Query mode WOS Download mode WOS 1 A product implementing an Analyzer which supports neither transaction LAB-21 nor transaction LAB-22 can still claim for the LDA Integration Profile conformance: It is a one way Analyzer, only able to report its results using transaction LAB

17 Actor Options Vol & Section Pre/Post-processor 2 Query mode WOS Download mode WOS Management of Pre/Post-processor : A product may implement an Automation Manager which manages only AWOS on Analyzers, and therefore supports only transactions LAB-21, LAB-22 and LAB-23. If a product supports the Management of Pre/Post-processor option, then it must also manages SWOS and it must support transactions LAB-26 with Pre/Post-processors. Query mode WOS: An Analyzer implementing this option must support transaction LAB-22. Download mode WOS: An Analyzer implementing this option must support transaction LAB- 21. Query mode WOS: A Pre/Post-processor implementing this option must support transaction LAB-22. Download mode WOS: A Pre/Post-processor implementing this option must support transaction LAB To claim for the LDA Integration Profile conformance, a product implementing a Pre/Post-processor must support at least one of the two transactions LAB-21 and LAB-22, together with the mandatory transaction LAB

18 X.6 LDA Integration Profile Process Flow These UML sequence diagrams present a high-level view of the process flow: Each transaction is represented by a single arrow with the initial triggering event, but without any detail on the various messages which compose the transaction. The message flow of each transaction and the description of each of its individual messages can be found in volume 2. X.6.1 Normal process of a specimen with all LD working in downlold mode This process flow is based on use case X.2.1, with all LD working in download mode. Work Order received from Order Filler Automation Manager LAB-21 WOS Download Pre/Postprocessor Pre/Postprocessor (acting as Pre-Processor) Analyzer LAB-21 WOS Download (acting as Post-Processor) LAB-21 WOS Download LAB-26 SWOS Status Change (specimen arrived) Specimen recognized LAB-26 SWOS Status Change (SWOS complete) LAB-23 AWOS Status Change LAB-23 AWOS Status Change with results SWOS complete Specimen recognized Tests performed Specimen recognized LAB-26 SWOS Status Change (specimen arrived) LAB-26 SWOS Status Change (SWOS complete) SWOS complete 440 Figure X Normal process in download mode In this example, all LD support the optional message WOS Status Change triggered by the event Specimen recognized on the LD carrier. This diagram shows a situation with one pre-processing device, one analyzer and one postprocessing device. In the situation where the three LDs are combined in a single physical device, duplicate messages shall not be sent. 17

19 X.6.2 WOS Update with all LD working in download mode This process flow based on use case X.2.1, shows the handling of the exception Work Order updated after download and before fulfillment of some of its WOS. Work Order received from Order Filler Automation Manager LAB-21 WOS Download Pre/Postprocessor Pre/Postprocessor (acting as Pre-Processor) Analyzer LAB-21 WOS Download (acting as Post-Processor) LAB-21 WOS Download SWOS complete Update received from Order Filler LAB-26 SWOS Status Change (SWOS complete) LAB-21 WOS Update LAB-21 WOS Update LAB-23 AWOS Status Change with results Tests performed LAB-26 SWOS Status Change (SWOS complete) SWOS complete 450 Figure X WOS Update, in download mode In this example, the LD do not use the optional message WOS status change triggered by the event specimen recognized on the LD carrier. When the Automation Manager receives the update from the Order Filler, it forwards this update only to those LDs which have not completed their Work Order Step yet, and which are concerned with this update. 18

20 X.6.3 Normal process with AWOS manual entry and SWOS download 460 This process flow is based on use case X.2.1, for SWOS, and use case X.2.3 for AWOS: Pre/Post-processors are working in download mode, whilst the Analyzer, has a one-way interface supporting only transaction LAB-23 to report its results, and therefore needs the manual entry of its worklist of AWOS. Work Order received from Order Filler Automation Manager Pre/Postprocessor Pre/Postprocessor (acting as Pre-Processor) LAB-21 SWOS Download Analyzer LAB-21 SWOS Download (acting as Post-Processor) SWOS complete LAB-26 SWOS Status Change (SWOS complete) AWOS worklist printed out AWOS worklist AWOS worklist manually entered LAB-23 AWOS Status Change with results Tests performed LAB-26 SWOS Status Change (SWOS complete) SWOS complete 19

21 X.6.4 Normal process of a specimen with all LD working in query mode This process flow is based on use case X.2.2, with all LD working in query mode. Automation Manager Pre/Postprocessor Pre/Postprocessor Analyzer Work Order received from Order Filler (acting as Pre-Processor) (acting as Post-Processor) LAB-22 WOS query Specimen recognized LAB-26 SWOS Status Change (SWOS complete) SWOS complete LAB-22 WOS query Specimen recognized LAB-23 AWOS Status Change with results LAB-22 WOS query Tests performed LAB-26 SWOS Status Change (SWOS complete) Specimen recognized SWOS complete Figure X Normal process in query mode 20

22 470 X.6.5 Automatic rerun on the Analyzer, triggered by out of range results This process flow is based on sub-use case X Work Order received from Order Filler Automation Manager Pre/Postprocessor Pre/Postprocessor (acting as Pre-Processor) LAB-21 WOS Download Analyzer LAB-21 WOS Download (acting as Post-Processor) LAB-21 WOS Download SWOS complete LAB-26 SWOS Status Change (SWOS complete) LAB-23 AWOS Status Change «First run failed» 1 st run performed, results out of range trigger 2 nd run with automatic dilution LAB-23 AWOS Status Change «AWOS complete after 2 nd run», with results 2 nd run performed, results correct LAB-26 SWOS Status Change (SWOS complete) SWOS complete Figure X Rerun decided on the Analyzer immediately after first run 21

23 X.6.6 Rerun requested by the Automation Manager during technical validation This process flow is based on sub-use case X Work Order received from Order Filler Automation Manager Pre/Postprocessor Pre/Postprocessor LAB-21 WOS Download (acting as Pre-Processor) LAB-21 WOS Download Analyzer LAB-21 WOS Download (acting as Post-Processor) LAB-26 SWOS Status Change (SWOS complete) SWOS complete LAB-23 AWOS Status Change «AWOS complete» with results 1st run performed, results reported Technical validation requests for a 2 nd run LAB-26 SWOS Status Change (SWOS complete) LAB-21 new WOS Download LAB-21 WOS Download (prepare specimen for rerun) LAB-26 SWOS Status Change (SWOS complete) SWOS complete SWOS complete LAB-23 AWOS Status Change «AWOS complete», with results 2 nd run performed, results reported Figure X Rerun decided on the Automation Manager at technical validation 480 The request for a second run generates a new AWOS for the same specimen on the Analyzer. In this example it also generates a new SWOS to the Post-processor, requesting it to prepare the specimen for the second run (aliquoting, retrieval, transportation to the analyzer ) 22

24 X.6.7 Urgent tests performed before the arrival of the Work Order This process flow is based on use case X.2.2 linked with use case X.2.3 Automation Manager Analyzer LAB-22 WOS query (specimen ID) Specimen recognized Reply: Unknown specimen. No pending AWOS for it Manual entry of the WOS: urgent tests to perform Work Order received from Order Filler LAB-4 LAB-5 results stored with specimen ID LAB-23 manual AWOS complete with results (specimen ID) Matching with the manual AWOS, based on the specimen ID Technical validation of the urgent results results sent to the Order Filler Tests performed results reported manually to the clinical department Figure X Manual urgent AWOS performed and used before arrival of Work Order 23

25 X6.8 QC downloaded by the Automation Manager The following diagram illustrates use case X Automation Manager Analyzer AWOS scheduled for QC specimen LAB-21 AWOS Download (Specimen role = QC) Specimen ID recognized LAB-23 AWOS Status Change (AWOS complete with results) (Specimen role = QC) QC results produced 24

26 490 X6.9 QC scheduled by the Automation Manager, queried by the Analyzer The following diagram illustrates use case X Automation Manager Analyzer AWOS scheduled for QC specimen LAB-22 WOS Query (The reply says «Specimen role = QC») Specimen ID recognized LAB-23 AWOS Status Change (AWOS complete with results) (Specimen role = QC) QC results produced 25

27 X6.10 Unsolicited QC results uploaded to the Automation Manager The following diagram illustrates use case X Automation Manager Analyzer QC specimen recognized, wih tests to perform LAB-23 AWOS Status Change (reflex AWOS complete with results) (Specimen role = QC) QC results produced 26

28 IHE Transactions Volume 2 - Transactions X.8 Transaction LAB-21: Work Order Step, Downloaded to LD 500 This section corresponds to Transaction LAB-21 of the IHE Technical Framework. Transaction LAB-21 is used by the Automation Manager and LD actors. X.8.1 Scope This transaction is used if the Automation Manager issues a new WOS to the LD. In addition, this transaction is used to cancel and/or modify a WOS which was previously sent to the LD. It is also possible to cancel a previous WOS and send a new WOS to modify it. X.8.2 Use Case Roles Automation Manager LD (Analyzer, Pre/Post Processor) WOS Mgt 510 Actor: Automation Manager Role: Manages the pre-processing, analysis, post-processing to fulfill the Work Order. Receives the Process Result from the Pre/Post Processor and (if necessary) performs the technical validation on it and (if necessary) sends the validated Process Result to the Order Filler. Actor: (LD) Pre/Post-processor, Analyzer Role: Analyzes the specimen, perform the ordered tests and generates the test results, or Manages the Pre/Post-process on the specimen and generates a Process Result. X.8.3 Referenced Standard HL7 v2.5, Chapter 4 27

29 X.8.4 Interaction Diagram Automation Manager LD OML^O33 New Order (ORC-1: NW) ORL^O34 Order accepted (ORC-1: OK) Unable to accept (ORC-1: UA) OML^O33 Order Modify (ORC-1: RP) ORL^O34 Order modified(orc-1:rq) OML^O33 Order Cancel (ORC-1: CA) ORL^O34 Order cancelled(orc-1:cr) 520 X Laboratory Order Message (OML^O33, ORL^O34) This transaction contains the messages used to download a Work Order Step (WOS) from the Automation Manager to the Analyzer or Pre/Post-processor. It includes new WOS, update WOS, cancel WOS and the related application acknowledgements. X Trigger Events OML (O33): WOS sent by the Automation Manager. ORL (O34): Acknowledgement of the WOS sent by the LD. X Message Semantics 530 Refer to the HL7 standard for the OML, ORL message of HL7 2.5 Chapter 4 and the general message semantics. MSH Message Header R [1..1] 2 [ --- PATIENT begin O [0..1] PID Patient Identification R [1..1] 3 28

30 [ PV1 ] Patient Visit RE [0..1] 3 ] --- PATIENT end { --- SPECIMEN begin R [1..1] SPM Specimen R [1..1] 7 [{SAC}] Specimen Container O [0..1] { --- ORDER begin R [1..1] ORC Common Order (for one battery) R [1..1] 4 [{TQ1}] Timing Quantity RE [0..1] 4 [ --- OBSERVATION REQUEST begin R [1..1] OBR Observation Request R [1..1] 4 [TCD] Test Code Details O [0..1] 13 [{OBX}] Observation Result C [0..*] 7 { --- PRIOR RESULT start O [0..*] [ORC] Common order prior result O [0..1] 4 OBR Order detail prior result R [1..1] 4 {OBX} Observation/Result prior result R [1..*] [{NTE}] Comment of the result C [0..*] 2 } --- PRIOR RESULT end ] --- OBSERVATION REQUEST end } --- ORDER end } --- SPECIMEN end MSH-9 - Message Type (MSG) shall have its three components respectively valued to "OML", "O33" and OML_O33 SPM-11 Specimen Role (CWE) in SPM segment shall be coded Q (Control specimen) in the case of a QC AWOS. MSH Message header R [1..1] 2 MSA Message Acknowledgement R [1..1] 2 [{ERR}] Error O [0..*] 2 [PID] Patient Identification O [0..1] 3 { --- SPECIMEN begin R [1..*] SPM Specimen R [1..1] 7 [{SAC}] Specimen Container O [0..*] 13 [{ --- ORDER begin O [0..*] 29

31 540 ORC Common Order R [1..1] 4 [{TQ1}] Timing/Quantity RE [0..1] 4 [OBR] Observation Request R [1..1] 4 }] --- ORDER end } --- SPECIMEN end MSH-9 - Message Type (MSG) shall have its three components respectively valued to "ORL", "O34" and ORL_O34. OBR segment All fields are optional except those listed in table below. Table : OBR Segment 2 22 EI R [1..1] Placer Order Number 3 22 EI RE [0..1] Filler Order Number CE R [1..1] Universal Service Identifier 5 2 ID X [0..0] Priority OBR 6 26 TS X [0..0] Requested Date/Time 7 26 TS X [0..0] Observation Date/Time # 8 26 TS X [0..0] Observation End Date/Time # 9 20 CQ X [0..0] Collection Volume * 11 1 ID RE [0..1] Specimen Action Code * CE X [0..0] Danger Code ST X [0..0] Relevant Clinical Information TS X [0..0] Specimen Received Date/Time * SPS X [0..0] Specimen Source XCN R [1..1] Ordering Provider XTN RE [0..2] Order Callback Phone Number ST X [0..0] Placer Field ST X [0..0] Placer Field ST X [0..0] Filler Field ST X [0..0] Filler Field TS X [0..0] Results Rpt/Status Chng - Date/Time MOC X [0..0] Charge to Practice ID C [0..1] Diagnostic Serv Sect ID 30

32 25 1 ID X [0..0] Result Status PRL X [0..0] Parent Result TQ X [0..0] Quantity/Timing EIP X [0..0] Parent ID X [0..0] Transportation Mode CE X [0..0] Transport Arrangement Responsibility ID X [0..0] Transport Arranged 42 1 ID X [0..0] Escort Required CE X [0..0] Planned Patient Transport Comment CWE X [0..0] Medically Necessary Duplicate Procedure Reason

33 TCD segment Table : TCD Segment CE R [1..1] Universal Service Identifier 2 20 SN O [0..1] Auto-Dilution Factor 3 20 SN O [0..1] Rerun Dilution Factor 4 20 SN O [0..1] Pre-Dilution Factor 5 20 SN O [0..1] Endogenous Content of Pre-Dilution Diluent 6 1 ID O [0..1] Automatic Repeat Allowed 7 1 ID O [0..1] Reflex Allowed CE O [0..1] Analyte Repeat Status Note: The usage of this segment needs to be considered between AM and LD. Universal Service Identifier is a copy of OBR-4. X Expected Actions 560 If the OML message of the Order Control Code NW is received from Automation Manager, the LD will receive and register the order information, then it will transmit the result either Accept or Reject to Automation Manager by the ORL message. X.9 Transaction LAB-22: WOS Query 570 This section corresponds to Transaction LAB-22 of the IHE Technical Framework. Transaction LAB-22 is used by the Automation Manager and the Pre/Post-processor, Analyzer(LD) actors. This transaction is used by the LD to get the WOS to perform for each specimen from the Automation Manager by querying after the specimen arrives. The transaction provides a query for multiple specimen and the reply will carry zero or one container and one WOS for each specimen. The Automation Manager and the LD preserve the conformity between the specimen and the WOS by checking the Specimen Information (Specimen ID and the like) within the message. X.9.1 Scope This transaction is used by the general use case Query for the WOS after specimen arrival on the LD described in the Volume 1 of this LDA Technical Framework. It is used by the 32

34 Automation Manager (Laboratory Automation System) and the LD which supports "Query Mode". X.9.2 Use Case Roles Automation Manager LD (Analyzer, Pre/Post Processor) WOS Mgt 580 Actor: Automation Manager Role: Manages the Work Orders and WOS. Returns the appropriate WOS to the query from the LD. Actor: (LD) Pre/Post-processor, Analyzer Role: Queries the WOS to the Automation Manager when a specimen arrives, and receives the WOS as the response. X.9.3 Referenced Standard HL7 version 2.5: Chapter5: "Query" --> QBP and RSP messages Chapter5: "Query" --> QPD, RCP and QAK segments X.9.4 Interaction Diagram

35 Automation Manager LD (in query mode) QBP^WOS^QBP_Q11 (Query for WOS) Specimen recognized RSP^WOS^RSP_K11 (Response including WOS) X WOS Query Message (QBP^WOS^QBP_Q11, RSP^WOS^RSP_K11) After the LD working in query mode recognizes one or more specimen arrival, the LD sends "WOS Query Message"(QBP^WOS^QBP_Q11) with one or more Specimen IDs or other IDs to the Automation Manager. The Automation Manager replies with the response message (RSP^WOS^RSP_K11) containing one or more WOS for each specimen identified in the query. X Trigger Events 600 QBP(Q11) : Query for the WOS sent by the LD. RSP(K11) : Response including the WOS sent by the Automation Manager. X Message Semantics Refer to the HL7 standard for the QBP message of HL7 2.5 Chapter 5 and the general message semantics. Table : QBP^WOS^QBP_Q11 MSH Message header R [1..1] 2 [{SFT}] Software Segment O [0..*] 2 QPD Query Parameter Definition R [1..1] 5 RCP Response Control Parameter R [1..1] 5 [DSC] Continuation Pointer O [0..1] 2 MSH-9 - Message Type (MSG) shall have its two first components respectively valued to "QBP" and "Q11". 34

36 Table : RSP^WOS^RSP_K11 MSH Message header R [1..1] 2 [{SFT}] Software Segment O [0..*] 2 MSA Message Acknowledgement R [1..1] 2 [ERR] Error O [0..1] 2 QAK Query Acknowledgement R [1..1] 5 QPD Query Parameter Definition R [1..1] 5 { --- SPECIMEN begin R [1..*] SPM Specimen R [1..1] 7 [{OBX}] Observation related to specimen O [0..*] 7 [{SAC}] Specimen Container RE [0..1] 13 [ --- PATIENT begin O [0..1] PID Patient Identification R [1..1] 3 [{OBX}] Observation related to the patient O [0..*] 7 ] --- PATIENT end { --- ORDER begin R [1..1] ORC Common Order R [1..1] 4 [{TQ1}] Timing/Quantity RE [0..1] 4 [ --- OBSERVATION REQUEST begin O [0..1] OBR Observation Request R [1..1] 4 [ TCD ] Test Code Details O [0..1] 13 ] } --- ORDER end --- OBSERVATION REQUEST end } --- SPECIMEN end 610 MSH-9 - Message Type (MSG) shall have its two first components respectively valued to "RSP" and "K11". SPM-11 Specimen Role (CWE) in SPM segment shall be coded Q (Control specimen) in the case of a QC AWOS. If the query was not based on the specimen ID, the response shall contain SAC. QPD segment Table : QPD segment 1 60 CE R [1..1] Message Query Name 2 32 ST R [1..1] Query Tag 3 80 EIP C [0..*] SPM-2:Specimen Identification 4 80 EI C [0..*] SAC-3:Container Identification 5 80 EI C [0..1] SAC-10:Carrier Identification 35