February 7-10, 2005IHE Interoperability Workshop 1 Established Profile for connectathon 2005: Laboratory Scheduled WorkFlow Francois Macary GWI Medica France (Agfa Healthcare IT) cochair IHE Laboratory Committee The other cochair is Yoshimitsu Takagi (Hitachi) Integrating the Healthcare Enterprise

February 7-10, 2005IHE Interoperability Workshop 2 Laboratory Technical Framework Volume 1

February 7-10, 2005IHE Interoperability Workshop 3 Scope of LSWF profile Integrate the clinical laboratory in the healthcare enterprise Workflow: Ordering, placing, scheduling, performing clinical laboratory tests, and delivering the results. In vitro testing: All specialties working on specimen, not on the patient itself. Bound to clinical biology (anatomo-pathology excluded)

February 7-10, 2005IHE Interoperability Workshop 4 LSWF: Three major use cases Externally placed order with identified specimens  The ordering provider collects the specimens and uniquely identifies them (in the message placing the order as well as on the container with a barcode label) Externally placed order with specimens unidentified or to be collected by the laboratory  The specimens are unidentified within the message placing the order Filler order with specimens identified by the laboratory  The order is created in the laboratory, and afterwards a number is assigned to it in the placer application.

February 7-10, 2005IHE Interoperability Workshop 5 Laboratory Scheduled Workflow Actors ADT - Manages patient related information (demography, location, visit). Provides other actors with up to date information. Order Placer - Registers orders for clinical laboratories, places an order to the selected Order Filler. Keeps the order status up to date along the process. Order Filler - Receives orders, schedules them and splits them into Work Orders addressed to one or more Automation Managers. Performs the clinical validation. Sends the results to one or more Order Result Trackers. Automation Manager - Receives Work Orders from Order Filler, processes ordered tests, stores the results, performs the technical validation, and sends results back to the Order Filler. Order Result Tracker - Centralizes the results from one or more Order Fillers.

February 7-10, 2005IHE Interoperability Workshop 6 LSWF: Actors and Transactions Order FillerOrder Placer Order Result Tracker ADT Lab-1: Placer order Lab-2: Filler order Rad1, Rad-12: Patient Demographics Lab-5: Results Rad-1, Rad-12 Lab-3: Results Lab-4: Work order Clinical Laboratory Automation Manager Technical validation Clinical validation

February 7-10, 2005IHE Interoperability Workshop 7 ActorsTransactionsOptionality ADTPatient demographics [RAD-1, RAD-12] R Order PlacerPatient demographics [RAD-1, RAD-12] R Placer Order management [LAB-1] R Filler Order Management [LAB-2] R Order FillerPatient demographics [RAD-1, RAD-12] R Placer Order management [LAB-1] R Filler Order Management [LAB-2] R Order result management [LAB-3] R Work Order management [LAB-4] R* Test results management [LAB-5] R* Automation Manager Work order management [LAB-4] R Test result management [LAB-5] R Order Result Tracker Patient demographics [RAD-1, RAD-12] R Order result management [LAB-3] R * In case the LIS encompasses both Order Filler and Automation Manager transactions LAB-4 and LAB-5 are irrelevant.

February 7-10, 2005IHE Interoperability Workshop 8 Order management in LSWF profile Two parallel flows to keep synchronized  Electronic: The order  Material: The specimen(s) required to perform the order A dynamic process  Specimen added by the placer to a running time study  Specimen rejected by the filler (damaged or spoiled), tests held in wait for a new specimen  Unordered test added by the filler (e.g. antibiogram in microbiology) Order Placer and Order Filler must keep the same vision of the order (content and status) all along the process

February 7-10, 2005IHE Interoperability Workshop 9 Results management in LSWF profile Results can be transmitted at various steps  After technical validation (by the lab technician)  After clinical validation (by the clinical expert) Requirement to keep Order Result Tracker informed with all changes occurred to results previously sent  Send corrections  Send validation or un-validation  Send cancellation Other characteristics  Result type: Numeric, coded, textual, graphical (electrophoresis)  Results are sent in recapitulative mode, appropriately sorted See Change Proposal 24

February 7-10, 2005IHE Interoperability Workshop 10 Laboratory Technical Framework Volume 2

February 7-10, 2005IHE Interoperability Workshop 11 Choice of the standard Need for an international standard, fully implementable with guides and tools ready for use  Excluded HL7 v3 Supporting specimen and container management  Excluded v2.3.1 and v2.4 Choice of HL7 v2.5, released a while before IHE Lab TF (end 2003) HL7 v2.5 Transactions LAB-1, LAB-2, LAB-3, LAB-4, LAB-5 HL7 v2.3.1 Transactions RAD-1, RAD-12 Vertical bar encoding shall be supported. XML encoding may be supported See Vol 2 section 1.1

February 7-10, 2005IHE Interoperability Workshop 12 HL7 v2.5 profiling conventions Static definition: Usage of segments and fields  R: Required  RE: Required but may be empty  O: Optional = Usage not defined yet  C: Conditional (condition predicate in the textual description)  X: Not supported. Must not be sent. For a better readability:  Segments with usage X do not appear in message tables  Fields with usage O do not appear in segment tables Cardinalities of segments, segment groups and fields:  Min and max between square brackets: [0..*]  * stands for “no upper limit” See Vol 2 section 2.2

February 7-10, 2005IHE Interoperability Workshop 13 Example of message static definition Specimen Segment group

February 7-10, 2005IHE Interoperability Workshop 14 Example of segment description

