PaLM F2F Minutes 2016-May

From IHE Wiki
Jump to navigation Jump to search

Minutes of IHE Pathology and Laboratory Medicine (PaLM) meeting

May 23 - 25, 2016

Berlin, Germany

Attendees

Name Company 23-May 24-May 25-May
Raj Dash CAP, planning co-chair X X X
Gunter Haroske IHE Germany X X X
Ed Heierman Abbott X(tc) X(tc)
Naomi Ishii JAHIS / Hitachi High-Tech X X X
John Hopson Abbott X X
Mary Kennedy CAP, board representative X X X
Carolyn Knapik CAP, secretary X X X
Megumi Kondo Sakura Finetek Japan X(tc)
Laurent Lardin bioMerieux X X X
Alessandro Sulis CRS4 X X X
Francois Macary Phast, technical co-chair X X X
Genichi Kato Shiga Hospital X X X
Riki Merrick APHL, planning co-chair X X X
Filip Migom MIPS X(tc) X(tc) X(tc)
Dmytro Rud Roche X X X
David de Mena SAS X X
Francesca Frexia CRS4 X X X
Francesca Vanzo Arsenal IT X X
James Harrison CAP X(tc)
John David Nolen Cerner X(tc) X(tc)
Jurgen De Decker MIPS X(tc) X(tc) X(tc)
Thomas Schrader Brandenberg X X
Lamine Traore UPMC - Paris X X X
Victor Feria X(tc)
Andre Huisman Medical PHIT X
Ralf Zwonitzer DGP X
Yves Sucaet Pathomation X
Mikael Wintell DICOM X
Frank van Apeldoorn Digital Pathology Solutions (Philips) X
Joachim Schmid Rocke X
Karl Weinbach Hamamatsu X
Marcial Gracia Hosp Jeratz X
Luis Alfaro HV Consuelo Vaeincm X
Johan Dore Hansel Viseopharm X
Arvyoas Laurinauicius Vilnius Univ. X
(tc) = Teleconference

Action Items/Wrap-Up

Action Items/ Wrap - Up

  1. PaLM TF v7.0
    1. Appendix A: add Analyzer Manager - Francois
    2. When are actors added? ask Mary Jungers – Riki
    3. Documents are on sFTP – review and send comments to Francois by 5/31 – ALL
    4. Finish Volume 3 by May 29th-Francois
    5. Submit all 6 volumes to Mary Jungers for publication on June 3 – Francois
  2. APSR
    1. Art Décor:
      1. Form authoring group (Gunter, Francois, Raj, Riki, JD, Frank) and get webinar from Frank- Mary K
      2. Review specimen DAM for harmonization – Riki/Raj
    2. Word document
      1. Review for most current changes and value sets – Francois/Gunter
      2. Add specimen organizer changes agreed to in Paris - Francois
  • Find other pathologists (more SME reviewers) - Raj
  1. Model APSR example using SDC - Raj
  1. Data Element Registry
    1. Share link to google drive to open source tooling for SDC form (Rich’s demo) definitions – Mary
    2. Data element registry white paper - bring up to DCC as plan – Riki/Raj
  2. Ensure LCC use cases are known to FHIR workflow discussions – Riki
  3. Find out more about HL7 CIMI work – Riki/Francois
  4. LSH – John
    1. Resolve the open issue on the semantic of command response sent back by device, possibly through email and the 2nd hour of PaLM monthly calls.
    2. Share the supplement for committee review, when its ready.
  5. Update SET profile Volume 1 - Alessandro
    1. Entering the design phase of volume 1: Focus on SET. This profile has no required actor grouping
    2. Follow the supplement template for Vol 1.
    3. Possible actor groupings to be illustrated (lightly) in section “Cross Profile Considerations”
    4. Review specimen DAM for input to SET– Riki/Alessandro
  6. Prepare the election announcement for email distribution in July/August– Mary/ Carolyn
    1. Japanese Co-Chair position renewal? - Naomi
  7. Send link to CLSI Auto 16 draft when available – Ed
  8. Review specimen DAM for input to SET– Riki/Alessandro
  9. Upcoming PaLM F2F meetings:
    1. November 7 – 9, 2016 at CAP in Northfield, IL
    2. Spring 2017 (April?) – Tokyo, Japan – Naomi to send dates to Mary/Carolyn
    3. Fall 2017 – Europe (Paris or Sardinia)

Minutes

Minutes May 23:

 

Welcome - thank you to the Charité personnel for setting us up!

Introductions All Around

 

Agenda review and objectives see PaLM_Committee_ Berlin_meeting_agenda_objectives.docx

  • Registry covers the vendor’s integration statement – attestation about profile and options implemented in their product
  • Connectathon matrix (actor, profile, transactions as search axis) consolidates results from Japan, Europe, North America

