Lab f2f Paris May 2014 minutes

From IHE Wiki
Jump to navigation Jump to search

Back to IHE Laboratory Domain

Back to IHE Laboratory Technical Committee Page


Name Organization
Riki Merrick (planning cochair) Vernetzt LLC
François Macary (technical cochair) ASIP Santé
Carolyn Knapik (secretary) CAP
Naomi Ishii Hitachi High-tec
Nobuyuki Chiba A&T
Ken Iguchi Osaka Medical College
Jim Harrison CAP, University of Virginia
Ed Heierman Abbott
Dmytro Rud Roche
Anna Orlova Johns Hopkins University
Laurent Lardin bioMerieux
Xavier Gansel bioMerieux
Anne-Gaëlle Bergé Kereval, IHE Services
Ayman Obeid Medasys
Filip Migom MIPS
Joost Van Averbeke MIPS
Jurgen De Decker MIPS
Gino Bearelle MIPS
Riccardo Triunfo Inpeco SA
Luca Giachetti Inpeco SA
Sylvie Cormont Assistance Publique Hôpitaux de Paris
Pierre Chuzel Syndicat des biologistes
Emilien Klein EPIC

Day 1 Minutes- May 12, 2014

Welcome (Carolyn Knapik- CAP)

Introductions (All)

IHE Lab Overview (Francois Macary) File:LAB Paris Opening FM.pdf

Agenda Review (Francois Macary)

LAW Discussion

  • Looking at Figure 3-1: Have not focused on the fact, if LAW is good at covering middleware to Lab Analyzer Manager or other middleware- to possibly LTW;
  • Beckman Coulter has tested LAW between middleware to analyzer manger to manage multiple instruments;
  • MIPS had issue with the fact that the Analyzer Manager must be able to support the two methods of the query (by specimen ID or by specimen position on the analyzer): LAW has communication about specimen and specimen location, depending on feature where middleware located – barcode labeled specimen vs using position of specimen on plates – use SPM or SAC segment to communicate – not needed in every discipline in lab – in hematology use the barcoded container;
  • LAW on its own does not distinguish between label as well as position – this profile should allow option to chose either barcoded containers or position identified specimen (from analyzer manager viewpoint);
  • Some analyzer managers are specialized for only one – would this be possible to consider as an option in LAW? – New CP!;
  • Biomerieux will submit a similar CP – part of the discussions on how to test for options at connectathon;
  • Adjust publication;
  • LAW – experience in exchanging messages using multi-character sets?;
  • Japan is using 3 character sets – Japanese industry standard; Unicode and micro code set? (see slides from Naomi’s presentation);
  • Declare in MSH-18 – would like a bit more implementation experience with this feature;
  • LAW requires UTF-8 – national extensions are allowed;
  • MSH-20 allows to communicate an alternate character set;
  • Looking at Ed’s slides to introduce LAW background and introduction to IICC.

IICC Tech Status

  • CPs for Trial implementation to be published in Oct 2014;
  • Options where instruments can be creator of patient demographics – how to deal with that, since LAW does not cover being an entry point for orders, with all that patient demographics;
  • ATM1391 and ASTM 1394 = now CLSI standards – idea is LAW to be a successor to LIS 1 and LIS2 style interfaces – Informatics Committee is the sponsoring CLSI body;
  • IVD vendors, federal governments and healthcare providers (lab director hospital, educational institution) – more participation from US, but it is an international SDO for the last 8-10 years;
  • The document development committees have minimal requirements for participation – hospital, IVD vendors, international etc.;
  • They also have an approval process involving CLSI membership and public comment (1 or 2 periods);
  • What about ISO endorsement? Don’t think CLSI currently has that as a goal – don’t think ISO has separate standards development ongoing for this topic;
  • CLSI has the Laboratory Automation Standard – references HL7 Chapter 13 – expect the same to happen for LAW profile;
  • Testing strategy to expand past connectathon testing using the tools used at IHE connectahon;
  • IHE USA has started certification process for specific IHE profiles – in certification roadmap to 2016 LAW is not included at this point – working on getting included;
  • IHE connectathon overview – will add 2013 EU connectahon and Japanese 2013 – 1 analyzer and 3 analyzer managers – will see in afternoon;
  • WHO is very interested in sending list of standards to recommend for implementation tight relationship with ISO – consider reaching out to WHO eHealth initiatives – timeline is 9 months to get this developed

