PaLM F2F Minutes 2017-Nov

From IHE Wiki
Jump to navigation Jump to search

IHE PaLM Face to Face Meeting, November 13 - 15, 2017 Cagliari, Sardinia IT


Name 13-Nov 14-Nov 15-Nov
Gunter Haroske x x x
Jurgen De Decker (tc) x x x
Jim Harrison x x x
Raj Dash x x x
Mary Kennedy x x x
Carolyn Knapik x x x
Riki Merrick x x x
Kenichi Takahashi x x x
François Macary x x x
Alessandro Sulis x x x
Francesca Frexia x x x
Daniel Rutz x x x
Mario Villace x x x
Toon Claeys x x x
Jessica Poisson (tc) x PM x PM
Vittorio Meloni x x x
Genichi Kato x x x
Cecilia Mascia x x x
Luca Lianas x x x
Filip Migom x x x
Megumi Kondo x x x
Paolo Anedda x
Alessandra Gocca x
Andrea Costaglioli x PM x AM
David De Mena (tc) x
David Clunie (tc) x AM x
Pieter De Smet (tc) x AM x
Romaric Croes (tc) x AM
Frank Van Apeldoorn (tc) x
Ralf Zwoenitzer (tc) x
  • tc indicates attendance via teleconference

Supporting Documents

Summary and Action Items (details follow in Minutes)

  • TMA
    • Need for additional stakeholders from TM domain (nursing, )
    • Change requests to base standard attempted for Jan. & May WGMs -> delay until ?
    • Pre-adopt approved new features
    • Wait for Japan’s expectations this month
  • LCC
    • Publish for public comment (request sent Nov15 to MJ)
    • Public comment period until end January
    • Process comments (2nd hour of February or March call)
    • Publish TI in June
  • SET
    • Choose the standard
    • Check standard’s coverage (using the 2nd hour of the monthly calls in December and January)
    • Request for changes -> delay for approval
    • Write Vol 2
  • APSR 2.0
    • Migrate media wiki content to ( tbd KH)
    • Publish for TI -> target date January 25
  • Digital Pathology
    • White paper scheduled
      • Skeleton + initial content shared on GoogleGroup Nov 25.
      • December 13 call -> assignment chapters/contributors + draft the monthly call calendar for S1 2018
      • First draft for January for sharing within PaLM committee and with DICOM WG 26.
    • Re-check alignment of specimen representation
      • DICOM supplement 122 / HL7 Specimen DAM / IHE PaLM
    • Start producing the first set of profiles (image acquisition, image retrieval & display, ordering/reporting, …)
    • Join DICOM WG 26 in Helsinki around June 1st to work on the profiles
    • 1st profiles for public comment after November meeting?
  • LSH
    • Waiting confirmation of interest from Roche Diagnostic
    • Reactivate and invite other stakeholders to participate.
  • PaLM TF Maintenance
    • Write the CP (Filip + Riki + François)
    • Potentially one or two additional CPs
    • CP balloting
    • Integration into TF
    • Publish release 9.0 in June.

Minutes - Monday, November 13, 2017

Synopsis of PaLM assets and ongoing projects discussed during the meeting:

PaLM Assetts Projects.jpg

Summary of milestones set by the meeting:

PaLM Milestones.jpg

Thank you to CRS4 for hosting the meeting!

Introductions were given around the table and teleconference for attendees.

(See File:PaLM meeting Cagliari2017 FM v2.pdf)

Agenda was reviewed with no changes:

Other meetings of interest: possible co-meeting with DICOM. ECDP 2018 (European Congress on Digital Pathology) will take place in Helsinki, Finland, May 30th – June 1st.


APSR 2.0: (see File:APSR 2.0 PC Remarks.pdf)

  • Gunter shared pdf draft for Public Comment that was published September 2017:
  • Art décor tool now used to produce the APSR profile on CDA template (free tool):  
  • We will need help from Kai to deal with the OID issue. The annotation comment uses the PCC OID and there is a collision with OIDs due to large volume of projects working in art décor (international patient summary, EPSOS, etc.) and no good central OID management tool at this time.
  • The media wiki hosted by Germany is migrating to a new wiki to be used by IHE (pilot project).
  • Reason for statusCode of not allowing active for the observation entries
    • Do we reinstate the missing value set, OR
    • Use the statusCode value set and constrain to final and aborted?
  • Corrections are handled by full replacement of the entire report (CDA) with link to replacing document. The corrected / changed result is not clearly indicated. Consider either:
    • a header indicator in replacement reports that indicates where the change is, or
    • add a new section that lists all the references to the sections that are changed
      • May not be possible identify the actual correction, as that is often in narrative form.
      • Would be good to (at least) identify which section to focus attention on.
      • Review the base CDA standard for possible solution.
      • Need to consider other changes that are important for patient care (diagnosis change either minor or major error), and those not affecting patient care.