Data Exchange

  • Would like to understand the scope of DEX – seems to be for a specific profile data element exchange only (IHE wide data element registry would be nice – any IHE profile – this does not exit at this time we think – each profile is required to list the data elements in the registry that it supports / with constraints etc)
  • DEX is very recent profile (2015) – but only a specification for clinical research– if we think this is a good idea, we should bring this up to the DCC
  • AHIMA also has project reviewing tools that allow non-IT users to create definitions for clinical pathways by combining and possibly further constraining pre-defined data elements and describing the business rules around them, having all harmonized to one set of specifications.
  • CaDSR has a data element registry. The hardest part was the maintenance of the registry and the QC of what goes into it. Should we make an IHE project to create governance around that? We should propose for AHIMA to look at this as part of their tool evaluation project
  • FHIR has a registry of resources and profiles built on resources = simplifier.net.
  • So far for publication we have scheduled: TF and one Supplement for 2016 year.

 

Relationships of PaLM

  • IHE Board: Mary attends these. The focus is mostly on the new membership model and planning the IHE International meeting in Amsterdam. <a href="http://www.ehealthweek.org/ehome/128630/ihe-world-summit/">http://www.ehealthweek.org/ehome/128630/ihe-world-summit/</a>
    • Membership is still evolving. Visitors are allowed to attend 1 or 2 meetings; SMEs are always allowed, when needed.
  • Domain Coordination Committee (DCC): Riki attends these. This group focuses on how common processes can be applied to multiple IHE projects that are shared across the various domains.
    • IHE publication cycles are rather short; 1 to publication and 1.5 till connectathon is expected, so projects are for specification.
    • White papers have 1 year to be published.
  • HL7 has HSI (Healthcare Standard Integration) WG, which summarizes ALL HL7 work projects that list cooperation with other SDOs
  • HL7 AP WG will be focusing on the IHE project. The decisions was made to move the AP WG back into OO (Orders and Observations) and focus on project work until / if we have critical mass to create a separate WG. HL7 AP is currently working through this process of moving back to OO.

 

PaLM TF 7.0:

  • New template plus adding LBL and LAW that are now final text.
  • ILW is implemented by one vendor in France, but never tested in connectathon – may have discussion about how to get this ILW final text, now that we have virtual connectathons, hope to get more participation so that we can get to final text.
  • APW profile part will be used in digital pathology workflow – more likely split into several profiles to support the digital workflow – as well as ordering / reporting, which is close to existing LTW.
  • Vol 1 has been reviewed by a few folks.
  • Section 1.2:
    • Scope – need to be sure to cover the workflow of specimen handling.
    • Need to clarify that the first bullet covers the primary clinical use of patient care and prevention.
    • Storage of specimen needs to be fleshed out so that it covers logistics as well as clinical data.
  • Appendix A:
    • Need to add Analyzer Manager - Francois
    • Review to make sure ALL actors listed in PaLM TF are listed there.
    • Find out when actors are added – assume during publication of supplement (ask Mary)
  • Appendix D:
    • Review glossary definitions
  • Appendix E – has all the definitions that work across ALL IHE domains – no work needed
    • Reviewing change summary
  • Chapter 2:
    • Review what is in the diagram.
    • After review of SET tomorrow, may add it.
  • What about the SD data element reuse project? Once we have published as a whitepaper with indication of actors, then we can add the new profiles into the diagram for possibly the next version of the TF.
  • All transactions will be labeled LAB-<number>, so for the 3 LSH transactions we will assign those this meeting.
  • AP profiles published as supplements, don’t currently have LAB-<number> transactions identified, will be changed, when they are updated – example: APW will be split into digital workflow and the order and resulting, which was just LTW transactions
  • APHR profile – how will this move to final text?
    • Should coincide with HL7 OO. PHER project to address NAACCR DSTU comments on ELR R2, which most likely affects data elements from LRI and ELR.
  • For review of the documents – pull OFF the sFTP site and send your edits (with track changes on) to Francois
    • Committee review ends May 31, 2016

 

IHE PaLM Webinar discussion: see IHE-PaLM_Webinar20160726.pptx

  • Create a table with expected delivery dates for the current project.
  • Raj to supply an SDC slide for webinar.
  • Add more about XD-Lab.
  • For LAW recruitment is for implementation.
  • Include a slide on benefits of participating in connectathon. Include the dates of future connectathons
  • Highlight the benefit of change for improved handling of data exchange topics, better understanding of processes (see slides from Eric)

 

