PaLM F2F Minutes 2016-Nov 09-11

Back to IHE Pathology and Laboratory Medicine (PaLM) Domain

Back to IHE Pathology and Laboratory Medicine (PaLM)Technical Committee Page

Recording

The recordings for this meeting can be downloaded here:

• Wednesday, 09 November 2016
• Thursday, 10 November 2016
• Friday, 11 November 2016

Attendees

Name	Company	09-Nov	10-Nov	11-Nov
Raj Dash	CAP, planning co-chair	X	X	X
Gunter Haroske	IHE Germany	X(tc)	X(tc)	X(tc)
Ed Heierman	Abbott	X	X
Naomi Ishii	JAHIS / Hitachi High-Tech	X(tc)
John Hopson	Abbott	X	X	X
Mary Kennedy	CAP, board representative	X	X	X
Carolyn Knapik	CAP, secretary	X	X	X
Megumi Kondo	Sakura Finetek Japan	X	X	X
Laurent Lardin	bioMerieux	X	X	X
Alessandro Sulis	CRS4	X(tc)	X(tc)	X(tc)
Francois Macary	Phast, technical co-chair	X	X	X
Juho Yamamoto	IHE-J (NIHON KOHDEN)	X	X	X
Riki Merrick	APHL, planning co-chair	X	X	X
Filip Migom	MIPS	X	X	X
Dmytro Rud	Roche	X(tc)	X(tc)	X(tc)
Kenichi Takahashi	JAHIS (Hitachi High-Technologies)	X	X	X
Francesca Frexia	CRS4	X(tc)
Francesca Vanzo	Arsenal IT	X(tc)	X(tc)	X(tc)
Sabrina Krejci	CAP	X	X	X
John David Nolen	Cerner	X	X	X(tc)
Andrea Pitkus	IMO	X	X	X
Dan Rutz	Epic	X	X	X
Doug DeShazo		X(tc)
James Wulkan	Beckman Coulter	X(tc)		X(tc)
Victor Feria		X(tc)
Ross Simpson	CAP		X(tc)
Rich Moldwin	CAP		X
Sam Spencer	CAP	X(tc)	X
(tc) = Teleconference

Action Items/Wrap-Up

Action Items/ Wrap - Up

SET:

• Have defined all use cases, will add on the derived specimen – complete Vol 1 by Dec 2016 and review on that call
• Create first draft of Vol 2 data model for Jan 2017
• Public comment in September 2017
• Trial implementation in January 2018

LSH:

• Write Vol 1 and Vol 2, make it coincide with the SET publication
• Update profile document on wiki
• Contact Gazelle team regarding simulator testing
• Public comment in September 2017
• Trial implementation in January 2018

LCC:

• Aim for April 2017 for group review
• Timeline dependent on HL7

APSR 2.0:

• Public comment in September 2017
• Trial implementation in January 2018

New Proposals

• Call for Proposals comes out 11/15/2016
• Proposals due by 12/31/2016

Blood bank should come as a new proposal prepared by Filip and Dan

• Review at January meeting
• Selection Feb 8, 2017

PaLM Milestones updates

• # of supplements = 4
• publish 9/18; give longer review period, so close date of 10/23
• publish supplements Jan 8, 2018 with no republication requests
• 1 TF, publish June 2017
• white paper – remove from 2016 table and plan on publishing Dec, 15, 2017

---

 

Minutes

Attachments for all documents mentioned below available via zip file at HERE

Minutes November 09:

Welcome

Introductions All Around

Election Update: New Co-Chairs are Francois for Technical and Riki for Planning

 

International meeting Update - please pay dues for 2016/17 if not yet done

 

IHTSDO Update  

• There has not been anything new
• Any “observable entity” we want to add to SNOMED CT for lab needs to go to Regenstrief. LOINC is the terminology for observables.
  • This will need follow up – not sure if this applies to specimen type and related terms
• The question was more about the development license that IHTSDO has with HL7 and use of the SCT codes in guides
• Discussion about LOINC, SCT, or data element registry use

 

SET profile review (attach SET_F2F_Chicago_NOV2016.pptx)

