Lab AP F2F MinutesAgenda 2015-May-19-22

Back to Anatomic Pathology

Back to IHE Laboratory Domain

Back to IHE Laboratory Technical Committee Page

Files

Presentations and documents are available HERE

The PDF verison of these minutes are available [https://app.box.com/s/m6egrfbitw04if4hluv5w6g50qv3l1on HERE}

Minutes

Minutes of IHE Lab and IHE Anatomic Pathology meeting

May 19 – 22, 2015

Paris, France

 

</tbody>

Name	Company	May 19	May 20	May 21	May 22
Fabio Clemci	Inpeco	X	X	X
Christel Daniel	AP-HP		X	X(pm)
Raj Dash	CAP	X	X	X	X
Jurgen De Decker	MIPS	X	X	X
David Escoffier	Medasys	X
Francesca Frexia	CRS4	X(am)(tc)		X(pm)(tc)	X
Anne Gaelle				X(tc)
Luca Giachetti	Inpeco	X	X	X	X
Gunter Haroske				X(tc)
Jim Harrison	CAP	X	X	X	X
Ed Heierman	Abbott	X	X	X	X
Naomi Ishii	JAHIS	X	X	X	X
Genichi Kato	Imperial Foundation Saisekai Shiga Hospital	X	X	X	X
John Hopson	Abbott	X	X	X	X
Mary Kennedy	CAP	X	X	X	X
Carolyn Knapik	CAP	X	X	X	X
Megumi Kondo	Sakwa Finetek (IHE)	X	X	X	X
Laurent Lardin	BioMerieux	X	X	X	X
Ward Lootens	MIPS	X	X	X
Francois Macary	ASIP Sante	X	X	X	X
Cecilia Mascia		X(am)(tc)	X(tc)	X(tc)
Riki Merrick	APHL	X	X	X	X
Filip Migom	MIPS	X	X	X	X (tc)
Dmytro Rud	Roche	X	X	X	X
Alessandro Sulis	CRS4	X(tc)	X(tc)	X(tc)	X(tc)
Joost Van Averbeke	MIPS	X
Mikael Wintell	DICOM		X

(tc) = Teleconference

 

<tbody>

	Topic	Actions	Responsibility	Due Date
1	LAW	Revision of Test Cases for the virtual Connectathon with LAW 1.4 Initialization of the spreadsheet, François (done) Add proposed updates to spreadsheet Final review during next conf call on June 9 (2nd hour), and then handed back to Anne-Gaëlle	Ed (lead), Dmytro, Laurent, François, Filip, Luca, Naomi	09 June 2015
2	LAW	Integration of additional CPs conformance length ASAP for virtual Connectathon in July Remainder for the final text version (CLSI + LAB TF)	Ed, Riki, Dmytro, Joanna	Before July
3	LAW	Follow up with HL7 - new trigger event 42 (correcting ORL^O34) needing a new message structure identifier	Riki	September 2015
4	LAW	Follow ups with CLSI	ED	October 2015
5	LSH	Complete the pre-spec and put it on the wiki and update wiki as needed	John	July, 2015
6	LCC	Complete the Change Requests for HL7, get them registered & discussed	Jim	ASAP
7	APSR	Complete the Change Requests to APSR (new name?, 1 single generic template, list of observations)	Christel & Thomas
8	LAB TF 6.0	Post materials to ftp + notify Mary Jungers (+ update LAW CPs on the wiki)	Francois	May 25 (done)
9	Cooperation with DICOM	DICOM starts a global use case (cross domain), and we complement it with pathology and laboratory medicine, to test the supplement 155 for the use case Raj described to see if it can flow through DICOM – consider breast cancer use case – initial mammogram, wire placement for surgery, needle core biopsy (or take it out of complex MDT case?) Or start with basic screening? We can announce that we will be working on supplement 155 / joint IHE Lab/AP - create a valid use case that would work in US, Europe and Asia.	Mikael for the use case.	October 2015
10	Cooperation with DICOM	Organize a teleconference with Harry Solomon in order to set up the strategic plan for in vitro imaging (split APW in 2 parts, introduction of the Automation Manager)	Christel	September 2015
11	AP & LAB merger to PaLM	Communicate plans to DCC (Once agreed on the decision to merge, will need to hold debate and ballot a formal vote)	Mary	May 2015
12	Merger	Can we have more than 2 planning and 2 technical Co-Chairs?	Mary	August 2015
13	LAW	Francois will update wiki page related to the CPs published as part of LAW v1.4.	Francois	August 2015
14	New proposals	Call for new proposals	Secretariat	October 2015

 

All slide presentations and spreadsheets for the meeting are located at:

https://app.box.com/s/acbtjvf8hi8hp0k76yhicc9f9spfde16

May 19, 2015 Agenda

<tbody> </tbody>

Time	Agenda Item	Presenter/Lead
09:00 – 9:30	Welcome/Housekeeping/Agenda Review/	Francois
9:30 – 10:00	Overview of AP & LAB current scopes and assets	Francois/Raj
10:00 – 12:00	Lab Device Automation (LDA) reengineering	John
12:00 – 13:00	Lunch at inhouse restaurant
13:00 – 14:00	LDA discussion continued	John
14:00 – 15:00	Demonstration of interoperability test tools	Joost
15:00 – 17:00	Lab Analytical Workflow (LAW) improvements	Ed

 

Introductions were given. This is the first official meeting of the joint Lab and AP Domains. The two domains will discuss merging into one domain during this week.

 

Overview of AP and Lab: (See APandLABComparison and APandLABCurrentScope)

We reviewed a spreadsheet from Francois highlighting potential reuse, overlaps and gaps between IHE Lab and IHE AP work. In some ways, AP is not very different from Lab although the differences need to be examined. Specific use cases: example smear of pleural fluid, which is captured by image, and described in AP work flow better than in the lab workflow, as opposed to cell counts which works well in the Lab profile. Results can include multiple items like CPT, LOINC, ICD-9/ICD-10, SNOMED CT code, and Diagnosis, which can then be sent to provider, billing, and patient. This workflow is the same for both AP and Lab. We need to look forward to how best leverage and avoid overlap. The goal of this meeting is to understand the redundancy between Lab an AP profiles and to develop the best process to reconcile, as well as covering the gaps in both Lab / AP workflows.

 

An example for Overlap: cell flow cytometry uses AP for some, and clinical lab for others. Which profile should be used? It should be the same profile for both. We also need to consider how to include the revenue planning. We need to look at the domain holistically and find a path forward to simplify, harmonize and improve the strength of our domain overall.

LDA/LAW: (See wiki: <a href="http://wiki.ihe.net/index.php?title=LDA_Update_Proposal">http://wiki.ihe.net/index.php?title=LDA_Update_Proposal</a>)

Previous diagram:

New diagram:

Typical lab automation components:

Most of the discussion concerns boundaries around the Analyzer Manager, combined into Automation Manager functions. So for now the three are grouped together. These can be separated, depending upon the vendor set up. The Analyzer Manager conforms to LAW for AWOS, but for other functions (SWOS and sample hand-off) it will follow LDA. What designation should be given to the Automation Manager? We don’t want to standardize the communication of the functions between the actors within the Automation Manager.

We can make this the actor as it has to participate in LWA and LDA. Do we need a specific profile for sample hand-off or should it be made part of LDA? If yes, then we would need to be careful what we define as mandatory profile.

The results go back to the Order Filler (using LTW LAB-4 and LAB-5). How do you decide where to make some of these decisions as they could be in the middleware, the analyzer, or in the LIS? Sample hand-off should be part of the LDA as we always have to have a pre-analyzer connected to the track. We would have to create separate component for testing purposes.

We have not connected the sample hand-off between the pre-analytic and analyzer, as the sample transport/track is often integrated and not to be standardized at this time. What if a specimen is collected for storage only? The lab places the specimen into the pre-processor but how does the track learn that it needs to go to storage only, if the interfaces are ONLY via analyzers?

Pre-processing may be different for specimen storage when testing is intended for a later date, as opposed to specimens intended for immediate testing. This could be handled as a hold for testing.

Physical sample is placed on track – pre-analyzer will query automation manger what to do with the barcoded sample:

• Put on centrifuge
• Put in storage
• Put on analyzer

After first testing is initiated, then route to another analyzer. After all testing is initiated, then send remaining specimen to storage. AWOS and SWOS can be query based.

Why was LAW separated from LDA in the first place? The original LDA is a higher level representation of the entire automation flow in the lab. We wanted to separate the actors. LAW has a focus on test orders and results for an AWOS.

SWOS purpose is to communicate with aliquot and centrifuge and not per se for communicating with the transport system. The transport system is usually vendor specific as they are almost always integrated (RWOS). This would only be needed if the vendor has a separate robotic device.

Sample hand-off should be the same profile, regardless of whether it is a pre-/post processor or

analyzer.

SWOS: will have query, update and download. Splitting out the Analyzer Manager from the Automation Manager was an important move, as in the market place there are several supporting ONLY analyzers, without the automation part of this (middleware can only talk to analyzer; but could still be the Automation Manager in the LAW profile).

Definition of an actor is always the same in one profile. In order to create a single format we would have to use the same name, where the actor can play different roles, based on the use case covered.

The specimen transport is either part of the pre/post processor or the analyzer in the current market place, which is why we keep communications to the sample transport out of the scope of new LDA.

Sample handoff:

• Sample routed on track
• lane goes in front of instrument
• sample A has arrived
• analyzer aspirates the sample
• analyzer has to let the track know, when the aspiration action is completed
• Sample A has arrived
• analyzer takes it off the track
• does what it needs
• analyzer gives specimen back to the track.

 

There is additional logic of tying the actors in the Automation Manager together, which has been left out. Current naming gives some boundaries to the actions of the Automation Manager when creating the different abstract level responsibility.

 

Do we want to split out the sample hand-off into a separate profile, rather than an option in LDA? A separate profile such as Lab Sample hand-off (LSH) or Lab Sample Tracking (LST) which might be good in case of a federated lab enterprise sample exchange (between different automation lines, across labs etc.) The transport can be even larger and can start from the patient collection step. This would be more scalable, so for current use cases we should use LSH and describe the boundaries in the background. The rational of leaving certain actors unnamed in the diagrams should be included in the background for clarity.

 

Assay availability information is needed, such as what test can be performed; is QC ok, was it calibrated, do I have reagents etc.? For future discussion: how to best communicate that information and which connection to use. Propose LAW to support scheduling.

Roche currently is working on the test availability process using automated equipment from HL7 chapter 13. HL7 is reviewing the change proposal to cover this use case; this could also help with forecasting such as who would manage the inventory across multiple analyzers. Analyzer Manager inside the Automation Manager along with the additional logic is not clearly defined. We currently have no profile describing the logic / rules engines at any of the steps where decisions are made. It is not part of the communication profile.

 

The current work covers updating LDA (in regards to pulling out LSH) and adding LSH – phase 1 focuses on LSH only. Discussion is needed in the framework as how to fit all these profiles together in Vol 1 of Lab-TF, as a supplement for Trial implementation.

 

Single sample point in space presentation use case:

Prepare complete = acknowledgement – can or not perform?

Currently: missing reagent or QNS is reported via LAW to Analyzer Manager as an exception message. Would it now only go via the LSH to the Automation Manager? Not necessarily; only the “not enough specimen” (QNS) would use the LSH and then route to the exception queue, for example. Missing reagent would not work that way.

 

INPECO sends the same error both ways: via the track as well as the LAW channel.

 

LDA Use case review:

• Determine analyzer’s ability to process sample
• Prepare for sample analysis
• Start sample analysis

 

Start sample analysis diagram:

Discussion of the actor responsibilities:

In each profile are we using the specialization of the actors based on responsibilities of the AM.

Proposed transactions:

• Transaction 1 can start with status request rather than receiving it unsolicited.
• Transactions 2 and 3 include the response

 

Analyzer ability to test MUST occur after analyzer receives AWOS from AM.

 

This use case can have different scenarios – for example, to cover exception handling. Other use cases include: Analyzer takes container off track, uses sample as needed and places container back in the track.

 

Rename aspirate – specimen action = acquire sample – so need to have start acquisition and acquisition complete

 

Does the status check have to occur before each sample? The status update message is asynchronous and not limited to a query. Not functionally feasible to query the analyzer all the time, hence just use an unsolicited status update.

Analyzer can also be Pre-/Post Analytical device, so change to device. Automation Manger would know next steps

 

Change prepare for sample analysis – seems to be more of a trigger than a request – command to create a closed loop. Create transactions 2 and 3 as two part transactions in order to create the loop.

Transactions:

• Status update = single transaction = LHS-2 = ESU^U01 with ACK for receipt of message.
• Query for status update = single transaction, with ACK for receipt or query, that then triggers the status update = LHS-1 = ESU^U02, with an ACK for receipt of query message
• Command – Response handling = 1 IHE transaction applied to both steps in the use case = LHS-3.

[Per chapter 13 it seems we should use EAC^U07 for the command and EAR^U08 for the response = note from Riki: not discussed]

 

Interoperability Test Tools: (See InteroperabiliytTestTools)

What is jRuby? It is Ruby running on Java environment plus using Java libraries. The datamapper maps data objects to segments.

 

Use Silvio to build the OML^O21 to send to interface application. Then translate and integrate into GLIMS including creation of the ORL^O22 followed by review of the integration result of the response message.

 

An integration review report is sent with color coding of results; this includes the message sent.

We will need to verify the validity of the IHE messages produced by Silvio. Are these valid IHE profiles?

• Gazelle tools are integrated into Silvio.
• Silvio will send message to Gazelle to validate that the produced message is valid.
• If the message is valid, Silvio sends the same message to GLIMS.
• An ORL is received as the reply.
• In the future, the messages from GLIMS could also be validated.

 

Silvio framework has automated testing using scripts. Gazelle order manager has knowledge of patient IDs, order numbers and visit numbers and the relationship between those, but the validator tool is agnostic. Silvio sends SOAP transaction to the Gazelle Validation tool. MIPS development is a test case driven using Silvio.

 

Questions:

Open eHealth (Apache 2 license) (Dmytro chairs this) adopted Gazelle code into production. Gazelle validation is based on conformance. In LAW, when the order is initiated on the instrument, the Order Placer number is “”, so the underlying code needs to be updated.

We will need to check with Gazelle about the details of the Reflex test case. What about the specimen collection in regards to the Order Filler and placer? Specimen information is from the placer, if specimen is collected at time of order, or in the result if specimen is collected after order. We have yet to consider the third party draw station option. In AP the specimen is collected at the time of order, so we can do either specimen centric, order centric, or container centric options, but the correct HL7 message type must be chosen.

 

Gazelle has examples of implementation for validation in several different languages, including ruby, which is a great resource! Next step is the virtual Connectathon between vendors using Gazelle.

 

LAW CPs – (presented by Ed Heierman. See IHE Lab wiki)

The NTE segments were placed in the incorrect spot in the message structure. This will be fixed.

In the ACK mode:

• We forgot to set MSH-15 to “NE” when we decided to not use MSH-15 for error reporting. We are still using enhanced mode, but setting the behavior to correspond to original mode. Dmytro will re-read the text and suggest new verbiage to make that more clear.
• We need to update the base standard as something seems to be wrong there (refers to the ORL message structure). Riki will do some research on the CR that caused the change.
• We have a rule that OBX-3 and OBX-4 must be unique in a message, so OBX-4 must be available in the previous results group. Can we agree to make this optional? Or should we make it RE instead?
• Related observations may be produced by equipment that is not LAW compliant, so do we need to enforce the constraints of these in LAW? How can we do that, when the datatype is OG in the message that has specific definitions? We would have to change the data type. Decision made to keep OG while using OG.2-4 to make it unique. (OG.1 is defined as run number.) This change needs to be tied to the option of prior results as well as to related observations
• Truncation and field length: Can you allow for legacy systems receiver that the length can be shorter than the conformance length? Most of the fields are not used for identification. Should we lower the conformance length instead? Should we drop this to match / allow Beckman Coulter to implement LAW in the requested fields? It was agreed that we should do this.

 

May 20, 2015 Agenda

<tbody> </tbody>

Time	Agenda Item	Presenter/Lead
09:00 – 11:00	Pathology and genetic molecular structured reporting	Raj, Christel
11:00 – 12:00	LAW or LDA additional time slot	Ed / John
12:00 – 13:00	Lunch at inhouse restaurant
13:00 – 14:00	Structured reporting & DICOM supplement 155	Mikael
14:00 – 14:30	Data sharing for Biobanking	Jim
14:30 – 17:00	LAB & AP merging process steps	Mary, Raj, Christel, François, Riki, Chris Carr

 

Pathology and Genetic Molecular Structured Reporting – (See ClinicalGenomicsAndLIS)

Christel led the discussion on pathology and genetic/molecular structured reporting. She reviewed the clinical genomics process and information flow and what would be needed for next generation sequencing (NGS). Current IHE profiles were reviewed and it appears that profiles are missing for:

• Genetic data archival for genomics data – should we copy the DICOM specs?
• File archiving/communication
• Biobanking of specimens

 

We need to evaluate if the existing IHE profiles can handle genetic and molecular structured reporting.

The additional clinical information has already been included in IHE Anatomic Pathology Structured Reporting profile (APSR).

 

In the US:

• None of the current software has functionality to support next gen sequencing.
• Robust clinical decision support is available for some areas, like radiology orders and pharmacy.

  In reviewing the JAMA diagram:

All the data we are storing we will also have the human interpretation. The diagram may be in the future, but the next diagram shows the current state with human review as the last step.

CSER and eMERGE started a project to create decision support in some of their hospitals (6 US hospitals), however this is not yet based on a query of the ‘omics’ system. There is a lack of standardization in this area.

The File formats may be the same. There are several proprietary systems but no standard as of yet.

Are there profiles that communicate between the clinical decision support and LIS? Variant calls need to be part of decision making process and then be integrated.

There is no existing IHE profile; there are profiles for querying systems, but we would have to review.

IHE PCD created Retrieve Clinical Knowledge (RCK) profile as Trial for Implementation – <a href="http://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_Suppl_RCK.pdf">IHE-RCD</a> – this is also related to the Infobutton profile developed by HL7 CDS: <a href="http://www.hl7.org/implement/standards/product_brief.cfm?product_id=22">http://www.hl7.org/implement/standards/product_brief.cfm?product_id=22</a>

Could that be used to send alerts to physicians if the patient already had the same test ordered by another doctor?

The variant database is pretty limited. Everyone is implementing a local knowledgebase and they become experts only on their local database. There is a need to identify what is real and what is noise. The system needs to learn.

DICOM profiles were designed to share images between machines. Is this the same use case?

What about using the IHE - XDS-I? That is just a link to something that is stored in the PACS, but that doesn’t cover some of the architecture that is already available by using the underlying DICOM.

This is a good time now to get vendor involvement during development, as most labs are starting on the implementation of next gen sequencing.

We need to better define the connection between the imaging part on AP and the classic Lab workflow. This will involve discussions with DICOM.

 

Anatomic Pathology Structured Reporting (APSR): (See APSR: <a href="http://www.ihe.net/Technical_Framework/upload/IHE_PAT_Suppl_APSR_Rev1-1_TI_2011_03_31.pdf">http://www.ihe.net/Technical_Framework/upload/IHE_PAT_Suppl_APSR_Rev1-1_TI_2011_03_31.pdf</a>)

 

APSR uses PathLEX: <a href="http://bioportal.bioontology.org/ontologies/PATHLEX">http://bioportal.bioontology.org/ontologies/PATHLEX</a> - a stop gap “terminology” for APSR until SNOMED CT and/or LOINC codes are created for all the concepts.

 

Christel worked on comparing ASPR to DICOM Radiology domain, using structured individual observation sparingly.

We need to focus on generic template and provide examples of the list of standardized observations for the domain while using PathLEX codes, for all, in order to request LOINC, where missing.

It was agreed that we will delete the term “anatomic” from the APSR title and the new title will be Pathology Structured Reporting (PSR). This way we can create a larger lab focus designed to carry clinical lab observations from the Lab domain and anatomic pathology. We would need to see how that compares to the XD-Lab specification. We have used some of those templates in APSR, so they are already aligned.

Clinical observations that appear here are under the clinical conclusion at this point. Reporting hematology cell counts – XD-Lab or ASPR? – can be in both. Medical summary was not be added to the figure in the document.

Integrated disease report combines clinical lab, AP report, plus temporal aspect of results over time.

This can either refer to a specific encounter vs consolidated by problem. We need to keep the simple lab report (XD-Lab), but refine the APSR to have the next generation report.

There was discussion on alternatives to LOINC and SNOMED CT:

• CADSR (data element registry codes) came out of clinical annotations initiative in the US.
• PathLEX has no maintenance resource – so need to get the LOINCs – and review against current LOINC.

It was agreed that a revised PSR profile needs to be created. Why split out AP from clinical observations? We can just call it ‘pathology observation’.

 

XD-Lab will stay as it is already implemented although there is an open issue: We need to clarify the relationship between PSR and XD-lab

 

Francois described the current status of the proposal submitted by Germany for simplification of the APSR last year:

Minor modifications of the proposal will continue in the interests of accommodating both anatomic pathology and clinical laboratory reporting needs. The specimen procedure steps data model was examined. There was a query from Gunter as to whether the parent-child hierarchy was necessary instead of leveraging the relationship between IDs alone to ease implementation. It was decided that the implementation should be no more difficult using the IHE proposed parent child hierarchy and would serve as a more robust model, supporting complex use cases such as tissue microarray where multiple specimen IDs may be placed onto a single slide. The word "anatomic" will be removed from "anatomic site" to indicate a more general purpose spatial representation of a specimen relative to the parent specimen. The content model was then examined and a simple breast cancer use case presented. The model appears to properly support a typical use case based on this demonstration.

LSH:

Added IHE Lab Profiles around the Lab Automation Actor – add role to the Automation Manager in this diagram – for LAW = Analyzer Manager, LDA = Device manager, LSH = transport manager etc.

IHE – Lab Profiles:

Need to be sure we don’t limit to single container for the long run – identify phase 1 for single sample/container and remove “a single” from the definition sentence for the container handoff.

 

Updated sequence diagram for the phase 1 use case:

• On LAW part, rename “orders” to “work order steps” (WOS) – and “query” to “query for WOS” and results to “WOS status update”, which includes the result data.
• This diagram will need to be expanded when we do the container hand-off to return the container back to the track.
• Identify the “status request” as optional by using dashed line for example – or break the columns to show that the status update and sample arrives are not coupled in time.
• Add example of aspiration for analyzer.

 

LSH.3 Command/Response:

Proposed messages content LSH-1:

Use sample track manager here as specialization of the Automation Manager.

Made ERR 0..* and C(M/X), (condition predicate: if MSA-1 NOT in {“AA”, “CA”}

LSH-2:

Same changes as above for ERR

LSH-3:

First part of LSH-3

Second part:

Do we need the SPM information here? SAC information might be enough as it does have information about container dimensions. Should these be mandatory, RE, or optional? For legacy systems it may not be needed. In LAW we created an option where those fields are RE.

We need to also have the trigger for a response when unsuccessful? It should be the same response.

Should we replace sample with specimen? Yes, to match the Lab-TF.EQU-3 make R (is C in the base, R in ESU message, O otherwise) HL70365.

For ECD-2 = Remote Control Command uses HL70368 is user defined – so we can define the code.

Is it ok to command vs notification that the sample has arrived? The command would have to be device specific for the device to be able to act. If we use command, then the analyzer will receive commands from different systems, but these are limited to the action: prepare for acquisition, acquire.

 

The EAR message is the response, but it is not the application ACK for the EAC message, even though it cannot be sent unsolicited. Do we need commit ACK in all cases or only on error to avoid too much overhead? No use of commit ACK here; should use only application ACK – so MSH-15 = NE, MSH-16 = ER.

DICOM and Pathology Structured Reporting – (See DICOM_DSR.pdf)

Mikael Wintell, Chair, DICOM WG 26 presented on structured documentation for pathology. Last year the meeting between Radiology, DICOM and IHE identified the need to organize/develop structured documentation in pathology.

Persisted object part and communication part is covered by DICOM. Covers wave form, sound, movies, and radiology.

Structured report from DICOM began as just text in 1995 and was later integrated into the image series.

Start with the referral and create a structured report (DICOM). Then add information as more results become available which is then returned to the order placer. Each level in DICOM inherits the parent information.

 

There are DICOM Work Groups involved in this work:

• WG 23 = radiology
• WG 8 = structured reporting
• WG 20 = Observation.

 

DICOM Supplement 155 is based on CDA R2.0 and focused on radiology at this time. This Supplement to the DICOM Standard introduces a new mechanism for specifying templates for imaging reports, as well as a set of specific templates for radiology diagnostic and screening reports. Such reports are intended to be encoded using the HL7 CDA R2 (or simply CDA) and to support professional society content specifications, such as the RSNA Radiology Report Initiative. Who should be doing the work on this – DICOM WG-26/20/8 or IHE? The important message is to not have multiple groups do the same thing. IHE does not create standards, but combines them for functional use cases.

We discussed this morning to generalize the APSR/PSR to create a single document template with observation templates bound to value set. We should leverage the effort in DICOM. How do those WGs collaborate? It depends on the projects.

 

We should feed templates into the supplement 155 to see if that works. We could use the PSR building block – entry templates are common across XD-Lab and PSR.

Places where you need DICOM:

• gross image
• micro image
• raw analytical data
• need hierarchy of information and knowledge that has DICOM embedded for image related content

We need to look at several aspects of DICOM and current IHE APW or PSR:

• Sending of orders to a slide scanner and/or analyzer
• Sending digitized images to another person
• Track specimens – what metadata is needed in regards to AP WSI
• How to reference an image
• Need a clear definition of series of images

It would be a good idea to take a use case through DICOM standard use as well to see how it flows through. In CDA document templates, we have a feature for embedding illustrations, but then they are separate images. HL7 created a translation between CDA and DICOM. We can apply that and test with this use case. We should look at PSR and focus on what components are required in a DICOM viewer to transverse the image. Should we consider converting PSR to a DICOM object?

 

The DICOM structured report started out from the patient perspective. Now we have to understand how AP will integrate into that workflow. Radiology has a joint workflow between RISs and PACs. Would pathology do something similar with LISs?

 

Next DICOM meeting is June 2015 in Spain: Propose a joint project to test the supplement 155 for the use case Raj described to see if it can flow through the DICOM. Consider breast cancer use case: initial mammogram, wire placement for surgery, needle core biopsy, or should it be taken out of complex MDT case? Or should we start with basic screening? DICOM WG could start the use case (valid use case that would work in US, Europe and Asia) and announce that we will be working on supplement 155 / joint IHE Lab/AP.

Referral = order = has unique ID that persists over time. Does IHE Radiology have Automation Manager to request image? They are mostly using the DICOM modality, as that was already established.

Biobanking – (See Biobank standardization)

Jim Harrison described a project for developing software for biobanking. He has received grant money to develop open source software; the grant is for the next 3 years. He reviewed the types and need for standardization in data collected in biobanking and stored in repositories. Bio-banking is currently not normalized across facilities.

IHE QRPH is working on a profile dealing with communication between CTMS and EHR-S – some still in progress.

Content standardization is zero, but there appears to be some harmonization about naming of elements. We need to first define the data elements; then define the content. Does that address the protection of patient privacy? The standardization does not necessarily address that. There are national based rules in place (IRB / consent required). How to anonymize genomic data? That problem won’t be solved here.

The Duke University created a data element collection that resulted from an extended process including active bio-banking efforts. Some sort of model is inherent but was not standardized across banks and literature research. University of Virginia (UVA) is mapping between their elements and the Duke elements. They will then have a comprehensive set of data elements for bio-banking and hope to publish this work soon.

Bio-banking software should be integrated to the clinical software. Should we connect to BRIDG WG at HL7? They just published the biospecimen model. We need to review the slide that lists the communication needs and then define the groups that should participate in the development of underlying data model and data exchange:

There is as perceived need to standardize but there is activity without coordination and integration. System vendors are not incentivized to standardize. We need an integrative “home base” with standards development expertise.

We should review the above slide to determine differences between the EHR-S and CTMS. We can handle this at SDO first, before it goes to IHE for functional profile building. The ONC Structured Data Capture (SDC) group is working on clinical trial data outside the EHR-S.

HL7 just started HSI = HealthCare Standards Integration WG. They may be able to help pull together interested parties. HL7 also has BRIDG WG – more info: <a href="http://www.bridgmodel.org/">http://www.bridgmodel.org/</a>

IHE can define the use cases and produce a white paper.

Lab and AP scope discussion and merger: (See APandLABCurrentScope and APandLABcomparison)

There was a discussion regarding similarities and gaps between Lab and AP profiles:

• Gap is specimen related information. Also provider – phlebotomist / transport – provider.
• Specimen errors are covered by LTW such as the specimen is not usable, for example.
• Need to create use cases from AP side to test existing/ planned profiles.
• LIS to LIS – covered by ILW (trial for implementation) – connecting AP LIS to other LIS could use this.
• LIS to CDS to EHR = RCK
• Francois’s spreadsheet collected all profiles produced by both domains and mapped to use cases. If we introduce the Automation Manager in to the APW, then it will be easier to align the Lab and AP created profiles. AP Order Filler does not thoroughly cover the reflex decisions happening at the lab. Using the accession number at the order level is not granular enough.
• In a new profile, create WOS for each step under the higher level order and assign the accession number at that level for only 1 device.
• In addition, we need to consider if a Slide scanner is a device or analyzer. It just transforms the slide to digital data that can then be analyzed, so it is more a device than an analyzer. Cytology imager does some analysis prior to taking the image so there is some overlap between device and analyzer. We need to consider if we want to have a raw DICOM capture of pathology images in order to be able to create data, rather than the “dead object storage” DICOM also supports for cytology. DICOM is not currently supporting the raw data approach for cytology. This will introduce a new actor of AM in AP workflow which should help with acquisition modality management.
• We need to have a different transaction to make the connection between the Automation Manager to the Order Filler that slide is ready; this could potentially be considered a result, or may be considered a status update, or that transaction is not even there.
• The Lab profile allows choice of 3 message structures, so ideally implementations should be able to choose the correct message type for their use case, but in real life vendors implement only 1 message type.
• Imaging related functionality needs to be optional.

 

A good review was provided of detailed material in both domains. In addition to the potential use of IHE Lab profiles to accommodate AP, another reason for a potential merger is that the lab domain has vendor involvement while AP domain has been less successful to attract vendors for testing profiles developed there.

 

We can approach the merger in steps while jointly developing the new LSH profile. Structured reporting development was also discussed. XD-Lab has been implemented in several countries, so it cannot be deprecated, but we could create an improved profile based on newer template usage approach designed in APSR to create the new PSR CDA. This will also contribute to the basic use case in DICOM structured document model, which can be translated to CDA structure. There needs to be collaboration between DICOM WG 8, 20 and 26 and us. As previously stated, DICOM will create the use case and create the DICOM related items; then we will take over and add the pathology side. We will apply the same use case to PSR and compare against the DICOM document.

 

Clinical lab is creating mostly data; it can be automated. AP is creating a diagnosis in addition to data, so automation is limited; however, clinical lab does provide interpretations and conclusions in addition to the results.

 

Defining next steps:

• Identify potential merging projects

For example:

• LSH development
• LDA development

For intra-hospital workflow, we need to start with LTW and APW and then define a new profile. Or do we split APW into two parts so we can harmonize LAB-1 to LAB-3 immediately and then deal with the other parts of the APW?

 

Dealing with in-vitro imaging (LII profile?) is most important for Christel.

We should request feedback from the community and request votes.

 

 

May 21, 2015 Agenda

Time	Agenda Item	Presenter/Lead
09:00 – 10:00	Specimen ordering and tracking enhancements	Raj, Christel, John, Alessandro
10:00 – 12:00	LAW update and LSH review	Ed / John (time permitting)
12:00 – 13:00	Lunch at inhouse restaurant
13:00 – 13:30	Lab Clinical Communication (LCC) status update	Jim
13:30 – 14:30	LAB & AP continent/country reports	Japan, US, Europe
14:30 – 15:00	Harmonization LAB TF / US guides	Riki
15:00 – 16:00	Merge prepare motion and process	Mary
16:00 – 17:00	LAB TF Release 6.0	Francois

 

Specimen Ordering and Tracking Enhancements

Specimen tracking (hierarchy) can be part of the PSR and the LBL profile has messages for tracking specimen labeling operations. We should add an entry in procedure section using specimen organizer which will carry the specimen through the entire step of preparation.

 

For each observation, we should just reference the respective specimen ID. We are still missing the vocabulary for processing for material used in the specimen hierarchy step.

 

Why is the ID listed as 0..1? We do have different level of identifiers:

• case
• part
• block
• slide

 

Each specimen has a pair of IDs consisting of its own and that of its parent. We can embed a growing ID in the child IDs. What if there is a different state of readiness? If no specimen has been attached to a case, then it would not have an ID. But would a report be sent then? Also, should the resulting material be 1..1 as well?

 

Gunter tried to create this construction using Art Décor and it took a lot of time. We have not discussed the combination of specimen and container which is normally 1:1, but that is not true for the slides, as there can be more than 1 section on a slide. There may also be specimens from different blocks contained on one slide. The parent child model will tell you the specimen origin in a tissue array.

We need to properly define what a target site is and have proper examples while defining the vocabulary for the target site outside the primary specimen. We should rename “anatomic site” to “site / relative to parent relationship”. We need to keep in mind that this is the report, not the data model in the LIS, which might have to track more than what we report.

 

There are only 3 steps of specimen procedure that are in concordance with DICOM:

• collection
• sampling to block
• cutting slides

If we are outside of image related DICOM, we have a structure that fits DICOM, but is broader in nature.

One of the outcomes from conversation with DICOM was to find out what the constraints are based on an example use case. AP entry uses the specimen ID in the specimen information organizer. The first entry is the primary specimen. Observations are sorted by problem with the related specimen.

 

For the procedure, do we need to have a specific link to the SOP (of the procedure)? The HL7 Specimen DAM includes a lot of aspects for each processing procedures. We will need to review if we have all that – that has not been translated into CDA; do we need to add an ID to the procedure step?

 

There are different code systems to express methods – like SCT, OPS (in Germany) It seems to be working well, so we will include in PSR release 2.

 

LBL:

Fig 7.3.1 has 2 modes to get the label information:

• query mode (LAB-62) initiates the Label delivery request (LAB-61)
• unsolicited Label delivery (LAB-61)

The supplement requested addition of LAB-63 to indicate successful delivery of labels to the containers using OML^O33 message using ORC-1 = SC – that was in 2011 F2F.

 

The Connectathon identified the following issues:

• Specific information needed on when to print the labels (timing aspect)
• needed additional way to convey this textual information, so decided to use SPM-14
• For specimens consisting of more than 1 tube, add in SAC into the message.

 

LBL is currently designed for blood specimen collection, which was the initial scope, in order to support the automatization of the labeling and specimen storage. Should we expand the scope to include tissue collection?

We renamed SAC-26 ‘cap type’, which is from the base standard. SAC-27 can be used to indicate which additives are used/added for tissue. A Finnish company implementing LBL successfully tested the LAB-63 transaction.

Which actor is responsible for the label design? Lab 61 message carries all the information needed to be put into the label. The label broker has some template and the message information is mapped to that template location. More than one template can be supported.

LAW update (See 2015-05 IICC Technical Team Status; IICC-Gazelle Demo v3; IICC-Supporter Letter April 2015)

Ed Heierman gave an update on the IICC technical team. CLSI will publish LAW as CLSI AUTO16 and IICC funds will be used to accelerate the development of this LAW standard. IICS created AUTO-3 standard – provides background/context and guidance and then incorporated Chapter 13 of HL7 v2 into this standard. The CLSI Document Development Committee (DDC) will formed and will meet in June 2015 to discuss the content of this profile.

DCC is staffed by Laurent, Ed, Andre and Danielle, so there is good participation from folks that are knowledgeable on LAW (in essence we will replicate what we have done in the supplement, which will go away, once integrated into the TF).

 

This will be a successor to LIS-1 and LIS-2 in the ASTM list. There will be discussion around the migration strategy including security information as well as information about how to migrate from serial connection to TCCP. Will all transactions of the latest version be tested at a Connectathon? Yes, we have virtual Connectathon planned, as well as the Japan and North American Connectathons.

There were substantial changes from v1.3 to 1.4, so we want to make sure we test this version well.

Expect a publication in Q1-Q2 2016.

 

Does the Gazelle tool do structure and content – yes! Registration for the virtual Connectathon starts June 1 and will last about 2 weeks. When will the test cases be available? Ed and Anne-Gaelle and Eric will coordinate; we need to identify the profiles to be used.

 

Previously, Anne had shared the test cases with Francois, who reviewed and sent feedback back to Anne-Gaelle. The committee can define the test plan based on the existing test cases and send back as consolidated feedback in spreadsheet. We need to assign the existing 10 test cases to the new options in LAW 1.4; these will be reviewed on the next Lab Committee call.

 

Committed participants:

• AM
  • Orchard
  • Data Innovations (related to Sunquest)
  • Inpeco
• Analyzer
  • Abott
  • Siemens
  • Biomerieux?

 

Orchard has participated in LAW discussions from the start. Results from the virtual Connectathon will be posted to registry, because it is a sanctioned Connectathon with IHE handling the registration, providing monitors, etc.

The time zone differences and other issues need to be addressed prior to the virtual Connectathon. We should set up a daily call for comments for all the participants; we will have Connectathon meetings to talk about the logistics and possibly set up pre-testing. Possibly we can establish a schedule for the week of July 6.

 

Will Japan test LAW v1.4? Naomi will check – also will update the LAW Connectathon slides for Japan 2014, if applicable.

 

LCC Update – James Harrison: (See <a href="http://wiki.ihe.net/index.php?title=LCC_Long_Proposal_-_wiki">http://wiki.ihe.net/index.php?title=LCC_Long_Proposal_-_wiki</a>)

We need to write up the change requests or HL7 v10 CRs. The intention here is communication between order placer and laboratory. Jim will create the change requests and submit to HL7.

 

Updates around the world: (See IHE-J Lab2015_Paris and 20150521_US Update_RMerrick)

Naomi Ishii gave the IHE Japan update. 15 vendors tested Lab profiles; for LAW: 2 Analyzers, 3 Analyzer Managers. Also, many tested for LTW with a microbiology emphasis.

 

The 2015 Connectathon will be Sep 15 – 20 at which there will be testing of all lab profiles. The deadline for registration is the end of May. Gazelle will update LAW to v1.4; is Japan using the same tool? Their tool has been updated, per Naomi

 

Riki gave the US and Europe. Testing was completed with the help of a simulator for LCSD.

aLOINC order code effort, an ONC S&I Framework Initiative, produced a mapping of the top 2000 Laboratory Orders to LOINC codes. This will assist those who are mapping their test orders to LOINC.

CMS Stage 3 MU comments are due May 29, 2015.

 

LSH Review – John Hopson:

Updated sequence diagram:

Looking for better way to depict either trigger event for the status update message

Updated IHE Lab-Profile diagram:

Added step numbers to the sequence diagram in order to better tie the description to the diagram:

Remove the specimen information from LSH-3.

This profile would not specify the notion of a timer, but can give guidance that there should be concept of time-out, when the “prepare complete” is not received in a specified time frame – more detail on how to implement ”time-out functionality” is out of scope for this profile.

For step 10, add extension for “process complete is not received” (time-out functionality support enabled, but not further defined).

Step 2 = Status update might also be sent – as a “heartbeat”.

Step 12 = change to WOS status update.

Step 11 = adjust language to state: Specimen container is under control of the STM.

 

Another version with extensions:

Step 4:

• incorrect message – NACK sent – end of use case
• device states invalid (should we include state of the device in the NACK message? Or just have reason for NACK? – reason is what is important – can be sort of codified in ECR-1

Step 5:

• no WOS – could reject prior to LHS, as part of LAW
• only partial WOS – that would be part of LAW, not needed here? – more discussion

Step 6:

• incorrect message – NACK sent – end of use case
• device states invalid (should we include state of the device in the NACK message? Or just have reason for NACK? Reason is what is important – can be sort of codified in ECR-1.

Step 7:

• specimen cannot be positioned – will just trigger the time-out concept – just don’t get to step 8?
• How can the STM send a status update – need to consider how the AWOS and the LHS message relate to each other – needs more thinking: does the “prepare for acquisition” put the device into a specific state? If yes, then it would need to get a notice; if not, then it does not necessarily need a notification.

 

Merger process: (See Notes_on_LAB_AP_merger_topic_v4)

There was discussion regarding the merging of IHE Lab and AP.

 

The current co-chairs are:

• AP Planning: Raj
• AP Tech: Marcial, Jacques
• Lab Planning: Riki, Francois
• Lab Tech: Francois, Yoshimi

 

Harmonization of shared terminology is a more consistent strategy for definition of code requests to SDOs; this is a consistent strategy in semantic domain and formal relationship with owners of reference terminologies.

 

The profiles the two groups have in common:

• LAW
• Sub-templates in CDA
• LDA / LSH
• LCC
• PSR
• New projects: in vitro imaging
• Needs to be completed

 

It was agreed that the process to begin the merging of the groups would be:

1. Agree on the decision to merge – need to get formal decision via the Google group list.
2. Prepare the reasons for merging and request for vote and comments to be sent out. We need to decide how long a voting period – follow up on regular call and we may need to set up separate call for technical discussions
3. Once decision has been made, we need to identify the common projects – write out project proposals - and prioritize those.

 

What we will do in the meantime:

1. For the joint AP/Lab call suggest second Tuesday at 6:00 AM PT / 8:00 AM CT / 9:00 AM ET = 3:00 PM Europe = 10 PM Japan - for AP and Lab common topics. The second hour will be used for pre-arranged technical discussions, such as LAW test case review.
2. Set up a good notification prior to the next call to ensure we have enough participation on the next call, which will be June 9th – proposed agenda – will send to both Google groups for now and maintain both wiki’s until we create new
3. Review of the merger ballot
4. Co-chairs – keep all for now and discuss the election process – suggest staggering
5. Christel would like to make sure we have at least 1 tech and planning co-chair for AP in order to keep representative in order to motivate AP members to participate.
6. Minimum Co-chair requirements: 1 planning and 1 technical from each domain – can have more, if we have the volunteers – single community of voters with staggered terms.
7. Mary to find out, if we can have more than 2 planning and 2 technical Co-Chairs
8. Suggestions for domain name: PaLM = Pathology and Laboratory Medicine

 

Christel expressed concerns regarding APW:

• We should have a solution for the virtual slide handing. It would be a good strategy to split the current APW into two: order and report – merge that one with LTW.
• Other part of the APW dealing with the imaging should be a new profile that is based on the other part of the APW and integrating the Automation Manager into that workflow. It would be good to contact Harry Solomon and the imaging side for their input. It is important to not throw away the work that has already been done and is properly adapted.

Lab TF – 6.0:

Documents have been shared with participants; leave track changes “on” and your comments will identify you and the CP. The Lab TF 6.0 included 1 change that was NOT balloted, which is a clean up between redundant chapters. The editor decision was to remove the redundant chapters from Vol 2b and correct 2a text where needed.

 

Editor also applied the CP#240, where discrepancies between the table and text were identified.

In volume 1 we have removed the reference to vol 4 deprecation, which is from a long time ago. Since then Vol 4 is now expected to house national extensions.

 

Also removed LSWF and LIR as those are covered under ITI domain. That switch also happened a long time ago.

Next steps:

1. Need to upload to sFTP server and notify Mary Junger – will publish on time!!!
2. Need to update the CP wiki page accordingly – seems to also have to update the LAW related list.

 

Miscellaneous:

Dues will now be collected and will be due in 2015.

 

IHE Secretariat has met with IHTSDO about usage rights for using SNOMED CT (SCT) in the publications.

In order to implement SCT, people need to be IHTSDO members (either country or affiliate license) – unsure of the outcome. IHE should work to have IHTSDO allow use of SCT for Connectathon, if it is not already the case.

May 22, 2015 Agenda

<tbody> </tbody>

Time	Agenda Item	Presenter/Lead
9:00 – 9:10	Next meeting in Japan	Yoshimi
9:10 – 10:30	The LAW	Ed
10:30 – 10:45	break
10:45 – 11:55	Wrap-up, Review of assignments & milestones	Raj, Riki, François, Ed, Mary, Carolyn
11:55 – 12:00	Adjourn ceremony	Naomi
12:00 – 13:00	Lunch at inhouse restaurant

 

The next F2F in Tokyo, Japan October 19-21, 2015 and will be a joint IHE Lab and IHE AP meeting.

 

LAW: (http://wiki.ihe.net/index.php?title=Laboratory_Analytical_Workflow

 

We will adjust the table notation to reflect the proper message structure.

 

Profile options MSH-21:

What are the messaging options when the message structure itself, is very different from the underlying message (like for both pooling options). In theory we can message any of the options in MSH-21, but in many of these there are additional fields in the regular message structure which will not cause validation issues.

 

ED datatype use of table values – we need to find out when HL7 changed over to support RCFnnnn values – we are using v2.8.2 HL70440 for OBX-2, so could just stick with citing v2.8.2.(Note: – not discussed at meeting: After ballot recon of the second ballot OBX-2 is referencing HL70125 again BUT that table is essentially ALL of 440, except 3 datatypes that are not allowed in OBX-5 by the description in table 440). SO in the long run will need a CP for this one.

 

Do we need a statement that raw data can use other datatypes – for example DR? Currently we support TX, ST, NM and NA for raw datatypes as the most common – of course it could be any of the value types already supported. Dmytro will review what we should be using for the raw datatypes and suggest CP change – issue resolved see profile: vendor specific agreement on any valid HL7 datatype for the Supplemental results.

 

LAW is using a OBX-3 and OBX-4 combination that has to be unique with the set ID – even without supporting use of OBX-21.

 

OBR resulted in 3 OBXes:

• First message holds run 1 result
• Second message sends run 2 result – and only that OBX
• Third message sends run 3 result – and only that OBX
• Fourth message would be correction to run 3 – and only that OBX.
• Alternatively the analyzer can send as entire group as well, but the correction will still be ONLY the corrected OBX. We will leave it as is.

 

Usage of OBR Set ID:

No need for OBR-1, since OBR-2 is unique – set ID has no bearing on message parsing in this arena – in LDA OBR-1 is R – in the future we may want to harmonize LAW and LDA.

 

OBX-2 usage:

Let’s not change the usage, so that you can send empty OBX-5 and use only OBX-8 for the interpretation codes. LAW supports ability to send only OBX-8 for valid results.

 

EIP usage for ORC-4:

Leave as is; it came from LTW, where it is being used, hence LAW inherits it.

 

Pre-adoption of ORC-8:

Parents of a reflex – in LAW the instrument wants to track which AWOS contributed to the reflex ordered on the analyzer. Ed to send some specific examples so OO can pick up this - Dmytro found this has been approved; <a href="http://wiki.hl7.org/index.php?title=OO_CR075-725_Repeat_ORC.8_and_OBR.54">http://wiki.hl7.org/index.php?title=OO_CR075-725_Repeat_ORC.8_and_OBR.54</a>

 

Use of profile IDs:

Update the MSH-21 populating section to be sure that we are explicit; which of the profile options MUST be sent in MSH-21 vs which are optional to be sent?

 

Use of “” in CE and CWE. When you populate with “”, we must clean up the document and we must send a notice to Gazelle to fix that, because they will raise an error if the code system is missing for CE or CWE.

 

Conformance length – Joanna to write CP.

 

How do we best provide feedback on the LAW test cases:

• Francois will create a spreadsheet that we can work with – we will need to identify the options in LAW for each test case.
• Expand the test cases for the NA Connectathon. For the virtual Connectathon due to time constraints, just identify the options that are applicable from the existing cases.

LSH:

What should we call the specimen processing device? Lab device = analyzer and automation related devices minus the specimen transport manager.

A new wiki page has been created: <a href="http://wiki.ihe.net/index.php?title=Laboratory_Specimen_Handoff">http://wiki.ihe.net/index.php?title=Laboratory_Specimen_Handoff</a>

But we will leave the old LDA page as is for now.

Updated the diagram to show:

Do all analyzers have to query for WOS? “Prepare for acquisition” may cause the query for WOS, but it should be more generic to alert the device to be ready (for whatever it needs to do), so the query should be optional (dashed line).

We will create time break between the “prepare for specimen acquisition” and the “prepare for acquisition”. This is expected to be for 1 sample ONLY. Make sure the diagram legend is clarified: instead of adding the time break, add a descriptive paragraph to explain that multiple messages can be interleaved.

 

The device needs a start “specimen acquisition”. As an exception, it should send a cancellation which also needs the “ok I did that” notification back to the specimen transport manager.

 

How do we handle coordination if the device is an analyzer? Should the cancelation come from the AM, and the AM would need to know if the STM notified the device? Should we list the options, or should we even prefer one? Better not; may be very dependent on the products. The design needs to accommodate both approaches.

 

Step 10 extension: what if “specimen acquisition complete” is not sent? STM assumes the worst case scenario, so STM must notify user after a time-out window. STM may start re-routing or other behavior, so that is not defined in the profile.

 

What if we receive the message, but the content is not understandable? Treat it the same way as above.

 

New project proposal template – initial: <a href="http://wiki.ihe.net/index.php?title=Brief_Proposal_Template">http://wiki.ihe.net/index.php?title=Brief_Proposal_Template</a>

For other templates look here: http://wiki.ihe.net/index.php?title=Process

We intend to plan priorities in Oct F2F.

 

Wrap up:

Action item review: (see assignments on page 1)

 

LAW:

Revision of test cases for virtual Connectathon:

• Francois to create review spreadsheet and send to: Ed, Luca, Dmytro, Laurent, Filip, Naomi
• Send comments to Ed by end of June
• Final review of spreadsheet is June 9^th.
• Ed will review the new CPs – one from Dmytro, one from Joanna. Ed will create the one for the conformance length. Collect by June 9th and hope to review on the tech part of the call.
• The CPs will be included in the next publication round. The CS length CP will be applicable for Connectathon testing prior to the new publication. We need to properly publicize that.

 

HL7 trigger event follow up – Riki to get HL7 resolution and then write CP for LAW fix.

Ed will provide a follow up on CLSI status in October.

Francois will update wiki page related to the CPs published as part of LAW v1.4.

 

LSH:

John will update wiki with all of the diagrams and will draft the first draft of the actual supplement document. Review of the LSH will continue on the technical calls and will be included in the agenda for Tokyo.

 

LCC:

Jim will submit CRs to HL7 for approval – Jim to draft, submit and discuss. Review will continue on the technical calls and will be included in the agenda for Tokyo.

 

Lab TF v6.0:

Francois will post material to FTP site and notify Mary Jungers.

 

AP and Lab merger into Pathology and Laboratory Medicine (PaLM):

• Draft merger reasoning document for approval and send out to AP and Lab list serves
• Reschedule conference calls – 2 hour slot with same GoToMeeting – Mary or Carolyn
• Update DCC and Chris Carr on process of merging - Mary
• Create call for proposals – new proposals should be evaluated for applicability to – using the template here: <a href="http://wiki.ihe.net/index.php?title=Brief_Proposal_Template">http://wiki.ihe.net/index.php?title=Brief_Proposal_Template</a>

 

PSR and AP:

• Determine if the DICOM use case be part under PSR, since we have options of CDA, FHIR, DICOM as standards to use. Raj/Christel/Mary will continue to follow up with DICOM through Mikael.
• Get draft cross domain use case from Mikael (DICOM) and forward to PaLM for addition of pathology and lab. The goal is to evaluate the underlying DICOM data model vs applying CDA structure vs other available models – it MUST be able to support imaging.

 

Webinar topic:

Riki and Raj will give an IHE webinar on the merger process:

• Reasons for merger: describe use cases in AP and Lab domain and illustrate how the existing profiles can be modified to accommodate the respective use cases.

 

Meeting adjourned.