APSR v1.0 to 2.0 comparison see SDC_APSR 2.0.pptx

  • APSR v1.0 was published in 2013
  • Have discussed the title change to Pathology Structured Report (PSR)(the leading A for Anatomic is dropped)
  • CPs from 2014/2015 from Germany still need to be applied (work with Christel was done on some of these, but need to locate who has the latest version)
    • Problems around procedure steps were discussed in Paris (specimen related processing)
    • Frank and Gunter have transferred APSR into Art Décor tooling = v2.0:
  • Start with data sets which include terminology binding capabilities.
  • Scenario describes the actors and descriptions of the use case(s).
  • All CDA templates are in the repository that can then be further constrained.
  • Diagramming function will show the template in UML.
  • Can also be linked to wiki to share the changes performed in art décor with the larger group
  • Frank Oemig developed an APP for Data capture based on Art Décor definitions – have asked if he can write an app for SDC.
  • Schema from the tool for conformance testing is being developed.
  • The SDR project can reuse the data elements defined in Art Décor.
  • Need more authors in Art Décor. Can we request a webinar by Kai for those who have decided to become authors?
  • We should write PSR in Art Décor to have the schematron generation and checking available and link with the wiki for the text. Then combine them into the final document.
  • Need to check the work that has been transferred into Art Décor
  • Need resources:
    • Identify the plan for Art Décor updates.
    • Compare against SDC roadmap – concept behind SDC is to provide elements to create the flexible research project.
    • In the PSR Art Décor creation focus on the proper tagging of the elements with the right name / value pair to describe the context and content.
    • Concentrate on creating the generic definitions for the elements: what is a “stage”, what is “circumference”,
    • QRPH developed phase 2 of SDC with a schema that can describe the behavior of a data element for data entry as well as reporting.
    • Oct 2015 publication takes into consideration some template aspects, like different realm handling / or language coverage.
    • How should APSR and XD-Lab be compared for future consideration to be able to create the consolidated report supporting both of them. (APSR can include clinical pathology observation = lab observation) –> PSR
  • XD-Lab is mandated in France, Austria, Switzerland and is preferred in the EU.
  • Next Steps:
    • APSR as is transferred needs review to the existing word document (does the general template cover the specific templates for the anatomic locations as described in the current word document). The value sets will change. (Francois)
    • Specimen procedure step adjustments (see slides from Paris F2F, not yet in the document).
    • Discussion of handling of the organizer templates.
    • First step is to become familiar with Art Décor tooling. Team of identified: Gunter, Francois, Raj, and Riki (specimen focus).
    • Raj will recruit other pathologists to find more SME reviewers (CAP meeting in Seattle in June – will put on agenda).
    • Will the discussion with Andre about specimen workflow (APW) influence the APSR development as that may affect the entries in the APSR? Re-engineering is part of the plan for the intra lab specimen processing.
    • Are the radiological approaches the right way to go since the digital images are used for direct interpretation?
    • JD Nolan will also help with participation of Frank and Kai.

LCC

Working through HL7 Change Requests for v2.x. We need to make sure the FHIR workflow discussions cover the LCC use cases.

 

LSH

  • John’s image of the 3 transaction:
    • SPD = Specimen ProcessingDevice, STM = Specimen Transport Manager
  • Wiki for specimen in place acquisition
  • Use case #1: Specimen handoff- re-initialization
  • Use case #2: cancel specific specimen
    • Question about difference between not sending start and sending the SPD cancel?
    • Cancel should never be sent after the specimen acquisition has been completed.
    • STM gets the specimen Acquisition Complete and then it can move the specimen around.
  • Use case #3:
    • Cancel all specimen preparations to be able to start with a clean slate, e.g. for interface start up. Are there more steps after the cancel all request?
    • Change name of use case to “specimen handoff interface Reset or Re-initialization” – this also encompasses the risk that the STM needs to reset during specimen presentation.
    • Should this be the first thing for EVERY time the interface is started? Could be, but not required.
    • Whenever any ambiguity about the status of specimen orders occurs to the STM, not just when powering up the interface for the first time, could come up at any time in the use case 1 workflow – should highlight that this applies to ALL sequences the SPD should compete the initialize sequence before responding to the re-Initialization message – clarify that as part of use case #3.
    • Consider breaking up LSH-3 Command and Response?
    • How should errors be handled when the SPD is down, waiting etc.? This is implementation specific and not defined here. If there are more than two conditions where the STM does not know the reason, then the Response does not come back. Need to suggest a way to indicate reason for failure and guidance on handling those failures (time out for example).
  • Would this profile apply to micro automatic photos of culture plates? Out of scope / not actually taking the specimen but taking a picture – so could the response include the image along with the response complete? – would be a variation of the LAW more than LSH.
  • Should keep single transaction with 2 trigger events, because it would not make sense for SPD to only take commands, and not send responses.
  • Individual LSH-03 transactions can overlap each other for different specimen, which should not be an issue
  • Specimen processing capability of the SPD is requested by the STM.
    • SPD role is report status
    • STM is request status
  • Use latest HL7 version = 2.8.2 – should not have material changes. MSH has 4 extra elements (sending and receiving responsible organization and sending and receiving network address) and EQU uses CWE instead of CE.
  • Need to rename LSH-01 to proper LAB-<number>.
  • Under expected actions: add the expected LSH-02 response.
  • No security considerations – basic practice of the current status of lab security policy is that these transactions are inside the lab. IHE in general, expects a sometimes pairing with the specific.
  • Will have to add milestone for publication of supplement.

Notes May 24