• Example of macro activities = in vitro diagnostic testing of the specimen: need to process specimen prior to testing
• Whose scope is it to define the specimen collection event? We will need to identify the information to be tracked about the specimen collection – need to do that for all events – important use cases would be referral between labs or specimen collection from a patient
  • The scope of IHE profiles is the interaction between 2 systems, but not how that information is used in the systems
• Pathology workflow should be generic = derivation of specimen, as it also applies to micro
• Keep “aliquots” separate from “derived”
• Should be valid for both Anatomic Pathology (AP) and Clinical Pathology (CP)
• Specimen retrieved – (query initiated and when specimen is shipped)-  need to decide if the use case starts with the retrieval part or should it include the query
• How do we deal with the unexpected event? Do we need to cover when specimen was dropped but not rejected?
• Other specimen event - design to allow collection of unexpected events/ exception handling
• Regarding LSH – need to support  every potential scenario
• Specimen collection use case #1
  • Part of the LBL profile is the creation of the specimen container, but pretty specified for just the labeling part, so created this profile
  • In the specimen collection event could include comment on exception (for example the collection volume is not what is expected and a reason for that) – would need patient, order, collection specific elements (those can depend on the type of specimen collected), exception reason; EXCLUDE optimization of collection process (multiple orders combined for collection is not part of that).
• Use case #2 has 3 flows = with or without (not sure this would happen very often) re-identification by receiver and then specimen rejection
  • Not sure the sender will do much with the receivers’ ID, except as part of the result in order to support follow up
  • We decided to track the events both within and across the organizations – but we wanted to support, if wanted – can decide which of these transaction MUST be supported, while others are optional
  • May need to include a note, that some of the data elements shared with this use case may depend at what state the specimen was exchanged between organizations
  • Need to consider the provenance change as part of this profile
  • Issue with single specimen vs multiple specimen in this use case? Handling with the packaging list – individual items are grouped; HL7 has a shipping message, but not sure it handles the individual specimen – should we just adopt FedEX process for this
  • What about digital specimen where one lab does upstream work and then another lab will do downstream work (for next generation sequencing information will need complex results attached with the specimen) -> deal with that in the digital pathology workflow
• Homework: review if use cases #2 and #3 can be merged

 

AUTO16 update

• Draft of AUTO16 (aka LAW) has been submitted to Clinical and Laboratory Standards Institute (CLSI) for vote initiating in December. Workflow as follows: open for 60 days, then address comments, and after that will have 30 day final vote to get it published (hopefully) in time for AACC 2017 announcement.
• Currently running about 5 months behind schedule. Hope to have AUTO16 ready by July 2017.
• Sections 1 and 2 are added by IICC – from technical framework and historical information
• Section 3 is verbatim LAW, but slightly different organization
• Added a few guidance elements that would be useful for users – example additional segments and fields may be added per HL7 rules, etc. – may consider CPs to add to TF in future
• Some grammar fixes that will result in CPs for TF in the future
• Section 4: Security considerations of the interface
• Section 5: Conclusions
• Supplemental information: several examples were checked (from James Wulkan, Dmytro Rud,  Gazelle)
• Appendix information added as required by CLSI
• The use of TCD to handle dilutions in re-run. – Ed and Francois to draft a CP to add a usage note for LAW  (not a substantial change, just clarification)
• Suggestion to revise the title, since in the laboratory world “Next Generation” has a different meaning  (Next Generation Sequencing (NGS))
• Question from Bill Williams – how did we establish the usage of some optional fields – example PV1 patient location (RE) vs OBR-2 (RE.AN), some information sent by the AM, but is not echoed back by analyzer
• Should echo back to the sender, if it was used as part of the result interpretation it should be echoed back -> may result in CPs for Usage Note

 

FDA/CDC/NLM/ONC meeting on 11/8/2016 (attach 2 documents: IICC Proposal for LOINC Publication.pdf + Digital Format for Publication of LOINC for Vendor IVD Tests (Draft) 2016-11-03.pdf)

