PaLM Conf Minutes 2019-August-14

From IHE Wiki
Revision as of 09:40, 26 August 2019 by Salaver (talk | contribs) (→‎Attendees)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Attendees

Name Email
David Beckman dbeckman@epic.com
Raj Dash r.dash@duke.edu
Gunter Haroke haroske@icloud.com
Nick Hasselhorst Nick.haarselhorst@philips.com
Ralf Herzog Ralf.Herzog@roche.com
Mary Kennedy mkenned@cap.org
Megumi Kondo Kondo.Megumi@sysmex-cp.co.jp
Francois Macary Francois.macary@phast.fr
Riki Merrick rikimerrick@gmail.com
Kevin Schap kschap@cap.org
Alessandro Sulis Allesandro.sulis@crs4.it
Rob Wilder Rob.wilder@spok.com
Eddie Albert ealbert@lifeimage.com
Francesca Frexia Francesca.frexia@gmail.com
JD Nolen jnolen@cmh.edu
Dana Marcelonis jnolen@cmh.edu
Ian Gabriel Ian.gabriel@siemens-healthineers.com
Dan Rutz dRutz@epic.com


Next call is September 11, 2019


F2F Meeting at CAP headquarters

Digital Pathology Profile and White Paper

  • Digital Pathology:
    • Supporting OBX/SPM as well as OBX/OBR
    • OBX/SPM required, if the stain name MUST be OBX/SPM, then there must be at least 1 OBX/SPM to cover that, since that is a DICOM required element and clearly related to the specimen
    • Where does the study UID go – ask David Clunie if OBX should be after SPM or OBR, and, who assigns that (the original submitter / the placer of this scan order (LIS / IA manager?) / the modality)?
      • Is a Series instance UID needed? Or, is it the same as placer order number? No, because we are talking to the scanner – that is for each scan – series is more the order from the placer to the lab, not from the lab to the scanner – so would that be ORC-38?
From HL7 v2.9: ORC-38 Filler Order Group Number (EI) nnnnn
Components: <Entity Identifier (ST)> & <Namespace ID (IS)> & <Universal ID (ST)> & <Universal ID Type (ID)>
Definition: This field contains a unique identifier for the Order Group as referenced by the Filler application. An Order Group is a set of orders grouped together by the placer application.
The first component is a string that uniquely identifies all order groups from the placer application. A limit of fifteen (15) characters is suggested but not required.
The second through fourth components constitute a filler application ID identical to the analogous components of ORC-2-placer order number or ORC-3-filler order number. Order groups and how to use them are described in detail in Section 4.5.1, "ORC–Common Order Segment."
      • Need to update the mapping spreadsheet but it is still be good to check with David Clunie.
    • Cancellation from the Scanner – how is that done? Can we get a real world example from Nick for that? The technician realizes the wrong batch is being scanned and pushes cancelation button.
      • In LAW can the analyzer send a cancelation? Send LAB-29 with the status as order completed and observation status as X or N – that would be at the order level so using the OBX does not work here so well
      • OBR-25 = X
      • ORC-1 = OC (for filler applications, so that should work, since that is te same is
      • ORC-5 = CA
    • Raj will create a google doc with the list of questions and answers

SET

    • We need two events to distinguish collection performed (S39) from collection failed (S40) sharing the same message structure SET_S38; we need two events to distinguish procedure step performed (S51) from procedure step failed (S52) sharing the same message structure SET_S51.
    • We need a distinct event (S50) and message structure (SET_S50) to track the derivation of a child specimen. The derivation of a child specimen is always a success.
    • For consideration:
      • When a specimen is processed to produce a derived (child) specimen the events tracked are:
        • 1 S51 (procedure step performed) on the input (parent) specimen;
        • n S50 (child specimen derived) for each child specimen produced;
        • When the derivation process fails, the single event tracked is:
        • S52 (procedure step failed) on the input specimen

1.png

      • We were having lengthy discussions about what processing produces a derived specimen and what doesn't - there are some clear examples:
        • culture -> isolate(s)
        • organ -> block -.> section -is really -> slide
        • sample -> aliquots (this is really just a splitting of the same sample across multiple containers, but then if the containers have different additives, they alter the specimen)
        • slide -> digital image
        • pooling multiple samples into one is less clear
        • centrifuging and using only the plasma / serum (if that was the intent of the blood collected in the tube with appropriate additives?)
      • Per Riki: the difference between a successful processing step and a derived specimen is the inclusion of the information about the derived specimen, right?
  • Are there advantages of having parent specimen and child specimen in the same message?
  • Options are:
    • #1 Use S50 for any processing successful message, with optionally reporting the derived specimen
    • #2 Use S50 only to declare the derived specimen (no information on the parent specimen other than SPM-3) and then use S51 for successful processing of the parent specimen
  • We need a message structure to report unsuccessful processing events, but need to examine if that message structure is at all different from the successful processing event.

PCD Joint Work

    • Rob Wilder, from Spoc, and part of the PC domain (planning Co-Chair)
    • ACM management working group = alerting
    • Mobile desktop managing for patient workflow in EHR-S
    • Lab and radiology alert managers – providing notification to docs to mobile devices, when results are ready, would like to standardize that
    • Successful implementations have reduced response times in result reviewed by the physicians
Link to PCD White Paper: https://docs.google.com/document/d/1P__yI970DTa-knfFr2Zqpqp8HQWgsqYWGG8hM331cAQ/edit?usp=sharing
    • The PCD white paper with this group – looking for input around the described actors
    • Want to promote use of the CD profiles and PaLM profiles for best implementations and to try to get this as joint Connectathons across domains.
    • There was a problem previously with endpoint communication devices in prior – adopted WPCT – extended that protocol
    • Added prioritization of URL
    • Enable lab systems remote readers and automate accessing radiology image on mobile devices
    • There is a need to be more specific of what to send alerts about vs creating a digest of bank of tests ordered
    • ORU^R40 – used for initial notification
    • There is a Radiology profile called MACM, but it was never adopted. ACM is widely adopted – working with radiology to migrate over to that
    • Some of the alerting is used for the dashboard in the EHR-S
    • LOE for this project? Need the domain expertise to make this successful ORU^R40 vs ORU^R01…
    • Maybe see if LIS can implement PCD-04 and maybe PCD-05 (doc has seen and accepted lab results)
    • Need pathologist expertise to continue
    • Please read white paper and send questions to Rob at Rob.wilder@spok.com
    • We will discuss this on the next call in the second hour.
Retrieved from "http://wiki.ihe.net/index.php?title=PaLM_Conf_Minutes_2019-August-14&oldid=116923"