IHE PaLM Updates from around the world

  • US Update (Laurent) see NA Connectathon.pptx
    • From NA Connectathon got some feedback on LAW – none for the other profiles.
  • Japanese Update (Naomi) see Update IHE-J 2016.pptx
  • Europe (Francois) see PaLM Committee Berlin meeting Agenda and Objectives.docx, page 6
    • XD-Lab France extension was built by ASIP-Santé, and describes the identification scheme of patients and healthcare providers in addition to base XD-Lab.
    • Austria update from HL7 WGM about ELGA project includes XD-Lab with National extension for the vocabulary and identification schemes and additional constraints to the structure.
    • Participation in regards to PaLM profiles was low.
    • LCSD has one vendor tested with simulator – SysteLab.
    • Advance Query tested by 6 vendors.
    • LAW was added to IHE Conformity Assessment program, which should increase number of vendors using / testing LAW (must have participated in a Connectathon in the last 3 years).
    • Clinical lab conference in June (Paris) may be another opportunity to give a presentation (so far no timeslot available though).
    • French ministry and IHTSDO started discussions about membership. Anticipate this for 2017.
      • Working on a subset of medication workflow translation into French.
      • MIPS has solution for ICU based on SCT concepts used in French hospitals.
      • Having associate licenses is additional push / reminder for the need of SNOMED CT adoption as a national standard.
    • Have built application managing ALL lab codes in Paris – sharing between labs and the hospitals.
    • LOINC is required in the XD-Lab French extension (type and report sections).
    • UCUM is required for units of measure.

 

SET Discussion: see PaLM_SET_F2F_Berlin.pptx

  • Out Of Scope: granular status changes during handling of automation.
  • What about the situation of tracking specimen location within an organization – in scope
  • PaLM-Y1 correct to LAB-Y1
  • Specimen Event Collector (SEC) – should we use Specimen Event Tracker (SET) which has the same acronym as the profile? Should not be a problem but try to always write out the actor names, except when we need to preserve space.
  • Specimen Event Sender / Specimen Event Receiver
  • Issues with use case for tracking LDA/LAW related status: wait for update to LDA to be better defined and for overlap with LSH.
  • Identified 2 simple use cases for biobanking.
  • Create use case called intra-organization inter-laboratory workflow.
  • Add the word “transfer” and remove “tracking from everything”.
  • Change specimen collection to specimen collecting
  • Intra-organization inter-laboratory transfer (different labs within the same organization)
  • Inter-organization transfer (between different organizations)
  • Intra-organization (within the same organization)
  • Inter-facility transfer (spatially / physically separated)
  • Intra-lab transfer
  • Intra-lab automation
  • Biobanking
  • Will need to explore existing framework transactions to see if all these use cases can be covered.
  • Use case #1:
    • Need to define control vocabulary to cover all the status changes we need for these use cases. Review existing control vocabulary - in v2 we have several different locations and vocabulary that cover specimen related statuses, reasons, etc.
    • Specimen collection scheduled
    • Specimen collection completed
    • Specimen departed
    • Specimen arrived
    • Focused on event: what, who, when, how
    • Do we need meta-data like temperature, or other attributes of the specimen?
    • Check Specimen DAM for data elements that might be needed for these use cases (also compared to the BRIDG biospecimen model) HL7 wiki page with most current minutes etc: <a href="http://wiki.hl7.org/index.php?title=Specimen">http://wiki.hl7.org/index.php?title=Specimen</a>
    • Label Broker and Specimen Informer are grouped, should be separated
  • Use Case #2:
    • May need to add specimen accepted / rejected.
    • Relabeling on the subcontractor (see ILW) as additional variation.
    • Change specimen delivered to specimen shipped.
    • Add SET actor to both sides – requester and subcontractor.
    • ILW is used in France in dozens of labs, but never at a connectathon since a single vendor on both sides.
    • Tracking when actors share SET information.
    • Need to consider harmonization with LCC and other profiles.
    • Does the use case require real time, or can the data exchange be delayed? Should not matter – MUST capture the date/time of the specimen event – that should be a trigger event; but intermittent network connection etc. or portable devices may delay actual sending.
    • Purpose of SET beyond ensuring arrival between actors, but also for work flow analysis – identify where processes are slow – specimen in a histology lab moves from one workspace to another or from one process to another.
  • Use case #3: intra-laboratory Workflow
    • For 3-1 and 3-2: Missing specimen shipped transaction
    • 3-1 – specimen collected on the ward
    • 3-2 – specimen ID by the LIS (pre-labeled) – have the event of re-identifying the specimen.
    • What about specimen has been received on analyzer and testing completed? That is the overlap with LAW / LSH
    • Harmonizing between use case 3-1 and 3-2.
    • How will central receiving and transferring be covered? Also how to track groups of specimen – nested containers, also needs to have location within container etc. – meta data as specimen shipped and arrived needs to cover the container location within the holder (which can be re-cursive).
    • Need to address the central receiving facility and distribution of specimen to one or more labs.
    • Specimen DAM differentiates between container (touches the specimen) and holder.
    • What about aliquoting?
    • Pooled samples - was dealt with in LAW – OOS.
    • Collecting pooled specimen (veterinary medicine – is OOS here).
    • 3-3 – specimen rejected – also missing the specimen shipped transaction.
  • Use case #4: lab automation – cross over to LSH
    • Analyzer Manager sends specimen to pre/post-processor as example.
    • Example how this new profile can be combined with existing profiles = events combined with order lifecycle.
  • Use case #5: Biobanking
    • 5-1: collect, ship and store specimen in biobank.
    • 5-2: query for stored specimen in biobank – would that be a different profile?
    • Biobank flow – level of tracking more robust than clinical care (protocols around the research samples) – additional meta-data on the tracking event, in order to support the protocol and biobank infrastructure (maybe part of the SR project?).
    • Basic transactions are the same; however, determination of what can be saved, what is processed for clinical care (aliquot), timing may need to be more granular, in order to support the protocol (if processing takes a long time, may affect specimen quality).
    • Very robust parent-child hierarchy – chain of custody.
    • Linking back from de-identified samples – OOS.
    • In the final document we create the main generic use case where these are the input.
    • Important is the list of events we want to track for each of the use cases (specimen movement, specimen processes (collection and consecutive processing)).
    • This collection good to write section x.6 cross profile considerations.
  • Open issue slide:
    • Include the events that happen on analytical devices for tracking purposes ONLY.
    • Collect list of specimen status concepts and then find the terminology.
    • Decision to use only 1 transaction for the SET. Metadata and codes may vary so we need to define which ones for each use case in Vol 1 as description (X.4.1) in concepts = list the requirements for every event category.
    • Vol 2 identifies how we actually fulfill the requirements listed in Vol 1.
    • Need to be sure the profile allows for customization, as we won’t be able to predict all the detail of events folks may be interested in – handle that in extensible value sets (terminology).
    • Consideration is for ALL specimen - not just the clinical specimen.
  • Next Steps:
    • Update Vol 1 as noted.
    • Generalize the use case for SET.
    • Collect the list of tracking events.
    • Create data model for the tracking event.
    • Publication planned early 2017 – review Vol 2 at F2F in Chicago.

 