Coffee Break

Open Items from CP (additions to OBR segment)

  • Expand OBR-16 to allow as O fields;
  • Required is OBR-16.1 = ID number consider the use of assigning authority, if the analyzer manager just passes on information from outside - we assume NOT, the analyzer manager is responsible for managing IDs and prevent collision of IDs;
  • Should we provide guidance on when to use assigning authority with the ID – possibly at a different level;
  • OBX-29 new field in v2.8.1 to include type of result – make Mandatory for LAW;
  • Special in LAW – has to be populated – is similar to the R in HL7 and if it is missing MUST cause an Error (stronger than R in HL7, where it can also be ignored when missing) – for all M elements will give guidance if Nullflavors are allowed;
  • Any new values for HL7 table;
  • AOE – vs SCI – solicited answer vs unsolicited answer – may not be important for the analyzer to be differentiated;
  • Consider adding a paragraph about pre-adoption to LAW


IHE Lab Profile Deployment Reports

  • USA: LAW, XD-Lab have been tested at NA Connectathon
  • Europe- see slides
    • LTW LAB-1: workflow dependent for implementation, even if supported in the message – harder to implement than LTW LAB-3;
    • Implementations bring up questions;
    • Where to send SPM, to repeat or not to repeat;
    • How to report interpretations on the susceptibility, when you don’t report actual results?;
    • Must have description for codes of local systems?;
    • How to report Isolation testing – for example beta-lactamase activity?
  • LCC(Jim Harrison) File:LCC IHE May2014-Paris-3.pdf
    • Wouldn’t it make sense when RC is sent to include the filler order number already?;
    • Depends if the filler system wants to create and maintain the ID for recommended orders even when they are declined. Discussion still to be had once profile published for larger feedback;
    • When Filler sends back the accepted order use IP as the order code;
    • If the recommendation expires, then the filler will revert to the original order, that will be handled;
    • How do we track the declined replacement orders when they don’t have any numbers to reference – do not send back, if not accepted – good catch.;
    • Could we use ORC-4 to group the replacement orders together? ORC-4 may already be used to create the requisition, so not necessarily available;
    • Intended to work on orders on the same message;
    • What OBR-25 status should we use in the Hold for review instance? Consider replicating the HR code for OBR-25 as well.;
    • Fulfillment request:
      • REL-2 = relationship type
      • REL-3 = Identifying the source order in EI
      • REL-4 = Identifying the target order in EI
      • EI is problematic for Lab order, which uses EIP to support placer and filler
      • REL-4 could use ORC-4 when follow up on all orders in the group are needed / OBR-2, when all results under one order are referenced / OBX-21 when referring to a specific result
      • What about the prior order group? Only needed for send to third party review.
      • In the proposal for adding REL – we should include taking out the other fields that are listed in the ORC and OBR segments (ORC-8, ORC-50, OBR-26, OBR-49) add parent order / parent reflex
      • There is a request for making ORC-8 repeatable in front of HL7 OO (see Dmytro’s email from 3/3/2014) – should consider together with the REL proposal!
      • The fulfillment order is NOT related to specimen – so do we need to add the REL segment to all the OML message structures, or just to the order centric.
      • May need to adjust planning of LCC publication based on the feedback we get from HL7.
      • How would this use case be handled in FHIR? Need to decide if this use case is ONLY in the 80 % rule if so, then could consider.
  • Feedback from the French WG on microbio vocabularies (Xavier Gansel)File:IHE Xavier May 12 2014.pdf
    • Sylvie is in charge of translating LOINC to French;
    • Add arrow to workflow reporting to PH: From LIS to PH;
    • Do we need to add information to the patient?;
    • In France they have a national health record that is accessible by patients – structured data to professionals only otherwise. Diagram is not representative of all flows.
  • Review of new supplement proposals, and selection (Riki)
    • Further discussion on LDA:File:IHE LAB LDA Presentation.pdf
      • What is the deliverable for this project?
      • Update to LDA, or new interactions to be added to LDA?
      • Currently LDA covers the automation and analytical workflow. Analytical workflow has now been replaced by LAW
      • Pre-or post analytical device – de-capper, aliquoter etc includes status change of the performed step (SWOS)
      • There are other interactions in the pre-analytical/ post-analytical steps:
      • Sample routing for example – need to handle custody of the sample between the track and the analyzer – analyzer draws specimen, then can return to tracker for further steps
      • Should this be part of LDA or become a new profile?
      • LAB-21 (analyzer location can be a parameter in this WOS) and LAB-26 (status change).
      • GLMIS has implementation projects for automation manager: individual instances of analyzers are managed by GLIMS
      • Specimen scanned – AM gives instructions on what to do – 2 options: aliquot or send to analyzer (in sequence, if more than 1) – send to analyzer – LAW – return to track – rescan: options: aliquot or send to analyzer or hold or archive
      • Do we need an intermediate step of “ask analyzer, if ready to perform this test before routing? Not sure this one is covered already.
      • Sounds like re-engineering the LDA profile starting at the use case level – currently only have simple steps described
      • This use case may need additional parameters beyond what is currently supported.
      • Also need to describe interactions between LDA and LAW and if LAW is responsive to the new use cases.
      • Ed’s additional LDA slides about Lab Automation Manager
      • Consider if the Analyzer Manager and Automation Manager should be linked – seems to be more independent. – Or there is a variety of existing implementations
      • Also not necessarily the order filler as the only source for this – would use LTW for this to get information to the analyzer manager / automation managers
      • LIS report status of the test order without results (LTW) – possibly use this for the status update messages in LAW

