Established Profile for connectathon 2005: L aboratory S cheduled W ork F low

1. Integrating the Healthcare Enterprise 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) IHE Interoperability Workshop

2. Laboratory Technical Framework Volume 1 IHE 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) IHE 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. IHE Interoperability Workshop

5. Laboratory Scheduled WorkflowActors • 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. IHE Interoperability Workshop

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

7. * In case the LIS encompasses both Order Filler and Automation Manager transactions LAB-4 and LAB-5 are irrelevant. IHE 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 IHE 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 IHE Interoperability Workshop

10. Laboratory Technical Framework Volume 2 IHE Interoperability Workshop

11. Choice of the standard See Vol 2 section 1.1 • 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 IHE Interoperability Workshop

12. HL7 v2.5 profiling conventions See Vol 2 section 2.2 • 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” IHE Interoperability Workshop

13. Example of message static definition Specimen Segment group IHE Interoperability Workshop

14. Example of segment description IHE Interoperability Workshop

15. Condition predicates for « usage C » fields See Vol 2 section 3.9 SPM-2 Specimen ID (EIP), conditional. 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 2.3.5.1 for the details of the data type. IHE Interoperability Workshop

16. Common segments descriptions See Vol 2 section 3 • 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 IHE Interoperability Workshop

17. HL7 conventions on empty fields If the value of a field is not present, the receiver shall not change corresponding data in its database. 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. See Vol 2 section 3.9 PID|1||6543210 OBX|1|NM|14996-3^^LN||””|umol/l Of course this is forbidden with fields marked with usage R IHE Interoperability Workshop

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

19. Watch the 4 examples of section 9 For implementers: One of the most helpful parts of Laboratory Technical Framework. • 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. IHE Interoperability Workshop

20. 1st example: Two hematology batteries IHE Interoperability Workshop

21. 1st example: Two hematology batteries IHE Interoperability Workshop

22. Two hematology batteries: One message IHE Interoperability Workshop

23. Acknowledgements with MLLP (1) See Vol 2 section 2.3 • 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 IHE Interoperability Workshop

24. Acknowledgements with MLLP (2) Results validated Order Filler Application Order Result Tracker Application ACK Message OUL Message OUL ACK <SB> message <EB><CR> MLLP Initiating module MLLP Accepting module <SB> acknowledgement <EB><CR> • 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. IHE Interoperability Workshop

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

26. Approved change proposals for connectathon 2005 IHE Interoperability Workshop

27. Approved change proposals for connectathon 2005 These Change Proposals will be integrated in version 1.2 FT published on www.ihe-europe for March 1st Volume 2 version 1.1 FT CPs 17-21, 24, 27-29 Volume 2 version 1.2 FT IHE Interoperability Workshop

28. Thank you for your attention… IHE Interoperability Workshop