• LOINC use in OBX-3 is what we need to capture. It does NOT cover ordering from LIS to the instrument  as OBR-4 coding is Out of Scope. Need to discuss if LOINC could be used for that in the future, or what other code system might be used
• Round 1: Table description for excel PLUS the electronic format for exchange between LIS and the instrument (which may or may not need ALL the information that the human readable version needs)
• Currently result values and coded units of measure are out of scope
• ALL the information that affects selection of LOINC parts should be in the vendor comment  (i.e. detection limits)
• Need to update the diagram to show more than one LOINC can be used
• For JSON format, need to be sure we establish the grouping and recurrence based on JSON rules
• Need to nest the localization of analyte name in a group in the schema
• LOINC covers too many parts in the pre-coordinated codes:
  • Use case of creating a list of clinically comparable results is currently not being addressed
  • Currently have an extensional list of codes that are applicable for that
  • What do I send to the instrument, what do I get from the instrument, what do I send to the doc – this covers the last part
  • Parts needed by the instrument: method, property, scale and component (though there are subcomponents that the instrument may not know).
  • Automating the mapping requires additional elements such as transmission code, specimen description (not from the instrument)

 

APSR 2.0 (attach 20161112_APSR_2_0_3bigPictures_reworked.pptx)

• Can we have an addendum to an initial / preliminary report? Preliminary report included in final report
• APSR and XD-Lab do support preliminary and final, and support any number of amended reports (complete snapshot complementing or correcting the previous version)
• Need to cover preliminary, final, amended, appended, corrected
• Have to deal with the labs sharing only the delta or sending the complete snapshot – receiver must display all content together
• Meant to be used with document exchange XDS or point to point message profile XDM –meta data is present if addendum or replacement
• Audit trail can be provided in the XDS/XDM  - you can identify if you need the series or the latest version
• Introduction to new code systems used in APSR on the wiki:
  • IHE Actcode is used in data element template annotation comment – if we need the annotation comment (created by PCC domain) will have to check to use the IHE version of annotation comment template – Gunter will check
• Support XD-Lab observation section to support molecular results
• In XD-Lab specialty section is optional and is the first section, below a specialty section adds the second level for the specific observation – so that would be the whole XD-Lab
• APSR uses the clinical lab observation template in order to support non-AP observations
• Specimen collection extended to include 1..* containers – reference to the container is needed on the report – can be 1 container with many specimen
• Does anyone report on-slide controls? Not sure it needs to be on the report but can have a canned text to explain that controls were run and their status.
• Do we need step sections? Every 4^th section on a slide –we need to know what section is coming from what/where
• Need to be able to track what diagnosis comes from which specimen – also need to know if the diagnosis comes from the clinic or the lab . It is important to know which container generated which Dx
• A procedure only has a code, not a value per CDA template – Gunter to fix
• Procedure steps is a way of documenting the manufacturing of slides, in order to understand how the diagnosis is being made and what will need to be used for further testing at a later time etc.
• Observation is linked to the specimenID
• Francois will take a look to correct the examples before 9 AM CT tomorrow (in Oxygen for CDA conformance, then in art décor against the defined templates– then send back to Kai)
• Will APSR allow dynamic population of reflex tests?
• Every AP case has APSR, as long as ALL the observations are part of the APSR – would need to make sure the caseID and specimenID and the observationID are part of the report
• Create a CAP style guide on how to render this APSR document
• If you do a test on the same specimen years later it would be a different order and a different APSR – but it would need to be combined with a summary report – that would be a different mechanism to relate several APSR documents for the same case
• Case = tissue collection event which is all results stemming from the original event and the subsequent events for the same case – this must not necessarily be a document – could be the system collecting all the information associated with the case
• APSR will have additional time on Friday, if digital pathology is cancelled

_______________________________________________________________________________________

 

Minutes November 10:

 

SET Review (continued from Wednesday)

• Use case #3 – merge the first 3 steps of the intra-organizational transfer and the inter-organizational transfer
  • Separate the specimen sent for testing from these use cases = event that belongs only to the receiver
  • The handling of identifiers varies between organizations.  Should add that to ensure that it does not get lost. That could also occur for intra-organizations, so re-identification may occur. Allow that for ALL use cases, so this could be at any point in the use cases.
  • Create a shipping with re-identification use case instead
  • Merge use cases #2 and #3, as proposed