Open Discussion

  • Support for the project from Beckman Coulter (discussed at NA conntectathon) and here GLIMS, Roche, Biomerieux and Inpeco
  • Trying to find out if Japan has interest in expanding LDA and possibly using other Chapter 13 messages.

Meeting adjourned 5:15 PM

Day 2- May 13, 2014

LDA: GLP Systems (Video Shown by Filip)

  • Several groups expressed support for LDA update – accepted;
  • Project lead: John Hopson – Abbott;
  • Use the diagram and start with the sample hand-off messages first – start with SWOS messages;
  • Relationship between Analyzer Manager vs Automation Manager - leave for later;
  • Start with writing the user story with 2 systems and create example of working up a specimen;
  • Write down the responsibilities of all actors (those we know as well). Then decide if we need new actors / new transactions / looking through Chapter 13 for possible messages for use;
  • John to set up the wiki page skeleton – assign due dates for sections to be completed, review on regular calls;
  • Common set of messages to support the scan and hand off use cases. If I put a sample in the car, need to know the analyzer is ready – included in the definition of what responsibilities does each actor have;
  • Status of analyzer, for transport controller etc – how to handle when analyzer is no longer available prior to hand-off;
  • HL7 always has a fixed sender – receiver – here we need a notification between the actors – looking for service X – analyzers can send interest of providing this service (listener);
  • Possibly use an all query? That also takes time – think more of broadcasting and subscribers responding;
  • Have the scheduler that knows all systems availability and decides where the sample be sent – device has a notification about samples to be tested, giving the device time to query the WOS for the scheduled samples before they get there;
  • How many applications will be involved and how many directions exist between them – suggest to draw boxes around several of these actors to indicate which functions are covered in a single solution, so we actually have fewer actors than what is shown in this slide;
  • QUESTION: Do we create the use case from existing “live” actors or do we approach it theoretically for each actor? Should start with real live situations – taking into account separation of actors actually encountered by the partners;
  • Depending on set up not every transaction will be needed in real live – needs to consider how to set up the connectathon to allow conformance testing – will have to create different options for the connectahon – granularity issue;
  • LTW profile is not granular enough – profile spans too many actors, so may need to set up separate actors to declare each profile that can be supported.
  • Abbot’s viewpoint is what interfaces do the analyzers need to provide – not worried about the upstream connections at the moment
  • System now has LIS and LAS interface – where would the analyzer availability go? Can we add to the LIS interface?;
  • For availability need to ask 4 questions: Do I have power?, Am I calibrated?, Is QC set up?, Do I have the reagents needed?;
  • Set up 3 profiles – but what guidance should IHE profile give for implementation – 3 separate vs allow additional to either LAW or LDA interface – may need a market analysis to get a better picture of what is currently available – may not be much.; and
  • Ricardo (slide)-showing Inpeco flow where scheduler is contained within automation manager-they would need an option where scheduler is “always imbedded”.

