PaLM Conf Minutes 2022-May-2-4

From IHE Wiki
Jump to navigation Jump to search

Attendees

Name May 2 May 3 May 4
Riki Merrick X X X
Raj Dash X X X
Kenichi Takahashi X
Ralf Herzog X X X
Filip Migom X X X
Jim Harrison X X X
Mary Kennedy X X X
Gunter Haroke X X X
Alesandro Sulis X X
Francesca Frexia (Sectra) X X X
Mauro Zanardini X X X
Dan Rutz X
Gianluca Pavan X X X
Juergen Brandstatter X X
RoyCL X X
Francesca Vanzo X
Megumi Kondo X X X
Ruben Fernandes X X X
Tobias Dahlberg X X X
Gregorio Canal X
Takuya Haga X X
Jim McNulty X X

May 2, 2022 – Day 1

  1. Administration and agenda review
    • Raj to update the DPIA pages
    • Francesca to update the SET page to link to Gazelle test cases under Implementer Support
    • Riki to update links to TF on LTW (and check for other broken links)
    • Riki or Raj to update the diagram of the PaLM use cases and update the wiki with them
    • CP for APW in TF indicating that this profile is in the process of being deprecated by NEW Digital Pathology Profiles - reference the current activity wiki page
    • CP for LAW and LDA – Ralf to write and bring back
    • Have Alex update DPIA
    • Around the world Update
    • PT discussion
  2. Around the world update
    • Japan JAHIS updates (JAHIS presentation:# 1)
    • US updates (US updates: #2)
      • LOI and LRI were both balloted in September
      • COVID data elements were added
    • Filip: LTW lab testing lab order is in place – in all their installations; in Belgium and Netherlands there are a lot
      • Austria has some
      • France: configuration of LOINC is being done by PHAST
      • Italy and Germany are converting CDA into FHIR
  3. Transfusion Medicine TMA – (Transfusion Medicine presentation: #3)
    • MIPS has three customers using TMA.
    • Typical workflow: https://www.ncbi.nlm.nih.gov/core/lw/2.0/html/tileshop_pmc/tileshop_pmc_inline.html?title=Click%20on%20image%20to%20zoom&p=PMC3&id=6059318_bmjoq-2017-000270f01.jpg From this article: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6059318/
    • Workflow steps:
      • Ordering – could use LAB-1 / proposed use of HL7 OMB^O27 messages
      • Matching and inventory
      • Individual units are tracked on dispense – using LAB-3 with some specific OBX segments / propose to use DPS^O
      • Have TMA covered
    • Actors
      • For ordering use Order Placer (use generic actor)
      • For dispense status reporting use OrderResultTracker – we can check the IHE actor list for appropriate actor (assume pharmacy has a correct term) – NEED TO DO!
        • While ordering a blood product need to communicate the blood group of the patient – who will set this up (need blood type and crossmatch) and how do we communicate that
          • In Belgium need to test blood group testing on 2 separate specimen, prefer this as reflex test to the blood product order (if it is known in the system, that test is not needed)
            • Should be included, but not required
            • Is part of LAB-1 message now
            • Need to assign the transaction ID _ can we use LAB-71? – Riki to check
        • Can you change / update the order?
          • Initially ordered 3 bags, then want to add more
            • Do you cancel all 3 and then order 4 (may end up with 7 bags), or do you just add 1 more (preferred)
          • Initially ordered 3 bags, then want only 2
            • How do you cancel just 1 of the 3 bags
            • Has risk of having all bags canceled
          • Maybe allow use of LCC in addition to this profile for anything but ADDING more bags
    • OMB_O27
      • NEW segment compared to LAB-1
        • BPO:
          • Type of blood product
          • BPO-5 (not used often, because blood bags have the same defined volume and is often standardized for adults)
          • In US it is not standardized – ordering number of blood bags vs blood volume
          • Orderer should not need to know the size of the bag
          • Focus on BPO-3, BPO-4 for now
          • BPO-13 – CWE datatype, allows clinical indication
        • Copy definitions for PID, ORC, and TQi from LAB-1
        • Use OBX under the order (as these may be different for different blood product types) – check if we can use the same definition as in LAB-1
        • Suggest to use v2.5.1, don’t need ARV and don’t want to support PRT
    • Code systems: Use ISBT128 (HL70575 is user defined without any suggested values, so we should identify the code system as IBT per HL70396
    • Support OMB_028 as application acknowledgement
    • To support reflex orders use LAB-1 in addition – note that the reflex order does not need to identify what triggered this blood type crossmatch order
    • Dispense
      • Has more complicated issues – examples:
        • Which blood bag is available and can be administered to the patient (support for positive patient ID process)
        • Transport of the blood product needs to be considered
          • Picked up from lab
          • Where is it now?
            • Refrigerator near the lab
            • Could we use SET for this?
      • Check in pharmacy to see, if we can identify any IHE profiles (no TF, only trial) that already dispense medication
      • Check with HL7 chapters
        • inpatient is v2 RDE for order and RDS for the dispense in the US
          • RXD – request to dispense
          • RXG – request to give
          • RXA – post administration
          • Chapter 4A
        • Outpatient in US is NCPDP
      • Identify the proper patient and the blood product matches
    • Suggest use of BPS_029 which has the BPX segment (assume this is similar to the RDX segment)
    • Important to know how much blood was transfused = in TMA
      • Currently only counting the number of blood products that have been transfused; not covering the volume of each bag – do we need to add this?
        • We have not yet addressed adverse event reporting in TMA other than transfusion was interrupted
        • In the US, the FDA has Adverse Event reporting in V3 but it is only supported by specific adverse event documentation system; separated out of clinical HER-s from workflow and legal reasons which is similar to other safety reporting (e.g., liquid spill).
    • Next steps
      • Riki to share the template links with Filip
      • Filip to draft 2 profiles: TMO and TMD
      • Review the actor list to find suitable actor for TMD
      • Update TMA profile to remove TMO and TMD as open issues (once published)

Day 2 - May 3, 2022

  1. XeHealth:
    • Googlesheet: ADD link from Juergen:
    • XeHealth Art Décor ADD LINK from Juergen
    • XD-Lab does not have business statuses:
      • Created CDA extension: XeH: statusCode drawing from FHIR Diagnostic Report Status
      • Would like to add this extension into XD-Lab
      • HL7 OO had discussion around need for having additional status codes for amended and corrected before results being final – discussion still ongoing
      • Also added observationStatus extension – also still need
      • Need to add description around the fact why there are 2 status codes (the first is CDA and comes from XD-Lab and explain the allowable combinations between the two
      • If we had done this from the start, then we could make observation.statusCode optional, but that would be a breaking change, so let’s not do that
      • How does CDA deal with corrections?
        • CDA should be used only once the lab is ready to share results with outside partners
          • Preliminary report can go out (final results, but not all results ready
          • Each CDA is a documentation of status at a point in time – the superseding CDA document
    • Narrative expression of comments on the whole report
      • Similar to an NTE after MSH
      • Would like to understand what would be in this kind of comment?
        • In clinical practice in EHR-s they track “conversation” with another physician or with the patient
        • Juergen to take this back
    • XeHealth added optional section about payer – copied from PCC
    • Observation.value
      • Has datatype of ANY
      • Research across implementations in member countries and IPS found constraints
      • Discussion:
        • Should keep the ST datatype
        • Add in ED, so you can reference media like pictures and pdf (matches use of DiagnosticReport_representedForm and us in ED in v2) but in CDA would that not be done by using the stylesheet rendering of the human readable section instead?
          • Discussion around using ED with ED.2 = TXT so that you can reference the text in the human readable part of the CDA for that observation
        • Pictures are more common in cytology or pathology reports
        • IPS seems to be missing a numeric array – not sure if that is needed
        • Conclusion:
          • RTO_QTY_QTY – why not use RTO_PQ_PQ – need to ask the IPS folks about that – assume that’s so they can create RTO_PQ_PQ, RTO_INT_INT and RTO_REAL_REAL
          • May need IVL_TS_TS to describe processing of specimen, travel history; but for processing in APSR we have a processing step section – should use APSR
      • Should we constrain XD-Lab observation.value to the smaller value set?
        • The way the current description is, it may give implementers the impression that only numeric values are used; should update the description that is much more explicit about when to use what datatype and which are the most common
    • Observation.ID is not in XD-Lab (helps with mapping to FHIR) – could include as optional
      • At the document level we have it in XD-Lab = InFullfillmentOf – applicable to the entire document
      • What if the order is different for one of the observations is done under a different order (when you create a summary for example)
        • Could be modeled similar to observation.basedOn
        • Would the referenced order be in the CDA report that is shared (not planned at the moment – have not set up the orders workflow for this, but want to be able to carry this data)
        • PaLM we have ordering workflows – supported by v2 messaging
        • Also looking at this in FHIR to have a collection of orders, that the lab, where the patient shows up can query for the order
        • In IHE Pharmacy have workflow for writing the prescription, dispensing, fulfilling – may be partially fulfilled (administration)
          • Switzerland has transformed the CDA ordering into FHIR documents
    • Add in the order reason = Diagnosis
      • Would need to have it at the document level (and if we add the order reference at the observation level)
      • Can always create an observation (but that is not at the document level) where observation/code is described as “Diagnosis” using LOINC, and observation/value is coded using ICD for example) – can do that now as is
      • In APSR we have clinical section which supports description of reason for referral section – could look there for inspiration
      • Difference between diagnosis in the order vs diagnosis in the report should be considered (Diagnosis in report is observation for sure)
  2. DPAT white paper (DPAT presentation: #4)
    • Discussion:
      • Option A
        • Can select the part of the image in real time
          • you can get an instance, a series a study
          • can be done as continuous connection, but it is slow – this is directly to the consumer
        • Why not using RAD-107 (RAJ?) – use this for the intra-net, which makes it more real-time (see Option b)
        • You can also schedule the fetch ahead of time, so all images are available at the time of the telemedicine interaction
        • Need to track the review request is done using XDS, so want to do this using the same infrastructure (may need to state that in the intro to the profiles)
      • Option b:
        • This is more real-time for intra-net, need closer connections
      • For both options the issue is security between different organizations
        • Takes a long time to set up the connections (legal etc)
        • For some only works if same EHR-s and data sharing agreement (legal) in place
        • Some image repositories are open access, but there is NO patient data to give you example of – rather than the specific patient care (so for research or teaching); annotations are visible, but no patient data (many systems support this)
        • Image management system in Germany share the URL without ANY patient information via email and the PHI is giving via phone, but that is not easy to do sharing the DICOM object
          • What information is in the RAD-107 – can you drop patient information – images go as they are, so you would have to DICOM QOS for the image that is linked to the anonymized study
          • XDSi has specification around sharing Masterpatient identifier when using the system – so for primary clinical care, unless you create a masked patient (void of metadata of the real patient) and then you could provide that patient information in a different manner; but that is not as secure and there is no audit trail (so cannot provide the access to data trail for the patient, as is required in Italy) – and also may need to have the consent attached
        • QRPH has a whitepaper around this topic _ ADD LINK @ Gianluca!
          • Make sure we include disclaimer / explanation of using different approaches around security consideration
        • May need to include more security elements like SML tokens etc for clinical care
          • Every transaction can add different profiles that includes the authorization (SOAP) or REST – see ITI specification for that
          • Will reference that in the white paper
          • In Portugal, the data is kept on the source system, allows users access based on role of the user
        • Registry can take in the request with token to verify user and roles – policies can be applied
        • Make sure we include disclaimer / explanation of using different approaches around security consideration
      • Will this support the use case of patient provided images and how they can be uploaded into the system? – no need for the above transactions, but should be included as a use case in the white paper; once uploaded, then the above transactions can be used for the tele health consultation
        • For pathology some vendors support sending of DICOM images (export and then import into c-storage before uploading), which would be similar to uploading from CD (c-storage)
        • Ideally we should be able to import pathology images the same way we import radiology from storage device
      • Option C:
        • Central Gateway Layer (data broker system)
        • Systems that can support option A should also be able to work with Option C, so if the image actor supports the named transactions
      • What is the order of preference for scanner systems?
        • Sectra uses Option A for radiology for images and reports (implemented in Portugal with several different PACs vendors), but not for pathology, because DICOM adoption is low in pathology domain
        • What if it is not a tiled image – what if customer wants to see @ask Raj what he asked – would be secondary image
      • Second part of white paper is around finding the consult request
        • DSUB – document subscription = XDS layer for creating notifications (notify, when consulting request is published / can add patient as additional - this should also work for lab orders where the filler is not known ahead of time!
        • MPQ= multiple patient query = looking for all published consultation requests (not using the patient ID as the search parameter)
        • This is how radiology works
        • For reference / consultation by a specialist that could use ILW, since you know where you are going to send the sample to for review / consultation – how do you pick to use this vs ILW?
          • Created XDW to track the workflow around the order – it is also used to create relationship between clinical elements
            • Prescription is related to report that then initiates the new clinical pathway – documents across
            • Can then subscribe to ANY other activities around this clinical pathway
            • This keeps the workflow part using the same infrastructure / paradigm as the documents exchange mechanism already used
            • This is needed to let the receiver of the order document know they have to do something with it, compared to just having the documentation
            • Similar to what FHIR is trying to do – adding a task to operationalize the resource that is being sent
            • Side conversation: E-prescribing of Controlled Substances (EPCS) is probably a better model to follow – not sure how implemented, but it's widely implemented in EMRs.
        • This workflow would be where the PACs drives the pathology review workflow
          • This needs input from PACS and LIS vendors around feasibility
          • Differences around use of RAD-107 vs RAD-55 for example
        • This workflow would be where the PACs drives the pathology review workflow
          • This needs input from PACS and LIS vendors around feasibility
          • Differences around use of RAD-107 vs RAD-55 for example
        • Workflow steps
          • XRR-WD is a wrapper for the order
          • In US the LIS drives the workflow, images are additional information – that would change the way this works
        • What is RAD-120?
          • They are light XDS transactions – SOAP messages sending documents and metadata and defining the content of the document being shared
          • 4.111 [RAD-111] – [RAD-120] = These transactions are currently in the Cross-Enterprise Reading Workflow Definition (XRR-WD) Trial Implementation Supplement
      • Next steps
        • Get feedback from PACs, LIS (pathologists asking for) vendors – maybe in future could be a provider asking for second opinion, so maybe need EHR-s input, too
  3. DP-OR mappings (5_HL7-DICOM-WSI mappings); (8_Digital Path Evidence Creation); (9_IHE_PaLM_DPIA_Review…); (10_IHE_PALM_Profile Diagram)
    • Discussion
      • During DPIA development we had scanner vendor input, but had no PACs vendors, hence the gap
      • Raj’s slides from March 11, 2019 – (6_Anatomic path Physical…)
        • Discussed through slide 14
        • And again for data model for pathology is on slide 30
      • Raj’s slides for Digital Pathology updated May 3, 2022 (7_20190711….)
        • We are indeed missing connection between Acquisition Manager to Image manager / image archive
      • Discussion around which system type is playing what role of the DPIA profile from chat:
        • From Dan Rutz to Everyone 07:11 AM = We had instead envisioned though PACS support of those LAB-81/etc messages is still in question.
        • From Dan Rutz to Everyone 07:11 AM = We had instead envisioned though PACS support of those LAB-81/etc messages is still in question.
        • From Rajesh Dash to Everyone 07:11 AM = Order Filler = LIS usually and Acquisition Manager = Scanner driver usually
        • From Dan Rutz to Everyone 07:12 AM = I thought the scanner was the modality.
        • From Rajesh Dash to Everyone 07:12 AM = Yes, scanner = modality but image management system or scanner driver usually not the LIS, correct?
        • From Dan Rutz to Everyone 07:13 AM = Not image management in the LIS commonly, no
      • Order placer -> Order Filler transaction does not change the workflow when migrating to digital pathology, so we don’t need DPOR; we can use existing lab order profiles (LAB-1 and LAB-3)
      • But need DPIO – image order
        • No need to order to add digital image from slide in primary workflow, specific procedure steps in the lab are covered by DPIA
        • PACS needs to get notification of physical asset available – they probably don’t need that – only need to know, when there is the order for a scan has been placed – rename to Digital Asset request notification
        • LIS needs to know when digital asset is available
        • We may need to be able to show snapshot of number of slides have been ordered and how many are already available in the PACs
        • Discussion in Chat:
          • From Dan Rutz to Everyone 07:31 AM = I think physical specimen notification to PACS is problematic, do those systems even have a logical concept of a physical; And which may never be (in non-primaryDx settings)?; That sounds like it's broadcasting procedure steps from Acquisition Manager to Image Archive. The orders for scan is what PACS needs, not the physical assets.; ANSWER: This is NOT for the scanner management – but the scanner needs metadata from LIS to create the DICOM header
          • From Dan R From Dan Rutz to Everyone 07:38 AM = I would propose we step back a bit and consider that perhaps many/all of these specimen-oriented actions are about the same... they are all pathology automation. Ordering a stain on a slide isn't conceptually much different than ordering an image of a slide.
        • Digital Asset request notification to both the acquisition Manager AND also Image Manager / Archive (as soon as the glass slide has been created)
        • We still need to have a workflow step to decide which of the slides that have been created that need to be scanned (not all will be scanned; could come up with an automatic algorithm AND support ad hoc slide requests
        • Order Filler (most likely it will be the LIS) can show total number of slides as well as number of slides that have been sent for scanning
        • Digital Image annotation happens in the PACs – how does the order filler know which slides have annotations vs which don’t = should be covered by the evidence creation – do we need an evidence notification – would that need to be differentiated as to the type of evidence
        • Slightly tangent, but important:
          • Annotation is a manual step (no order via DPIA for this) – happens during physician review
          • DICOM Supplement 222 describes how
          • This could be an unsolicited ORU message – conceptually similar to the status update message in LAW?
      • Next steps
        • DPIO profile start
        • Revisit model discussion
  4. FHIR http://build.fhir.org/ig/hl7-be/hl7-be-fhir-laboratory-report/; https://build.fhir.org/services.html; https://bridgmodel.nci.nih.gov/model-subset; https://bridgmodel.nci.nih.gov/bridg-iso-dicom; https://bridgmodel.nci.nih.gov/hl7-fhir
    • Discussion on how to handle workflow in FHIR and how to do messaging (it is in possibly theory?)
    • Discussion around the relationship between IHE and HL7 for FHIR IGs?
      • HL7 should focus on vocabulary - having the same representation of the same concept regardless of what product family is being used to convey it
      • HL7 should focus on proposing which product family should be used for what genera functionality based on its benefit
      • Work on LAB-1 on FHIR?
      • Create a bundle with focus ServiceRequest and all referenced resources, but need to come up with a way to take over the event based
      • IHE has created several FHIR translations for profiles: works pretty well for query use cases
      • Potentially could work on FHIR representation of Lab report and Lab Order (without necessarily working out the workflow) – to support patient access and mobile access to this data as IHE profile
  5. Digital Pathology
    • DPIO: How should we define digital data elements in HL7?
    • A PACs get data from DICOM and HL7 – how should the same data element be represented in each of these standards?
    • Use BRIDG possibly to do the cross-mapping: https://bridgmodel.nci.nih.gov/bridg-iso-dicom and https://bridgmodel.nci.nih.gov/hl7-fhir
    • Probably need SAC + SPM to express ALL attributes of the slide
    • We have discussed using nested specimen to describe each step of the processing and then also have the digital slide become a new specimen.
    • We have a CP to add SAC into the specimen group to the DPIA messages (to support micro-arrays) but usually there is a 1:1 relationship between specimen and slide, but there could be on specimen in multiple containers
    • Digital slide was mapped to specimen, because the slide is no longer a container – which works for the evidence creation use case, making it similar to clinical analytics and possibly allowing us to reuse LAW and LDA for automating the scanning workflow
    • Would there be merit in expanding the HL7 specimen to DICOM mapping document?
    • Ruben has a different mapping document that explains where to take data form to generate the DICOM file (can that be shared and we could ask additional examples to see, if we have any gaps) review and verify this with DICOM WG26 at the joint meeting in Berlin and then add as appendix to the previously published whitepaper.
    • Cytology glass slide with WSI from that and then series of images that show the most abnormal cells and possibly different magnifications – these are derived digital assets, but we have not created a hierarchy of these and how this will be displayed, organized to retain (or not) the order of what looked at (there is a lot of metadata that needs to ; potentially covered by annotations (DICOM supplement 222 for image annotations) Heat map annotation could capture some / all? of this – sounds similar to key image / key series in radiology? Not exactly the same
    • In DPIA we created display identifiers, so you can look at them in a different sequence than how they were produced, shared etc.
    • In DPIO do we need to include viewing notification (or annotation of which slide has been viewed) – just because an asset was sent to the viewer does not guarantee that the physician actually looked at the slide (but the system knows which image was sent for viewing) – could this be done using SET, as this seems to be more of a auditing trail for image opening = specimen “transport”
  6. DPEC (Ray’s slides)
    • Use cases
    • Will need to look at the vocabulary for several of these annotations – should consider a coding system for annotations to support machine level classification (and also can support drop down for the most common things being called out – in order to support standardization of the most common elements – annotation group description – SNOMED International Pathology Reporting WG; that is what Scott Campbell is working on; they are also mapping cancer protocol attributes - property of a resection margin etc;
    • This will be a good topic for the June meeting also; Maybe look through literature for research on annotation machine learning to identify the top 100 terms used in annotation
    • Topics for June:
      • Audit trail model for viewing and documentation of what subset was viewed (with specific attributes that should be covered) as well as annotations
      • Coding system for annotations – at least support for codification, so it is not ONLY text
        • Create starter set of category codes
      • Mapping of common elements into DICOM and HL7 – review and then publish as appendix to the Digital Pathology White Paper
      • Additional profiles for Digital Pathology
      • Thinking through digital and pathology and related Connectathon opportunities
    • Next steps
      • Set up a call between us and Markus (+ more DICOM WG26 members?)
  7. New IHE PaLM proposal – Proficiency Testing (11_IHE Profile Proposal PaLM PT)
    • Raj and Jim Harrison are lead
    • Rationale: Other than these regulations (in the USA, other countries may differ), there is very little guidance and no standard procedure, either manual or electronic, that mandates how PT is performed and how data related to PT is conveyed from a laboratory to any authorized PT program provider.
    • No data or interoperability standards on how to organize PT data within an EHR or LIS or how to transmit this electronic data to/from a PT provider.
    • This has led to slow adoption of electronic interfaces in support of PT. For those PT providers that support some type of electronic data interchange, there are growing interoperability challenges due to fragmentation of the data model and messaging model across lab information systems for electronic representation and transmission of PT data.
    • Will initially support transmission of key data elements necessary to support PT testing, supporting both electronic requests for PT sample testing (orders) and request fulfillment with data sent back to the PT provider (results).
  8. Question from Ralf: There are instruments that support priority status (by where the sample is placed on the instrument) – none of the queries support priority notifications to the analyzer manager
  9. From Chat on May 4:
    • 13:10:35 From Dan Rutz to Everyone: We had instead envisioned the Order Filler and Acquisition Manager to be filled by the same system, that is the LIS vendor product would support both roles.
    • 13:11:00 From Dan Rutz to Everyone: Though PACS support of those LAB-81/etc messages is still in question.
    • 13:11:40 From Rajesh Dash to Everyone: Order Filler = LIS usually and Acquisition Manager = Scanner driver usually
    • 13:12:17 From Dan Rutz to Everyone: I thought the scanner was the modality.
    • 13:12:29 From Rajesh Dash to Everyone: Yes, scanner = modality
    • 13:12:47 From Rajesh Dash to Everyone: but image management system or scanner driver usually not the LIS, correct?,
    • 13:13:39 From Dan Rutz to Everyone: Not image management in the LIS commonly, no
    • 13:29:46 From Dan Rutz to Everyone: I think physical specimen notification to PACS is problematic, do those systems even have a logical concept of a physical specimen which has not yet been imaged? And which may never be (in non-primaryDx settings)?,
    • 13:31:19 From Dan Rutz to Everyone: http://build.fhir.org/ig/hl7-be/hl7-be-fhir-laboratory-report/
    • 15:40:45 From Riki Merrick to Everyone: https://bridgmodel.nci.nih.gov/model-subset
    • 15:41:29 From Riki Merrick to Everyone: https://bridgmodel.nci.nih.gov/bridg-iso-dicom
    • 15:41:46 From Riki Merrick to Everyone: https://bridgmodel.nci.nih.gov/hl7-fhir
  10. Wrap up for day (next steps)
    • Riki to send link to the Add-on orders / Reflex testing etc in FHIR to Thibault
    • Mary to cancel the May call
    • Ruben to share the DICOM / HL7 mapping spreadsheet
    • Thibault to share slides presented
    • Raj to share the digital pathology PPT used today
    • Juergen to write CP(s) for XD-Lab


Day 3 - May 4, 2022

  1. Review DICOM Supplement 222
    • Type = Usage in HL7
    • Type 1 = Required; Type 1C = Conditionally required; Type 2 = Required if known ; Type 3 = optional
    • Looks like Annotation Group Generation: has a list of 3 enumerated values – looks like the values are text, but seem to function as code : https://dicom.nema.org/dicom/2013/output/chtml/part03/sect_C.7.html
    • Table CID ccc1. Microscopy Annotation Property Types – lists 2 codes from SCT – assume those are examples… what is the best mechanism to standardize these values
    • How do you SNOMED CT encode the region of interest that has multiple elements of interest – how would that be modeled? IHE PaLM proposes to create a list of top 100, unless DICOM already has that code system, or can you have more than one SCT code for this element?
    • This will be hard to do in a single flat list of codes – so there may be the need to create “buckets” of type of properties that are important to pathologists – this data is created by the pathologist while viewing the image
    • This may be related to DICOM Supplement 122 table on page 22 = Specimen Preparation Sequence; there are other DICOM elements that give other important meta data like source site
    • This information comes across with the order for the image creation and is attached to the image in DICOM structured report as metadata – now the pathologist needs to describe specific parts of the image
    • We may want to map out a few examples from specific reports into DICOM 122 and DICOM 222 to find the gaps. And then describe the proper value set definitions for each element
    • If annotation category type is the label for the text field, then we should identify the proper SCT representation for these, too
    • From Chat: From Ruben Fernandes to Everyone 03:30 AM: https://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_8135.html
    • They gave the same 2 examples in DICOM PS3.16 (probably most common ones). But it sates extensible. So local adaptations or external tables should be allowed
    • From Chat:
  2. XeHealth
    • Juergen reviewed the APSR wiki page to find the solution to reason for study (indication for the test)
    • The image needs to be updated to include the Clinical information section
    • XeHealth will consider using the APSR structure to cover the reason for referral section (at minimum) – to cover the linkage to the reason for the observation
    • Device Used is not in XD-Lab – where should this go?
    • IHE LAW supports communication of this information inOBX-18, but not many folks have implemented
    • Software as medical device is hard ( may need to track version number)
    • Look at the HL7 UDI Cross-paradigm IG here: @Riki to find
    • Where should these be put?
    • Measurement uncertainty:
    • TestCalibrator: is not currently well standardized in the lab (needs to be more than 1 allowed)
    • Molecular testing often has no specific calibrator set up – for example in PCR testing the curve adjustment is for the specific instrument for the run
    • Or are they talking about the harmonized test list (see: https://www.harmonization.net/measurands/ ) and knowing what international standard was used for harmonization – in that case just one may be sufficient
    • Lab observation names – LOINC has multiple naming options: Shortname / Long Name / Display name
    • What to put into the displayName? This is similar to original text in CWE.9 in v2
    • In v2 we also allow for more than one code system to be used (up to 3 since v2.6) – need to check if this is possible in CDA (and also check FHIR) @Riki to do
    • Can deal with translation to convert between different languages (though this is a translation of the same code, which is not the same)
    • Observation/interpretation – element should be 0..* in XD-Lab – this is OBX-8 in v2 (it is a CWE as of v2.6? – Riki to look up)
    • Harmonized code system across all 3 product families = https://terminology.hl7.org/CodeSystem-v3-ObservationInterpretation.html
    • If we can make this repeat, then can use also for trending
    • Reference range is limited to 1 – to indicate the reference range that was used by the lab to produce the interpretation
    • If you have a different unit of measure for the standard reference range you would have to repeat the entire observation
    • But you may need to specify if you have a therapeutic normal reference range – should consider to loosen this up? Or use observationRange/code? This Is not used - @Riki to look up and also follow up with Francois; If there are more reference ranges this is often reported as a comment
  3. Wrap up and Next steps
    • CDA look up follow ups for Riki and send findings to Juergen
    • Juergen some CPs for XD-Lab
    • Juergen some CPs for XD-Lab
    • Prep for Berlin: need docs for the Joint meeting with DICOM and then also have someone review the slides Riki will present on IHE and specifically the Digital Pathology work
    • Next F2F should be at CAP in either October or November (Mary to offer some dates)
    • Once LAW is update, we need to notify CLSI
    • Write test cases for DPIA (Raj to reach out to Nick, Mandel, Ralf and other scanner vendors) – Alessandro will share his experience in writing them for SET
    • Planning for publication :
        • DPAT white paper – September
        • TF updates – August ? Alessandro to do
        • DPIO for public comment – September and Supplement for Trial Use by end of November
        • Check with Alex about having testing for Radiology-Pathology Concordance profile
  4. From Wednesday chat :
    • 09:23:23 From Ralf Herzog to Everyone: Out of the book from Frank Oemig/Robert Snelick - HealthCare Interoperability Standards Compliance Handbook...
    • 09:30:04 From Ruben Fernandes to Everyone: https://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_8135.html - they gave the same 2 examples in DICOM PS3.16 (probably most common ones). But it sates extensible. So local adaptations r external tables should be allowed
    • 09:47:40 From Ruben Fernandes to Everyone: (0018,0015) Body Part Examined
    • 09:50:37 From Ruben Fernandes to Everyone: Sequence is type 2, elements are type 1. But I believe there are only mandatory if known to the acquisition modality -
             https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.6.22.html#sect_C.7.6.22.1.3
  2. Adjourned
Retrieved from "http://wiki.ihe.net/index.php?title=PaLM_Conf_Minutes_2022-May-2-4&oldid=128394"