• Use case #4:
  • SET goal is to know what happened to a specimen, while LSH goal is to handle the workflow on the specimen and the succession of steps – both are related to specimen custody
  • SET actors most likely will be part of the automation manager, but not necessarily the instruments, where LSH is being used
  • Section X.6 of volume 1 “SET Cross Profile Considerations” will describe how the different profiles are related to each other.
  • Clarify the names of the grey actors (testing manager can be a person or machine if they have automation). Will add explanation to the diagram.
  • Change name from “Device” to “Analyzer”
  • Remove archive from workflow and just keep pre/post-processor and move the archive specimen to that line
  • What is the difference between start/stop and check-in/check-out? Both are the same  (specimen arrived and specimen release off)
  • Pre-processing start and end – should be handled by LSH
  • Just track here that specimen is under custody of device  - so use ONLY device and device check-in and check-out.
  • Include another diagram to describe all the devices in the overall workflow. Assume this applies to ALL specimen handling, whether by person or machine
  • Do we need to add discard/final disposition event as well? May be a discharge event with disposition to where it went? Or more of a status change since custody is no longer tracked; this can be final (discard) or can be recovered from (example could be lost in transit and then found again).
  • So we really have a last known location ONLY.
  • Change device to custodian in the diagram and explain what all can be a custodian.
• Use case #5:
  • Biobanking specimen tracking from patient = use cases already described apply
  • In that case this may also fit under the custodian
  • Need to include both a “one way trip” of the specimen as well as de-identification for research specimens
  • Biobank locations could be in different locations (under CLIA lab or in research labs – depends on IRB protocols) – except the de-identifications that needs to happen for research – that can be covered by re-identification use case, with specific rules = de-identification (need to define which actor keeps the link between the clinical ID and the bio-bank ID)
  • For any custodian there is opportunity to modify the specimen as well as result in observations – but we are defining the data package needed for different specimen tracking steps, so those will still need to be use case specific
  • Specifically describe the derived specimen – is not necessarily unique to biobanking and re-identification (need an ID custodian = honest broker = guardian of the patient ID) of a specimen (at least to a patient, not necessarily to the exact specimenID). How should we deal with the IDs going to the biobank and a message to the clinical lab about the disposition?
  • parentID should be associated to the immediate specimenID, so you can create a full chain – should call that out specifically so folks are aware that they need to support more than one parent ID in their data model.
  • Need to add these three events:
    • Specimen de-identification reversible
    • specimen re-identification
    • specimen de-identification irreversible
  • The de-identification should support being able to track additional specimen from the same patient - go to same research co-hort.
  • Pathology specimen tracking is similar to other use cases.  Perhaps convert this one to the derived specimen (applicable to micro, and pathology)  and use pathology as examples.

 

PaLM Structured Data  (attach Structured_Reporting_PALM_Nov2016.pptx)

• Why are we still struggling?
  • Lack of leadership (best practices and give benefits to standardization) is at root of all 3 questions, fueled by a lot of legacy based barriers of interoperability – lack of leadership in vision to allow “snowflake mentality”  at industry / vendor level
  • Short term incentives are more clear to stakeholders than long-term incentives
  • Legal and political barriers to actual implementation
• Have a professional society create the guidelines and computable rules and make that available to systems
• Europe study of SCT versus the use of a set of other code systems, or each country by itself? – use SCT with ecosystem of other terminologies (for cross border care coordination project will use this)
• Use LOINC for labels of the data elements
• Challenge – add: foster and lay groundwork for rapid adoption demonstrating the ROI to all stakeholders
• LOINC has a LOINC form project through NLM – need to check that out (part of SDC project)
• LOINC does not follow the ISO11??? – and ISO?? has no schema, DEX covers minimum of that, but not all, so DEX would need improvement
• Also FHIR data element definition resource work is ongoing
• Create data element names that can be mapped – map can then be published for ALL to use (possibly using FHIR conceptmap resource) – that needs to be funded to be hosted = NLM?
• Downstream will facilitate federated content producer then distributed content access versus centralized hosting
• Ultimately we want to be able to define clinical guidelines for a specific domain– right now represented as forms = ONC complex data element
• Need to look at ArdenSyntax to see if it is applicable (have to consider the design of the query language that will be using the data stored)
• Next Step:
  • Check on CIMI work
  • Complete rough draft of white paper, including ROI
  • Reach out to LOINC leadership to discuss alignment of visions and goals
  • Identify alignment of other strategic partners (HL7, IHTSDO)
  • Identify future efforts and funding sources

 