Second proposal: Harmonization of US MU specifications and IHE Lab profiles

  • First step create analysis of differences between MU guides and IHE profiles;
  • MU guides are available at DSTU site;
  • Consider long term implications should MU change?

- will need information about changes as early as possible

- compare against IGs build by standards keeper to see, if new ideas can be used to build better profiles

Next step: Propose project to Cross Domain and ultimately to IHE board before proceeding

ACTION: Riki to set up Wiki page for this so folks can review and comment.

Gazelle presentation: (insert Anne-Gaille slides here)

  • Webservices available 24/7 – can validate message during message development as well as use of simulators;
  • Can also download and locally install;
  • Could Gazelle be used as a cloud service to set up virtual connectathon? – Gazelle can act as proxy to forward and keeps a copy of the message that can be validated as well = internet session – not yet advertised much – may need to set up the business model for this and better advertise once decided;
  • New tool of assertion manager – have not yet added LTW, because we are basing the validation on the message – hard in the IG to identify the individual requirements (not enumerated).
  • Need to get more system to connectathons – may be the virtual connectathon would be an option;
  • Consider adding requirement identifiers to help compile the assertions for the assertion manager tool;
  • Assertion Manager has a REST API – will need to get instructions on how to access / implement;
  • What format does report use? – OASIS format testing assertion format language = XML;
  • Value set manager – sometimes it is a challenge to use the existing value sets for LAW testing – could there be a way to identify which value sets apply to what profile stream; and
  • Value sets are test case specific.


Sharing of the NIST tools: (Riki)

Questions for NIST tools:

  • Is there a tool available to further constrain the profiles?
    • NIST is developing a tool (IGAMP) that can properly apply HL7 rules for constraining – in beta testing – or download the XML and change in XML reader (not restricted to HL7 rules)
    • What was the strategy for choosing LOINCs?
      • For LOI used existing LOINCs from labs online sites. In general APHL Informatics approach is to map to most generic LOINC;
      • LIC that helped hospitals to map suggested to map to most specific LOINC;
      • Sharing the Lab flow in regards to LOINC: see Ed’s slide Test Order Route;
      • Several kit vendors want to include – or make publically available on a website or in a spreadsheet – as part of the package insert to provide the possible LOINCs applicable
      • Take this drawing and add on the IHE profiles that apply – as well as other standards available. Also extend the picture to keep the lab detail

ACTION: Riki to send Ed link to S&I Wiki page for aLOINC order code

LAW/LDA improvements: - Japanese slides insert here)

  • Chapter 13 has nice image explaining the carrier / container transport paradigm;
  • Patient Care device WG has a white paper how to maximize messaging for slow moving interfaces proposing an extension for serial connections (still need to support) HL7 messages in LMOP with integrity checks and make all optional fields not supported to slim down the HL7 messages – need to check the recommended lower layer protocols per HL7 standards, too;
  • Normally no consistency check in serial interfaces;
  • Agree that LDA improvement is a good project, but is HL7 the right choice over TCP/IP connections may need more market analysis if HL7 is the choice to follow;
  • MU regulation showed that when standards are written into regulation, they are being implemented – we need a good list of available standards for EHR-systems and LIS for the WHO e-health initiative
  • Need to make sure IHE can provide the list of standards for countries – need to bring this up to ISO because that’s what countries look for. Need strategy for the roadmap for the next 5 years;
  • ACTION: Anna to provide primer of WHO e-health initiative – follow up with Ramesh for discussion on next call;
  • Should probably also reach out to CLSI to get the existing standards in addition – CLSI has document on security of IVD systems – should get their standards as well.
  • CP for existing LDA: Need to add NTE after OBR – for tomorrow;
  • LAW: work on CPs please review the current documents: Proposed changes are posted on Wiki <a href=""></a> ; and
  • Clarifications, coding systems, error handling, length