LSH:

  • MLLP was only in version 2.3.1? – not concerned with socket layer transaction details – so not described anymore in HL7 later versions.
  • Where should the segment definitions for the supplement be placed?
    • Underlying segments are described in Vol 2.x, else in Vol 2.? for the new supplement.
  • Still need to define the states for the interface.
  • Mechanical issue of the SPD interface side = error state should be defined rather than leaving it up to individual implementations.
  • Proposed transactions:
    • ECD-1 = unique ID
    • ECD-2 is coded element
  • How to define the IHE profile specific vocabulary? Define at the profile level that we did for LAW, or create IHE PaLM and register that for the domain?
  • Do we want to manage a standard ontology? That is not the point – it is user defined table, no need to submit to HL7.
  • Defining codes: PRE = Prepare, STQ = Start Acquisition, CAQ = Cancel Acquisition, CLA = Clear All – from IHELSH (need to register with HL70396).
  • Use HL70387 as basis for Response to each ECD-2 command, extend as needed using IHELSH.
  • Controlling the amount of acquired specimen is part of the WOS from the analyzer manager, not part of the STM interface.
  • To deal with the possible reasons for when the acquisition could not be completed, add use of ECD-3 Error parameter text for display to the user.
  • Code: if the machine has protocol to handle based on code then different machine behavior is expected. Can still use the parameter text for user display details.
  • For cancel specimen acquisition command -> discussion about the codes to use: use “OK”
  • No preparation indicates that there is logic issue on STM to follow up and therefore important.
  • How do you say “could not cancel”, when acquisition has been completed?
  • From STM perspective, the important thing is to know whether or not the specimen can be moved, hence OK works for John, but does not explain the handling from the SPD perspective. Therefore need a different code; could be “ok to move specimen” or something, regardless, of whether the cancel command was followed or the specimen acquisition was completed or anything in between. SPD releases the specimen but it may not even have been presented to the SPD yet, so need to find a good term to indicate the expected behavior.
  • Move to the monthly call as a topic.

 

