PaLM Conf Minutes 2020-July-08
Jump to navigation
Jump to search
Attendees
Name | |
---|---|
Gunter Haroske | haroske@icloud.com |
Mary Kennedy | mkenned@cap.org |
Raj Dash | r.dash@duke.edu |
Rikki Merrick | rikimerrick@gmail.com |
Alessandro Sulis | Allesandro.sulis@crs4.it |
Ralf Herzog | ralf.herzog@roche.com |
David de Mena Garcia | david.mena.exts@juntadeandalucia.es |
Megumi Kondo | megumi.kondo.sakura.japan@gmail.com |
Dan Rutz | drutz@epic.com |
Kevin Schap | kschap@cap.org |
David Beckman | dbeckman@epic.com |
Francesca Frexia | Francesca.frexia@crs4.it |
Jim Harrison | james.harrison@virginia.edu |
JD Nolen | jdlnolen@gmail.com |
Nick Haarselhorst | Nick.Haarselhorst@philips.com |
Nick Jones | thatwsiguy@gmail.com |
Ian Gabriel | Ian.gabriel@leicabiosystems.com |
Filip Migom | Filip.migom@mips.be |
John Hargett | jhargett@epic.com |
Mandel Mickley | Mandel.mickley@leica-biosystems.com |
Next call is August 12, 2020
- Digital Pathology update:
- Document has been sent to Mary Jungers
- Sharing the spreadsheet of open issues
- Still need to have to update the wiki for this profile
- Also put the comparison spreadsheet here: https://wiki.ihe.net/index.php/APW_Image_Acquisition
- Harmonization proposal for HL7
- Need to submit for code for identifier type of “Image Display Sort Order” (IDSO); it would be applicable for the assigning authority that creates it, so there could be more than one for an image – Riki to do
- Slides have to be properly labeled correctly to convey the cut order (7th cut off the block); that is important, but the sorting is done on string, so that can be hard to do in the system natively
- Sorting based on how the slides are created is most important
- This should be created in DICOM Supplement 122
- Also, there may be rules in protocols that govern sort orders
- It is good to be able to have a way to create a sort order for the image (from the acquisition manager) first
- There is also sorting by the users at a later point in time
- DICOM has presentation states – this may be needed for the long-term image storage to cover application and end-user sorting – up to vendors to implement
- What do we do if there are changes of the sort order?
- This is in LAB-80, but not in the image display back report, but this should probably be also part of the DICOM metadata; we are just providing a mechanism to share
- We may want to have image view trails / annotations and sort order changes may be stored there so that the case comes back up the same way
- Limited use here: display identifier is just giving the sort order for the new images to be acquired – all else is out of scope
- What if the sort order was changed – how would the acquisition manager know that the change has happened?
- That should be covered in the evidence creation transactions in new profile
- Comment from Nick Jones: To add a comment: I think it's important to differentiate the physical abstraction change vs. a display sort order. Nick H is right that labs vary a lot on how they describe these; one lab might say B2-4 for a slide, (the 4th cut on a second block on a second part of a case) while another lab describes that as 2-B-4, or 2-B-D, etc. That should be recognized as different descriptions of assets, not necessarily sort order for viewing (which is what the viewer wants.)
- When to use ORL^O34
- Error in the handling of the acquisition modality
- Cannot use the order message, system not ready
- use LAB-82 – as soon as you start the work
- Error in the handling of the acquisition modality
- When to use ORL^O34
- Sorting based on how the slides are created is most important
- SET Update
- Updated document
- Added diagrams
- Fixed typos
- As pathology is moving into digital world
- For current slides we have manual process / physical to ensure pathologists know that the case is NOT complete
- Need to be sure that in the digital world we need to be sure the case is not signed out
- Imaging vendors and LIS vendors need to have a way to figure out, when all the physical assets are complete vs when all the digital assets are available
- SET transaction telling the acquisition manager that it has been received at the stainer for example
- Vendors can implement SET for this purpose
- This is just the framework for trigger event driven data exchange; that the vendors can then build application on these profiles, for example the application can be build using SET to give information on status of digital assets
- Specimen derivation
- All other events in SET are driven by other profiles, but this one is not yet fully defined
- Will the current message structure support the digital asset development?
- Message structure includes the order information for the processing step, resulting in the derived specimen
- We need to update the OO change request to this message structure
- Nick Jones comment:
- I may have some ideas on additions for events to add to these tables after I talk with the DICOM group (i.e. modeling the reduction of a specimen by its creation of a child specimen). But I'll follow up with you later. The basics here look great to me though; it solves some problems I hadn't figured out yet
- It might just be that events like "Specimen Procedure Step successfully produced a derived specimen" get associated with both the parent and child specimens in various systems
- All other events in SET are driven by other profiles, but this one is not yet fully defined
- Need to update the event reason table
- Almost ready for public comment
- Updated document
- Next F2F:
- Plan to postpone planning