IHE around the world

Europe (attach 161110_IHE_Europe.pdf)

• Germany – new protocol LDT V3 (not sure if they are using LOINC)
• Belgium hubs: document registry with meta data about the patient (national ID) and a date and what kind of document is available by the document producer (not sure what happens when the document producer is no longer available) – the content will be transmitted as the CDA using XD-Lab that is wrapped in KMEHR;  use LOINC and UCUM
• France: IHE and HL7 France are working on a LOINC based value set for ordering lab tests – also including AOEs and the results – Francois can share AOEs, if interested. Also have problems with the conventional units. Use HL7 CDA, LOINC, and UCUM
• Austria: project ELGA – HL7 CDA + LOINC

Japan (attach IHE-Japan_20161110.pptx)

• Keeping IHE AP and Laboratory as separate domains
• Published IHE Interoperability book in 2016 to enable adoption by vendors
• Results of J-Connectathon published November 1, 2016

US

Northamerican Connectathon (attach IHE LAB 2017.jpg)

• Only XD-Lab will be tested, and no partners for LAW, so may need to set up a virtual connectathon to get that profile tested more
• Micro guide: ftp://ftp.ihe.net/PaLM/iheyr1_2016/ImplementationGuides/Guide_bacteriomycoparasito_V1_0_EN_15nov (1)
  • French guide was translated to English – want to share with PaLM listserve to collect comments and then published on sFTP site
  • Describe the different workflows for micro and highlight use cases with examples
  • How do we order micro in LOINC – Francois has some input based on discussions with Dan Vreeman this week, to be added.
  • Need to restructure the specimen information
  • Massive confusion about what the specimen type and the source  is, some use pre-coordinated terms versus single terms that create post-coordination combinations
  • That’s where we are trying to get the Specimen crossmapping table – need to figure out where to host and publish it ASAP, so we can add the link to it
  • Dealing with information on the isolate about the original specimen

 

F2F meetings:

• Next location is Tokyo, Japan  proposed is May 22 – May 24, 2016 (JAHIS facility), possibly May 15 – May 18. Need to avoid HL7 (5/7 to 5/12) and API meeting (May 22 – 25).
• Next autumn F2F would be in November in Sardinia, Italy  - not the week of 11/20 (Thanksgiving in US is 11/23)
• Make decision on Dec 14 call

 

CP review – no CPs

Will have one non-substantial CP on LAW for review on the December call

 

PaLM scope update

• Include Bloodbank workflow – testing of blood in transfusion medicine is currently in scope for  PaLM, but not blood product administration/transfusion
• HL7 has v2 message for infrastructure, but the workflow has not been well defined
• Could also be covered in the PCC domain

 

Proposed:

Implementation of healthcare information systems and technologies occur across a broad range of domains by teams that are comprised primarily of technical experts. In many circumstances, there is less involvement by subject matter experts and end users during requirements specification and development. End user acceptance testing of these deployed systems is often the first time that unique workflows and customer needs are recognized. This late recognition of critical requirements poses a risk to implementation efforts. Such risks may be mitigated by clear articulation and documentation of the workflows and associated data elements commonly required in a particular domain. The current effort serves to capture a comprehensive (but not exhaustive nor very detailed) enumeration of workflows within the domain of pathology and laboratory medicine with particular attention devoted to specimen management and associated data elements.

 

Blood based workflow (chemistry, coagulation, flow cytometry)

Typical scenario: a clinical provider places an order for a laboratory test that requires a blood draw from a patient. The blood is collected by a nurse or phlebotomist either immediately or in the near future with results to be available prior to the next patient encounter. The sample is submitted to the laboratory via a tube shuttle system or picked up by a manual courier. The lab receives the sample registering it into their lab information system. The urgency or priority of the sample may inherently dictate the collection SOP. For example, an urgent or STAT order may require collection by a nurse rather than a phlebotomist.