February 7-10, 2005IHE Interoperability Workshop 15 Condition predicates for « usage C » fields This field contains a unique identifier for the specimen, enterprise- wide. Condition predicate: This field shall be populated in OML messages of transaction LAB-1, in the context of the use case "Externally placed order with identified specimens" defined in volume 1. This field is required in OML messages of LAB-2 transaction. It may also be used in transaction LAB-3. This field is required if known (RE) in transactions LAB-4 and LAB-5. Please refer to section for the details of the data type. SPM-2 Specimen ID (EIP), conditional. See Vol 2 section 3.9

February 7-10, 2005IHE Interoperability Workshop 16 Common segments descriptions MSH – Message Header MSA – Message Acknowledgement ERR – Error NTE – Notes and Comments PID – Patient Identification PV1 – Patient Visit ORC – Common Order TQ1 – Timing Quantity  Only one TQ1 per order  One single execution per order SPM – Specimen SAC – Container Detail OBX- Observation/Result See Vol 2 section 3

February 7-10, 2005IHE Interoperability Workshop 17 HL7 conventions on empty fields See Vol 2 section 3.9 PID|1|| If the value of a field is not present, the receiver shall not change corresponding data in its database. OBX|1|NM| ^^LN||””|umol/l If the sender defines the field value to be the explicit NULL value (i.e. two double quotes ""), it shall cause removal of any values for that field in the receiver's database. This convention is fully applied by the Laboratory Technical Framework. Of course this is forbidden with fields marked with usage R

February 7-10, 2005IHE Interoperability Workshop 18Vocabulary  a CBC (complete blood count)  an electrolye (Na, K, Cl)  a creatinine clearance Order Placer allocates an Identifier to each ordered battery Order Filler allocates an Identifier to each accepted battery The physician places a lab request. The Order Placer allocates the unique Id “123” to this request consisting of: Laboratory request 123 Placer Order Number (ordered battery) ordered battery Filler Order Number (accepted battery) F101 F102 F103 accepted battery F103

February 7-10, 2005IHE Interoperability Workshop 19 Watch the 4 examples of section 9 Each example is using the same layout:  Storyboard  List of human actors and organizations  Ids and numbers  List of interactions  Interaction diagram  Messages with key information highlighted. For implementers: One of the most helpful parts of Laboratory Technical Framework.

February 7-10, 2005IHE Interoperability Workshop 20 1st example: Two hematology batteries

February 7-10, 2005IHE Interoperability Workshop 21 1st example: Two hematology batteries

February 7-10, 2005IHE Interoperability Workshop 22 Two hematology batteries: One message

February 7-10, 2005IHE Interoperability Workshop 23 Acknowledgements with MLLP (1) An OML message shall be acknowledged by one single ORL message. An OUL message shall be acknowledged by one single ACK message. These acknowledgements are application-level acknowledgements (i.e. not transport acknowledgements) and must be generated by the receiving application after it has processed the message semantic content, according to its own business rules. Intermediate message brokers do not have this capacity and therefore shall not be used to generate the contents of application acknowledgements. The receiving application shall automatically generate the application-level acknowledgement messages without waiting for human approval of the contents of the message that was received See Vol 2 section 2.3

February 7-10, 2005IHE Interoperability Workshop 24 Acknowledgements with MLLP (2) A MLLP (Minimal Lower Layer Protocol) network connection is unidirectional. Event-triggered messages flow in one direction and related acknowledgement messages flow in the other direction. The acknowledgement message to an event-triggered message shall be sent immediately to the sender on the same MLLP connection that carried the event-triggered message. Results validated Order Filler Application MLLP Accepting module MLLP Initiating module Order Result Tracker Application acknowledgement ACK message Message OUL

February 7-10, 2005IHE Interoperability Workshop 25 Accepting module Initiating module Accepting module Initiating module Order Placer application Acknowledgements with MLLP (3) Transactions with trigger events on both sides (e.g. LAB-1) New placer order OML^NW ORL^OK Order Filler application Order Status change OML^SC

February 7-10, 2005IHE Interoperability Workshop 26 Approved change proposals for connectathon 2005 CP # Content 17Acknowledgements in LAB-1 and LAB-2 deliver an order number. These applicative acknowledgments have to be generated by the receiving application immediately, not by message brokers (which can still be used for transport) 18Incorrect message type in LAB-3 messages of the “Glucose tolerance study” example: Message structure OUL^R22 is to be replaced with OUL^R24 19 Typo in “Glucose tolerance study” example: “Gucose”  “Glucose” 20Inversion of segment order in some of the example messages (9.3, 9.4, ). In OUL messages, OBR must precede ORC, because OBR is the required segment. Underlying reason given in HL7 chapter 2: c): « c) The first segment in a newly-defined segment group, as of v 2.5, must be marked as required.” 21Correct the position of OBX in the LAB-3 example messages of “glucose tolerance study”.

February 7-10, 2005IHE Interoperability Workshop 27 Approved change proposals for connectathon 2005 CP # Content 24Precision on recapitulative mode in Lab-3: the Order Filler shall transmit all available results for the battery (if OUL^R24) or specimen (if OUL^R22) in recapitulative mode whether they have already been transmitted or not. 27OBR-10 « Collector Identifier » in LAB-3 messages should be RE instead of X 28Clarifies condition of use of SPM/SAC segment group within OML^O21 in LAB-4 29Correction of some ISO+ units in the example messages These Change Proposals will be integrated in version 1.2 FT published on europe for March 1 st Volume 2 version 1.1 FT CPs 17-21, 24, Volume 2 version 1.2 FT

February 7-10, 2005IHE Interoperability Workshop 28 Thank you for your attention…