|
|
| Line 11: |
Line 11: |
|
| |
|
| ==Minutes== | | ==Minutes== |
|
| |
|
| |
| * Agenda review
| |
| * Digital Pathology meeting debrief:
| |
| ** Slides from Raj
| |
| *** Need to identify digital assets
| |
| *** Leveraging XDS for use case #1
| |
| *** Merged use case 1 and prior# 9 – since similar – still listed as niche use case under 1
| |
| *** Helsinki focus was on short term effort for the white paper:
| |
| **** Acquisition of digital asset
| |
| ***** Actors:
| |
| ****** Acquisition modality
| |
| ****** Order filler, digital evidence creators
| |
| ****** Archiver
| |
| ****** Image displayer
| |
| ***** Acquisition manager
| |
| **** Side identification standardization, could potentially happen later as part of the asset acquisition work
| |
| **** Supported workflows
| |
| ***** Explicit request = scheduled workflow in radiology
| |
| ***** Slide appears at scanner and how to handle that
| |
| ***** Reconciliation between actors (identification handling / troubleshooting; barcode is supposed to be scanned, or barcode for outside organization) – closer to unsolicited workflow – prelim communication with order filler to select information on the slide (modified unsolicited – cannot be automated all the way) – also applies to image imports somewhat, since there is not specifically a barcode available for that
| |
| **** DICOM requested an abbreviated white paper for just acquisition
| |
| ***** Would also be good to include an indication of all the future use cases – list what data elements we might need to get a full information model – list explicitly what is now out of scope for the abbreviated white paper = assumptions like identifiers are usable, etc.
| |
| *** At F2F work on that all day
| |
| *** Use DICOM WG26 and PaLM listserves for getting feedback on the white paper
| |
| * TF ballot votes –
| |
| ** 11 voters
| |
| ** CP256 had one negative vote:
| |
| *** Agree with the concern that OBR-25 should not be F when any OBX-11 I C
| |
| *** Nullify OBX-5.1 using “”
| |
| **** If we leave a value in OBX-5.1 this is a URL to an incorrect report
| |
| **** Convention of use in “” is request to delete, but OBX-11 already indicates that
| |
| **** In Filip’s experience there are result receivers that may falsely interpret that there was a result, because there is a result value in there – this way is safer to remove it (else the receiver might just mark the status change, but not actually remove the link to the report)
| |
| **** Similar handling might be needed for OBX-8
| |
| **** Users will be made aware that there is a correction by OBR-25 = C
| |
| **** CP approved in the new version
| |
| ** Next step to incorporate all approved CRs for review at the F2F
| |
| * SET and HL7 Change request
| |
| ** Have created a CR and updated the matric mapping spreadsheet
| |
| *** Updated the matrix mapping
| |
| **** If we use the same message structure to carry the information for the different use cases, then need to ID the event
| |
| ***** Create different trigger event codes for use in MSH-12 (similar to ADT messages)
| |
| ****** Useful for validation, when different segments are needed
| |
| ****** We have 15 use cases, but potentially can group these into trigger events, where same data is needed
| |
| ****** At least have 2 different types – shipment vs processing
| |
| ***** Use EVN-4 with SET type codes
| |
| **** How to reference the order the specimen is related to without adding an order block
| |
| **** Alessandro will update this to showcase the fields that need more discussion
| |
| *** Next step is to build a z message structure and then provide that into the CR for HL7 for next version of HL7, whose publication might be out 2 – 3 years
| |
| *** Message structure can be similar to the shipment message
| |
| **** Shipment segment is mandatory, can’t use it for all use cases
| |
| ** Do we need any code updated – harmonization proposals are due June 22 for this cycle – else we can go for the November cycle
| |
| *** Alessandro will prepare a list of user defined tables needed by F2F
| |
| * Comments submitted to TMA
| |
| ** This document describes one of the possible workflow, but did not describe the elements needed in the segments nor the values and cardinality etc.
| |
| *** Intent was to not overwrite existing HL7 rules
| |
| *** If we want to use this document to start work on the interface set up – so we should add in message definitions from HL7 to define the profile
| |
| **** Do that for next week’s meeting
| |
| * Ed is planning on being at the F2F Monday afternoon (around 1:30 PM CDT) – do we want update on LAW, LIVD etc – for 20 minutes – yes – will adjust agenda
| |