Alternative related scenarios: reference future orders workflow, FNA workflow, timed orders workflow, STAT order workflow

Order name examples: CBC, CBC w/ manual diff, BMP (basic metabolic panel), RFP (renal function panel)

Order questions: urgency / priority (STAT vs urgent vs routine), site [optional], arterial / venous / capillary [optional]

 

• Collection of ALL possible workflows in the PaLM domain
• Add result routing workflows (parent to critical result workflow)
• CPOE management (eDOS)
• Clinical decision support workflow
• Split reference lab workflow – inbound and outbound
• Then provide resources for each of these where we have some, or show that we may have upcoming projects

 

Submit as new proposal

Blood bank workflow:

• Testing on the blood product – when sitting at the bedside want to know the status of the testing on the blood product – has it been tested, has it been released?
• After the blood product leaves lab, want to know if administered and if there was adverse reaction
• During transfusion orders in NL need to check every 15 minutes if the blood product has reached the patient
• In US there may also be ERs or ORs that have universal blood products available
• Some LIS have admin to track the full life cycle of blood products
• Will need more SME input (need to get blood banking informaticists) to get the detail worked out – submit as new proposal for the next cycle and bring up on DCC committee call to let all other domains know about it.
• Dan to reach out to international customers; also will need some more information from across the world
• Submit as new proposal for 2017 cycle
• Haemonetics, Mediware, ABB – Carolyn has experience
• Another workflow refrigerator with blood product is a closed loop, once that is set up assumes only authorized use

 

Specimen collector representation:

OBR-10 Collector information - (attach 20161110_IHE_CollectorIdentifier_OBR-10.docx)

_______________________________________________________________________________________

 

Minutes November 11:

 

APSR 2.0: (attach 20161112_APSR_2_0_3bigPictures_reworked.pptx)

• Do not have procedure codes in SNOMED CT for some of the procedures like sectioning combined with staining
  • Solution is to split up sectioning and staining, which already have procedure codes individually. Use high level code and use qualifier to specify the target
  • Use PathLex? – this was a temporary solution (no longer maintained) – so should not use. It is no longer usable.
  • We have this additional detail on the specimen procedure and can present the hierarchy for derived specimen in this CDA document; it depends on who is reading the report – primary care doc may not need it, but consulting pathologist may want all that detail
  • Should have a full chain of custody of the specimen to really understand the diagnosis
  • Can you also use the procedure hierarchy in the CDA qualifier
  • “Unstained slide” can be added as an intermediate hierarchy level between “block” and  “slide” with the final slide termed “stained slide”. It might be helpful to know that you possibly have that available for a specific additional slide from unstained to specific stain – qualifier can then be updated in solution 2
  • HE stains on block A1 and A2 and have 3 unstained slides, then can change that unstained with another stain – might be helpful during work up, but otherwise does not matter – in the report we only need the final step that the result is related to. We need to be able to specify the level and the stain. Chose option 2 which uses a more generic procedure code and a qualifier for stain
• Looking at the overview of the APSR; only the Diagnostic conclusion section is mandatory with 1..*
  • Problem organizer diagram
    • The last observationMedia is redundant – delete. What if you have a scanned report related to the case, that is not related to a problem, should it be as it is
    • Do we need to add a specimen to the observationMedia that is attached to the problem organizer also as part of the observationMedia (we already have that, just not showing in the diagram)
    • Example: One problem = CIS breast cancer – can be in both the right and the left breast – have 2 different specimens in 2 different containers
    • We have specimen attached at problem organizer and AP observation, so should we remove the specimen reference that don’t have observation (list all the specimen in the procedure step section ONLY and not at the problem level list) – need to state that specifically in the profile and describe that if we retain both
  • Procedure Step section diagram
    • entryRelationship allows to enumerate the hierarchy – should include the minimum cardinality for all of the diagrams to avoid any ambiguity
    • For the US this may cause issues as you would use CDA for AP and messaging for the lab (may use both – v2 messaging to the ordering provider per MU), but can use this CDA to be used for HIE and also for referrals for specific tests
    • In the big picture – take out the intraoperative / macro / micro and list as detail observation section – or add one additional section for any other observation as “additional specified  observation section” using problem organizer
    • May need to get several LOINCs if they don’t yet exist – leave the LOINC section code open – for this template OID - 0..*
  • What about molecular pathology?
  • Specific problem organizer would be:
    • Clinical Information Section
    • Additional Specified Observation Section
    • Conclusion Section
    • Procedure Step – covers also fixation information
  • Timeline: review by group due by January 2017 and then may be publish for public review no later than May 2017.
    • Raj can share some de-identified examples of the different types of reports with the group.
    • Epic can also review against the workflow to produce these data element, then review what can we add that can be aggregated across – Dan and Raj to do
    • Can we also see if the eCC can fit into the APSR as well?
  • Need to also consider how that will fit with the v2 messaging of LRI, etc. (LRI currently support pdf sending in the examples)

 