= If implementing this, we should consider the clinical impact of revision as well.

  • IHE-Lab extension is in header to the status of the entire report. We will need assistance from Kai to develop a solution.
  • Do we need Payer information in header?
    • This was requested by cancer registry.  
    • Could we use this section from PCC or should we add a participant in the header indicating this is insurance?
    • XD-Lab is an open document template, so we can add additional unspecified content (receiver does not need to raise an error if present, but also does not need to consume it) The header level would be the better location for this
    • Do we want to allow 0..* for insurance?  We would need to define what each one means, when sending more than one. This would be ONLY limited to patient member ID and Name/ID for the insurance company. (in Germany public health requests payment from insurance in order to reimburse the pathologist). We need to get a better idea of what elements we need as part of that insurance.
    • Include a note in the accompanying text that intention is just for reference, not the entire insurance related information, leaving the recipient to get more research based on the IDs provided.
  • Ask Kai what the difference in the tool is between “includes” or “contains” regarding author in additional observation versus in all other sections. We can then decide which way to proceed. Contains seems more compact.
  • Additive: in SpecimenDAM have additive in 2 places (in container and in the processing activity). In APSR we use the processing additive. There may be a difference in the vocabulary between the container (for transport) and the processing additives for preparation of specimen.
  • The circular reference is correct, since we can have recursive parent-child relationships.
  • ICD-O codes: not all are publically available (but supposed to be).
    • Why not use SCT? They are missing the cancer detail. iPaLM SCT could work on adding gap concepts to SCT. Gunter to bring some examples to PaLM.
    • ICD-O-3 has 1:1 map to SCT. We can research newer concepts.
    • M code has first 4 digits describing the morphology, the /5th digit describes the behavior part of the tumor. Can you have all behaviors for all morphologies? If not, it will be difficult to validate the codes.
    • Should we allow multiple code systems (SCT and ICD-O codes) in this element?
  • High level sections in APSR: would it be valuable to have molecular observations in a separate section instead of using the additional observation? Check with Clinical Genomic regarding CDA templates (Cambridge 2013)


SNOMED CT Candidate Free Subset: (See File:PaLM meeting Cagliari2017 FM v2.pdf)

  • SNOMED IHTSDO is now SNOMED International, headquartered in London
  • There is an effort starting in USA by University of Nebraska’s Scott Campbell (chair of iPALM at SNOMED International) with a deliverable focused 3 year plan to create SCT codes for all CAP cancer protocols.
    • Harmonized with Australia, Sweden, UK, and Canadian rules.
    • We will need to check with Netherlands (European organization for SCT harmonization) as to their status with this effort.
    • Working on genomic concepts related to cancer with clinically actionable components. Breast, colon, and melanoma are completed.
    • SCT codes will be listed in University of Nebraska’s extension in UMLS and will be available.
    • LOINCs are generated for SCT observables created for these cancer protocols. Discussions are ongoing about migrating LOINC into SNOMED International.
  • Francois introduced APSR to the SNOMED International work and they will use it as basis to attach the vocabulary binding for the cancer work.
  • CAP direction for incorporating SCT: the vocabulary will be added into the work. Scott will have to deconstruct some of the SDC eCC representation. This might adjust the data model to be of a more clinical data focus as additional material to the eCC work.
  • Since SNOMED International requires country based membership (or per individual implementation) – annual fees based on GDP of each country – more info:  It cannot be a required vocabulary
  • How many concepts to add for synoptic cancer reporting? For variance reporting would be under 100, but several 100/protocol. TMN is not part of it due to an AJCC licensing issue. Prognostic staging is excluded (includes biomarkers and other indicators), but should be able to include limited TNM staging declaration.
  • Next step will be in January, so if there are more requests for free SCT codes, add now and send to Co-Chairs.
  • Here is the list for review:


IHE PaLM updates around the world:

  • Japan: (see File:PaLM-IHE-Japan.pdf)
    • Change in Lab Co-chair: Yoshimi Hirasawa is replaced by Naomi Ishii.
    • IHE Connectathon had about 160 participants. Summary results will be posted soon on the internet.
    • LTW-MB = national extension for microbiology used in Japan
  • US:
    • LAW to CLSI AUTO-16 conversion: the plan is to publish for proposed draft vote for 60 days at the beginning of 2018. This will replace the old ASTM standards used for instrument connections: CLSI is ISO TC 212 supported.
    • Connectathon will be held January 15-19, 2018 in Cleveland, Ohio. LTW and XD-Lab, maybe LPOCT (single vendor) and LAW (if Orchard joins) will be tested.
    • LOI / LRI update: both are in ballot reconciliation. Added profiles include clinical genomics to LRI and newborn screening for LOI and LRI. Publication is expected sometime in January or February 2018.
  • Europe:
    • Belgium:
      • LTW has experienced some implementation.
      • CDA reporting using XD-Lab to forward lab results to the physician. They will use a messaging wrapper for exchange.
    • France:
      • larger hospitals are implementing LTW
      • Use of XD-Lab is mandated from laboratories
      • Not sure a lot of folks have implemented for microbiology
    • IHE-Europe Connectathon in the HAGUE, 16-20 April 2018.
    • New HL7 project to represent micro for handoff from hospital to nursing homes (care transition between acute care and long term care). There are new PSS CCDA infectious disease additions.