Focus on Order and Observation: TCD

  • Specimen pooling: current use case covers specimen has already been pooled, listing the sample IDs (which if you count how many IDs = number of pooled samples);
  • New use case to X.2.9: indicate that samples are allowed to be pooled and how many can be pooled – still have to write this up in addition to the proposed HL7 fields to be added – this applies to clinical chemistry so give that as example;
  • Pooling should be handled on the instrument only – not sure we need to cover that in the LIS or the analyzer manager – that workflow should be ONLY in the analyzer;
  • Bundling of optionality?;
  • barcodeIDs, or container location, or isolate ID – not all analyzer managers talk to instruments that need this use case to support tray position support, as that can be discipline dependent. For isolate SAC-3 is not the unique across different samples - unique ID for LIS is the SAC-4 plus SAC-3 ONLY! Could use the plate ID or the specimen ID – how to differentiate between the two? Use identifier type ode – may need new code for plate ID;
  • Work through the profile on analyzer manager side to identify options and list those out by functionality support;
  • Decided to use SAC to cover the tracking instead of suing the SPM – reasoning was that SAC is more flexible, as in some cases the identifier is for the specimen vs container/plate;
  • Currently we have several C usages – could consider creating different profiles for all additional (besides barcode) features that analyzers could support. Consider using the different message query name in the query message to indicate the option the system supports – make the barcode approach mandatory, and leave the others optional;
  • Support: tray location, carrier location and isolate;
  • Problem is not only in the queries, but also in the result – need to consider how to handle the option display;
  • Can report the additional information back with the result – main linkages is the AWOS ID that carries the linking power;
  • List these query options under x.5 – bidirectional is still and option, but IF you support bi-directional then you MUST support he WOS query option;
  • ACTION: Laurent will update the wiki and prepare the CP accordingly;
  • Make WOS_ALL a separate query? Yes as an option;
  • Pooled specimen should be an optional profile to support, right?;
  • Once pooled no longer PID information in this message – need to check, if we have this indicated in the message structure;
  • Analyzer requirement for SPM-11 is M – if systems need to support ‘L’ – ;
  • HL7 Vocab is working on creating a standards framework to declare value sets more clearly in specifications that we can then apply (example to list ‘L’ as permitted vs. required vs. excluded);
  • May have to declare a profile – then can create a test case for this specifically; and
  • Need a market analysis on what IVD vendors can support in terms of pooling, if there is even a desire to create this option.

Ordering of replicates:

  • Option1: Use TQ1 to list how many times to re-run a test;
  • Option 2: Do not include in use case, make Analyzer keep track of the replicates – send as separate AWOS;
    • Chose Option 2 – so update the CP accordingly and also provide a paragraph explaining this – where to place? In Vol 2 next to re-run section or at bottom of that section (W2.X). Dmytro to do;
    • Result Aspect – use specific codes to indicate the aspect included with the code in OBX-3. Found this issue in v.2.5.1 (still the same in v2.8);
    • If this is an interpretation can also go into OBX-8;
    • Drop fragments and then create a new IHELAW code as addition to the supplemental codes?; and
    • Also consider section 7.2.4 – Suffixes for Defining Observation IDs For Common Components of Narrative Reports.


Day 2 Presentations:

Day 3- May 14, 2014

Agenda Review

IICC Technical Status Update - see presentations below

