PaLM Conf Minutes 2018-Jun-18-20
Back to IHE Pathology and Laboratory Medicine (PaLM) Domain
Back to IHE Pathology and Laboratory Medicine (PaLM)Technical Committee Page
Documents
Presentations from the face-to-face meeting are available at https://drive.google.com/open?id=1Ta_k1TmdRE3FB6J9zkwSs-4tT13DEkiC
Attendees
| 6/18 AM | 6/18/PM | 6/19 AM | 6/19/PM | 6/20 AM | 6/20/PM | |
|---|---|---|---|---|---|---|
| Francois Macary | x | x | x | x | x | x |
| Riki Merrick | x | x | x | x | x | |
| Raj Dash | x | x | x | x | x | x |
| Kenichi Takahashi | x | x | x | x | x | x |
| Genichi Kato | x | x | x | x | x | x |
| Filip Migom | x | x | x | x | x | x |
| Jim Harrison | x | x | x | x | x | x |
| JD Nolen | x | x | x | x | x | x |
| Mary Kennedy | x | x | x | x | x | x |
| Sabrina Krejeci | x | x | x | x | x | x |
| Gunter Haroke | x | x | ||||
| Alesandro Sulis | x | x | x | x | x | x |
| Francesca Frexia | x | x | x | |||
| Nicholas Jones | x | x | ||||
| Dan Rutz | x | x | x | x | x | |
| Venkat Muruganandam | x | x | x | x | x | |
| Marc Madore | x | x | x | x | x | |
| Doug Murphy | x | x | ||||
| Jeffrey Karp | x | |||||
| Eric Daley | x | |||||
| Sam Spencer | x | |||||
| Varsha Parekh | x | |||||
| Ed Heierman | x | |||||
| George Fiedler | x |
Minutes
PRESENTATIONS LISTED BELOW IN ITALIC'S ARE LOCATED ON THE GOOGLE DRIVE FOLDER LISTED ABOVE UNDER "DOCUMENTS"
June 18, 2018
Introductions were given and the agenda for the meeting was reviewed by Francois.
Publication of new release 9.0 of PaLM TF:
Francois presented Volumes 1 and 2a, 2b,2c, 2x (contains common specifications to most profiles) and the CPs integrated into this new release.
APSR updates:
The Trial Implementation version in preparation is here: http://pubswiki.ihe.net/index.php/APSR For the past two months François, Gunter, Riki and JD conducted a harmonization process between APSR 2.0 and the HL7 BRIDG model to be out for ballot in September. This process allowed to correct some issues and bring a few refinements to the APSR 2 specification. As a consequence it will be released for Trial Implementation as APSR 2.1. – it will be the first IHE profile produced without the conventional word processing (Office). The formal machine-processable specification is maintained within ART-DÉCOR, and it is then complemented with additional text within the new IHE mediawiki server pubswiki.ihe.net created for that purpose. The pdf format is generated from pubswiki. APSR 2.1 is meant to apply to any structured report in anatomic or cytologic pathology that is CDA-based.
The APSR overview resulted in simplification of the representation of the problem organizer and the procedure step. The XML representation of examples show that better now. The question was asked on how can we capture additional information about temperature of the processing step = do we need to add additional entries to the procedure step – No – is there a need to use the clinical lab observation in the problem organizer? It was recommended to maybe submit a comment to include observation in the procedure step.
HL7 SD is working with the CDC on Healthcare Associated Infection reporting using C-CDA – we need to follow up with them why they did not want to use XD-Lab. Riki will follow up with them.
APSR 1.0 had no implementers to date. MIPS is currently looking at it but has no concrete plan. In Europe a lot of the countries already have some solution for cancer registry reporting – similar to clinical chemistry reporting. An issue is with the receiving applications more so than the sending applications.
A next step would be to check to see how APSR 2.1 fits with the electronic cancer checklists (eCC) from the CAP (and also the templates from APSR 1.0). The eCC has list of data elements that are required, but they can be displayed as desired locally, and create different views of the report.
The eCC has specific sequence in their XML, which constrains the end user based on how the vendors implement them. We would need to separate the different requirements of data content from the data presentation / structure. The eCC new structure will be released in SDC. The BRIDG is a different philosophy from the current eCC. The BRIDG model federates out the technical resource requirements and provides a framework for modeling information that isn’t constrained. In the future, this is something for the CAP’s eCC to consider.
Given the work in SDC, PaLM should reach out to this IHE domain (QRPH) to learn more.
IHE PaLM TF 9.0 source documents are in ftp://ftp.ihe.net/DocumentPublication/CurrentPublished/PathologyLaboratoryMedicine/:
It is ready for publication and IHE publications has been notified. It should be posted next week. This IHE TF is based on HL7 v2.x and CDA, but when do we need to think about supporting FHIR? The stakeholder will express themselves, as usual, during the yearly process of call for new proposals (next one is on December 2018). At some point we might see coming proposals for new use cases targeting the FHIR standards.
PaLM Deployed Around the World:
1. Japan (k050705e_PaLM-IHE-J.pdf) Megumi has a job change and her new employer will support her IHE activities, but she will no longer be a Co-Chair. There will need to be Japanese representation at the international level; this will be decided on the Japanese side. JAHIS would like to retain their Japanese involvement as a Co-Chair position at the international level.
Japan working on implementing ILW:
- In Japan prefer OML^O33 for order and OUL^R22 for reports
- ILW is in Trial status and some organizations have implemented, but have not participated in Connectathons in Europe or North America.
- If changes are needed, a CP will be submitted.
2. Europe update: Filip has a list of hospitals in Europe that have implemented LTW (LAB-1 < LAB-3). François will add more hospitals to the list (almost now standard for intra-hospital orders – most use LAB-1 with OML^O21, except 1, which uses OML^O33).
France uses LCSD to communicate reference labs catalogs to all proximity labs. So all LIS have implemented it. In the rest of the World, there are not many LCSD implementations yet. It is still a manual process. This may be the place where we could promote FHIR (using the capabilities defined by eDOS, which is based on v2.x Chapter 8 like LCSD, but not implemented in many places either). A new set of resources for sharing catalogs of products or services is being built in FHIR; the next FHIR Connectathon is in Sep at HL7 WGM in Baltimore. Filip has a list of known issues with LCSD that he will share with the group.
For XD-Lab, France has a regulatory framework for sending to national EHR-S, but the national EHR-S is not as successful as promised. There is some support for clinical lab and hematology, but not micro (since France is not SNOMED international member). In Belgium, there is a national plan to standardize results for all physicians and registries starting with XD-Lab for content. MIPS is working on a proof of concept – by 2020 XD-Lab implementations using LOINC for tests and SNOMED CT for specimen, micro; UCUM will also be used.
XD-LAB is mandatory in Austria where a national xslt stylesheet has been designed to render XD-Lab information in a nice manner; Switzerland has it in its regulations and converted the word specifications into art-décor. We will have to check with Tony Schaller on implementation levels.
What is the prevalence of UCUM in Europe? In France it is used for medication workflow and in lab reporting. There was a discussion about use of different units for the same LOINC; often labs will provide results in IU and conventional unit in France to allow the conversion to make trending easier. In CDA you can provide more than one unit along with a translation between units; this is not possible in v2.x or in FHIR. In that case you would need to produce two observations instead of one.
LOINC SNOMED cooperation:
Some side news about this ongoing cooperation: LOINC to SNOMED expression mapping – is behind and also not clear how good the quality of the mapping is for the expressions – the LOINC parts have been translated (better quality than the expressions) – several countries reported to the SNOMED International board.
LBL is in production in Italy with Inpeco; we need to get numbers. There is also work on expansion of this product in Switzerland, Belgium, and France.
IHE PaLM webinar:
A discussion was held as to which profiles to highlight in the upcoming June IHE webinar:
- It will cover digital pathology
- Split into category of published ( LCC and APSR 2.1 and TMA) and in progress: (SET, Digital Pathology)
- Discussion how to get involved – point to wiki pages for the profiles in development
Here are the stats from last year’s webinar: https://drive.google.com/drive/folders/0B9_jYVJ2XnXsUTZ6YmNkNmtseTQ
PaLM Board report:
We will need to update the Japanese Co-Chair for 2018 – Ken will update the group as to the decision. We will also need to update the membership roster; Sabrina will do this. The PaLM timeline on the wiki will need to be updated also.
We need to update the numbers using profiles (based on Filip’s email and from Francois) and also check the links that all of these work. For LBL, there are implementations in 10 sites (Inpeco). We need to add in Japan’s new work on ILW and get bullets from Ed about LIVD, AUTO-16, and SHIELD. Board report is due in January 2019 so due to DCC in December 2018 – will reiew finalized version in November.
List of known LCSD issues:
The open issues are all related to GLIMS as “Code Set Master” in LAB-51 [Laboratory code set management]
| MR | Goal | Sts | Owner | Assigned | Modification(s) | Incident(s) |
|---|---|---|---|---|---|---|
| 3573 | [100H]J_LCSD : MFN^M10 shall fill-in OM1.19 "Report Header" | EvDev | FM | JVA | 1703-0510 (FR: 'Tourcoing-LCSD-LAB3'),1805-0907 (FR: 'STLO-Support') | |
| Note : A panel has no Report Header. | ||||||
| 2664 | [118H]J_LCSD : OM1-5 : ProducerID when there is no Procedure.Department | Dev | FM | JVA | J_LCSD-00017 (Unconfirmed, ?d, ANL) | 1604-0360 (FR: 'VICHY-Lab3Orbis'),1605-0131 (FR: 'VICHY-Lab3Orbis'),1703-0378 (FR: 'NICE_CHU-ORBIS_LAB-3_LCSD'),1707-0847 (FR: 'Bordeaux_CHU-Glims'),1707-0856 (FR: 'VIEN-ORBIS_LAB-3') |
| Note : Informational tests, calculated tests, … are not related to an executing procedure in a specific department/laboratory | ||||||
| 3579 | [118H]J_LCSD : OM1-5 shall be limited to export a producerID for a specific Source identification. | EvDev | FM | JVA | 1710-0241 (FR: 'NICE_CHU-ORBIS_LAB-3_LCSD') | |
| Note : for Billing, an identifier sources might be configured in GLIMS which is not usefull for the LAB – LAB3. We should not export all known identifications. | ||||||
| 2668 | [121H]J_LCSD : OM1-12 : RequestCode.Explicit (internal or external) | Dev | FM | JVA | GLIMS_CX-00021 (9.9.0, 4.d, ANL), J_LCSD-00018 (Unconfirmed, 4.d, ANL) | 1605-0048 (FR: 'VICHY-Lab3Orbis'),1703-0380 (FR: 'NICE_CHU-ORBIS_LAB-3_LCSD'),1707-0845 (FR: 'Bordeaux_CHU-Glims'),1707-0853 (FR: 'VIEN-ORBIS_LAB-3') |
| Note : Special USE-CASE. Can we inform if an individual RequestCode can be ordered directly or only as member of a panel ? | ||||||
| 2666 | [124H]J_LCSD : OM1-31 : Property.Autoprompt | EvDev | FM | LVDB | 1506-0301 (BE: 'MIPS-J_LCSDMaintenance'),1604-0133 (FR: 'VICHY-Lab3Orbis'),1703-0376 (FR: 'NICE_CHU-ORBIS_LAB-3_LCSD'),1703-0655 (FR: 'NICE_CHU-ORBIS_LAB-3_LCSD'),1707-0855 (FR: 'VIEN-ORBIS_LAB-3') | |
| Note : can we force a pop-up during order entry to fill in some questions ? | ||||||
| 3307 | [127H]J_LCSD : OM3-3 shall be filled | EvDev | FM | JVA | J_LCSD-00015 (Unconfirmed, 3.d, ARVW) | 1611-0603 (FR: 'VICHY-Development') |
| Note : We have a list of possible values, this data is repeated. | ||||||
| See also MR003299 | ||||||
| 3297 | [130H]J_LCSD MFN^M10 shall export all RequestCodes (not limited to Panels) | EvDev | FM | JVA | 1707-0726 (FR: 'Bordeaux_CHU-Glims') | |
| Note : Strange concept of France ? | ||||||
| 3295 | [133H]J_LCSD : Allow panels with only one member via Codingsystems | Dev | FM | JVA | 1708-0910 (BE: 'Portaels-Development'),1706-1218 (FR: 'NICE_CHU-ORBIS_LAB-3_LCSD') | |
| Note : Restricte by GLIMS. If a panel has only one member, we concider the member only requestable via LCSD. To be corrected. | ||||||
| 2674 | [136H]J_LCSD FR : OM4-9 -> SPM-15 : Special Handling Requirements ( Conditions de Conservation (TX) ) | Ini | FM | FM | 1604-0487 (FR: 'VICHY-Lab3Orbis'),1703-0379 (FR: 'NICE_CHU-ORBIS_LAB-3_LCSD'),1703-0639 (FR: 'STLO-Development'),1707-0848 (FR: 'Bordeaux_CHU-Glims'),1707-0857 (FR: 'VIEN-ORBIS_LAB-3') | |
| Note : USE-CASE to be discussed further ? Perhaps via IHE | ||||||
| 3299 | [139H]J_LCSD : MFN^M09 : OM3-3 Enabled GLIMS Choice by Seqno | Dev | FM | JVA | 1606-0166 (FR: 'VICHY-Lab3Orbis'),1706-0125 (FR: 'NICE_CHU-ORBIS_LAB-1'),1707-0850 (FR: 'Bordeaux_CHU-Glims'),1707-0858 (FR: 'VIEN-ORBIS_LAB-3') | |
| Note : We have a list of possible values, this data is repeated. | ||||||
| See also MR003307 | ||||||
| 3302 | [142H]J_LCSD : MFN shall not export an MFE entry for RequestCode.Enabled=NO | Dev | FM | JVA | J_LCSD-00016 (Unconfirmed, 5.d, ARVW) | 1506-0303 (BE: 'MIPS-J_LCSDMaintenance') |
| Note : to be corrected | ||||||
| 3300 | [145H]J_LCSD : OM4-6 Specimen shall not be filled for disabled, unavailable planning | DevSch | FM | FM | GLIMS_CX-00022 (9.9.0, 3.d, ANL) | 1703-0693 (FR: 'NICE_CHU-ORBIS_LAB-3_LCSD') |
| Note : to be corrected | ||||||
| 3575 | [199H]J_LCSD : MFN^M10 OM1-7 + MFN^M09 to transmit Specimen Variable + choices | Ini | FM | ? | 1608-0479 (FR: 'VICHY-Lab3Orbis'),1703-0383 (FR: 'NICE_CHU-ORBIS_LAB-3_LCSD'),1703-0640 (FR: 'STLO-Development'),1707-0852 (FR: 'Bordeaux_CHU-Glims'),1707-0859 (FR: 'VIEN-ORBIS_LAB-3') | |
| Note : USE-CASE to be discussed further ? Perhaps via IHE | ||||||
| AGFA proposed something in France (see attachment) | ||||||
| 3577 | [199H]J_LCSD shall export MicrobiologyProcedure Request Definitions | Ini | FM | ? | 1804-0122 (FR: 'NICE_CHU-ORBIS_LAB-3_LCSD') | |
| Note : Strange setup. To be corrected or configured differently |
Also, review this Word document: variables de materiel.docx (see google drive link above)
In reviewing the red highlights above:
- Special handling instructions of samples: order placer is responsible for collecting the sample, so need that information – that should be in the catalog = LCSD = static information presented as reference, but not needed on EVERY order transaction
- Should SPM-15 handling instructions be filled out each time – originally thought for biohazard, but that is SPM-16 is more intended to raise awareness, when caution needs to be for instance – LIKE BSL3 = biohazard
- How should we deal with special questions – more info about sample collection
- SNOMED CT pre-coordinated term in the preferred sample type OR special new segment that eDOS created and added into v2.8.2
- We should review the gap analysis between eDOS and LCSD and could create CPs for LCSD and create new version based on v2.9: http://wiki.ihe.net/index.php/IHE-SNI_Lab_Harmonization#eDOS_to_LCSD_Comparison
- We will review Filip’s list against the gap analysis.
LCC (LCC-June18.pptx)
Riki will create a harmonization proposal for the new codes in HL70119 (order control codes and control reason codes. It was agreed that the CAP knows that LCC got O60 into base HL7. We need to update LAB-7 to point to O60 and remove REL from O21 – Riki will do that that. Jim will update the codes and add the example.
Jim will write up summary on which elements are applicable for clinical vs IT folks and also a “why they should read it” (i.e., what benefit to the clinicians if LCC is implemented). Then the CAP (Mary) can circulate this to some members for review. In addition, Riki will send to LabMCoP and see if APHL can send to members also.
LAW update (and IICC IVD LOINC update) (UCM610636 LOINC guidance.pdf and IICC IVD LOINC Vocabulary Update 2018-06-7.pptx)
Ed reported that LAW -> AUTO 16 publication may need some editorial changes but is expected to be published by the end of 2018.
Ed discussed AdvaMed; a consortium of medical device manufacturers (ONLY) including diagnostic devices that represents manufacturers. They are separate from MDIC, an industry group closely working with FDA. The FDA is working on real world evidence (RWE) support for research and clinical care, which supports trending across different tests on same patient or population etc.
Ed reported on LIVD, a manufacturer defined JSON format (can be rendered as webpage or excel spreadsheet) that is now being migrated to HL7 FHIR format.
SHIELD (Systemic Harmonization and Interoperability Enhancement for Lab Data) establishes the vocabulary needed for the problem space of tests (LOINC => LIVD), value set definition for results (SNOMED CT for categorical results of qualitative tests) = description of efforts across the industry.
LAW supports LOINC, UCUM and SNOMED CT as basis for SHIELD. The FDA just produced guidance on use of LOINC in IVDs on June 15, 2018: https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM610636.pdf?utm_campaign=FDA%20Final%20Guidance%20on%20Logical%20Observation%20Identifiers%20Names&utm_medium=email&utm_source=Eloqua&elqTrackId=5996578EFCA1565655BA5E374F9B10FE&elq=0d3b8c794a8747de8bcde7036bee5de7&elqaid=3935&elqat=1&elqCampaignId=3060
LAW and LIVID were discussed at the last CLIAC meeting. The committee drafted a recommendation for the use of LAW and LIVD for the industry. (http://ftp.cdc.gov/pub/CLIAC_meeting_presentations/pdf/Recommendations/CLIAC_Recommendations.pdf )
For the IHE Board report, add IICC efforts to support SHIELD by implementation of LAW and LIVD. There will be a LIVD FHIR connectathon (goal is Sep 2018). But, this is a very tight timeline, since proposals are due in 2 weeks and the FHIR content freeze is beginning of August. Most likely the connectathon will be in January.
There is a need to write the use cases to test at the connectathon = could stick that under the catalog FHIR track – focus on smaller steps that can be achieved in the 2 day timeline
BioMerieux has published their LIVD here: https://techlib.biomerieux.com/wcm/techlib/techlib/applications/guidedSearch/cleverLink/searchResultDocumentList.jsp?gs_productname=LOINC+CODIFICATION&gs_productnumber=00-LOINC
It was discussed that is LOINC can be used to make instrument integration easier for labs, there will be uptake for t LIVD use.
Next step for LIVD:
Expand to support the results for each test in the format – need to differentiate between work moving forward AND doing work on how to deal with legacy systems. Represent answer lists for NEW tests and get harmonization effort by method going – sample of 10 common tests that have more than one manufacturer
Questions from IICC Serge: 1. Inform board of work on SHIELD = should we take the FHIR LIVD into IHE profile = write that up as a proposal for 2019 (if base resource is at FMM 3 may be) – LIVD helps in test configuration during set up of the instrument interface; could also help with “auto-LOINC” based on more structured represtentation of results and specimen - add this as future path / trend to board support (SHIELD =RWE) – create a playbook of all the profiles that are needed for best practice lab workflow (LIVD, LAW, LBL etc.) 2. IHE collaboration with MDIC = unsure about MDIC’s role and work output although MDIC could be used to help promote IHE profiles.
Digital Pathology White Paper (http://wiki.ihe.net/index.php/APW-EDM_White_Paper) and IHE APW REDESIGN June 19 2018.pptx)
Raj discussed the current white paper focus which will be to limit the use case to just image acquisition for the first profile. The white paper should be a profile by January 2019, if possible. It depends on a number of items including needed resources from DICOM. David De Mena (Roche) volunteered at Helsinki meeting to help with this.
The white paper will list the requirements and find existing profiles to use, if possible. It will capture high level first and then go into details at the later time (not field by field). An example is handling of barcodes; i.e. handle the local identifier already on the container – that will come at the profile level. Some of the terms may already have definitions (image manager). We will need to identify existing profiles for some of the transactions in the acquisition scenario. We may also need to look at the background on some parts of image distribution.
At the recent PaLM/DICOM meeting in Helsinki, folks supported describing a standard way of identifying a slide; we will need to decide if that is to be included in the white paper.
The goal is for Raj to draft white paper by end of this meeting for review by the group. There was also interest in machine learning for a later profile. (use case is described (evidence creator) = this is similar to analyzer role in clinical side).
The meeting adjourned for the day at 4:55 PM CDT.
'June 20, 2018
SET (2018_06_20_PaLM_SET_F2F_Chicago.pptx)
Alessandro reviewed the SET profile:
- Message structure: EVN-4 = Event Reason has HL70062, user defined and for SET we create IHE specific codes here and then create a few trigger codes for the groups
- The shipment use case should be checked: Can we have z01 – for specimen collection, specimen derived
- Reason for not using OML^O39^OML_O39:Does not have EVN; ORC is mandatory here – though we want reference to order numbers, may not need all the detail (ordering provider etc = the R elements in ORC are: ORC-1 = order control, ORC-2/ORC-3 = Placer and filler order number)
- Do we want OBR also as optional? (R element here are: OBR-2, OBR-3, OBR-4, OBR-7=SPM-17, Conditional for OBR-22 and OBR-25, if results are included, so does NOT apply here)- also have too many segments in it, though most of them are optional) – for biobanking maybe having patient information as optional might be good
- Keep the z-message strucutre for shipment – also this includes speicmen rejection / acceptance – so there is no need for there to be an order for those
- Challenges for biobanking to have consent identification for specimencollection; that is part of the workflow – but this is OUTSIDE of SET => may need a new IHE profile for biobanking workflow
MSH EVN {[PRT]} to track participation of different actors for the event SPM {[PRT]} Order group
ORC
{[PRT]}
[OBR]
{[PRT]}
SAC {[PRT]} Need order reference ONLY for the first message in the chain
- Can we use PRT to track specific routes of delivery using participation type codes (PRT-4) from HL70912
- For chain of custody or for QC do we need PRT after PAC
- What about having same event for specimen processing rather than having 2 events – one for start and one for end?
- For Element mapping: Specimen collection reason – just map that to the order number – can be inferred from that reference
- Missed reason for collection: The container might have been prepared, so may have IDs assigend then; Not sure how that is currently documented in a system.
- Create a specific event for missed collection – create annotation about reason for not being able to collect add OBX after SPM to provide detail: An issue is that lab sometimes gets an empty container and it would be good to be able to figure out where the sampel got lost (or never collected)
- Drop element specimen collection status
- Need a CR to add new fields to the SAC segment to describe Name (ST), length (numer and unit), width (number with unit) – but NOT sure we need to have this for SET – it is in the DAM to be able describe the container for other reasons – Riki can create that CR anyways to improve the base standard AND expand the SAC-27 Container additives to be named container attributes
- For SAC also create element that matches SPM-27 to allow classification schemas
- Marker to indicate that specimen is de-Identified = use EVN-4
- Use EVN-2 and EVN-3 instead of TQ1-7.
- What to do about processing type code – in SPM? We want to have the detail about processing?
- Use OBX after the SPM with OBX-3 – what goes into the OBX-5 there? The date range? What would go into OBX-3 – SCT code for procedure? Riki will bring this up on an OO call as this is a new usage for OBX segment.
LCC (see PPT from previous day)
Jim and Riki reviewed the LCC:
- In reviewing the diagram, the RP/SU, n both elements will be updated
- How to communicate the recommending provider ? Use ORC-12/OBR-16, ORC-14/OBR-17, ORC-24 for provider and ORC-21 – 23 for facility information. That can be overwritten with the actual ordering provider in the response when the recommendation is accepted (it does not include order numbers – just a skeleton order).
- Do we need to identify these similar to reflex orders (OBR-11 = G) = use A for the new order in the supplement request and use R for replacing orders (accepted recommended replacement order) and the original would have the OBR-11 as blank.
- Jim will make the updates to text and check who has the latest version of the diagram (Figure 3.6.4-1)
- The use of O60 for LAB-7 was verified as v2.9.
TMA (20180620_IHE_TMA.PPTX)
Filip and Dan review TMA:
- During the action of transfusion will you check prior to immediate administration, if product is still usable.
- Need to define the elements needed in the BTX segment
- Need verification of patient (PID-3 and PV1-19 (visit number) and blood bag = product code PLUS Donation ID
- For BTX-11, need to review codes in HL7 and which one to use for that; in example message got COMPLETED = map to transfused
- Need to add more discussion about the verification; that is not currently covered, there is no existing message
- Should we extend the values of BTX-11 to cover request to transfuse – and do we communicate “ ok to transfuse” via application ACK? This is a separate profile; this does not currently exist as functionality in systems. It is also a timing delay and something to do later.
- Dan will add an example message
- Add BTX and BTO segment static definition – only needed if different from base standard – need to check the conditonality of the 6 Conditional elements BTX-2, BTX-3, BTX-4 are requried for blood products
- BTX-5, BTX-6 and BTX-7 for commercail products for blood derivatives.
Digital Pathology White Paper, cont. (IHE F2F 6 19 2018 slides v1pptx) and (201906_PaLM_DigitalPatho_high-level_view_FM.pptx) and (IHE APW REDESIGN June 19 2018.pptx)
Nicholas presented an overview of his experience at MGH that included services, issues with prior implementations, DICOM networking comments, and modality worklist from radiology. A number of issues were discussed that could affect the workflow of digital pathology and the development of a profile:
- Information getting passed is not structured
- Current systems are HL7 messages without confirmation messages
- One scanning vendor will probably not meet all your needs; multiple viewer systems are in use
- There is a lack of well-defined needs to manage the requests for images
- More systems may need a PACS broker in the future.
There will be multiple scanners in multiple enterprise hospitals and we need to understand and model where to send the slides to be scanned. For the profile, we need to know where slides are being scanned. Need to know where the data needs to go.
Raj stated there is a need to support workflows with a scanner expecting the arrival of a specific glass slide. It’s an asset ID issue. Information that is required for scanner is somehow made available via interaction over the network. So there needs to be another way to schedule the asset with the scanner. Need to give the scanner enough info to know what to do.
There are problems with labels on slides when there are multiple stickers that have been placed on the glass. Separate this from initial image acquisition.
Let’s assume the bar code is on the slide and can be read.
Need to recognize the ordering process of images is more complicated than the models would suggest
Comments: - Should we work with the unsolicited workflow - The slide appears on a scanner and assumes everything from histology will be scanned. - Today, the LIS determines the creation of the glass slides. With unsolicited workflow, the vendor preference is to make the interface as simple as possible; not bi-directional interface to query the LIS to send the info on what to do. - We need to broadcast and query the APW terms - An unsolicited workflow always needs to be a query to be performed; the management system has a particular request for that slide stored. - In an order filler and image acquisition and image manager, who plays the image acquisition manager– in the LIS? - For acquisition scenarios: o A specific event (e.g., tumor board or send out) necessitates placing an “order” or “task” to ask for glass slides to be pulled and imaged o Acquire all slides as soon as they are physically produced for primary dx using digital image o Glass slides used for digital image and lab staff annotates which ones require image acquisition
The following were discussed and finalized: - The scheduled workflow steps were defined; only applies to slide level, not block level. - The order driven workflow steps - Initial profile assumptions - The acquisition scenarios – actors were finalized. - Surgical Pathology macroscopic (cross-organization) views - Pathology microscopic (in-lab) views
The first candidate profiles were revised and finalized. Discussions centered on: - Query vs pull - Broadcast vs pull - Optional transactions u and v - Will check for conformity with DICOM supplement 145 (RAD-8 and supplement 145 issue. Need to see if RAD 14 and 16 are pertinent.
It was agreed that LAW should be reviewed to see if any transactions can be used from that profile. For example, what are the requirements for the transactions and which standard cover them already.
For the white paper, Raj and Nicholas are the main editors. On July 31, the first draft of the white paper will be sent to the working group for review. It will also be shared with the DICOM co-chairs. In addition, Bruce Beckwith and Frank Apledom from DICOM will be asked to review the draft.
All will review the draft by August 30th with the intention of publishing in on IHE.net September 17. Riki will let Mary Jungers know of these dates.
Wrap up Francois provided a summary and wrap up from the meeting:
- APW-EDM white paper and 1st profiles
> July 30th: draft WP circulated within PaLM and WG 26 (Raj) > Feedback deadline: August 31st > Submission for publication September 17th > 1st profiles: image acquisition + ordering/reporting
- public comment in October
- trial implementation in December
- in time for Europe connectathon in April 2019 (France)
- PaLM TF release 9.0 publication
> submitted for publication June 20th (now!) > LCC: 2nd PC publication with broadened reach out > Planned submission for publication June 29th > Audience broadened to HL7 OO, CAP committees and API > HL7 version is 2.9 for LAB-7, and 2.5.1 for LAB-6
- APSR 2.1 released for Trial Implementation
> François will hand it over to Mary Jungers right after the meeting.
- SET: Vol 2, with Z msg structure > CR to HL7
> Check general message structure and trigger events > EVN-4 represents the precise event > Follow-up on how to represent specimen processing with OO (Riki) > New CR for HL7 for SAC elements, not directly related to SET (Riki) > Merge change requests (Alessandro’s > Riki’s) > Re-check on the matrix (Vol 1) > Consider booking a dedicated 2nd hour call for SET, when Alessandro is ready.
- TMA:
> Check public & internal comments > Pre-administration verification out of scope of TMA. Consider creating a separate profile for this. Add text in TMA to clarify. > No example messages.
- Add one in the supplement.
> Missing segment static definitions for BTX and BPO.
- Provide a static definition for BTX
- BPO content is not really useful to TMA, though it is mandated by the message structure. Clarify that in the profile. No expectation of usage by recipient.
- PaLM Board report 2018
- François prepared draft, hands it over to Riki
- To be consolidated by PaLM leadership and then shared with the PaLM committee
- Will include PaLM position statement towards SHIELD/LIVD --> future PaLM profile
- Due for December DCC call
- Review PaLM webinar 2018
- Done
- Scheduled for June 28 (Riki & Raj)
- Status of PaLM SNOMED CT candidates
- PaLM is all set. Check at next DCC call (Riki)
The meeting adjourned at noon.
14