LCC Update to review for publication for comment

  • A pathologist can place an order for HER2 testing, it can be added to the system, and refinement on the exact block that the order should be made on can occur at a later point in time. LCC could potentially be used for that, as long as the system can handle the incomplete order. In current systems the pathologist in the laboratory does that adjustment. GAO profile (clinical decision support profile) does something similar? Example skin sample placed order for GU test – currently need to cancel the test and add in a manual order that needs to be authorized later.
  • The LCC already makes note that all use cases are lab based, because of our expertise.
    • Pharmacy may have to look at how the RDX segment may need to be changed to match the added field in OBR segment in the OML and (in radiology) OMG messages.
  • Will circulate to google group and then will send for publishing on Wednesday, so all comments should be submitted by COB Tuesday to the group.



  • No comments received on the document (comment period closed yesterday).
  • First in series of Transfusion Medicine profiles: Adverse event reporting – prior to that have the dispensing workflow and then the ordering of the units (some issues exist with linking crossmatching to encounters or patient MRNs etc.)
    • HL7 v2 specification does not currently handle the detail about the adverse reaction, so we will need to propose a new v2 message to get that covered. It is planned to work with HL7 Patient Care group, who is designing FHIR handling and data modeling (allergy reaction)
    • Adverse outcome on patient side could be relevant, but is not part of the current documentation (due to terminology being based on US centric reporting requirements (who is reporting to whom).
  • Reviewing the profile:
    • Open issues:
      • New codes for the HL70513 Blood Transfusion Disposition status (at the unit level) will need a harmonization proposal for the next cycle Mar 2018.
      • Need to additionally include status that describes when administration was interrupted – with or without a reaction. Suggest to pull the existing equivalence from the treatment completion status (HL70322), which has less useful codes (Complete, refused, not administered, partially administered). (Ask Margaret about nutrition administration status codes).
      • Do we need to document a rate change for blood transfusion like you do for IVs?
      • Clotting factor – is that medication or blood product? (Ask Jessica)
      • Finland has national blood management system and red cross system for adverse reactions (may need independent reaction consumer).
      • France is building national infrastructure for adverse event reporting which supports keeping that actor separate. Our focus is suspected reaction, not a verified reaction that is reported to the authorities for investigation (this is prior to the blood bank having to report to authorities). Consider adding the report from the blood product filler to the adverse event consumer.
      • The instructions are to stop the transfusion at any time there is suspected reaction and call the bloodbank, so it indeed is a different “beast”. Is there terminology around this? Probability is assessed/ determined by the blood bank (possible, probable, confirmed, what other?). Would it be useful to capture the assessment from the blood bank to the transfusion documenter?
      • Is the report from the transfusion documenter suspected initially and then confirmed from blood product filler? The assessment is in the blood bank system that will be reported back to the EHR (currently as a narrative pathology report) and if appropriate, also to the PH authorities.
      • Highlighting specific antibodies is currently non–standard script. Some systems may need this.
      • When the blood product is contaminated it needs to be sent to the supplier of the blood product. This bleeds into the inventory workflow. We have ruled OOS, but we may need to refine. This occurs more commonly with platelets.
      • Will need reaction consumer as stand-alone actor.
    • 2 phases of LAB-76
      • One for suspected reaction from documenter to filler. This filler is actually an order to evaluate the observations sent.
      • One for evaluation of reaction from filler to documenter (and possibly to public health). This may be a distinct translation, because it is a logically a different step in the workflow with different semantics.
      • Is the blood product filler, not the blood transfusion documenter that reports to the adverse event consumer? The endpoints are different systems, but is the role the same?
      • If there is no reaction, the transfusion is continued, or repeated – so no report is sent.
      • Dan will try to adjust the diagram for us to review
      • LAB-76 is expected to carry the observations about the relevant vitals for the suspected reaction messages. This may not be needed for confirmed reactions but should be possible to send.
      • In Belgium there is requirement to document the vitals (RR, pulse and temp) for patients with transfusions every 15 minutes. Should the vitals be sent ONLY in the documenting message, or should they be included in the transfusion status message? Vitals at the start of transfusion are the baseline vitals. Vitals in the transfusion status message are not a continuous feed.
      • Vital attached to suspected reaction message are useful; it would be useful to include the baseline vitals as well as ALL vitals up to the moment in time that the reaction occurs. It may be better to only include the vitals from the start of transfusion/pre-transfusion and those at the time the reaction occurs.
      • We may need to review the OBX-29/OBX-30 value sets to cover other reaction types as well as noting which ones are vitals.
    • The described scope is fine with the following exception: The line about whole blood transfusion not being needed should be changed so that whole blood is added as another available blood product.
    • Need more description on the workflow. Consider for the next round of review.
    • Currently reporting to FDA is ONLY for fatalities due to blood transfusion via phone or email.


SET: (see File:PaLM SET F2F Cagliari.pdf)

  • Container definition may be:
    • A single tube when the specimen is collected;
    • A shipping box that holds multiple containers (so we can track the box a specimen is shipped in);
    • Specimen can be spread across multiple containers, which is why we use specimen ID pus container ID (i.e. 24 hour urine collected in multiple containers).
  • Does the label on the tube contain the specimenID as well as the container ID? In many cases, systems will assign the container ID based on the specimenID, and may add further IDs to the specimen, such as -01, or -A, but it is not mandated.
  • Need to clarify whether the specimenID refers to the parent specimen ONLY or to ANY specimen, including a derived specimen. In the specimen DAM we consider each derived specimen, including aliquots, as specimens.
  • Wil have to look at LBL profile use of specimen ID and container ID.
  • Matrix open issues (red font items)
    • Do we need to include associated ordered tests in SET? That would be only for specimen container prepared and specimen collection events.
    • We must be able to represent the timestamp of the event.
    • We need to define these timestamps:
      • Effective time of the event (for example the collection date/time, the processing date/time, the transport date/time)
      • Event documentation time (Entered into system)
      • Message created / sent
  • FHIR resource includes the reference to the procedureRequest.
  • Drop the placer group number and the associated test list (should be in the order workflow). We may need to list the dependency on another profile to query for the order information based on the placer order number. This would be limited to the time of the event.
  • Goal of this profile is to document the event and not the specimen itself.  Consider this as a snapshot of the specimen at the time of the event. If you need to look for ALL associated tests, may need to look in more places and not rely on SET to find all related orders on a specimen.


Minutes - Tuesday, November 14, 2017

APSR 2.0: (see File:APSR 2.0 PC Remarks.pdf)

  • Updates to reports
    • Add update organizer and place it into the diagnostic conclusion section, since it is the ONLY section that is required.
    • Use the organizer from PCC titled UpdateEntry
  • TemplateID can carry the context, so we don’t need to assign a LOINC to the section.
    • Try to find a code in LOINC or SNOMED CT that can represent the clinical significance level.
    • What kind of values should we have in this value set (significant, not significant) as it would be important to indicate if patient follow up is required?
  • Typographical correction – documentation update
    • Updated information (more accurate description, additional diagnosis), but has no impact on patient care.
    • Updated information with impact on patient care.
    • Diagnosis section changed  
      • “minor typographical error / minor change, not clinically significant”
      • “change, clinically significant”.
    • Location of the updateOrganizer does not have meaning so it does not imply that the change is ONLY in the diagnostic conclusion section.
    • The PCC organizer would have to be repeatable to allow more than one change.
      • PCC update entry text has verbiage: This reference shall not be present when the update entry is adding new entries or sections. ALSO, this entry cannot repeat and MUST be in the section that has been replaced.
    • We would like to make our own organizer.
      • Allow the change reference to repeat, but only have a single flag if the any of the changes are clinically significant.
      • Need to define the value set
  • Payer templates should be optional elements with cardinality 0..*
    • We are looking for key insurance information.
    • Gunter has created a new participant called Pertinent Insurance Information.
    • Associated entity references the patient that is insured by using the ID assigned by the insurance company.
    • Associated person is the physician affiliated with the related insurance information.
    • Scoping organization = insurance information. This means that information applies to everything in the report.
  • ICD-O typing codes:
    • Use this template, if ICD-O has to be used, e.g. when country needs to classify the observation of the morphology, the behavior and the grading. We can already report SCT codes using the normal observation (morphologic abnormality which can be expressed in SCT).
    • First 4 digits are morphological abnormality.
    • 5th digit is behavior.
    • 6th digit is grading.
    • This template deconstructs the ICD-O code set so that you can represent the current data in the underlying system.
    • This helps validate the underlying syntax of the specific code system. It could also be accomplished with regular observation templates.


Digital pathology: (see File:IHE APW REDESIGN 1.pdf)

  • APW redesign
    • Focus on surgical pathology with tissue specimen workflow (there are others like autopsy or cytopathology).
    • When a consult is received it should be included, since the specimen is already prepped.
    • Sakura is working on automation lien for digital pathology
  • Scope:
    • In Berlin we had split APW into multiple profiles = manage order placer/filler and result tracker under LTW = PAT-1 / PAT-2 / PAT-3 => LAB-1 / LAB-2  LAB-3 to create the order and result management profile in future (OML / ORL / ORU / ACK) – can also consider ILW (LAB-35 / LAB-36) for external orders = consults for that profile
    • For pathology we have 2 extras from clinical pathology. More often changes occur to the procedure request which is covered by LCC.
    • We need to specify the result we are giving. It may be APSR in pathology versus V2 messages with the additional option to use APSR or FHIR resources in the future. Many hospitals still use V2 messaging in AP.
    • We should start with tissue arriving in the lab.
    • End with the series of glass slides that have been digitized and are available for viewing. The viewing part may be a separate profile, since those are separate actors.
    • Should clinical transaction include tumor board? Tumor board may be larger than PaLM. We should focus on the data elements we may need to collect (is that the APSR = diagnostic conclusion and some images). PCC should be managing the tumor board profile, as this is multi-discipline input for the patient.
    • Glass slide is being read (based on scanned barcode) when the scanner creates the digitized slide (that step needs to be included in the profile – the image metadata that must accompany the image). Do we need an order message for that? Scanner vendors are just starting to create DICOM images. The next step is to add in the transfer to the scanner. This will be determined by whether the DICOM workflow or HL7 messaging is best suited;
      • LAW provides the option to query for AWOS which is similar to automation step in CM;
      • Can also have an SOP – when you receive a slide, there is ONLY 1 type of procedure to be performed, so may not be needed – need to identify the differences between radiology (human interacts with machine to image a human) and pathology (slide is barcoded and less human interaction –
      • Scanners do have parameters that need to be set for specific types of tissue, or for certain situations – it can be SOP based so the LIS can send the parameters? Should that be in the LIS vs scanner, who has to maintain that kind of information;
      • In radiology there is assisted acquisition workflow using specific work codes in the worklist / or unsolicited message (similar to message from analyzer manager?). Some pass through metadata, controlling scanner behavior, number of scans.
    • Need more information about how the scanner will take in data, so we need scanner vendors to participate to get that information.
    • Barcoded unstained slide, apply the AB based on protocol. These workflow steps are pre-programmed into machine and ID identifies that protocol and the LIS sends the request for the protocol ID.
  • Create 2 profiles:
    • For slide image creation (along with the meta data needed for viewing and result interpretation).
    • Viewing of slides (larger than the encoding reports / interpretation and producing reports).
    • And separately the report creation / interpretation, which may include step of viewing slides.
  • Digital slide viewer actor is needed for viewing and interpretation workflow.
    • It may be needed for QC during slide creation whether by manual or automated methods.
    • Radiology has profiles for consistent presentation of images. Image selection is important for viewing and annotation.
  • There are 2 types of viewing – for diagnosis versus for post-diagnosis viewing (ability for making annotations is different or post-processing analysis of image). The retrieval for either are the same.
  • Have to have several actors: scanner, archive, viewer, analyzer and analyzer manager. We may need to re-evaluate the definitions used in LAW.
  • Keep in mind the histology process map (patent application from 2007).
  • Keep in mind automation.
  • Can we remove the PACs box, but retain the image manager and archive actors?
  • We need to discuss if we are going to use DICOM messages developed for these workflows.
  • We are definitely working with DICOM WG26.
  • Digital assets in pathology are just one part in the APW (DICOM covers the transactions for images = whole slide images and gross images) along with staining, slicing etc.
  • Need to define the actors and transactions we need (slide 20 lists all of these)
  • Acquisition Modality devices
    • Image storage => image archive;
    • Iimage workflow manager = creation of images in a particular sequence in automated fashion up to the interpretation of the images = similar to the automation track manager in Clinical lab;
    • Add image manager for handling of post-production workflows and rename to automation manager (workflow manager); automation manager organizes the different acquisition modality devices while we need another actor that communicates the detail that needs to be done for EACH of the acquisition modalities;
    • We also have “analyzers” that review the images (post-acquisition steps = evidence creators in radiology (using the push workflow and automated result creation)). It currently does not handle interactive review at this time (pathologist identifies the region and the function that the “analyzer” needs to perform and produce results for).
    • Image viewer => image display
    • Automation manager will take care of the instructions to each evidence creator (based on protocol).
    • Endoscope with in vivo microscopy is clearly out of scope the PaLM domain, which is limited to in vitro studies. IHE has a dedicated domain for Endoscopy. However, assets (profiles, images …) produced by the Endoscopy domain of IHE may be useful to the digital pathology workflow in the PaLM domain: (Endoscope is placed and then take images of microscopic view of the mucosa, pathologist identifies the place for the biopsy, or OCT down the endoscope = exclude them from this effort, it is not done in the lab per se – quite different workflow from the other use cases, since the management is different in the EHR-S also.)
    • Ultrasound images to document needle placement of biopsy – do we just reference this image in the order, as it is really identifying the specimen source site? Keep this as text in the scope section
    • What if the pathologist performs an xray on the specimen? We will cover this as part of the radiology workflow; as part of gross interpretation these images are pulled up now (there is no patient related order associated with this specimen radiograph, because the order is done in the lab with the specimen ID).
    • Consider focusing on some items like gross and WSI now and then expand to the others later; keep the stakeholder list limited to achieving a profile for now.


Correction of results: (see File:20171113 IHE Filip.pdf)

  • Correction sends a valuable flag to the EHR-S to indicate that is something wrong.
  • C status means we need to make a CR for PaLM-TF to use the original HL7 definition and update all references to C in the remaining text.
  • Can we use OBR-25 to indicate the order is not yet final? LRI added code M (correction, but order not final), but currently F cannot go to M per LRI.
  • Can we use ORC-5? And use A after CM for the time when we have OBR-25 and OBX-11 = C, but the OBX-11 is not yet final – at which time it goes back to CM – remove () around CM and add a row that includes A / C / C.
  • ORC-5 is conditional in LTW – MUST be in OML from filler, but not supported in OML from placer, we are silent on what use it is in ORU messages, which is what we are talking about – add to condition predicate:  “In result messages this field is optional.”
  • Will the change from F to C include the removal of the result from view of the physician? In LRI / HL7 OO we are working on adding a new field to OBX that describes a data absence reason (no data in OBX-5); use “” (as long as folks don’t interpret this to delete existing data in the database). Is there guidance that you HAVE to send the result before it is verified by the physician? This use case does not imply that this change in result status is the reason for the message; more likely it is another result that has a reason to be reported and since we are sending in snapshot mode, we have to send something when that result is in any of the normally supported statuses.
  • Since we are changing the diagram, move “O” to the same line as “X” and “D”.


SET: (see File:PaLM SET F2F Cagliari.pdf)

  • Matrix of elements:
    • Container number – we consider we have a new specimen, so each specimen is only in 1 container.  For order placer they may NOT follow the same approach, so they may only identify the containers with the patient ID and may need to convey the number of containers associated with the specimen.  Accessioning may happen in the lab or at the time of specimen collection. You have to capture the parent specimen.
    • Change container rank to container number. There is no need to document a specific order of the containers. We may need to keep the sequence of the draw (i.e. CSF samples, where the later samples may be contaminated with blood).
    • For a point in time collection we need to fill in both start and end time = will be the same date.
  • ContainerAdditive vs ProcessingActivityAdditive in DAM: we need to figure out what is the difference and take it back to HL7 OO for discussion (we just closed ballot reconciliation, but maybe make motion to re-open to add this as discovered item).
  • RejectReason is a string but what about code? There are some codes available, but they could still use some tweaking.
  • Biobank use case:
    • We are standardizing the event model. The de-identified flag is not in the DAM, so we need to discuss; the honest broker has assigned an identifier for sending out, but has mapping to the old identifier, so can be re-identified. Does the receiving lab need to know that a sample has been de-identified? It may be needed for chain of custody tracking;
    • Do we need to re-introduce the old use case of de-identification, which we took out a few calls ago, since we figured it is the same as the re-identified use case, but in the first case, you want to keep track of the old identifier?
    • What if we just overwrite the specimenID for the de-identification use case? You need to update ALL identifiers that can link back to the older samples. Rather than Boolean, have re-identified comments and write guidance for what folks should do for each and they can note that the de-identification or re-identification for consulting is happening.
  • Specimen arrived:  Use holder identifier and holder position to describe the boxes.
  • Specimen discard reason – not covered in DAM.
  • For specimen retrieved need to add retriever name / etc. which is the performer on the specimenMove.
  • Transformation to underlying standards from DAM mapping:
    • We are covering notifications so v2 is more common to cover this kind of functionality (FHIR is more for looking up resources for retrieval).
    • V2 has specimen shipment message. We can look for other segments that cover data elements in SET (may be EVN segment, potential CTI segment, for sure SAC, SPM, MSH).



  • Open issues:
    • #2: Sender and receiver should have to support LAB-76
    • #4: Reviewed HL70513 – begin, complete, interrupted ending; sometimes you can resume transfusion of a unit. Do we need the resume action be separate and to not reuse “begin”?  This is an uncommon situation.
      • Also have to take into account how long you can use the blood product after removed from dispense (expiration date/time). It is more important to know if the patient got the whole product or not.
      • Do we need volume transfused for interrupted transmission? Currently assume it is estimated as part of the reaction work up. We will know the starting volume and evaluate what’s left in the bag that is being sent back with the report; in some cases the exact volume transfused is obtained from the pump.
      • Currently record the volume transfused from the IV pump for all completed transfusions (in ER situation may be estimated, but still reported as amount) – use BTX-9 for that volume.
      • Update the use case diagram per the material Jessica sent for review.
      • #7: Start with units that are assigned to patient. The assumption is to document who has approved the transfusion when it is started.
        • There is already a positive patient ID message being exchanged (blood bank assigned to patient based on blood type). Two users need to sign off on the positive patient ID (in some cases 2 physical persons and in some cases a system can be one of the users.)
        • Message is sent with ID of the bloodbag and the results of the cross-matching. Just prior to transfusion, the patient ID and product ID are scanned and verify that there is NOT any change since results were sent (currently the same system does this). This is effectively a query to the blood bank system to see if the patient and the product ID are still linked. Design this to allow this messaging as optional and attach regional requirements with an override reason included for administering the blood product, even if there are mismatches against the algorithm. These checks should all be done in the bloodbank side and the lab will give ok to transfuse; should not be left up to EHR-S algorithm to determine if OK.
      • Remote refrigerator:  Record what unit is assigned to which patient along with  the crossmatching information and the bloodbank approval to transfuse. This is usually done in emergency situation and applies basically for O neg units only, which bypasses several safety checks.
  • Next steps:
    • Have started outreach to vendors, and will update documentation based on feedback.
    • Incorporate comments – if we feel like we need the new transaction.
    • Work out HL7 message CR requirements.
  • Status code table changes: interrupted, interrupted with reaction and begin
    • 2 messages first = start time only; second message will have start and end time.
    • Maybe a third message after transfusion that changes the status to the completed with reaction (add documented flow for this).
  • Consider what connectathon – soonest may be Japan, if there is desire there (Megumi and Kenichi are checking) – most likely for NA in Jan 2019, so we have time for Trial implementation publication = aim for Sept 2018.
  • Aim for 2nd hour in Feb 2019 meeting to discuss HL7 WGM outcome of introduction of the new message structures.


Minutes - Wednesday, November 15, 2017

Digital Pathology: (see File:IHE APW REDESIGN 2.pdf)

  • EHR-S to LIS (slide #2):
    • Same as PaLM TF LAB-1, LAB-2, LAB-3 for use in APW and then pull it out = Ordering and Reporting (need a name for final profile).
  • Order filler – Acquisition Manager (similar to Analyzer Manger in LAW):
    • (LIS) order filler issues requisition: WOS.
    • Acquisition Manager queries LIS for WOS.
    • Similar to LDA or LAW? Transactions LAB-22 or LAB-27? (WOS query), or LAB-21 or LAB-28 (WOS broadcast) – need to figure out what the response would be – may be LAB-26 (WOS status change) not LAB-29 as that includes results.
    • Limit to Whole slide images (WSI) and macroscopic images for now.
    • Do we need to query acquisition manager for status or forecasting?
    • Are we getting a single slide or a set of slides (set of images related to the accession on the bar code)?
    • We may need to state that the identifiers are produced locally as a pre-condition (accession number as primary identifier of the slide or separate slide ID?). We have a case accession number and a container ID, blockID and slide ID (often derived from the accession number). Different IDs for gross sample (container and slide) and container ID; both are linked to the specimen ID.
    • Take a glass slide that is supposed to be sent out for consultation and put it on the scanner.
    • There is a device targeting and a slide selection step we need to cover, we need to write those up
    • The acquisition manager is currently located in the software that manages the slide scanners and not in the LIS.
    • Order Filler to Preparation Manager (similar to automation manager in LDA).
    • Automation manger takes care of the slide prep and any other processing step (including track management (LSH)).
    • The transactions from order filler to these managers are covered by LTW WOS (LAB-4) and WOS status (LAB-5) and queries; the listed transactions are from the respective manager to the acquisition modality systems (WSI scanners, gross image producer) or the image analyzer respectively.
    • US approved systems right now are combining scanners and analysis in the same box.
    • For the prep automation we need to consider the different steps needed – LTW -> LDA or LSH as needed.
    • Which transaction would we use for identifying the HER2 scores in an image (results)? There is a corresponding image for subjective review. Do we need to have it respond similar to the acquisition modality, perhaps group the analyzer with the evidence creator for this?
    • This may be a new image, or an annotation object that is referencing the existing image (to reduce file size); in addition, discrete data like a score or count may be produced.
    • Do we need status check here? Depends on how long this step could take. Do we have status?
    • We need to consider error handling (i.e. scanning cannot happen due to cracked slide)?
    • Status of WOS: we do not have that at this time. We will need to create; we can then also consider including the location of the slide/annotation when completed.
    • Do we want to support unmanaged image analysis? They are only doing a single action, so it is really a standing order, but that is on the level of individual analyzer. You may not need to define transaction between the manager and the instrument then.
    • How do you get some communication when there are issues with the analysis algorithm? Do we need a separate profile (region of interest profile – is it a sub-image, or specifying the coordinates, etc.)? For now let us cover it as status of “human intervention needed”.
  • Acquisition manger to acquisition modality:
    • Need to get the application vendors in the room
    • Descriptive meta data and ?? to the scanner – push the WOS to the scanner or pull WOS from manager.
    • Need to define the data elements for these transactions
    • DICOM modality worklist or other way that does include the DICOM identifiers (study ID MUST be added for DICOM).
    • Expand the scope of this use case to include the archive manager in this workflow. Should keep as separate transactions, but we need to group the acquisition manager and image manager for an efficient workflow.
    • APW currently uses RAD-8 for storing images and can probably be used as is.  RAD-10 (retrieve) will need to be modified, or consider adding in the newer versions of DICOM technology for query and retrieve image transactions. We need to describe the display behavior as part of this. How do you find the right tile, size of tile etc.?
    • Also need to cover lifecycle management – can draw from radiology profiles for that policy.
    • Need cooperation with DICOM WG26 – so we need slide scanner vendors at the table – Roche will participate (Mario will find the people).
  • Next steps:
    • Complete transaction definitions
    • Plan for white paper


SET: (see File:PaLM SET F2F Cagliari.pdf)

  • Slide #2: Consider using v2 messages for SET transactions.
    • It may include orders, so could use OML^O33 (4.4.8) (specimen centric), or,
    • OML^O35 (4.4.10) (container centric), or,
    • OML^O39 (4.4.12) (Shipment centric).
    • Others may want to use shipment manifest messages OSM (7.18).
    • Or use notification message SSU from chapter 13 (13.3).
    • We may need to extend these to cover all our elements.
  • Does the re-identification use case include de-identification, so this is really change of identification of the specimen (re-identification is generic adding a new specimenID without explaining the purpose)? De-identification flag is required to know that the prior identifiers have been removed.
  • Make the specimenID and containerID required, so that they are ALWAYS available, and then have no elements for de-identification in the parent specimenID (or the placer specimenID). Add a paragraph explaining the relationship between these two attributes and how they are used across all the use cases of SET.



Roche is interested in participating. Mario to follow up with Roche.


Wrap up: (see File:PaLM meeting Cagliari2017 FM v2.pdf)

  • SET – reserve second hour of the monthly calls for standard selection and gap analysis in Dec and Jan
  • Choosing publication dates depends on when we want to review comments (often for a F2F) or when the profile needs to be available prior to a connectathon.
  • If we need to request base standard changes, aim for HL7 WGM in May 2018 in Cologne (if not completed on calls before then). V2.9.1 may be in ballot Sept 2018.
  • LCC:
    • Have a few edits since presented on Monday:
    • Include orders that are impossible to carry out (future orders that time out) with request to re-order.
    • Adjustment to the LOINC codes made in the table and examples.
    • Will send final version to Mary Jungers hopefully for November and make the public comment period till end of Jan 2018. Review on monthly call in Feb or March.
    • Publication for TI in June 2018 (or sooner), so it will be ready for 2019 Connectathons.
  • TMA:
    • Change request to base standard goal to have at WGM Jan 2018 and if still needed at WGM May 2018
    • Publication for TI in Sep 2018. Do we want another round of Public Comment if we have enough time between PC round and planned TI publication? This depends where HL7 publication is; use the approved change requests and include them in the publication and possibly adjust, if changes occur in 2.9.1 ballot.
  • APSR:
    • Request technical support from Art décor team.
    • Added pertinent insurance information section in art décor.
    • Created update organizer (indicate the sections where the changes happened and overall assessment of clinical importance of all the changes). If the diagnosis section has changed, that should be an alert, and if we identify that change as clinically significant, we can give guidance to alert the physician.
    • Schematrons are generated by art décor and sent to Gazelle team for IHE tool; we may need to help with writing the test cases.
    • Goal is to have available for all 2019 connectathons.
  • Digital Pathology:
    • White paper: would like to have more DICOM and stakeholder participation. Raj to draft, with Francois, Riki, and Francesca helping; Raj to share rough draft (layout, transactions, problems) to google group by Nov 25th. On Dec call, assign contributors and plan what future calls we will discuss digital pathology in the second hour, so that we can invite vendors. Will review white paper on January call in 1st hour; aim for publication in February 2019.
    • Need to check alignment between DICOM (122 = also in TI in APW) and HL7 Specimen DAM. Need gap analysis.
    • Most important profiles would be to work on:
      • Image acquisition and how to communicate the location of stored image;
      • Image retrieval and display in order to have work for the DICOM meeting in Helsinki May/June.
    • Some of the LDA transactions may be applicable so here we can reuse them to update LDA, since it needed some re-work as well.
    • Image retrieval process has a patent on it (Leica is vendor –they have resolved the patent issue and there has been positive feedback from other vendors, so that has been resolved; need to register with Leica).
  • PaLM TF CRs:
    • Need to write new CP for OBX-11/OBR-25/ORC-5 usage.
    • Have a gap in LAB-1 (Toon) – another CP is needed.
    • Need to reserve some time for CP review and balloting to publish release 9.0 in June.
  • Milestones: See picture on top of these minutes
    • Meeting in Helsinki focused on DP ONLY May 29 – Jun 1 – Raj, Megumi, Francesca, Francois; Mary to coordinate with DICOM WG26. We will fix dates on the Dec call.
    • Next F2F in Chicago June 18 – 20.