february 7-10, 2005ihe interoperability workshop 1 established profile for connectathon 2005:...
Post on 11-Jan-2016
212 Views
Preview:
TRANSCRIPT
February 7-10, 2005 IHE Interoperability Workshop1
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 EnterpriseIntegrating the Healthcare Enterprise
February 7-10, 2005 IHE Interoperability Workshop2
Laboratory Technical Framework Volume 1
February 7-10, 2005 IHE Interoperability Workshop3
Scope of LSWF profileScope 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, 2005 IHE Interoperability Workshop4
LSWF: Three major use casesLSWF: 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, 2005 IHE Interoperability Workshop5
Laboratory Scheduled WorkflowLaboratory Scheduled WorkflowActorsActors
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, 2005 IHE Interoperability Workshop6
LSWF: Actors and TransactionsLSWF: Actors and Transactions
Order FillerOrder Placer
Order Result Tracker
ADT
Lab-1: Placer orderLab-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
Clinicalvalidation
February 7-10, 2005 IHE Interoperability Workshop7
Actors Transactions Optionality
ADT Patient demographics [RAD-1, RAD-12] R
Order Placer Patient demographics [RAD-1, RAD-12] R
Placer Order management [LAB-1] R
Filler Order Management [LAB-2] R
Order Filler Patient 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, 2005 IHE Interoperability Workshop8
Order management in LSWF profileOrder 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, 2005 IHE Interoperability Workshop9
Results management in LSWF profileResults 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, 2005 IHE Interoperability Workshop10
Laboratory Technical Framework Volume 2
February 7-10, 2005 IHE Interoperability Workshop11
Choice of the standardChoice 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, 2005 IHE Interoperability Workshop12
HL7 v2.5 profiling conventionsHL7 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, 2005 IHE Interoperability Workshop13
Example of message static definitionExample of message static definition
Specimen Segment group
February 7-10, 2005 IHE Interoperability Workshop14
Example of segment descriptionExample of segment description
February 7-10, 2005 IHE Interoperability Workshop15
Condition predicates for « usage C » fields 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 2.3.5.1 for the details of the data type.
SPM-2 Specimen ID (EIP), conditional.
See Vol 2 section 3.9
February 7-10, 2005 IHE Interoperability Workshop16
Common segments descriptionsCommon 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, 2005 IHE Interoperability Workshop17
HL7 conventions on empty fields HL7 conventions on empty fields See Vol 2 section 3.9
PID|1||6543210 If the value of a field is not present, the receiver shall not change corresponding data in its database.
OBX|1|NM|14996-3^^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, 2005 IHE Interoperability Workshop18
VocabularyVocabulary
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)
12345
12346
12347
ordered battery 12347
Filler Order Number
(accepted battery)
F101
F102
F103
accepted battery F103
February 7-10, 2005 IHE Interoperability Workshop19
Watch the 4 examples of section 9Watch 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, 2005 IHE Interoperability Workshop20
1st example: Two hematology batteries1st example: Two hematology batteries
February 7-10, 2005 IHE Interoperability Workshop21
1st example: Two hematology batteries1st example: Two hematology batteries
February 7-10, 2005 IHE Interoperability Workshop22
Two hematology batteries: One messageTwo hematology batteries: One message
February 7-10, 2005 IHE Interoperability Workshop23
Acknowledgements with MLLP (1)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, 2005 IHE Interoperability Workshop24
Acknowledgements with MLLP (2)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
<SB> acknowledgement <EB><CR>
ACKACK
<SB> message <EB><CR>
Message OUL Message OUL
February 7-10, 2005 IHE Interoperability Workshop25
Accepting module
Initiating module
Accepting module
Initiating module
Order Placer application
Acknowledgements with MLLP (3)Acknowledgements with MLLP (3)Transactions with trigger events on both sides (e.g. LAB-1)Transactions with trigger events on both sides (e.g. LAB-1)
New placer order
OML^NW OML^NW
OML^NW
ORL^OK
ORL^OK
ORL^OK
ORL^OK
ORL^OK
ORL^OK
Order Filler application
Order Status change
OML^SC
OML^SC
OML^SC
February 7-10, 2005 IHE Interoperability Workshop26
Approved change proposals for connectathon 2005 Approved change proposals for connectathon 2005
CP #
Content
17 Acknowledgements 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)
18 Incorrect 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”
20 Inversion of segment order in some of the example messages (9.3, 9.4, 9.5.3.3). In OUL messages, OBR must precede ORC, because OBR is the required segment. Underlying reason given in HL7 chapter 2: 2.8.1 c): « c) The first segment in a newly-defined segment group, as of v 2.5, must be marked as required.”
21 Correct the position of OBX in the LAB-3 example messages of “glucose tolerance study”.
February 7-10, 2005 IHE Interoperability Workshop27
Approved change proposals for connectathon 2005 Approved change proposals for connectathon 2005
CP #
Content
24 Precision 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.
27 OBR-10 « Collector Identifier » in LAB-3 messages should be RE instead of X
28 Clarifies condition of use of SPM/SAC segment group within OML^O21 in LAB-4
29 Correction of some ISO+ units in the example messages
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
February 7-10, 2005 IHE Interoperability Workshop28
Thank you for your attention…
top related