Structured Reporting see PALM Structured Reporting v2 Berlin2016.pptx

  • APSR R1 was designed around surgical pathology report structure.
  • Proposal was made to make it more generic to cover more use cases without requiring ALL pathology content be defined in organ specific templates -> introducing organizers for flexibility.
  • To cover the integrated reports now needed as the industry combines reports from AP with molecular and other data.
  • Reviewing PaLM SR Proposal:
    • Sequence should be less important than proper grouping.
    • SR is defining the data elements well enough to allow systems that use them to clearly understand them (and understand the language of the descriptions).
    • Structured to allow both human and machine readable.
    • Reference library consisting of data elements that are shareable should include a way to define business rules as well as defining which data elements go together (form grouping like in SDC).
    • Need to define the attributes for each element (cardinality, visibility, is used in, etc.).
    • How do we take APSR v2.0 and combine with SDC to create what we need?
  • Have 2 projects:
    • APSR v2.0 = CDA report in Art Décor
    • Broader scope for future PaLM SR = data element definition / registry
  • 3 levels of abstraction:
    • Data element
    • Grouped into form sections
    • Create templates from the form sections
      • Copy template for local instance
    • Richard Moldwin from CAP has used the CAP synaptic form and tested SDC at connectathon (eCC forms).
    • Have well defined data elements like demographics, and a few observations like vital signs that are well defined, but in AP have lots of changes.
    • Create a form template that has data element. Think of it as question / answer set.
    • Form definition with question answer sets as defined by IHE.
    • Link to data element repositories with attached standardized vocabularies that are versioned.
    • IHE profile describes the transactions.
    • Some behavior associated with data elements have been added in SDC last year.
    • SDC pilot as part of the IHE comment period for testing the XML schema of the form design template using standard RFD wrapper.
    • In IHE there is not currently the notion of a form creator.
    • Tables have the content of the question and answer elements.
    • Can SDC describe that data elements need to be hidden?
    • And form design tool (eCC form tool – has base template to create copy from for creation of new template) which allows access to the data element by reference to data element repository.
    • Raj to share link to google drive to open source tooling used.
    • IHE version used here.
    • FHIR version – using Questionnaire and QuestionnaireResponse resources
    • Plan to harmonize by moving IHE features to FHIR resources.
    • Create new WG to be able to transmit IHE XML form definitions using FHIR transactions.
    • Scott Campbell (University from NE) – Chair of IHTSDO Pathology Interest group.
      • Scott working on mapping the CAP Cancer reports to SNOMED CT in their NE university IHTSDO namespace (Riki to email Scott what he thinks about the CIMI effort on comparison to his work).
    • Observable entity: origin of the excised … - answer list is describing the topographic location
    • Can this be shared?
    • Roadmap to attach SCT codes to Cancer Checklist – yes via mapping tables in Richard’s Moldwin’s tool (pre-coordinated concepts as well as SNOMED CT expression)
    • Recommendations:
      • Split white paper into 2 shorter papers.
      • First paper about how IHE could implement IHE wide data element registry – bring up to the DCC when written – requirements and planned work as a means to get IHE community feedback.
      • Second paper content (see summary slide in set).
      • Pilot to create SDC representation for an APSR template based on excision template as basis for the white paper, which would help define scope and technical requirements.
      • Intention of the SDC is to capture the structured data, while report also has a lot of free text.
      • Define the roadmap early tomorrow morning to conclude the work split, etc.

LAW = AUTO16 Update see CLSI_Minutes_20160317.doc

  • LAW will become “Next Generation IVD interface = AUTO16” CLSI standard
  • A 20 month project (to complete March 2017) to publish the proposed draft
  • Vote was planned for July/Aug – about 2 months behind schedule as they are based on PaLM TF v7.0 Vol 1 and Vol 2b and some from 2.x to create a full specification.
  • Who can vote on the CLSI Draft standard? – assume it is open to all – CAP Committee has been trying to follow – how do we get information? – Ed will follow up with CLSI
  • AUTO16 is project name? – CLSI identifier, Title is Next generation of IVD Interface.
  • Will there be reference to the LAW? Assume so.
  • Will work on last CP for LAW as part of creation of PaLM v7.0 Vol 2b.


Notes May 25

 

Structured Reports (SR) Discussion |see PALM Structured Reporting v2 Berlin2016.pptx – slide #16

  • White paper #1: describe IHE wide project of creating a date element registry (exchange format independent) and determine the governance for the long term maintenance.
  • Support adoption and development of APSR, XD-Lab and APW updates.
  • Defer SR project until:
    • After comments on the white paper are submitted;
    • To allow for improvement of tooling for data element registry (DEX or SDC implemented in tooling).
  • XD-Lab took about 8 – 10 years to be in regulations in countries and deployed, so protect that investment.
  • APSR should become asset of the same kind – APSR 2.0 with added generalized template enhancement transferred into Art Décor and published from there.
  • Once central data registry is developed, we can then adjust /figure out how the APSR and XD-Lab artifacts can be enhanced (at minimum mapped to the elements in the data element registry).
  • Need to reach out to QRPH (they own SDC) and Patient Care Coordination (for their data element templates for CDA) – bring up to DCC as plan – Riki.
  • Data element definitions are independent of the exchange format.
  • Need to find out what the HL7 CIMI working group is doing:
    • Clinical Information Modeling Initiative (CIMI) – creating clinical information data models based on Open EHR archetypes using LOINC as identifiers, applicable units of measure, etc.
    • They have already built 1500 data models for reporting lab results.

 

PaLM Domain Co-Chair elections

  • Set up elections for two of the four Co-Chairs:
    • Technical Co-Chairs: Francois and Yoshimi.
    • Planning Co-Chairs: Raj and Riki.
  • Technical Co-Chair position from Francois will be up for election this year – he will re-apply.
  • Ideally should have 1 of each for AP and for Lab, but not required each time.
  • Ideally should have co-chairs across the globe.
  • In Japan IHE members don’t pay too much attention to being a co-chair, but Japan is very active in deployment and testing. They prefer to participate with feedback rather than leadership.
  • If Yoshimi not putting up his position for re-election, then Riki would put up her position and apply for re-election
  • Co-Chair time commitment is documented on IHE wiki under process pages.
  • Co-Chair term is 2 years starting in 2016 – election schedule.
  • Announce the plans for elections on the next monthly call – secretariat welcomes nominations until September 1, voting in October via email, announce results of elections at F2F in November in Chicago.
  • And will do the same going forward holding elections 2 month prior to the Fall F2F meeting.

 

PaLM CP processing: see LAW TF CPs 20160516.docx

  • CP for LDA to LAB-26:
  • Allow more than one specimen container group in the SSU^U03 and add comments on specimen container – was applied correctly.
  • The actor name was updated to Pre/Post- Processor.
  • CP for LAW:
    • Only non-substantial changes can be made in final text.
    • In figure showing the grouping of actors: LAS no longer showing – replaced by middleware, which is more generic – list as LAS / Middleware for the actor grouping that includes an automation manger  / analyzer manger – Francois will adjust.
    • Change the length of OBX-5 for datatype ED to unlimited rather than using the HL7 convention of 64k meaning unlimited – that was dropped in v2.7 – was changed, no need to annotate.
    • Allow use of OBX-6 for units, when OBX-2 is ST was decided to not allow it.
    • Support for INV-12 with usage RE.AN to be able to send contributing substances, if known from the analyzer.
    • Discussed how to handle the timestamp data type – where to find in FT, that time zone offset is used only in MSH-7 and applies to ALL other TS in the message.
    • Completed the CP changes.
    • PaLM TF v7.0 has been updated over break.

 

IHE Updates and Wrap-up  see IHE PaLM wrap up_final.pptx

  • APSR migration to Art Décor and wiki for creating the next version of this document.
  • Next F2F meetings:
    • PaLM F2F at CAP in Northfield, IL from November 7 – 9, 2016
    • Agenda is working on ongoing projects
    • F2F in Japan aim for April /May 2017(Cherry blossom and baseball time), except 4/16/2017 - IHE European Connectathon is first week in April - HL7 WGM May 7 – 12, 2017
    • Fall 2017 - Europe – perhaps Sardinia, Italy.
  • Review Domain milestones page: <a href="http://wiki.ihe.net/index.php/Domain_Milestone_Dates">http://wiki.ihe.net/index.php/Domain_Milestone_Dates</a>
  • LSH profile publication date – move to first Monday of Sept 2016 and also that should be for PC instead – for TI then Dec first Monday – white paper to mid December – Riki to update.
  • Send dates for Spring 2017 F2F meeting to Mary K – Naomi.
  • Send answer about Japanese Co-Chair position renewal - Naomi.

 

APW modernization introduction see APW_update_combined_proposals_20160411.docx

 

Digital Pathology Standards Committee

  • Keep profiles small enough to give the vendors more opportunities to deploy. Take the Order Placer, Order Filler and Order result tracker and make that the common PaLM profile.
  • Create digital pathology specific profile.
  • Radiology workflow is missing LIS incorporation – workflow.
  • Radiology dictates into the system that connects to the EHR-S report – only the radiology tech deals with the PACs for storage.
  • The pathologist uses the LIS as the tool to interact with the outside world as well as the instruments needed.
  • Different points at which the image is acquired (US stored on machine and PAC and document needle biopsy placement is correct) – macro pictures to show the transformation from gross biopsy to the different procedures to the slides, then micro.
  • Could use the still image as the index how the micro slides (WSI) are arranged in order to support modeling of the tumor.
  • At this point we want to create the base functionality.
  • Fine balance between having a single very large profile vs too many not well coordinated profiles.
  • APW transactions used in Spain – acquisition modality and image archive – RAD-14, RAD-16, RAD-10, RAD-8 (RAD-8 and RAD-10 are captured manually and uploaded to the LIS).
  • Gross images as well as WSI should be available – need to consider.
  • Radiology transactions are thinking about frames in terms of video, but different from zooming into parts of the WSI in pathology.
  • Secondary capture of the image to represent the gross and WSI use cases.
  • Should consider how to store images that are not necessarily DICOM (i.e. genetic sequencing). How would an image display be handling that difference, because the user needs to be able to trust the outcome of the image display / storage?
  • Today we support DICOM format – so perhaps we need to convert all images to DICOM for data exchange. It does not matter what format is used for storing.
  • Why are image manager and image archive grouped? Cannot just archive without some form of management – if we ungroup this, we need to make sure where the transactions need to go (RAD-14 should go to the Image manager) – this needs to synchronize the order filler expectations and the image display
  • Change Image archive -> image repository?
  • New APW:
    • Order Filler / Placer and Result Tracker = part 1.
    • Evidence creator / image manager and archive / Acquisition Modality / image display = part 2.
    • New reporting functionality = part 3.
    • QC for WSI flow – is manual, over time.
    • Similar flow can be applied to other use cases, that don’t require WSI.
    • Change “go back to sectioning” as result of “No” from “all needed views present” to “go back to acquisition”.
    • Consider creating a similar profile as the LAW in AP area.
    • General Pathology workflow – store DICOM SR vs expanded APSR in CDA format – this needs to be discussed.
    • Also need to consider research aspect of the available data – in radiology currently a lot of manual labor – next step AFTER the patient care use case.
    • Pathologists will always want to see the image along the calculated result from the machine.
    • Need to be ready to consider active sending as well as allowing to poll using API (FHIR).
    • Need to do some research if it is really RAD-43 that we want to replace with RAD-10 – Andre to do.
    • Fetching image use case needs to create new transaction:
      • Create a method to show the region of interest – change the DICOM standard used as basis for RAD-16 – Use one or more frames in a multi-frame image rather than many single frame images (which takes too long).
      • Getting an image of the DICOM object using Webservices (WADO) improved the fetch time appropriately – single regional view.
      • Would be good to send multi-frame images at the same resolution for the user – how would that work?
      • Needs discussion about picking one of the solutions or support both?
    • DICOM object may need information about specimen prep information - what is meant by this? (attributes of the specimen as well as the stepwise detail and custody) – use the specimen barcode to link to LIS information – not sure this information should be stored with the image – should be able to be produced, but see no need to store at the image level, (a lot of data) by using a query – when you remove the image from the storage – cross enterprise data sharing, also from the entirety of the image size, this data is not a lot.
    • Could this be similar use case to barcode labeling of a container – need to print image?
    • Must also include the scanner information in the image stored – DICOM standard has specific sections with required data elements per image (300) – specific to the image, not the entire patient history.

 