LSH – Overview

• Extensibility
  • Discussed how specimen handoff use cases are control-oriented.  Control interfaces are necessarily coupled to a mechanical implementation that may vary from manufacturer to manufacturer.  Industry adoption of LSH may rely on providing enough structure to build on, while allowing flexibility to accommodate a variety of scenarios.
  • Proposal for LSH Transactions
    • Defined syntax
    • Extensible semantics
      • Semantics specified where there is consensus for known use cases
        • e.g. general error handling
  • Discussed examples of LSH variation

Example 1: 

Single-Sample Single Point-in-Space   vs

Single-Sample Multiple Points-in-Space  vs

Multiple-Sample Single Point-in-Space

• Could use separate transactions for each specimen, or use separate Prepare but same Start
• Attendees interested in seeing illustrated examples of above, and also
  • No PosID for track
  • PosID managed by instrument
• John to provide illustrated examples for discussion in January meeting

Example 2: 

Error Handling

• Error scenarios will vary widely
• General agreement that LSH should seek a balance of specification and flexibility.  Too much constraint may make creating a conforming implementation difficult.
• Testability
  • Discussed options for testing LSH implementations.  Thorough testing requires actual equipment. Difficult, since equipment is often large, and in a pre-release development state.
  • Propose to use a Gazelle-like tool for online profile conformance testing.  
  • John to contact Gazelle developers (IHE Services Team)
    • Gazelle may be able to provide simulators
    • Talk to Gazelle team Eric Poiseau and Anne-Gaelle
  • How to handle interoperability testing will require further discussion
• Follow Up
  • John to update LSH profile document and Wiki
    • Have ready by October meeting, for discussion at Fall F2F in November
    • SET profile will also be ready by then.  Want to supplement TF with both SET and LSH at the same time.

 

LCC: http://wiki.ihe.net/index.php/LCC_Long_Proposal_-_wiki#Result_Fulfillment.2FFollowup_.28LAB-7.29

• OBX does not fit the need. We definitely need the REL segment. This will ease the processing.
• REL needs additional features for our LAB-47 need: Need to type the source and the target of the relationship (placer number, filler number, observation identifier …)
  • The best path is to upgrade datatype of REL-4 and REL-5 from EI to CX.
  • This would need an additional CR built to the Patient Care WG
  • Location of the REL segment: Just before the OBSERVATION segment group, confirmed as the best fit.
• Either do this on one new dedicated message structure, or potentially apply this new segment to all existing ordering messaging structures
• Will bring up on the OO call on 11/17 or 12/1

 

IHE to US Realm harmonization: http://wiki.ihe.net/index.php/IHE-SNI_Lab_Harmonization

• Comparison documents of IHE profiles to US realm Lab related Implementation Guides
• Three different use cases
• Please review

 

F2F meeting in Japan dates 2017

• Japan
  • 1st Possibility     May 31 - June 2 (Italian Holiday) = 11
  • 2nd Possibility     May 29 - May 31 (Memorial Day) = 10
  • 3rd Possibility    May 15 - May 17 = 10
  • Doodle poll for dates and review on next call in December
• Sardinia will aim for November 2017 (NOT week of 11/20) best may be week of 11/6