PaLM F2F Minutes 2017-May

From IHE Wiki
Jump to navigation Jump to search

IHE PaLM Face to Face Meeting, May 31 – June 2, 2017 Tokyo, Japan

Attendees

Name 31-May 1-Jun 2-Jun
Gunter Haroske x x
Ed Heierman x AM
Jim Harrison x
Mary Kennedy x x x
Riki Merrick x x x
Kenichi Takahashi x x x
François Macary x x x
Francesca Vanzo x x
Francesca Frexia x x x
Daniel Rutz x x x
Alessandro Sulis x x x
Mikael Wittel x
Jessica Poisson x x
Yoshitake Fujisaku x
Genichi Kato x
Raj Dash x x x
Nobuyuki Chiba x x x
Philip Mignon x x x
Akitoshi Suzuki x x x
Megumi Kondo x x x

Summary and Action Items (details follow in Minutes)

  • TMA – Have defined next steps for TMA (updated Vol 1 and started Vol 2.). Next steps determined.
  • LCC – Complete document to be reviewed. Next steps determined.
  • SET – Updated Vol 1. Next steps determined. We will have an update of volume 1 with a matrix of metadata and events and review it on the next 2 PaLM calls. Use cases defined.
  • APSR 2.0 – All of PaLM is to review the schema, wiki page and examples. (Links are included in the detailed minutes).
  • Digital Pathology – Raj will propose a first draft of a white paper that will have a marketing angle to recruit more engagement from vendors. All transactions for digital pathology will start with” DP” going forward. APW will be retired as it and broken into new pieces with “DP” something.
  • Structured Reporting –Raj is spearheading the white paper. We need more vendors engaged in this effort and an email should be sent to the appropriate vendors to encourage them to participate.
  • IHE Marketing – Contact marketing for IHE resources to improve vendor involvement (Suggestion to IHE International webpage / DCC) – change informational page on already involved vendors as well understand who to contact for vendor engagement as part of profile development and how to properly distribute the white papers -> action is to draft the table(s) on the wiki page (should not conflict, but compliment the product registry) and then present that to DCC (June 27, 2017) – Riki to add the topic to the DCC agenda wiki page.
  • SNOMED spreadsheet – Give to Domain Coordination Committee for June 27th DCC meeting. Request that other domains complete this spreadsheet with SCT concepts that are candidates to free IHE SCT ref set.
  • Proposal to DCC June 27th call - Request that the membership process includes a spreadsheet that vendors can complete that lists the domains they are interested in for their products. This spreadsheet will be posted to the PaLM webpage so that PaLM vendors can complete it.
  • Riki will add the instructions and the key to the SCT spreadsheet and put in the micro public health concepts.
  • Raj will request that Scott Campbell, Chair, SNOMED International pathology work group review the SCT list. (https://docs.google.com/spreadsheets/d/1rONueGvi6pxO6CKHpad90n7zEBya0Gxz2FSTQt5ILhY/edit#gid=0)
  • Next IHE PaLM F2F meeting is November 13-15 2017 in Sardinia.

Minutes - Wednesday, May 31 2017

Meeting objectives and agenda review Francois reviewed the agenda.

CPs for PaLM TF 7.1 final review, Supplement templates review (first pass) – François (see PaLM_meeting_Tokyo2017_FM_1st_pass.pptx)

  • Francois presented the status of the PaLM Profiles
    • LCSD should work well for both AP and CP.
    • LDA is now limited to pre-and post-analytical work – will that work for AP as well – stainers, cutters, embedders; Have another diagram that lists all profiles, but is missing the newer profiles – so need to update – may need to add some text in the TF to point that out more.
    • LCC should also be applicable to AP domain – make sure to add text to that respect.
  • Review of new diagram showing PaLM profiles and players
    • ARPH –review against Cancer reporting guide in US – they were the ones that originally developed this profile.
    • Would LCC need to connect to specimen collection facility? Not explicitly, though LCC can request new orders.
    • Lab work area – Lab workplace – is good.
    • Need to add bloodbank and digital pathology as player for the new profile starting at this meeting.
    • Blood product filler = blood bank.
    • Blood product testing = regular lab management.
    • Adverse event listener – receiver ONLY – may be independent of lab management or part of that.
    • The new diagram does not cover the relationships/dependencies to the other IHE profiles.
    • Also add sentence to explain the difference between lab management and lab work area, as folks are often not used to splitting that out.
    • Move public health so that lab management and lab work area are together.
  • Review of 2017 cycle publication schedule for PaLM:
  • White Papers
    • Blood products – for the larger picture. Dan is drafting a supplement for blood products adverse event tracking to be ready in fall 2017. This needs to be coordinated with new adverse event message development in HL7.
    • Structured reporting – for defining interoperability context exchange. Raj has draft options for the current status in IHE and for vendors’ future plans to catalyze the work. The work will be complete by end of 2017.

LAW and LTW discussion – Ed, Francois

  • LAW CPs
    • Ballot results:
  • #252 passed
  • #253 had negative comments.
    • #253 discussion: (from Dan and Riki):
  • Use of “” in PID-3 and PID-5.
  • Scope of PID segment use in LAW is different than use in upstream systems.
  • The analyzer provides patient info to the manager for the AWOS.
  • Use of “” in LAW Analyzer is not associating any patient name with the test.
  • However if you have information from the analyzer before receiving the OUL, then delete what you have now – BUT not if have this information in the dB from another source.
  • Does LAW cover analyzer sharing patient demographics and then updating them? Not really.
  • Order is entered at the analyzer and adds in some patient demographic that is available – example DOB, needed to determine age for reference range.
  • There was a long email chain about use of “”.
  • Include a footnote: “” is not intended to delete the data in the system for this message.
  • For each instance add a clarifying sentence specific to the instance where it is used.
  • For PID-5: The use of NULL (“”) should not be interpreted as a requirement to delete the patient name from the patient records maintained by the Analyzer Manger. = adjust accordingly for PID-3, SPM-4 etc.
  • In the first part of the text explaining the general NULL use behavior give some more background of the HL7 baggage / or at least make clear how it is used here by saying: The use of NULL (“”) sent by the Analyzer should not be interpreted as a requirement to delete information from data base records maintained by the Analyzer Manger.
  • Ed will adjust the CP accordingly – and send the updated and approved CP (François will publish on FTP server) with the minutes of this meeting. Ed will also update the Vol 2B.
  • LTW CPs
    • #254 – negative comment received:
  • Specimen Collector Information is captured in OBR-10 using XCN datatype, which is limited to persons.
  • The description of person, department or facility is pulled straight from the base – we many need to fix it there.
  • Since there is no real need to support department and facility remove that part and make the sentence grammatically correct.
  • Francois will upload the updated and approved CP to sFTP.
  • Francois will create the new CP identifying use of LDA and LCSD for use in AP domain.

Update on IHE PaLM around the World (Japan, NA, Europe)

  • IHE Japan updates (see Japan_Palm-IHE-J.pdf)
    • New Japanese Secretariats are Megumi and Kenichi; Naomi has retired as secretary.
    • In April 2017, a new IG has been published on the use of HL7 for POCT. It describes how each segment is used.
    • There is new IG guidance to exchange Test results from July 2016. The application codes send OBR-4 instead of OBX-3. The latter is permitted for backwards compatibility in Japan.
    • The next Japanese IHE Connectathon is scheduled for the week of September 25, 2017 in Asakusa. It will focus on using OBR-4 for application code sharing.
  • IHE NA Connectathon
  • US eDOS, LOI and LRI updates
    • LOI and LRI were balloted in May 2017
    • eDOS is ready for release; however EHRs are having a problem with implementation due to their own CPOE systems. The most complex part is reconciling individual tests to existing test orders. Reference labs don’t always know where the test was performed. FHIR may help with this: Patient has paper order, scan barcode, identify the ordering organization, query for the order and then have the order information exchange.
    • APHL is building a lab web portal for Public Health laboratories – first focusing on TB testing and Antimicrobial Resistance testing allowing submitters to log on and create an order – order will be sent using LOI to the testing lab – testing lab returns LRI to the portal (in first phase ONLY rendering the pdf in the portal, but in future will include discrete data for submitters to access / download (or submitters that can do HL7 messaging may be able to send LOI either directly to testing lab OR to the portal- that part is TBD).
    • Several states are implementing LOI and LRI in their Newborn Dried Bloodspot Screening (TX, WA, MI and VA ).
    • HL7 OO is working on building a catalog resource – the requirements for the lab catalog came from eDOS – France is looking to use FHIR for eDOS. The working group meets weekly on Wednesdays from 1 -2 PM EST. (https://global.gotomeeting.com/join/442585925 for both web and audio). If interested in participating, subscribe to the catalog listserve : http://www.hl7.org/myhl7/managelistservs.cfm?ref=nav (under orders and observations =ordercatalog@lists.hl7.org)
    • eDOS can support helping the provider order better tests aligned with health system policy / patient condition etc. from the lab side to give the provider organization the choice what to decide to allow order choices.

SNOMED CT free subset for IHE International, submission (first pass) – Raj/Francois

  • SNOMED CT free reference set for IHE International
    • An agreement between the two organizations is in development. It will allow the use of specified SCT that are in IHE profiles for IHE members to use who do not have a SNOMED CT license from SNOMED International.
    • Francois created an initial spreadsheet that can be expanded to other IHE domains via the Domain Coordination Committee.
    • An enhanced spreadsheet was developed and concepts were prioritized. SNOMED requests a list and description of the profiles in which we are requesting SCT codes; as well as synonyms (descriptions) of the requested concepts. The spreadsheet will also include the value sets the concepts belong to.
    • A previous spreadsheet from Chris Carr was merged into the PaLM spreadsheet (https://docs.google.com/spreadsheets/d/1ykM6SlBPAIDFYggnwtoUDPXWqyBbvdXtUxN-_KngGYo/edit?usp=sharing).
    • To date, PaLM has around 2000 concepts to request. For concepts not yet in SCT, there are approximately 100 concepts we will request). SCT has recommended that in the MOU we can increase the number of concepts by 10% over the next 5 years.
    • The earliest we can obtain the codes to use is January 2018.
    • The ref set is to help non-member countries to understand the importance of SCT for interoperability purposes and encourage migration to SCT.
    • Other IHE domains interested in submitting concepts are cardiology, patient care coordination, eye care and QRPH.
    • A number of concepts in France, Germany, Austria, Japan and China (about 6000 concepts of the most commonly used terms in SCT member countries) have been translated) see:  https://refset.ihtsdotools.org/#/directory.
    • A priority review was developed for PaLM concepts using these fields:
  • Where a concept is used in the profile – data element (DE).
  • Field usage – DE usage: Required/RE/Optional.
  • Is the value set (VS) binding strength: required/recommended/future.
  • Prevalence: high/low.
  • Overall priority, where 1=highest; 2=medium; 3=low.
    • It was agreed that micro-organisms should also be added with an aim of 100 or so. Riki will create the RCMT list as a starter set.
    • It was agreed to add the four blood groups – Riki and/or Francois will add these.
    • Specimen processing and specimen collection will be split into 2 value sets – Riki will do this.
    • Commonly used stains should also be incorporated – Raj and Riki will work on this.
    • For micro in vol 2x, OBX-5 should use the concept ID in the first component and “SCT” in the third component.

SET supplement review (1st pass) - Alessandro (see SET_F2F_Tokio_1st_pass.pptx)

  • SET discussion (first pass)
    • The use case matrix will be added to the event list in Vol 1.
    • Aliquoting is mainly used in clinical labs, not AP. In AP, the derived specimen is tracked, not the aliquoting/splitting.
    • There is a need to distinguish between inter-laboratory and intra-laboratory events.
    • Specimen processing start and end don’t need to exist because of a date/time stamp.
    • Keep Specimen sent to and Specimen leaving – might be manual and not on an automation line.
    • Change laboratory device to laboratory location (lab work area – which can be a device, a human at the bench, etc.).
    • Change specimen discharged to specimen discarded.
    • For use case #2, change organization with institution.
    • For use case #3, just call it intra laboratory specimen tracking; don’t need IVD
    • Need a definition for shipping; transfer between institutions.
    • Change: “specimen left laboratory device” to “specimen left location.”
    • Change: “specimen arrived at laboratory device” to “specimen arrived at location.”
    • Remove: specimen sent for testing, specimens shipped, specimen received.
    • Remove query and clinical annotations as they are outside of the scope.
    • Alessandro will make the changes for review tomorrow.


Digital pathology discussion (1st pass) - Raj, Mikael (see DigPath,APW_WSI, the LIS, and the EHR.pptx)

  • Digital Pathology, DICOM, and next version of APW (first pass)
    • Mikael Wittel discussed the possibility of incorporating DICOM profiles into PaLM profiles; we will have to split APW.
    • Leica has put up an agreement between Leica and vendors for used of DICOM supplement 145 whole slide imaging. This paves the way for vendors to now implement this profile. There was a suggestion that Leica give up the patent to DICOM. All other patents in DICOM are free to use without having to register with a particular vendor.
    • DICOM WG 26 is preparing a connectathon to involve the clinical vendors as no one has seen the supplement implemented.
    • DICOM is working on: a proposal for use cases and workflows (3); pre-populate lists as needed. Mikael stated that when you scan a glass slide with the tiling of the layers, each layer has to have metadata. This will be a proposal for a CP since viewers need to know how many glass slides are in a study. You can think of supplement 122 as the specimen description and supplement 145 is the whole slide representation. Raj mentioned that annotation is important to all workflows and there needs to be a way to link the annotations and the images and drive the workflow.
    • Raj discussed the ways to leverage radiology transactions that exist in PaLM profiles like APW.
    • The EHR focuses on the integrated care of a single patient; AP LIS focuses on the production, storage and conveyance of the diagnostic interpretation of stained tissue; AP LIS becoming part of large EHR systems; whole slide imaging has the potential to reinvent the processes in the AP LIS. We can work with DICOM and WSI to do more than just focus on glass slides.
    • A holistic digital pathology solution must accommodate WSI management as well as other digital assets (gross imaging; etc.).
    • Need to create a Digital APW. Raj outlined the workflow steps for the next version of APW that includes digital pathology solutions, PACS, LIS and the EHR. This could be a new profile with new transactions. We need to match the use cases with these players and speak to how vendor systems fit together.

Workflow Steps IHE PalM.png

  • Image key:
  • VNA = vendor neutral archives = storage platform for accessing.
  • DPS = digital pathology solution (image acquisition and management).
    • Profile(s) need to include:
  • Tracking on which slide/image is viewed and by whom; for how long; and with what filters used.
  • Images of the specimen: from ultrasound, specimen radiograph, glass slide, WSI, gross specimen image, etc.
  • Annotations with coordinates on the image. This also includes a legend for ink color on the annotated gross finding and its link to the micro findings.
  • Patient ID but the ability to de-identify if needed.
    • A digital pathology business case should be developed.
    • Need to define uses cases and the metadata that is needed for the transactions (i.e., we need to decide what part of DICOM should be in the PaLM profiles).
    • Medical information, system data, event data, etc. extract from PACS and VNA. These need to move to the center of the diagram.
    • Need to decide where to store the information needed to tie all these together into a workflow. Suggested it be the VNA since it has a larger storage capacity than PACS. Today, the LIS cannot communicate with the VNA for the metadata.
    • No one has implemented APW at this time because all transaction have to be implemented in the profile. The goal should be to build small building blocks between two actors only, since most vendors focus on individual parts.
    • In reality, there are variations to the standard case presented in the image. Need to define variation to the normal flow and this needs to be dynamic.
    • Need to determine how to add staining and fixation quality in the transactions.
    • Multiple profiles can be built from the revised APW. Diagram suggests the need for some specific profiles, for example:
  • EHR to LIS transaction = HL7 messages. This could be the same as what is in the current LTW.
  • Transactions between VNA and DPS (could include DICOM supplement for WSI and light microscopes and jpegs) plus something to cover the gross image (maybe XDS).
    • Need to create an overarching specification for all the transactions and actors and identify use cases and requirements for each of them.
    • Discussion on how to get more vendors involved. There will be a DICOM connectathon as part of RSNA in San Diego in October. (Participants may include Sectra, Philips, Roche, Hatmachi, Leica – sp?). WG 26 will create three use cases depending on who participates ranging from simple to complex).
  • Next steps:
    • Document each use case.
    • Define requirements for each use case.
    • Link the use cases to the images.
    • Decide which profiles need to be created.
    • Engage vendor involvement.

Thursday, June 1, 2017

Transfusion Medicine Project Review (1st pass) - Dan, Filip (see IHE_BloodProductProfilesProposal.pptx and IHE_Suppl_TMA_2017-05-20_1st_pass.docx)

  • Considered outside of scope :
    • donating blood and testing for blood type etc. for transporting.
    • requesting blood products from blood bank (usually using LAB-1 can be used here – HL7 has blood product specific order message (see Chapter 4) and compatibility testing.
    • matching a patient to a blood product.
  • Starting point of transfusion is critical for patient safety – need to verify blood product status just prior to transfusion to ensure no changes happened since blood product was assigned to the patient.
  • Need to decide on the starting point for the profile = at what point do OTHER actors need to know about this?
  • Need to record who approved the transfusion AND who started the transfusion (this goes along with billing info, too).
  • Check on data elements in Haemonetics messages – will need to see, if we can share, so we can reuse.
  • Questions:
    • This scope now sounds a little larger than what was in the original proposal which was to cover ALL workflow? It was decided to break it down into three different profiles:
      • Initial order and pre-transfusion workup.
      • Ordering and dispensing of assigned blood product.
      • Transfusion and reaction management.
  • Include the summary of the workflow for context in the profile document and what scope we are covering with it; for now 6 – 12 o’clock in diagram.

Vein 2 Vein IHE Palm.png

  • May add profile for stock management or include this in the order and dispense for the assigned blood product.
  • Academic centers can have two workflows: one for creation of new products AND the administration of blood products.
  • Inventory management requires interfacing with the donor system – there are some of those set up with collection facilities. It was decided to hold off on working on that for now as it may confuse issues.
  • Raj said to consider handling of units identified as radiated (but is handled pretty well by blood bank LIS).
  • How do we reach out to other vendors (EPIC has reached out to their vendor contacts, specifically the blood bank (Haemonetics, Sunquest, Cerner and some others) but have not yet shared the draft document. Will wait to share with them until it is more scoped out.
  • Included contact with outside system? NOT yet – focus ONLY on flow in patient care, but may come up to the line dealing with inventory (example fridges in ER or surgery for immediate access to product) for the middle profile for consideration.
  • Dan shared TMA profile = Transfuse units – this needs to be added in the remarks on transfused blood products - may be use a different diagram in the document.
  • Middle profile = “assign units” to “collect units” in the diagram.
  • TMA document has breadcrumbs to link to the family of profiles for the entire workflow.
  • Naming of profile:
    • Transfusion Medicine – Administration / or Blood product coordination = use TMA.
  • Do we need a definition for blood products? Do we exclude medications that include blood products? The same process applies to plasma and factor derivatives though some facilities use it out of Pharmacy. Where is the line to IHE Rx domain and this profile? This needs to be clearly articulated. Dan will add these as open issues/questions: Does Pharmacy already have profile? We have not seen inpatient dispense of pharmacy, but Dan will check with them (IHE HMW profile – covers in the hospital – not used in any country, only tested once at a connectathon – this information needs to be verified).
  • Open issue #2 – should LAB-76 be optional or required? We need input from the vendors – per Jessica this should be required.
  • Appendix A is cross domain – so not part of the profile – see: http://ihe.net/TF_Intro_Appendices.aspx
  • Appendix A:
    • We need to simplify the definitions currently in the Appendix part – this is for the big picture, but can use some of the text in other parts of the profile and make it clear what this actor does in a particular profile.
    • There is value to having explanatory text in the profile, rather than in a separate whitepaper – Dan will take some of Francois’s comments and incorporate them into the explanatory text.
  • Appendix B:
    • Transaction numbering can be adjusted – Francois will check on that and provide other numbers, if needed.
    • BTS message to use for Transfusion Admin status (for a specific unit) – ONLY the status code changes.
  • We will need a new HL7 message for reaction reporting.
  • What about positive patient ID and transfusion testing documentation? That could happen in the transfusion admin system for some systems, but do we need to add optional transaction for when that is NOT the case? This is an example for future “plug and play” of other actors.
  • We do need an actor so that product and patient are appropriately associated; it may be stand-alone OR part of administration actor? Mark this as an open issue (right now this is a human – so if we don’t have device NOW, don’t create it now).
  • Scan bracelet of patient and scan blood product – then verify that the two IDs are correctly matched.
  • Blood product filler is doing the verification in this profile – will that work well?
  • May need to create a profile to identify which actor is handling the patient verification (Filip likes using the blood product filler for that verification step, so that any changes to the blood product status are available to them immediately).
  • The positive patient ID MUST be at the bedside right before administration.
  • The difference between the documentation and the administration step is that the documenter is the EMR while the administrator is an actual person.
  • Create a distinct profile to support the verification Query to the blood product filler – this is architecture specific – make it an optional transaction in this profile (might need to define what transaction to use – review HL7 messages for candidates).
  • In emergency situations the time of issue of the unit from the refrigerator in the ER – grabbing 2 units O neg blood – enter patient ID and that’s when the product ID is assigned and verified that unit is OK for that patient.
  • We need to take a closer look – issue to patient with confirmed compatibility (or non-compatibility from the blood bank). That is as far as the profile can go. We should probably not include alert in profile.
  • Make positive patient ID – where it occurs, and whether to include it as an optional transaction - an open issue.
  • Adverse Event Consumer = incident reporting system in EHR systems. In MIPS: the blood product filler creates an email to a person to follow up, so a functional requirement, but not interaction? Dan will do more follow up with examples, or will remove this.
  • This may be related to compliance administrator usage that are separate from EHR-S and SRS (not sure those are connected to EHR-S or LIS right now – vs in the future). Transfusion reactions are double reported in EHR-S (narrative either as consult note or anatomic pathology report) and blood bank system (structured with room for narrative).
  • HL7 defines reaction as single field to a single unit, but in the record it is normally only at the encounter level. We want to move the reaction up to that level, rather than only at the specified unit level – (and add more metadata)– in NL the reaction is specific to the blood product – then they have to research if related to patient or to the product (for example during transport incorrect temperature). It must be for single product, even if more than one unit used although one could report on both, if unclear which caused it.
  • Actor options – none now, but may be positive patient ID transaction in future.
  • In “TMA overview” Dan will add more of the context here – per Francois’ comments – THIS IS ONLY for the profile including boundary definitions.
  • For the larger picture we will need to go in the first chapter: introduction to this supplement to give the global landscape.
  • In NL and Belgium there is legal requirement to take vitals 15 min after transfusion start to the blood product filler – optional transaction.
  • Reaction reporting can be after completed OR after interrupted (due to reaction or for other reasons) – in all cases the transfusion will be stopped.
  • Maybe several use cases:
    • Transfusion, no reaction.
    • Transfusion reaction interrupts transfusion.
    • Transfusion reaction AFTER transfusion complete.
  • Will use current draft for review tomorrow

Digital Pathology Recap and Next Steps – Raj (see previous slides)

  • There is no adoption of the DICOM format as described in DICOM supplement 145 – due to the LEICA patent issues. However, there is now a resolution in sight.
  • Agreed that may be five separate profiles in the diagram shown by Raj from the previous day.
  • For the proposed QA use case, there is overlap with the SET profile for the slides received/scanning starting/scanning completed so this use case is removed.
  • Next steps include engaging more vendors and building smaller transaction profiles.
  • VNA and PACS may need to be split out, since the functions are different – may need something like the analyzer manager in LAW to coordinate the disparate DPS.
  • Gross imaging and WSI needs to be split out also since each DPS is specialized. The transactions are very different for gross image vs WSI etc., so may need to create to different profiles. Need to review the metadata needed around the different image types and may be able to harmonize: viewed, annotated, location type, linkage.
  • Will a profile handle ultrasound, derma ex-vivo microscopy; in-vivo microscopy – similar to the images in the colonoscopy? Needs to be determined.
  • Gunter’s email points out that there is work going on that may complicate who drives the workflow – the scanner or the LIS?
  • Micro is also digitalizing the picture of the culture plates and these scanners are driving the workflow on that part of the workflow.
  • There are roles that can be played by different systems which leads to the rationale of creating small complimentary profiles for transactions between two actors only.
  • Should there be connection between different DPS, or should ALL transactions go through the imaging manager (same as analyzer manager in LAW. There is a need to if that can be copied for the ordering of the work LAW might be sufficient, BUT for the “results” back will need to handle more
  • Agreed to change the final image on slide:
    • EHR to “order placer” and “result tracker” – or make two boxes.
    • LIS to “order filler” and add “image workflow manager” box.
    • PACS/VNA split into “image repository” and “image viewer”.
    • DPS split into “Macro imager” and “WSI scanner) and “Endoscopy” and “ultrasound” and “specimen radiographs” into “image acquisition device”. (Depending on the needed metadata, can use one or multiple profiles).
  • All DPS must support:
    • Linkages to patient/encounter/container/derived specimen/image (linkage is always from child to parent). These are all assets.
    • Annotations.
  • Out of scope:
    • Microarray/TMA where a slide has sections from multiple patients. This is only used in research and for development of new lab tests. This is something to consider for later.
  • Vendor input:
    • Raj to write request email explaining the value of the IHE for profile development to recruit volunteers for profile development.
    • Mary to send to vendors.
    • Ask IHE endoscopy domain for names of vendors.
  • Vendor spreadsheet: might be good to create a list of all vendors in PaLM and identify which are IHE members. Also include in the spreadsheet a column where vendors can identify their interests in different domains/profiles.
  • Next steps regarding vendors:
    • Reach out to IHE marketing committee to get advice on the best way to reach out to specific vendor communities.
    • Raj to lead the development of a white paper with a summary of the use cases, the identified actor roles. He will also create an email request soliciting interesting parties to join the profile development.

Structured Reporting and data element repository white paper – Raj (See PaLM Structured Reporting v2 IHE Mtg May 2016_2017 update.pptx)

  • No real change to these slides from May last year.
  • Focus should be interoperability of structured content rather than the actual content of these transactions.
  • Raj reviewed the existing platforms in IHE including Structured Data Capture (SDC).
  • Currently working on APSR 2.0. This has become an extensible model thanks to Gunter and Francois.
  • In terms of Art Décor, there is a possible limitation in the development of content in this tool to federate the creation of templated content.
  • There is a learning curve to use Art Décor. It would be good to have vendors to implement templates in their solutions producing the reports = that will create the example content.
  • Raj reviewed existing data element registries, Art Décor, caDSR = curated data element registry supported by NCI.
  • Next Steps on white paper:
    • Publish White paper in December – including Art Décor use in support of APSR 2.0 after its publication in September.
    • Cover the current APSR work in the IHE webinar.
    • Will consider submission of the white paper to an international journal – possibly JAMIA?
  • Germany is working on a new controlled vocabulary headed by Federation of German Pathologist – using Art Décor and collaborated effort.
  • Gunter will write up his experience with Art Décor – benefit / challenges / improvement suggestions / support for federated content development.
  • Need to decide on the level of moderation for using Art Décor for this:
    • Should there be access only or also access and content – may be of benefit to develop an ontology first that can then be imported into art décor, as there is no content moderation in Art décor at the moment.
  • In Art décor we need:
    • Structured templates for a domain – example XD-Lab and APSR.
    • Content for the templates for the domains – lung cancer vs gyn cancers vs gastrointestinal cancers
  • Use the WHO content as the basis for the terminology to use.
  • NEED to find a group that maps and harmonizes the WHO content to terminologies – need organization to define the interoperability – example could apply the rules from the CAP eCCs to the APSR template.
  • APSR 2.0 does NOT include the specific value set, but it does bind to the code system level.
  • Feedback from vendors is that they will use CDA, if they are provided the content to use in conjunction with the structure of the CDA.
  • APRS 2.0 right now supports ALL the structured data for all templates and the narrative section – but does not require the derivation of the narrative section from the structured part of the APSR (and it does NOT have to cover all of the data in the structured section).[RM1]

SNOMED CT free subset for IHE International (2nd pass) - Francois/Riki

  • Francois filled in more columns for AB+Rh factor value set to give examples for values and completed the ABO only value set.
  • Not needed for APSR 2.0.
  • No need to add value set for RH factor, since that is covered by Qualitative lab results value set
  • Looking into APSR value sets:
    • SpecimenCollectionAndProcessing – do not split out, because it goes into the same location in the APSR = Procedure code in ProcedureStep section.
  • Need to prioritize the less commonly used stains.
  • Riki will add organisms – as highest priority one organism for each reportable conditions plus a few more for the most commonly reported variations of organisms.

SET supplement review (2nd pass) - Alessandro (see SET_Tokio_2017_2nd_pass.pptx)

  • Metadata for ALL events:
    • Only support one of these: specimenContainerID or specimenID. There are situations where you have one specimen that gets distributed across multiple containers.
  • Real world examples given:
    • Create the specimenID based on the derived path it took to get to = caseID+TissueID+cintainerID+blockID+levelID+slideID.
    • New numbers will be needed for each specimen with reference to the parentID.
    • Some PaLM profiles require both specimenID and ContainerID.
    • Both specimenID and containerID are materialized on the container.
    • In most cases, only the specimenID will be used but at times both will be needed.
    • Clarify the use for containerID as it may be empty.
    • Add eventID.
  • Should there be a column for usage of each element? specimenID is R.
  • Should remove sending and receiving elements from the common list? No, this is for the MESSAGE, not the movement of the specimen; leave in.
  • For Specimen Collection event elements, add:
    • Source site.
    • Laterality.
    • Condition.
    • Rename type to specimen type.
    • Drop collection duration.
    • For all these elements, add description and usage, cardinality and potentially include the mapping to the model.
  • For specimen archived, drop original measurement.
  • Should measurement be changed to volume?
  • Overall, we need to review how many of these elements are important for event tracking (chain of custody and location) vs overall information about the specimen at the time of the event.
  • Timestamp should be in the header. This is for sending the message.
  • Next steps: create the new matrix layout and will review in technical hour of the next PaLM call.

APSR 2.0 Review - Gunter, François (See and APSR_20_20170601_Gunter.pptx)

  • Gunter requests all review the content modules, specifically for cardinality and for the wiki content.
  • Appended = additional information to answer specific question on the previously issued final report.
  • Delta highlighting for amended report; in AP world we only need this (same as corrected – in clinical Lab changes to results are called corrected, changes to interpretation because changes in demographics are called amended there) = close this issue.
  • Gunter is still waiting on LOINC codes.
  • Will handle reflex testing by using appended reports in APSR – applies only to Pap smear (HPV testing reflex).
  • The cancer checklist content can be incorporated in APSR.
  • Do we need to make these IDs mandatory, because they are mandatory in APW – no need to harmonize with APW? – propose them as required in the public comment version.
  • No activity on the style guide for rendering the APSR.
  • Status codes are required in the base CDA – so we cannot change it.
  • Add a rule to schematron to check for the status codes of the document – vs status codes in observations and other sections.
  • Gunter will share the second example of the breast excision example. It will not include the procedure steps, since they are the same as in the other example. May need to add introductory sentence AND include inline as <COMMENTS>.
  • The OID conflicts between APSR and XD-Lab have been resolved – last version is #12
  • APSR is ready for publication once the IHE documentation is finished that sets up the conversion from Art Décor into IHE documents.
  • Next steps:
    • All review APSR documents and examples:
  • ART-DÉCOR: http://art-decor.org/decor/services/RetrieveTemplate?prefix=psr-&version=&language=en-US&id=1.3.6.1.4.1.19376.1.8.1.1.1&effectiveDate=2014-05-13T11:57:57&format=html&collapsable=true
  • Mediawiki: http://wiki.hl7.de/index.php?title=IG:Pathologiebefund
    • Francois will transfer the OID excel spreadsheet to a Google document and ensure only a few will have editing rights (i.e., Francois and Gunter).

Friday, June 2, 2017

Transfusion Medicine Project Review (2nd pass) - Dan, Filip (See IHE_Suppl_TMA_2017-05-20_fm_2nd_pass.docx)

  • Reviewed the edited Transfusion Medicine document.
  • Review of the diagram:
    • For “no reaction” is a separate diagram needed?
    • Begin transfusion of unit and create a diagram for event with multiple units being transfused; and also add note in text above that there is a start and end date/time for each unit.
    • In an emergency department situation, would more than one unit be hung at a time? There could be 4 units put into a Belmont infuser. Thus, the start would be in a series, since each has to be scanned one at a time but the end would be single. In real time the start time is almost the same, but for each unit the start and end time is recorded.
    • For the joint transfusion how do you document the reaction? Per Filip, a reason must be given for each blood bag, so may need to report reaction on ALL units when the event occurred. Duke also records all units that are related to the event. That difference needs to be clarified in the text.
  • Do we need to promote IUA (internet user authorization) vs XUA profile (cross enterprise user authentication using SAML) – in QRPH profiles we use IUA – Dan will do some research.
  • Filip’s system uses SAML authentication, since the transaction goes outside of lab.
  • Cross profile considerations – In the future for the larger context we may want to list LAB-1 for the order here. Should we list future development profiles here? When we build the other profiles we will use a CP to update this section. Can make this an open issue that this section is expected to update, when the additional content is created.
  • Should we leave all profiles in trial implementation until they are all well exercised and then add them into the TF together, or add them one at a time? The TF integration depends on the amount of testing and implementation for each of the profiles. A decision will be made based on connectathon results and CP requests. Dan would prefer to move only the entire set to preserve the context .
  • Dan will provide updated version on Vol 1 for the next PaLM call.
  • For Vol 2:
    • Need to write up the CRs for HL7 to add a new segment and new message structure – this still needs more research. We also need to review if we need a general adverse event message. This would be of interest for other WGs (PC, Rx, PHER).
    • New segment to indicate beginning and end of the reaction is needed.
    • REL segment will indicate the unit(s) involved or the encounter.
  • Positive patient ID query to the filler system also needs to be researched. This may require a new message structure using existing segments. The question to be answered would be: I have this patient matched to this/these units – is that ok? The answers of yes, no, no information available will be included. Are there other answers?
  • We may be able to reuse existing base query message (QBP^RSP) like we did in LBL, LAW, LDA – Dan will review those.
  • There is a FHIR resource for adverse event: http://hl7.org/fhir/adverseevent.html.

LCC supplement review - Riki & Jim (See LCC transaction flow.pptx)

  • Jim presented slides for the LAB-6 transaction needs:
    • ORC-25 – allows more info on what should happen in regards to the ORC-5 status code – for example what happens, when the time on the hold expires – need to add more description about this field and how it is being used.
  • [post meeting note: The field actually just states, if the status expires on event or on timing, not what happens when it expires.]
    • There is an issue with the parent orderIDs for reflex testing. This may need to be reviewed in HL7 O&O base standard = OBR-29/ORC-8/OBR-54.
    • Is there a way to tell if the replacement recommendation was done by human or machine (CDS)? Whose recommendation it is may affect if the placer accepts the replacement recommendation – can include NTE segment after the OBR that can convey all the information.
    • ORC-16 is codeable. This is user defined – no HL7 table assigned here, so can be defined by the organizations and agreed to by partners.
    • What about multiple suggested replacement codes? Agreed that this is not covered under this use case. It does, however, cover when more than one test is ordered and replacements are sent for each. They can be accepted or rejected for each as needed.
  • GAO profile covers a lot of the functionality – list this as related profile and explain the boundaries between the two profiles – Jim will look at that that profile: https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_Suppl_GAO.pdf. This is intended to work during the ordering process to an external knowledge recommendation – does this queue up the recommended orders in the system (it lists the LOINC and can be accepted by ordering doc – need to review for overlap and resolution).
  • Riki will check why CR-855 is listed as an open issue and send Jim the answer.
  • Remove the tentative use case #9 in LAB-6.
  • For the security section, will explain that we are extending LTW so the two are the same.
  • ORC-16: Make C(RE/O) with CP: If MSH-21 is valued “LAB-6”.
  • ORC-25: Need to update to the OO CR related to it and the harmonization proposal.
  • Make C(RE/X) with CP: If ORC-1 is valued “HR” – or make this dependent on ORC-36 being valued? May have partner agreement to do this external of the message – both are conditional on HR in ORC-1
  • Expected Actions describes what the receiving system has to do when it receives this message, including suggestions on how to display this information etc. Jim will copy from the wiki and expand this.(http://wiki.ihe.net/index.php/LCC_Long_Proposal_-_wiki#Result_Fulfillment.2FFollowup_.28LAB-7.29)
  • Audit – see what we did in LAB-1 in LTW
  • LAB-7:
    • missing LAB-7 diagram? – Riki to add
    • New REL-field number = 17 and 18 per CR-855- that needs to go through PC – Riki to follow up
  • Jim will update comments and share, then Riki to complete her edits and send back to Jim, so that he can add the expected action sections.
  • The harmonization proposal is to be submitted for the July cycle – initial draft due 6/17 midnight EST – Riki to submit.

Wrap-up, assignments, milestones - Raj, Riki, Yoshimi, François (See PaLM-meeting_Tokyo2017_FM_2nd_pass.pptx)

  • In September, we will publish an additional white paper on Digital Pathology along with APSR 20 publication (see below for publication cycle).

2017 cycle publication IHE PaLM.png

  • We also want to identify the vendors that are participating in each project.
  • We will also suggest creation of a registry of vendors and the domains they are interested in – or maybe a web page of all the member engagement in IHE. We need to reach out to the marketing group at IHE International and will bring it up to the DCC. We can model it on the PaLM domain wiki – Raj will draft a table layout.
  • Have a product registry, where the vendors can register which profile each product has implemented (integration statement) – vendor provided information.
  • Also have the connectathon results for all profiles, where you can see, who participated in testing.
  • Next F2F meeting place and dates: Cagliari, Sardinia, Italy, November 13-15. There are 7-8 flights from Rome or Milan by Alitalia to Sardinia.
  • At the next F2F, the goal is to review comments on the supplements that will be published for public comment in September (APSR 2.0, TMA, LCC).
  • For SET we need at least 2 more calls to finalize Vol 1 and then need to create Vol 2; so this may not make the September deadline. We will work on Vol 2 at the next F2F.
  • Next publication is PaLM TF – for June 12, 2017 – Francois almost ready.
  • Review CP-255: to add explicit statement that LDA and LCSD also covers AP domain
  • There was a motion to accept CP as presented: Mary Kennedy, Dan Rutz, against: 0, abstain:0, in favor: unanimously.
  • Francois will update to STP server.
  • The PaLM profiles and players slide has been updated by Francois:

PaLM Profiles and Players IHE PaLM.png

  • Reviewed Action items:
    • TMA – have defined next steps for TMA (updated Vol 1 and start of Vol 2), LCC (complete document for review), SET (Updated Vol 1), APRS: ALL NEED TO REVEW the schema, the wiki page and the examples!!!!
    • For Digital Pathology (DP) start all the profile acronyms with DP to indicate that they all belong together – will start with the order placer and order filler, since all the transactions are already defined in LTW.
    • White paper for DP – with marketing angle to get more involvement from vendors
    • White paper on structured reporting to get more awareness and help with developing tooling to create domain specific content.
    • Contact marketing for IHE resources to improve vendor involvement (Suggestion to IHE International webpage / DCC) – change informational page on already involved vendors as well understand who to contact for vendor engagement as part of profile development and how to properly distribute the white papers -> action is to draft the table(s) on the wiki page (should not conflict, but compliment the product registry) and then present that to DCC (June 27, 2017) – Riki to add the topic to the DCC agenda wiki pag
    • SNOMED CT free ref set at: https://docs.google.com/spreadsheets/d/1rONueGvi6pxO6CKHpad90n7zEBya0Gxz2FSTQt5ILhY/edit#gid=0. We need to write descriptions for each of the column headings and what kind of data is expected in the columns as additional sheet in the file – Riki to add – also include a separate sheet with DOMAIN – PROFILE – PROFILE description (1 sentence description) and link it to the profile summary. The Priority column will be used to sort the concepts, if we are limited by SNOMED International to a certain number and have to prioritize. The Comment column can include links to value set source, if applicable or other context). This spreadsheet is for existing concepts and describes new concepts that might be needed to round out a value set. Scott Campbell at Nebraska Medical Center could review and help with prioritization of content (Raj to ask Scott). Riki will add the organisms.
    • APSR is ready for publication once the IHE documentation folks finish setting up the conversion from Art Décor into IHE documents
  • Francois reviewed publication schedule:
    • Confirmed that LCC, TMA and APSR 2 are in good shape for publication on schedule: September 2017.
    • SET might need an additional semester and in that case could be issued on S1 2018.
    • On the other hand, we will have two white papers instead of one, and we will request to publish the Structured reporting one synchronously with APSR 2.
  • Francois reviewed tasks for the November meeting in Cagliari (Sardinia):
    • Reconciliation of comments received on the “public comment” supplements (TMA, APSR 2, LCC? …)
    • Review and refinement of volume 2 of SET (in case it was not published in September)
    • Review of volume 1 of the first DP* profile(s).

[RM1]Francois / Gunter – I thought that was a requirement of CDA that structured content is represented in human readable form? 16

Retrieved from "http://wiki.ihe.net/index.php?title=PaLM_F2F_Minutes_2017-May&oldid=103121"