Joint session with DICOM WG 6 see DICOM_IHE_Berlin_2016.ppt

  • OMTIF has a framework to capture annotations well - can bring up to their WG meeting and could potentially reuse in DICOM standard.
  • Historically, annotations in DICOM were “burned” into the image – now dealing with annotations in overlay.
  • Presentation state format is often proprietary format, so when sharing images that information is lost.
  • Currently using separate data store for annotations and link them together with the stored image.
  • Regulatory requirements for the storage of the images and auxiliary data.
  • WSI supplement does not cover annotations – only how to construct the WSI from multiple views
  • Need to create the use cases and clearly identify the requirements to give DICOM the means to fix the deficits
  • How should virtual staining be represented?
  • Optical path per image, not at individual frame level (recommendation to make optional).
  • Use same tile size for all layers in the images – suggestion to be made for viewer support
  • Handling of empty tiles (currently viewers skip tiles where scanner thinks there is no tissue – if you skip a tile, then should show as special color (should this be in the viewer, or in the stored image for consistency?) – fluorescent image or not may affect the background color chosen – tag the empty tile, allow configuration for the viewer to select to use background color (determined from the calibration of the instrument) or another color.
  • Lens power is optional data point, so should be made required (Type1) – do we care about the power of the scanning lens = the viewing lens; or do we mean the resolution? The lens power is for the entire image at the time the image was taken – this is the way the pathologist thinks about the “zoom” type – translated from the microscope – it is the base the digital zoom gets to work on top of that.
  • DICOM has no tag to record the number of levels available for the image; you can have different numbers of levels across a single image – tag is needed at tile level.
  • Need to combine the domain expertise with the technology to create the correct solution that is valuable to the end user.
  • Include the clinical workflow in the considerations.
  • Summary from DICOM WG26:
    • Have 3 subgroups.
    • DICOM Structured Report – align with the APSR CDA.
    • Need to understand why we need the structured report in the format suggested - goal is to be as system independent as possible and pick the best of breed to accomplish that.
    • Multispectral imaging:
      • In histopathology with good input from the FDA (color summit a few years ago), discussing how to reference image and add in the muti-spectrum part – there are other standards dealing with that ICC v5 will be come out soon (how to separate fluorescence into channels).
    • Whole Slide Imaging Workflow:
      • Need to create a proof of concept to the user to help them create improved workflow.
      • Goal was to create demo at this meeting that this should be able to mix and match systems because folks are using standards.
      • The Basic workflow is divided into:
        • Order to LIS.
        • Scanner to create image.
        • Storage to image viewer.
      • Define 3 use cases in clinical perspective and get user feedback.
      • Struggling with the patent (Leica held) issue for Supplement 145 – how to create a pyramid DICOM object based on tiles.
        • Technical approach to the patent seems to not have an issue, but from vendor perspective it is still being perceived as too dangerous to implement.
        • Could DICOM make statement about the impact of the patent – the legal folks are looking into this and are meeting with Leica to try to resolve the patent (DICOM members could be able to use the patent for free – but that might have other legal / marketing impacts, NEMA/DICOM in not actively involved in the dialogues between vendor).
        • Patent is expiring in a few years, so could wait until then.
        • Another option is to retire Supplement 145 and re-write with the aim of a more multi-frame angle to avoid the patent overlap.
      • DICOM is in dialog with HL7 Anatomic Pathology WG – which is just now merging with Orders and Observations (OO).
      • What mandatory DICOM tags do we need for Pathology – define the different levels needed, if any – who should do that?
      • Have study level requirements from radiology – is that adequate for AP?
      • Should it actually be Patient, Study, Series, Instances level?
      • Do we need to adapt to the radiology based model, or create our own?
      • How can we merge multiple objects into a single object?
      • Looking back at Paris meeting notes – seems to have covered the topics raised then.
      • Divided the clinical workflow into 4 parts.
      • How to implement Supplement 122 for specimen processing into APSR.
      • IHE PaLM is working on White paper for central data element registry to present the need for that.
      • Will update the proposal based on feedback from today.
      • Digital Pathology with showcase in spring will be in March 2017 in San Antonio.

DICOM WG 26 could join next IHE PaLM F2F in Chicago Nov 7 – 9, 2016.

| Photos from IHE PaLM in Berlin can be viewed here.