Follow-up on "ordering using OBR/OBX" discussion from Tokyo (Nobuyuki, Filip)

  • OBX-Suffixes
    • Table with the suggested suffixes is labeled Figure;
    • Adding the “&” to the code seems to be overloading the String element again; Can this be used also for ordering – in the use case of LCC Fullfilment –Would be for ordering to the LIS – IVDs would not expect different types of orders – 1 order only for the IVD;
    • ACTION: Need to make decision to add on to the LOINC in OBR-4 or in additional OBR-49 field;
    • IVD can send 1-3 results for each order – numeric result, interpretation and possibly a cut-off value (this could also be sent in the Ref range OBX-7);
    • No advantage in using the ‘&’ over more specific LOINC
    • This suffix addition has been deprecated in v2.8 in favor of using correctly coordinated LOINC
  • Multiple OBXes-Qualitative:
    • Interpretation (OBX-5 with different code for the numeric) or OBX-8 for the numeric it applies to – ordinal; and
    • Coded elements (CE), OBX-5 – nominal or ordinal

  • Quantitative: Numeric (NM), structured numeric (SN), numeric array (NA)

  • Supplemental: Image, graph, raw value

  • Narrative:
    • String (ST) or text (TX);
    • Historical the instruments use a single ID for each assay – then they add a subcomponent to identify what is sent;
    • Rule: use different codes for the subcomponents – as long as a you don’t use the HL7 delimiters (or escape those);
    • If there is a value in HL70078 that works for interpretation – must use OBX-8, otherwise create a separate OBX segments and send your interpretation with a new code (LOINC preferred) as a result in OBX-5 – or should we allow OBX-8 to be extended – we should allow extending OBX-8 with vendor codes; and
    • No more result fragments in LAW!
  • Patient Demographics:
    • Allow vendors to extend LAW with optional segments that are allowed in the standard – for conformance testing need to not support them – or do we want to create another option for testing;
    • Currently for information flow from LIS to analyzer manager (LAB-4) we are not supporting NTE after PID, not sure we should support it the other way around;
    • Use the same approach as we do in LAB-1 – use a separate OBR to send patient information and send OBX with ST or TX, if you really need to send it on.

  • Profile options:
    • Need to review the LAW specifications and identify all the elements that should be in the base profile component;
    • Use MSH-21 repeats to declare adherence to specific optional profile components to create the profile you are supporting;
    • Will need to add a column to the tables to add comments and CPs as well;
    • For demographics are we comparing the data elements to PIXPDQ? Riki too double check (ACTION)

Result Progression – Francois to take lead for CP:

  • When the result is invalid and the analyzer will not repeat and still want to report the result. Will use the Section from the technical framework and how that applies to LAW;
  • ORC-5 – set to CM for complete and send OBX-11 = R – will possibly add all the allowable combinations and the explanations for how to interpret this;
  • Or do we want to add another code to indicate result was found invalid compared to not evaluated and just sent; and
  • Consider using HR = hold for review for the invalid? Used in LCC for ORC-5

CP on existing LDA:

  • Query Response message - used to transfer orders in response message – wanted to add the NTE for ORC and OBR to match the OML^O33.
  • In LAW we are already supporting both as this – pre-adopted from v2.9
  • All agree on this CP – Francois to update the docs and upload to sFTP (ACTION)

Wrap up:

  • Webinar – need date and Riki to figure out when (ACTION)
  • LCC – need to update the publication calendar to move to 2015 (ACTION)
  • LDA: John Hopson to write use cases for incremental approach – based on real life solutions (ACTION)
  • LAW: Pull out from meeting minutes all action items – optional will be part of R1.4 for Oct 2014 (ACTION)
  • Write CPs – Ed, Francois, Dmytro, Laurent (ACTION)
  • Identify the profile options (ACTION)
  • Harmonization of MU lab profiles to IHE LTW and LCD
  • Prepare gap analysis, then evaluate new actions from there – need to also reach out to ONC and HL7 project (ACTION)
  • At the next IHE Board meeting report on HL7 IGs and IHE Lab Profiles (ACTION)
  • IHE Lab Committee Meeting is Second Tuesday of the month (June 10) – Carolyn will update to new conference call number will keep that timeslot (ACTION)

Next F2F- Possible Dates

  • November 2014 in Chicago – possibly coordinate with AP group – Carolyn to check dates; or AMIA is 15-19 of November – so suggest 11/10 – 11/12/2014 in Deerfield


Day 3 Presentations: