PaLM Conf Minutes 2026-November-11: Difference between revisions
Riki Merrick (talk | contribs) No edit summary |
Riki Merrick (talk | contribs) No edit summary |
||
| Line 56: | Line 56: | ||
- PS3.17: Container Identifier = Specimen Identifier | - PS3.17: Container Identifier = Specimen Identifier | ||
- DPIA: Container Identifier is different from the Specimen Identifier (seems to be the Block ID but not guaranteed) | - DPIA: Container Identifier is different from the Specimen Identifier (seems to be the Block ID but not guaranteed) | ||
[[ | [[File:Unnamed.png]] | ||
[[ | [[File:File:Unnamed_(1).png]] | ||
In the latest draft of DPOW it is also unclear whether the Block Id will be explicitly addressed or not. Currently in my experience, different vendors place the Block information using different HL7 segments (e.g. OBX). It would be helpful to hear your thoughts about this and whether this issue will be solved in a standard way by HL7 or DICOM ? | In the latest draft of DPOW it is also unclear whether the Block Id will be explicitly addressed or not. Currently in my experience, different vendors place the Block information using different HL7 segments (e.g. OBX). It would be helpful to hear your thoughts about this and whether this issue will be solved in a standard way by HL7 or DICOM ? | ||
Revision as of 11:35, 11 November 2026
2026-11-11_IHE_PaLM_Notes
Attendees:
Kevin Schap (CAP), Megumi Kondo (JAHIS), Alessandro Sulis (CRS4), Ruben Fernandes (Sectra), Riki Merrick (Vernetzt, LLC / APHL), Kazunari Fukagawa (JAHIS), Francesca Vanzo, Mustafa Qays Yousif, Ralf Herzog (Roche), Nori (Siemens Healthineers), Jim Harrison, Raj Dash (Duke), David Clunie, Gunther Haroske, James Howe,
Agenda
- Next F2F organization
- Proposals for 2027 projects
- IHE CAT 2027
- CP Follow up:
- DPIA
- LAW
- DP Profile Updates
- Nori's question about how to represent Block ID
- DPOW
- DPEC
- DPQC (new project)
- DICOM Connectathon Update
- PMW Update
- Question on OBR-31 in LTW – will update language to use model
- usage of segments O or RE – list anything that is optional and needs discussion with the partners as O
- not support collection date since those don’t exist in PT – they don’t test the lab’s handling of the expired specimen
- we do have receipt in lab time to calculate turn-around time
- New CPs for
- Representing Assay, Reaction Mix, and Target in OUL^R22 (IHE LAW)
- Representing UDI in OUL^R22
- Update from LIS vendor survey by SHIELD LIDR WG (not final)
- LTW CP update to add PRT
- Collaboration between IHE Japan and the Asian Society of Digital Pathology (ASDP) plans
- Australian PALM Work Update
- AOB
Notes
- Next F2F organization
- ECDP – June 14-18 in Rotterdam, NL https://www.ecdp2027.org/ – Kevin will check with Norman about feasibililty
- CAP can also always host
- Proposals for 2027 projects
- no other projects proposed besides the already approved DPQC profile
- IHE CAT 2027
- held the webinar on November 9th: ADD LINK WHEN WE HAVE IT>
- Can test DPIA 1.5 version with the new transactions – will review test cases on next month’s call, so that they are ready for registration closure
- Alessandro has been using AI using Opus 5.5 in Claude with medium load to create the Gazelle profiles we already have in IGAMT: LBL, LDA, LCSD, LTW <ALESSANDRO PLEASE CHECK AND FIX!>
- Still need to get time from Gazelle team to import the IGAMT profiles based on what is requested for testing (in January 2027 after registration closes)
- We may consider some CPs to keep LTW in line with LRI – Riki also found some issues when comparing against PMW (including a major issue with the ORL message structure in LTW)
- held the webinar on November 9th: ADD LINK WHEN WE HAVE IT>
- CP Follow up:
- DPIA
- expected publication date is in in a few days, when Mary Jungers is back
- LAW
- updates in IGAMT and Gazelle surfaced some issues, so new CP forthcoming
- DPIA
- DP Profile Updates
- Nori's question about how to represent Block ID explicitly
- Goal is to not have to derive it from the convention of Specimen ID format, which may not be used everywhere: As a viewer, I receive more and more requests to group slides by the Block. I think it is a valid request but I could not find a reliable source from where to get this information.
- Nori's question about how to represent Block ID explicitly
In the latest DPIA version, I have seen 2 different uses of Container Identifier and Specimen Identifier
- PS3.17: Container Identifier = Specimen Identifier
- DPIA: Container Identifier is different from the Specimen Identifier (seems to be the Block ID but not guaranteed)
File:File:Unnamed (1).png
In the latest draft of DPOW it is also unclear whether the Block Id will be explicitly addressed or not. Currently in my experience, different vendors place the Block information using different HL7 segments (e.g. OBX). It would be helpful to hear your thoughts about this and whether this issue will be solved in a standard way by HL7 or DICOM ?
- David Clunie’ s answer: By way of background, the information model we use in DICOM (from HL7 DAM) is described in [Daniel C, Garcia Rojo M, Bourquard K, Henin D, Schrader T, Della Mea V, et al. Standards to Support Information Systems Integration in Anatomic Pathology. Arch Pathol Lab Med. 2009 Nov;133(11):1841–9. doi:10.5858/133.11.1841] and informative examples are in https://dicom.nema.org/medical/dicom/current/output/chtml/part17/chapter_NN.html.
In particular, the multiple entries in the DICOM Specimen Preparation Step Content Item Sequence allow for hierarchical relationships between such things as blocks and sections to be communicated with Parent and child Specimen Identifiers and the (433465004,SCT,"Specimen Sampling") relationship for processing type. See the TCGA in IDC documentation for a somewhat contrived example here: https://github.com/ImagingDataCommons/idc-wsi-conversion#tcga This does not explain how such information should be communicated (and mapped to DICOM from) HL7 though. I am not sure that either the "parent" or the "block" sending/mapping is adequately covered in DPIA at moment though. SPM-3 has Specimen Parent IDs (DPIA Table A.5-1, Table A.5-12)? Also SPM-2 and SPM-31 are shown in in Table A.5-12, with SPM-2 specifically designated for the block. We could certainly improve B.2 DICOM Specimen Preparation Sequence Template Usage to show the inclusion of a "Specimen Sampling" item to link to blocks (and higher level parent containers), and show where in the SPM segment this came from (e.g., SPM-2 per Table A.5-12). Is this related to Closed Issue 37 in DPIA? Does the handling of parent and child specimens in the clinical lab transactions provide any guidance on (precedent for) this?
- Discussion today: while we could send multiple SPMs – one for each step of the processing, but in DPIA LAB-80 message we only have 1 SPM expected at the moment, where we are expecting SPM-2 to be the ID for the section on the slide; SPM-31 is CX datatype, we could use it for the block ID, if we get a NEW code from HL7 for the type of block identifier
SPM-3 repeats in the base standard, but not currently in DPIA, also it is EIP, so no identifier type available SAC-4 is not used in DPIA, but that would have to be for the cassette ID Container is the cassette, but DICOM does not have a type of tissue block, which should be added – new DICOM CP Value for having the block ID: you fix and embed the block and the slide? If you want to have a re-cut, the LIS would know what block; it also helps knowing the processing time gets you a scheduling advantage for workflow management (not the slide scanner), QC would also be on the section on the slide from the scanner – the viewer wants to know the block to group slides together for viewing by the pathologists We need to remove the SPM-2 entry for Block ID in the table in DPIA – need a CP for that David, Nori and Riki will work on a CP describing how to best represent Block ID in HL7 v2 messages
- DPOW
- Block ID identification is less of an issue here, because it can handle the processing to identify the different specimen – so will find the block via registration – Ruben will include the above considerations of where to best explicitly include it in DPOW messages
- Ruben needs to merge more work into the current github version – will bring back next month
- not discussed today:
- DPEC
- DPQC (new project)
- DICOM Connectathon Update
- DPOW
- PMW Update
- Question on OBR-31 in LTW – will update language to use modeling after LTW rather than creating a profile on LTW message definitions
- usage of segments O or RE - we can either:
- list anything that is optional and needs discussion with the partners as O and then we cannot test these at connectathons, as each implementation will need to negotiate the constraints
- create one or more named options (that describe the desired functionality) and for each option describe the usage and vocabulary binding specifically, then these options can be tested at connectathon and implementation partners that want to support the option’s functionality do not require negotiations (look at the LAW for handling of options) – basically it makes the segment / field conditonal on the option supported
- for PMW we do not need to support collection date since those don’t exist in PT – the specimen are concocted, so they don’t have collection date/times and the PT does not test the lab’s handling of the expired specimen
- we do have receipt in lab time to calculate turn-around time of lab processes
- Raj used Claude Fable to analyze Riki’s comments in the PMW and it found quite a few things – Jim and Riki will review
- We will bring this back for next call in December and start with it
- Collaboration between IHE Japan and the Asian Society of Digital Pathology (ASDP) plans
- Still working on MOU – no update today
- Australian PALM Work Update
- initiated a working group defining representation of clinical genomics concepts in V2 and later also FHIR for cancer reporting. This group meets every other week on Tuesdays 9-10 AM Australian Eastern Time (5-6 PM ET at the moment) - next call is November 17 – meeting info: https://us06web.zoom.us/j/85144564981?pwd=lXvDuaL0ZZjfaoaCuKPsADzqs55l3V.1
- Our next call is December 9, 2026 9 – 10:30 AM ET (make 90 minutes, so hopefully we can get through all the topics at hand)
From Chat:
KEVIN CAN YOU ADD – I don’t think there was a lot there