PaLM F2F Minutes 2016-Nov 09-11

From IHE Wiki
Revision as of 16:40, 5 December 2016 by Cknapik (talk | contribs) (→‎Minutes)
Jump to navigation Jump to search

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
  • publication for public review in Fall 2017 – aim for end of Sept beginning of Oct 2017 to have 1 month to collect comments and review at F2F meeting

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

LCC:

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

APSR 2.0:

  • Aim for summer, but Call for Proposals comes out 11/15/2016
  • Proposals due by 12/31/2016

Blood bank

  • 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

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 4th 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.