Card Tech Minutes 2016.11.30: Difference between revisions
Jump to navigation
Jump to search
| (One intermediate revision by the same user not shown) | |||
| Line 11: | Line 11: | ||
==Minutes== | ==Minutes== | ||
:''Agenda Development for December F2F Meeting'' | :''Agenda Development for December F2F Meeting'' = 33 mins | ||
:* Addition and sequencing of items for discussion during the two-day meetings in Washington DC. | :* Addition and sequencing of items for discussion during the two-day meetings in Washington DC. | ||
:''PCC Point of Care Medical Device Tracking profile'' = 27 mins | |||
:''PCC Point of Care Medical Device Tracking profile'' | :*Questions from Dan Murphy regarding details of the profile: | ||
:*Questions from Dan Murphy regarding | :1. In discussing this with some of our integration experts, they said Epic doesn't receive HL7 v2 messages or any other interaction directly from the barcode scanning servers as far as they are aware. Any information comes to the EHR from the IMS. This seems to contradict what we heard at the previous TConn call. Is this their expectation also for a workflow? We do support the other direction if desired where a USB barcode scanner is used to scan information into Epic's surgical and invasive procedural software directly and then increment/decrement messages are sent to the IMS. | ||
:2. Since this profile seems to want to encourage the IMS to support the UDI, then wouldn't we want to amend existing HL7 v2 interface specs to include UDI if they don't already to support the communication from the barcode scanner software to the IMS and then to the EHR? That would be an easier path for the barcode scanner software and IMS to support UDI. If those specs already support UDI, then is this more of an implementation problem? | |||
:3. Is this a workflow profile only and leverages the existing "Device" FHIR resource? If it is a proposal for a new FHIR resource then how does it differ from the existing "Device" resource? This already includes the UDI and should work with existing methods. The IMS passes to the EHR an identifier known to the IMS and the barcode scanner software and the EHR could then query the barcode scanner software for the UDI if the IMS can't/doesn't want to handle the UDI. | |||
:*The use cases must be scoped clearly to communicate which clinical use cases are supported by the profile. This may change with more input from cardiologists regarding their workflows. | |||
[[http://www.hl7.org/implement/standards/fhir/device.html]] | |||
Latest revision as of 11:00, 30 November 2016
Attendees
- Chris Melo, Philips, Co-chair
- Nick Gawrit, Heartbase, Co-chair
- Paul Dow, ACC, Secretary
- Dan Murphy, Epic
- Antje Schroeder, Siemens
- Abdul Mailk Shakir, Hi3 Solutions
- Rebecca Baker, ACC
- Andrea Price, Indiana University
Minutes
- Agenda Development for December F2F Meeting = 33 mins
- Addition and sequencing of items for discussion during the two-day meetings in Washington DC.
- PCC Point of Care Medical Device Tracking profile = 27 mins
- Questions from Dan Murphy regarding details of the profile:
- 1. In discussing this with some of our integration experts, they said Epic doesn't receive HL7 v2 messages or any other interaction directly from the barcode scanning servers as far as they are aware. Any information comes to the EHR from the IMS. This seems to contradict what we heard at the previous TConn call. Is this their expectation also for a workflow? We do support the other direction if desired where a USB barcode scanner is used to scan information into Epic's surgical and invasive procedural software directly and then increment/decrement messages are sent to the IMS.
- 2. Since this profile seems to want to encourage the IMS to support the UDI, then wouldn't we want to amend existing HL7 v2 interface specs to include UDI if they don't already to support the communication from the barcode scanner software to the IMS and then to the EHR? That would be an easier path for the barcode scanner software and IMS to support UDI. If those specs already support UDI, then is this more of an implementation problem?
- 3. Is this a workflow profile only and leverages the existing "Device" FHIR resource? If it is a proposal for a new FHIR resource then how does it differ from the existing "Device" resource? This already includes the UDI and should work with existing methods. The IMS passes to the EHR an identifier known to the IMS and the barcode scanner software and the EHR could then query the barcode scanner software for the UDI if the IMS can't/doesn't want to handle the UDI.
- The use cases must be scoped clearly to communicate which clinical use cases are supported by the profile. This may change with more input from cardiologists regarding their workflows.
[[1]]