http://wiki.ihe.net/api.php?action=feedcontributions&user=Kho&feedformat=atomIHE Wiki - User contributions [en]2024-03-29T10:01:42ZUser contributionsMediaWiki 1.35.5http://wiki.ihe.net/index.php?title=Rad_Tech_Minutes_2023-04-24-28&diff=130124Rad Tech Minutes 2023-04-24-282023-04-28T06:09:00Z<p>Kho: /* Integrated Reporting Applications (IRA) */</p>
<hr />
<div>=='''Participants'''==<br />
* Andrei Leontiev<br />
* Steve Nichols<br />
* Wim Corbijn<br />
* Kinson Ho<br />
* Kevin O'Donnell<br />
* Antje Schroeder<br />
* Ben Larson<br />
* Eric Martin<br />
<br />
RSNA Staff: TeRhonda McGee, Jamie Dulkowski<br />
<br />
{{TOCright}}<br />
==='''Reference Documents'''===<br />
* [https://drive.google.com/drive/folders/1p4c2bMYFWz7RWi_5AwRnxuNMHDI40A8h?usp=sharing Rad Tech 2023 Google Folder]<br />
: '''Integrated Reporting Applications'''<br />
:* [https://build.fhir.org/ig/IHE/RAD.RTC-IMR/index.html Supplement Draft]<br />
:* [[Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed|Reporting Content Communication - Proposal]]<br />
: '''Reporting Worklist Prioritization'''<br />
:* [https://drive.google.com/drive/folders/1hgtzMWUu6fEjP_hv0FykpGcdSyXm7-jU?usp=share_link Supplement Drafts]<br />
:* [[Reporting Worklist Prioritization - Proposal]]<br />
:* [https://docs.google.com/spreadsheets/d/13mhkRDDDv-JZaT-W4CCO-C0gmBtgP9-3YT1ADnJTVTY/edit?usp=sharing Table of Factors]<br />
:* [https://www.jacr.org/article/S1546-1440(13)00840-5/pdf 2014 ACR Actionable Finding Categories Paper]<br />
* [https://docs.google.com/spreadsheets/d/1IoRwFz1xxORCwYIJat-Yn2trfkhiT5OKbU8toEpKb5k/edit?usp=sharing 2022-23 Breakdown of Tasks]<br />
* [https://docs.google.com/spreadsheets/d/1ano3hPPOqKC9jJyussJ58JIAma-_Qu9JKfr3OCpOoc8/edit#gid=1412282829 Public Comments Form]<br />
<br />
All times are US Central Time.<br />
<br />
=='''Monday, April 24, 2023'''==<br />
:*A1: 8:45am-9:00am Administrative Time <br />
:**Introductions (Name and IHE Member Organization)<br />
:**[https://docs.google.com/spreadsheets/d/198eCuMJcsMEWwtahidRLcMYzzIrte48CI7kuHbkpY-4/edit?usp=sharing IHE Radiology Technical Committee Roster]<br />
:**[https://www.ihe.net/about_ihe/member_organizations/ IHE International Member Organizations]<br />
:**[https://www.ihe.net/about_ihe/patent_disclosure_process/ IHE Patent Disclosure Statement]<br />
:**[https://docs.google.com/spreadsheets/d/10eE1Hh4czrPc7ntuom_sOQbIH621eRkIe8agXRB4D5U/edit?usp=sharing Current Patent Disclosure Statements]<br />
:*S1: 9:00am-10:30am: Prioritization of Worklists for Reporting (POWR) [1.5hr]<br />
:*S2: 10:45am-12:15pm: Maintenance [1.5hr]<br />
:**Link to [https://docs.google.com/spreadsheets/d/1TmSwnn4AIiXqFLc_AtzP0dNd9LUWnA-ZcCjBMKpLzp4/edit#gid=0 RAD CP Tracking sheet]<br />
:**Link to [https://docs.google.com/spreadsheets/d/1f7Y7ImugFbcyon709ewthFprMVbvPmAtuSlQrtMp3dE/edit?usp=sharing Assessment of RAD TI Supplements]<br />
:** <b>Top Ten: </b><br />
:*** CP-RAD-257 Clearly add Admitting Diagnosis to SWF for REM and TCE <br />
:*** CP-RAD-293 Extended CT Dose Reporting (SSDE and Dose Check Logs)<br />
:*** CP-RAD-349 Add close and logout to IID<br />
:*** CP-RAD-364 Clarify IID<br />
:*** CP-RAD-423 Add specificity to IOCM<br />
:*** CP-RAD-475 Extensions to RAD-107 for IMR<br />
:*** CP-RAD-486 Update RAD-108 Message Semantics<br />
:*** CP-RAD-372 REM-NM<br />
:*** CP-RAD-501 WIA – RAD-129 fix in Expected Actions<br />
:*** CP-RAD-517 NMI Cardiac Option - update to include support of PS<br />
:** <b>Other active CPs: </b><br />
:** CP-RAD-460-LB - XCA-I Clarify IIG behavior in the local community<br />
:*** -- Finalize the CP after two ballots<br />
:** CP-RAD-305-02 - Revise profile dependencies (grouping) in Vol 1)<br />
:*** -- cmte input needed* CP-RAD-347-01 - XDS-I Vol 1 clean-up<br />
:** CP-RAD-343-01 - Consistency in specification of PID segment & references to MPI<br />
:*** -- a few points for cmte discussion<br />
:** CP-RAD-368-01 - Update/Remove MIMA Referenced in Vol 1 TF (editorial)<br />
:*** -- ready for cmte review; could be ready for ballot<br />
:** CP-RAD-436-02 - Fix inconsistencies in IOCM actor / transaction and grouping requirements<br />
:*** -- cmte input needed<br />
:** CP-RAD-410-03 - XCA-I is out of date for Async<br />
:** CP-RAD-492-01 - Update SNM3 and SRT codes in Vol 2<br />
:** CP-RAD-491-01 - Code Mapping WP update<br />
:** CP-RAD-490-01 - Update Vol 1x to remove retired transport for Submit Dose Information [RAD-63]<br />
<br />
'''All CPs approved'''<br />
<br />
:*S3: 1:15pm-4:15pm: Integrated Reporting Applications (IRA) [3hr]<br />
:** 2:00pm-3:00pm: ITI Committee - Github Governance call [for those who are interested]<br />
:*S4: 4:15pm-5:00pm: Editorial Session (as needed)<br />
<br />
=='''Tuesday, April 25, 2023'''==<br />
:*A1: 8:45am-9:00am Administrative Time<br />
:**Introductions (Name and IHE Member Organization)<br />
:**[https://docs.google.com/spreadsheets/d/198eCuMJcsMEWwtahidRLcMYzzIrte48CI7kuHbkpY-4/edit?usp=sharing IHE Radiology Technical Committee Roster]<br />
:**[https://www.ihe.net/about_ihe/member_organizations/ IHE International Member Organizations]<br />
:**[https://www.ihe.net/about_ihe/patent_disclosure_process/ IHE Patent Disclosure]<br />
:*S1: 9:00am-11:00am: Integrated Reporting Applications (IRA) [5hr]<br />
:*S2: 11:15am-12:45pm: Prioritization of Worklists for Reporting (POWR) [3hr]<br />
:*A2: 1:15pm-1:45pm: Administrative Time<br />
:** Framework Republication Plan [Lynn]<br />
:*S3: 1:45pm-3:45pm: Integrated Reporting Applications (IRA)[7hr]<br />
:*S4: 4:00-5:00pm: Editorial Session (as needed)<br />
:*Dinner at 6:30pm @Wildfire - 232 Oak Brook Center<br />
<br />
=='''Wednesday, April 26, 2023'''==<br />
:*A1: 8:45am-9:00am Administrative Time<br />
:**Introductions (Name and IHE Member Organization)<br />
:**[https://docs.google.com/spreadsheets/d/198eCuMJcsMEWwtahidRLcMYzzIrte48CI7kuHbkpY-4/edit?usp=sharing IHE Radiology Technical Committee Roster]<br />
:**[https://www.ihe.net/about_ihe/member_organizations/ IHE International Member Organizations]<br />
:**IHE Patent Disclosure<br />
:*S1: 9:00am-10:30am: Prioritization of Worklists for Reporting (POWR) [4.5hr]<br />
:*S2: 10:45am-12:45pm: Integrated Reporting Applications (IRA) (RBC-IMR)[9hr]<br />
:*A2: 1:15pm-1:45pm: Administrative Time<br />
:*S3: 1:45pm-3:45pm: Integrated Reporting Applications (IRA) (RBC-IMR)[11hr]<br />
:*S4: 4:00-5:00pm: Editorial Session (as needed)<br />
<br />
=='''Thursday, April 27, 2022'''==<br />
:*A1: 8:45am-9:00am Administrative Time<br />
:**Introductions (Name and IHE Member Organization)<br />
:**[https://docs.google.com/spreadsheets/d/198eCuMJcsMEWwtahidRLcMYzzIrte48CI7kuHbkpY-4/edit?usp=sharing IHE Radiology Technical Committee Roster]<br />
:**[https://www.ihe.net/about_ihe/member_organizations/ IHE International Member Organizations]<br />
:**IHE Patent Disclosure<br />
:*S1: 9:00am-10:30am: Integrated Reporting Applications (IRA)[13.5hr]<br />
:*S2: 10:45am-12:15pm: Maintenance [3hr]<br />
:*S3: 1:15pm-4:15pm: Prioritization of Worklists for Reporting (POWR) [6.5hr]<br />
:*S4: 4:15-5:00pm Editorial Session (as needed)<br />
<br />
=='''Friday, April 28, 2023'''==<br />
:*A1: 8:30am-9:00am Administrative Time<br />
:**Introductions (Name and IHE Member Organization)<br />
:**[https://docs.google.com/spreadsheets/d/198eCuMJcsMEWwtahidRLcMYzzIrte48CI7kuHbkpY-4/edit?usp=sharing IHE Radiology Technical Committee Roster]<br />
:**[https://www.ihe.net/about_ihe/member_organizations/ IHE International Member Organizations]<br />
:**IHE Patent Disclosure<br />
:*S1: 9:00am-11:00am Integrated Reporting Applications (IRA)[15.5hr]<br />
:*S2: 11:00-12:00: Admin - Checkpoint assessments<br />
<br />
===TI-Prep Closing Assessments===<br />
<br />
====Prioritization of Worklists for Reporting (POWR)====<br />
* Did we line-by-line the entire document<br />
:<br />
* How ready is it to go out for TI: Completely, Almost, Soonish, Hmmm<br />
:<br />
* How did the work fit in the allocated bandwidth? (Time to spare? Just right? Things were left undone?)<br />
:<br />
* Review the evaluation. Which complexity/uncertainty/effort points missed the mark?<br />
:<br />
* Or alternatively, estimate how many points you went over and assign the overage effort/complexity/uncertainty to the appropriate points.<br />
:<br />
* Are all the open issues closed?<br />
:<br />
* What significant debates in TI-prep were not anticipated in the Kickoff or PC-Prep<br />
:<br />
* Did the Breakdown of Tasks accurately reflect the work? What extra tasks arose?<br />
:<br />
* What residual risks are worth noting<br />
:<br />
* Does it feel we've met all the use cases<br />
:<br />
* Did the promised resources manifest<br />
:<br />
* What vendors are engaged (for each actor)<br />
:<br />
* Who should specifically be targeted for TI notification (implementors & advocates)<br />
:<br />
* When will we have sample data/objects<br />
:<br />
* Was the profile where it needed to be at the start of the TI meeting, if not what was the gap<br />
:<br />
* Was the profile where it needed to be at the end of the TI meeting, if not what was the gap<br />
:<br />
* Do you need any tcons between now and TI Publication<br />
:<br />
<br />
====Integrated Reporting Applications (IRA)====<br />
* Did we line-by-line the entire document<br />
** No<br />
:<br />
* How ready is it to go out for TI: Completely, Almost, Soonish, Hmmm<br />
** Hmmmm ... Large portion of the profile are stable. Most discussions are focus on architectural design to handle interruption and resume use case.<br />
:<br />
* How did the work fit in the allocated bandwidth? (Time to spare? Just right? Things were left undone?)<br />
** Most time have been concentrated on a few but significant topics. These are important topics to address and the discussions are productive, with the help from the FHIRcast members too. However, the downside is that there are not enough time to review all public comments and review the profile line-by-line.<br />
:<br />
* Review the evaluation. Which complexity/uncertainty/effort points missed the mark?<br />
** The interruption and resume use case is not identified in the task breakdown and it has been taken significant amount of time. The use case was reviewed and discussed during public comment development, but there are subtle details identified that require lots of time to resolve<br />
:<br />
* Or alternatively, estimate how many points you went over and assign the overage effort/complexity/uncertainty to the appropriate points.<br />
** Probably 8 points (2/4/2) for Interruption and Resume<br />
:<br />
* Are all the open issues closed?<br />
** Pending discussion<br />
:<br />
* What significant debates in TI-prep were not anticipated in the Kickoff or PC-Prep<br />
** Interruption and resume use case<br />
:<br />
* Did the Breakdown of Tasks accurately reflect the work? What extra tasks arose?<br />
** Interruption and resume use case<br />
:<br />
* What residual risks are worth noting<br />
** Tcon time to review line-by-line, which is unfortunately not the most effective<br />
:<br />
* Does it feel we've met all the use cases<br />
** Yes<br />
:<br />
* Did the promised resources manifest<br />
** Yes.<br />
:<br />
* What vendors are engaged (for each actor)<br />
** Image Display<br />
** Report Creator<br />
** Worklist Client<br />
** Evidence Creator: Tempus<br />
** Hub: Tempus<br />
** Watcher<br />
:<br />
* Who should specifically be targeted for TI notification (implementors & advocates)<br />
:<br />
* When will we have sample data/objects<br />
** Already defined in the profile Artifacts tab<br />
:<br />
* Was the profile where it needed to be at the start of the TI meeting, if not what was the gap<br />
** Yes<br />
:<br />
* Was the profile where it needed to be at the end of the TI meeting, if not what was the gap<br />
** No. Must time have been spent on addressing the interruption and resume use case<br />
:<br />
* Do you need any tcons between now and TI Publication<br />
** Yes. Probably 4 @2 hours to start<br />
:</div>Khohttp://wiki.ihe.net/index.php?title=Rad_Tech_Minutes_2023-04-24-28&diff=130123Rad Tech Minutes 2023-04-24-282023-04-28T05:50:16Z<p>Kho: /* Friday, April 28, 2023 */</p>
<hr />
<div>=='''Participants'''==<br />
* Andrei Leontiev<br />
* Steve Nichols<br />
* Wim Corbijn<br />
* Kinson Ho<br />
* Kevin O'Donnell<br />
* Antje Schroeder<br />
* Ben Larson<br />
* Eric Martin<br />
<br />
RSNA Staff: TeRhonda McGee, Jamie Dulkowski<br />
<br />
{{TOCright}}<br />
==='''Reference Documents'''===<br />
* [https://drive.google.com/drive/folders/1p4c2bMYFWz7RWi_5AwRnxuNMHDI40A8h?usp=sharing Rad Tech 2023 Google Folder]<br />
: '''Integrated Reporting Applications'''<br />
:* [https://build.fhir.org/ig/IHE/RAD.RTC-IMR/index.html Supplement Draft]<br />
:* [[Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed|Reporting Content Communication - Proposal]]<br />
: '''Reporting Worklist Prioritization'''<br />
:* [https://drive.google.com/drive/folders/1hgtzMWUu6fEjP_hv0FykpGcdSyXm7-jU?usp=share_link Supplement Drafts]<br />
:* [[Reporting Worklist Prioritization - Proposal]]<br />
:* [https://docs.google.com/spreadsheets/d/13mhkRDDDv-JZaT-W4CCO-C0gmBtgP9-3YT1ADnJTVTY/edit?usp=sharing Table of Factors]<br />
:* [https://www.jacr.org/article/S1546-1440(13)00840-5/pdf 2014 ACR Actionable Finding Categories Paper]<br />
* [https://docs.google.com/spreadsheets/d/1IoRwFz1xxORCwYIJat-Yn2trfkhiT5OKbU8toEpKb5k/edit?usp=sharing 2022-23 Breakdown of Tasks]<br />
* [https://docs.google.com/spreadsheets/d/1ano3hPPOqKC9jJyussJ58JIAma-_Qu9JKfr3OCpOoc8/edit#gid=1412282829 Public Comments Form]<br />
<br />
All times are US Central Time.<br />
<br />
=='''Monday, April 24, 2023'''==<br />
:*A1: 8:45am-9:00am Administrative Time <br />
:**Introductions (Name and IHE Member Organization)<br />
:**[https://docs.google.com/spreadsheets/d/198eCuMJcsMEWwtahidRLcMYzzIrte48CI7kuHbkpY-4/edit?usp=sharing IHE Radiology Technical Committee Roster]<br />
:**[https://www.ihe.net/about_ihe/member_organizations/ IHE International Member Organizations]<br />
:**[https://www.ihe.net/about_ihe/patent_disclosure_process/ IHE Patent Disclosure Statement]<br />
:**[https://docs.google.com/spreadsheets/d/10eE1Hh4czrPc7ntuom_sOQbIH621eRkIe8agXRB4D5U/edit?usp=sharing Current Patent Disclosure Statements]<br />
:*S1: 9:00am-10:30am: Prioritization of Worklists for Reporting (POWR) [1.5hr]<br />
:*S2: 10:45am-12:15pm: Maintenance [1.5hr]<br />
:**Link to [https://docs.google.com/spreadsheets/d/1TmSwnn4AIiXqFLc_AtzP0dNd9LUWnA-ZcCjBMKpLzp4/edit#gid=0 RAD CP Tracking sheet]<br />
:**Link to [https://docs.google.com/spreadsheets/d/1f7Y7ImugFbcyon709ewthFprMVbvPmAtuSlQrtMp3dE/edit?usp=sharing Assessment of RAD TI Supplements]<br />
:** <b>Top Ten: </b><br />
:*** CP-RAD-257 Clearly add Admitting Diagnosis to SWF for REM and TCE <br />
:*** CP-RAD-293 Extended CT Dose Reporting (SSDE and Dose Check Logs)<br />
:*** CP-RAD-349 Add close and logout to IID<br />
:*** CP-RAD-364 Clarify IID<br />
:*** CP-RAD-423 Add specificity to IOCM<br />
:*** CP-RAD-475 Extensions to RAD-107 for IMR<br />
:*** CP-RAD-486 Update RAD-108 Message Semantics<br />
:*** CP-RAD-372 REM-NM<br />
:*** CP-RAD-501 WIA – RAD-129 fix in Expected Actions<br />
:*** CP-RAD-517 NMI Cardiac Option - update to include support of PS<br />
:** <b>Other active CPs: </b><br />
:** CP-RAD-460-LB - XCA-I Clarify IIG behavior in the local community<br />
:*** -- Finalize the CP after two ballots<br />
:** CP-RAD-305-02 - Revise profile dependencies (grouping) in Vol 1)<br />
:*** -- cmte input needed* CP-RAD-347-01 - XDS-I Vol 1 clean-up<br />
:** CP-RAD-343-01 - Consistency in specification of PID segment & references to MPI<br />
:*** -- a few points for cmte discussion<br />
:** CP-RAD-368-01 - Update/Remove MIMA Referenced in Vol 1 TF (editorial)<br />
:*** -- ready for cmte review; could be ready for ballot<br />
:** CP-RAD-436-02 - Fix inconsistencies in IOCM actor / transaction and grouping requirements<br />
:*** -- cmte input needed<br />
:** CP-RAD-410-03 - XCA-I is out of date for Async<br />
:** CP-RAD-492-01 - Update SNM3 and SRT codes in Vol 2<br />
:** CP-RAD-491-01 - Code Mapping WP update<br />
:** CP-RAD-490-01 - Update Vol 1x to remove retired transport for Submit Dose Information [RAD-63]<br />
<br />
'''All CPs approved'''<br />
<br />
:*S3: 1:15pm-4:15pm: Integrated Reporting Applications (IRA) [3hr]<br />
:** 2:00pm-3:00pm: ITI Committee - Github Governance call [for those who are interested]<br />
:*S4: 4:15pm-5:00pm: Editorial Session (as needed)<br />
<br />
=='''Tuesday, April 25, 2023'''==<br />
:*A1: 8:45am-9:00am Administrative Time<br />
:**Introductions (Name and IHE Member Organization)<br />
:**[https://docs.google.com/spreadsheets/d/198eCuMJcsMEWwtahidRLcMYzzIrte48CI7kuHbkpY-4/edit?usp=sharing IHE Radiology Technical Committee Roster]<br />
:**[https://www.ihe.net/about_ihe/member_organizations/ IHE International Member Organizations]<br />
:**[https://www.ihe.net/about_ihe/patent_disclosure_process/ IHE Patent Disclosure]<br />
:*S1: 9:00am-11:00am: Integrated Reporting Applications (IRA) [5hr]<br />
:*S2: 11:15am-12:45pm: Prioritization of Worklists for Reporting (POWR) [3hr]<br />
:*A2: 1:15pm-1:45pm: Administrative Time<br />
:** Framework Republication Plan [Lynn]<br />
:*S3: 1:45pm-3:45pm: Integrated Reporting Applications (IRA)[7hr]<br />
:*S4: 4:00-5:00pm: Editorial Session (as needed)<br />
:*Dinner at 6:30pm @Wildfire - 232 Oak Brook Center<br />
<br />
=='''Wednesday, April 26, 2023'''==<br />
:*A1: 8:45am-9:00am Administrative Time<br />
:**Introductions (Name and IHE Member Organization)<br />
:**[https://docs.google.com/spreadsheets/d/198eCuMJcsMEWwtahidRLcMYzzIrte48CI7kuHbkpY-4/edit?usp=sharing IHE Radiology Technical Committee Roster]<br />
:**[https://www.ihe.net/about_ihe/member_organizations/ IHE International Member Organizations]<br />
:**IHE Patent Disclosure<br />
:*S1: 9:00am-10:30am: Prioritization of Worklists for Reporting (POWR) [4.5hr]<br />
:*S2: 10:45am-12:45pm: Integrated Reporting Applications (IRA) (RBC-IMR)[9hr]<br />
:*A2: 1:15pm-1:45pm: Administrative Time<br />
:*S3: 1:45pm-3:45pm: Integrated Reporting Applications (IRA) (RBC-IMR)[11hr]<br />
:*S4: 4:00-5:00pm: Editorial Session (as needed)<br />
<br />
=='''Thursday, April 27, 2022'''==<br />
:*A1: 8:45am-9:00am Administrative Time<br />
:**Introductions (Name and IHE Member Organization)<br />
:**[https://docs.google.com/spreadsheets/d/198eCuMJcsMEWwtahidRLcMYzzIrte48CI7kuHbkpY-4/edit?usp=sharing IHE Radiology Technical Committee Roster]<br />
:**[https://www.ihe.net/about_ihe/member_organizations/ IHE International Member Organizations]<br />
:**IHE Patent Disclosure<br />
:*S1: 9:00am-10:30am: Integrated Reporting Applications (IRA)[13.5hr]<br />
:*S2: 10:45am-12:15pm: Maintenance [3hr]<br />
:*S3: 1:15pm-4:15pm: Prioritization of Worklists for Reporting (POWR) [6.5hr]<br />
:*S4: 4:15-5:00pm Editorial Session (as needed)<br />
<br />
=='''Friday, April 28, 2023'''==<br />
:*A1: 8:30am-9:00am Administrative Time<br />
:**Introductions (Name and IHE Member Organization)<br />
:**[https://docs.google.com/spreadsheets/d/198eCuMJcsMEWwtahidRLcMYzzIrte48CI7kuHbkpY-4/edit?usp=sharing IHE Radiology Technical Committee Roster]<br />
:**[https://www.ihe.net/about_ihe/member_organizations/ IHE International Member Organizations]<br />
:**IHE Patent Disclosure<br />
:*S1: 9:00am-11:00am Integrated Reporting Applications (IRA)[15.5hr]<br />
:*S2: 11:00-12:00: Admin - Checkpoint assessments<br />
<br />
===TI-Prep Closing Assessments===<br />
<br />
====Prioritization of Worklists for Reporting (POWR)====<br />
* Did we line-by-line the entire document<br />
:<br />
* How ready is it to go out for TI: Completely, Almost, Soonish, Hmmm<br />
:<br />
* How did the work fit in the allocated bandwidth? (Time to spare? Just right? Things were left undone?)<br />
:<br />
* Review the evaluation. Which complexity/uncertainty/effort points missed the mark?<br />
:<br />
* Or alternatively, estimate how many points you went over and assign the overage effort/complexity/uncertainty to the appropriate points.<br />
:<br />
* Are all the open issues closed?<br />
:<br />
* What significant debates in TI-prep were not anticipated in the Kickoff or PC-Prep<br />
:<br />
* Did the Breakdown of Tasks accurately reflect the work? What extra tasks arose?<br />
:<br />
* What residual risks are worth noting<br />
:<br />
* Does it feel we've met all the use cases<br />
:<br />
* Did the promised resources manifest<br />
:<br />
* What vendors are engaged (for each actor)<br />
:<br />
* Who should specifically be targeted for TI notification (implementors & advocates)<br />
:<br />
* When will we have sample data/objects<br />
:<br />
* Was the profile where it needed to be at the start of the TI meeting, if not what was the gap<br />
:<br />
* Was the profile where it needed to be at the end of the TI meeting, if not what was the gap<br />
:<br />
* Do you need any tcons between now and TI Publication<br />
:<br />
<br />
====Integrated Reporting Applications (IRA)====<br />
* Did we line-by-line the entire document<br />
:<br />
* How ready is it to go out for TI: Completely, Almost, Soonish, Hmmm<br />
:<br />
* How did the work fit in the allocated bandwidth? (Time to spare? Just right? Things were left undone?)<br />
:<br />
* Review the evaluation. Which complexity/uncertainty/effort points missed the mark?<br />
:<br />
* Or alternatively, estimate how many points you went over and assign the overage effort/complexity/uncertainty to the appropriate points.<br />
:<br />
* Are all the open issues closed?<br />
:<br />
* What significant debates in TI-prep were not anticipated in the Kickoff or PC-Prep<br />
:<br />
* Did the Breakdown of Tasks accurately reflect the work? What extra tasks arose?<br />
:<br />
* What residual risks are worth noting<br />
:<br />
* Does it feel we've met all the use cases<br />
:<br />
* Did the promised resources manifest<br />
:<br />
* What vendors are engaged (for each actor)<br />
:<br />
* Who should specifically be targeted for TI notification (implementors & advocates)<br />
:<br />
* When will we have sample data/objects<br />
:<br />
* Was the profile where it needed to be at the start of the TI meeting, if not what was the gap<br />
:<br />
* Was the profile where it needed to be at the end of the TI meeting, if not what was the gap<br />
:<br />
* Do you need any tcons between now and TI Publication<br />
:</div>Khohttp://wiki.ihe.net/index.php?title=Rad_Tech_Agenda_2023-02-06-10&diff=129486Rad Tech Agenda 2023-02-06-102023-02-07T16:37:59Z<p>Kho: /* Reference Documents */</p>
<hr />
<div>==='''Reference Documents'''===<br />
* [https://drive.google.com/drive/folders/1p4c2bMYFWz7RWi_5AwRnxuNMHDI40A8h?usp=sharing Rad Tech 2023 Google Folder]<br />
: '''Integrated Reporting Applications'''<br />
:* <link to draft materials><br />
:* [[Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed|Reporting Content Communication - Proposal]]<br />
:* [https://build.fhir.org/ig/IHE/RAD.RTC-IMR/index.html Supplement Draft]<br />
: '''Reporting Worklist Prioritization'''<br />
:* [https://drive.google.com/drive/folders/1hgtzMWUu6fEjP_hv0FykpGcdSyXm7-jU?usp=share_link Supplement Drafts]<br />
:* [[Reporting Worklist Prioritization - Proposal]]<br />
:* [https://docs.google.com/spreadsheets/d/13mhkRDDDv-JZaT-W4CCO-C0gmBtgP9-3YT1ADnJTVTY/edit?usp=sharing Table of Factors]<br />
:* [https://www.jacr.org/article/S1546-1440(13)00840-5/pdf 2014 ACR Actionable Finding Categories Paper]<br />
* [https://docs.google.com/spreadsheets/d/1IoRwFz1xxORCwYIJat-Yn2trfkhiT5OKbU8toEpKb5k/edit?usp=sharing 2022-23 Breakdown of Tasks]<br />
<br />
All times are US Central Time.<br />
<br />
=='''Monday, February 06, 2022'''==<br />
:*A1: 8:45am-9:00am Administrative Time <br />
:**Introductions (Name and IHE Member Organization)<br />
:**[https://docs.google.com/spreadsheets/d/198eCuMJcsMEWwtahidRLcMYzzIrte48CI7kuHbkpY-4/edit?usp=sharing IHE Radiology Technical Committee Roster]<br />
:**[https://www.ihe.net/about_ihe/member_organizations/ IHE International Member Organizations]<br />
:**[https://www.ihe.net/about_ihe/patent_disclosure_process/ IHE Patent Disclosure Statement]<br />
:**[https://docs.google.com/spreadsheets/d/10eE1Hh4czrPc7ntuom_sOQbIH621eRkIe8agXRB4D5U/edit?usp=sharing Current Patent Disclosure Statements]<br />
:*S1: 9:00am-10:30am: Reporting Worklist Prioritization (RWP) [1.5hr]<br />
:*S2: 10:45am-12:15pm: Maintenance [1.5hr]<br />
:**Link to [https://docs.google.com/spreadsheets/d/1TmSwnn4AIiXqFLc_AtzP0dNd9LUWnA-ZcCjBMKpLzp4/edit#gid=0 RAD CP Tracking sheet]<br />
:**Link to [https://docs.google.com/spreadsheets/d/1f7Y7ImugFbcyon709ewthFprMVbvPmAtuSlQrtMp3dE/edit?usp=sharing Assessment of RAD TI Supplements]<br />
:** <b>Top Ten: </b><br />
:*** CP-RAD-257 Clearly add Admitting Diagnosis to SWF for REM and TCE <br />
:*** CP-RAD-293 Extended CT Dose Reporting (SSDE and Dose Check Logs)<br />
:*** CP-RAD-349 Add close and logout to IID<br />
:*** CP-RAD-364 Clarify IID<br />
:*** CP-RAD-423 Add specificity to IOCM<br />
:*** CP-RAD-475 Extensions to RAD-107 for IMR<br />
:*** CP-RAD-486 Update RAD-108 Message Semantics<br />
:*** CP-RAD-501 WIA – RAD-129 fix in Expected Actions<br />
:** <b>Other active CPs: </b><br />
:** CP-RAD-460-LB - XCA-I Clarify IIG behavior in the local community<br />
:*** -- Finalize the CP after two ballots<br />
:** CP-RAD-305-02 - Revise profile dependencies (grouping) in Vol 1)<br />
:*** -- cmte input needed* CP-RAD-347-01 - XDS-I Vol 1 clean-up<br />
:** CP-RAD-343-01 - Consistency in specification of PID segment & references to MPI<br />
:*** -- a few points for cmte discussion<br />
:** CP-RAD-368-01 - Update/Remove MIMA Referenced in Vol 1 TF (editorial)<br />
:*** -- ready for cmte review; could be ready for ballot<br />
:** CP-RAD-436-02 - Fix inconsistencies in IOCM actor / transaction and grouping requirements<br />
:*** -- cmte input needed<br />
:** CP-RAD-410-03 - XCA-I is out of date for Async<br />
:** CP-RAD-492-01 - Update SNM3 and SRT codes in Vol 2<br />
:** CP-RAD-491-01 - Code Mapping WP update<br />
:** CP-RAD-490-01 - Update Vol 1x to remove retired transport for Submit Dose Information [RAD-63]<br />
<br />
:*S3: 1:15pm-4:15pm: Realtime Bidirectional Communication for Interactive Multimedia Reporting (RBC-IMR) [3hr]<br />
:** 2:00pm-3:00pm: ITI Committee - Github Governance call [for those who are interested]<br />
:*S4: 4:15pm-5:00pm: Editorial Session (as needed) <br />
<br />
<br />
=='''Tuesday, February 07, 2022'''==<br />
:*A1: 8:45am-9:00am Administrative Time<br />
:**Introductions (Name and IHE Member Organization)<br />
:**[https://docs.google.com/spreadsheets/d/198eCuMJcsMEWwtahidRLcMYzzIrte48CI7kuHbkpY-4/edit?usp=sharing IHE Radiology Technical Committee Roster]<br />
:**[https://www.ihe.net/about_ihe/member_organizations/ IHE International Member Organizations]<br />
:**[https://www.ihe.net/about_ihe/patent_disclosure_process/ IHE Patent Disclosure]<br />
:*S1: 9:00am-10:30am: Reporting Worklist Prioritization (RWP)[3hr]<br />
:*S2: 10:45am-12:45pm: Realtime Bidirectional Communication for Interactive Multimedia Reporting (RBC-IMR) [5hr]<br />
:*A2: 1:15pm-1:45pm: Administrative Time<br />
:** Radiology at European Connect-a-thon [Lynn]<br />
:*S3: 1:45pm-3:45pm: Realtime Bidirectional Communication for Interactive Multimedia Reporting (RBC-IMR)[7hr]<br />
:*S4: 4:00-5:00pm: Editorial Session (as needed)<br />
:*Dinner at 6:30pm @Wildfire - 232 Oak Brook Center<br />
<br />
=='''Wednesday, February 8, 2022'''==<br />
:*A1: 8:45am-9:00am Administrative Time<br />
:**Introductions (Name and IHE Member Organization)<br />
:**[https://docs.google.com/spreadsheets/d/198eCuMJcsMEWwtahidRLcMYzzIrte48CI7kuHbkpY-4/edit?usp=sharing IHE Radiology Technical Committee Roster]<br />
:**[https://www.ihe.net/about_ihe/member_organizations/ IHE International Member Organizations]<br />
:**IHE Patent Disclosure<br />
:*S1: 9:00am-10:30am: Reporting Worklist Prioritization (RWP)[4.5hr]<br />
:*S2: 10:45am-12:45pm: Realtime Bidirectional Communication for Interactive Multimedia Reporting (RBC-IMR)[9hr]<br />
:*A2: 1:15pm-1:45pm: Administrative Time<br />
:*S3: 1:45pm-3:45pm: Realtime Bidirectional Communication for Interactive Multimedia Reporting (RBC-IMR)[11hr]<br />
:*S4: 4:00-5:00pm: Editorial Session (as needed)<br />
<br />
=='''Thursday, February 9, 2022'''==<br />
:*A1: 8:45am-9:00am Administrative Time<br />
:**Introductions (Name and IHE Member Organization)<br />
:**[https://docs.google.com/spreadsheets/d/198eCuMJcsMEWwtahidRLcMYzzIrte48CI7kuHbkpY-4/edit?usp=sharing IHE Radiology Technical Committee Roster]<br />
:**[https://www.ihe.net/about_ihe/member_organizations/ IHE International Member Organizations]<br />
:**IHE Patent Disclosure<br />
:*S1: 9:00am-10:30am: Realtime Bidirectional Communication for Interactive Multimedia Reporting (RBC-IMR)[13.5hr]<br />
:*S2: 10:45am-12:15pm: Maintenance [3hr]<br />
:*S3: 1:15pm-4:15pm: Reporting Worklist Prioritization (RWP) Checklist [6.5hr]<br />
:*S4: 4:15-5:00pm Editorial Session (as needed)<br />
<br />
=='''Friday, February 10, 2022'''==<br />
:*A1: 8:30am-9:00am Administrative Time<br />
:**Introductions (Name and IHE Member Organization)<br />
:**[https://docs.google.com/spreadsheets/d/198eCuMJcsMEWwtahidRLcMYzzIrte48CI7kuHbkpY-4/edit?usp=sharing IHE Radiology Technical Committee Roster]<br />
:**[https://www.ihe.net/about_ihe/member_organizations/ IHE International Member Organizations]<br />
:**IHE Patent Disclosure<br />
:*S1: 9:00am-10:30am: Realtime Bidirectional Communication for Interactive Multimedia Reporting (RBC-IMR)[15hr]<br />
:*S2: 10:45am-11:45: Maintenance: Preparing the new Ballot 2023A [4hr]<br />
:*S3: 12:00-2:00pm: Realtime Bidirectional Communication for Interactive Multimedia Reporting (RBC-IMR)[8hr]</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication_for_Interactive_Multimedia_Reporting_-_Detailed&diff=129007Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed2022-09-29T15:40:53Z<p>Kho: /* 8. Tech Cmte Evaluation */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication for Interactive Multimedia Reporting==<br />
<br />
* Proposal Editor: Kinson Ho, David Vining, Peter O'Toole, Seth Berkowitz, David Kwan<br />
* Editor: Kinson Ho<br />
* Domain: Radiology<br />
<br />
===Summary===<br />
Standardized realtime bidirectional communication protocols do not exist to allow for rapid information flow between systems in order to support advanced use cases in the healthcare enterprise.<br />
<br />
FHIRcast is an emerging standard that facilitates a general publication / subscription messaging mechanism. It defines the messaging protocol as well as the message payload.<br />
<br />
With realtime bidirectional communication, data and/or commands can be conveyed between system to facilitate advanced integration. For example, an Interactive Multimedia Reporting (IMR) extension might require an Image Display to convey measurements made in realtime to a Report Creator so that measurements can be automatically displayed in context while a medical report is being generated.<br />
<br />
HIMSS/SIIM published a [https://link.springer.com/article/10.1007/s10278-022-00658-z whitepaper] regarding the importance of IMR and a critical component was identified as being realtime bidirectional communication. HIMSS/SIIM IMR workgroup participants from multiple disciplines expressed strong interest pursuing this aim.<br />
<br />
Several proprietary methods for point-to-point integration exist, but a standardized method for bidirectional communication is a fundamental unmet need that would be optimally orchestrated by the IHE. Creating a standards-based mechanism will promote interoperability and accelerate adoption of more advanced integrated workflows.<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with the use of multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to enable advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve the workflow efficiency of radiologists and promote patient safety by eliminating human transfer of data by manual or speech means that is time consuming and susceptible to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
within a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
generates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* Reporting System (Report Creator)<br />
* AI Manager (Evidence Creator)<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
==5. Technical Approach==<br />
<br />
===Actors===<br />
New Actors:<br />
* Data Publisher<br />
* Data Subscriber<br />
* Data Hub<br />
<br />
These are actors that provide the messaging mechanism. These actors are meant to be grouped with other actors that provides the message content.<br />
<br />
Existing actors:<br />
<br />
*For the IMR use case<br />
** Report Creator is the Data Subscriber<br />
** Image Display / Evidence Creator is the Data Publisher<br />
<br />
===Transactions===<br />
<br />
New transactions:<br />
* [RAD-X1] Subscribe Event - FHIRcast<br />
* [RAD-X2] Publish Event - FHIRcast<br />
* [RAD-X3] Notify Event - FHIRcast<br />
* [RAD-X4] Unsubscribe Event - FHIRcast<br />
<br />
Content Modules:<br />
* IMR Measurements and image references - FHIR Observation<br />
<br />
Out of Scope<br />
* [RAD-X5] Launch Application - OAuth2 / SMART on FHIR<br />
<br />
===Profile===<br />
<br />
* New profile for RTBC-IMR<br />
<br />
Note that once RAD-X1 through RAD-X5 are defined, new message payload can be defined to accommodate other use cases such as IID context switching.<br />
<br />
===Decisions/Topics/Uncertainties===<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is the optimal venue because realtime bidirectional communication is a common unmet need and currently there are only proprietary methods for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at recent FHIR Connectathons, and there is a growing rate of adoption for new applications (e.g. one major reporting vendor is already using FHIRcast as its new API integrating with PACS).<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to the use cases highlighted above.<br />
<br />
* (Out of Scope) Adopting FHIRcast and SMART on FHIR enables new secure application integration and communication beyond traditional DICOM and HL7.<br />
<br />
* (Out of Scope) FHIRcast recommends SMART on FHIR as a method to convey the topic from the App Launcher to the Application. This should be an optional method as not all integrations leverage SMART on FHIR or OAuth2.<br />
<br />
=== Task Breakdowns ===<br />
* Describe the use case for realtime bidirectional communication in the context of reporting between the PACS and Reporting System<br />
* Define the new transactions<br />
* Define the message content (e.g. using FHIR Observation) for IMR use case<br />
<br />
Note: This profile can be done using either the traditional Word document or the FHIR IG Publisher. FHIRcast definition is not directly supported by the IG Publisher, thus the majority of the specification will be composed in regular text.<br />
<br />
==6. Support & Resources==<br />
<br />
HIMSS / SIIM IMR workgroup has been an ardent supporter of the IMR profile and this extension. Many of the active participants (e.g. David Vining and Peter O'Toole) are interested in helping the development of the profile, from the clinical expert perspective as well as vendor / implementation perspective.<br />
<br />
==7. Risks==<br />
* HL7 FHIR is also developing a new SMART Web Messaging protocol which is aiming at browser applications. However, this is less mature than FHIRcast and is limited to browser applications.<br />
<br />
* Realtime Bidirectional Communication is a cross-cutting concern that has broad applications. One may argue that it is better to have a profile in the ITI domain first and then Radiology can adopt it by defining content modules. The counter-argument is that the need in Radiology is current with many rapid data exchange integration use cases exist in imaging.<br />
<br />
==8. Tech Cmte Evaluation==<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* 40% for MUE<br />
:* 50% for MUE + optional<br />
<br />
Editor:<br />
: Kinson Ho<br />
<br />
SME/Champion:<br />
:* David Vining (MD Anderson / VisionSR)<br />
:* Peter O'Toole (mTuitive)<br />
:* Seth Berkowitz, MD (BIDMC)</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication_for_Interactive_Multimedia_Reporting_-_Detailed&diff=129006Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed2022-09-29T15:40:20Z<p>Kho: /* 8. Tech Cmte Evaluation */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication for Interactive Multimedia Reporting==<br />
<br />
* Proposal Editor: Kinson Ho, David Vining, Peter O'Toole, Seth Berkowitz, David Kwan<br />
* Editor: Kinson Ho<br />
* Domain: Radiology<br />
<br />
===Summary===<br />
Standardized realtime bidirectional communication protocols do not exist to allow for rapid information flow between systems in order to support advanced use cases in the healthcare enterprise.<br />
<br />
FHIRcast is an emerging standard that facilitates a general publication / subscription messaging mechanism. It defines the messaging protocol as well as the message payload.<br />
<br />
With realtime bidirectional communication, data and/or commands can be conveyed between system to facilitate advanced integration. For example, an Interactive Multimedia Reporting (IMR) extension might require an Image Display to convey measurements made in realtime to a Report Creator so that measurements can be automatically displayed in context while a medical report is being generated.<br />
<br />
HIMSS/SIIM published a [https://link.springer.com/article/10.1007/s10278-022-00658-z whitepaper] regarding the importance of IMR and a critical component was identified as being realtime bidirectional communication. HIMSS/SIIM IMR workgroup participants from multiple disciplines expressed strong interest pursuing this aim.<br />
<br />
Several proprietary methods for point-to-point integration exist, but a standardized method for bidirectional communication is a fundamental unmet need that would be optimally orchestrated by the IHE. Creating a standards-based mechanism will promote interoperability and accelerate adoption of more advanced integrated workflows.<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with the use of multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to enable advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve the workflow efficiency of radiologists and promote patient safety by eliminating human transfer of data by manual or speech means that is time consuming and susceptible to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
within a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
generates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* Reporting System (Report Creator)<br />
* AI Manager (Evidence Creator)<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
==5. Technical Approach==<br />
<br />
===Actors===<br />
New Actors:<br />
* Data Publisher<br />
* Data Subscriber<br />
* Data Hub<br />
<br />
These are actors that provide the messaging mechanism. These actors are meant to be grouped with other actors that provides the message content.<br />
<br />
Existing actors:<br />
<br />
*For the IMR use case<br />
** Report Creator is the Data Subscriber<br />
** Image Display / Evidence Creator is the Data Publisher<br />
<br />
===Transactions===<br />
<br />
New transactions:<br />
* [RAD-X1] Subscribe Event - FHIRcast<br />
* [RAD-X2] Publish Event - FHIRcast<br />
* [RAD-X3] Notify Event - FHIRcast<br />
* [RAD-X4] Unsubscribe Event - FHIRcast<br />
<br />
Content Modules:<br />
* IMR Measurements and image references - FHIR Observation<br />
<br />
Out of Scope<br />
* [RAD-X5] Launch Application - OAuth2 / SMART on FHIR<br />
<br />
===Profile===<br />
<br />
* New profile for RTBC-IMR<br />
<br />
Note that once RAD-X1 through RAD-X5 are defined, new message payload can be defined to accommodate other use cases such as IID context switching.<br />
<br />
===Decisions/Topics/Uncertainties===<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is the optimal venue because realtime bidirectional communication is a common unmet need and currently there are only proprietary methods for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at recent FHIR Connectathons, and there is a growing rate of adoption for new applications (e.g. one major reporting vendor is already using FHIRcast as its new API integrating with PACS).<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to the use cases highlighted above.<br />
<br />
* (Out of Scope) Adopting FHIRcast and SMART on FHIR enables new secure application integration and communication beyond traditional DICOM and HL7.<br />
<br />
* (Out of Scope) FHIRcast recommends SMART on FHIR as a method to convey the topic from the App Launcher to the Application. This should be an optional method as not all integrations leverage SMART on FHIR or OAuth2.<br />
<br />
=== Task Breakdowns ===<br />
* Describe the use case for realtime bidirectional communication in the context of reporting between the PACS and Reporting System<br />
* Define the new transactions<br />
* Define the message content (e.g. using FHIR Observation) for IMR use case<br />
<br />
Note: This profile can be done using either the traditional Word document or the FHIR IG Publisher. FHIRcast definition is not directly supported by the IG Publisher, thus the majority of the specification will be composed in regular text.<br />
<br />
==6. Support & Resources==<br />
<br />
HIMSS / SIIM IMR workgroup has been an ardent supporter of the IMR profile and this extension. Many of the active participants (e.g. David Vining and Peter O'Toole) are interested in helping the development of the profile, from the clinical expert perspective as well as vendor / implementation perspective.<br />
<br />
==7. Risks==<br />
* HL7 FHIR is also developing a new SMART Web Messaging protocol which is aiming at browser applications. However, this is less mature than FHIRcast and is limited to browser applications.<br />
<br />
* Realtime Bidirectional Communication is a cross-cutting concern that has broad applications. One may argue that it is better to have a profile in the ITI domain first and then Radiology can adopt it by defining content modules. The counter-argument is that the need in Radiology is current with many rapid data exchange integration use cases exist in imaging.<br />
<br />
==8. Tech Cmte Evaluation==<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* 40% for MUE<br />
:* 50% for MUE + optional<br />
<br />
Editor:<br />
: Kinson Ho<br />
<br />
SME/Champion:<br />
:* David Vining (MD Anderson / VisionSR)<br />
:* Peter O'Toole (mIntuitive)<br />
:* Seth Berkowitz, MD (BIDMC)</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication_for_Interactive_Multimedia_Reporting_-_Detailed&diff=128955Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed2022-09-26T13:44:28Z<p>Kho: /* 8. Tech Cmte Evaluation */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication for Interactive Multimedia Reporting==<br />
<br />
* Proposal Editor: Kinson Ho, David Vining, Peter O'Toole, Seth Berkowitz, David Kwan<br />
* Editor: Kinson Ho<br />
* Domain: Radiology<br />
<br />
===Summary===<br />
Standardized realtime bidirectional communication protocols do not exist to allow for rapid information flow between systems in order to support advanced use cases in the healthcare enterprise.<br />
<br />
FHIRcast is an emerging standard that facilitates a general publication / subscription messaging mechanism. It defines the messaging protocol as well as the message payload.<br />
<br />
With realtime bidirectional communication, data and/or commands can be conveyed between system to facilitate advanced integration. For example, an Interactive Multimedia Reporting (IMR) extension might require an Image Display to convey measurements made in realtime to a Report Creator so that measurements can be automatically displayed in context while a medical report is being generated.<br />
<br />
HIMSS/SIIM published a [https://link.springer.com/article/10.1007/s10278-022-00658-z whitepaper] regarding the importance of IMR and a critical component was identified as being realtime bidirectional communication. HIMSS/SIIM IMR workgroup participants from multiple disciplines expressed strong interest pursuing this aim.<br />
<br />
Several proprietary methods for point-to-point integration exist, but a standardized method for bidirectional communication is a fundamental unmet need that would be optimally orchestrated by the IHE. Creating a standards-based mechanism will promote interoperability and accelerate adoption of more advanced integrated workflows.<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with the use of multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to enable advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve the workflow efficiency of radiologists and promote patient safety by eliminating human transfer of data by manual or speech means that is time consuming and susceptible to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
within a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
generates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* Reporting System (Report Creator)<br />
* AI Manager (Evidence Creator)<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
==5. Technical Approach==<br />
<br />
===Actors===<br />
New Actors:<br />
* Data Publisher<br />
* Data Subscriber<br />
* Data Hub<br />
<br />
These are actors that provide the messaging mechanism. These actors are meant to be grouped with other actors that provides the message content.<br />
<br />
Existing actors:<br />
<br />
*For the IMR use case<br />
** Report Creator is the Data Subscriber<br />
** Image Display / Evidence Creator is the Data Publisher<br />
<br />
===Transactions===<br />
<br />
New transactions:<br />
* [RAD-X1] Subscribe Event - FHIRcast<br />
* [RAD-X2] Publish Event - FHIRcast<br />
* [RAD-X3] Notify Event - FHIRcast<br />
* [RAD-X4] Unsubscribe Event - FHIRcast<br />
<br />
Content Modules:<br />
* IMR Measurements and image references - FHIR Observation<br />
<br />
Out of Scope<br />
* [RAD-X5] Launch Application - OAuth2 / SMART on FHIR<br />
<br />
===Profile===<br />
<br />
* New profile for RTBC-IMR<br />
<br />
Note that once RAD-X1 through RAD-X5 are defined, new message payload can be defined to accommodate other use cases such as IID context switching.<br />
<br />
===Decisions/Topics/Uncertainties===<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is the optimal venue because realtime bidirectional communication is a common unmet need and currently there are only proprietary methods for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at recent FHIR Connectathons, and there is a growing rate of adoption for new applications (e.g. one major reporting vendor is already using FHIRcast as its new API integrating with PACS).<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to the use cases highlighted above.<br />
<br />
* (Out of Scope) Adopting FHIRcast and SMART on FHIR enables new secure application integration and communication beyond traditional DICOM and HL7.<br />
<br />
* (Out of Scope) FHIRcast recommends SMART on FHIR as a method to convey the topic from the App Launcher to the Application. This should be an optional method as not all integrations leverage SMART on FHIR or OAuth2.<br />
<br />
=== Task Breakdowns ===<br />
* Describe the use case for realtime bidirectional communication in the context of reporting between the PACS and Reporting System<br />
* Define the new transactions<br />
* Define the message content (e.g. using FHIR Observation) for IMR use case<br />
<br />
Note: This profile can be done using either the traditional Word document or the FHIR IG Publisher. FHIRcast definition is not directly supported by the IG Publisher, thus the majority of the specification will be composed in regular text.<br />
<br />
==6. Support & Resources==<br />
<br />
HIMSS / SIIM IMR workgroup has been an ardent supporter of the IMR profile and this extension. Many of the active participants (e.g. David Vining and Peter O'Toole) are interested in helping the development of the profile, from the clinical expert perspective as well as vendor / implementation perspective.<br />
<br />
==7. Risks==<br />
* HL7 FHIR is also developing a new SMART Web Messaging protocol which is aiming at browser applications. However, this is less mature than FHIRcast and is limited to browser applications.<br />
<br />
* Realtime Bidirectional Communication is a cross-cutting concern that has broad applications. One may argue that it is better to have a profile in the ITI domain first and then Radiology can adopt it by defining content modules. The counter-argument is that the need in Radiology is current with many rapid data exchange integration use cases exist in imaging.<br />
<br />
==8. Tech Cmte Evaluation==<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* 40% for MUE<br />
:* 50% for MUE + optional<br />
<br />
Editor:<br />
: Kinson Ho<br />
<br />
SME/Champion:<br />
:* David Vining (MD Anderson / VisionSR)<br />
:* Peter O'Toole (mIntuition)<br />
:* Seth Berkowitz, MD (BIDMC)</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication_for_Interactive_Multimedia_Reporting_-_Detailed&diff=128954Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed2022-09-26T13:43:53Z<p>Kho: /* 5. Technical Approach */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication for Interactive Multimedia Reporting==<br />
<br />
* Proposal Editor: Kinson Ho, David Vining, Peter O'Toole, Seth Berkowitz, David Kwan<br />
* Editor: Kinson Ho<br />
* Domain: Radiology<br />
<br />
===Summary===<br />
Standardized realtime bidirectional communication protocols do not exist to allow for rapid information flow between systems in order to support advanced use cases in the healthcare enterprise.<br />
<br />
FHIRcast is an emerging standard that facilitates a general publication / subscription messaging mechanism. It defines the messaging protocol as well as the message payload.<br />
<br />
With realtime bidirectional communication, data and/or commands can be conveyed between system to facilitate advanced integration. For example, an Interactive Multimedia Reporting (IMR) extension might require an Image Display to convey measurements made in realtime to a Report Creator so that measurements can be automatically displayed in context while a medical report is being generated.<br />
<br />
HIMSS/SIIM published a [https://link.springer.com/article/10.1007/s10278-022-00658-z whitepaper] regarding the importance of IMR and a critical component was identified as being realtime bidirectional communication. HIMSS/SIIM IMR workgroup participants from multiple disciplines expressed strong interest pursuing this aim.<br />
<br />
Several proprietary methods for point-to-point integration exist, but a standardized method for bidirectional communication is a fundamental unmet need that would be optimally orchestrated by the IHE. Creating a standards-based mechanism will promote interoperability and accelerate adoption of more advanced integrated workflows.<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with the use of multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to enable advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve the workflow efficiency of radiologists and promote patient safety by eliminating human transfer of data by manual or speech means that is time consuming and susceptible to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
within a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
generates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* Reporting System (Report Creator)<br />
* AI Manager (Evidence Creator)<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
==5. Technical Approach==<br />
<br />
===Actors===<br />
New Actors:<br />
* Data Publisher<br />
* Data Subscriber<br />
* Data Hub<br />
<br />
These are actors that provide the messaging mechanism. These actors are meant to be grouped with other actors that provides the message content.<br />
<br />
Existing actors:<br />
<br />
*For the IMR use case<br />
** Report Creator is the Data Subscriber<br />
** Image Display / Evidence Creator is the Data Publisher<br />
<br />
===Transactions===<br />
<br />
New transactions:<br />
* [RAD-X1] Subscribe Event - FHIRcast<br />
* [RAD-X2] Publish Event - FHIRcast<br />
* [RAD-X3] Notify Event - FHIRcast<br />
* [RAD-X4] Unsubscribe Event - FHIRcast<br />
<br />
Content Modules:<br />
* IMR Measurements and image references - FHIR Observation<br />
<br />
Out of Scope<br />
* [RAD-X5] Launch Application - OAuth2 / SMART on FHIR<br />
<br />
===Profile===<br />
<br />
* New profile for RTBC-IMR<br />
<br />
Note that once RAD-X1 through RAD-X5 are defined, new message payload can be defined to accommodate other use cases such as IID context switching.<br />
<br />
===Decisions/Topics/Uncertainties===<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is the optimal venue because realtime bidirectional communication is a common unmet need and currently there are only proprietary methods for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at recent FHIR Connectathons, and there is a growing rate of adoption for new applications (e.g. one major reporting vendor is already using FHIRcast as its new API integrating with PACS).<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to the use cases highlighted above.<br />
<br />
* (Out of Scope) Adopting FHIRcast and SMART on FHIR enables new secure application integration and communication beyond traditional DICOM and HL7.<br />
<br />
* (Out of Scope) FHIRcast recommends SMART on FHIR as a method to convey the topic from the App Launcher to the Application. This should be an optional method as not all integrations leverage SMART on FHIR or OAuth2.<br />
<br />
=== Task Breakdowns ===<br />
* Describe the use case for realtime bidirectional communication in the context of reporting between the PACS and Reporting System<br />
* Define the new transactions<br />
* Define the message content (e.g. using FHIR Observation) for IMR use case<br />
<br />
Note: This profile can be done using either the traditional Word document or the FHIR IG Publisher. FHIRcast definition is not directly supported by the IG Publisher, thus the majority of the specification will be composed in regular text.<br />
<br />
==6. Support & Resources==<br />
<br />
HIMSS / SIIM IMR workgroup has been an ardent supporter of the IMR profile and this extension. Many of the active participants (e.g. David Vining and Peter O'Toole) are interested in helping the development of the profile, from the clinical expert perspective as well as vendor / implementation perspective.<br />
<br />
==7. Risks==<br />
* HL7 FHIR is also developing a new SMART Web Messaging protocol which is aiming at browser applications. However, this is less mature than FHIRcast and is limited to browser applications.<br />
<br />
* Realtime Bidirectional Communication is a cross-cutting concern that has broad applications. One may argue that it is better to have a profile in the ITI domain first and then Radiology can adopt it by defining content modules. The counter-argument is that the need in Radiology is current with many rapid data exchange integration use cases exist in imaging.<br />
<br />
==8. Tech Cmte Evaluation==<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% for MUE<br />
:* yy% for MUE + optional<br />
<br />
Editor:<br />
: Kinson Ho<br />
<br />
SME/Champion:<br />
:* David Vining (MD Anderson / VisionSR)<br />
:* Peter O'Toole (mIntuition)<br />
:* Seth Berkowitz, MD (BIDMC)</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication_for_Interactive_Multimedia_Reporting_-_Detailed&diff=128787Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed2022-08-24T19:56:02Z<p>Kho: /* 7. Risks */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication for Interactive Multimedia Reporting==<br />
<br />
* Proposal Editor: Kinson Ho, David Vining, Peter O'Toole, Seth Berkowitz, David Kwan<br />
* Editor: Kinson Ho<br />
* Domain: Radiology<br />
<br />
===Summary===<br />
Standardized realtime bidirectional communication protocols do not exist to allow for rapid information flow between systems in order to support advanced use cases in the healthcare enterprise.<br />
<br />
FHIRcast is an emerging standard that facilitates a general publication / subscription messaging mechanism. It defines the messaging protocol as well as the message payload.<br />
<br />
With realtime bidirectional communication, data and/or commands can be conveyed between system to facilitate advanced integration. For example, an Interactive Multimedia Reporting (IMR) extension might require an Image Display to convey measurements made in realtime to a Report Creator so that measurements can be automatically displayed in context while a medical report is being generated.<br />
<br />
HIMSS/SIIM published a [https://link.springer.com/article/10.1007/s10278-022-00658-z whitepaper] regarding the importance of IMR and a critical component was identified as being realtime bidirectional communication. HIMSS/SIIM IMR workgroup participants from multiple disciplines expressed strong interest pursuing this aim.<br />
<br />
Several proprietary methods for point-to-point integration exist, but a standardized method for bidirectional communication is a fundamental unmet need that would be optimally orchestrated by the IHE. Creating a standards-based mechanism will promote interoperability and accelerate adoption of more advanced integrated workflows.<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with the use of multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to enable advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve the workflow efficiency of radiologists and promote patient safety by eliminating human transfer of data by manual or speech means that is time consuming and susceptible to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
within a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
generates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* Reporting System (Report Creator)<br />
* AI Manager (Evidence Creator)<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
==5. Technical Approach==<br />
<br />
===Actors===<br />
New Actors:<br />
* Data Publisher<br />
* Data Subscriber<br />
* Data Hub<br />
<br />
These are actors that provide the messaging mechanism. These actors are meant to be grouped with other actors that provides the message content.<br />
<br />
Existing actors:<br />
<br />
*For the IMR use case<br />
** Report Creator is the Data Subscriber<br />
** Image Display / Evidence Creator is the Data Publisher<br />
<br />
===Transactions===<br />
<br />
New transactions:<br />
* [RAD-X1] Subscribe Event - FHIRcast<br />
* [RAD-X2] Publish Event - FHIRcast<br />
* [RAD-X3] Notify Event - FHIRcast<br />
* [RAD-X4] Unsubscribe Event - FHIRcast<br />
* [RAD-X5] Launch Application - OAuth2 / SMART on FHIR<br />
<br />
Content Modules:<br />
* IMR Measurements and image references - FHIR Observation<br />
<br />
===Profile===<br />
<br />
* New profile for RTBC-IMR<br />
<br />
Note that once RAD-X1 through RAD-X5 are defined, new message payload can be defined to accommodate other use cases such as IID context switching.<br />
<br />
===Decisions/Topics/Uncertainties===<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is the optimal venue because realtime bidirectional communication is a common unmet need and currently there are only proprietary methods for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at recent FHIR Connectathons, and there is a growing rate of adoption for new applications (e.g. one major reporting vendor is already using FHIRcast as its new API integrating with PACS).<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to the use cases highlighted above.<br />
<br />
* Adopting FHIRcast and SMART on FHIR enables new secure application integration and communication beyond traditional DICOM and HL7.<br />
<br />
* FHIRcast recommends SMART on FHIR as a method to convey the topic from the App Launcher to the Application. This should be an optional method as not all integrations leverage SMART on FHIR or OAuth2.<br />
<br />
=== Task Breakdowns ===<br />
* Extend the existing IMR use cases to accommodate RTBC-IMR steps<br />
* Define the new transactions<br />
* Define the message content (e.g. using FHIR Observation) for IMR use case<br />
<br />
Note: This profile can be done using either the traditional Word document or the FHIR IG Publisher. FHIRcast definition is not directly supported by the IG Publisher, thus the majority of the specification will be composed in regular text.<br />
<br />
==6. Support & Resources==<br />
<br />
HIMSS / SIIM IMR workgroup has been an ardent supporter of the IMR profile and this extension. Many of the active participants (e.g. David Vining and Peter O'Toole) are interested in helping the development of the profile, from the clinical expert perspective as well as vendor / implementation perspective.<br />
<br />
==7. Risks==<br />
* HL7 FHIR is also developing a new SMART Web Messaging protocol which is aiming at browser applications. However, this is less mature than FHIRcast and is limited to browser applications.<br />
<br />
* Realtime Bidirectional Communication is a cross-cutting concern that has broad applications. One may argue that it is better to have a profile in the ITI domain first and then Radiology can adopt it by defining content modules. The counter-argument is that the need in Radiology is current with many rapid data exchange integration use cases exist in imaging.<br />
<br />
==8. Tech Cmte Evaluation==<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% for MUE<br />
:* yy% for MUE + optional<br />
<br />
Editor:<br />
: Kinson Ho<br />
<br />
SME/Champion:<br />
:* David Vining (MD Anderson / VisionSR)<br />
:* Peter O'Toole (mIntuition)<br />
:* Seth Berkowitz, MD (BIDMC)</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication_for_Interactive_Multimedia_Reporting_-_Detailed&diff=128786Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed2022-08-24T19:54:02Z<p>Kho: /* 6. Support & Resources */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication for Interactive Multimedia Reporting==<br />
<br />
* Proposal Editor: Kinson Ho, David Vining, Peter O'Toole, Seth Berkowitz, David Kwan<br />
* Editor: Kinson Ho<br />
* Domain: Radiology<br />
<br />
===Summary===<br />
Standardized realtime bidirectional communication protocols do not exist to allow for rapid information flow between systems in order to support advanced use cases in the healthcare enterprise.<br />
<br />
FHIRcast is an emerging standard that facilitates a general publication / subscription messaging mechanism. It defines the messaging protocol as well as the message payload.<br />
<br />
With realtime bidirectional communication, data and/or commands can be conveyed between system to facilitate advanced integration. For example, an Interactive Multimedia Reporting (IMR) extension might require an Image Display to convey measurements made in realtime to a Report Creator so that measurements can be automatically displayed in context while a medical report is being generated.<br />
<br />
HIMSS/SIIM published a [https://link.springer.com/article/10.1007/s10278-022-00658-z whitepaper] regarding the importance of IMR and a critical component was identified as being realtime bidirectional communication. HIMSS/SIIM IMR workgroup participants from multiple disciplines expressed strong interest pursuing this aim.<br />
<br />
Several proprietary methods for point-to-point integration exist, but a standardized method for bidirectional communication is a fundamental unmet need that would be optimally orchestrated by the IHE. Creating a standards-based mechanism will promote interoperability and accelerate adoption of more advanced integrated workflows.<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with the use of multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to enable advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve the workflow efficiency of radiologists and promote patient safety by eliminating human transfer of data by manual or speech means that is time consuming and susceptible to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
within a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
generates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* Reporting System (Report Creator)<br />
* AI Manager (Evidence Creator)<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
==5. Technical Approach==<br />
<br />
===Actors===<br />
New Actors:<br />
* Data Publisher<br />
* Data Subscriber<br />
* Data Hub<br />
<br />
These are actors that provide the messaging mechanism. These actors are meant to be grouped with other actors that provides the message content.<br />
<br />
Existing actors:<br />
<br />
*For the IMR use case<br />
** Report Creator is the Data Subscriber<br />
** Image Display / Evidence Creator is the Data Publisher<br />
<br />
===Transactions===<br />
<br />
New transactions:<br />
* [RAD-X1] Subscribe Event - FHIRcast<br />
* [RAD-X2] Publish Event - FHIRcast<br />
* [RAD-X3] Notify Event - FHIRcast<br />
* [RAD-X4] Unsubscribe Event - FHIRcast<br />
* [RAD-X5] Launch Application - OAuth2 / SMART on FHIR<br />
<br />
Content Modules:<br />
* IMR Measurements and image references - FHIR Observation<br />
<br />
===Profile===<br />
<br />
* New profile for RTBC-IMR<br />
<br />
Note that once RAD-X1 through RAD-X5 are defined, new message payload can be defined to accommodate other use cases such as IID context switching.<br />
<br />
===Decisions/Topics/Uncertainties===<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is the optimal venue because realtime bidirectional communication is a common unmet need and currently there are only proprietary methods for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at recent FHIR Connectathons, and there is a growing rate of adoption for new applications (e.g. one major reporting vendor is already using FHIRcast as its new API integrating with PACS).<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to the use cases highlighted above.<br />
<br />
* Adopting FHIRcast and SMART on FHIR enables new secure application integration and communication beyond traditional DICOM and HL7.<br />
<br />
* FHIRcast recommends SMART on FHIR as a method to convey the topic from the App Launcher to the Application. This should be an optional method as not all integrations leverage SMART on FHIR or OAuth2.<br />
<br />
=== Task Breakdowns ===<br />
* Extend the existing IMR use cases to accommodate RTBC-IMR steps<br />
* Define the new transactions<br />
* Define the message content (e.g. using FHIR Observation) for IMR use case<br />
<br />
Note: This profile can be done using either the traditional Word document or the FHIR IG Publisher. FHIRcast definition is not directly supported by the IG Publisher, thus the majority of the specification will be composed in regular text.<br />
<br />
==6. Support & Resources==<br />
<br />
HIMSS / SIIM IMR workgroup has been an ardent supporter of the IMR profile and this extension. Many of the active participants (e.g. David Vining and Peter O'Toole) are interested in helping the development of the profile, from the clinical expert perspective as well as vendor / implementation perspective.<br />
<br />
==7. Risks==<br />
* HL7 FHIR is also developing a new SMART Web Messaging protocol which is aiming at browser applications. However, this is less mature than FHIRcast and it is more limited to browser applications.<br />
<br />
* Realtime Bidirectional Communication is a cross-cutting concern that has broader applicability. One may argue that it is better to be profiles in the ITI domain first and the Radiology can adopt it by defining the content modules. The counter-argument is that the need for Radiology is now and many of the rapid data exchange integration use cases exist in imaging.<br />
<br />
==8. Tech Cmte Evaluation==<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% for MUE<br />
:* yy% for MUE + optional<br />
<br />
Editor:<br />
: Kinson Ho<br />
<br />
SME/Champion:<br />
:* David Vining (MD Anderson / VisionSR)<br />
:* Peter O'Toole (mIntuition)<br />
:* Seth Berkowitz, MD (BIDMC)</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication_for_Interactive_Multimedia_Reporting_-_Detailed&diff=128785Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed2022-08-24T19:53:41Z<p>Kho: /* 5. Technical Approach */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication for Interactive Multimedia Reporting==<br />
<br />
* Proposal Editor: Kinson Ho, David Vining, Peter O'Toole, Seth Berkowitz, David Kwan<br />
* Editor: Kinson Ho<br />
* Domain: Radiology<br />
<br />
===Summary===<br />
Standardized realtime bidirectional communication protocols do not exist to allow for rapid information flow between systems in order to support advanced use cases in the healthcare enterprise.<br />
<br />
FHIRcast is an emerging standard that facilitates a general publication / subscription messaging mechanism. It defines the messaging protocol as well as the message payload.<br />
<br />
With realtime bidirectional communication, data and/or commands can be conveyed between system to facilitate advanced integration. For example, an Interactive Multimedia Reporting (IMR) extension might require an Image Display to convey measurements made in realtime to a Report Creator so that measurements can be automatically displayed in context while a medical report is being generated.<br />
<br />
HIMSS/SIIM published a [https://link.springer.com/article/10.1007/s10278-022-00658-z whitepaper] regarding the importance of IMR and a critical component was identified as being realtime bidirectional communication. HIMSS/SIIM IMR workgroup participants from multiple disciplines expressed strong interest pursuing this aim.<br />
<br />
Several proprietary methods for point-to-point integration exist, but a standardized method for bidirectional communication is a fundamental unmet need that would be optimally orchestrated by the IHE. Creating a standards-based mechanism will promote interoperability and accelerate adoption of more advanced integrated workflows.<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with the use of multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to enable advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve the workflow efficiency of radiologists and promote patient safety by eliminating human transfer of data by manual or speech means that is time consuming and susceptible to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
within a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
generates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* Reporting System (Report Creator)<br />
* AI Manager (Evidence Creator)<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
==5. Technical Approach==<br />
<br />
===Actors===<br />
New Actors:<br />
* Data Publisher<br />
* Data Subscriber<br />
* Data Hub<br />
<br />
These are actors that provide the messaging mechanism. These actors are meant to be grouped with other actors that provides the message content.<br />
<br />
Existing actors:<br />
<br />
*For the IMR use case<br />
** Report Creator is the Data Subscriber<br />
** Image Display / Evidence Creator is the Data Publisher<br />
<br />
===Transactions===<br />
<br />
New transactions:<br />
* [RAD-X1] Subscribe Event - FHIRcast<br />
* [RAD-X2] Publish Event - FHIRcast<br />
* [RAD-X3] Notify Event - FHIRcast<br />
* [RAD-X4] Unsubscribe Event - FHIRcast<br />
* [RAD-X5] Launch Application - OAuth2 / SMART on FHIR<br />
<br />
Content Modules:<br />
* IMR Measurements and image references - FHIR Observation<br />
<br />
===Profile===<br />
<br />
* New profile for RTBC-IMR<br />
<br />
Note that once RAD-X1 through RAD-X5 are defined, new message payload can be defined to accommodate other use cases such as IID context switching.<br />
<br />
===Decisions/Topics/Uncertainties===<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is the optimal venue because realtime bidirectional communication is a common unmet need and currently there are only proprietary methods for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at recent FHIR Connectathons, and there is a growing rate of adoption for new applications (e.g. one major reporting vendor is already using FHIRcast as its new API integrating with PACS).<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to the use cases highlighted above.<br />
<br />
* Adopting FHIRcast and SMART on FHIR enables new secure application integration and communication beyond traditional DICOM and HL7.<br />
<br />
* FHIRcast recommends SMART on FHIR as a method to convey the topic from the App Launcher to the Application. This should be an optional method as not all integrations leverage SMART on FHIR or OAuth2.<br />
<br />
=== Task Breakdowns ===<br />
* Extend the existing IMR use cases to accommodate RTBC-IMR steps<br />
* Define the new transactions<br />
* Define the message content (e.g. using FHIR Observation) for IMR use case<br />
<br />
Note: This profile can be done using either the traditional Word document or the FHIR IG Publisher. FHIRcast definition is not directly supported by the IG Publisher, thus the majority of the specification will be composed in regular text.<br />
<br />
==6. Support & Resources==<br />
<br />
HIMSS / SIIM IMR workgroup has been a great supporter of the IMR profile and this extension. Many of the active participants (e.g. David Vining and Peter O'Toole) are interested in helping the development of the profile, from the clinical expert perspective as well as vendor / implementation perspective.<br />
<br />
==7. Risks==<br />
* HL7 FHIR is also developing a new SMART Web Messaging protocol which is aiming at browser applications. However, this is less mature than FHIRcast and it is more limited to browser applications.<br />
<br />
* Realtime Bidirectional Communication is a cross-cutting concern that has broader applicability. One may argue that it is better to be profiles in the ITI domain first and the Radiology can adopt it by defining the content modules. The counter-argument is that the need for Radiology is now and many of the rapid data exchange integration use cases exist in imaging.<br />
<br />
==8. Tech Cmte Evaluation==<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% for MUE<br />
:* yy% for MUE + optional<br />
<br />
Editor:<br />
: Kinson Ho<br />
<br />
SME/Champion:<br />
:* David Vining (MD Anderson / VisionSR)<br />
:* Peter O'Toole (mIntuition)<br />
:* Seth Berkowitz, MD (BIDMC)</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication_for_Interactive_Multimedia_Reporting_-_Detailed&diff=128784Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed2022-08-24T19:38:46Z<p>Kho: /* 3. Key Use Case */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication for Interactive Multimedia Reporting==<br />
<br />
* Proposal Editor: Kinson Ho, David Vining, Peter O'Toole, Seth Berkowitz, David Kwan<br />
* Editor: Kinson Ho<br />
* Domain: Radiology<br />
<br />
===Summary===<br />
Standardized realtime bidirectional communication protocols do not exist to allow for rapid information flow between systems in order to support advanced use cases in the healthcare enterprise.<br />
<br />
FHIRcast is an emerging standard that facilitates a general publication / subscription messaging mechanism. It defines the messaging protocol as well as the message payload.<br />
<br />
With realtime bidirectional communication, data and/or commands can be conveyed between system to facilitate advanced integration. For example, an Interactive Multimedia Reporting (IMR) extension might require an Image Display to convey measurements made in realtime to a Report Creator so that measurements can be automatically displayed in context while a medical report is being generated.<br />
<br />
HIMSS/SIIM published a [https://link.springer.com/article/10.1007/s10278-022-00658-z whitepaper] regarding the importance of IMR and a critical component was identified as being realtime bidirectional communication. HIMSS/SIIM IMR workgroup participants from multiple disciplines expressed strong interest pursuing this aim.<br />
<br />
Several proprietary methods for point-to-point integration exist, but a standardized method for bidirectional communication is a fundamental unmet need that would be optimally orchestrated by the IHE. Creating a standards-based mechanism will promote interoperability and accelerate adoption of more advanced integrated workflows.<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with the use of multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to enable advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve the workflow efficiency of radiologists and promote patient safety by eliminating human transfer of data by manual or speech means that is time consuming and susceptible to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
within a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
generates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* Reporting System (Report Creator)<br />
* AI Manager (Evidence Creator)<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
==5. Technical Approach==<br />
<br />
===Actors===<br />
New Actors:<br />
* Data Publisher<br />
* Data Subscriber<br />
* Data Hub<br />
<br />
These are actors that provide the messaging mechanism. These actors are meant to be grouped with other actors that provides the message content.<br />
<br />
Existing actors:<br />
<br />
*For the IMR use case<br />
** Report Creator is the Data Subscriber<br />
** Image Display / Evidence Creator is the Data Publihser<br />
<br />
===Transactions===<br />
<br />
New transactions:<br />
* [RAD-X1] Subscribe Event - FHIRcast<br />
* [RAD-X2] Publish Event - FHIRcast<br />
* [RAD-X3] Notify Event - FHIRcast<br />
* [RAD-X4] Unsubscribe Event - FHIRcast<br />
* [RAD-X5] Launch Application - OAuth2 / SMART on FHIR<br />
<br />
Content Modules:<br />
* IMR Measurements and image references - FHIR Observation<br />
<br />
===Profile===<br />
<br />
* New profile for RTBC-IMR<br />
<br />
Note that once RAD-X1 to RAD-X5 are defined, new message payload can be defined to accommodate other use cases such as IID context switching.<br />
<br />
===Decisions/Topics/Uncertainties===<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at recent FHIR Connectathons, and there is a growing rate of adoption for new applications (e.g. one major reporting vendor is already using FHIRcast as its new API integrating with PACS).<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to the use cases highlighted above.<br />
<br />
* Adopting FHIRcast and SMART on FHIR enables new secure application integration and communication beyond traditional DICOM and HL7.<br />
<br />
* FHIRcast recommends SMART on FHIR as a method to convey the topic from the App Launcher to the Application. This should be an optional method as not all integrations leverages SMART on FHIR or OAuth2.<br />
<br />
=== Task Breakdowns ===<br />
* Extend the existing IMR use cases to accommodate RTBC-IMR steps<br />
* Define the new transactions<br />
* Define the message content (e.g. using FHIR Observation) for IMR use case<br />
<br />
Note: This profile can be done using either the traditional Word document or the FHIR IG Publisher. FHIRcast definition is not directly supported by the IG Publisher. So majority of the specification will be regular text.<br />
<br />
==6. Support & Resources==<br />
<br />
HIMSS / SIIM IMR workgroup has been a great supporter of the IMR profile and this extension. Many of the active participants (e.g. David Vining and Peter O'Toole) are interested in helping the development of the profile, from the clinical expert perspective as well as vendor / implementation perspective.<br />
<br />
==7. Risks==<br />
* HL7 FHIR is also developing a new SMART Web Messaging protocol which is aiming at browser applications. However, this is less mature than FHIRcast and it is more limited to browser applications.<br />
<br />
* Realtime Bidirectional Communication is a cross-cutting concern that has broader applicability. One may argue that it is better to be profiles in the ITI domain first and the Radiology can adopt it by defining the content modules. The counter-argument is that the need for Radiology is now and many of the rapid data exchange integration use cases exist in imaging.<br />
<br />
==8. Tech Cmte Evaluation==<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% for MUE<br />
:* yy% for MUE + optional<br />
<br />
Editor:<br />
: Kinson Ho<br />
<br />
SME/Champion:<br />
:* David Vining (MD Anderson / VisionSR)<br />
:* Peter O'Toole (mIntuition)<br />
:* Seth Berkowitz, MD (BIDMC)</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication_for_Interactive_Multimedia_Reporting_-_Detailed&diff=128783Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed2022-08-24T19:27:40Z<p>Kho: /* 2. The Problem */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication for Interactive Multimedia Reporting==<br />
<br />
* Proposal Editor: Kinson Ho, David Vining, Peter O'Toole, Seth Berkowitz, David Kwan<br />
* Editor: Kinson Ho<br />
* Domain: Radiology<br />
<br />
===Summary===<br />
Standardized realtime bidirectional communication protocols do not exist to allow for rapid information flow between systems in order to support advanced use cases in the healthcare enterprise.<br />
<br />
FHIRcast is an emerging standard that facilitates a general publication / subscription messaging mechanism. It defines the messaging protocol as well as the message payload.<br />
<br />
With realtime bidirectional communication, data and/or commands can be conveyed between system to facilitate advanced integration. For example, an Interactive Multimedia Reporting (IMR) extension might require an Image Display to convey measurements made in realtime to a Report Creator so that measurements can be automatically displayed in context while a medical report is being generated.<br />
<br />
HIMSS/SIIM published a [https://link.springer.com/article/10.1007/s10278-022-00658-z whitepaper] regarding the importance of IMR and a critical component was identified as being realtime bidirectional communication. HIMSS/SIIM IMR workgroup participants from multiple disciplines expressed strong interest pursuing this aim.<br />
<br />
Several proprietary methods for point-to-point integration exist, but a standardized method for bidirectional communication is a fundamental unmet need that would be optimally orchestrated by the IHE. Creating a standards-based mechanism will promote interoperability and accelerate adoption of more advanced integrated workflows.<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with the use of multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to enable advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve the workflow efficiency of radiologists and promote patient safety by eliminating human transfer of data by manual or speech means that is time consuming and susceptible to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create these<br />
DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
into a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are good resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
generates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* Reporting System (Report Creator)<br />
* AI Manager (Evidence Creator)<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
==5. Technical Approach==<br />
<br />
===Actors===<br />
New Actors:<br />
* Data Publisher<br />
* Data Subscriber<br />
* Data Hub<br />
<br />
These are actors that provide the messaging mechanism. These actors are meant to be grouped with other actors that provides the message content.<br />
<br />
Existing actors:<br />
<br />
*For the IMR use case<br />
** Report Creator is the Data Subscriber<br />
** Image Display / Evidence Creator is the Data Publihser<br />
<br />
===Transactions===<br />
<br />
New transactions:<br />
* [RAD-X1] Subscribe Event - FHIRcast<br />
* [RAD-X2] Publish Event - FHIRcast<br />
* [RAD-X3] Notify Event - FHIRcast<br />
* [RAD-X4] Unsubscribe Event - FHIRcast<br />
* [RAD-X5] Launch Application - OAuth2 / SMART on FHIR<br />
<br />
Content Modules:<br />
* IMR Measurements and image references - FHIR Observation<br />
<br />
===Profile===<br />
<br />
* New profile for RTBC-IMR<br />
<br />
Note that once RAD-X1 to RAD-X5 are defined, new message payload can be defined to accommodate other use cases such as IID context switching.<br />
<br />
===Decisions/Topics/Uncertainties===<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at recent FHIR Connectathons, and there is a growing rate of adoption for new applications (e.g. one major reporting vendor is already using FHIRcast as its new API integrating with PACS).<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to the use cases highlighted above.<br />
<br />
* Adopting FHIRcast and SMART on FHIR enables new secure application integration and communication beyond traditional DICOM and HL7.<br />
<br />
* FHIRcast recommends SMART on FHIR as a method to convey the topic from the App Launcher to the Application. This should be an optional method as not all integrations leverages SMART on FHIR or OAuth2.<br />
<br />
=== Task Breakdowns ===<br />
* Extend the existing IMR use cases to accommodate RTBC-IMR steps<br />
* Define the new transactions<br />
* Define the message content (e.g. using FHIR Observation) for IMR use case<br />
<br />
Note: This profile can be done using either the traditional Word document or the FHIR IG Publisher. FHIRcast definition is not directly supported by the IG Publisher. So majority of the specification will be regular text.<br />
<br />
==6. Support & Resources==<br />
<br />
HIMSS / SIIM IMR workgroup has been a great supporter of the IMR profile and this extension. Many of the active participants (e.g. David Vining and Peter O'Toole) are interested in helping the development of the profile, from the clinical expert perspective as well as vendor / implementation perspective.<br />
<br />
==7. Risks==<br />
* HL7 FHIR is also developing a new SMART Web Messaging protocol which is aiming at browser applications. However, this is less mature than FHIRcast and it is more limited to browser applications.<br />
<br />
* Realtime Bidirectional Communication is a cross-cutting concern that has broader applicability. One may argue that it is better to be profiles in the ITI domain first and the Radiology can adopt it by defining the content modules. The counter-argument is that the need for Radiology is now and many of the rapid data exchange integration use cases exist in imaging.<br />
<br />
==8. Tech Cmte Evaluation==<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% for MUE<br />
:* yy% for MUE + optional<br />
<br />
Editor:<br />
: Kinson Ho<br />
<br />
SME/Champion:<br />
:* David Vining (MD Anderson / VisionSR)<br />
:* Peter O'Toole (mIntuition)<br />
:* Seth Berkowitz, MD (BIDMC)</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication_for_Interactive_Multimedia_Reporting_-_Detailed&diff=128782Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed2022-08-24T19:24:42Z<p>Kho: /* Summary */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication for Interactive Multimedia Reporting==<br />
<br />
* Proposal Editor: Kinson Ho, David Vining, Peter O'Toole, Seth Berkowitz, David Kwan<br />
* Editor: Kinson Ho<br />
* Domain: Radiology<br />
<br />
===Summary===<br />
Standardized realtime bidirectional communication protocols do not exist to allow for rapid information flow between systems in order to support advanced use cases in the healthcare enterprise.<br />
<br />
FHIRcast is an emerging standard that facilitates a general publication / subscription messaging mechanism. It defines the messaging protocol as well as the message payload.<br />
<br />
With realtime bidirectional communication, data and/or commands can be conveyed between system to facilitate advanced integration. For example, an Interactive Multimedia Reporting (IMR) extension might require an Image Display to convey measurements made in realtime to a Report Creator so that measurements can be automatically displayed in context while a medical report is being generated.<br />
<br />
HIMSS/SIIM published a [https://link.springer.com/article/10.1007/s10278-022-00658-z whitepaper] regarding the importance of IMR and a critical component was identified as being realtime bidirectional communication. HIMSS/SIIM IMR workgroup participants from multiple disciplines expressed strong interest pursuing this aim.<br />
<br />
Several proprietary methods for point-to-point integration exist, but a standardized method for bidirectional communication is a fundamental unmet need that would be optimally orchestrated by the IHE. Creating a standards-based mechanism will promote interoperability and accelerate adoption of more advanced integrated workflows.<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to support advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve a radiologist's workflow efficiency and patient safety by eliminating human input of data (e.g. manual, dictation) that is time consuming and subject to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create these<br />
DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
into a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are good resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
generates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* Reporting System (Report Creator)<br />
* AI Manager (Evidence Creator)<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
==5. Technical Approach==<br />
<br />
===Actors===<br />
New Actors:<br />
* Data Publisher<br />
* Data Subscriber<br />
* Data Hub<br />
<br />
These are actors that provide the messaging mechanism. These actors are meant to be grouped with other actors that provides the message content.<br />
<br />
Existing actors:<br />
<br />
*For the IMR use case<br />
** Report Creator is the Data Subscriber<br />
** Image Display / Evidence Creator is the Data Publihser<br />
<br />
===Transactions===<br />
<br />
New transactions:<br />
* [RAD-X1] Subscribe Event - FHIRcast<br />
* [RAD-X2] Publish Event - FHIRcast<br />
* [RAD-X3] Notify Event - FHIRcast<br />
* [RAD-X4] Unsubscribe Event - FHIRcast<br />
* [RAD-X5] Launch Application - OAuth2 / SMART on FHIR<br />
<br />
Content Modules:<br />
* IMR Measurements and image references - FHIR Observation<br />
<br />
===Profile===<br />
<br />
* New profile for RTBC-IMR<br />
<br />
Note that once RAD-X1 to RAD-X5 are defined, new message payload can be defined to accommodate other use cases such as IID context switching.<br />
<br />
===Decisions/Topics/Uncertainties===<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at recent FHIR Connectathons, and there is a growing rate of adoption for new applications (e.g. one major reporting vendor is already using FHIRcast as its new API integrating with PACS).<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to the use cases highlighted above.<br />
<br />
* Adopting FHIRcast and SMART on FHIR enables new secure application integration and communication beyond traditional DICOM and HL7.<br />
<br />
* FHIRcast recommends SMART on FHIR as a method to convey the topic from the App Launcher to the Application. This should be an optional method as not all integrations leverages SMART on FHIR or OAuth2.<br />
<br />
=== Task Breakdowns ===<br />
* Extend the existing IMR use cases to accommodate RTBC-IMR steps<br />
* Define the new transactions<br />
* Define the message content (e.g. using FHIR Observation) for IMR use case<br />
<br />
Note: This profile can be done using either the traditional Word document or the FHIR IG Publisher. FHIRcast definition is not directly supported by the IG Publisher. So majority of the specification will be regular text.<br />
<br />
==6. Support & Resources==<br />
<br />
HIMSS / SIIM IMR workgroup has been a great supporter of the IMR profile and this extension. Many of the active participants (e.g. David Vining and Peter O'Toole) are interested in helping the development of the profile, from the clinical expert perspective as well as vendor / implementation perspective.<br />
<br />
==7. Risks==<br />
* HL7 FHIR is also developing a new SMART Web Messaging protocol which is aiming at browser applications. However, this is less mature than FHIRcast and it is more limited to browser applications.<br />
<br />
* Realtime Bidirectional Communication is a cross-cutting concern that has broader applicability. One may argue that it is better to be profiles in the ITI domain first and the Radiology can adopt it by defining the content modules. The counter-argument is that the need for Radiology is now and many of the rapid data exchange integration use cases exist in imaging.<br />
<br />
==8. Tech Cmte Evaluation==<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% for MUE<br />
:* yy% for MUE + optional<br />
<br />
Editor:<br />
: Kinson Ho<br />
<br />
SME/Champion:<br />
:* David Vining (MD Anderson / VisionSR)<br />
:* Peter O'Toole (mIntuition)<br />
:* Seth Berkowitz, MD (BIDMC)</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication_for_Interactive_Multimedia_Reporting_-_Detailed&diff=128776Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed2022-08-23T20:47:26Z<p>Kho: /* 1. Proposed Workitem: Realtime Bidirectional Communication for Interactive Multimedia Reporting */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication for Interactive Multimedia Reporting==<br />
<br />
* Proposal Editor: Kinson Ho, David Vining, Peter O'Toole, Seth Berkowitz, David Kwan<br />
* Editor: Kinson Ho<br />
* Domain: Radiology<br />
<br />
===Summary===<br />
In current practices, there is no standard realtime bidirectional communications between systems in a health enterprise to support advanced integrated use cases that require rapid information flow between systems.<br />
<br />
FHIRcast is an emerging standard that facilitates a general publication / subscription messaging mechanism. It defines the messaging protocol as well as the message payload.<br />
<br />
With such a realtime bidirectional communication method, data or commands can be conveyed between system to facilitate advanced integration. For example, an Interactive Multimedia Reporting extension could require compliant an Image Display to convey measurements in realtime to the Report Creator so that the measurements can be automatically displayed in context while dictation is proceeding.<br />
<br />
HIMSS/SIIM has published a [https://link.springer.com/article/10.1007/s10278-022-00658-z whitepaper] regarding the importance of IMR and part of the discussion is a need for such realtime bidirection communication. Many participants from the HIMSS/SIIM IMR workgroup are interested in this effort.<br />
<br />
IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration. Having a standard-based mechanism increases interoperability and can accelerate adoption of more advanced integrated workflows.<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to support advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve a radiologist's workflow efficiency and patient safety by eliminating human input of data (e.g. manual, dictation) that is time consuming and subject to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create these<br />
DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
into a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are good resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
generates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* Reporting System (Report Creator)<br />
* AI Manager (Evidence Creator)<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
==5. Technical Approach==<br />
<br />
===Actors===<br />
New Actors:<br />
* Data Publisher<br />
* Data Subscriber<br />
* Data Hub<br />
<br />
These are actors that provide the messaging mechanism. These actors are meant to be grouped with other actors that provides the message content.<br />
<br />
Existing actors:<br />
<br />
*For the IMR use case<br />
** Report Creator is the Data Subscriber<br />
** Image Display / Evidence Creator is the Data Publihser<br />
<br />
===Transactions===<br />
<br />
New transactions:<br />
* [RAD-X1] Subscribe Event - FHIRcast<br />
* [RAD-X2] Publish Event - FHIRcast<br />
* [RAD-X3] Notify Event - FHIRcast<br />
* [RAD-X4] Unsubscribe Event - FHIRcast<br />
* [RAD-X5] Launch Application - OAuth2 / SMART on FHIR<br />
<br />
Content Modules:<br />
* IMR Measurements and image references - FHIR Observation<br />
<br />
===Profile===<br />
<br />
* New profile for RTBC-IMR<br />
<br />
Note that once RAD-X1 to RAD-X5 are defined, new message payload can be defined to accommodate other use cases such as IID context switching.<br />
<br />
===Decisions/Topics/Uncertainties===<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at recent FHIR Connectathons, and there is a growing rate of adoption for new applications (e.g. one major reporting vendor is already using FHIRcast as its new API integrating with PACS).<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to the use cases highlighted above.<br />
<br />
* Adopting FHIRcast and SMART on FHIR enables new secure application integration and communication beyond traditional DICOM and HL7.<br />
<br />
* FHIRcast recommends SMART on FHIR as a method to convey the topic from the App Launcher to the Application. This should be an optional method as not all integrations leverages SMART on FHIR or OAuth2.<br />
<br />
=== Task Breakdowns ===<br />
* Extend the existing IMR use cases to accommodate RTBC-IMR steps<br />
* Define the new transactions<br />
* Define the message content (e.g. using FHIR Observation) for IMR use case<br />
<br />
Note: This profile can be done using either the traditional Word document or the FHIR IG Publisher. FHIRcast definition is not directly supported by the IG Publisher. So majority of the specification will be regular text.<br />
<br />
==6. Support & Resources==<br />
<br />
HIMSS / SIIM IMR workgroup has been a great supporter of the IMR profile and this extension. Many of the active participants (e.g. David Vining and Peter O'Toole) are interested in helping the development of the profile, from the clinical expert perspective as well as vendor / implementation perspective.<br />
<br />
==7. Risks==<br />
* HL7 FHIR is also developing a new SMART Web Messaging protocol which is aiming at browser applications. However, this is less mature than FHIRcast and it is more limited to browser applications.<br />
<br />
* Realtime Bidirectional Communication is a cross-cutting concern that has broader applicability. One may argue that it is better to be profiles in the ITI domain first and the Radiology can adopt it by defining the content modules. The counter-argument is that the need for Radiology is now and many of the rapid data exchange integration use cases exist in imaging.<br />
<br />
==8. Tech Cmte Evaluation==<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% for MUE<br />
:* yy% for MUE + optional<br />
<br />
Editor:<br />
: Kinson Ho<br />
<br />
SME/Champion:<br />
:* David Vining (MD Anderson / VisionSR)<br />
:* Peter O'Toole (mIntuition)<br />
:* Seth Berkowitz, MD (BIDMC)</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication_for_Interactive_Multimedia_Reporting_-_Detailed&diff=128775Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed2022-08-23T20:47:02Z<p>Kho: /* 8. Tech Cmte Evaluation */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication for Interactive Multimedia Reporting==<br />
<br />
* Proposal Editor: Kinson Ho, David Vining, Peter O'Toole, Seth Berkowitz<br />
* Editor: Kinson Ho<br />
* Domain: Radiology<br />
<br />
===Summary===<br />
In current practices, there is no standard realtime bidirectional communications between systems in a health enterprise to support advanced integrated use cases that require rapid information flow between systems.<br />
<br />
FHIRcast is an emerging standard that facilitates a general publication / subscription messaging mechanism. It defines the messaging protocol as well as the message payload.<br />
<br />
With such a realtime bidirectional communication method, data or commands can be conveyed between system to facilitate advanced integration. For example, an Interactive Multimedia Reporting extension could require compliant an Image Display to convey measurements in realtime to the Report Creator so that the measurements can be automatically displayed in context while dictation is proceeding.<br />
<br />
HIMSS/SIIM has published a [https://link.springer.com/article/10.1007/s10278-022-00658-z whitepaper] regarding the importance of IMR and part of the discussion is a need for such realtime bidirection communication. Many participants from the HIMSS/SIIM IMR workgroup are interested in this effort.<br />
<br />
IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration. Having a standard-based mechanism increases interoperability and can accelerate adoption of more advanced integrated workflows.<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to support advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve a radiologist's workflow efficiency and patient safety by eliminating human input of data (e.g. manual, dictation) that is time consuming and subject to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create these<br />
DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
into a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are good resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
generates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* Reporting System (Report Creator)<br />
* AI Manager (Evidence Creator)<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
==5. Technical Approach==<br />
<br />
===Actors===<br />
New Actors:<br />
* Data Publisher<br />
* Data Subscriber<br />
* Data Hub<br />
<br />
These are actors that provide the messaging mechanism. These actors are meant to be grouped with other actors that provides the message content.<br />
<br />
Existing actors:<br />
<br />
*For the IMR use case<br />
** Report Creator is the Data Subscriber<br />
** Image Display / Evidence Creator is the Data Publihser<br />
<br />
===Transactions===<br />
<br />
New transactions:<br />
* [RAD-X1] Subscribe Event - FHIRcast<br />
* [RAD-X2] Publish Event - FHIRcast<br />
* [RAD-X3] Notify Event - FHIRcast<br />
* [RAD-X4] Unsubscribe Event - FHIRcast<br />
* [RAD-X5] Launch Application - OAuth2 / SMART on FHIR<br />
<br />
Content Modules:<br />
* IMR Measurements and image references - FHIR Observation<br />
<br />
===Profile===<br />
<br />
* New profile for RTBC-IMR<br />
<br />
Note that once RAD-X1 to RAD-X5 are defined, new message payload can be defined to accommodate other use cases such as IID context switching.<br />
<br />
===Decisions/Topics/Uncertainties===<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at recent FHIR Connectathons, and there is a growing rate of adoption for new applications (e.g. one major reporting vendor is already using FHIRcast as its new API integrating with PACS).<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to the use cases highlighted above.<br />
<br />
* Adopting FHIRcast and SMART on FHIR enables new secure application integration and communication beyond traditional DICOM and HL7.<br />
<br />
* FHIRcast recommends SMART on FHIR as a method to convey the topic from the App Launcher to the Application. This should be an optional method as not all integrations leverages SMART on FHIR or OAuth2.<br />
<br />
=== Task Breakdowns ===<br />
* Extend the existing IMR use cases to accommodate RTBC-IMR steps<br />
* Define the new transactions<br />
* Define the message content (e.g. using FHIR Observation) for IMR use case<br />
<br />
Note: This profile can be done using either the traditional Word document or the FHIR IG Publisher. FHIRcast definition is not directly supported by the IG Publisher. So majority of the specification will be regular text.<br />
<br />
==6. Support & Resources==<br />
<br />
HIMSS / SIIM IMR workgroup has been a great supporter of the IMR profile and this extension. Many of the active participants (e.g. David Vining and Peter O'Toole) are interested in helping the development of the profile, from the clinical expert perspective as well as vendor / implementation perspective.<br />
<br />
==7. Risks==<br />
* HL7 FHIR is also developing a new SMART Web Messaging protocol which is aiming at browser applications. However, this is less mature than FHIRcast and it is more limited to browser applications.<br />
<br />
* Realtime Bidirectional Communication is a cross-cutting concern that has broader applicability. One may argue that it is better to be profiles in the ITI domain first and the Radiology can adopt it by defining the content modules. The counter-argument is that the need for Radiology is now and many of the rapid data exchange integration use cases exist in imaging.<br />
<br />
==8. Tech Cmte Evaluation==<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% for MUE<br />
:* yy% for MUE + optional<br />
<br />
Editor:<br />
: Kinson Ho<br />
<br />
SME/Champion:<br />
:* David Vining (MD Anderson / VisionSR)<br />
:* Peter O'Toole (mIntuition)<br />
:* Seth Berkowitz, MD (BIDMC)</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication_for_Interactive_Multimedia_Reporting_-_Detailed&diff=128774Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed2022-08-23T20:45:52Z<p>Kho: /* 1. Proposed Workitem: Realtime Bidirectional Communication for Interactive Multimedia Reporting */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication for Interactive Multimedia Reporting==<br />
<br />
* Proposal Editor: Kinson Ho, David Vining, Peter O'Toole, Seth Berkowitz<br />
* Editor: Kinson Ho<br />
* Domain: Radiology<br />
<br />
===Summary===<br />
In current practices, there is no standard realtime bidirectional communications between systems in a health enterprise to support advanced integrated use cases that require rapid information flow between systems.<br />
<br />
FHIRcast is an emerging standard that facilitates a general publication / subscription messaging mechanism. It defines the messaging protocol as well as the message payload.<br />
<br />
With such a realtime bidirectional communication method, data or commands can be conveyed between system to facilitate advanced integration. For example, an Interactive Multimedia Reporting extension could require compliant an Image Display to convey measurements in realtime to the Report Creator so that the measurements can be automatically displayed in context while dictation is proceeding.<br />
<br />
HIMSS/SIIM has published a [https://link.springer.com/article/10.1007/s10278-022-00658-z whitepaper] regarding the importance of IMR and part of the discussion is a need for such realtime bidirection communication. Many participants from the HIMSS/SIIM IMR workgroup are interested in this effort.<br />
<br />
IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration. Having a standard-based mechanism increases interoperability and can accelerate adoption of more advanced integrated workflows.<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to support advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve a radiologist's workflow efficiency and patient safety by eliminating human input of data (e.g. manual, dictation) that is time consuming and subject to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create these<br />
DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
into a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are good resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
generates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* Reporting System (Report Creator)<br />
* AI Manager (Evidence Creator)<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
==5. Technical Approach==<br />
<br />
===Actors===<br />
New Actors:<br />
* Data Publisher<br />
* Data Subscriber<br />
* Data Hub<br />
<br />
These are actors that provide the messaging mechanism. These actors are meant to be grouped with other actors that provides the message content.<br />
<br />
Existing actors:<br />
<br />
*For the IMR use case<br />
** Report Creator is the Data Subscriber<br />
** Image Display / Evidence Creator is the Data Publihser<br />
<br />
===Transactions===<br />
<br />
New transactions:<br />
* [RAD-X1] Subscribe Event - FHIRcast<br />
* [RAD-X2] Publish Event - FHIRcast<br />
* [RAD-X3] Notify Event - FHIRcast<br />
* [RAD-X4] Unsubscribe Event - FHIRcast<br />
* [RAD-X5] Launch Application - OAuth2 / SMART on FHIR<br />
<br />
Content Modules:<br />
* IMR Measurements and image references - FHIR Observation<br />
<br />
===Profile===<br />
<br />
* New profile for RTBC-IMR<br />
<br />
Note that once RAD-X1 to RAD-X5 are defined, new message payload can be defined to accommodate other use cases such as IID context switching.<br />
<br />
===Decisions/Topics/Uncertainties===<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at recent FHIR Connectathons, and there is a growing rate of adoption for new applications (e.g. one major reporting vendor is already using FHIRcast as its new API integrating with PACS).<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to the use cases highlighted above.<br />
<br />
* Adopting FHIRcast and SMART on FHIR enables new secure application integration and communication beyond traditional DICOM and HL7.<br />
<br />
* FHIRcast recommends SMART on FHIR as a method to convey the topic from the App Launcher to the Application. This should be an optional method as not all integrations leverages SMART on FHIR or OAuth2.<br />
<br />
=== Task Breakdowns ===<br />
* Extend the existing IMR use cases to accommodate RTBC-IMR steps<br />
* Define the new transactions<br />
* Define the message content (e.g. using FHIR Observation) for IMR use case<br />
<br />
Note: This profile can be done using either the traditional Word document or the FHIR IG Publisher. FHIRcast definition is not directly supported by the IG Publisher. So majority of the specification will be regular text.<br />
<br />
==6. Support & Resources==<br />
<br />
HIMSS / SIIM IMR workgroup has been a great supporter of the IMR profile and this extension. Many of the active participants (e.g. David Vining and Peter O'Toole) are interested in helping the development of the profile, from the clinical expert perspective as well as vendor / implementation perspective.<br />
<br />
==7. Risks==<br />
* HL7 FHIR is also developing a new SMART Web Messaging protocol which is aiming at browser applications. However, this is less mature than FHIRcast and it is more limited to browser applications.<br />
<br />
* Realtime Bidirectional Communication is a cross-cutting concern that has broader applicability. One may argue that it is better to be profiles in the ITI domain first and the Radiology can adopt it by defining the content modules. The counter-argument is that the need for Radiology is now and many of the rapid data exchange integration use cases exist in imaging.<br />
<br />
==8. Tech Cmte Evaluation==<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% for MUE<br />
:* yy% for MUE + optional<br />
<br />
Editor:<br />
: Kinson Ho<br />
<br />
SME/Champion:<br />
:* David Vining (MD Anderson / VisionSR)<br />
:* Peter O'Toole (mIntuition)</div>Khohttp://wiki.ihe.net/index.php?title=Radiology_Proposals_2022-2023&diff=128771Radiology Proposals 2022-20232022-08-23T17:50:12Z<p>Kho: /* Short List/ Detailed Proposals */</p>
<hr />
<div>{{TOCright}}<br />
<br />
===Final Selection===<br />
Final selection by the '''[[Rad_Plan_Minutes_2022-09-26|Planning Committee on Sept 26, 2022]]''' <br />
:* A. Maintenance (25%)<br />
<br />
===Effort Evaluations===<br />
The Technical Committee [[Proposal Effort Evaluation|evaluated the required effort]] of the Detailed Proposals as follows in tcons on [[Rad_Tech_Minutes_2022-08-29 | Aug 29]], [[Rad_Tech_Minutes_2022-08-31 | Aug 31]], & [[Rad_Tech_Minutes_2022-09-01 | Sept 1]].<br />
<br />
Assessments were captured in the new spreadsheet form. <br />
<br />
:* A. [[RAD TF Maintenance 2022-2023]]<br />
<br />
See [[Proposal Effort Evaluation#TC Review & Effort Estimation]] for evaluation guidance.<br />
<br />
===Short List/ Detailed Proposals===<br />
The Tech Cmte agreed to evaluate TBD number of proposals. The following Proposals were shortlisted by the [[Rad Plan Minutes 2022-08-10| Planning Committee on Aug 10, 2022]].<br />
<br />
:* A. Maintenance<br />
:* B. [[Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed]]<br />
<br />
'''Editors''': by COB '''Aug 24''', 2022<br />
* '''Complete the Breakdown of Tasks''' with a strawman estimate of story points:<br />
:* [https://docs.google.com/spreadsheets/d/1IoRwFz1xxORCwYIJat-Yn2trfkhiT5OKbU8toEpKb5k/edit?usp=sharing BoD & Estimation - Google Sheet (Tab for each proposal)]<br />
* '''Expand your Brief Proposal''' to include Detailed Proposal elements<br />
:* Copy the [[Delta Proposal Template]] into the bottom of your proposal page<br />
:* Update as described in the Delta Template (adds Summary, Technical Details, Evaluation, etc.)<br />
:* Breakdown of Tasks is now covered in the Google Sheet (above)<br />
* Your goal is to give sufficient detail for the Tech Cmte to be able to evaluate the technical feasibility, specification tasks and effort required.<br />
<br />
'''Reviewers''': Feel free to enter comments under Risks and Decisions/Topics/Uncertainties section of the proposal<br />
<br />
Tech Cmte evaluations will be recorded at the bottom of each detailed proposal. The "Breakdown of Tasks" and "Story Point" refinements to the '''[[Proposal Effort Evaluation]]''' are in the Google Sheet.<br />
<br />
===Brief Proposals===<br />
:* A. Maintenance<br />
:* B. [[Enhanced SOLE for AI]]<br />
:* C. [[SWF on FHIR]]<br />
:* D. [[Realtime Bidirectional Communication]]<br />
:* E. [https://docs.google.com/document/d/1DeFr0oB6ZA-SBAk2BSgZ_mjNtydQwULh/edit?usp=sharing&ouid=102612276002431976750&rtpof=true&sd=true Management of Sensitive Images (MOSI)] <br />
:* F. [[Reporting Worklist Prioritization - Proposal]]<br />
:* G. [[Imaging Diagnostic Report - Proposal]]<br />
<br />
Submission DEADLINE is '''August 5''', 2022, 11:59pm CT<br />
<br />
===Call for Proposals===<br />
Interested parties are invited to submit proposal pages based on the '''[[Brief Proposal Template]]'''.<br />
<br />
You are also welcome to update and resubmit proposals from '''[[Radiology Proposals 2021-2022|last year]]''' or earlier.<br />
<br />
Contact radiology@ihe.net with any questions.<br />
<br />
===Committee Links===<br />
<br />
[[Radiology Planning Committee]]<br />
<br />
[[Radiology Technical Committee]]</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication_-_Detailed&diff=128770Realtime Bidirectional Communication - Detailed2022-08-23T17:48:33Z<p>Kho: Kho moved page Realtime Bidirectional Communication - Detailed to Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed</p>
<hr />
<div>#REDIRECT [[Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed]]</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication_for_Interactive_Multimedia_Reporting_-_Detailed&diff=128769Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed2022-08-23T17:48:33Z<p>Kho: Kho moved page Realtime Bidirectional Communication - Detailed to Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication for Interactive Multimedia Reporting==<br />
<br />
* Proposal Editor: Kinson Ho, David Vining, Peter O'Toole<br />
* Editor: Kinson Ho<br />
* Domain: Radiology<br />
<br />
===Summary===<br />
In current practices, there is no standard realtime bidirectional communications between systems in a health enterprise to support advanced integrated use cases that require rapid information flow between systems.<br />
<br />
FHIRcast is an emerging standard that facilitates a general publication / subscription messaging mechanism. It defines the messaging protocol as well as the message payload.<br />
<br />
With such a realtime bidirectional communication method, data or commands can be conveyed between system to facilitate advanced integration. For example, an Interactive Multimedia Reporting extension could require compliant an Image Display to convey measurements in realtime to the Report Creator so that the measurements can be automatically displayed in context while dictation is proceeding.<br />
<br />
HIMSS/SIIM has published a [https://link.springer.com/article/10.1007/s10278-022-00658-z whitepaper] regarding the importance of IMR and part of the discussion is a need for such realtime bidirection communication. Many participants from the HIMSS/SIIM IMR workgroup are interested in this effort.<br />
<br />
IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration. Having a standard-based mechanism increases interoperability and can accelerate adoption of more advanced integrated workflows.<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to support advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve a radiologist's workflow efficiency and patient safety by eliminating human input of data (e.g. manual, dictation) that is time consuming and subject to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create these<br />
DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
into a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are good resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
generates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* Reporting System (Report Creator)<br />
* AI Manager (Evidence Creator)<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
==5. Technical Approach==<br />
<br />
===Actors===<br />
New Actors:<br />
* Data Publisher<br />
* Data Subscriber<br />
* Data Hub<br />
<br />
These are actors that provide the messaging mechanism. These actors are meant to be grouped with other actors that provides the message content.<br />
<br />
Existing actors:<br />
<br />
*For the IMR use case<br />
** Report Creator is the Data Subscriber<br />
** Image Display / Evidence Creator is the Data Publihser<br />
<br />
===Transactions===<br />
<br />
New transactions:<br />
* [RAD-X1] Subscribe Event - FHIRcast<br />
* [RAD-X2] Publish Event - FHIRcast<br />
* [RAD-X3] Notify Event - FHIRcast<br />
* [RAD-X4] Unsubscribe Event - FHIRcast<br />
* [RAD-X5] Launch Application - OAuth2 / SMART on FHIR<br />
<br />
Content Modules:<br />
* IMR Measurements and image references - FHIR Observation<br />
<br />
===Profile===<br />
<br />
* New profile for RTBC-IMR<br />
<br />
Note that once RAD-X1 to RAD-X5 are defined, new message payload can be defined to accommodate other use cases such as IID context switching.<br />
<br />
===Decisions/Topics/Uncertainties===<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at recent FHIR Connectathons, and there is a growing rate of adoption for new applications (e.g. one major reporting vendor is already using FHIRcast as its new API integrating with PACS).<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to the use cases highlighted above.<br />
<br />
* Adopting FHIRcast and SMART on FHIR enables new secure application integration and communication beyond traditional DICOM and HL7.<br />
<br />
* FHIRcast recommends SMART on FHIR as a method to convey the topic from the App Launcher to the Application. This should be an optional method as not all integrations leverages SMART on FHIR or OAuth2.<br />
<br />
=== Task Breakdowns ===<br />
* Extend the existing IMR use cases to accommodate RTBC-IMR steps<br />
* Define the new transactions<br />
* Define the message content (e.g. using FHIR Observation) for IMR use case<br />
<br />
Note: This profile can be done using either the traditional Word document or the FHIR IG Publisher. FHIRcast definition is not directly supported by the IG Publisher. So majority of the specification will be regular text.<br />
<br />
==6. Support & Resources==<br />
<br />
HIMSS / SIIM IMR workgroup has been a great supporter of the IMR profile and this extension. Many of the active participants (e.g. David Vining and Peter O'Toole) are interested in helping the development of the profile, from the clinical expert perspective as well as vendor / implementation perspective.<br />
<br />
==7. Risks==<br />
* HL7 FHIR is also developing a new SMART Web Messaging protocol which is aiming at browser applications. However, this is less mature than FHIRcast and it is more limited to browser applications.<br />
<br />
* Realtime Bidirectional Communication is a cross-cutting concern that has broader applicability. One may argue that it is better to be profiles in the ITI domain first and the Radiology can adopt it by defining the content modules. The counter-argument is that the need for Radiology is now and many of the rapid data exchange integration use cases exist in imaging.<br />
<br />
==8. Tech Cmte Evaluation==<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% for MUE<br />
:* yy% for MUE + optional<br />
<br />
Editor:<br />
: Kinson Ho<br />
<br />
SME/Champion:<br />
:* David Vining (MD Anderson / VisionSR)<br />
:* Peter O'Toole (mIntuition)</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication_for_Interactive_Multimedia_Reporting_-_Detailed&diff=128768Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed2022-08-23T17:47:39Z<p>Kho: /* 5. Technical Approach */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication for Interactive Multimedia Reporting==<br />
<br />
* Proposal Editor: Kinson Ho, David Vining, Peter O'Toole<br />
* Editor: Kinson Ho<br />
* Domain: Radiology<br />
<br />
===Summary===<br />
In current practices, there is no standard realtime bidirectional communications between systems in a health enterprise to support advanced integrated use cases that require rapid information flow between systems.<br />
<br />
FHIRcast is an emerging standard that facilitates a general publication / subscription messaging mechanism. It defines the messaging protocol as well as the message payload.<br />
<br />
With such a realtime bidirectional communication method, data or commands can be conveyed between system to facilitate advanced integration. For example, an Interactive Multimedia Reporting extension could require compliant an Image Display to convey measurements in realtime to the Report Creator so that the measurements can be automatically displayed in context while dictation is proceeding.<br />
<br />
HIMSS/SIIM has published a [https://link.springer.com/article/10.1007/s10278-022-00658-z whitepaper] regarding the importance of IMR and part of the discussion is a need for such realtime bidirection communication. Many participants from the HIMSS/SIIM IMR workgroup are interested in this effort.<br />
<br />
IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration. Having a standard-based mechanism increases interoperability and can accelerate adoption of more advanced integrated workflows.<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to support advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve a radiologist's workflow efficiency and patient safety by eliminating human input of data (e.g. manual, dictation) that is time consuming and subject to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create these<br />
DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
into a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are good resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
generates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* Reporting System (Report Creator)<br />
* AI Manager (Evidence Creator)<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
==5. Technical Approach==<br />
<br />
===Actors===<br />
New Actors:<br />
* Data Publisher<br />
* Data Subscriber<br />
* Data Hub<br />
<br />
These are actors that provide the messaging mechanism. These actors are meant to be grouped with other actors that provides the message content.<br />
<br />
Existing actors:<br />
<br />
*For the IMR use case<br />
** Report Creator is the Data Subscriber<br />
** Image Display / Evidence Creator is the Data Publihser<br />
<br />
===Transactions===<br />
<br />
New transactions:<br />
* [RAD-X1] Subscribe Event - FHIRcast<br />
* [RAD-X2] Publish Event - FHIRcast<br />
* [RAD-X3] Notify Event - FHIRcast<br />
* [RAD-X4] Unsubscribe Event - FHIRcast<br />
* [RAD-X5] Launch Application - OAuth2 / SMART on FHIR<br />
<br />
Content Modules:<br />
* IMR Measurements and image references - FHIR Observation<br />
<br />
===Profile===<br />
<br />
* New profile for RTBC-IMR<br />
<br />
Note that once RAD-X1 to RAD-X5 are defined, new message payload can be defined to accommodate other use cases such as IID context switching.<br />
<br />
===Decisions/Topics/Uncertainties===<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at recent FHIR Connectathons, and there is a growing rate of adoption for new applications (e.g. one major reporting vendor is already using FHIRcast as its new API integrating with PACS).<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to the use cases highlighted above.<br />
<br />
* Adopting FHIRcast and SMART on FHIR enables new secure application integration and communication beyond traditional DICOM and HL7.<br />
<br />
* FHIRcast recommends SMART on FHIR as a method to convey the topic from the App Launcher to the Application. This should be an optional method as not all integrations leverages SMART on FHIR or OAuth2.<br />
<br />
=== Task Breakdowns ===<br />
* Extend the existing IMR use cases to accommodate RTBC-IMR steps<br />
* Define the new transactions<br />
* Define the message content (e.g. using FHIR Observation) for IMR use case<br />
<br />
Note: This profile can be done using either the traditional Word document or the FHIR IG Publisher. FHIRcast definition is not directly supported by the IG Publisher. So majority of the specification will be regular text.<br />
<br />
==6. Support & Resources==<br />
<br />
HIMSS / SIIM IMR workgroup has been a great supporter of the IMR profile and this extension. Many of the active participants (e.g. David Vining and Peter O'Toole) are interested in helping the development of the profile, from the clinical expert perspective as well as vendor / implementation perspective.<br />
<br />
==7. Risks==<br />
* HL7 FHIR is also developing a new SMART Web Messaging protocol which is aiming at browser applications. However, this is less mature than FHIRcast and it is more limited to browser applications.<br />
<br />
* Realtime Bidirectional Communication is a cross-cutting concern that has broader applicability. One may argue that it is better to be profiles in the ITI domain first and the Radiology can adopt it by defining the content modules. The counter-argument is that the need for Radiology is now and many of the rapid data exchange integration use cases exist in imaging.<br />
<br />
==8. Tech Cmte Evaluation==<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% for MUE<br />
:* yy% for MUE + optional<br />
<br />
Editor:<br />
: Kinson Ho<br />
<br />
SME/Champion:<br />
:* David Vining (MD Anderson / VisionSR)<br />
:* Peter O'Toole (mIntuition)</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication_for_Interactive_Multimedia_Reporting_-_Detailed&diff=128767Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed2022-08-23T17:43:49Z<p>Kho: /* 4. Standards and Systems */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication for Interactive Multimedia Reporting==<br />
<br />
* Proposal Editor: Kinson Ho, David Vining, Peter O'Toole<br />
* Editor: Kinson Ho<br />
* Domain: Radiology<br />
<br />
===Summary===<br />
In current practices, there is no standard realtime bidirectional communications between systems in a health enterprise to support advanced integrated use cases that require rapid information flow between systems.<br />
<br />
FHIRcast is an emerging standard that facilitates a general publication / subscription messaging mechanism. It defines the messaging protocol as well as the message payload.<br />
<br />
With such a realtime bidirectional communication method, data or commands can be conveyed between system to facilitate advanced integration. For example, an Interactive Multimedia Reporting extension could require compliant an Image Display to convey measurements in realtime to the Report Creator so that the measurements can be automatically displayed in context while dictation is proceeding.<br />
<br />
HIMSS/SIIM has published a [https://link.springer.com/article/10.1007/s10278-022-00658-z whitepaper] regarding the importance of IMR and part of the discussion is a need for such realtime bidirection communication. Many participants from the HIMSS/SIIM IMR workgroup are interested in this effort.<br />
<br />
IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration. Having a standard-based mechanism increases interoperability and can accelerate adoption of more advanced integrated workflows.<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to support advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve a radiologist's workflow efficiency and patient safety by eliminating human input of data (e.g. manual, dictation) that is time consuming and subject to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create these<br />
DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
into a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are good resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
generates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* Reporting System (Report Creator)<br />
* AI Manager (Evidence Creator)<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
==5. Technical Approach==<br />
<br />
===Actors===<br />
New Actors:<br />
* Data Publisher<br />
* Data Subscriber<br />
* Data Hub<br />
<br />
These are actors that provide the messaging mechanism. These actors are meant to be grouped with other actors that provides the message content.<br />
<br />
Existing actors:<br />
<br />
*For the IMR use case<br />
** Report Creator is the Data Subscriber<br />
** Image Display is the Data Publihser<br />
<br />
* For the EMR with embedded viewer use case<br />
** Image Display Invoker is the Data Publisher<br />
** Image Display is the Data Subscriber<br />
<br />
===Transactions===<br />
<br />
New transactions:<br />
* [RAD-X1] Subscribe Event - FHIRcast<br />
* [RAD-X2] Publish Event - FHIRcast<br />
* [RAD-X3] Notify Event - FHIRcast<br />
* [RAD-X4] Unsubscribe Event - FHIRcast<br />
* [RAD-X5] Launch Application - OAuth2 / SMART on FHIR<br />
<br />
Content Modules:<br />
* IMR Measurements - FHIR Observation<br />
* Study Open/Close - FHIRcast<br />
* Patient Open/Close - FHIRCast<br />
<br />
===Profile===<br />
There can be two approaches to the implementation:<br />
<br />
* Approach 1: Independent Realtime Bidirectional Communication Profile and then update IMR and IID with grouped actors<br />
* Approach 2: New transactions [RAD-1] to [RAD-5] and they are added to IMR and IID profiles for the corresponding actors<br />
<br />
===Decisions/Topics/Uncertainties===<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at recent FHIR Connectathons, and there is a growing rate of adoption for new applications (e.g. one major reporting vendor is already using FHIRcast as its new API integrating with PACS).<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to the use cases highlighted above.<br />
<br />
* Adopting FHIRcast and SMART on FHIR enables new secure application integration and communication beyond traditional DICOM and HL7.<br />
<br />
* FHIRcast recommends SMART on FHIR as a method to convey the topic from the App Launcher to the Application. This should be an optional method as not all integrations leverages SMART on FHIR or OAuth2.<br />
<br />
=== Task Breakdowns ===<br />
* Decide on which approach for the profile development<br />
* Extend the existing IMR and IID use cases to accommodate RTBC steps<br />
* Define the new transactions<br />
* Define the message content (e.g. using FHIR Observation) for IMR use case<br />
* Review and modify the existing patient/study-open/close message in FHIRcast for the IID use case<br />
<br />
Note: This profile can be done using either the traditional Word document or the FHIR IG Publisher. FHIRcast definition is not directly supported by the IG Publisher. So majority of the specification will be regular text.<br />
<br />
==6. Support & Resources==<br />
<br />
HIMSS / SIIM IMR workgroup has been a great supporter of the IMR profile and this extension. Many of the active participants (e.g. David Vining and Peter O'Toole) are interested in helping the development of the profile, from the clinical expert perspective as well as vendor / implementation perspective.<br />
<br />
==7. Risks==<br />
* HL7 FHIR is also developing a new SMART Web Messaging protocol which is aiming at browser applications. However, this is less mature than FHIRcast and it is more limited to browser applications.<br />
<br />
* Realtime Bidirectional Communication is a cross-cutting concern that has broader applicability. One may argue that it is better to be profiles in the ITI domain first and the Radiology can adopt it by defining the content modules. The counter-argument is that the need for Radiology is now and many of the rapid data exchange integration use cases exist in imaging.<br />
<br />
==8. Tech Cmte Evaluation==<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% for MUE<br />
:* yy% for MUE + optional<br />
<br />
Editor:<br />
: Kinson Ho<br />
<br />
SME/Champion:<br />
:* David Vining (MD Anderson / VisionSR)<br />
:* Peter O'Toole (mIntuition)</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication_for_Interactive_Multimedia_Reporting_-_Detailed&diff=128766Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed2022-08-23T17:42:22Z<p>Kho: /* 3. Key Use Case */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication for Interactive Multimedia Reporting==<br />
<br />
* Proposal Editor: Kinson Ho, David Vining, Peter O'Toole<br />
* Editor: Kinson Ho<br />
* Domain: Radiology<br />
<br />
===Summary===<br />
In current practices, there is no standard realtime bidirectional communications between systems in a health enterprise to support advanced integrated use cases that require rapid information flow between systems.<br />
<br />
FHIRcast is an emerging standard that facilitates a general publication / subscription messaging mechanism. It defines the messaging protocol as well as the message payload.<br />
<br />
With such a realtime bidirectional communication method, data or commands can be conveyed between system to facilitate advanced integration. For example, an Interactive Multimedia Reporting extension could require compliant an Image Display to convey measurements in realtime to the Report Creator so that the measurements can be automatically displayed in context while dictation is proceeding.<br />
<br />
HIMSS/SIIM has published a [https://link.springer.com/article/10.1007/s10278-022-00658-z whitepaper] regarding the importance of IMR and part of the discussion is a need for such realtime bidirection communication. Many participants from the HIMSS/SIIM IMR workgroup are interested in this effort.<br />
<br />
IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration. Having a standard-based mechanism increases interoperability and can accelerate adoption of more advanced integrated workflows.<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to support advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve a radiologist's workflow efficiency and patient safety by eliminating human input of data (e.g. manual, dictation) that is time consuming and subject to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create these<br />
DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
into a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are good resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
generates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* EMR<br />
* Reporting System (Report Creator)<br />
* AI Manager<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
<br />
==5. Technical Approach==<br />
<br />
===Actors===<br />
New Actors:<br />
* Data Publisher<br />
* Data Subscriber<br />
* Data Hub<br />
<br />
These are actors that provide the messaging mechanism. These actors are meant to be grouped with other actors that provides the message content.<br />
<br />
Existing actors:<br />
<br />
*For the IMR use case<br />
** Report Creator is the Data Subscriber<br />
** Image Display is the Data Publihser<br />
<br />
* For the EMR with embedded viewer use case<br />
** Image Display Invoker is the Data Publisher<br />
** Image Display is the Data Subscriber<br />
<br />
===Transactions===<br />
<br />
New transactions:<br />
* [RAD-X1] Subscribe Event - FHIRcast<br />
* [RAD-X2] Publish Event - FHIRcast<br />
* [RAD-X3] Notify Event - FHIRcast<br />
* [RAD-X4] Unsubscribe Event - FHIRcast<br />
* [RAD-X5] Launch Application - OAuth2 / SMART on FHIR<br />
<br />
Content Modules:<br />
* IMR Measurements - FHIR Observation<br />
* Study Open/Close - FHIRcast<br />
* Patient Open/Close - FHIRCast<br />
<br />
===Profile===<br />
There can be two approaches to the implementation:<br />
<br />
* Approach 1: Independent Realtime Bidirectional Communication Profile and then update IMR and IID with grouped actors<br />
* Approach 2: New transactions [RAD-1] to [RAD-5] and they are added to IMR and IID profiles for the corresponding actors<br />
<br />
===Decisions/Topics/Uncertainties===<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at recent FHIR Connectathons, and there is a growing rate of adoption for new applications (e.g. one major reporting vendor is already using FHIRcast as its new API integrating with PACS).<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to the use cases highlighted above.<br />
<br />
* Adopting FHIRcast and SMART on FHIR enables new secure application integration and communication beyond traditional DICOM and HL7.<br />
<br />
* FHIRcast recommends SMART on FHIR as a method to convey the topic from the App Launcher to the Application. This should be an optional method as not all integrations leverages SMART on FHIR or OAuth2.<br />
<br />
=== Task Breakdowns ===<br />
* Decide on which approach for the profile development<br />
* Extend the existing IMR and IID use cases to accommodate RTBC steps<br />
* Define the new transactions<br />
* Define the message content (e.g. using FHIR Observation) for IMR use case<br />
* Review and modify the existing patient/study-open/close message in FHIRcast for the IID use case<br />
<br />
Note: This profile can be done using either the traditional Word document or the FHIR IG Publisher. FHIRcast definition is not directly supported by the IG Publisher. So majority of the specification will be regular text.<br />
<br />
==6. Support & Resources==<br />
<br />
HIMSS / SIIM IMR workgroup has been a great supporter of the IMR profile and this extension. Many of the active participants (e.g. David Vining and Peter O'Toole) are interested in helping the development of the profile, from the clinical expert perspective as well as vendor / implementation perspective.<br />
<br />
==7. Risks==<br />
* HL7 FHIR is also developing a new SMART Web Messaging protocol which is aiming at browser applications. However, this is less mature than FHIRcast and it is more limited to browser applications.<br />
<br />
* Realtime Bidirectional Communication is a cross-cutting concern that has broader applicability. One may argue that it is better to be profiles in the ITI domain first and the Radiology can adopt it by defining the content modules. The counter-argument is that the need for Radiology is now and many of the rapid data exchange integration use cases exist in imaging.<br />
<br />
==8. Tech Cmte Evaluation==<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% for MUE<br />
:* yy% for MUE + optional<br />
<br />
Editor:<br />
: Kinson Ho<br />
<br />
SME/Champion:<br />
:* David Vining (MD Anderson / VisionSR)<br />
:* Peter O'Toole (mIntuition)</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication_for_Interactive_Multimedia_Reporting_-_Detailed&diff=128765Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed2022-08-23T17:40:46Z<p>Kho: /* 1. Proposed Workitem: Realtime Bidirectional Communication */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication for Interactive Multimedia Reporting==<br />
<br />
* Proposal Editor: Kinson Ho, David Vining, Peter O'Toole<br />
* Editor: Kinson Ho<br />
* Domain: Radiology<br />
<br />
===Summary===<br />
In current practices, there is no standard realtime bidirectional communications between systems in a health enterprise to support advanced integrated use cases that require rapid information flow between systems.<br />
<br />
FHIRcast is an emerging standard that facilitates a general publication / subscription messaging mechanism. It defines the messaging protocol as well as the message payload.<br />
<br />
With such a realtime bidirectional communication method, data or commands can be conveyed between system to facilitate advanced integration. For example, an Interactive Multimedia Reporting extension could require compliant an Image Display to convey measurements in realtime to the Report Creator so that the measurements can be automatically displayed in context while dictation is proceeding.<br />
<br />
HIMSS/SIIM has published a [https://link.springer.com/article/10.1007/s10278-022-00658-z whitepaper] regarding the importance of IMR and part of the discussion is a need for such realtime bidirection communication. Many participants from the HIMSS/SIIM IMR workgroup are interested in this effort.<br />
<br />
IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration. Having a standard-based mechanism increases interoperability and can accelerate adoption of more advanced integrated workflows.<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to support advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve a radiologist's workflow efficiency and patient safety by eliminating human input of data (e.g. manual, dictation) that is time consuming and subject to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create these<br />
DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
into a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are good resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
generates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
# Use Case 2: Context Sharing between EMR and Universal Viewer<br />
<br />
When an EMR launches an imaging viewer to show a study, the commands to launch the viewer usually includes the specific patient and study context. When the user switches to another study and/or patient, the EMR needs to communicate reliably the new context to the viewer to trigger loading of a new study automatically without human intervention. Traditionally this context switching is done using vendor specific proprietary methods that requiers custom integration.<br />
<br />
In additional, when the user no longer needs to view the patient's study, the EMR should send a command to the viewer to close the study in context. This may be done automatically using a proprietary method today, or has to be done manually. This can potentially cause patient safety issue if the viewer is not reliably closed while the user switches context to another patient / study in the EMR. The user may be mistakenly viewing a wrong study for the wrong patient and hence and result in incorrect diagnosis.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* EMR<br />
* Reporting System (Report Creator)<br />
* AI Manager<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
<br />
==5. Technical Approach==<br />
<br />
===Actors===<br />
New Actors:<br />
* Data Publisher<br />
* Data Subscriber<br />
* Data Hub<br />
<br />
These are actors that provide the messaging mechanism. These actors are meant to be grouped with other actors that provides the message content.<br />
<br />
Existing actors:<br />
<br />
*For the IMR use case<br />
** Report Creator is the Data Subscriber<br />
** Image Display is the Data Publihser<br />
<br />
* For the EMR with embedded viewer use case<br />
** Image Display Invoker is the Data Publisher<br />
** Image Display is the Data Subscriber<br />
<br />
===Transactions===<br />
<br />
New transactions:<br />
* [RAD-X1] Subscribe Event - FHIRcast<br />
* [RAD-X2] Publish Event - FHIRcast<br />
* [RAD-X3] Notify Event - FHIRcast<br />
* [RAD-X4] Unsubscribe Event - FHIRcast<br />
* [RAD-X5] Launch Application - OAuth2 / SMART on FHIR<br />
<br />
Content Modules:<br />
* IMR Measurements - FHIR Observation<br />
* Study Open/Close - FHIRcast<br />
* Patient Open/Close - FHIRCast<br />
<br />
===Profile===<br />
There can be two approaches to the implementation:<br />
<br />
* Approach 1: Independent Realtime Bidirectional Communication Profile and then update IMR and IID with grouped actors<br />
* Approach 2: New transactions [RAD-1] to [RAD-5] and they are added to IMR and IID profiles for the corresponding actors<br />
<br />
===Decisions/Topics/Uncertainties===<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at recent FHIR Connectathons, and there is a growing rate of adoption for new applications (e.g. one major reporting vendor is already using FHIRcast as its new API integrating with PACS).<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to the use cases highlighted above.<br />
<br />
* Adopting FHIRcast and SMART on FHIR enables new secure application integration and communication beyond traditional DICOM and HL7.<br />
<br />
* FHIRcast recommends SMART on FHIR as a method to convey the topic from the App Launcher to the Application. This should be an optional method as not all integrations leverages SMART on FHIR or OAuth2.<br />
<br />
=== Task Breakdowns ===<br />
* Decide on which approach for the profile development<br />
* Extend the existing IMR and IID use cases to accommodate RTBC steps<br />
* Define the new transactions<br />
* Define the message content (e.g. using FHIR Observation) for IMR use case<br />
* Review and modify the existing patient/study-open/close message in FHIRcast for the IID use case<br />
<br />
Note: This profile can be done using either the traditional Word document or the FHIR IG Publisher. FHIRcast definition is not directly supported by the IG Publisher. So majority of the specification will be regular text.<br />
<br />
==6. Support & Resources==<br />
<br />
HIMSS / SIIM IMR workgroup has been a great supporter of the IMR profile and this extension. Many of the active participants (e.g. David Vining and Peter O'Toole) are interested in helping the development of the profile, from the clinical expert perspective as well as vendor / implementation perspective.<br />
<br />
==7. Risks==<br />
* HL7 FHIR is also developing a new SMART Web Messaging protocol which is aiming at browser applications. However, this is less mature than FHIRcast and it is more limited to browser applications.<br />
<br />
* Realtime Bidirectional Communication is a cross-cutting concern that has broader applicability. One may argue that it is better to be profiles in the ITI domain first and the Radiology can adopt it by defining the content modules. The counter-argument is that the need for Radiology is now and many of the rapid data exchange integration use cases exist in imaging.<br />
<br />
==8. Tech Cmte Evaluation==<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% for MUE<br />
:* yy% for MUE + optional<br />
<br />
Editor:<br />
: Kinson Ho<br />
<br />
SME/Champion:<br />
:* David Vining (MD Anderson / VisionSR)<br />
:* Peter O'Toole (mIntuition)</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication_for_Interactive_Multimedia_Reporting_-_Detailed&diff=128759Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed2022-08-23T14:07:37Z<p>Kho: /* 7. Risks */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication==<br />
<br />
* Proposal Editor: Kinson Ho, David Vining, Peter O'Toole<br />
* Editor: Kinson Ho<br />
* Domain: Radiology<br />
<br />
===Summary===<br />
In current practices, there is no standard realtime bidirectional communications between systems in a health enterprise to support advanced integrated use cases that require rapid information flow between systems.<br />
<br />
FHIRcast is an emerging standard that facilitates a general publication / subscription messaging mechanism. It defines the messaging protocol as well as the message payload.<br />
<br />
With such a realtime bidirectional communication method, data or commands can be conveyed between system to facilitate advanced integration. For example, an Interactive Multimedia Reporting extension could require compliant an Image Display to convey measurements in realtime to the Report Creator so that the measurements can be automatically displayed in context while dictation is proceeding. Another use case is for EMR to send a command to switch patient and/or study context to an embedded Image Display or to close it rather than requiring the user to manually switch patient/study or close the viewer.<br />
<br />
HIMSS/SIIM has published a [https://link.springer.com/article/10.1007/s10278-022-00658-z whitepaper] regarding the importance of IMR and part of the discussion is a need for such realtime bidirection communication. Many participants from the HIMSS/SIIM IMR workgroup are interested in this effort.<br />
<br />
Embedding an enterprise viewer in EMR is common practice to show imaging studies along with the patient records in an EMR. IHE Invoked Image Display profile facilitates that by defining a standard URL to launch a viewer. IID is close to final text, with the exception that there is an outstanding CP to support automatic switching context or closing the viewer.<br />
<br />
IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration. Having a standard-based mechanism increases interoperability and can accelerate adoption of more advanced integrated workflows.<br />
<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to support advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve a radiologist's workflow efficiency and patient safety by eliminating human input of data (e.g. manual, dictation) that is time consuming and subject to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create these<br />
DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
into a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are good resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
generates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
# Use Case 2: Context Sharing between EMR and Universal Viewer<br />
<br />
When an EMR launches an imaging viewer to show a study, the commands to launch the viewer usually includes the specific patient and study context. When the user switches to another study and/or patient, the EMR needs to communicate reliably the new context to the viewer to trigger loading of a new study automatically without human intervention. Traditionally this context switching is done using vendor specific proprietary methods that requiers custom integration.<br />
<br />
In additional, when the user no longer needs to view the patient's study, the EMR should send a command to the viewer to close the study in context. This may be done automatically using a proprietary method today, or has to be done manually. This can potentially cause patient safety issue if the viewer is not reliably closed while the user switches context to another patient / study in the EMR. The user may be mistakenly viewing a wrong study for the wrong patient and hence and result in incorrect diagnosis.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* EMR<br />
* Reporting System (Report Creator)<br />
* AI Manager<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
<br />
==5. Technical Approach==<br />
<br />
===Actors===<br />
New Actors:<br />
* Data Publisher<br />
* Data Subscriber<br />
* Data Hub<br />
<br />
These are actors that provide the messaging mechanism. These actors are meant to be grouped with other actors that provides the message content.<br />
<br />
Existing actors:<br />
<br />
*For the IMR use case<br />
** Report Creator is the Data Subscriber<br />
** Image Display is the Data Publihser<br />
<br />
* For the EMR with embedded viewer use case<br />
** Image Display Invoker is the Data Publisher<br />
** Image Display is the Data Subscriber<br />
<br />
===Transactions===<br />
<br />
New transactions:<br />
* [RAD-X1] Subscribe Event - FHIRcast<br />
* [RAD-X2] Publish Event - FHIRcast<br />
* [RAD-X3] Notify Event - FHIRcast<br />
* [RAD-X4] Unsubscribe Event - FHIRcast<br />
* [RAD-X5] Launch Application - OAuth2 / SMART on FHIR<br />
<br />
Content Modules:<br />
* IMR Measurements - FHIR Observation<br />
* Study Open/Close - FHIRcast<br />
* Patient Open/Close - FHIRCast<br />
<br />
===Profile===<br />
There can be two approaches to the implementation:<br />
<br />
* Approach 1: Independent Realtime Bidirectional Communication Profile and then update IMR and IID with grouped actors<br />
* Approach 2: New transactions [RAD-1] to [RAD-5] and they are added to IMR and IID profiles for the corresponding actors<br />
<br />
===Decisions/Topics/Uncertainties===<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at recent FHIR Connectathons, and there is a growing rate of adoption for new applications (e.g. one major reporting vendor is already using FHIRcast as its new API integrating with PACS).<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to the use cases highlighted above.<br />
<br />
* Adopting FHIRcast and SMART on FHIR enables new secure application integration and communication beyond traditional DICOM and HL7.<br />
<br />
* FHIRcast recommends SMART on FHIR as a method to convey the topic from the App Launcher to the Application. This should be an optional method as not all integrations leverages SMART on FHIR or OAuth2.<br />
<br />
=== Task Breakdowns ===<br />
* Decide on which approach for the profile development<br />
* Extend the existing IMR and IID use cases to accommodate RTBC steps<br />
* Define the new transactions<br />
* Define the message content (e.g. using FHIR Observation) for IMR use case<br />
* Review and modify the existing patient/study-open/close message in FHIRcast for the IID use case<br />
<br />
Note: This profile can be done using either the traditional Word document or the FHIR IG Publisher. FHIRcast definition is not directly supported by the IG Publisher. So majority of the specification will be regular text.<br />
<br />
==6. Support & Resources==<br />
<br />
HIMSS / SIIM IMR workgroup has been a great supporter of the IMR profile and this extension. Many of the active participants (e.g. David Vining and Peter O'Toole) are interested in helping the development of the profile, from the clinical expert perspective as well as vendor / implementation perspective.<br />
<br />
==7. Risks==<br />
* HL7 FHIR is also developing a new SMART Web Messaging protocol which is aiming at browser applications. However, this is less mature than FHIRcast and it is more limited to browser applications.<br />
<br />
* Realtime Bidirectional Communication is a cross-cutting concern that has broader applicability. One may argue that it is better to be profiles in the ITI domain first and the Radiology can adopt it by defining the content modules. The counter-argument is that the need for Radiology is now and many of the rapid data exchange integration use cases exist in imaging.<br />
<br />
==8. Tech Cmte Evaluation==<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% for MUE<br />
:* yy% for MUE + optional<br />
<br />
Editor:<br />
: Kinson Ho<br />
<br />
SME/Champion:<br />
:* David Vining (MD Anderson / VisionSR)<br />
:* Peter O'Toole (mIntuition)</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication_for_Interactive_Multimedia_Reporting_-_Detailed&diff=128758Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed2022-08-22T22:38:45Z<p>Kho: </p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication==<br />
<br />
* Proposal Editor: Kinson Ho, David Vining, Peter O'Toole<br />
* Editor: Kinson Ho<br />
* Domain: Radiology<br />
<br />
===Summary===<br />
In current practices, there is no standard realtime bidirectional communications between systems in a health enterprise to support advanced integrated use cases that require rapid information flow between systems.<br />
<br />
FHIRcast is an emerging standard that facilitates a general publication / subscription messaging mechanism. It defines the messaging protocol as well as the message payload.<br />
<br />
With such a realtime bidirectional communication method, data or commands can be conveyed between system to facilitate advanced integration. For example, an Interactive Multimedia Reporting extension could require compliant an Image Display to convey measurements in realtime to the Report Creator so that the measurements can be automatically displayed in context while dictation is proceeding. Another use case is for EMR to send a command to switch patient and/or study context to an embedded Image Display or to close it rather than requiring the user to manually switch patient/study or close the viewer.<br />
<br />
HIMSS/SIIM has published a [https://link.springer.com/article/10.1007/s10278-022-00658-z whitepaper] regarding the importance of IMR and part of the discussion is a need for such realtime bidirection communication. Many participants from the HIMSS/SIIM IMR workgroup are interested in this effort.<br />
<br />
Embedding an enterprise viewer in EMR is common practice to show imaging studies along with the patient records in an EMR. IHE Invoked Image Display profile facilitates that by defining a standard URL to launch a viewer. IID is close to final text, with the exception that there is an outstanding CP to support automatic switching context or closing the viewer.<br />
<br />
IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration. Having a standard-based mechanism increases interoperability and can accelerate adoption of more advanced integrated workflows.<br />
<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to support advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve a radiologist's workflow efficiency and patient safety by eliminating human input of data (e.g. manual, dictation) that is time consuming and subject to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create these<br />
DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
into a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are good resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
generates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
# Use Case 2: Context Sharing between EMR and Universal Viewer<br />
<br />
When an EMR launches an imaging viewer to show a study, the commands to launch the viewer usually includes the specific patient and study context. When the user switches to another study and/or patient, the EMR needs to communicate reliably the new context to the viewer to trigger loading of a new study automatically without human intervention. Traditionally this context switching is done using vendor specific proprietary methods that requiers custom integration.<br />
<br />
In additional, when the user no longer needs to view the patient's study, the EMR should send a command to the viewer to close the study in context. This may be done automatically using a proprietary method today, or has to be done manually. This can potentially cause patient safety issue if the viewer is not reliably closed while the user switches context to another patient / study in the EMR. The user may be mistakenly viewing a wrong study for the wrong patient and hence and result in incorrect diagnosis.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* EMR<br />
* Reporting System (Report Creator)<br />
* AI Manager<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
<br />
==5. Technical Approach==<br />
<br />
===Actors===<br />
New Actors:<br />
* Data Publisher<br />
* Data Subscriber<br />
* Data Hub<br />
<br />
These are actors that provide the messaging mechanism. These actors are meant to be grouped with other actors that provides the message content.<br />
<br />
Existing actors:<br />
<br />
*For the IMR use case<br />
** Report Creator is the Data Subscriber<br />
** Image Display is the Data Publihser<br />
<br />
* For the EMR with embedded viewer use case<br />
** Image Display Invoker is the Data Publisher<br />
** Image Display is the Data Subscriber<br />
<br />
===Transactions===<br />
<br />
New transactions:<br />
* [RAD-X1] Subscribe Event - FHIRcast<br />
* [RAD-X2] Publish Event - FHIRcast<br />
* [RAD-X3] Notify Event - FHIRcast<br />
* [RAD-X4] Unsubscribe Event - FHIRcast<br />
* [RAD-X5] Launch Application - OAuth2 / SMART on FHIR<br />
<br />
Content Modules:<br />
* IMR Measurements - FHIR Observation<br />
* Study Open/Close - FHIRcast<br />
* Patient Open/Close - FHIRCast<br />
<br />
===Profile===<br />
There can be two approaches to the implementation:<br />
<br />
* Approach 1: Independent Realtime Bidirectional Communication Profile and then update IMR and IID with grouped actors<br />
* Approach 2: New transactions [RAD-1] to [RAD-5] and they are added to IMR and IID profiles for the corresponding actors<br />
<br />
===Decisions/Topics/Uncertainties===<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at recent FHIR Connectathons, and there is a growing rate of adoption for new applications (e.g. one major reporting vendor is already using FHIRcast as its new API integrating with PACS).<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to the use cases highlighted above.<br />
<br />
* Adopting FHIRcast and SMART on FHIR enables new secure application integration and communication beyond traditional DICOM and HL7.<br />
<br />
* FHIRcast recommends SMART on FHIR as a method to convey the topic from the App Launcher to the Application. This should be an optional method as not all integrations leverages SMART on FHIR or OAuth2.<br />
<br />
=== Task Breakdowns ===<br />
* Decide on which approach for the profile development<br />
* Extend the existing IMR and IID use cases to accommodate RTBC steps<br />
* Define the new transactions<br />
* Define the message content (e.g. using FHIR Observation) for IMR use case<br />
* Review and modify the existing patient/study-open/close message in FHIRcast for the IID use case<br />
<br />
Note: This profile can be done using either the traditional Word document or the FHIR IG Publisher. FHIRcast definition is not directly supported by the IG Publisher. So majority of the specification will be regular text.<br />
<br />
==6. Support & Resources==<br />
<br />
HIMSS / SIIM IMR workgroup has been a great supporter of the IMR profile and this extension. Many of the active participants (e.g. David Vining and Peter O'Toole) are interested in helping the development of the profile, from the clinical expert perspective as well as vendor / implementation perspective.<br />
<br />
==7. Risks==<br />
* HL7 FHIR is also developing a new SMART Web Messaging protocol which is aiming at browser applications. However, this is less mature than FHIRcast and it is more limited to browser applications.<br />
<br />
<br />
==8. Tech Cmte Evaluation==<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% for MUE<br />
:* yy% for MUE + optional<br />
<br />
Editor:<br />
: Kinson Ho<br />
<br />
SME/Champion:<br />
:* David Vining (MD Anderson / VisionSR)<br />
:* Peter O'Toole (mIntuition)</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication_for_Interactive_Multimedia_Reporting_-_Detailed&diff=128757Realtime Bidirectional Communication for Interactive Multimedia Reporting - Detailed2022-08-22T21:06:52Z<p>Kho: Created page with "__NOTOC__ ==1. Proposed Workitem: Realtime Bidirectional Communication== * Proposal Editor: Kinson Ho, David Vining, Peter O'Toole * Editor: Kinson Ho * Domain: Radiology =..."</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication==<br />
<br />
* Proposal Editor: Kinson Ho, David Vining, Peter O'Toole<br />
* Editor: Kinson Ho<br />
* Domain: Radiology<br />
<br />
===Summary===<br />
In current practices, there is no standard realtime bidirectional communications between systems in a health enterprise to support advanced integrated use cases that require rapid information flow between systems.<br />
<br />
FHIRcast is an emerging standard that facilitates a general publication / subscription messaging mechanism. It defines the messaging protocol as well as the message payload.<br />
<br />
With such a realtime bidirectional communication method, data or commands can be conveyed between system to facilitate advanced integration. For example, an Interactive Multimedia Reporting extension could require compliant an Image Display to convey measurements in realtime to the Report Creator so that the measurements can be automatically displayed in context while dictation is proceeding. Another use case is for EMR to send a command to switch patient and/or study context to an embedded Image Display or to close it rather than requiring the user to manually switch patient/study or close the viewer.<br />
<br />
HIMSS/SIIM has published a [https://link.springer.com/article/10.1007/s10278-022-00658-z whitepaper] regarding the importance of IMR and part of the discussion is a need for such realtime bidirection communication. Many participants from the HIMSS/SIIM IMR workgroup are interested in this effort.<br />
<br />
Embedding an enterprise viewer in EMR is common practice to show imaging studies along with the patient records in an EMR. IHE Invoked Image Display profile facilitates that by defining a standard URL to launch a viewer. IID is close to final text, with the exception that there is an outstanding CP to support automatic switching context or closing the viewer.<br />
<br />
IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration. Having a standard-based mechanism increases interoperability and can accelerate adoption of more advanced integrated workflows.<br />
<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to support advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve a radiologist's workflow efficiency and patient safety by eliminating human input of data (e.g. manual, dictation) that is time consuming and subject to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create these<br />
DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
into a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are good resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
generates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
# Use Case 2: Context Sharing between EMR and Universal Viewer<br />
<br />
When an EMR launches an imaging viewer to show a study, the commands to launch the viewer usually includes the specific patient and study context. When the user switches to another study and/or patient, the EMR needs to communicate reliably the new context to the viewer to trigger loading of a new study automatically without human intervention. Traditionally this context switching is done using vendor specific proprietary methods that requiers custom integration.<br />
<br />
In additional, when the user no longer needs to view the patient's study, the EMR should send a command to the viewer to close the study in context. This may be done automatically using a proprietary method today, or has to be done manually. This can potentially cause patient safety issue if the viewer is not reliably closed while the user switches context to another patient / study in the EMR. The user may be mistakenly viewing a wrong study for the wrong patient and hence and result in incorrect diagnosis.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* EMR<br />
* Reporting System (Report Creator)<br />
* AI Manager<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
==5. Discussion==<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at recent FHIR Connectathons, and there is a growing rate of adoption for new applications.<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to the use cases highlighted above.<br />
<br />
* Adopting FHIRcast and SMART on FHIR enables new secure application integration and communication beyond traditional DICOM and HL7.<br />
<br />
<br />
==5. Technical Approach==<br />
''<This section describes the technical scope of the work and the proposed approach to solve the problems in the Use Cases. The Technical Committee will be responsible for the full design and may choose to take a different approach, but a sample design is a good indication of feasibility. The Technical Committee may revise/expand this section when doing the effort estimation.>''<br />
<br />
''<If any context or "big picture" is needed to understand the transaction, actor and profile discussion below, that can be put here>''<br />
<br />
''<If a phased approach would make sense indicate some logical phases. This may be because standards are evolving, because the problem is too big to solve at once, or because there are unknowns that won’t be resolved soon.>''<br />
<br />
''<The material below also serves as the breakdown of tasks that the technical committee will use to estimate the effort required to design, review and implement the profile. It helps a lot if it is reasonably complete/realistic.>''<br />
<br />
<br />
''<READ PROPOSER HOMEWORK IN '''[[Proposal_Effort_Evaluation#Proposer_Homework|Proposal Effort Evaluation]]''' FOR GUIDANCE ON POPULATING THE FOLLOWING SECTIONS >''<br />
<br />
===Actors===<br />
* (NEW) ''<List possible new actors>''<br />
*''<List existing actors that may be given requirements in the Profile.>''<br />
<br />
===Transactions===<br />
* (NEW) ''<List possible new transactions (indicating what standards would likely be used for each. Transaction diagrams are very helpful here. Feel free to go into as much detail as seems useful.>''<br />
* ''<List existing transactions that may be used and which might need modification/extension.>''<br />
<br />
===Profile===<br />
* ''<Describe the main new profile chunks that will need to be written.>''<br />
* ''<List existing profiles that may need to be modified.>''<br />
<br />
===Decisions/Topics/Uncertainties===<br />
* ''<List key decisions that will need to be made, open issues, design problems, topics to discuss, and other potential areas of uncertainty>''<br />
* ''<Credibility point: A proposal for a profile with any degree of novelty should have items listed here. If there is nothing here, it is usually a sign that the proposal analysis and discussion has been incomplete.>''<br />
<br />
==6. Support & Resources==<br />
''<List groups that have expressed support for the proposal and resources that would be available to accomplish the tasks listed above.>''<br />
<br />
''<Identify anyone who has indicated an interest in implementing/prototyping the Profile if it is published this cycle.>''<br />
<br />
==7. Risks==<br />
''<List real-world practical or political risks that could impede successfully fielding the profile.>''<br />
<br />
''<Technical risks should be noted above under Uncertainties.>''<br />
<br />
==8. Tech Cmte Evaluation==<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% for MUE<br />
:* yy% for MUE + optional<br />
<br />
Editor:<br />
: Kinson Ho<br />
<br />
SME/Champion:<br />
:* David Vining (MD Anderson / VisionSR)<br />
:* Peter O'Toole (mIntuition)</div>Khohttp://wiki.ihe.net/index.php?title=Radiology_Proposals_2022-2023&diff=128756Radiology Proposals 2022-20232022-08-22T20:21:03Z<p>Kho: /* Short List/ Detailed Proposals */</p>
<hr />
<div>{{TOCright}}<br />
<br />
===Final Selection===<br />
Final selection by the '''[[Rad_Plan_Minutes_2022-09-26|Planning Committee on Sept 26, 2022]]''' <br />
:* A. Maintenance (25%)<br />
<br />
===Effort Evaluations===<br />
The Technical Committee [[Proposal Effort Evaluation|evaluated the required effort]] of the Detailed Proposals as follows in tcons on [[Rad_Tech_Minutes_2022-08-29 | Aug 29]], [[Rad_Tech_Minutes_2022-08-31 | Aug 31]], & [[Rad_Tech_Minutes_2022-09-01 | Sept 1]].<br />
<br />
Assessments were captured in the new spreadsheet form. <br />
<br />
:* A. [[RAD TF Maintenance 2022-2023]]<br />
<br />
See [[Proposal Effort Evaluation#TC Review & Effort Estimation]] for evaluation guidance.<br />
<br />
===Short List/ Detailed Proposals===<br />
The Tech Cmte agreed to evaluate TBD number of proposals. The following Proposals were shortlisted by the [[Rad Plan Minutes 2022-08-10| Planning Committee on Aug 10, 2022]].<br />
<br />
:* A. Maintenance<br />
:* B. [[Realtime Bidirectional Communication - Detailed]]<br />
<br />
'''Editors''': by COB '''Aug 24''', 2022<br />
* '''Complete the Breakdown of Tasks''' with a strawman estimate of story points:<br />
:* [https://docs.google.com/spreadsheets/d/1IoRwFz1xxORCwYIJat-Yn2trfkhiT5OKbU8toEpKb5k/edit?usp=sharing BoD & Estimation - Google Sheet (Tab for each proposal)]<br />
* '''Expand your Brief Proposal''' to include Detailed Proposal elements<br />
:* Copy the [[Delta Proposal Template]] into the bottom of your proposal page<br />
:* Update as described in the Delta Template (adds Summary, Technical Details, Evaluation, etc.)<br />
:* Breakdown of Tasks is now covered in the Google Sheet (above)<br />
* Your goal is to give sufficient detail for the Tech Cmte to be able to evaluate the technical feasibility, specification tasks and effort required.<br />
<br />
'''Reviewers''': Feel free to enter comments under Risks and Decisions/Topics/Uncertainties section of the proposal<br />
<br />
Tech Cmte evaluations will be recorded at the bottom of each detailed proposal. The "Breakdown of Tasks" and "Story Point" refinements to the '''[[Proposal Effort Evaluation]]''' are in the Google Sheet.<br />
<br />
===Brief Proposals===<br />
:* A. Maintenance<br />
:* B. [[Enhanced SOLE for AI]]<br />
:* C. [[SWF on FHIR]]<br />
:* D. [[Realtime Bidirectional Communication]]<br />
:* E. [https://docs.google.com/document/d/1DeFr0oB6ZA-SBAk2BSgZ_mjNtydQwULh/edit?usp=sharing&ouid=102612276002431976750&rtpof=true&sd=true Management of Sensitive Images (MOSI)] <br />
:* F. [[Reporting Worklist Prioritization - Proposal]]<br />
:* G. [[Imaging Diagnostic Report - Proposal]]<br />
<br />
Submission DEADLINE is '''August 5''', 2022, 11:59pm CT<br />
<br />
===Call for Proposals===<br />
Interested parties are invited to submit proposal pages based on the '''[[Brief Proposal Template]]'''.<br />
<br />
You are also welcome to update and resubmit proposals from '''[[Radiology Proposals 2021-2022|last year]]''' or earlier.<br />
<br />
Contact radiology@ihe.net with any questions.<br />
<br />
===Committee Links===<br />
<br />
[[Radiology Planning Committee]]<br />
<br />
[[Radiology Technical Committee]]</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication&diff=128721Realtime Bidirectional Communication2022-08-10T16:07:30Z<p>Kho: /* 4. Standards and Systems */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication==<br />
<br />
* Proposal Editor: Kinson Ho, David Vining, Peter O'Toole<br />
* Editor: Kinson Ho<br />
* Domain: Radiology<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to support advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve a radiologist's workflow efficiency and patient safety by eliminating human input of data (e.g. manual, dictation) that is time consuming and subject to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create these<br />
DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
into a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are good resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
gemerates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
# Use Case 2: Context Sharing between EMR and Universal Viewer<br />
<br />
When an EMR launches an imaging viewer to show a study, the commands to launch the viewer usually includes the specific patient and study context. When the user switches to another study and/or patient, the EMR needs to communicate reliably the new context to the viewer to trigger loading of a new study. Traditionally this context switching is done using vendor specific proprietary methods. In additional, when the user no longer needs to view the patient's study, the EMR should send a command to the viewer to close the study in context.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* EMR<br />
* Reporting System (Report Creator)<br />
* AI Manager<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
==5. Discussion==<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at recent FHIR Connectathons, and there is a growing rate of adoption for new applications.<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to the use cases highlighted above.<br />
<br />
* Adopting FHIRcast and SMART on FHIR enables new secure application integration and communication beyond traditional DICOM and HL7.</div>Khohttp://wiki.ihe.net/index.php?title=Radiology_Proposals_2022-2023&diff=128692Radiology Proposals 2022-20232022-08-05T15:39:04Z<p>Kho: /* Brief Proposals */</p>
<hr />
<div>{{TOCright}}<br />
<br />
===Final Selection===<br />
Final selection by the '''[[Rad_Plan_Minutes_2022-09-26|Planning Committee on Sept 26, 2022]]''' <br />
:* A. Maintenance (25%)<br />
<br />
===Effort Evaluations===<br />
The Technical Committee [[Proposal Effort Evaluation|evaluated the required effort]] of the Detailed Proposals as follows in tcons on [[Rad_Tech_Minutes_2022-08-29 | Aug 29]], [[Rad_Tech_Minutes_2022-08-31 | Aug 31]], & [[Rad_Tech_Minutes_2022-09-01 | Sept 1]].<br />
<br />
Assessments were captured in the new spreadsheet form. <br />
<br />
:* A. [[RAD TF Maintenance 2022-2023]]<br />
<br />
See [[Proposal Effort Evaluation#TC Review & Effort Estimation]] for evaluation guidance.<br />
<br />
===Short List/ Detailed Proposals===<br />
The Tech Cmte agreed to evaluate TBD number of proposals. The following Proposals were shortlisted by the [[Rad Plan Minutes 2022-08-10| Planning Committee on Aug 10, 2022]].<br />
<br />
:* A. Maintenance<br />
<br />
'''Editors''': by COB '''Aug 24''', 2022<br />
* '''Complete the Breakdown of Tasks''' with a strawman estimate of story points:<br />
:* [https://docs.google.com/spreadsheets/d/18wETLZhLYcXq5pOMfAhH8-Q4M5cKztj6QNUEOAcOnng/edit#gid=1166925166 BoD & Estimation - Google Sheet (Tab for each proposal)]<br />
* '''Expand your Brief Proposal''' to include Detailed Proposal elements<br />
:* Copy the [[Delta Proposal Template]] into the bottom of your proposal page<br />
:* Update as described in the Delta Template (adds Summary, Technical Details, Evaluation, etc.)<br />
:* Breakdown of Tasks is now covered in the Google Sheet (above)<br />
* Your goal is to give sufficient detail for the Tech Cmte to be able to evaluate the technical feasibility, specification tasks and effort required.<br />
<br />
'''Reviewers''': Feel free to enter comments under Risks and Decisions/Topics/Uncertainties section of the proposal<br />
<br />
Tech Cmte evaluations will be recorded at the bottom of each detailed proposal. The "Breakdown of Tasks" and "Story Point" refinements to the '''[[Proposal Effort Evaluation]]''' are in the Google Sheet.<br />
<br />
===Brief Proposals===<br />
:* A. Maintenance<br />
:* B. [[Enhanced SOLE for AI]]<br />
:* C. [[SWF on FHIR]]<br />
:* D. [[Realtime Bidirectional Communication]]<br />
:* E. [https://docs.google.com/document/d/1DeFr0oB6ZA-SBAk2BSgZ_mjNtydQwULh/edit?usp=sharing&ouid=102612276002431976750&rtpof=true&sd=true Management of Sensitive Images (MOSI)] <br />
<br />
Submission DEADLINE is '''August 5''', 2022, 11:59pm CT<br />
<br />
===Call for Proposals===<br />
Interested parties are invited to submit proposal pages based on the '''[[Brief Proposal Template]]'''.<br />
<br />
You are also welcome to update and resubmit proposals from '''[[Radiology Proposals 2021-2022|last year]]''' or earlier.<br />
<br />
Contact radiology@ihe.net with any questions.<br />
<br />
===Committee Links===<br />
<br />
[[Radiology Planning Committee]]<br />
<br />
[[Radiology Technical Committee]]</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Communication&diff=128691Realtime Communication2022-08-05T15:38:23Z<p>Kho: Kho moved page Realtime Communication to Realtime Bidirectional Communication</p>
<hr />
<div>#REDIRECT [[Realtime Bidirectional Communication]]</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication&diff=128690Realtime Bidirectional Communication2022-08-05T15:38:23Z<p>Kho: Kho moved page Realtime Communication to Realtime Bidirectional Communication</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication==<br />
<br />
* Proposal Editor: Kinson Ho, David Vining, Peter O'Toole<br />
* Editor: Kinson Ho<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to support advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve a radiologist's workflow efficiency and patient safety by eliminating human input of data (e.g. manual, dictation) that is time consuming and subject to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create these<br />
DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
into a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are good resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
gemerates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
# Use Case 2: Context Sharing between EMR and Universal Viewer<br />
<br />
When an EMR launches an imaging viewer to show a study, the commands to launch the viewer usually includes the specific patient and study context. When the user switches to another study and/or patient, the EMR needs to communicate reliably the new context to the viewer to trigger loading of a new study. Traditionally this context switching is done using vendor specific proprietary methods. In additional, when the user no longer needs to view the patient's study, the EMR should send a command to the viewer to close the study in context.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* EMR<br />
* Reporting System (Report Creator)<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
==5. Discussion==<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at recent FHIR Connectathons, and there is a growing rate of adoption for new applications.<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to the use cases highlighted above.<br />
<br />
* Adopting FHIRcast and SMART on FHIR enables new secure application integration and communication beyond traditional DICOM and HL7.</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication&diff=128689Realtime Bidirectional Communication2022-08-05T15:33:01Z<p>Kho: /* 5. Discussion */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication==<br />
<br />
* Proposal Editor: Kinson Ho, David Vining, Peter O'Toole<br />
* Editor: Kinson Ho<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to support advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve a radiologist's workflow efficiency and patient safety by eliminating human input of data (e.g. manual, dictation) that is time consuming and subject to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create these<br />
DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
into a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are good resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
gemerates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
# Use Case 2: Context Sharing between EMR and Universal Viewer<br />
<br />
When an EMR launches an imaging viewer to show a study, the commands to launch the viewer usually includes the specific patient and study context. When the user switches to another study and/or patient, the EMR needs to communicate reliably the new context to the viewer to trigger loading of a new study. Traditionally this context switching is done using vendor specific proprietary methods. In additional, when the user no longer needs to view the patient's study, the EMR should send a command to the viewer to close the study in context.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* EMR<br />
* Reporting System (Report Creator)<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
==5. Discussion==<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at recent FHIR Connectathons, and there is a growing rate of adoption for new applications.<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to the use cases highlighted above.<br />
<br />
* Adopting FHIRcast and SMART on FHIR enables new secure application integration and communication beyond traditional DICOM and HL7.</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication&diff=128688Realtime Bidirectional Communication2022-08-05T15:30:55Z<p>Kho: /* 1. Proposed Workitem: Realtime Bidirectional Communication */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication==<br />
<br />
* Proposal Editor: Kinson Ho, David Vining, Peter O'Toole<br />
* Editor: Kinson Ho<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to support advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve a radiologist's workflow efficiency and patient safety by eliminating human input of data (e.g. manual, dictation) that is time consuming and subject to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create these<br />
DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
into a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are good resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
gemerates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
# Use Case 2: Context Sharing between EMR and Universal Viewer<br />
<br />
When an EMR launches an imaging viewer to show a study, the commands to launch the viewer usually includes the specific patient and study context. When the user switches to another study and/or patient, the EMR needs to communicate reliably the new context to the viewer to trigger loading of a new study. Traditionally this context switching is done using vendor specific proprietary methods. In additional, when the user no longer needs to view the patient's study, the EMR should send a command to the viewer to close the study in context.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* EMR<br />
* Reporting System (Report Creator)<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
==5. Discussion==<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at recent FHIR Connectathons, and there is a growing rate of adoption for new applications.<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to the use cases highlighted above.</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication&diff=128687Realtime Bidirectional Communication2022-08-05T15:29:31Z<p>Kho: /* 5. Discussion */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication==<br />
<br />
* Proposal Editor: Kinson Ho<br />
* Editor: Kinson Ho<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to support advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve a radiologist's workflow efficiency and patient safety by eliminating human input of data (e.g. manual, dictation) that is time consuming and subject to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create these<br />
DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
into a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are good resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
gemerates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
# Use Case 2: Context Sharing between EMR and Universal Viewer<br />
<br />
When an EMR launches an imaging viewer to show a study, the commands to launch the viewer usually includes the specific patient and study context. When the user switches to another study and/or patient, the EMR needs to communicate reliably the new context to the viewer to trigger loading of a new study. Traditionally this context switching is done using vendor specific proprietary methods. In additional, when the user no longer needs to view the patient's study, the EMR should send a command to the viewer to close the study in context.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* EMR<br />
* Reporting System (Report Creator)<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
==5. Discussion==<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is the optimal venue because the need for bidirectional communication is common and currently there are multiple proprietary methods for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at recent FHIR Connectathons, and there is a growing rate of adoption for new applications.<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to the use cases highlighted above.</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication&diff=128686Realtime Bidirectional Communication2022-08-05T15:27:11Z<p>Kho: /* 4. Standards and Systems */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication==<br />
<br />
* Proposal Editor: Kinson Ho<br />
* Editor: Kinson Ho<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to support advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve a radiologist's workflow efficiency and patient safety by eliminating human input of data (e.g. manual, dictation) that is time consuming and subject to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create these<br />
DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
into a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are good resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
gemerates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
# Use Case 2: Context Sharing between EMR and Universal Viewer<br />
<br />
When an EMR launches an imaging viewer to show a study, the commands to launch the viewer usually includes the specific patient and study context. When the user switches to another study and/or patient, the EMR needs to communicate reliably the new context to the viewer to trigger loading of a new study. Traditionally this context switching is done using vendor specific proprietary methods. In additional, when the user no longer needs to view the patient's study, the EMR should send a command to the viewer to close the study in context.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* EMR<br />
* Reporting System (Report Creator)<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
==5. Discussion==<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is a good venue because the need for such communication method is common and currently there are lots of proprietary integration for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at FHIR Connectathon for a number of years. There is a growing number of adoption in application already.<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to some of the use cases mentioned above.</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication&diff=128685Realtime Bidirectional Communication2022-08-05T15:26:57Z<p>Kho: /* 3. Key Use Case */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication==<br />
<br />
* Proposal Editor: Kinson Ho<br />
* Editor: Kinson Ho<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to support advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve a radiologist's workflow efficiency and patient safety by eliminating human input of data (e.g. manual, dictation) that is time consuming and subject to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting (IMR) is the ability to include multimedia content (e.g. links to images, tables/graphs of measurement data, etc.) in a radiology report. Traditionally, these annotations, markups, presentation states, and<br />
key images have been captured as DICOM objects (e.g. GSPS, SR, or KOS). These objects are designed to capture static<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create these<br />
DICOM objects at the end of a reporting session in order to record metrics and annotations created by an image-centric specialist<br />
into a single object, rather than create multiple unique evidence objects for each metric or annotation. These DICOM evidence<br />
objects are good resources for subsequent retrieval when viewing an IMR, but not good payload<br />
candidates for real-time communication during a reporting session. As the image-centric specialist<br />
gemerates measurements, regions of interest, and other annotation data, the PACS should provide those data to the<br />
reporting system in real-time without unnecessary delays/interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
# Use Case 2: Context Sharing between EMR and Universal Viewer<br />
<br />
When an EMR launches an imaging viewer to show a study, the commands to launch the viewer usually includes the specific patient and study context. When the user switches to another study and/or patient, the EMR needs to communicate reliably the new context to the viewer to trigger loading of a new study. Traditionally this context switching is done using vendor specific proprietary methods. In additional, when the user no longer needs to view the patient's study, the EMR should send a command to the viewer to close the study in context.<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* EMR<br />
* Dictation System (Report Creator)<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
==5. Discussion==<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is a good venue because the need for such communication method is common and currently there are lots of proprietary integration for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at FHIR Connectathon for a number of years. There is a growing number of adoption in application already.<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to some of the use cases mentioned above.</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication&diff=128684Realtime Bidirectional Communication2022-08-05T15:19:57Z<p>Kho: /* 2. The Problem */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication==<br />
<br />
* Proposal Editor: Kinson Ho<br />
* Editor: Kinson Ho<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology<br />
<br />
==2. The Problem==<br />
<br />
As the health enterprise becomes more sophisticated with multiple systems (i.e. EMR, PACS, reporting systems, artificial intelligence analysis, etc.) requiring information flow between each other to support advanced integrated use cases, there is a growing need to support realtime bidirectional communication between systems. Solving this challenge has the potential to improve a radiologist's workflow efficiency and patient safety by eliminating human input of data (e.g. manual, dictation) that is time consuming and subject to error.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting is the ability to include clinical findings such as measurements, ROI,<br />
etc. with interactive links to the source images. Traditionally, these annotations, markups, presentation states, and<br />
key images could be captured as DICOM objects such as GSPS, SR, or KOS. These objects are designed to capture<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create these<br />
evidence objects at the end of a session in order to capture all the data points created by the image-centric specialist<br />
in one object, rather than create multiple evidence objects resulting in one per data point. As a result, these evidence<br />
objects in DICOM are good resources for subsequent interactive access when viewing an IMR, but not good<br />
candidates as the payload for real-time communication during a reporting session. As the image-centric specialist<br />
captures measurements, regions of interest, and other data points, the PACS should provide those data points to the<br />
reporting system in real-time without introducing any unnecessary interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
# Use Case 2: Context Sharing between EMR and Universal Viewer<br />
<br />
When an EMR launches an imaging viewer to show the study, the commands to launch the viewer usually includes the specific patient and study context. When the user switches to another study and/or patient, the EMR needs to communicate reliably the new context to the viewer to trigger loading of new study. Traditionally this context switching is done using vendor specific proprietary method. In additional, when the user no longer needs to show the patient's study, the EMR can send a command to the viewer to close the study in context.<br />
<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* EMR<br />
* Dictation System (Report Creator)<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
==5. Discussion==<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is a good venue because the need for such communication method is common and currently there are lots of proprietary integration for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at FHIR Connectathon for a number of years. There is a growing number of adoption in application already.<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to some of the use cases mentioned above.</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication&diff=128683Realtime Bidirectional Communication2022-08-05T15:14:51Z<p>Kho: /* 1. Proposed Workitem: Realtime Communication */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Bidirectional Communication==<br />
<br />
* Proposal Editor: Kinson Ho<br />
* Editor: Kinson Ho<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology<br />
<br />
==2. The Problem==<br />
<br />
As a health system becomes more sophisticated including many different systems (EMR, PACS, dictation system, etc.) with more advanced integrated use cases in which a user uses multiple systems simultaneously and need information to flow between these systems in realtime to keep them in sync and in context, there is a growing need to support more sophisticated realtime bidirectional communication between systems. Without this realtime communication method, often time the user can experience noticeable delays, leading to a suboptimal user experience; or worse, the information becomes out of context without notice and eventually causing wrong diagnosis.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting is the ability to include clinical findings such as measurements, ROI,<br />
etc. with interactive links to the source images. Traditionally, these annotations, markups, presentation states, and<br />
key images could be captured as DICOM objects such as GSPS, SR, or KOS. These objects are designed to capture<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create these<br />
evidence objects at the end of a session in order to capture all the data points created by the image-centric specialist<br />
in one object, rather than create multiple evidence objects resulting in one per data point. As a result, these evidence<br />
objects in DICOM are good resources for subsequent interactive access when viewing an IMR, but not good<br />
candidates as the payload for real-time communication during a reporting session. As the image-centric specialist<br />
captures measurements, regions of interest, and other data points, the PACS should provide those data points to the<br />
reporting system in real-time without introducing any unnecessary interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
# Use Case 2: Context Sharing between EMR and Universal Viewer<br />
<br />
When an EMR launches an imaging viewer to show the study, the commands to launch the viewer usually includes the specific patient and study context. When the user switches to another study and/or patient, the EMR needs to communicate reliably the new context to the viewer to trigger loading of new study. Traditionally this context switching is done using vendor specific proprietary method. In additional, when the user no longer needs to show the patient's study, the EMR can send a command to the viewer to close the study in context.<br />
<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* EMR<br />
* Dictation System (Report Creator)<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
==5. Discussion==<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is a good venue because the need for such communication method is common and currently there are lots of proprietary integration for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at FHIR Connectathon for a number of years. There is a growing number of adoption in application already.<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to some of the use cases mentioned above.</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication&diff=128682Realtime Bidirectional Communication2022-08-04T22:06:50Z<p>Kho: /* 4. Standards and Systems */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Communication==<br />
<br />
* Proposal Editor: Kinson Ho<br />
* Editor: Kinson Ho<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology<br />
<br />
==2. The Problem==<br />
<br />
As a health system becomes more sophisticated including many different systems (EMR, PACS, dictation system, etc.) with more advanced integrated use cases in which a user uses multiple systems simultaneously and need information to flow between these systems in realtime to keep them in sync and in context, there is a growing need to support more sophisticated realtime bidirectional communication between systems. Without this realtime communication method, often time the user can experience noticeable delays, leading to a suboptimal user experience; or worse, the information becomes out of context without notice and eventually causing wrong diagnosis.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting is the ability to include clinical findings such as measurements, ROI,<br />
etc. with interactive links to the source images. Traditionally, these annotations, markups, presentation states, and<br />
key images could be captured as DICOM objects such as GSPS, SR, or KOS. These objects are designed to capture<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create these<br />
evidence objects at the end of a session in order to capture all the data points created by the image-centric specialist<br />
in one object, rather than create multiple evidence objects resulting in one per data point. As a result, these evidence<br />
objects in DICOM are good resources for subsequent interactive access when viewing an IMR, but not good<br />
candidates as the payload for real-time communication during a reporting session. As the image-centric specialist<br />
captures measurements, regions of interest, and other data points, the PACS should provide those data points to the<br />
reporting system in real-time without introducing any unnecessary interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
# Use Case 2: Context Sharing between EMR and Universal Viewer<br />
<br />
When an EMR launches an imaging viewer to show the study, the commands to launch the viewer usually includes the specific patient and study context. When the user switches to another study and/or patient, the EMR needs to communicate reliably the new context to the viewer to trigger loading of new study. Traditionally this context switching is done using vendor specific proprietary method. In additional, when the user no longer needs to show the patient's study, the EMR can send a command to the viewer to close the study in context.<br />
<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* EMR<br />
* Dictation System (Report Creator)<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
* [https://www.hl7.org/fhir/observation.html FHIR Observation] for message payload<br />
<br />
==5. Discussion==<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is a good venue because the need for such communication method is common and currently there are lots of proprietary integration for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at FHIR Connectathon for a number of years. There is a growing number of adoption in application already.<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to some of the use cases mentioned above.</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication&diff=128681Realtime Bidirectional Communication2022-08-04T22:05:52Z<p>Kho: /* 4. Standards and Systems */</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Communication==<br />
<br />
* Proposal Editor: Kinson Ho<br />
* Editor: Kinson Ho<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology<br />
<br />
==2. The Problem==<br />
<br />
As a health system becomes more sophisticated including many different systems (EMR, PACS, dictation system, etc.) with more advanced integrated use cases in which a user uses multiple systems simultaneously and need information to flow between these systems in realtime to keep them in sync and in context, there is a growing need to support more sophisticated realtime bidirectional communication between systems. Without this realtime communication method, often time the user can experience noticeable delays, leading to a suboptimal user experience; or worse, the information becomes out of context without notice and eventually causing wrong diagnosis.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting is the ability to include clinical findings such as measurements, ROI,<br />
etc. with interactive links to the source images. Traditionally, these annotations, markups, presentation states, and<br />
key images could be captured as DICOM objects such as GSPS, SR, or KOS. These objects are designed to capture<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create these<br />
evidence objects at the end of a session in order to capture all the data points created by the image-centric specialist<br />
in one object, rather than create multiple evidence objects resulting in one per data point. As a result, these evidence<br />
objects in DICOM are good resources for subsequent interactive access when viewing an IMR, but not good<br />
candidates as the payload for real-time communication during a reporting session. As the image-centric specialist<br />
captures measurements, regions of interest, and other data points, the PACS should provide those data points to the<br />
reporting system in real-time without introducing any unnecessary interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
# Use Case 2: Context Sharing between EMR and Universal Viewer<br />
<br />
When an EMR launches an imaging viewer to show the study, the commands to launch the viewer usually includes the specific patient and study context. When the user switches to another study and/or patient, the EMR needs to communicate reliably the new context to the viewer to trigger loading of new study. Traditionally this context switching is done using vendor specific proprietary method. In additional, when the user no longer needs to show the patient's study, the EMR can send a command to the viewer to close the study in context.<br />
<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* EMR<br />
* Dictation System (Report Creator)<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
* [https://docs.smarthealthit.org/ Smart on FHIR] for authentication and authorization<br />
<br />
==5. Discussion==<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is a good venue because the need for such communication method is common and currently there are lots of proprietary integration for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at FHIR Connectathon for a number of years. There is a growing number of adoption in application already.<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to some of the use cases mentioned above.</div>Khohttp://wiki.ihe.net/index.php?title=Realtime_Bidirectional_Communication&diff=128675Realtime Bidirectional Communication2022-08-04T19:02:39Z<p>Kho: Created page with "__NOTOC__ ==1. Proposed Workitem: Realtime Communication== * Proposal Editor: Kinson Ho * Editor: Kinson Ho * Date: N/A (Wiki keeps history) * Version: N/A (Wiki keeps hi..."</p>
<hr />
<div>__NOTOC__<br />
<br />
==1. Proposed Workitem: Realtime Communication==<br />
<br />
* Proposal Editor: Kinson Ho<br />
* Editor: Kinson Ho<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology<br />
<br />
==2. The Problem==<br />
<br />
As a health system becomes more sophisticated including many different systems (EMR, PACS, dictation system, etc.) with more advanced integrated use cases in which a user uses multiple systems simultaneously and need information to flow between these systems in realtime to keep them in sync and in context, there is a growing need to support more sophisticated realtime bidirectional communication between systems. Without this realtime communication method, often time the user can experience noticeable delays, leading to a suboptimal user experience; or worse, the information becomes out of context without notice and eventually causing wrong diagnosis.<br />
<br />
==3. Key Use Case==<br />
<br />
# Use Case 1: Interactive Multimedia Reporting<br />
<br />
A key element for interactive multimedia reporting is the ability to include clinical findings such as measurements, ROI,<br />
etc. with interactive links to the source images. Traditionally, these annotations, markups, presentation states, and<br />
key images could be captured as DICOM objects such as GSPS, SR, or KOS. These objects are designed to capture<br />
evidence for long-term reference instead of real-time communication or composition. Most PACS will create these<br />
evidence objects at the end of a session in order to capture all the data points created by the image-centric specialist<br />
in one object, rather than create multiple evidence objects resulting in one per data point. As a result, these evidence<br />
objects in DICOM are good resources for subsequent interactive access when viewing an IMR, but not good<br />
candidates as the payload for real-time communication during a reporting session. As the image-centric specialist<br />
captures measurements, regions of interest, and other data points, the PACS should provide those data points to the<br />
reporting system in real-time without introducing any unnecessary interruptions or adding transitory content to the<br />
permanent record.<br />
<br />
# Use Case 2: Context Sharing between EMR and Universal Viewer<br />
<br />
When an EMR launches an imaging viewer to show the study, the commands to launch the viewer usually includes the specific patient and study context. When the user switches to another study and/or patient, the EMR needs to communicate reliably the new context to the viewer to trigger loading of new study. Traditionally this context switching is done using vendor specific proprietary method. In additional, when the user no longer needs to show the patient's study, the EMR can send a command to the viewer to close the study in context.<br />
<br />
<br />
==4. Standards and Systems==<br />
<br />
Systems:<br />
<br />
* PACS (Image Manager and Image Display)<br />
* EMR<br />
* Dictation System (Report Creator)<br />
<br />
Standards:<br />
<br />
* [https://fhircast.org/ FHIRcast]<br />
* [http://build.fhir.org/ig/HL7/smart-web-messaging/smart-web-messaging.html HL7 Smart Web Messaging]<br />
<br />
==5. Discussion==<br />
<br />
* IHE IID is currently blocked by oustanding open CP regarding not having a method to open or close the context of the viewer. This can be addressed by this proposal and move IID to final text<br />
<br />
* IHE is a good venue because the need for such communication method is common and currently there are lots of proprietary integration for point-to-point integration.<br />
<br />
* FHIRcast has been successfully tested at FHIR Connectathon for a number of years. There is a growing number of adoption in application already.<br />
<br />
* FHIRcast has already defined a number of events (e.g. Patient-open/close, ImagingStudy-open/close) which are immediately applicable to some of the use cases mentioned above.</div>Khohttp://wiki.ihe.net/index.php?title=Radiology_Proposals_2022-2023&diff=128674Radiology Proposals 2022-20232022-08-04T16:58:00Z<p>Kho: /* Brief Proposals */</p>
<hr />
<div>{{TOCright}}<br />
<br />
===Final Selection===<br />
Final selection by the '''[[Rad_Plan_Minutes_2022-09-26|Planning Committee on Sept 26, 2022]]''' <br />
:* A. Maintenance (25%)<br />
<br />
===Effort Evaluations===<br />
The Technical Committee [[Proposal Effort Evaluation|evaluated the required effort]] of the Detailed Proposals as follows in tcons on [[Rad_Tech_Minutes_2022-08-29 | Aug 29]], [[Rad_Tech_Minutes_2022-08-31 | Aug 31]], & [[Rad_Tech_Minutes_2022-09-01 | Sept 1]].<br />
<br />
Assessments were captured in the new spreadsheet form. <br />
<br />
:* A. [[RAD TF Maintenance 2022-2023]]<br />
<br />
See [[Proposal Effort Evaluation#TC Review & Effort Estimation]] for evaluation guidance.<br />
<br />
===Short List/ Detailed Proposals===<br />
The Tech Cmte agreed to evaluate TBD number of proposals. The following Proposals were shortlisted by the [[Rad Plan Minutes 2022-08-10| Planning Committee on Aug 10, 2022]].<br />
<br />
:* A. Maintenance<br />
<br />
'''Editors''': by COB '''Aug 24''', 2022<br />
* '''Complete the Breakdown of Tasks''' with a strawman estimate of story points:<br />
:* [https://docs.google.com/spreadsheets/d/18wETLZhLYcXq5pOMfAhH8-Q4M5cKztj6QNUEOAcOnng/edit#gid=1166925166 BoD & Estimation - Google Sheet (Tab for each proposal)]<br />
* '''Expand your Brief Proposal''' to include Detailed Proposal elements<br />
:* Copy the [[Delta Proposal Template]] into the bottom of your proposal page<br />
:* Update as described in the Delta Template (adds Summary, Technical Details, Evaluation, etc.)<br />
:* Breakdown of Tasks is now covered in the Google Sheet (above)<br />
* Your goal is to give sufficient detail for the Tech Cmte to be able to evaluate the technical feasibility, specification tasks and effort required.<br />
<br />
'''Reviewers''': Feel free to enter comments under Risks and Decisions/Topics/Uncertainties section of the proposal<br />
<br />
Tech Cmte evaluations will be recorded at the bottom of each detailed proposal. The "Breakdown of Tasks" and "Story Point" refinements to the '''[[Proposal Effort Evaluation]]''' are in the Google Sheet.<br />
<br />
===Brief Proposals===<br />
:* A. Maintenance<br />
:* B. [[Enhanced SOLE for AI]]<br />
:* C. [[SWF on FHIR]]<br />
:* D. [[Realtime Communication]]<br />
<br />
Submission DEADLINE is '''August 5''', 2022, 11:59pm CT<br />
<br />
===Call for Proposals===<br />
Interested parties are invited to submit proposal pages based on the '''[[Brief Proposal Template]]'''.<br />
<br />
You are also welcome to update and resubmit proposals from '''[[Radiology Proposals 2021-2022|last year]]''' or earlier.<br />
<br />
Contact radiology@ihe.net with any questions.<br />
<br />
===Committee Links===<br />
<br />
[[Radiology Planning Committee]]<br />
<br />
[[Radiology Technical Committee]]</div>Khohttp://wiki.ihe.net/index.php?title=Rad_Tech_Agenda_2022-04-07&diff=128028Rad Tech Agenda 2022-04-072022-04-07T00:48:12Z<p>Kho: /* Agenda */</p>
<hr />
<div>==Agenda==<br />
<br />
--> [https://docs.google.com/spreadsheets/d/1TmSwnn4AIiXqFLc_AtzP0dNd9LUWnA-ZcCjBMKpLzp4/edit#gid=0 RAD CP Tracking Spreadsheet]<br />
<br />
<b>(1) Process Newly Submitted CPs:</b><br />
<br />
[https://drive.google.com/drive/folders/1CRrTYH4sCTK9pjWz67v3m6mjC0bYl_ol?usp=sharing Link to Submitted folder on Google Drive]<br />
<br />
* CP-RAD-474-Add-Series-Instance-Leve-Display-In-IID<br />
* CP-RAD-475-Add-Retrieve-Rendered-Images-in-WADO-RS<br />
* CP-RAD-451-FT-proposeToCancel<br />
* CP-RAD-JM-Small mistakes in Storage Commitment (Note: This CP is out of date with revisions to RAD-10 in RAD TF Rev 20 and may be able to be cancelled)<br />
* CP-RAD-xxx-CodeWhitePapater-outOfDate-statements<br />
* CP-RAD-xxx-MAWF-out-of-date-for RAD-13<br />
* CP-RAD-xxx-NMI-Card-fix-outOfDateCodes<br />
* CP-RAD-xxx-Out-of-Date-DICOM-references<br />
* CP-RAD-xxx-PWF really out of date<br />
* CP-RAD-xxx-RAD-60-reason-code-reference<br />
* CP-RAD-xxx-Vol2-No-MPI-out of date<br />
* CP-RAD-xxx-Vol4-newContactForIHE-F<br />
* CP-RAD-xxx-Update-RAD-108-Message-Semantics<br />
* CP-RAD-xxx-Vol1x-out-of-date<br />
* CP-RAD-DC-Code-WP-update<br />
* CP-RAD-DC-Vol2-Codes-update<br />
* CP-RAD-LF-EnterpriseIdentity-updates<br />
* CP-RAD-LF-Appx2x-fix<br />
<br />
<br />
<br />
<b>(2) Process Assigned CPs (time permitting):</b>.<br />
<br />
[https://drive.google.com/drive/folders/1CFxL_FrInp4mmQ5Zy-z3zfQBEbyZe9fv link to Assigned folder on Google Drive]<br />
<br />
* CP-RAD-347-01 - XDS-I Vol 1 clean-up<br />
* CP-RAD-468-01-WIC-updateSecurityConsiderations<br />
* CP-RAD-343-01 - Consistency in specification of PID segment & references to MPI<br />
** -- a few points for cmte discussion<br />
* CP-RAD-368-01 - Update/Remove MIMA Referenced in Vol 1 TF (editorial)<br />
** -- ready for cmte review; could be ready for ballot<br />
* CP-RAD-436-02 - Fix inconsistencies in IOCM actor / transaction and grouping requirements<br />
** -- cmte input needed<br />
* CP-RAD-305-02 - Revise profile dependencies (grouping) in Vol 1)<br />
** -- cmte input needed<br />
* CP-RAD-410-02 - XCA-I is out of date for Async</div>Khohttp://wiki.ihe.net/index.php?title=Rad_Joint_Meeting_Agenda_2021-11-30&diff=126938Rad Joint Meeting Agenda 2021-11-302021-11-30T17:10:31Z<p>Kho: /* Agenda */</p>
<hr />
<div>==Time and Location==<br />
:Tuesday, November 30, 2:30-3:45pm CST)<br />
:Room N128 - North Building, McCormick Place<br />
:Zoom sent via Outlook Calendar invitation<br />
<br />
==Agenda==<br />
<br />
*Introductions<br />
:*[https://docs.google.com/spreadsheets/d/198eCuMJcsMEWwtahidRLcMYzzIrte48CI7kuHbkpY-4/edit?usp=sharing IHE Radiology Technical and Planning Committee Roster]<br />
:*Name and [https://www.ihe.net/about_ihe/member_organizations/ IHE Member Organization]<br />
:*Review Radiology activities since 2020 [https://docs.google.com/presentation/d/1TP7Io9eN20dM97FnNOKgJkp7QPJTwzrE/edit?usp=sharing&ouid=106763211083690924606&rtpof=true&sd=true]<br />
:*Roundtable discussion<br />
** Leveraging the IHE Interoperability white paper. Focus on planning and scoping higher priority profiles. <br />
** Chris Roth to briefly comment on the pending calls with RIC IHE Subcommittee for AI Root Results and IMR.<br />
** Publicizing the profiles in a consumable way resonating to docs via PubMed (Radiographics?). Consider putting on January RIC retreat agenda and have a proposal as to which profiles we want to better publicize: AIW-I; AIR; CDS-OAT; EBIW; MAP; MRRT; IMR and AI Root Results<br />
*Recommendation from IHE Rad Tech to approve moving MRRT to Final Text pending 2 actions<br />
:*1. Kinson will finish 1 page wiki summary page overview<br />
:*2. Kinson will complete open issues in the supplement or create additional CPs</div>Khohttp://wiki.ihe.net/index.php?title=Rad_Joint_Meeting_Agenda_2021-11-30&diff=126934Rad Joint Meeting Agenda 2021-11-302021-11-30T16:58:20Z<p>Kho: /* Agenda */</p>
<hr />
<div>==Time and Location==<br />
:Tuesday, November 30, 2:30-3:45pm CST)<br />
:Room N128 - North Building, McCormick Place<br />
:Zoom sent via Outlook Calendar invitation<br />
<br />
==Agenda==<br />
<br />
*Introductions<br />
:*[https://docs.google.com/spreadsheets/d/198eCuMJcsMEWwtahidRLcMYzzIrte48CI7kuHbkpY-4/edit?usp=sharing IHE Radiology Technical and Planning Committee Roster]<br />
:*Name and [https://www.ihe.net/about_ihe/member_organizations/ IHE Member Organization]<br />
:*Review Radiology activities since 2020<br />
:*Roundtable discussion<br />
<br />
*Recommendation from IHE Rad Tech to approve moving MRRT to Final Text pending 2 actions<br />
:*1. Kinson will finish 1 page wiki summary page overview<br />
:*2. Kinson will complete open issues in the supplement or create additional CPs</div>Khohttp://wiki.ihe.net/index.php?title=Rad_Tech_Minutes_2021-11-15-19&diff=126836Rad Tech Minutes 2021-11-15-192021-11-19T19:37:13Z<p>Kho: /* Friday, November 19, 2021: 8:30am - 3:15pm Central Time (CT) */</p>
<hr />
<div>==Location==<br />
<br />
:* Virtual<br />
:* Via Zoom<br />
<br />
==Meeting Directory==<br />
:* [https://drive.google.com/drive/folders/1Su16aIkwLX9WQ1AN3DbINzRrCgpsKRgM?usp=sharing IHE Radiology 2022 Technical Committee Working Docs]<br />
<br />
==Topics==<br />
<br />
:* Interactive Multimedia Reporting (55%)<br />
:* AIR Datasets and Root Results (30%)<br />
:* Maintenance (25%) (for this meeting we will work at 15% for Maintenance)<br />
<br />
==Notes to Explain Agenda==<br />
<br />
:*(Number in parentheses is cumulative total hours for week)<br />
:*One action item that came out from the retrospective meeting is try to schedule some ‘editorial time’ vs ‘discussion time’.<br />
:**Discussion Time: Focus on the actual design discussion<br />
:**Editorial Time: Smaller group discussion with focus on getting the text in a good shape<br />
<br />
=='''Monday, November 15, 2021: 8:30am - 3:15pm Central Time (CT)'''==<br />
:*A1: 8:30am-9:00am Administrative Time <br />
:**Introductions (Name and IHE Member Organization)<br />
:**[https://docs.google.com/spreadsheets/d/198eCuMJcsMEWwtahidRLcMYzzIrte48CI7kuHbkpY-4/edit?usp=sharing IHE Radiology Technical Committee Roster]<br />
:***Wim Corbijn, Rad Tech Co-Chair, Philips<br />
:***Andrei Leontiev, Rad Tech Co-Chair, Visage Imaging<br />
:***Matt Hayes, Radiology Partners<br />
:***Kinson Ho, Change Healthcare<br />
:***David Kwan, Insygnia Consulting<br />
:***Chris Lindop, GE<br />
:***Weber Marrett, IBM Watson Health<br />
:***Steve Nichols, GE<br />
:***Kevin O'Donnell, Canon Medical<br />
:***Antje Schroeder, Siemens Healthineers<br />
:***Jonathan Whitby<br />
:***Khaled Younis, Philips<br />
:**Non-Voting<br />
:***Lynn Felhofer, IHE Radiology Technical Project Manager, IHE USA Contractor<br />
:***Nichole Knox, RSNA, IHE Radiology Secretary<br />
:**[https://www.ihe.net/about_ihe/member_organizations/ IHE International Member Organizations]<br />
:**[https://www.ihe.net/about_ihe/patent_disclosure_process/ IHE Patent Disclosure]<br />
:***No disclosures<br />
:*Brief description of IHE Radiology cycle and goal of this meeting (Kevin)<br />
:**Two profiles selected for development. IMR and AIR Datasets and Root Results. Maintenance will focus on new and existing Change Proposals (CPs).<br />
:**The kickoff meeting goal is to work on areas of uncertainty and agree to technology that will be used.<br />
:***February 7-11, 2022 meeting: Bulk of the profile should be completed by the end of the meeting. Review text and make sure complexity is correct. Then the document goes to Public Comment (PC)<br />
:***April 11-15, 2022 meeting: Review and resolve public comments and prepare documents for Trial Implementation.<br />
<br />
:*S1: 9:00am-10:30am: AIR Datasets and Root Results (AIR)<br />
:**Discussed scope and areas of uncertainty. Made notes directly in document. Continue discussion tomorrow.<br />
<br />
:**Introductions for IMR Session<br />
:***Wim Corbijn, Rad Tech Co-Chair, Philips<br />
:***Andrei Leontiev, Rad Tech Co-Chair, Visage Imaging<br />
:***Matt Hayes, Radiology Partners<br />
:***Kinson Ho, Change Healthcare<br />
:***David Kwan, Insygnia Consulting<br />
:***Chris Lindop, GE<br />
:***Weber Marrett, IBM Watson Health<br />
:***Steve Nichols, GE<br />
:***Kevin O'Donnell, Canon Medical<br />
:***Antje Schroeder, Siemens Healthineers<br />
:***Jonathan Whitby, Canon Medical<br />
:***Khaled Younis, Philips<br />
:**Non-Voting and Guests<br />
:***Alex Aisen, IU<br />
:***Daniel Bach<br />
:***Adam Cole, Smile CDR<br />
:***Lynn Felhofer, IHE Radiology Technical Project Manager, IHE USA Contractor<br />
:***Nichole Knox, RSNA, IHE Radiology Secretary<br />
:***Ed Sabean-Untermann, Smile CDR<br />
:***Sophie Tekeste, Smile CDR<br />
:***David Vining, MD, MD Anderson Cancer Center<br />
:**[https://www.ihe.net/about_ihe/patent_disclosure_process/ IHE Patent Disclosure]<br />
:***Disclosures from Dr. David Vining<br />
:****US Patent 6,785,410. Image reporting method and system. Inventors: David Vining, Yaorong Ge, David Ahn, David Stelts. Filed November 21, 2001. Issued August 31, 2004.<br />
:****US Patent 6,819,785. Image reporting method and system. Inventors: David Vining, Yaorong Ge, David Ahn, David Stelts. Filed August 9, 2000. Issued November 16, 2004.<br />
:****US Patent 7,289,651. Image reporting method and system. Inventors: David Vining, Yaorong Ge, David Ahn, David Stelts. Filed August 31, 2004. Issued October 30, 2007.<br />
:****US Patent 7,693,317. Image reporting method and system. Inventors: David Vining, Yaorong Ge, David Ahn, David Stelts. Filed November 12, 2004. Issued April 6, 2010.<br />
:****US Patent 7,835,560. Image reporting method and system. Inventors: David Vining, Yaorong Ge, David Ahn, David Stelts. Filed October 30, 2007. Issued November 16, 2010.<br />
:****US Patent 7,995,823. Image reporting method and system. Inventors: David Vining, Yaorong Ge, David Ahn, David Stelts. Filed November 16, 2010. Issued August 9, 2011.<br />
:****US Patent 8,320,651. Image<br />
<br />
:*S2: 10:45am-12:45pm: Interactive Multimedia Reporting (IMR)<br />
:*A2: 1:15pm-1:45pm: Administrative Time<br />
:*S3: 1:45pm-3:15pm: Interactive Multimedia Reporting (IMR)<br />
:**Get an overview of IMR, scope and questions to discuss and to be continued tomorrow.<br />
<br />
<br />
=='''Tuesday, November 16, 2021: 8:30am - 3:15pm Central Time (CT)'''==<br />
:*A1: 8:30am-9:00am Administrative Time<br />
:**Introductions (Name and IHE Member Organization)<br />
:**[https://docs.google.com/spreadsheets/d/198eCuMJcsMEWwtahidRLcMYzzIrte48CI7kuHbkpY-4/edit?usp=sharing IHE Radiology Technical Committee Roster]<br />
:**[https://www.ihe.net/about_ihe/member_organizations/ IHE International Member Organizations]<br />
:**[https://www.ihe.net/about_ihe/patent_disclosure_process/ IHE Patent Disclosure]<br />
:***Wim Corbijn, Rad Tech Co-Chair, Philips<br />
:***Andrei Leontiev, Rad Tech Co-Chair, Visage Imaging<br />
:***Chris Carr, RSNA<br />
:***Matt Hayes, Radiology Partners<br />
:***Kinson Ho, Change Healthcare<br />
:***David Kwan, Insygnia Consulting<br />
:***Chris Lindop, GE<br />
:***Weber Marrett, IBM Watson Health<br />
:***Steve Nichols, GE<br />
:***Kevin O'Donnell, Canon Medical<br />
:***Antje Schroeder, Siemens Healthineers<br />
:***Jonathan Whitby, Canon Medical<br />
:***Khaled Younis, Philips<br />
:**Non-Voting and Guests<br />
:***Alex Aisen, IU<br />
:***Daniel Bach<br />
:***Adam Cole, Smile CDR<br />
:***Lynn Felhofer, IHE Radiology Technical Project Manager, IHE USA Contractor<br />
:***Nichole Knox, RSNA, IHE Radiology Secretary<br />
:***Ed Sabean-Untermann, Smile CDR<br />
:***Sophie Tekeste, Smile CDR<br />
:*S1: 9:00am-10:30am: Maintenance <br />
:**IHE Sharazone Brief Introduction - Steven Nichols<br />
:***[[Media:IHE-SHARAZONE-Grand_Lauch-Overview-V7.pdf | Presentation]]<br />
:**[https://forms.gle/o3F5yzdPA9ksMcxXA IHE Radiology CP Ballot 2021D Form]<br />
:***Ballot email resent to rad tech on 11/16/21<br />
:*S2: 10:45am-12:45pm: Interactive Multimedia Reporting (IMR)<br />
:*A2: 1:15pm-1:45pm: Administrative Time<br />
:*S3: 1:45pm-2:45pm: AIR Datasets and Root Results (AIR)<br />
<br />
=='''Wednesday, November 17, 2021: 8:30 - 3:15pm Central Time (CT)'''==<br />
:*A1: 8:30am-9:00am Administrative Time<br />
:**Introductions (Name and IHE Member Organization)<br />
:**[https://docs.google.com/spreadsheets/d/198eCuMJcsMEWwtahidRLcMYzzIrte48CI7kuHbkpY-4/edit?usp=sharing IHE Radiology Technical Committee Roster]<br />
:**[https://www.ihe.net/about_ihe/member_organizations/ IHE International Member Organizations]<br />
:**IHE Patent Disclosure<br />
:***Wim Corbijn, Rad Tech Co-Chair, Philips<br />
:***Andrei Leontiev, Rad Tech Co-Chair, Visage Imaging<br />
:***Chris Lindop, GE<br />
:***Weber Marrett, IBM Watson Health<br />
:***Steve Nichols, GE<br />
:***Kevin O'Donnell, Canon Medical<br />
:***Antje Schroeder, Siemens Healthineers<br />
:***Jonathan Whitby, Canon Medical<br />
:***Khaled Younis, Philips<br />
:**Non-Voting and Guests<br />
:***Lynn Felhofer, IHE Radiology Technical Project Manager, IHE USA Contractor<br />
:***Nichole Knox, RSNA, IHE Radiology Secretary<br />
:*S1: 9:00am-10:30am: AIR Datasets and Root Results (AIR)<br />
:**[https://docs.google.com/spreadsheets/d/18wETLZhLYcXq5pOMfAhH8-Q4M5cKztj6QNUEOAcOnng/edit?usp=sharing Discussed all uncertainty point as described in this document]<br />
:*S2: 10:45am-12:45pm: Interactive Multimedia Reporting (IMR)<br />
:***Wim Corbijn, Rad Tech Co-Chair, Philips<br />
:***Andrei Leontiev, Rad Tech Co-Chair, Visage Imaging<br />
:***Chris Carr, RSNA<br />
:***Kinson Ho, Change Healthcare<br />
:***David Kwan, Insygnia Consulting<br />
:***Chris Lindop, GE<br />
:***Weber Marrett, IBM Watson Health<br />
:***Steve Nichols, GE<br />
:***Kevin O'Donnell, Canon Medical<br />
:***Antje Schroeder, Siemens Healthineers<br />
:***Jonathan Whitby, Canon Medical<br />
:***Khaled Younis, Philips<br />
:**Non-Voting and Guests<br />
:***Alex Aisen, IU<br />
:***Daniel Bach<br />
:***Adam Cole, Smile CDR<br />
:***Lynn Felhofer, IHE Radiology Technical Project Manager, IHE USA Contractor<br />
:***Nichole Knox, RSNA, IHE Radiology Secretary<br />
:***Ed Sabean-Untermann, Smile CDR<br />
:***Sophie Tekeste, Smile CDR<br />
:*A2: 1:15pm-1:45pm: Administrative Time - Steve Drew visit<br />
:*S3: 1:45pm-3:15pm: Interactive Multimedia Reporting (IMR)<br />
<br />
<br />
=='''Thursday, November 18, 2021: 8:30am - 3:15pm Central Time (CT)'''==<br />
:*A1: 8:30am-9:00am Administrative Time<br />
:**Introductions (Name and IHE Member Organization)<br />
:**[https://docs.google.com/spreadsheets/d/198eCuMJcsMEWwtahidRLcMYzzIrte48CI7kuHbkpY-4/edit?usp=sharing IHE Radiology Technical Committee Roster]<br />
:**Attendees<br />
:***Wim Corbijn, Rad Tech Co-Chair, Philips<br />
:***Andrei Leontiev, Rad Tech Co-Chair, Visage Imaging<br />
:***Alex Goel, Purajuniper<br />
:***Kinson Ho, Change Healthcare<br />
:***David Kwan, Insygnia Consulting<br />
:***Steve Nichols, GE<br />
:***Kevin O'Donnell, Canon Medical<br />
:***Antje Schroeder, Siemens Healthineers<br />
:***Jonathan Whitby, Canon Medical<br />
:**Non-Voting and Guests<br />
:***Daniel Bach, Smile CDR<br />
:***Lynn Felhofer, IHE Radiology Technical Project Manager, IHE USA Contractor<br />
:***Nichole Knox, RSNA, IHE Radiology Secretary<br />
:***Ed Sabean-Untermann, Smile CDR<br />
:***Sophie Tekeste, Smile CDR<br />
:**[https://www.ihe.net/about_ihe/member_organizations/ IHE International Member Organizations]<br />
:**IHE Patent Disclosure<br />
:*S1: 9:00am-10:30am: Interactive Multimedia Reporting (IMR)<br />
:*S2: 10:45am-12:45pm: Maintenance <br />
:*A2: 1:15pm-1:45pm: Joint meeting with PaLM domain regarding RPC profile<br />
:*S3: 1:45pm-3:15pm: AIR Datasets and Root Results (AIR)<br />
:*S3: 3:00pm - 3:15pm: Maintenance<br />
:**The following are in the Assigned folder for further work:<br />
:***CP-RAD-468-00 - WIC Update Security Considerations - assigned to Steve Nichols<br />
:**The following are Ready to publish in ballot. I put them in the Approved for Ballot > for 2021E folder. (Sorry to create a sub-folder, but there are left-over CPs from a previous in “Approved for Ballot” and I did not want to mix them together)<br />
:***CP-RAD-470-CM - Vol 4 URL fix<br />
:***CP-RAD-469-CM - WIC - Remove out-of-date options<br />
:***CP-RAD-473-CM - MAWF - fix out-of-date codes<br />
:***CP-RAD-466-CM - WIC - Update out-of-date language for RAD-108<br />
:***CP-RAD-462-CM - WIA - Update out-of-date language for RAD-108 and RA-129<br />
:**The following is in the Approved for Final Text folder. It will not be balloted because it is a update to a white paper:<br />
:***CP-RAD-472-FT - Fix out-of-date codes in white paper<br />
<br />
=='''Friday, November 19, 2021: 8:30am - 3:15pm Central Time (CT)'''==<br />
:*A1: 8:30am-9:00am Administrative Time<br />
:**Introductions (Name and IHE Member Organization)<br />
:**[https://docs.google.com/spreadsheets/d/198eCuMJcsMEWwtahidRLcMYzzIrte48CI7kuHbkpY-4/edit?usp=sharing IHE Radiology Technical Committee Roster]<br />
:**Attendees<br />
:***Wim Corbijn, Rad Tech Co-Chair, Philips<br />
:***Andrei Leontiev, Rad Tech Co-Chair, Visage Imaging<br />
:***Chris Lindop, GE<br />
:***Kinson Ho, Change Healthcare<br />
:***David Kwan, Insygnia Consulting<br />
:***Steve Nichols, GE<br />
:***Kevin O'Donnell, Canon Medical<br />
:***Antje Schroeder, Siemens Healthineers<br />
:**Non-Voting and Guests<br />
:***Daniel Bach, Smile CDR<br />
:***Lynn Felhofer, IHE Radiology Technical Project Manager, IHE USA Contractor<br />
:***Nichole Knox, RSNA, IHE Radiology Secretary<br />
:***Sophie Tekeste, Smile CDR<br />
:*S1: 9:00am-10:30am: Interactive Multimedia Reporting (IMR)<br />
:*S2: 10:45am-12:00pm: Interactive Multimedia Reporting (IMR) <br />
:*A2: 12:15pm-1:45pm: Administrative Time<br />
<br />
* Profile Name: AIR+<br />
** Describe gaps in Use Case coverage<br />
*** Split the use case into two chunks, but no gaps.<br />
** Review ALL "uncertainty points" in the evaluation. Is there a resolution plan for each?<br />
*** Yes, all reviewed. Each has a TODO text for resolution/next step.<br />
** Do the effort points in the evaluation still seem right? <br />
*** Mostly yes, little adjustments. But the examples are likely a bit more than a 2.<br />
** Did the Breakdown of Tasks accurately reflect the work? What extra tasks arose?<br />
*** Accurate.<br />
** Describe unresolved technical issues/tasks<br />
*** Some will derive from the feedback from the "focus group". Mostly well in hand.<br />
** Describe potential practical issues<br />
*** Will need to get tooling for example object generation.<br />
** Review the open issue list. Does it feel complete<br />
*** Will populate OI for PC. Most other questions are in the TODO plans. Feels complete.<br />
** Which open issues feel most risky; what other risks exist?<br />
*** Main risk might be aggressive expectations for display capabilities from the focus group<br />
*** Also risk of not being able to pull focus group together quickly (get on it now)<br />
*** Potential for examples to experience gold-plating/runaway complexity<br />
** How is the work fitting in the allocated bandwidth? (Time to spare? Just right? Things were left undone?)<br />
*** A bit of time to spare (partly because deferred a slot to a future tcon)<br />
** How does the scope feel? (Room to expand? Just right? Pretty ambitious?)<br />
*** Feels good.<br />
** If you had to reduce scope, what would you drop?<br />
*** Binary examples. (if need to drop more, would drop some paper examples)<br />
** Have the promised resources manifested?<br />
*** Mostly, will look for focus participants and help with tooling.<br />
** What tasks would benefit from additional expertise?<br />
*** Need good focus groups participants and experience with creating objects.<br />
** What vendors are engaged for each actor? Record how many.<br />
*** Evidence Creators: Canon, Philips?, GE, Siemens, <br />
*** Image Displays: Canon, Philips, GE, Siemens, <br />
** Was the profile where it needed to be at the start of the Kickoff meeting (See "Kickoff Meeting" above), if not what was the gap<br />
*** Yes. <br />
** Was the profile where it needed to be at the end of the Kickoff meeting, if not what was the gap<br />
*** Mostly. Will do some work based on the initial input for the next tcon<br />
** How many tcons would you like between now and the PC Prep Meeting?<br />
*** One or two. (The focus group will be separate)<br />
<br />
* Profile Name: IMR<br />
** Describe gaps in Use Case coverage<br />
*** Working on clarification of how the multimedia capability relate to structured part of the report.<br />
*** otherwise, cover the creation and display use cases, and several variations of the display use cases<br />
** Review ALL "uncertainty points" in the evaluation. Is there a resolution plan for each?<br />
*** Review the updated IMR design with the IMR working group<br />
*** Continue to develop and review the information model (important to clarify what is in scope and out of scope)<br />
*** Terminology clarification for 'structured' (coded vs conceptual sections vs ...)<br />
*** Continue to refine how we will profile DiagnosticReport and certain specific details (e.g. what and how different contents go into conclusion)<br />
** Do the effort points in the evaluation still seem right?<br />
*** Effort may be a bit low, but with the complexity point as a buffer, the total is still in the ballpark<br />
** Did the Breakdown of Tasks accurately reflect the work? What extra tasks arose?<br />
*** Mostly.<br />
*** Should have called out the information model explicitly<br />
** Describe unresolved technical issues/tasks<br />
*** Work through the DiagnosticReport mapping and how the presentedForm is created and corresponds to the content exist in the DiagnosticReport resource<br />
** Describe potential practical issues<br />
*** How to 'allow' sections in report without explicitly profiling them<br />
*** New to profiling FHIR resources by the Rad Tech<br />
** Review the open issue list. Does it feel complete<br />
*** Good list of questions in the powerpoint to guide the discussion and capture resolution and action items<br />
** Which open issues feel most risky; what other risks exist?<br />
*** DiagnosticReport mapping<br />
*** How to profile FHIR resources, what constraints IMR need to impose on each resource<br />
** How is the work fitting in the allocated bandwidth? (Time to spare? Just right? Things were left undone?)<br />
*** Would be better if a few more items were identified early and prepared ahead of time so we can discuss during the meeting (e.g. model mapping, FHIR resource packaging)<br />
*** otherwise, time are okay.<br />
** How does the scope feel? (Room to expand? Just right? Pretty ambitious?)<br />
*** Feel right from the perspective of what is requested to support interactive multimedia report with reasonable effort<br />
*** Feel tricky that without full profiling radiology reports using FHIR, there may be gaps unidentified<br />
*** Encourages Report Creator implementation to make up missing bits on their own<br />
** If you had to reduce scope, what would you drop?<br />
*** PDF option<br />
*** look at the different named options what can be dropped in what order<br />
** Have the promised resources manifested?<br />
*** Yes, David Kwon, Dr. David Vining, representatives from Smile CDR, and others from the IMR working group<br />
** What tasks would benefit from additional expertise?<br />
*** Content mapping<br />
*** FHIR mapping / profiling<br />
** What vendors are engaged for each actor? Record how many.<br />
*** Report Creator: Dr. David Vining, Smile CDR, Carestream, GE?<br />
*** Report Reader: Change Healthcare, Carestream, Smile CDR, Dr. David Vining, <br />
*** Image Display: Change Healthcare, GE?<br />
*** Image Manager: Change Healthcare,<br />
** Was the profile where it needed to be at the start of the Kickoff meeting (See "Kickoff Meeting" above), if not what was the gap<br />
*** A bit behind because the profile document is barely started<br />
** Was the profile where it needed to be at the end of the Kickoff meeting, if not what was the gap<br />
*** Collected good feedback on all open questions. Enough materials to start<br />
** How many tcons would you like between now and the PC Prep Meeting?<br />
*** Should schedule 1 or 2 meetings to review work-in-progress and confirm resolution to remaining uncertainties<br />
*** Meetings with the IMR working group</div>Khohttp://wiki.ihe.net/index.php?title=MRRT_FT_Evaluation&diff=121608MRRT FT Evaluation2020-06-15T15:27:31Z<p>Kho: /* Planning Committee Checklist */</p>
<hr />
<div>==Proposal==<br />
The Management of Radiology Report Template (MRRT) profile has been nominated for advancement to Final Text. (Advocate: Kinson Ho)<br />
Per the [[Final Text Process]], <font color="blue">Items in blue text</font> below warrant Committee discussion.<br />
<br />
== Technical Committee Checklist ==<br />
<br />
* Are all significant CPs against the profile "closed"<br />
::* Yes. Significant CPs identified and addressed. See [ftp://ftp.ihe.net/Radiology/TF_Maintenance/2_Ready%20to%20Publish%20in%20Ballot/]<br />
<br />
* Are all significant CPs against the underlying standards "closed"?<br />
::* There are no significant CPs against the underlying standards (HTML5, HTTPS, Dublin Core)<br />
<br />
* Have all significant comments been CP'd or rejected?<br />
::* Yes, specifically the following CPs are rejected as we decided to leave those advanced features out of MRRT. Alternative solutions like IHE QRPH Structured Data Capture (SDC) can be used that has already provided these advanced features<br />
:::* '''TODO''' CP-RAD-307 Add Conditional data-field-completion attributes in MRRT<br />
:::* '''TODO''' CP-RAD-308 Add Business Names to MRRT template format<br />
::* The following CPs are rejected as identified out of scope of MRRT but implementation can support them<br />
:::* CP-RAD-412 Support optional use of javascript in MRRT<br />
<br />
* Have all open issues listed in the Supplement been closed?<br />
::* Yes<br />
<br />
* Have all significant issues at Connectathon been dealt with?<br />
::* Yes<br />
<br />
* Gather feedback from implementers via a [ftp://ftp.ihe.net/Connectathon/IHE%20Vendor%20Questionnaire%20V0.4.doc formal questionnaire to Connectathon participants]<br />
::* radreport.org used MRRT format for its report template. The templates have significant number of downloads [[https://radreport.org/metrics]]<br />
:::* According to Dr. Charles Kahn, the counter only includes downloads of the revised website, excluding 5 million downloads already at the original site<br />
::* T-REX, a report template creator tool, is available at radreport.org to create radiology report template that are compliant with MRRT<br />
:::* According to Dr. Charles Kahn, T-REX is also actively being used to create new templates<br />
::* Prof. Mildenberger published a paper regarding MRRT [[https://epos.myesr.org/poster/esr/eurosafeimaging2016/ESI-0025]]<br />
<br />
* Has the Connectathon Project Manager been queried and significant issues addressed?<br />
::* Yes<br />
<br />
== Technical Committee Consensus==<br />
:* '''TODO:''' The Technical Committee agreed to continue with the Final Text Process and continue with an evaluation by the Planning Committee<br />
<br />
== Planning Committee Checklist ==<br />
<br />
* Has the profile been through a Connectathon in at least two regions?<br />
::* No. There is one successful testing done in NA2016. Here are additional comments from Lynn<br />
:::* Siemens successfully tested the Report Creator with one Report Template Mgr partner (Sectra); this included [RAD-105] Query Img Report Templates, and [RAD-103] Retrieve Img Report Templates<br />
:::* Thus, Sectra successfully tested the Report Template Manager with Siemens for [RAD-103] and [RAD-105]. However, since there was no Report Template Creator test partner, Sectra was not able to test [RAD-104] Store Imaging Report Template.<br />
:::* We had no Report Template Creator test partner. <br />
:::* We have a set of MRRT Report templates that we used in the test scenario. They are now stored on the IHE Google Drive here. That test data has not been re-assessed for any updates that need to be done due to CPs processed since 2016.<br />
<br />
* Has the profile been successfully tested with all actors at least at one Connectathon?<br />
::* No. Only Report Template Manager and Report Creator were tested, but no Report Template Creator.<br />
:::* However, there exist T-REX at radreport.org which is a Report Template Creator.<br />
<br />
<br />
* Have different implementations of each actor in the profile been tested?<br />
::* No. Only one implementation for Report Template Manager and one implementation for Report Creator was tested.<br />
<br />
* Have all the options been tested successfully at at least one Connectathon?<br />
::* N/A. No options available in MRRT<br />
<br />
* Are there IHE-provided software testing tools to address all aspects of the profile?<br />
::* No testing tools available, besides the sample report templates mentioned above (extracted from radreport.org)<br />
<br />
* Have the standards underlying the profile been implemented? In similar use cases? In healthcare? In general IT?<br />
::* Yes, HTML5 and HTTP(S) are widely implemented.<br />
<br />
* (Do you have concrete reason to believe that this works robustly in the Real World) / (Are any products available for purchase that implement the profile?)<br />
::* Yes<br />
:::* From Prof. Mildenberger:<br />
::::* one is actually implementing a solution (goal Q4/2020), which will provide all three actors and also will support the import/export of MRRT compliant templates. This company is already aiming for connectathon partizipation<br />
::::* one company does have a PoC implementation supporting ReportCreator, not yet transferred in a product<br />
::::* one company does actually using their proporietory structur, but is analyzing options for compatibility (all three actors in principle). Actually, a manuel import for MRRT templates is supported.. Partizipation at connectathon might be a topic for the future.<br />
::::* another company (international PACS provider with reporting solution): structured reporting will be integrated actually, MRRT compatibility planned (personal communication, e-mail not yet received)<br />
:::* From Dr. Kahn, SmartRadiology and Sectra has expressed interest in using MRRT (and Sectra has tested at Connectathon)<br />
<br />
* Have all issues that may have been raised about the profile been resolved?<br />
::* Yes, all significant issues have been addressed<br />
::* The following issues are rejected<br />
:::* Conditional statements (CP-RAD-307) - defer to other alternatives such as IHE QRPH SDC<br />
:::* Support for javascript (CP-RAD-412) - Implementation details, cannot be standardized. Leave it out as implementation decision<br />
:::* Support for image link - discussed and decided to defer<br />
:::* Support for repeated statements - discussed and defer to other alternatives such as IHE QRPH SDC<br />
<br />
* Has there been sufficient interest in the profile to generate a one-page [[Profiles|overview of the profile]]<br />
:::* Yes, '''TODO''' see [https://wiki.ihe.net/index.php/Management_of_Radiology_Report_Templates]</div>Khohttp://wiki.ihe.net/index.php?title=MRRT_FT_Evaluation&diff=121542MRRT FT Evaluation2020-06-08T01:57:49Z<p>Kho: /* Planning Committee Checklist */</p>
<hr />
<div>==Proposal==<br />
The Management of Radiology Report Template (MRRT) profile has been nominated for advancement to Final Text. (Advocate: Kinson Ho)<br />
Per the [[Final Text Process]], <font color="blue">Items in blue text</font> below warrant Committee discussion.<br />
<br />
== Technical Committee Checklist ==<br />
<br />
* Are all significant CPs against the profile "closed"<br />
::* Yes. Significant CPs identified and addressed. See [ftp://ftp.ihe.net/Radiology/TF_Maintenance/2_Ready%20to%20Publish%20in%20Ballot/]<br />
<br />
* Are all significant CPs against the underlying standards "closed"?<br />
::* There are no significant CPs against the underlying standards (HTML5, HTTPS, Dublin Core)<br />
<br />
* Have all significant comments been CP'd or rejected?<br />
::* Yes, specifically the following CPs are rejected as we decided to leave those advanced features out of MRRT. Alternative solutions like IHE QRPH Structured Data Capture (SDC) can be used that has already provided these advanced features<br />
:::* '''TODO''' CP-RAD-307 Add Conditional data-field-completion attributes in MRRT<br />
:::* '''TODO''' CP-RAD-308 Add Business Names to MRRT template format<br />
::* The following CPs are rejected as identified out of scope of MRRT but implementation can support them<br />
:::* CP-RAD-412 Support optional use of javascript in MRRT<br />
<br />
* Have all open issues listed in the Supplement been closed?<br />
::* Yes<br />
<br />
* Have all significant issues at Connectathon been dealt with?<br />
::* Yes<br />
<br />
* Gather feedback from implementers via a [ftp://ftp.ihe.net/Connectathon/IHE%20Vendor%20Questionnaire%20V0.4.doc formal questionnaire to Connectathon participants]<br />
::* radreport.org used MRRT format for its report template. The templates have significant number of downloads [[https://radreport.org/metrics]]<br />
:::* According to Dr. Charles Kahn, the counter only includes downloads of the revised website, excluding 5 million downloads already at the original site<br />
::* T-REX, a report template creator tool, is available at radreport.org to create radiology report template that are compliant with MRRT<br />
:::* According to Dr. Charles Kahn, T-REX is also actively being used to create new templates<br />
::* Prof. Mildenberger published a paper regarding MRRT [[https://epos.myesr.org/poster/esr/eurosafeimaging2016/ESI-0025]]<br />
<br />
* Has the Connectathon Project Manager been queried and significant issues addressed?<br />
::* Yes<br />
<br />
== Technical Committee Consensus==<br />
:* '''TODO:''' The Technical Committee agreed to continue with the Final Text Process and continue with an evaluation by the Planning Committee<br />
<br />
== Planning Committee Checklist ==<br />
<br />
* Has the profile been through a Connectathon in at least two regions?<br />
::* No. There is one successful testing done in NA2016. Here are additional comments from Lynn<br />
:::* Siemens successfully tested the Report Creator with one Report Template Mgr partner (Sectra); this included [RAD-105] Query Img Report Templates, and [RAD-103] Retrieve Img Report Templates<br />
:::* Thus, Sectra successfully tested the Report Template Manager with Siemens for [RAD-103] and [RAD-105]. However, since there was no Report Template Creator test partner, Sectra was not able to test [RAD-104] Store Imaging Report Template.<br />
:::* We had no Report Template Creator test partner. <br />
:::* We have a set of MRRT Report templates that we used in the test scenario. They are now stored on the IHE Google Drive here. That test data has not been re-assessed for any updates that need to be done due to CPs processed since 2016.<br />
<br />
* Has the profile been successfully tested with all actors at least at one Connectathon?<br />
::* No. Only Report Template Manager and Report Creator were tested, but no Report Template Creator.<br />
:::* However, there exist T-REX at radreport.org which is a Report Template Creator.<br />
<br />
<br />
* Have different implementations of each actor in the profile been tested?<br />
::* No. Only one implementation for Report Template Manager and one implementation for Report Creator was tested.<br />
<br />
* Have all the options been tested successfully at at least one Connectathon?<br />
::* N/A. No options available in MRRT<br />
<br />
* Are there IHE-provided software testing tools to address all aspects of the profile?<br />
::* No testing tools available, besides the sample report templates mentioned above (extracted from radreport.org)<br />
<br />
* Have the standards underlying the profile been implemented? In similar use cases? In healthcare? In general IT?<br />
::* Yes, HTML5 and HTTP(S) are widely implemented.<br />
<br />
* (Do you have concrete reason to believe that this works robustly in the Real World) / (Are any products available for purchase that implement the profile?)<br />
::* Yes<br />
:::* '''TODO''' Prof. Mildenberger provides additional evidence of implementation.<br />
:::* From Dr. Kahn, SmartRadiology and Sectra has expressed interest in using MRRT (and Sectra has tested at Connectathon)<br />
<br />
* Have all issues that may have been raised about the profile been resolved?<br />
::* Yes, all significant issues have been addressed<br />
::* The following issues are rejected<br />
:::* Conditional statements (CP-RAD-307) - defer to other alternatives such as IHE QRPH SDC<br />
:::* Support for javascript (CP-RAD-412) - Implementation details, cannot be standardized. Leave it out as implementation decision<br />
:::* Support for image link - discussed and decided to defer<br />
:::* Support for repeated statements - discussed and defer to other alternatives such as IHE QRPH SDC<br />
<br />
* Has there been sufficient interest in the profile to generate a one-page [[Profiles|overview of the profile]]<br />
:::* Yes, '''TODO''' see [https://wiki.ihe.net/index.php/Management_of_Radiology_Report_Templates]</div>Khohttp://wiki.ihe.net/index.php?title=MRRT_FT_Evaluation&diff=121541MRRT FT Evaluation2020-06-07T18:31:43Z<p>Kho: /* Technical Committee Checklist */</p>
<hr />
<div>==Proposal==<br />
The Management of Radiology Report Template (MRRT) profile has been nominated for advancement to Final Text. (Advocate: Kinson Ho)<br />
Per the [[Final Text Process]], <font color="blue">Items in blue text</font> below warrant Committee discussion.<br />
<br />
== Technical Committee Checklist ==<br />
<br />
* Are all significant CPs against the profile "closed"<br />
::* Yes. Significant CPs identified and addressed. See [ftp://ftp.ihe.net/Radiology/TF_Maintenance/2_Ready%20to%20Publish%20in%20Ballot/]<br />
<br />
* Are all significant CPs against the underlying standards "closed"?<br />
::* There are no significant CPs against the underlying standards (HTML5, HTTPS, Dublin Core)<br />
<br />
* Have all significant comments been CP'd or rejected?<br />
::* Yes, specifically the following CPs are rejected as we decided to leave those advanced features out of MRRT. Alternative solutions like IHE QRPH Structured Data Capture (SDC) can be used that has already provided these advanced features<br />
:::* '''TODO''' CP-RAD-307 Add Conditional data-field-completion attributes in MRRT<br />
:::* '''TODO''' CP-RAD-308 Add Business Names to MRRT template format<br />
::* The following CPs are rejected as identified out of scope of MRRT but implementation can support them<br />
:::* CP-RAD-412 Support optional use of javascript in MRRT<br />
<br />
* Have all open issues listed in the Supplement been closed?<br />
::* Yes<br />
<br />
* Have all significant issues at Connectathon been dealt with?<br />
::* Yes<br />
<br />
* Gather feedback from implementers via a [ftp://ftp.ihe.net/Connectathon/IHE%20Vendor%20Questionnaire%20V0.4.doc formal questionnaire to Connectathon participants]<br />
::* radreport.org used MRRT format for its report template. The templates have significant number of downloads [[https://radreport.org/metrics]]<br />
:::* According to Dr. Charles Kahn, the counter only includes downloads of the revised website, excluding 5 million downloads already at the original site<br />
::* T-REX, a report template creator tool, is available at radreport.org to create radiology report template that are compliant with MRRT<br />
:::* According to Dr. Charles Kahn, T-REX is also actively being used to create new templates<br />
::* Prof. Mildenberger published a paper regarding MRRT [[https://epos.myesr.org/poster/esr/eurosafeimaging2016/ESI-0025]]<br />
<br />
* Has the Connectathon Project Manager been queried and significant issues addressed?<br />
::* Yes<br />
<br />
== Technical Committee Consensus==<br />
:* '''TODO:''' The Technical Committee agreed to continue with the Final Text Process and continue with an evaluation by the Planning Committee<br />
<br />
== Planning Committee Checklist ==<br />
<br />
* Has the profile been through a Connectathon in at least two regions?<br />
::* No. There is one successful testing done in NA2016. Here are additional comments from Lynn<br />
:::* Siemens successfully tested the Report Creator with one Report Template Mgr partner (Sectra); this included [RAD-105] Query Img Report Templates, and [RAD-103] Retrieve Img Report Templates<br />
:::* Thus, Sectra successfully tested the Report Template Manager with Siemens for [RAD-103] and [RAD-105]. However, since there was no Report Template Creator test partner, Sectra was not able to test [RAD-104] Store Imaging Report Template.<br />
:::* We had no Report Template Creator test partner. <br />
:::* We have a set of MRRT Report templates that we used in the test scenario. They are now stored on the IHE Google Drive here. That test data has not been re-assessed for any updates that need to be done due to CPs processed since 2016.<br />
<br />
* Has the profile been successfully tested with all actors at least at one Connectathon?<br />
::* No. Only Report Template Manager and Report Creator were tested, but no Report Template Creator.<br />
:::* However, there exist T-REX at radreport.org which is a Report Template Creator.<br />
<br />
<br />
* Have different implementations of each actor in the profile been tested?<br />
::* No. Only one implementation for Report Template Manager and one implementation for Report Creator was tested.<br />
<br />
* Have all the options been tested successfully at at least one Connectathon?<br />
::* N/A. No options available in MRRT<br />
<br />
* Are there IHE-provided software testing tools to address all aspects of the profile?<br />
::* No testing tools available, besides the sample report templates mentioned above (extracted from radreport.org)<br />
<br />
* Have the standards underlying the profile been implemented? In similar use cases? In healthcare? In general IT?<br />
::* Yes, HTML5 and HTTP(S) are widely implemented.<br />
<br />
* (Do you have concrete reason to believe that this works robustly in the Real World) / (Are any products available for purchase that implement the profile?)<br />
::* Yes<br />
:::* '''TODO''' Prof. Mildenberger provides additional evidence of implementation.<br />
<br />
* Have all issues that may have been raised about the profile been resolved?<br />
::* Yes, all significant issues have been addressed<br />
::* The following issues are rejected<br />
:::* Conditional statements (CP-RAD-307) - defer to other alternatives such as IHE QRPH SDC<br />
:::* Support for javascript (CP-RAD-412) - Implementation details, cannot be standardized. Leave it out as implementation decision<br />
:::* Support for image link - discussed and decided to defer<br />
:::* Support for repeated statements - discussed and defer to other alternatives such as IHE QRPH SDC<br />
<br />
* Has there been sufficient interest in the profile to generate a one-page [[Profiles|overview of the profile]]<br />
:::* Yes, '''TODO''' see [https://wiki.ihe.net/index.php/Management_of_Radiology_Report_Templates]</div>Khohttp://wiki.ihe.net/index.php?title=MRRT_FT_Evaluation&diff=121540MRRT FT Evaluation2020-06-06T16:16:17Z<p>Kho: </p>
<hr />
<div>==Proposal==<br />
The Management of Radiology Report Template (MRRT) profile has been nominated for advancement to Final Text. (Advocate: Kinson Ho)<br />
Per the [[Final Text Process]], <font color="blue">Items in blue text</font> below warrant Committee discussion.<br />
<br />
== Technical Committee Checklist ==<br />
<br />
* Are all significant CPs against the profile "closed"<br />
::* Yes. Significant CPs identified and addressed. See [ftp://ftp.ihe.net/Radiology/TF_Maintenance/2_Ready%20to%20Publish%20in%20Ballot/]<br />
<br />
* Are all significant CPs against the underlying standards "closed"?<br />
::* There are no significant CPs against the underlying standards (HTML5, HTTPS, Dublin Core)<br />
<br />
* Have all significant comments been CP'd or rejected?<br />
::* Yes, specifically the following CPs are rejected as we decided to leave those advanced features out of MRRT. Alternative solutions like IHE QRPH Structured Data Capture (SDC) can be used that has already provided these advanced features<br />
:::* '''TODO''' CP-RAD-307 Add Conditional data-field-completion attributes in MRRT<br />
:::* '''TODO''' CP-RAD-308 Add Business Names to MRRT template format<br />
::* The following CPs are rejected as identified out of scope of MRRT but implementation can support them<br />
:::* CP-RAD-412 Support optional use of javascript in MRRT<br />
<br />
* Have all open issues listed in the Supplement been closed?<br />
::* Yes<br />
<br />
* Have all significant issues at Connectathon been dealt with?<br />
::* Yes<br />
<br />
* Gather feedback from implementers via a [ftp://ftp.ihe.net/Connectathon/IHE%20Vendor%20Questionnaire%20V0.4.doc formal questionnaire to Connectathon participants]<br />
::* radreport.org used MRRT format for its report template. The templates have significant number of downloads [[https://radreport.org/metrics]]<br />
::* T-REX, a report template creator tool, is available at radreport.org to create radiology report template that are compliant with MRRT<br />
::* Prof. Mildenberger published a paper regarding MRRT [[https://epos.myesr.org/poster/esr/eurosafeimaging2016/ESI-0025]]<br />
<br />
* Has the Connectathon Project Manager been queried and significant issues addressed?<br />
::* Yes<br />
<br />
== Technical Committee Consensus==<br />
:* '''TODO:''' The Technical Committee agreed to continue with the Final Text Process and continue with an evaluation by the Planning Committee<br />
<br />
== Planning Committee Checklist ==<br />
<br />
* Has the profile been through a Connectathon in at least two regions?<br />
::* No. There is one successful testing done in NA2016. Here are additional comments from Lynn<br />
:::* Siemens successfully tested the Report Creator with one Report Template Mgr partner (Sectra); this included [RAD-105] Query Img Report Templates, and [RAD-103] Retrieve Img Report Templates<br />
:::* Thus, Sectra successfully tested the Report Template Manager with Siemens for [RAD-103] and [RAD-105]. However, since there was no Report Template Creator test partner, Sectra was not able to test [RAD-104] Store Imaging Report Template.<br />
:::* We had no Report Template Creator test partner. <br />
:::* We have a set of MRRT Report templates that we used in the test scenario. They are now stored on the IHE Google Drive here. That test data has not been re-assessed for any updates that need to be done due to CPs processed since 2016.<br />
<br />
* Has the profile been successfully tested with all actors at least at one Connectathon?<br />
::* No. Only Report Template Manager and Report Creator were tested, but no Report Template Creator.<br />
:::* However, there exist T-REX at radreport.org which is a Report Template Creator.<br />
<br />
<br />
* Have different implementations of each actor in the profile been tested?<br />
::* No. Only one implementation for Report Template Manager and one implementation for Report Creator was tested.<br />
<br />
* Have all the options been tested successfully at at least one Connectathon?<br />
::* N/A. No options available in MRRT<br />
<br />
* Are there IHE-provided software testing tools to address all aspects of the profile?<br />
::* No testing tools available, besides the sample report templates mentioned above (extracted from radreport.org)<br />
<br />
* Have the standards underlying the profile been implemented? In similar use cases? In healthcare? In general IT?<br />
::* Yes, HTML5 and HTTP(S) are widely implemented.<br />
<br />
* (Do you have concrete reason to believe that this works robustly in the Real World) / (Are any products available for purchase that implement the profile?)<br />
::* Yes<br />
:::* '''TODO''' Prof. Mildenberger provides additional evidence of implementation.<br />
<br />
* Have all issues that may have been raised about the profile been resolved?<br />
::* Yes, all significant issues have been addressed<br />
::* The following issues are rejected<br />
:::* Conditional statements (CP-RAD-307) - defer to other alternatives such as IHE QRPH SDC<br />
:::* Support for javascript (CP-RAD-412) - Implementation details, cannot be standardized. Leave it out as implementation decision<br />
:::* Support for image link - discussed and decided to defer<br />
:::* Support for repeated statements - discussed and defer to other alternatives such as IHE QRPH SDC<br />
<br />
* Has there been sufficient interest in the profile to generate a one-page [[Profiles|overview of the profile]]<br />
:::* Yes, '''TODO''' see [https://wiki.ihe.net/index.php/Management_of_Radiology_Report_Templates]</div>Kho