http://wiki.ihe.net/api.php?action=feedcontributions&user=Terisippel&feedformat=atomIHE Wiki - User contributions [en]2024-03-29T14:58:31ZUser contributionsMediaWiki 1.35.5http://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=111346Follow-up of Non Critical Actionable Findings - Proposal2018-09-07T19:59:20Z<p>Terisippel: </p>
<hr />
<div>__NOTOC__<br />
<br />
<br />
==1. Proposed Workitem: Completion of FUNC (Follow-Up of Non-Critical Actionable Findings) ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Proposal Contributors:<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Contributors:<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
The FUNC profile was underestimated in 2016. As a result, Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses are no less relevant or important than when the workitem was originally selected.<br />
<br />
'''Current state of FUNC'''<br />
:The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
:'''FUNC Volume 1:''' The use cases and background material are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
<br />
:'''FUNC Volume 2:''' The basic architecture has been determined; after intense and lengthy discussions; the "Alert Reporter" actor is effectively also a FHIR server. Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussion as FHIR has evolved significantly in the last two years.<br />
<br />
'''FUNC clinical problem statement:''' (Taken from Volume 1)<br />
<br />
:In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications between affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover notifications sent between distinct ''unaffiliated'' facilities.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 ("non-critical actionable") findings. ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are not addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is currently an HL7 v2.5.1. order message (ORM). (RAD-Y2 and RAD-Y5) which needs to be migrated to FHIR v4.<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources. (RAD-Y3 and RAD-Y4)<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 (RAD-128) transaction have been moved to the Results Distribution (RD) profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter - new to Radiology, from mACM<br />
::* Alert Aggregator - new to Radiology, from mACM<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-128 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
::* RAD-Y3 Send Followup Alert (FHIR)<br />
::* RAD-Y4 Acknowledge Followup Alert (FHIR)<br />
::* RAD-Y2 Initiate Followup Alert Plan (HL7v2 ORM or FHIR)<br />
::* RAD-Y5 Close Followup Alert Plan (HL7v2 ORM or FHIR)<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:* none<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
'''Transactions'''<br />
:*Trigger transaction: (MinUE)<br />
::*RAD-128 Send Result - complete, may need a CP, but not aware of any<br />
:::*assume done<br />
:*Radiology department transactions: (MinUE)<br />
::* RAD-Y2 Initiate Followup Alert Plan (decision: FHIR v4)<br />
:::*SP effort 3<br />
:::*SP complexity 2<br />
:::*SP uncertainty 2<br />
::* RAD-Y5 Close Followup Alert Plan (decision: FHIR v4)<br />
:::*SP effort 2<br />
:::*makes assumption that RAD-Y5 is very similar to RAD-Y2<br />
:::*makes assumption that semantics exist in HL7 v2 ORM message in current draft FUNC supplement<br />
:*Cross enterprise transactions: (MaxUE)<br />
::* RAD-Y3 Send Followup Alert (FHIR v4 w/ mACM)<br />
:::*SP effort 2<br />
:::*SP complexity 2 (cross enterprise messaging -authorization)<br />
:::*SP uncertainty 2 (specifically going to v4 and mACM yet to be re-published with v4 updates)<br />
::* RAD-Y4 Acknowledge Followup Alert (FHIR v4)<br />
:::*SP effort 1<br />
:::*SP complexity 1<br />
<br />
<br />
<br />
'''Profile'''<br />
<br />
:* We estimate that FUNC Volume 1 development (writing) is 60% complete to get to Public Comment.<br />
:::*SP effort 3<br />
:::*SP complexity 1<br />
:::*SP uncertainty 0<br />
::*One primary Use Case with variants<br />
:::*SP effort 2 (MinUE)<br />
:::*SP complexity 3 (MinUE -2; Max UE-3)<br />
::*Options<br />
:::* none<br />
<br />
<br />
'''Topics/Debates'''<br />
::* how close to follow mACM? (MinUE)<br />
:::*SP uncertainty 1<br />
::* define boundaries of robustness (ie., fallback mechanisms; set up conscious boundary) (MinUE)<br />
:::*SP uncertainty 1<br />
::* defining scope of "cross-enterprise" (MaxUE)<br />
:::*SP uncertainty 1<br />
::*potential new use cases (MaxUE)<br />
:::*SP uncertainty 2<br />
<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* editor: 8 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align (assume moving v2 ORM to FHIR)<br />
:* TC: 8 more TC sessions 2h each to re-review Vol 1 and complete Vol 2 transactions (1- ORM?, 3- FHIR); vote for PC (16 HOURS TC)<br />
:* editor: 3 h to clean up Volume 1 and re-align<br />
:* editor: 15 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editors: 5 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h sessions); vote for approval to TI<br />
:* editors: 20 h of PC comment clean up<br />
:* TC or individually: re-review supplement to vote for TI: 4 hours<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized '''TC committee''' efforts:<br />
<br />
:* To get to publish for Public Comment: 16 hours<br />
:* To review Public Comments: 12 hours<br />
:* To get to vote to publish for Trial Implementation (final review): 4 hours<br />
<br />
'''For MINIMUM USEFUL EFFORT we propose the following:'''<br />
'''aka: Scope Management''' <br />
<br />
Complete RAD-Y2 and RAD-Y5 to get the communication of the Actionable Finding out of the Radiology Department to the EMR (i.e, the Alert Manager). The methods by which the Alert Manager completes the communication to the end user would be undefined (in other words: RAD-Y3 and RAD-Y4 would not be included). The analogy is the Radiology Department sending Certified Mail to a healthcare system and receiving a signature that the envelope was received. Hopefully, we could do one step better than a simple signature "ack" and have the "ack" defined to be different levels of acceptance other than just "received", but those could simply be an enumerated value set of response codes.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (e.g.., Elliot Silver).<br />
<br />
==7. Risks==<br />
Challenges during the prior work included underestimation of the level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR).<br />
<br />
:* Need to decide whether or not to introduce FHIR server into use cases/architecture; go contained resources everywhere; or a hybrid<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 is currently frozen. FHIR DSTU-4 is ??. The re-write between DSTU-2 and STU-3 was nearly 100%.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products may not use FHIR, but probably do not use HL7 v2 new message either.<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
<br />
==8. Open Issues==<br />
<br />
:* would need committee decision to move elusive HL7 v2 ORM-ish message to FHIR transaction<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation: Sept 7, 2018<br />
:* MaxUE = 31 SP<br />
:* MinUE = 19 SP <br />
<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% to complete through Trial Implementation publication for FUNC<br />
:* MUE xx% - x hours at each of 3 TC meetings<br />
::* Plan:<br />
<br />
Candidate Editors:<br />
: Teri Sippel Schmidt and Kinson Ho</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=111344Follow-up of Non Critical Actionable Findings - Proposal2018-09-07T18:10:35Z<p>Terisippel: /* 9. Tech Cmte Evaluation */</p>
<hr />
<div>__NOTOC__<br />
<br />
<br />
==1. Proposed Workitem: Completion of FUNC (Follow-Up of Non-Critical Actionable Findings) ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Proposal Contributors:<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Contributors:<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
The FUNC profile was underestimated in 2016. As a result, Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses are no less relevant or important than when the workitem was originally selected.<br />
<br />
'''Current state of FUNC'''<br />
:The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
:'''FUNC Volume 1:''' The use cases and background material are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
<br />
:'''FUNC Volume 2:''' The basic architecture has been determined; after intense and lengthy discussions; the "Alert Reporter" actor is effectively also a FHIR server. Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussion as FHIR has evolved significantly in the last two years.<br />
<br />
'''FUNC clinical problem statement:''' (Taken from Volume 1)<br />
<br />
:In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications between affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover notifications sent between distinct ''unaffiliated'' facilities.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 ("non-critical actionable") findings. ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are not addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is currently an HL7 v2.5.1. order message (ORM). (RAD-Y2 and RAD-Y5) which needs to be migrated to FHIR v4.<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources. (RAD-Y3 and RAD-Y4)<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 (RAD-128) transaction have been moved to the Results Distribution (RD) profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter - new to Radiology, from mACM<br />
::* Alert Aggregator - new to Radiology, from mACM<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-128 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
::* RAD-Y3 Send Followup Alert (FHIR)<br />
::* RAD-Y4 Acknowledge Followup Alert (FHIR)<br />
::* RAD-Y2 Initiate Followup Alert Plan (HL7v2 ORM or FHIR)<br />
::* RAD-Y5 Close Followup Alert Plan (HL7v2 ORM or FHIR)<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:* none<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
'''Transactions'''<br />
:*Trigger transaction: (MinUE)<br />
::*RAD-128 Send Result - complete, may need a CP, but not aware of any<br />
:::*assume done<br />
:*Radiology department transactions: (MinUE)<br />
::* RAD-Y2 Initiate Followup Alert Plan (decision: FHIR v4)<br />
:::*SP effort 3<br />
:::*SP complexity 2<br />
:::*SP uncertainty 2<br />
::* RAD-Y5 Close Followup Alert Plan (decision: FHIR v4)<br />
:::*SP effort 2<br />
:::*makes assumption that RAD-Y5 is very similar to RAD-Y2<br />
:::*makes assumption that semantics exist in HL7 v2 ORM message in current draft FUNC supplement<br />
:*Cross enterprise transactions: (MaxUE)<br />
::* RAD-Y3 Send Followup Alert (FHIR v4 w/ mACM)<br />
:::*SP effort 2<br />
:::*SP complexity 2 (cross enterprise messaging -authorization)<br />
:::*SP uncertainty 2 (specifically going to v4 and mACM yet to be re-published with v4 updates)<br />
::* RAD-Y4 Acknowledge Followup Alert (FHIR v4)<br />
:::*SP effort 1<br />
:::*SP complexity 1<br />
<br />
<br />
<br />
'''Profile'''<br />
<br />
:* We estimate that FUNC Volume 1 development (writing) is 60% complete to get to Public Comment.<br />
:::*SP effort 3<br />
:::*SP complexity 1<br />
:::*SP uncertainty 0<br />
::*One primary Use Case with variants<br />
:::*SP effort 2 (MinUE)<br />
:::*SP complexity 3 (MinUE -2; Max UE-3)<br />
::*Options<br />
:::* none<br />
<br />
<br />
'''Topics/Debates'''<br />
::* how close to follow mACM? (MinUE)<br />
:::*SP uncertainty 1<br />
::* define boundaries of robustness (ie., fallback mechanisms; set up conscience boundary) (MinUE)<br />
:::*SP uncertainty 1<br />
::* defining scope of "cross-enterprise" (MaxUE)<br />
:::*SP uncertainty 1<br />
::*potential new use cases (MaxUE)<br />
:::*SP uncertainty 2<br />
<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* editor: 8 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align (assume moving v2 ORM to FHIR)<br />
:* TC: 8 more TC sessions 2h each to re-review Vol 1 and complete Vol 2 transactions (1- ORM?, 3- FHIR); vote for PC (16 HOURS TC)<br />
:* editor: 3 h to clean up Volume 1 and re-align<br />
:* editor: 15 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editors: 5 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h sessions); vote for approval to TI<br />
:* editors: 20 h of PC comment clean up<br />
:* TC or individually: re-review supplement to vote for TI: 4 hours<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized '''TC committee''' efforts:<br />
<br />
:* To get to publish for Public Comment: 16 hours<br />
:* To review Public Comments: 12 hours<br />
:* To get to vote to publish for Trial Implementation (final review): 4 hours<br />
<br />
'''For MINIMUM USEFUL EFFORT we propose the following:'''<br />
'''aka: Scope Management''' <br />
<br />
Complete RAD-Y2 and RAD-Y5 to get the communication of the Actionable Finding out of the Radiology Department to the EMR (i.e, the Alert Manager). The methods by which the Alert Manager completes the communication to the end user would be undefined (in other words: RAD-Y3 and RAD-Y4 would not be included). The analogy is the Radiology Department sending Certified Mail to a healthcare system and receiving a signature that the envelope was received. Hopefully, we could do one step better than a simple signature "ack" and have the "ack" defined to be different levels of acceptance other than just "received", but those could simply be an enumerated value set of response codes.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (e.g.., Elliot Silver).<br />
<br />
==7. Risks==<br />
Challenges during the prior work included underestimation of the level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR).<br />
<br />
:* Need to decide whether or not to introduce FHIR server into use cases/architecture; go contained resources everywhere; or a hybrid<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 is currently frozen. FHIR DSTU-4 is ??. The re-write between DSTU-2 and STU-3 was nearly 100%.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products may not use FHIR, but probably do not use HL7 v2 new message either.<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
<br />
==8. Open Issues==<br />
<br />
:* would need committee decision to move elusive HL7 v2 ORM-ish message to FHIR transaction<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation: Sept 7, 2018<br />
:* MinUE = 19 SP <br />
:* MaxUE = 31 SP<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% to complete through Trial Implementation publication for FUNC<br />
:* MUE xx% - x hours at each of 3 TC meetings<br />
::* Plan:<br />
<br />
Candidate Editors:<br />
: Teri Sippel Schmidt and Kinson Ho</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=111343Follow-up of Non Critical Actionable Findings - Proposal2018-09-07T18:10:16Z<p>Terisippel: /* 9. Tech Cmte Evaluation */</p>
<hr />
<div>__NOTOC__<br />
<br />
<br />
==1. Proposed Workitem: Completion of FUNC (Follow-Up of Non-Critical Actionable Findings) ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Proposal Contributors:<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Contributors:<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
The FUNC profile was underestimated in 2016. As a result, Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses are no less relevant or important than when the workitem was originally selected.<br />
<br />
'''Current state of FUNC'''<br />
:The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
:'''FUNC Volume 1:''' The use cases and background material are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
<br />
:'''FUNC Volume 2:''' The basic architecture has been determined; after intense and lengthy discussions; the "Alert Reporter" actor is effectively also a FHIR server. Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussion as FHIR has evolved significantly in the last two years.<br />
<br />
'''FUNC clinical problem statement:''' (Taken from Volume 1)<br />
<br />
:In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications between affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover notifications sent between distinct ''unaffiliated'' facilities.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 ("non-critical actionable") findings. ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are not addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is currently an HL7 v2.5.1. order message (ORM). (RAD-Y2 and RAD-Y5) which needs to be migrated to FHIR v4.<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources. (RAD-Y3 and RAD-Y4)<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 (RAD-128) transaction have been moved to the Results Distribution (RD) profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter - new to Radiology, from mACM<br />
::* Alert Aggregator - new to Radiology, from mACM<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-128 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
::* RAD-Y3 Send Followup Alert (FHIR)<br />
::* RAD-Y4 Acknowledge Followup Alert (FHIR)<br />
::* RAD-Y2 Initiate Followup Alert Plan (HL7v2 ORM or FHIR)<br />
::* RAD-Y5 Close Followup Alert Plan (HL7v2 ORM or FHIR)<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:* none<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
'''Transactions'''<br />
:*Trigger transaction: (MinUE)<br />
::*RAD-128 Send Result - complete, may need a CP, but not aware of any<br />
:::*assume done<br />
:*Radiology department transactions: (MinUE)<br />
::* RAD-Y2 Initiate Followup Alert Plan (decision: FHIR v4)<br />
:::*SP effort 3<br />
:::*SP complexity 2<br />
:::*SP uncertainty 2<br />
::* RAD-Y5 Close Followup Alert Plan (decision: FHIR v4)<br />
:::*SP effort 2<br />
:::*makes assumption that RAD-Y5 is very similar to RAD-Y2<br />
:::*makes assumption that semantics exist in HL7 v2 ORM message in current draft FUNC supplement<br />
:*Cross enterprise transactions: (MaxUE)<br />
::* RAD-Y3 Send Followup Alert (FHIR v4 w/ mACM)<br />
:::*SP effort 2<br />
:::*SP complexity 2 (cross enterprise messaging -authorization)<br />
:::*SP uncertainty 2 (specifically going to v4 and mACM yet to be re-published with v4 updates)<br />
::* RAD-Y4 Acknowledge Followup Alert (FHIR v4)<br />
:::*SP effort 1<br />
:::*SP complexity 1<br />
<br />
<br />
<br />
'''Profile'''<br />
<br />
:* We estimate that FUNC Volume 1 development (writing) is 60% complete to get to Public Comment.<br />
:::*SP effort 3<br />
:::*SP complexity 1<br />
:::*SP uncertainty 0<br />
::*One primary Use Case with variants<br />
:::*SP effort 2 (MinUE)<br />
:::*SP complexity 3 (MinUE -2; Max UE-3)<br />
::*Options<br />
:::* none<br />
<br />
<br />
'''Topics/Debates'''<br />
::* how close to follow mACM? (MinUE)<br />
:::*SP uncertainty 1<br />
::* define boundaries of robustness (ie., fallback mechanisms; set up conscience boundary) (MinUE)<br />
:::*SP uncertainty 1<br />
::* defining scope of "cross-enterprise" (MaxUE)<br />
:::*SP uncertainty 1<br />
::*potential new use cases (MaxUE)<br />
:::*SP uncertainty 2<br />
<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* editor: 8 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align (assume moving v2 ORM to FHIR)<br />
:* TC: 8 more TC sessions 2h each to re-review Vol 1 and complete Vol 2 transactions (1- ORM?, 3- FHIR); vote for PC (16 HOURS TC)<br />
:* editor: 3 h to clean up Volume 1 and re-align<br />
:* editor: 15 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editors: 5 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h sessions); vote for approval to TI<br />
:* editors: 20 h of PC comment clean up<br />
:* TC or individually: re-review supplement to vote for TI: 4 hours<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized '''TC committee''' efforts:<br />
<br />
:* To get to publish for Public Comment: 16 hours<br />
:* To review Public Comments: 12 hours<br />
:* To get to vote to publish for Trial Implementation (final review): 4 hours<br />
<br />
'''For MINIMUM USEFUL EFFORT we propose the following:'''<br />
'''aka: Scope Management''' <br />
<br />
Complete RAD-Y2 and RAD-Y5 to get the communication of the Actionable Finding out of the Radiology Department to the EMR (i.e, the Alert Manager). The methods by which the Alert Manager completes the communication to the end user would be undefined (in other words: RAD-Y3 and RAD-Y4 would not be included). The analogy is the Radiology Department sending Certified Mail to a healthcare system and receiving a signature that the envelope was received. Hopefully, we could do one step better than a simple signature "ack" and have the "ack" defined to be different levels of acceptance other than just "received", but those could simply be an enumerated value set of response codes.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (e.g.., Elliot Silver).<br />
<br />
==7. Risks==<br />
Challenges during the prior work included underestimation of the level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR).<br />
<br />
:* Need to decide whether or not to introduce FHIR server into use cases/architecture; go contained resources everywhere; or a hybrid<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 is currently frozen. FHIR DSTU-4 is ??. The re-write between DSTU-2 and STU-3 was nearly 100%.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products may not use FHIR, but probably do not use HL7 v2 new message either.<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
<br />
==8. Open Issues==<br />
<br />
:* would need committee decision to move elusive HL7 v2 ORM-ish message to FHIR transaction<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* MinUE = 19 SP <br />
:* MaxUE = 31 SP<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% to complete through Trial Implementation publication for FUNC<br />
:* MUE xx% - x hours at each of 3 TC meetings<br />
::* Plan:<br />
<br />
Candidate Editors:<br />
: Teri Sippel Schmidt and Kinson Ho</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=111342Follow-up of Non Critical Actionable Findings - Proposal2018-09-07T18:09:13Z<p>Terisippel: /* Breakdown of tasks */</p>
<hr />
<div>__NOTOC__<br />
<br />
<br />
==1. Proposed Workitem: Completion of FUNC (Follow-Up of Non-Critical Actionable Findings) ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Proposal Contributors:<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Contributors:<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
The FUNC profile was underestimated in 2016. As a result, Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses are no less relevant or important than when the workitem was originally selected.<br />
<br />
'''Current state of FUNC'''<br />
:The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
:'''FUNC Volume 1:''' The use cases and background material are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
<br />
:'''FUNC Volume 2:''' The basic architecture has been determined; after intense and lengthy discussions; the "Alert Reporter" actor is effectively also a FHIR server. Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussion as FHIR has evolved significantly in the last two years.<br />
<br />
'''FUNC clinical problem statement:''' (Taken from Volume 1)<br />
<br />
:In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications between affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover notifications sent between distinct ''unaffiliated'' facilities.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 ("non-critical actionable") findings. ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are not addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is currently an HL7 v2.5.1. order message (ORM). (RAD-Y2 and RAD-Y5) which needs to be migrated to FHIR v4.<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources. (RAD-Y3 and RAD-Y4)<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 (RAD-128) transaction have been moved to the Results Distribution (RD) profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter - new to Radiology, from mACM<br />
::* Alert Aggregator - new to Radiology, from mACM<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-128 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
::* RAD-Y3 Send Followup Alert (FHIR)<br />
::* RAD-Y4 Acknowledge Followup Alert (FHIR)<br />
::* RAD-Y2 Initiate Followup Alert Plan (HL7v2 ORM or FHIR)<br />
::* RAD-Y5 Close Followup Alert Plan (HL7v2 ORM or FHIR)<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:* none<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
'''Transactions'''<br />
:*Trigger transaction: (MinUE)<br />
::*RAD-128 Send Result - complete, may need a CP, but not aware of any<br />
:::*assume done<br />
:*Radiology department transactions: (MinUE)<br />
::* RAD-Y2 Initiate Followup Alert Plan (decision: FHIR v4)<br />
:::*SP effort 3<br />
:::*SP complexity 2<br />
:::*SP uncertainty 2<br />
::* RAD-Y5 Close Followup Alert Plan (decision: FHIR v4)<br />
:::*SP effort 2<br />
:::*makes assumption that RAD-Y5 is very similar to RAD-Y2<br />
:::*makes assumption that semantics exist in HL7 v2 ORM message in current draft FUNC supplement<br />
:*Cross enterprise transactions: (MaxUE)<br />
::* RAD-Y3 Send Followup Alert (FHIR v4 w/ mACM)<br />
:::*SP effort 2<br />
:::*SP complexity 2 (cross enterprise messaging -authorization)<br />
:::*SP uncertainty 2 (specifically going to v4 and mACM yet to be re-published with v4 updates)<br />
::* RAD-Y4 Acknowledge Followup Alert (FHIR v4)<br />
:::*SP effort 1<br />
:::*SP complexity 1<br />
<br />
<br />
<br />
'''Profile'''<br />
<br />
:* We estimate that FUNC Volume 1 development (writing) is 60% complete to get to Public Comment.<br />
:::*SP effort 3<br />
:::*SP complexity 1<br />
:::*SP uncertainty 0<br />
::*One primary Use Case with variants<br />
:::*SP effort 2 (MinUE)<br />
:::*SP complexity 3 (MinUE -2; Max UE-3)<br />
::*Options<br />
:::* none<br />
<br />
<br />
'''Topics/Debates'''<br />
::* how close to follow mACM? (MinUE)<br />
:::*SP uncertainty 1<br />
::* define boundaries of robustness (ie., fallback mechanisms; set up conscience boundary) (MinUE)<br />
:::*SP uncertainty 1<br />
::* defining scope of "cross-enterprise" (MaxUE)<br />
:::*SP uncertainty 1<br />
::*potential new use cases (MaxUE)<br />
:::*SP uncertainty 2<br />
<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* editor: 8 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align (assume moving v2 ORM to FHIR)<br />
:* TC: 8 more TC sessions 2h each to re-review Vol 1 and complete Vol 2 transactions (1- ORM?, 3- FHIR); vote for PC (16 HOURS TC)<br />
:* editor: 3 h to clean up Volume 1 and re-align<br />
:* editor: 15 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editors: 5 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h sessions); vote for approval to TI<br />
:* editors: 20 h of PC comment clean up<br />
:* TC or individually: re-review supplement to vote for TI: 4 hours<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized '''TC committee''' efforts:<br />
<br />
:* To get to publish for Public Comment: 16 hours<br />
:* To review Public Comments: 12 hours<br />
:* To get to vote to publish for Trial Implementation (final review): 4 hours<br />
<br />
'''For MINIMUM USEFUL EFFORT we propose the following:'''<br />
'''aka: Scope Management''' <br />
<br />
Complete RAD-Y2 and RAD-Y5 to get the communication of the Actionable Finding out of the Radiology Department to the EMR (i.e, the Alert Manager). The methods by which the Alert Manager completes the communication to the end user would be undefined (in other words: RAD-Y3 and RAD-Y4 would not be included). The analogy is the Radiology Department sending Certified Mail to a healthcare system and receiving a signature that the envelope was received. Hopefully, we could do one step better than a simple signature "ack" and have the "ack" defined to be different levels of acceptance other than just "received", but those could simply be an enumerated value set of response codes.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (e.g.., Elliot Silver).<br />
<br />
==7. Risks==<br />
Challenges during the prior work included underestimation of the level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR).<br />
<br />
:* Need to decide whether or not to introduce FHIR server into use cases/architecture; go contained resources everywhere; or a hybrid<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 is currently frozen. FHIR DSTU-4 is ??. The re-write between DSTU-2 and STU-3 was nearly 100%.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products may not use FHIR, but probably do not use HL7 v2 new message either.<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
<br />
==8. Open Issues==<br />
<br />
:* would need committee decision to move elusive HL7 v2 ORM-ish message to FHIR transaction<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* MinUE <br />
:* MaxUE<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% to complete through Trial Implementation publication for FUNC<br />
:* MUE xx% - x hours at each of 3 TC meetings<br />
::* Plan:<br />
<br />
Candidate Editors:<br />
: Teri Sippel Schmidt and Kinson Ho</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=111341Follow-up of Non Critical Actionable Findings - Proposal2018-09-07T18:06:29Z<p>Terisippel: /* Breakdown of tasks */</p>
<hr />
<div>__NOTOC__<br />
<br />
<br />
==1. Proposed Workitem: Completion of FUNC (Follow-Up of Non-Critical Actionable Findings) ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Proposal Contributors:<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Contributors:<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
The FUNC profile was underestimated in 2016. As a result, Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses are no less relevant or important than when the workitem was originally selected.<br />
<br />
'''Current state of FUNC'''<br />
:The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
:'''FUNC Volume 1:''' The use cases and background material are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
<br />
:'''FUNC Volume 2:''' The basic architecture has been determined; after intense and lengthy discussions; the "Alert Reporter" actor is effectively also a FHIR server. Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussion as FHIR has evolved significantly in the last two years.<br />
<br />
'''FUNC clinical problem statement:''' (Taken from Volume 1)<br />
<br />
:In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications between affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover notifications sent between distinct ''unaffiliated'' facilities.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 ("non-critical actionable") findings. ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are not addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is currently an HL7 v2.5.1. order message (ORM). (RAD-Y2 and RAD-Y5) which needs to be migrated to FHIR v4.<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources. (RAD-Y3 and RAD-Y4)<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 (RAD-128) transaction have been moved to the Results Distribution (RD) profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter - new to Radiology, from mACM<br />
::* Alert Aggregator - new to Radiology, from mACM<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-128 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
::* RAD-Y3 Send Followup Alert (FHIR)<br />
::* RAD-Y4 Acknowledge Followup Alert (FHIR)<br />
::* RAD-Y2 Initiate Followup Alert Plan (HL7v2 ORM or FHIR)<br />
::* RAD-Y5 Close Followup Alert Plan (HL7v2 ORM or FHIR)<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:* none<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
'''Transactions'''<br />
:*Trigger transaction: (MinUE)<br />
::*RAD-128 Send Result - complete, may need a CP, but not aware of any<br />
:::*assume done<br />
:*Radiology department transactions: (MinUE)<br />
::* RAD-Y2 Initiate Followup Alert Plan (decision: FHIR v4)<br />
:::*SP effort 3<br />
:::*SP complexity 2<br />
:::*SP uncertainty 2<br />
::* RAD-Y5 Close Followup Alert Plan (decision: FHIR v4)<br />
:::*SP effort 2<br />
:::*makes assumption that RAD-Y5 is very similar to RAD-Y2<br />
:::*makes assumption that semantics exist in HL7 v2 ORM message in current draft FUNC supplement<br />
:*Cross enterprise transactions: (MaxUE)<br />
::* RAD-Y3 Send Followup Alert (FHIR v4 w/ mACM)<br />
:::*SP effort 2<br />
:::*SP complexity 2 (cross enterprise messaging -authorization)<br />
:::*SP uncertainty 2 (specifically going to v4 and mACM yet to be re-published with v4 updates)<br />
::* RAD-Y4 Acknowledge Followup Alert (FHIR v4)<br />
:::*SP effort 1<br />
:::*SP complexity 1<br />
<br />
<br />
<br />
'''Profile'''<br />
<br />
:* We estimate that FUNC Volume 1 development (writing) is 60% complete to get to Public Comment.<br />
:::*SP effort 3<br />
:::*SP complexity 1<br />
:::*SP uncertainty 0<br />
::*One primary Use Case with variants<br />
:::*SP effort 2 (MinUE -1; MaxUE-2)<br />
:::*SP complexity 3 (MinUE -2; Max UE-3)<br />
::*Options<br />
:::* none<br />
<br />
<br />
'''Topics/Debates'''<br />
::* how close to follow mACM? (MinUE)<br />
:::*SP uncertainty 1<br />
::* define boundaries of robustness (ie., fallback mechanisms; set up conscience boundary) (MinUE)<br />
:::*SP uncertainty 1<br />
::* defining scope of "cross-enterprise" (MaxUE)<br />
:::*SP uncertainty 1<br />
::*potential new use cases (MaxUE)<br />
:::*SP uncertainty 2<br />
<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* editor: 8 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align (assume moving v2 ORM to FHIR)<br />
:* TC: 8 more TC sessions 2h each to re-review Vol 1 and complete Vol 2 transactions (1- ORM?, 3- FHIR); vote for PC (16 HOURS TC)<br />
:* editor: 3 h to clean up Volume 1 and re-align<br />
:* editor: 15 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editors: 5 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h sessions); vote for approval to TI<br />
:* editors: 20 h of PC comment clean up<br />
:* TC or individually: re-review supplement to vote for TI: 4 hours<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized '''TC committee''' efforts:<br />
<br />
:* To get to publish for Public Comment: 16 hours<br />
:* To review Public Comments: 12 hours<br />
:* To get to vote to publish for Trial Implementation (final review): 4 hours<br />
<br />
'''For MINIMUM USEFUL EFFORT we propose the following:'''<br />
'''aka: Scope Management''' <br />
<br />
Complete RAD-Y2 and RAD-Y5 to get the communication of the Actionable Finding out of the Radiology Department to the EMR (i.e, the Alert Manager). The methods by which the Alert Manager completes the communication to the end user would be undefined (in other words: RAD-Y3 and RAD-Y4 would not be included). The analogy is the Radiology Department sending Certified Mail to a healthcare system and receiving a signature that the envelope was received. Hopefully, we could do one step better than a simple signature "ack" and have the "ack" defined to be different levels of acceptance other than just "received", but those could simply be an enumerated value set of response codes.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (e.g.., Elliot Silver).<br />
<br />
==7. Risks==<br />
Challenges during the prior work included underestimation of the level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR).<br />
<br />
:* Need to decide whether or not to introduce FHIR server into use cases/architecture; go contained resources everywhere; or a hybrid<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 is currently frozen. FHIR DSTU-4 is ??. The re-write between DSTU-2 and STU-3 was nearly 100%.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products may not use FHIR, but probably do not use HL7 v2 new message either.<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
<br />
==8. Open Issues==<br />
<br />
:* would need committee decision to move elusive HL7 v2 ORM-ish message to FHIR transaction<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* MinUE <br />
:* MaxUE<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% to complete through Trial Implementation publication for FUNC<br />
:* MUE xx% - x hours at each of 3 TC meetings<br />
::* Plan:<br />
<br />
Candidate Editors:<br />
: Teri Sippel Schmidt and Kinson Ho</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=111340Follow-up of Non Critical Actionable Findings - Proposal2018-09-07T18:04:31Z<p>Terisippel: /* Breakdown of tasks */</p>
<hr />
<div>__NOTOC__<br />
<br />
<br />
==1. Proposed Workitem: Completion of FUNC (Follow-Up of Non-Critical Actionable Findings) ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Proposal Contributors:<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Contributors:<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
The FUNC profile was underestimated in 2016. As a result, Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses are no less relevant or important than when the workitem was originally selected.<br />
<br />
'''Current state of FUNC'''<br />
:The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
:'''FUNC Volume 1:''' The use cases and background material are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
<br />
:'''FUNC Volume 2:''' The basic architecture has been determined; after intense and lengthy discussions; the "Alert Reporter" actor is effectively also a FHIR server. Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussion as FHIR has evolved significantly in the last two years.<br />
<br />
'''FUNC clinical problem statement:''' (Taken from Volume 1)<br />
<br />
:In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications between affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover notifications sent between distinct ''unaffiliated'' facilities.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 ("non-critical actionable") findings. ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are not addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is currently an HL7 v2.5.1. order message (ORM). (RAD-Y2 and RAD-Y5) which needs to be migrated to FHIR v4.<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources. (RAD-Y3 and RAD-Y4)<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 (RAD-128) transaction have been moved to the Results Distribution (RD) profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter - new to Radiology, from mACM<br />
::* Alert Aggregator - new to Radiology, from mACM<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-128 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
::* RAD-Y3 Send Followup Alert (FHIR)<br />
::* RAD-Y4 Acknowledge Followup Alert (FHIR)<br />
::* RAD-Y2 Initiate Followup Alert Plan (HL7v2 ORM or FHIR)<br />
::* RAD-Y5 Close Followup Alert Plan (HL7v2 ORM or FHIR)<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:* none<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
'''Transactions'''<br />
:*Trigger transaction: (MinUE)<br />
::*RAD-128 Send Result - complete, may need a CP, but not aware of any<br />
:::*assume done<br />
:*Radiology department transactions: (MinUE)<br />
::* RAD-Y2 Initiate Followup Alert Plan (decision: FHIR v4)<br />
:::*SP effort 3<br />
:::*SP complexity 2<br />
:::*SP uncertainty 2<br />
::* RAD-Y5 Close Followup Alert Plan (decision: FHIR v4)<br />
:::*SP effort 2<br />
:::*makes assumption that RAD-Y5 is very similar to RAD-Y2<br />
:::*makes assumption that semantics exist in HL7 v2 ORM message in current draft FUNC supplement<br />
:*Cross enterprise transactions: (MaxUE)<br />
::* RAD-Y3 Send Followup Alert (FHIR v4 w/ mACM)<br />
:::*SP effort 2<br />
:::*SP complexity 2 (cross enterprise messaging -authorization)<br />
:::*SP uncertainty 2 (specifically going to v4 and mACM yet to be re-published with v4 updates)<br />
::* RAD-Y4 Acknowledge Followup Alert (FHIR v4)<br />
:::*SP effort 1<br />
:::*SP complexity 1<br />
<br />
<br />
<br />
'''Profile'''<br />
<br />
:* We estimate that FUNC Volume 1 development (writing) is 60% complete to get to Public Comment.<br />
:::*SP effort 3<br />
:::*SP complexity 1<br />
:::*SP uncertainty 0<br />
::*One primary Use Case with variants<br />
:::*SP effort 2 (MinUE -1; MaxUE-2)<br />
:::*SP complexity 3 (MinUE -2; Max UE-3)<br />
::*Options<br />
:::* none<br />
<br />
<br />
'''Topics/Debates'''<br />
::* how close to follow mACM? (MinUE)<br />
:::*SP uncertainty 1<br />
::* define boundaries of robustness (ie., fallback mechanisms; set up conscience boundary) (MinUE)<br />
:::*SP uncertainty <br />
::* defining scope of "cross-enterprise" (MaxUE)<br />
:::*SP uncertainty 1<br />
::*potential new use cases (MaxUE)<br />
:::*SP uncertainty 2<br />
<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* editor: 8 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align (assume moving v2 ORM to FHIR)<br />
:* TC: 8 more TC sessions 2h each to re-review Vol 1 and complete Vol 2 transactions (1- ORM?, 3- FHIR); vote for PC (16 HOURS TC)<br />
:* editor: 3 h to clean up Volume 1 and re-align<br />
:* editor: 15 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editors: 5 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h sessions); vote for approval to TI<br />
:* editors: 20 h of PC comment clean up<br />
:* TC or individually: re-review supplement to vote for TI: 4 hours<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized '''TC committee''' efforts:<br />
<br />
:* To get to publish for Public Comment: 16 hours<br />
:* To review Public Comments: 12 hours<br />
:* To get to vote to publish for Trial Implementation (final review): 4 hours<br />
<br />
'''For MINIMUM USEFUL EFFORT we propose the following:'''<br />
'''aka: Scope Management''' <br />
<br />
Complete RAD-Y2 and RAD-Y5 to get the communication of the Actionable Finding out of the Radiology Department to the EMR (i.e, the Alert Manager). The methods by which the Alert Manager completes the communication to the end user would be undefined (in other words: RAD-Y3 and RAD-Y4 would not be included). The analogy is the Radiology Department sending Certified Mail to a healthcare system and receiving a signature that the envelope was received. Hopefully, we could do one step better than a simple signature "ack" and have the "ack" defined to be different levels of acceptance other than just "received", but those could simply be an enumerated value set of response codes.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (e.g.., Elliot Silver).<br />
<br />
==7. Risks==<br />
Challenges during the prior work included underestimation of the level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR).<br />
<br />
:* Need to decide whether or not to introduce FHIR server into use cases/architecture; go contained resources everywhere; or a hybrid<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 is currently frozen. FHIR DSTU-4 is ??. The re-write between DSTU-2 and STU-3 was nearly 100%.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products may not use FHIR, but probably do not use HL7 v2 new message either.<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
<br />
==8. Open Issues==<br />
<br />
:* would need committee decision to move elusive HL7 v2 ORM-ish message to FHIR transaction<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* MinUE <br />
:* MaxUE<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% to complete through Trial Implementation publication for FUNC<br />
:* MUE xx% - x hours at each of 3 TC meetings<br />
::* Plan:<br />
<br />
Candidate Editors:<br />
: Teri Sippel Schmidt and Kinson Ho</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=111339Follow-up of Non Critical Actionable Findings - Proposal2018-09-07T18:01:41Z<p>Terisippel: /* 9. Tech Cmte Evaluation */</p>
<hr />
<div>__NOTOC__<br />
<br />
<br />
==1. Proposed Workitem: Completion of FUNC (Follow-Up of Non-Critical Actionable Findings) ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Proposal Contributors:<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Contributors:<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
The FUNC profile was underestimated in 2016. As a result, Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses are no less relevant or important than when the workitem was originally selected.<br />
<br />
'''Current state of FUNC'''<br />
:The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
:'''FUNC Volume 1:''' The use cases and background material are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
<br />
:'''FUNC Volume 2:''' The basic architecture has been determined; after intense and lengthy discussions; the "Alert Reporter" actor is effectively also a FHIR server. Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussion as FHIR has evolved significantly in the last two years.<br />
<br />
'''FUNC clinical problem statement:''' (Taken from Volume 1)<br />
<br />
:In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications between affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover notifications sent between distinct ''unaffiliated'' facilities.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 ("non-critical actionable") findings. ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are not addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is currently an HL7 v2.5.1. order message (ORM). (RAD-Y2 and RAD-Y5) which needs to be migrated to FHIR v4.<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources. (RAD-Y3 and RAD-Y4)<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 (RAD-128) transaction have been moved to the Results Distribution (RD) profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter - new to Radiology, from mACM<br />
::* Alert Aggregator - new to Radiology, from mACM<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-128 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
::* RAD-Y3 Send Followup Alert (FHIR)<br />
::* RAD-Y4 Acknowledge Followup Alert (FHIR)<br />
::* RAD-Y2 Initiate Followup Alert Plan (HL7v2 ORM or FHIR)<br />
::* RAD-Y5 Close Followup Alert Plan (HL7v2 ORM or FHIR)<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:* none<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
'''Transactions'''<br />
:*Trigger transaction: (MinUE)<br />
::*RAD-128 Send Result - complete, may need a CP, but not aware of any<br />
:::*assume done<br />
:*Radiology department transactions: (MinUE)<br />
::* RAD-Y2 Initiate Followup Alert Plan (decision: FHIR v4)<br />
:::*SP effort 3<br />
:::*SP complexity 2<br />
:::*SP uncertainty 2<br />
::* RAD-Y5 Close Followup Alert Plan (decision: FHIR v4)<br />
:::*SP effort 2<br />
:::*makes assumption that RAD-Y5 is very similar to RAD-Y2<br />
:::*makes assumption that semantics exist in HL7 v2 ORM message in current draft FUNC supplement<br />
:*Cross enterprise transactions: (MaxUE)<br />
::* RAD-Y3 Send Followup Alert (FHIR v4 w/ mACM)<br />
:::*SP effort 2<br />
:::*SP complexity 2 (cross enterprise messaging -authorization)<br />
:::*SP uncertainty 2 (specifically going to v4 and mACM yet to be re-published with v4 updates)<br />
::* RAD-Y4 Acknowledge Followup Alert (FHIR v4)<br />
:::*SP effort 1<br />
:::*SP complexity 1<br />
<br />
<br />
<br />
'''Profile'''<br />
<br />
:* We estimate that FUNC Volume 1 development (writing) is 60% complete to get to Public Comment.<br />
:::*SP effort 3<br />
:::*SP complexity 1<br />
:::*SP uncertainty 0<br />
::*One primary Use Case with variants<br />
:::*SP effort 2<br />
:::*SP complexity 3<br />
::*Options<br />
:::* none<br />
<br />
<br />
'''Topics/Debates'''<br />
::* how close to follow mACM? (MinUE)<br />
:::*SP uncertainty 1<br />
::* define boundaries of robustness (ie., fallback mechanisms; set up conscience boundary) (MinUE)<br />
:::*SP uncertainty <br />
::* defining scope of "cross-enterprise" (MaxUE)<br />
:::*SP uncertainty 1<br />
::*potential new use cases (MaxUE)<br />
:::*SP uncertainty 2<br />
<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* editor: 8 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align (assume moving v2 ORM to FHIR)<br />
:* TC: 8 more TC sessions 2h each to re-review Vol 1 and complete Vol 2 transactions (1- ORM?, 3- FHIR); vote for PC (16 HOURS TC)<br />
:* editor: 3 h to clean up Volume 1 and re-align<br />
:* editor: 15 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editors: 5 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h sessions); vote for approval to TI<br />
:* editors: 20 h of PC comment clean up<br />
:* TC or individually: re-review supplement to vote for TI: 4 hours<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized '''TC committee''' efforts:<br />
<br />
:* To get to publish for Public Comment: 16 hours<br />
:* To review Public Comments: 12 hours<br />
:* To get to vote to publish for Trial Implementation (final review): 4 hours<br />
<br />
'''For MINIMUM USEFUL EFFORT we propose the following:'''<br />
'''aka: Scope Management''' <br />
<br />
Complete RAD-Y2 and RAD-Y5 to get the communication of the Actionable Finding out of the Radiology Department to the EMR (i.e, the Alert Manager). The methods by which the Alert Manager completes the communication to the end user would be undefined (in other words: RAD-Y3 and RAD-Y4 would not be included). The analogy is the Radiology Department sending Certified Mail to a healthcare system and receiving a signature that the envelope was received. Hopefully, we could do one step better than a simple signature "ack" and have the "ack" defined to be different levels of acceptance other than just "received", but those could simply be an enumerated value set of response codes.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (e.g.., Elliot Silver).<br />
<br />
==7. Risks==<br />
Challenges during the prior work included underestimation of the level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR).<br />
<br />
:* Need to decide whether or not to introduce FHIR server into use cases/architecture; go contained resources everywhere; or a hybrid<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 is currently frozen. FHIR DSTU-4 is ??. The re-write between DSTU-2 and STU-3 was nearly 100%.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products may not use FHIR, but probably do not use HL7 v2 new message either.<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
<br />
==8. Open Issues==<br />
<br />
:* would need committee decision to move elusive HL7 v2 ORM-ish message to FHIR transaction<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* MinUE <br />
:* MaxUE<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% to complete through Trial Implementation publication for FUNC<br />
:* MUE xx% - x hours at each of 3 TC meetings<br />
::* Plan:<br />
<br />
Candidate Editors:<br />
: Teri Sippel Schmidt and Kinson Ho</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=111338Follow-up of Non Critical Actionable Findings - Proposal2018-09-07T18:00:34Z<p>Terisippel: /* Breakdown of tasks */</p>
<hr />
<div>__NOTOC__<br />
<br />
<br />
==1. Proposed Workitem: Completion of FUNC (Follow-Up of Non-Critical Actionable Findings) ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Proposal Contributors:<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Contributors:<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
The FUNC profile was underestimated in 2016. As a result, Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses are no less relevant or important than when the workitem was originally selected.<br />
<br />
'''Current state of FUNC'''<br />
:The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
:'''FUNC Volume 1:''' The use cases and background material are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
<br />
:'''FUNC Volume 2:''' The basic architecture has been determined; after intense and lengthy discussions; the "Alert Reporter" actor is effectively also a FHIR server. Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussion as FHIR has evolved significantly in the last two years.<br />
<br />
'''FUNC clinical problem statement:''' (Taken from Volume 1)<br />
<br />
:In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications between affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover notifications sent between distinct ''unaffiliated'' facilities.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 ("non-critical actionable") findings. ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are not addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is currently an HL7 v2.5.1. order message (ORM). (RAD-Y2 and RAD-Y5) which needs to be migrated to FHIR v4.<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources. (RAD-Y3 and RAD-Y4)<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 (RAD-128) transaction have been moved to the Results Distribution (RD) profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter - new to Radiology, from mACM<br />
::* Alert Aggregator - new to Radiology, from mACM<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-128 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
::* RAD-Y3 Send Followup Alert (FHIR)<br />
::* RAD-Y4 Acknowledge Followup Alert (FHIR)<br />
::* RAD-Y2 Initiate Followup Alert Plan (HL7v2 ORM or FHIR)<br />
::* RAD-Y5 Close Followup Alert Plan (HL7v2 ORM or FHIR)<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:* none<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
'''Transactions'''<br />
:*Trigger transaction: (MinUE)<br />
::*RAD-128 Send Result - complete, may need a CP, but not aware of any<br />
:::*assume done<br />
:*Radiology department transactions: (MinUE)<br />
::* RAD-Y2 Initiate Followup Alert Plan (decision: FHIR v4)<br />
:::*SP effort 3<br />
:::*SP complexity 2<br />
:::*SP uncertainty 2<br />
::* RAD-Y5 Close Followup Alert Plan (decision: FHIR v4)<br />
:::*SP effort 2<br />
:::*makes assumption that RAD-Y5 is very similar to RAD-Y2<br />
:::*makes assumption that semantics exist in HL7 v2 ORM message in current draft FUNC supplement<br />
:*Cross enterprise transactions: (MaxUE)<br />
::* RAD-Y3 Send Followup Alert (FHIR v4 w/ mACM)<br />
:::*SP effort 2<br />
:::*SP complexity 2 (cross enterprise messaging -authorization)<br />
:::*SP uncertainty 2 (specifically going to v4 and mACM yet to be re-published with v4 updates)<br />
::* RAD-Y4 Acknowledge Followup Alert (FHIR v4)<br />
:::*SP effort 1<br />
:::*SP complexity 1<br />
<br />
<br />
<br />
'''Profile'''<br />
<br />
:* We estimate that FUNC Volume 1 development (writing) is 60% complete to get to Public Comment.<br />
:::*SP effort 3<br />
:::*SP complexity 1<br />
:::*SP uncertainty 0<br />
::*One primary Use Case with variants<br />
:::*SP effort 2<br />
:::*SP complexity 3<br />
::*Options<br />
:::* none<br />
<br />
<br />
'''Topics/Debates'''<br />
::* how close to follow mACM? (MinUE)<br />
:::*SP uncertainty 1<br />
::* define boundaries of robustness (ie., fallback mechanisms; set up conscience boundary) (MinUE)<br />
:::*SP uncertainty <br />
::* defining scope of "cross-enterprise" (MaxUE)<br />
:::*SP uncertainty 1<br />
::*potential new use cases (MaxUE)<br />
:::*SP uncertainty 2<br />
<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* editor: 8 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align (assume moving v2 ORM to FHIR)<br />
:* TC: 8 more TC sessions 2h each to re-review Vol 1 and complete Vol 2 transactions (1- ORM?, 3- FHIR); vote for PC (16 HOURS TC)<br />
:* editor: 3 h to clean up Volume 1 and re-align<br />
:* editor: 15 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editors: 5 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h sessions); vote for approval to TI<br />
:* editors: 20 h of PC comment clean up<br />
:* TC or individually: re-review supplement to vote for TI: 4 hours<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized '''TC committee''' efforts:<br />
<br />
:* To get to publish for Public Comment: 16 hours<br />
:* To review Public Comments: 12 hours<br />
:* To get to vote to publish for Trial Implementation (final review): 4 hours<br />
<br />
'''For MINIMUM USEFUL EFFORT we propose the following:'''<br />
'''aka: Scope Management''' <br />
<br />
Complete RAD-Y2 and RAD-Y5 to get the communication of the Actionable Finding out of the Radiology Department to the EMR (i.e, the Alert Manager). The methods by which the Alert Manager completes the communication to the end user would be undefined (in other words: RAD-Y3 and RAD-Y4 would not be included). The analogy is the Radiology Department sending Certified Mail to a healthcare system and receiving a signature that the envelope was received. Hopefully, we could do one step better than a simple signature "ack" and have the "ack" defined to be different levels of acceptance other than just "received", but those could simply be an enumerated value set of response codes.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (e.g.., Elliot Silver).<br />
<br />
==7. Risks==<br />
Challenges during the prior work included underestimation of the level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR).<br />
<br />
:* Need to decide whether or not to introduce FHIR server into use cases/architecture; go contained resources everywhere; or a hybrid<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 is currently frozen. FHIR DSTU-4 is ??. The re-write between DSTU-2 and STU-3 was nearly 100%.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products may not use FHIR, but probably do not use HL7 v2 new message either.<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
<br />
==8. Open Issues==<br />
<br />
:* would need committee decision to move elusive HL7 v2 ORM-ish message to FHIR transaction<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* <br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% to complete through Trial Implementation publication for FUNC<br />
:* MUE xx% - x hours at each of 3 TC meetings<br />
::* Plan:<br />
<br />
Candidate Editors:<br />
: Teri Sippel Schmidt and Kinson Ho</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=111337Follow-up of Non Critical Actionable Findings - Proposal2018-09-07T17:53:54Z<p>Terisippel: /* 4. Standards and Systems */</p>
<hr />
<div>__NOTOC__<br />
<br />
<br />
==1. Proposed Workitem: Completion of FUNC (Follow-Up of Non-Critical Actionable Findings) ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Proposal Contributors:<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Contributors:<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
The FUNC profile was underestimated in 2016. As a result, Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses are no less relevant or important than when the workitem was originally selected.<br />
<br />
'''Current state of FUNC'''<br />
:The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
:'''FUNC Volume 1:''' The use cases and background material are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
<br />
:'''FUNC Volume 2:''' The basic architecture has been determined; after intense and lengthy discussions; the "Alert Reporter" actor is effectively also a FHIR server. Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussion as FHIR has evolved significantly in the last two years.<br />
<br />
'''FUNC clinical problem statement:''' (Taken from Volume 1)<br />
<br />
:In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications between affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover notifications sent between distinct ''unaffiliated'' facilities.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 ("non-critical actionable") findings. ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are not addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is currently an HL7 v2.5.1. order message (ORM). (RAD-Y2 and RAD-Y5) which needs to be migrated to FHIR v4.<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources. (RAD-Y3 and RAD-Y4)<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 (RAD-128) transaction have been moved to the Results Distribution (RD) profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter - new to Radiology, from mACM<br />
::* Alert Aggregator - new to Radiology, from mACM<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-128 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
::* RAD-Y3 Send Followup Alert (FHIR)<br />
::* RAD-Y4 Acknowledge Followup Alert (FHIR)<br />
::* RAD-Y2 Initiate Followup Alert Plan (HL7v2 ORM or FHIR)<br />
::* RAD-Y5 Close Followup Alert Plan (HL7v2 ORM or FHIR)<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:* none<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
'''Transactions'''<br />
::*RAD-128 Send Result - complete, may need a CP, but not aware of any<br />
:::*assume done<br />
::* RAD-Y3 Send Followup Alert (FHIR v4 w/ mACM)<br />
:::*SP effort 2<br />
:::*SP complexity 2 (cross enterprise messaging -authorization)<br />
:::*SP uncertainty 2 (specifically going to v4 and mACM yet to be re-published with v4 updates)<br />
::* RAD-Y4 Acknowledge Followup Alert (FHIR v4)<br />
:::*SP effort 1<br />
::* RAD-Y2 Initiate Followup Alert Plan (decision: FHIR v4)<br />
:::*SP effort 2<br />
:::*SP complexity 1<br />
:::*SP uncertainty 2<br />
::* RAD-Y5 Close Followup Alert Plan (decision: FHIR v4)<br />
:::*SP effort 2<br />
:::*makes assumption that RAD-Y5 is very similar to RAD-Y2<br />
:::*makes assumption that semantics exist in HL7 v2 ORM message in current draft FUNC supplement<br />
<br />
<br />
'''Profile'''<br />
<br />
:* We estimate that FUNC Volume 1 development (writing) is 60% complete to get to Public Comment.<br />
:::*SP effort 3<br />
:::*SP complexity 1<br />
:::*SP uncertainty 0<br />
::*One primary Use Case with variants<br />
:::*SP effort 2<br />
:::*SP complexity 3<br />
::*Options<br />
:::* none<br />
<br />
<br />
'''Topics/Debates'''<br />
::* defining scope of "cross-enterprise"<br />
:::*SP uncertainty 1<br />
::* how close to follow mACM?<br />
:::*SP uncertainty 1<br />
::* define boundaries of robustness (ie., fallback mechanisms; set up conscience boundary)<br />
:::*SP uncertainty 1<br />
<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* editor: 8 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align (assume moving v2 ORM to FHIR)<br />
:* TC: 8 more TC sessions 2h each to re-review Vol 1 and complete Vol 2 transactions (1- ORM?, 3- FHIR); vote for PC (16 HOURS TC)<br />
:* editor: 3 h to clean up Volume 1 and re-align<br />
:* editor: 15 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editors: 5 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h sessions); vote for approval to TI<br />
:* editors: 20 h of PC comment clean up<br />
:* TC or individually: re-review supplement to vote for TI: 4 hours<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized '''TC committee''' efforts:<br />
<br />
:* To get to publish for Public Comment: 16 hours<br />
:* To review Public Comments: 12 hours<br />
:* To get to vote to publish for Trial Implementation (final review): 4 hours<br />
<br />
'''For MINIMUM USEFUL EFFORT we propose the following:'''<br />
'''aka: Scope Management''' <br />
<br />
Complete RAD-Y2 and RAD-Y5 to get the communication of the Actionable Finding out of the Radiology Department to the EMR (i.e, the Alert Manager). The methods by which the Alert Manager completes the communication to the end user would be undefined (in other words: RAD-Y3 and RAD-Y4 would not be included). The analogy is the Radiology Department sending Certified Mail to a healthcare system and receiving a signature that the envelope was received. Hopefully, we could do one step better than a simple signature "ack" and have the "ack" defined to be different levels of acceptance other than just "received", but those could simply be an enumerated value set of response codes.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (e.g.., Elliot Silver).<br />
<br />
==7. Risks==<br />
Challenges during the prior work included underestimation of the level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR).<br />
<br />
:* Need to decide whether or not to introduce FHIR server into use cases/architecture; go contained resources everywhere; or a hybrid<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 is currently frozen. FHIR DSTU-4 is ??. The re-write between DSTU-2 and STU-3 was nearly 100%.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products may not use FHIR, but probably do not use HL7 v2 new message either.<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
<br />
==8. Open Issues==<br />
<br />
:* would need committee decision to move elusive HL7 v2 ORM-ish message to FHIR transaction<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* <br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% to complete through Trial Implementation publication for FUNC<br />
:* MUE xx% - x hours at each of 3 TC meetings<br />
::* Plan:<br />
<br />
Candidate Editors:<br />
: Teri Sippel Schmidt and Kinson Ho</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=111336Follow-up of Non Critical Actionable Findings - Proposal2018-09-07T17:50:23Z<p>Terisippel: </p>
<hr />
<div>__NOTOC__<br />
<br />
<br />
==1. Proposed Workitem: Completion of FUNC (Follow-Up of Non-Critical Actionable Findings) ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Proposal Contributors:<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Contributors:<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
The FUNC profile was underestimated in 2016. As a result, Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses are no less relevant or important than when the workitem was originally selected.<br />
<br />
'''Current state of FUNC'''<br />
:The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
:'''FUNC Volume 1:''' The use cases and background material are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
<br />
:'''FUNC Volume 2:''' The basic architecture has been determined; after intense and lengthy discussions; the "Alert Reporter" actor is effectively also a FHIR server. Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussion as FHIR has evolved significantly in the last two years.<br />
<br />
'''FUNC clinical problem statement:''' (Taken from Volume 1)<br />
<br />
:In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications between affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover notifications sent between distinct ''unaffiliated'' facilities.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 ("non-critical actionable") findings. ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are not addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is an HL7 v2.5.1. order message (ORM). (RAD-Y2 and RAD-Y5)<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources. (RAD-Y3 and RAD-Y4)<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC supplement link Volume 2 has extensive additional detail.<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 transaction have been moved to the RD profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter - new to Radiology, from mACM<br />
::* Alert Aggregator - new to Radiology, from mACM<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-128 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
::* RAD-Y3 Send Followup Alert (FHIR)<br />
::* RAD-Y4 Acknowledge Followup Alert (FHIR)<br />
::* RAD-Y2 Initiate Followup Alert Plan (HL7v2 ORM or FHIR)<br />
::* RAD-Y5 Close Followup Alert Plan (HL7v2 ORM or FHIR)<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:* none<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
'''Transactions'''<br />
::*RAD-128 Send Result - complete, may need a CP, but not aware of any<br />
:::*assume done<br />
::* RAD-Y3 Send Followup Alert (FHIR v4 w/ mACM)<br />
:::*SP effort 2<br />
:::*SP complexity 2 (cross enterprise messaging -authorization)<br />
:::*SP uncertainty 2 (specifically going to v4 and mACM yet to be re-published with v4 updates)<br />
::* RAD-Y4 Acknowledge Followup Alert (FHIR v4)<br />
:::*SP effort 1<br />
::* RAD-Y2 Initiate Followup Alert Plan (decision: FHIR v4)<br />
:::*SP effort 2<br />
:::*SP complexity 1<br />
:::*SP uncertainty 2<br />
::* RAD-Y5 Close Followup Alert Plan (decision: FHIR v4)<br />
:::*SP effort 2<br />
:::*makes assumption that RAD-Y5 is very similar to RAD-Y2<br />
:::*makes assumption that semantics exist in HL7 v2 ORM message in current draft FUNC supplement<br />
<br />
<br />
'''Profile'''<br />
<br />
:* We estimate that FUNC Volume 1 development (writing) is 60% complete to get to Public Comment.<br />
:::*SP effort 3<br />
:::*SP complexity 1<br />
:::*SP uncertainty 0<br />
::*One primary Use Case with variants<br />
:::*SP effort 2<br />
:::*SP complexity 3<br />
::*Options<br />
:::* none<br />
<br />
<br />
'''Topics/Debates'''<br />
::* defining scope of "cross-enterprise"<br />
:::*SP uncertainty 1<br />
::* how close to follow mACM?<br />
:::*SP uncertainty 1<br />
::* define boundaries of robustness (ie., fallback mechanisms; set up conscience boundary)<br />
:::*SP uncertainty 1<br />
<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* editor: 8 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align (assume moving v2 ORM to FHIR)<br />
:* TC: 8 more TC sessions 2h each to re-review Vol 1 and complete Vol 2 transactions (1- ORM?, 3- FHIR); vote for PC (16 HOURS TC)<br />
:* editor: 3 h to clean up Volume 1 and re-align<br />
:* editor: 15 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editors: 5 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h sessions); vote for approval to TI<br />
:* editors: 20 h of PC comment clean up<br />
:* TC or individually: re-review supplement to vote for TI: 4 hours<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized '''TC committee''' efforts:<br />
<br />
:* To get to publish for Public Comment: 16 hours<br />
:* To review Public Comments: 12 hours<br />
:* To get to vote to publish for Trial Implementation (final review): 4 hours<br />
<br />
'''For MINIMUM USEFUL EFFORT we propose the following:'''<br />
'''aka: Scope Management''' <br />
<br />
Complete RAD-Y2 and RAD-Y5 to get the communication of the Actionable Finding out of the Radiology Department to the EMR (i.e, the Alert Manager). The methods by which the Alert Manager completes the communication to the end user would be undefined (in other words: RAD-Y3 and RAD-Y4 would not be included). The analogy is the Radiology Department sending Certified Mail to a healthcare system and receiving a signature that the envelope was received. Hopefully, we could do one step better than a simple signature "ack" and have the "ack" defined to be different levels of acceptance other than just "received", but those could simply be an enumerated value set of response codes.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (e.g.., Elliot Silver).<br />
<br />
==7. Risks==<br />
Challenges during the prior work included underestimation of the level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR).<br />
<br />
:* Need to decide whether or not to introduce FHIR server into use cases/architecture; go contained resources everywhere; or a hybrid<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 is currently frozen. FHIR DSTU-4 is ??. The re-write between DSTU-2 and STU-3 was nearly 100%.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products may not use FHIR, but probably do not use HL7 v2 new message either.<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
<br />
==8. Open Issues==<br />
<br />
:* would need committee decision to move elusive HL7 v2 ORM-ish message to FHIR transaction<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* <br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% to complete through Trial Implementation publication for FUNC<br />
:* MUE xx% - x hours at each of 3 TC meetings<br />
::* Plan:<br />
<br />
Candidate Editors:<br />
: Teri Sippel Schmidt and Kinson Ho</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=111322Follow-up of Non Critical Actionable Findings - Proposal2018-09-07T15:48:45Z<p>Terisippel: /* New actors */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''STILL IN DEV!~!!!'''<br />
<br />
==1. Proposed Workitem: Completion of FUNC (Follow-Up of Non-Critical Actionable Findings) ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Proposal Contributors:<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Contributors:<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
The FUNC profile was underestimated in 2016. As a result, Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses are no less relevant or important than when the workitem was originally selected.<br />
<br />
'''Current state of FUNC'''<br />
:The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
:'''FUNC Volume 1:''' The use cases and background material are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
<br />
:'''FUNC Volume 2:''' The basic architecture has been determined; after intense and lengthy discussions; the "Alert Reporter" actor is effectively also a FHIR server. Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussion as FHIR has evolved significantly in the last two years.<br />
<br />
'''FUNC clinical problem statement:''' (Taken from Volume 1)<br />
<br />
:In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications between affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover notifications sent between distinct ''unaffiliated'' facilities.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 ("non-critical actionable") findings. ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are not addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is an HL7 v2.5.1. order message (ORM). (RAD-Y2 and RAD-Y5)<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources. (RAD-Y3 and RAD-Y4)<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC supplement link Volume 2 has extensive additional detail.<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 transaction have been moved to the RD profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter - new to Radiology, from mACM<br />
::* Alert Aggregator - new to Radiology, from mACM<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-128 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
::* RAD-Y3 Send Followup Alert (FHIR)<br />
::* RAD-Y4 Acknowledge Followup Alert (FHIR)<br />
::* RAD-Y2 Initiate Followup Alert Plan (HL7v2 ORM or FHIR)<br />
::* RAD-Y5 Close Followup Alert Plan (HL7v2 ORM or FHIR)<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:* none<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
'''Transactions'''<br />
::*RAD-128 Send Result - complete, may need a CP, but not aware of any<br />
::* RAD-Y3 Send Followup Alert (FHIR) - move to FHIR V4?<br />
::* RAD-Y4 Acknowledge Followup Alert (FHIR) - move to FHIR V4?<br />
::* RAD-Y2 Initiate Followup Alert Plan (decision: HL7v2 ORM or FHIR)<br />
::* RAD-Y5 Close Followup Alert Plan (decision: HL7v2 ORM or FHIR)<br />
<br />
<br />
'''Profile'''<br />
<br />
:* We estimate that FUNC Volume 1 development (writing) is 60% complete to get to Public Comment.<br />
<br />
:* We estimate that FUNC Volume 2 development (writing) is 50% complete to get to Public Comment, based on list of Transactions above.<br />
<br />
'''Topics/Debates'''<br />
::* RAD-Y2 and RAD-Y5 - stick with HL7 v2 within radiology or bring FHIR into radiology (original decision 3 years old...)<br />
::* how close to follow mACM?<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* editor: 8 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align (assume moving v2 ORM to FHIR)<br />
:* TC: 8 more TC sessions 2h each to re-review Vol 1 and complete Vol 2 transactions (1- ORM?, 3- FHIR); vote for PC (16 HOURS TC)<br />
:* editor: 3 h to clean up Volume 1 and re-align<br />
:* editor: 15 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editors: 5 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h sessions); vote for approval to TI<br />
:* editors: 20 h of PC comment clean up<br />
:* TC or individually: re-review supplement to vote for TI: 4 hours<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized '''TC committee''' efforts:<br />
<br />
:* To get to publish for Public Comment: 16 hours<br />
:* To review Public Comments: 12 hours<br />
:* To get to vote to publish for Trial Implementation (final review): 4 hours<br />
<br />
'''For MINIMUM USEFUL EFFORT we propose the following:'''<br />
'''aka: Scope Management''' <br />
<br />
Complete RAD-Y2 and RAD-Y5 to get the communication of the Actionable Finding out of the Radiology Department to the EMR (i.e, the Alert Manager). The methods by which the Alert Manager completes the communication to the end user would be undefined (in other words: RAD-Y3 and RAD-Y4 would not be included). The analogy is the Radiology Department sending Certified Mail to a healthcare system and receiving a signature that the envelope was received. Hopefully, we could do one step better than a simple signature "ack" and have the "ack" defined to be different levels of acceptance other than just "received", but those could simply be an enumerated value set of response codes.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (e.g.., Elliot Silver).<br />
<br />
==7. Risks==<br />
Challenges during the prior work included underestimation of the level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR).<br />
<br />
:* Need to decide whether or not to introduce FHIR server into use cases/architecture; go contained resources everywhere; or a hybrid<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 is currently frozen. FHIR DSTU-4 is ??. The re-write between DSTU-2 and STU-3 was nearly 100%.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products may not use FHIR, but probably do not use HL7 v2 new message either.<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
<br />
==8. Open Issues==<br />
<br />
:* would need committee decision to move elusive HL7 v2 ORM-ish message to FHIR transaction<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* <br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% to complete through Trial Implementation publication for FUNC<br />
:* MUE xx% - x hours at each of 3 TC meetings<br />
::* Plan:<br />
<br />
Candidate Editors:<br />
: Teri Sippel Schmidt and Kinson Ho</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=111321Follow-up of Non Critical Actionable Findings - Proposal2018-09-07T15:48:00Z<p>Terisippel: /* 5. Technical Approach */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''STILL IN DEV!~!!!'''<br />
<br />
==1. Proposed Workitem: Completion of FUNC (Follow-Up of Non-Critical Actionable Findings) ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Proposal Contributors:<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Contributors:<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
The FUNC profile was underestimated in 2016. As a result, Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses are no less relevant or important than when the workitem was originally selected.<br />
<br />
'''Current state of FUNC'''<br />
:The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
:'''FUNC Volume 1:''' The use cases and background material are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
<br />
:'''FUNC Volume 2:''' The basic architecture has been determined; after intense and lengthy discussions; the "Alert Reporter" actor is effectively also a FHIR server. Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussion as FHIR has evolved significantly in the last two years.<br />
<br />
'''FUNC clinical problem statement:''' (Taken from Volume 1)<br />
<br />
:In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications between affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover notifications sent between distinct ''unaffiliated'' facilities.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 ("non-critical actionable") findings. ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are not addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is an HL7 v2.5.1. order message (ORM). (RAD-Y2 and RAD-Y5)<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources. (RAD-Y3 and RAD-Y4)<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC supplement link Volume 2 has extensive additional detail.<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 transaction have been moved to the RD profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter<br />
::* Alert Aggregator<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-128 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
::* RAD-Y3 Send Followup Alert (FHIR)<br />
::* RAD-Y4 Acknowledge Followup Alert (FHIR)<br />
::* RAD-Y2 Initiate Followup Alert Plan (HL7v2 ORM or FHIR)<br />
::* RAD-Y5 Close Followup Alert Plan (HL7v2 ORM or FHIR)<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:* none<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
'''Transactions'''<br />
::*RAD-128 Send Result - complete, may need a CP, but not aware of any<br />
::* RAD-Y3 Send Followup Alert (FHIR) - move to FHIR V4?<br />
::* RAD-Y4 Acknowledge Followup Alert (FHIR) - move to FHIR V4?<br />
::* RAD-Y2 Initiate Followup Alert Plan (decision: HL7v2 ORM or FHIR)<br />
::* RAD-Y5 Close Followup Alert Plan (decision: HL7v2 ORM or FHIR)<br />
<br />
<br />
'''Profile'''<br />
<br />
:* We estimate that FUNC Volume 1 development (writing) is 60% complete to get to Public Comment.<br />
<br />
:* We estimate that FUNC Volume 2 development (writing) is 50% complete to get to Public Comment, based on list of Transactions above.<br />
<br />
'''Topics/Debates'''<br />
::* RAD-Y2 and RAD-Y5 - stick with HL7 v2 within radiology or bring FHIR into radiology (original decision 3 years old...)<br />
::* how close to follow mACM?<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* editor: 8 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align (assume moving v2 ORM to FHIR)<br />
:* TC: 8 more TC sessions 2h each to re-review Vol 1 and complete Vol 2 transactions (1- ORM?, 3- FHIR); vote for PC (16 HOURS TC)<br />
:* editor: 3 h to clean up Volume 1 and re-align<br />
:* editor: 15 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editors: 5 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h sessions); vote for approval to TI<br />
:* editors: 20 h of PC comment clean up<br />
:* TC or individually: re-review supplement to vote for TI: 4 hours<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized '''TC committee''' efforts:<br />
<br />
:* To get to publish for Public Comment: 16 hours<br />
:* To review Public Comments: 12 hours<br />
:* To get to vote to publish for Trial Implementation (final review): 4 hours<br />
<br />
'''For MINIMUM USEFUL EFFORT we propose the following:'''<br />
'''aka: Scope Management''' <br />
<br />
Complete RAD-Y2 and RAD-Y5 to get the communication of the Actionable Finding out of the Radiology Department to the EMR (i.e, the Alert Manager). The methods by which the Alert Manager completes the communication to the end user would be undefined (in other words: RAD-Y3 and RAD-Y4 would not be included). The analogy is the Radiology Department sending Certified Mail to a healthcare system and receiving a signature that the envelope was received. Hopefully, we could do one step better than a simple signature "ack" and have the "ack" defined to be different levels of acceptance other than just "received", but those could simply be an enumerated value set of response codes.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (e.g.., Elliot Silver).<br />
<br />
==7. Risks==<br />
Challenges during the prior work included underestimation of the level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR).<br />
<br />
:* Need to decide whether or not to introduce FHIR server into use cases/architecture; go contained resources everywhere; or a hybrid<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 is currently frozen. FHIR DSTU-4 is ??. The re-write between DSTU-2 and STU-3 was nearly 100%.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products may not use FHIR, but probably do not use HL7 v2 new message either.<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
<br />
==8. Open Issues==<br />
<br />
:* would need committee decision to move elusive HL7 v2 ORM-ish message to FHIR transaction<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* <br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% to complete through Trial Implementation publication for FUNC<br />
:* MUE xx% - x hours at each of 3 TC meetings<br />
::* Plan:<br />
<br />
Candidate Editors:<br />
: Teri Sippel Schmidt and Kinson Ho</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=110841Follow-up of Non Critical Actionable Findings - Proposal2018-08-08T18:36:47Z<p>Terisippel: /* '5. Discussion */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''STILL IN DEV!~!!!'''<br />
<br />
==1. Proposed Workitem: Completion of Follow-Up of Non-Critical Actionable Findings (FUNC) supplement ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
'''The IHE TC problem:''' The possibility exists that the Follow-Up of Non-Critical Actionable Findings (FUNC) profile was underestimated in 2016 for its level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR). As a result, the Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses is no less relevant or important than it was when the profile was originally introduced.<br />
<br />
'''Current state of FUNC supplement:'''<br />
The scope of the FUNC profile itself was nearly halved in terms of length (i.e., number of pages) when the Results Distribution profile was spun off. The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
'''FUNC Volume 1:'''<br />
:The use cases and background material in Volume 1 are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
'''FUNC Volume 2:'''<br />
:The basic architecture has been determined; after intense and lengthy discussions, the "Alert Reporter" actor is effectively also a FHIR server.<br />
:Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussions as FHIR has evolved significantly in the last two years.<br />
<br />
'''The FUNC clinical problem statement:'''<br />
<br />
Taken from Volume 1:<br />
<br />
In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications within affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover the situation where a notification has to be sent between entirely distinct and unaffiliated facilities,.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 findings, or "non-critical actionable findings". ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are therefore not covered in or addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is an HL7 v2.5.1. order message (ORM). (RAD-Y2 and RAD-Y5)<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources. (RAD-Y3 and RAD-Y4)<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC supplement link Volume 2 has extensive additional detail.<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 transaction have been moved to the RD profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==''''''5. Discussion==<br />
<br />
We estimate that FUNC Volume 1 development (writing) is 60% complete to get to Public Comment.<br />
<br />
We estimate that FUNC Volume 2 development (writing) is 50% complete to get to Public Comment. In particular, the FHIR resource definitions are still under development and, other than RAD-128, RAD-Y4 and RAD-Y5 should be reconsidered as a FHIR transaction.<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* editor: 8 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align (assume moving v2 ORM to FHIR)<br />
:* TC: 8 more TC sessions 2h each to re-review Vol 1 and complete Vol 2 transactions (1- ORM?, 3- FHIR); vote for PC (16 HOURS TC)<br />
:* editor: 3 h to clean up Volume 1 and re-align<br />
:* editor: 15 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editors: 5 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h sessions); vote for approval to TI<br />
:* editors: 20 h of PC comment clean up<br />
:* TC or individually: re-review supplement to vote for TI: 4 hours<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized '''TC committee''' efforts:<br />
<br />
:* To get to publish for Public Comment: 16 hours<br />
:* To review Public Comments: 12 hours<br />
:* To get to vote to publish for Trial Implementation (final review): 4 hours<br />
<br />
<br />
'''For MINIMUM EFFECTIVE USE we propose the following:'''<br />
<br />
Complete RAD-Y2 and RAD-Y5 to get the communication of the Actionable Finding out of the Radiology Department to the EMR (i.e, the Alert Manager). The methods by which the Alert Manager completes the communication to the end user would be undefined (in other words: RAD-Y3 and RAD-Y4 would not be included). The analogy is the Radiology Department sending Certified Mail to a healthcare system and receiving a signature that the envelope was received. Hopefully, we could do one step better than a simple signature "ack" and have the "ack" defined to be different levels of acceptance other than just "received", but those could simply be an enumerated value set of response codes.<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter<br />
::* Alert Aggregator<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-128 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
<br />
::* 2 new FHIR transactions (RAD-Y3 and RAD-Y4)<br />
::* 2 new HL7 v2 ORM transaction (RAD-Y2 and RAD-Y5) '''OR''' switch to a similar FHIR transaction as above<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:*Need to complete RD<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
<br />
See work break down above.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (e.g.., Elliot Silver).<br />
<br />
==7. Risks==<br />
<br />
:* Need to decide whether or not to introduce FHIR server into use cases/architecture; go contained resources everywhere; or a hybrid<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 is currently frozen. FHIR DSTU-4 is ??. The re-write between DSTU-2 and STU-3 was nearly 100%.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products may not use FHIR, but probably do not use HL7 v2 new message either.<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
<br />
==8. Open Issues==<br />
<br />
:* would need committee decision to move elusive HL7 v2 ORM-ish message to FHIR transaction<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* <br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% to complete through Trial Implementation publication for FUNC<br />
:* MUE xx% - x hours at each of 3 TC meetings<br />
::* Plan:<br />
<br />
Candidate Editors:<br />
: Teri Sippel Schmidt and Kinson Ho</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=110840Follow-up of Non Critical Actionable Findings - Proposal2018-08-08T17:43:44Z<p>Terisippel: /* '5. Discussion */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''STILL IN DEV!~!!!'''<br />
<br />
==1. Proposed Workitem: Completion of Follow-Up of Non-Critical Actionable Findings (FUNC) supplement ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
'''The IHE TC problem:''' The possibility exists that the Follow-Up of Non-Critical Actionable Findings (FUNC) profile was underestimated in 2016 for its level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR). As a result, the Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses is no less relevant or important than it was when the profile was originally introduced.<br />
<br />
'''Current state of FUNC supplement:'''<br />
The scope of the FUNC profile itself was nearly halved in terms of length (i.e., number of pages) when the Results Distribution profile was spun off. The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
'''FUNC Volume 1:'''<br />
:The use cases and background material in Volume 1 are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
'''FUNC Volume 2:'''<br />
:The basic architecture has been determined; after intense and lengthy discussions, the "Alert Reporter" actor is effectively also a FHIR server.<br />
:Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussions as FHIR has evolved significantly in the last two years.<br />
<br />
'''The FUNC clinical problem statement:'''<br />
<br />
Taken from Volume 1:<br />
<br />
In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications within affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover the situation where a notification has to be sent between entirely distinct and unaffiliated facilities,.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 findings, or "non-critical actionable findings". ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are therefore not covered in or addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is an HL7 v2.5.1. order message (ORM). (RAD-Y2 and RAD-Y5)<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources. (RAD-Y3 and RAD-Y4)<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC supplement link Volume 2 has extensive additional detail.<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 transaction have been moved to the RD profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==''''''5. Discussion==<br />
<br />
We estimate that FUNC Volume 1 development (writing) is 60% complete to get to Public Comment.<br />
<br />
We estimate that FUNC Volume 2 development (writing) is 50% complete to get to Public Comment. In particular, the FHIR resource definitions are still under development and, other than RAD-128, RAD-Y4 and RAD-Y5 should be reconsidered as a FHIR transaction.<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* editor: 8 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align (assume moving v2 ORM to FHIR)<br />
:* TC: 8 more TC sessions 2h each to re-review Vol 1 and complete Vol 2 transactions (1- ORM?, 3- FHIR); vote for PC (16 HOURS TC)<br />
:* editor: 3 h to clean up Volume 1 and re-align<br />
:* editor: 15 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editors: 5 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h sessions); vote for approval to TI<br />
:* editors: 20 h of PC comment clean up<br />
:* TC or individually: re-review supplement to vote for TI: 4 hours<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized '''TC committee''' efforts:<br />
<br />
:* To get to publish for Public Comment: 16 hours<br />
:* To review Public Comments: 12 hours<br />
:* To get to vote to publish for Trial Implementation (final review): 4 hours<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter<br />
::* Alert Aggregator<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-128 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
<br />
::* 2 new FHIR transactions (RAD-Y3 and RAD-Y4)<br />
::* 2 new HL7 v2 ORM transaction (RAD-Y2 and RAD-Y5) '''OR''' switch to a similar FHIR transaction as above<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:*Need to complete RD<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
<br />
See work break down above.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (e.g.., Elliot Silver).<br />
<br />
==7. Risks==<br />
<br />
:* Need to decide whether or not to introduce FHIR server into use cases/architecture; go contained resources everywhere; or a hybrid<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 is currently frozen. FHIR DSTU-4 is ??. The re-write between DSTU-2 and STU-3 was nearly 100%.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products may not use FHIR, but probably do not use HL7 v2 new message either.<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
<br />
==8. Open Issues==<br />
<br />
:* would need committee decision to move elusive HL7 v2 ORM-ish message to FHIR transaction<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* <br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% to complete through Trial Implementation publication for FUNC<br />
:* MUE xx% - x hours at each of 3 TC meetings<br />
::* Plan:<br />
<br />
Candidate Editors:<br />
: Teri Sippel Schmidt and Kinson Ho</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=110839Follow-up of Non Critical Actionable Findings - Proposal2018-08-08T17:38:28Z<p>Terisippel: /* 7. Risks */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''STILL IN DEV!~!!!'''<br />
<br />
==1. Proposed Workitem: Completion of Follow-Up of Non-Critical Actionable Findings (FUNC) supplement ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
'''The IHE TC problem:''' The possibility exists that the Follow-Up of Non-Critical Actionable Findings (FUNC) profile was underestimated in 2016 for its level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR). As a result, the Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses is no less relevant or important than it was when the profile was originally introduced.<br />
<br />
'''Current state of FUNC supplement:'''<br />
The scope of the FUNC profile itself was nearly halved in terms of length (i.e., number of pages) when the Results Distribution profile was spun off. The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
'''FUNC Volume 1:'''<br />
:The use cases and background material in Volume 1 are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
'''FUNC Volume 2:'''<br />
:The basic architecture has been determined; after intense and lengthy discussions, the "Alert Reporter" actor is effectively also a FHIR server.<br />
:Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussions as FHIR has evolved significantly in the last two years.<br />
<br />
'''The FUNC clinical problem statement:'''<br />
<br />
Taken from Volume 1:<br />
<br />
In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications within affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover the situation where a notification has to be sent between entirely distinct and unaffiliated facilities,.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 findings, or "non-critical actionable findings". ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are therefore not covered in or addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is an HL7 v2.5.1. order message (ORM). (RAD-Y2 and RAD-Y5)<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources. (RAD-Y3 and RAD-Y4)<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC supplement link Volume 2 has extensive additional detail.<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 transaction have been moved to the RD profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==''''''5. Discussion==<br />
<br />
We estimate that FUNC Volume 1 development (writing) is 60% complete to get to Public Comment.<br />
<br />
We estimate that FUNC Volume 2 development (writing) is 50% complete to get to Public Comment. In particular, the FHIR resource definitions are still under development and, other than RAD-128, RAD-Y4 and RAD-Y5 should be reconsidered as a FHIR transaction.<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* editor: 8 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align (assume moving v2 ORM to FHIR)<br />
:* TC: 8 more TC sessions 2h each to re-review Vol 1 and complete Vol 2 transactions (1- ORM?, 3- FHIR); vote for PC (16 HOURS TC)<br />
:* editor: 3 h to clean up Volume 1 and re-align<br />
:* editor: 15 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editors: 5 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h sessions); vote for approval to TI<br />
:* editors: 20 h of PC comment clean up<br />
:* TC or individually: re-review supplement to vote for TI: 4 hours<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized '''TC committee''' efforts:<br />
<br />
:* To get to publish for Public Comment: 16 hours<br />
:* To review Public Comments: 12 hours<br />
:* To get to vote to publish for Trial Implementation: 4 hours<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter<br />
::* Alert Aggregator<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-128 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
<br />
::* 2 new FHIR transactions (RAD-Y3 and RAD-Y4)<br />
::* 2 new HL7 v2 ORM transaction (RAD-Y2 and RAD-Y5) '''OR''' switch to a similar FHIR transaction as above<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:*Need to complete RD<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
<br />
See work break down above.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (e.g.., Elliot Silver).<br />
<br />
==7. Risks==<br />
<br />
:* Need to decide whether or not to introduce FHIR server into use cases/architecture; go contained resources everywhere; or a hybrid<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 is currently frozen. FHIR DSTU-4 is ??. The re-write between DSTU-2 and STU-3 was nearly 100%.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products may not use FHIR, but probably do not use HL7 v2 new message either.<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
<br />
==8. Open Issues==<br />
<br />
:* would need committee decision to move elusive HL7 v2 ORM-ish message to FHIR transaction<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* <br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% to complete through Trial Implementation publication for FUNC<br />
:* MUE xx% - x hours at each of 3 TC meetings<br />
::* Plan:<br />
<br />
Candidate Editors:<br />
: Teri Sippel Schmidt and Kinson Ho</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=110838Follow-up of Non Critical Actionable Findings - Proposal2018-08-08T17:37:02Z<p>Terisippel: /* New transactions (standards used) */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''STILL IN DEV!~!!!'''<br />
<br />
==1. Proposed Workitem: Completion of Follow-Up of Non-Critical Actionable Findings (FUNC) supplement ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
'''The IHE TC problem:''' The possibility exists that the Follow-Up of Non-Critical Actionable Findings (FUNC) profile was underestimated in 2016 for its level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR). As a result, the Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses is no less relevant or important than it was when the profile was originally introduced.<br />
<br />
'''Current state of FUNC supplement:'''<br />
The scope of the FUNC profile itself was nearly halved in terms of length (i.e., number of pages) when the Results Distribution profile was spun off. The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
'''FUNC Volume 1:'''<br />
:The use cases and background material in Volume 1 are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
'''FUNC Volume 2:'''<br />
:The basic architecture has been determined; after intense and lengthy discussions, the "Alert Reporter" actor is effectively also a FHIR server.<br />
:Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussions as FHIR has evolved significantly in the last two years.<br />
<br />
'''The FUNC clinical problem statement:'''<br />
<br />
Taken from Volume 1:<br />
<br />
In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications within affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover the situation where a notification has to be sent between entirely distinct and unaffiliated facilities,.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 findings, or "non-critical actionable findings". ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are therefore not covered in or addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is an HL7 v2.5.1. order message (ORM). (RAD-Y2 and RAD-Y5)<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources. (RAD-Y3 and RAD-Y4)<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC supplement link Volume 2 has extensive additional detail.<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 transaction have been moved to the RD profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==''''''5. Discussion==<br />
<br />
We estimate that FUNC Volume 1 development (writing) is 60% complete to get to Public Comment.<br />
<br />
We estimate that FUNC Volume 2 development (writing) is 50% complete to get to Public Comment. In particular, the FHIR resource definitions are still under development and, other than RAD-128, RAD-Y4 and RAD-Y5 should be reconsidered as a FHIR transaction.<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* editor: 8 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align (assume moving v2 ORM to FHIR)<br />
:* TC: 8 more TC sessions 2h each to re-review Vol 1 and complete Vol 2 transactions (1- ORM?, 3- FHIR); vote for PC (16 HOURS TC)<br />
:* editor: 3 h to clean up Volume 1 and re-align<br />
:* editor: 15 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editors: 5 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h sessions); vote for approval to TI<br />
:* editors: 20 h of PC comment clean up<br />
:* TC or individually: re-review supplement to vote for TI: 4 hours<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized '''TC committee''' efforts:<br />
<br />
:* To get to publish for Public Comment: 16 hours<br />
:* To review Public Comments: 12 hours<br />
:* To get to vote to publish for Trial Implementation: 4 hours<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter<br />
::* Alert Aggregator<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-128 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
<br />
::* 2 new FHIR transactions (RAD-Y3 and RAD-Y4)<br />
::* 2 new HL7 v2 ORM transaction (RAD-Y2 and RAD-Y5) '''OR''' switch to a similar FHIR transaction as above<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:*Need to complete RD<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
<br />
See work break down above.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (e.g.., Elliot Silver).<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 changes dramatically again. STU-3 is currently frozen. FHIR DSTU-4 is ??.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products may not use FHIR, but probably do not use HL7 v2 new message either.<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
<br />
==8. Open Issues==<br />
<br />
:* would need committee decision to move elusive HL7 v2 ORM-ish message to FHIR transaction<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* <br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% to complete through Trial Implementation publication for FUNC<br />
:* MUE xx% - x hours at each of 3 TC meetings<br />
::* Plan:<br />
<br />
Candidate Editors:<br />
: Teri Sippel Schmidt and Kinson Ho</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=110837Follow-up of Non Critical Actionable Findings - Proposal2018-08-08T17:36:01Z<p>Terisippel: /* '5. Discussion */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''STILL IN DEV!~!!!'''<br />
<br />
==1. Proposed Workitem: Completion of Follow-Up of Non-Critical Actionable Findings (FUNC) supplement ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
'''The IHE TC problem:''' The possibility exists that the Follow-Up of Non-Critical Actionable Findings (FUNC) profile was underestimated in 2016 for its level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR). As a result, the Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses is no less relevant or important than it was when the profile was originally introduced.<br />
<br />
'''Current state of FUNC supplement:'''<br />
The scope of the FUNC profile itself was nearly halved in terms of length (i.e., number of pages) when the Results Distribution profile was spun off. The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
'''FUNC Volume 1:'''<br />
:The use cases and background material in Volume 1 are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
'''FUNC Volume 2:'''<br />
:The basic architecture has been determined; after intense and lengthy discussions, the "Alert Reporter" actor is effectively also a FHIR server.<br />
:Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussions as FHIR has evolved significantly in the last two years.<br />
<br />
'''The FUNC clinical problem statement:'''<br />
<br />
Taken from Volume 1:<br />
<br />
In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications within affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover the situation where a notification has to be sent between entirely distinct and unaffiliated facilities,.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 findings, or "non-critical actionable findings". ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are therefore not covered in or addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is an HL7 v2.5.1. order message (ORM). (RAD-Y2 and RAD-Y5)<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources. (RAD-Y3 and RAD-Y4)<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC supplement link Volume 2 has extensive additional detail.<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 transaction have been moved to the RD profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==''''''5. Discussion==<br />
<br />
We estimate that FUNC Volume 1 development (writing) is 60% complete to get to Public Comment.<br />
<br />
We estimate that FUNC Volume 2 development (writing) is 50% complete to get to Public Comment. In particular, the FHIR resource definitions are still under development and, other than RAD-128, RAD-Y4 and RAD-Y5 should be reconsidered as a FHIR transaction.<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* editor: 8 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align (assume moving v2 ORM to FHIR)<br />
:* TC: 8 more TC sessions 2h each to re-review Vol 1 and complete Vol 2 transactions (1- ORM?, 3- FHIR); vote for PC (16 HOURS TC)<br />
:* editor: 3 h to clean up Volume 1 and re-align<br />
:* editor: 15 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editors: 5 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h sessions); vote for approval to TI<br />
:* editors: 20 h of PC comment clean up<br />
:* TC or individually: re-review supplement to vote for TI: 4 hours<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized '''TC committee''' efforts:<br />
<br />
:* To get to publish for Public Comment: 16 hours<br />
:* To review Public Comments: 12 hours<br />
:* To get to vote to publish for Trial Implementation: 4 hours<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter<br />
::* Alert Aggregator<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-128 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
<br />
::* 3 new FHIR transactions (RAD-Y3, RAD-Y4 and RAD-Y5)<br />
::* 1 new HL7 v2 ORM transaction (RAD-Y2), including ack OR switch to a similar FHIR transaction as above<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:*Need to complete RD<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
<br />
See work break down above.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (e.g.., Elliot Silver).<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 changes dramatically again. STU-3 is currently frozen. FHIR DSTU-4 is ??.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products may not use FHIR, but probably do not use HL7 v2 new message either.<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
<br />
==8. Open Issues==<br />
<br />
:* would need committee decision to move elusive HL7 v2 ORM-ish message to FHIR transaction<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* <br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% to complete through Trial Implementation publication for FUNC<br />
:* MUE xx% - x hours at each of 3 TC meetings<br />
::* Plan:<br />
<br />
Candidate Editors:<br />
: Teri Sippel Schmidt and Kinson Ho</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=110836Follow-up of Non Critical Actionable Findings - Proposal2018-08-08T17:34:55Z<p>Terisippel: /* 4. Standards and Systems */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''STILL IN DEV!~!!!'''<br />
<br />
==1. Proposed Workitem: Completion of Follow-Up of Non-Critical Actionable Findings (FUNC) supplement ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
'''The IHE TC problem:''' The possibility exists that the Follow-Up of Non-Critical Actionable Findings (FUNC) profile was underestimated in 2016 for its level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR). As a result, the Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses is no less relevant or important than it was when the profile was originally introduced.<br />
<br />
'''Current state of FUNC supplement:'''<br />
The scope of the FUNC profile itself was nearly halved in terms of length (i.e., number of pages) when the Results Distribution profile was spun off. The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
'''FUNC Volume 1:'''<br />
:The use cases and background material in Volume 1 are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
'''FUNC Volume 2:'''<br />
:The basic architecture has been determined; after intense and lengthy discussions, the "Alert Reporter" actor is effectively also a FHIR server.<br />
:Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussions as FHIR has evolved significantly in the last two years.<br />
<br />
'''The FUNC clinical problem statement:'''<br />
<br />
Taken from Volume 1:<br />
<br />
In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications within affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover the situation where a notification has to be sent between entirely distinct and unaffiliated facilities,.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 findings, or "non-critical actionable findings". ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are therefore not covered in or addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is an HL7 v2.5.1. order message (ORM). (RAD-Y2 and RAD-Y5)<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources. (RAD-Y3 and RAD-Y4)<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC supplement link Volume 2 has extensive additional detail.<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 transaction have been moved to the RD profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==''''''5. Discussion==<br />
<br />
We estimate that FUNC Volume 1 development (writing) is 80% complete to get to Public Comment.<br />
<br />
We estimate that FUNC Volume 2 development (writing) is 50% complete to get to Public Comment. In particular, the FHIR resource definitions are still under development and, other than RAD-128, should be reconsidered as a FHIR transaction.<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* editor: 8 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align (assume moving v2 ORM to FHIR)<br />
:* TC: 8 more TC sessions 2h each to re-review Vol 1 and complete Vol 2 transactions (1- ORM?, 3- FHIR); vote for PC (16 HOURS TC)<br />
:* editor: 3 h to clean up Volume 1 and re-align<br />
:* editor: 15 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editors: 5 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h sessions); vote for approval to TI<br />
:* editors: 20 h of PC comment clean up<br />
:* TC or individually: re-review supplement to vote for TI: 4 hours<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized '''TC committee''' efforts:<br />
<br />
:* To get to publish for Public Comment: 16 hours<br />
:* To review Public Comments: 12 hours<br />
:* To get to vote to publish for Trial Implementation: 4 hours<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter<br />
::* Alert Aggregator<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-128 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
<br />
::* 3 new FHIR transactions (RAD-Y3, RAD-Y4 and RAD-Y5)<br />
::* 1 new HL7 v2 ORM transaction (RAD-Y2), including ack OR switch to a similar FHIR transaction as above<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:*Need to complete RD<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
<br />
See work break down above.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (e.g.., Elliot Silver).<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 changes dramatically again. STU-3 is currently frozen. FHIR DSTU-4 is ??.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products may not use FHIR, but probably do not use HL7 v2 new message either.<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
<br />
==8. Open Issues==<br />
<br />
:* would need committee decision to move elusive HL7 v2 ORM-ish message to FHIR transaction<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* <br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% to complete through Trial Implementation publication for FUNC<br />
:* MUE xx% - x hours at each of 3 TC meetings<br />
::* Plan:<br />
<br />
Candidate Editors:<br />
: Teri Sippel Schmidt and Kinson Ho</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=110835Follow-up of Non Critical Actionable Findings - Proposal2018-08-08T17:33:03Z<p>Terisippel: /* New transactions (standards used) */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''STILL IN DEV!~!!!'''<br />
<br />
==1. Proposed Workitem: Completion of Follow-Up of Non-Critical Actionable Findings (FUNC) supplement ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
'''The IHE TC problem:''' The possibility exists that the Follow-Up of Non-Critical Actionable Findings (FUNC) profile was underestimated in 2016 for its level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR). As a result, the Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses is no less relevant or important than it was when the profile was originally introduced.<br />
<br />
'''Current state of FUNC supplement:'''<br />
The scope of the FUNC profile itself was nearly halved in terms of length (i.e., number of pages) when the Results Distribution profile was spun off. The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
'''FUNC Volume 1:'''<br />
:The use cases and background material in Volume 1 are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
'''FUNC Volume 2:'''<br />
:The basic architecture has been determined; after intense and lengthy discussions, the "Alert Reporter" actor is effectively also a FHIR server.<br />
:Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussions as FHIR has evolved significantly in the last two years.<br />
<br />
'''The FUNC clinical problem statement:'''<br />
<br />
Taken from Volume 1:<br />
<br />
In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications within affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover the situation where a notification has to be sent between entirely distinct and unaffiliated facilities,.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 findings, or "non-critical actionable findings". ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are therefore not covered in or addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is an HL7 v2.5.1. order message (ORM).<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources.<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC supplement link Volume 2 has extensive additional detail.<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 transaction have been moved to the RD profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==''''''5. Discussion==<br />
<br />
We estimate that FUNC Volume 1 development (writing) is 80% complete to get to Public Comment.<br />
<br />
We estimate that FUNC Volume 2 development (writing) is 50% complete to get to Public Comment. In particular, the FHIR resource definitions are still under development and, other than RAD-128, should be reconsidered as a FHIR transaction.<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* editor: 8 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align (assume moving v2 ORM to FHIR)<br />
:* TC: 8 more TC sessions 2h each to re-review Vol 1 and complete Vol 2 transactions (1- ORM?, 3- FHIR); vote for PC (16 HOURS TC)<br />
:* editor: 3 h to clean up Volume 1 and re-align<br />
:* editor: 15 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editors: 5 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h sessions); vote for approval to TI<br />
:* editors: 20 h of PC comment clean up<br />
:* TC or individually: re-review supplement to vote for TI: 4 hours<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized '''TC committee''' efforts:<br />
<br />
:* To get to publish for Public Comment: 16 hours<br />
:* To review Public Comments: 12 hours<br />
:* To get to vote to publish for Trial Implementation: 4 hours<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter<br />
::* Alert Aggregator<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-128 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
<br />
::* 3 new FHIR transactions (RAD-Y3, RAD-Y4 and RAD-Y5)<br />
::* 1 new HL7 v2 ORM transaction (RAD-Y2), including ack OR switch to a similar FHIR transaction as above<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:*Need to complete RD<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
<br />
See work break down above.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (e.g.., Elliot Silver).<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 changes dramatically again. STU-3 is currently frozen. FHIR DSTU-4 is ??.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products may not use FHIR, but probably do not use HL7 v2 new message either.<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
<br />
==8. Open Issues==<br />
<br />
:* would need committee decision to move elusive HL7 v2 ORM-ish message to FHIR transaction<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* <br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% to complete through Trial Implementation publication for FUNC<br />
:* MUE xx% - x hours at each of 3 TC meetings<br />
::* Plan:<br />
<br />
Candidate Editors:<br />
: Teri Sippel Schmidt and Kinson Ho</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=110834Follow-up of Non Critical Actionable Findings - Proposal2018-08-08T17:26:16Z<p>Terisippel: /* 9. Tech Cmte Evaluation */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''STILL IN DEV!~!!!'''<br />
<br />
==1. Proposed Workitem: Completion of Follow-Up of Non-Critical Actionable Findings (FUNC) supplement ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
'''The IHE TC problem:''' The possibility exists that the Follow-Up of Non-Critical Actionable Findings (FUNC) profile was underestimated in 2016 for its level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR). As a result, the Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses is no less relevant or important than it was when the profile was originally introduced.<br />
<br />
'''Current state of FUNC supplement:'''<br />
The scope of the FUNC profile itself was nearly halved in terms of length (i.e., number of pages) when the Results Distribution profile was spun off. The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
'''FUNC Volume 1:'''<br />
:The use cases and background material in Volume 1 are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
'''FUNC Volume 2:'''<br />
:The basic architecture has been determined; after intense and lengthy discussions, the "Alert Reporter" actor is effectively also a FHIR server.<br />
:Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussions as FHIR has evolved significantly in the last two years.<br />
<br />
'''The FUNC clinical problem statement:'''<br />
<br />
Taken from Volume 1:<br />
<br />
In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications within affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover the situation where a notification has to be sent between entirely distinct and unaffiliated facilities,.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 findings, or "non-critical actionable findings". ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are therefore not covered in or addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is an HL7 v2.5.1. order message (ORM).<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources.<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC supplement link Volume 2 has extensive additional detail.<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 transaction have been moved to the RD profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==''''''5. Discussion==<br />
<br />
We estimate that FUNC Volume 1 development (writing) is 80% complete to get to Public Comment.<br />
<br />
We estimate that FUNC Volume 2 development (writing) is 50% complete to get to Public Comment. In particular, the FHIR resource definitions are still under development and, other than RAD-128, should be reconsidered as a FHIR transaction.<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* editor: 8 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align (assume moving v2 ORM to FHIR)<br />
:* TC: 8 more TC sessions 2h each to re-review Vol 1 and complete Vol 2 transactions (1- ORM?, 3- FHIR); vote for PC (16 HOURS TC)<br />
:* editor: 3 h to clean up Volume 1 and re-align<br />
:* editor: 15 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editors: 5 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h sessions); vote for approval to TI<br />
:* editors: 20 h of PC comment clean up<br />
:* TC or individually: re-review supplement to vote for TI: 4 hours<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized '''TC committee''' efforts:<br />
<br />
:* To get to publish for Public Comment: 16 hours<br />
:* To review Public Comments: 12 hours<br />
:* To get to vote to publish for Trial Implementation: 4 hours<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter<br />
::* Alert Aggregator<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-128 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
<br />
::* 6 new FHIR transactions, however 3 of them are "acks"<br />
::* 1 new HL7 v2 ORM transaction, including ack OR switch to a similar FHIR transaction as above<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:*Need to complete RD<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
<br />
See work break down above.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (e.g.., Elliot Silver).<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 changes dramatically again. STU-3 is currently frozen. FHIR DSTU-4 is ??.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products may not use FHIR, but probably do not use HL7 v2 new message either.<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
<br />
==8. Open Issues==<br />
<br />
:* would need committee decision to move elusive HL7 v2 ORM-ish message to FHIR transaction<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* <br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% to complete through Trial Implementation publication for FUNC<br />
:* MUE xx% - x hours at each of 3 TC meetings<br />
::* Plan:<br />
<br />
Candidate Editors:<br />
: Teri Sippel Schmidt and Kinson Ho</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=110833Follow-up of Non Critical Actionable Findings - Proposal2018-08-08T17:26:03Z<p>Terisippel: /* 9. Tech Cmte Evaluation */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''STILL IN DEV!~!!!'''<br />
<br />
==1. Proposed Workitem: Completion of Follow-Up of Non-Critical Actionable Findings (FUNC) supplement ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
'''The IHE TC problem:''' The possibility exists that the Follow-Up of Non-Critical Actionable Findings (FUNC) profile was underestimated in 2016 for its level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR). As a result, the Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses is no less relevant or important than it was when the profile was originally introduced.<br />
<br />
'''Current state of FUNC supplement:'''<br />
The scope of the FUNC profile itself was nearly halved in terms of length (i.e., number of pages) when the Results Distribution profile was spun off. The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
'''FUNC Volume 1:'''<br />
:The use cases and background material in Volume 1 are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
'''FUNC Volume 2:'''<br />
:The basic architecture has been determined; after intense and lengthy discussions, the "Alert Reporter" actor is effectively also a FHIR server.<br />
:Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussions as FHIR has evolved significantly in the last two years.<br />
<br />
'''The FUNC clinical problem statement:'''<br />
<br />
Taken from Volume 1:<br />
<br />
In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications within affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover the situation where a notification has to be sent between entirely distinct and unaffiliated facilities,.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 findings, or "non-critical actionable findings". ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are therefore not covered in or addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is an HL7 v2.5.1. order message (ORM).<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources.<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC supplement link Volume 2 has extensive additional detail.<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 transaction have been moved to the RD profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==''''''5. Discussion==<br />
<br />
We estimate that FUNC Volume 1 development (writing) is 80% complete to get to Public Comment.<br />
<br />
We estimate that FUNC Volume 2 development (writing) is 50% complete to get to Public Comment. In particular, the FHIR resource definitions are still under development and, other than RAD-128, should be reconsidered as a FHIR transaction.<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* editor: 8 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align (assume moving v2 ORM to FHIR)<br />
:* TC: 8 more TC sessions 2h each to re-review Vol 1 and complete Vol 2 transactions (1- ORM?, 3- FHIR); vote for PC (16 HOURS TC)<br />
:* editor: 3 h to clean up Volume 1 and re-align<br />
:* editor: 15 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editors: 5 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h sessions); vote for approval to TI<br />
:* editors: 20 h of PC comment clean up<br />
:* TC or individually: re-review supplement to vote for TI: 4 hours<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized '''TC committee''' efforts:<br />
<br />
:* To get to publish for Public Comment: 16 hours<br />
:* To review Public Comments: 12 hours<br />
:* To get to vote to publish for Trial Implementation: 4 hours<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter<br />
::* Alert Aggregator<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-128 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
<br />
::* 6 new FHIR transactions, however 3 of them are "acks"<br />
::* 1 new HL7 v2 ORM transaction, including ack OR switch to a similar FHIR transaction as above<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:*Need to complete RD<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
<br />
See work break down above.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (e.g.., Elliot Silver).<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 changes dramatically again. STU-3 is currently frozen. FHIR DSTU-4 is ??.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products may not use FHIR, but probably do not use HL7 v2 new message either.<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
<br />
==8. Open Issues==<br />
<br />
:* would need committee decision to move elusive HL7 v2 ORM-ish message to FHIR transaction<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* <br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* xx% to complete through Trial Implementation publication for FUNC<br />
:* MUE xx% - x hours at each of 3 TC meetings<br />
::* get to Public Comment version ready for publication (but not Public Comment review)<br />
<br />
Candidate Editors:<br />
: Teri Sippel Schmidt and Kinson Ho</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=110832Follow-up of Non Critical Actionable Findings - Proposal2018-08-08T17:25:27Z<p>Terisippel: /* 8. Open Issues */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''STILL IN DEV!~!!!'''<br />
<br />
==1. Proposed Workitem: Completion of Follow-Up of Non-Critical Actionable Findings (FUNC) supplement ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
'''The IHE TC problem:''' The possibility exists that the Follow-Up of Non-Critical Actionable Findings (FUNC) profile was underestimated in 2016 for its level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR). As a result, the Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses is no less relevant or important than it was when the profile was originally introduced.<br />
<br />
'''Current state of FUNC supplement:'''<br />
The scope of the FUNC profile itself was nearly halved in terms of length (i.e., number of pages) when the Results Distribution profile was spun off. The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
'''FUNC Volume 1:'''<br />
:The use cases and background material in Volume 1 are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
'''FUNC Volume 2:'''<br />
:The basic architecture has been determined; after intense and lengthy discussions, the "Alert Reporter" actor is effectively also a FHIR server.<br />
:Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussions as FHIR has evolved significantly in the last two years.<br />
<br />
'''The FUNC clinical problem statement:'''<br />
<br />
Taken from Volume 1:<br />
<br />
In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications within affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover the situation where a notification has to be sent between entirely distinct and unaffiliated facilities,.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 findings, or "non-critical actionable findings". ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are therefore not covered in or addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is an HL7 v2.5.1. order message (ORM).<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources.<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC supplement link Volume 2 has extensive additional detail.<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 transaction have been moved to the RD profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==''''''5. Discussion==<br />
<br />
We estimate that FUNC Volume 1 development (writing) is 80% complete to get to Public Comment.<br />
<br />
We estimate that FUNC Volume 2 development (writing) is 50% complete to get to Public Comment. In particular, the FHIR resource definitions are still under development and, other than RAD-128, should be reconsidered as a FHIR transaction.<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* editor: 8 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align (assume moving v2 ORM to FHIR)<br />
:* TC: 8 more TC sessions 2h each to re-review Vol 1 and complete Vol 2 transactions (1- ORM?, 3- FHIR); vote for PC (16 HOURS TC)<br />
:* editor: 3 h to clean up Volume 1 and re-align<br />
:* editor: 15 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editors: 5 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h sessions); vote for approval to TI<br />
:* editors: 20 h of PC comment clean up<br />
:* TC or individually: re-review supplement to vote for TI: 4 hours<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized '''TC committee''' efforts:<br />
<br />
:* To get to publish for Public Comment: 16 hours<br />
:* To review Public Comments: 12 hours<br />
:* To get to vote to publish for Trial Implementation: 4 hours<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter<br />
::* Alert Aggregator<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-128 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
<br />
::* 6 new FHIR transactions, however 3 of them are "acks"<br />
::* 1 new HL7 v2 ORM transaction, including ack OR switch to a similar FHIR transaction as above<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:*Need to complete RD<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
<br />
See work break down above.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (e.g.., Elliot Silver).<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 changes dramatically again. STU-3 is currently frozen. FHIR DSTU-4 is ??.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products may not use FHIR, but probably do not use HL7 v2 new message either.<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
<br />
==8. Open Issues==<br />
<br />
:* would need committee decision to move elusive HL7 v2 ORM-ish message to FHIR transaction<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* No unsolvable hurdles foreseen<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* 20% to complete through Trial Implementation publication for FUNC<br />
:* MUE 10% - 3 hours at each of 3 TC meetings<br />
::* get to Public Comment version ready for publication (but not Public Comment review)<br />
<br />
Candidate Editor:<br />
: Teri Sippel Schmidt</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=110831Follow-up of Non Critical Actionable Findings - Proposal2018-08-08T17:24:51Z<p>Terisippel: /* 7. Risks */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''STILL IN DEV!~!!!'''<br />
<br />
==1. Proposed Workitem: Completion of Follow-Up of Non-Critical Actionable Findings (FUNC) supplement ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
'''The IHE TC problem:''' The possibility exists that the Follow-Up of Non-Critical Actionable Findings (FUNC) profile was underestimated in 2016 for its level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR). As a result, the Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses is no less relevant or important than it was when the profile was originally introduced.<br />
<br />
'''Current state of FUNC supplement:'''<br />
The scope of the FUNC profile itself was nearly halved in terms of length (i.e., number of pages) when the Results Distribution profile was spun off. The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
'''FUNC Volume 1:'''<br />
:The use cases and background material in Volume 1 are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
'''FUNC Volume 2:'''<br />
:The basic architecture has been determined; after intense and lengthy discussions, the "Alert Reporter" actor is effectively also a FHIR server.<br />
:Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussions as FHIR has evolved significantly in the last two years.<br />
<br />
'''The FUNC clinical problem statement:'''<br />
<br />
Taken from Volume 1:<br />
<br />
In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications within affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover the situation where a notification has to be sent between entirely distinct and unaffiliated facilities,.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 findings, or "non-critical actionable findings". ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are therefore not covered in or addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is an HL7 v2.5.1. order message (ORM).<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources.<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC supplement link Volume 2 has extensive additional detail.<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 transaction have been moved to the RD profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==''''''5. Discussion==<br />
<br />
We estimate that FUNC Volume 1 development (writing) is 80% complete to get to Public Comment.<br />
<br />
We estimate that FUNC Volume 2 development (writing) is 50% complete to get to Public Comment. In particular, the FHIR resource definitions are still under development and, other than RAD-128, should be reconsidered as a FHIR transaction.<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* editor: 8 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align (assume moving v2 ORM to FHIR)<br />
:* TC: 8 more TC sessions 2h each to re-review Vol 1 and complete Vol 2 transactions (1- ORM?, 3- FHIR); vote for PC (16 HOURS TC)<br />
:* editor: 3 h to clean up Volume 1 and re-align<br />
:* editor: 15 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editors: 5 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h sessions); vote for approval to TI<br />
:* editors: 20 h of PC comment clean up<br />
:* TC or individually: re-review supplement to vote for TI: 4 hours<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized '''TC committee''' efforts:<br />
<br />
:* To get to publish for Public Comment: 16 hours<br />
:* To review Public Comments: 12 hours<br />
:* To get to vote to publish for Trial Implementation: 4 hours<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter<br />
::* Alert Aggregator<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-128 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
<br />
::* 6 new FHIR transactions, however 3 of them are "acks"<br />
::* 1 new HL7 v2 ORM transaction, including ack OR switch to a similar FHIR transaction as above<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:*Need to complete RD<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
<br />
See work break down above.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (e.g.., Elliot Silver).<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 changes dramatically again. STU-3 is currently frozen. FHIR DSTU-4 is ??.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products may not use FHIR, but probably do not use HL7 v2 new message either.<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
<br />
==8. Open Issues==<br />
<br />
:* profile is off cycle from Radiology TC now<br />
:* IHE Documentation staff availability<br />
:* profile does not get to TI by November<br />
<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* No unsolvable hurdles foreseen<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* 20% to complete through Trial Implementation publication for FUNC<br />
:* MUE 10% - 3 hours at each of 3 TC meetings<br />
::* get to Public Comment version ready for publication (but not Public Comment review)<br />
<br />
Candidate Editor:<br />
: Teri Sippel Schmidt</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=110830Follow-up of Non Critical Actionable Findings - Proposal2018-08-08T17:23:30Z<p>Terisippel: /* 6. Support & Resources */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''STILL IN DEV!~!!!'''<br />
<br />
==1. Proposed Workitem: Completion of Follow-Up of Non-Critical Actionable Findings (FUNC) supplement ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
'''The IHE TC problem:''' The possibility exists that the Follow-Up of Non-Critical Actionable Findings (FUNC) profile was underestimated in 2016 for its level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR). As a result, the Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses is no less relevant or important than it was when the profile was originally introduced.<br />
<br />
'''Current state of FUNC supplement:'''<br />
The scope of the FUNC profile itself was nearly halved in terms of length (i.e., number of pages) when the Results Distribution profile was spun off. The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
'''FUNC Volume 1:'''<br />
:The use cases and background material in Volume 1 are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
'''FUNC Volume 2:'''<br />
:The basic architecture has been determined; after intense and lengthy discussions, the "Alert Reporter" actor is effectively also a FHIR server.<br />
:Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussions as FHIR has evolved significantly in the last two years.<br />
<br />
'''The FUNC clinical problem statement:'''<br />
<br />
Taken from Volume 1:<br />
<br />
In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications within affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover the situation where a notification has to be sent between entirely distinct and unaffiliated facilities,.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 findings, or "non-critical actionable findings". ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are therefore not covered in or addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is an HL7 v2.5.1. order message (ORM).<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources.<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC supplement link Volume 2 has extensive additional detail.<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 transaction have been moved to the RD profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==''''''5. Discussion==<br />
<br />
We estimate that FUNC Volume 1 development (writing) is 80% complete to get to Public Comment.<br />
<br />
We estimate that FUNC Volume 2 development (writing) is 50% complete to get to Public Comment. In particular, the FHIR resource definitions are still under development and, other than RAD-128, should be reconsidered as a FHIR transaction.<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* editor: 8 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align (assume moving v2 ORM to FHIR)<br />
:* TC: 8 more TC sessions 2h each to re-review Vol 1 and complete Vol 2 transactions (1- ORM?, 3- FHIR); vote for PC (16 HOURS TC)<br />
:* editor: 3 h to clean up Volume 1 and re-align<br />
:* editor: 15 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editors: 5 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h sessions); vote for approval to TI<br />
:* editors: 20 h of PC comment clean up<br />
:* TC or individually: re-review supplement to vote for TI: 4 hours<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized '''TC committee''' efforts:<br />
<br />
:* To get to publish for Public Comment: 16 hours<br />
:* To review Public Comments: 12 hours<br />
:* To get to vote to publish for Trial Implementation: 4 hours<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter<br />
::* Alert Aggregator<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-128 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
<br />
::* 6 new FHIR transactions, however 3 of them are "acks"<br />
::* 1 new HL7 v2 ORM transaction, including ack OR switch to a similar FHIR transaction as above<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:*Need to complete RD<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
<br />
See work break down above.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (e.g.., Elliot Silver).<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 changes dramatically again. STU-3 is currently frozen. FHIR DSTU-4 is approximately a year out.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products do not use FHIR.<br />
:* Need to get RD out the door and to TI to be able to focus on FUNC.<br />
:* Disagreement on FHIR Resources selected during Public Comment period. (ie., Communication and Communication Request)<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
:* IHE TC availability for conference calls to get to Public Comment<br />
<br />
==8. Open Issues==<br />
<br />
:* profile is off cycle from Radiology TC now<br />
:* IHE Documentation staff availability<br />
:* profile does not get to TI by November<br />
<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* No unsolvable hurdles foreseen<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* 20% to complete through Trial Implementation publication for FUNC<br />
:* MUE 10% - 3 hours at each of 3 TC meetings<br />
::* get to Public Comment version ready for publication (but not Public Comment review)<br />
<br />
Candidate Editor:<br />
: Teri Sippel Schmidt</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=110829Follow-up of Non Critical Actionable Findings - Proposal2018-08-08T17:23:16Z<p>Terisippel: /* New transactions (standards used) */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''STILL IN DEV!~!!!'''<br />
<br />
==1. Proposed Workitem: Completion of Follow-Up of Non-Critical Actionable Findings (FUNC) supplement ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
'''The IHE TC problem:''' The possibility exists that the Follow-Up of Non-Critical Actionable Findings (FUNC) profile was underestimated in 2016 for its level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR). As a result, the Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses is no less relevant or important than it was when the profile was originally introduced.<br />
<br />
'''Current state of FUNC supplement:'''<br />
The scope of the FUNC profile itself was nearly halved in terms of length (i.e., number of pages) when the Results Distribution profile was spun off. The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
'''FUNC Volume 1:'''<br />
:The use cases and background material in Volume 1 are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
'''FUNC Volume 2:'''<br />
:The basic architecture has been determined; after intense and lengthy discussions, the "Alert Reporter" actor is effectively also a FHIR server.<br />
:Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussions as FHIR has evolved significantly in the last two years.<br />
<br />
'''The FUNC clinical problem statement:'''<br />
<br />
Taken from Volume 1:<br />
<br />
In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications within affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover the situation where a notification has to be sent between entirely distinct and unaffiliated facilities,.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 findings, or "non-critical actionable findings". ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are therefore not covered in or addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is an HL7 v2.5.1. order message (ORM).<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources.<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC supplement link Volume 2 has extensive additional detail.<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 transaction have been moved to the RD profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==''''''5. Discussion==<br />
<br />
We estimate that FUNC Volume 1 development (writing) is 80% complete to get to Public Comment.<br />
<br />
We estimate that FUNC Volume 2 development (writing) is 50% complete to get to Public Comment. In particular, the FHIR resource definitions are still under development and, other than RAD-128, should be reconsidered as a FHIR transaction.<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* editor: 8 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align (assume moving v2 ORM to FHIR)<br />
:* TC: 8 more TC sessions 2h each to re-review Vol 1 and complete Vol 2 transactions (1- ORM?, 3- FHIR); vote for PC (16 HOURS TC)<br />
:* editor: 3 h to clean up Volume 1 and re-align<br />
:* editor: 15 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editors: 5 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h sessions); vote for approval to TI<br />
:* editors: 20 h of PC comment clean up<br />
:* TC or individually: re-review supplement to vote for TI: 4 hours<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized '''TC committee''' efforts:<br />
<br />
:* To get to publish for Public Comment: 16 hours<br />
:* To review Public Comments: 12 hours<br />
:* To get to vote to publish for Trial Implementation: 4 hours<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter<br />
::* Alert Aggregator<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-128 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
<br />
::* 6 new FHIR transactions, however 3 of them are "acks"<br />
::* 1 new HL7 v2 ORM transaction, including ack OR switch to a similar FHIR transaction as above<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:*Need to complete RD<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
<br />
See work break down above.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (i.e., Elliot Silver).<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 changes dramatically again. STU-3 is currently frozen. FHIR DSTU-4 is approximately a year out.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products do not use FHIR.<br />
:* Need to get RD out the door and to TI to be able to focus on FUNC.<br />
:* Disagreement on FHIR Resources selected during Public Comment period. (ie., Communication and Communication Request)<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
:* IHE TC availability for conference calls to get to Public Comment<br />
<br />
==8. Open Issues==<br />
<br />
:* profile is off cycle from Radiology TC now<br />
:* IHE Documentation staff availability<br />
:* profile does not get to TI by November<br />
<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* No unsolvable hurdles foreseen<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* 20% to complete through Trial Implementation publication for FUNC<br />
:* MUE 10% - 3 hours at each of 3 TC meetings<br />
::* get to Public Comment version ready for publication (but not Public Comment review)<br />
<br />
Candidate Editor:<br />
: Teri Sippel Schmidt</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=110828Follow-up of Non Critical Actionable Findings - Proposal2018-08-08T17:22:49Z<p>Terisippel: /* Existing transactions */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''STILL IN DEV!~!!!'''<br />
<br />
==1. Proposed Workitem: Completion of Follow-Up of Non-Critical Actionable Findings (FUNC) supplement ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
'''The IHE TC problem:''' The possibility exists that the Follow-Up of Non-Critical Actionable Findings (FUNC) profile was underestimated in 2016 for its level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR). As a result, the Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses is no less relevant or important than it was when the profile was originally introduced.<br />
<br />
'''Current state of FUNC supplement:'''<br />
The scope of the FUNC profile itself was nearly halved in terms of length (i.e., number of pages) when the Results Distribution profile was spun off. The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
'''FUNC Volume 1:'''<br />
:The use cases and background material in Volume 1 are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
'''FUNC Volume 2:'''<br />
:The basic architecture has been determined; after intense and lengthy discussions, the "Alert Reporter" actor is effectively also a FHIR server.<br />
:Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussions as FHIR has evolved significantly in the last two years.<br />
<br />
'''The FUNC clinical problem statement:'''<br />
<br />
Taken from Volume 1:<br />
<br />
In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications within affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover the situation where a notification has to be sent between entirely distinct and unaffiliated facilities,.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 findings, or "non-critical actionable findings". ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are therefore not covered in or addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is an HL7 v2.5.1. order message (ORM).<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources.<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC supplement link Volume 2 has extensive additional detail.<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 transaction have been moved to the RD profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==''''''5. Discussion==<br />
<br />
We estimate that FUNC Volume 1 development (writing) is 80% complete to get to Public Comment.<br />
<br />
We estimate that FUNC Volume 2 development (writing) is 50% complete to get to Public Comment. In particular, the FHIR resource definitions are still under development and, other than RAD-128, should be reconsidered as a FHIR transaction.<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* editor: 8 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align (assume moving v2 ORM to FHIR)<br />
:* TC: 8 more TC sessions 2h each to re-review Vol 1 and complete Vol 2 transactions (1- ORM?, 3- FHIR); vote for PC (16 HOURS TC)<br />
:* editor: 3 h to clean up Volume 1 and re-align<br />
:* editor: 15 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editors: 5 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h sessions); vote for approval to TI<br />
:* editors: 20 h of PC comment clean up<br />
:* TC or individually: re-review supplement to vote for TI: 4 hours<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized '''TC committee''' efforts:<br />
<br />
:* To get to publish for Public Comment: 16 hours<br />
:* To review Public Comments: 12 hours<br />
:* To get to vote to publish for Trial Implementation: 4 hours<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter<br />
::* Alert Aggregator<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-128 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
<br />
::* 6 new FHIR transactions, however 3 of them are "acks"<br />
::* 1 new HL7 v2 ORM transaction, including ack<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:*Need to complete RD<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
<br />
See work break down above.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (i.e., Elliot Silver).<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 changes dramatically again. STU-3 is currently frozen. FHIR DSTU-4 is approximately a year out.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products do not use FHIR.<br />
:* Need to get RD out the door and to TI to be able to focus on FUNC.<br />
:* Disagreement on FHIR Resources selected during Public Comment period. (ie., Communication and Communication Request)<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
:* IHE TC availability for conference calls to get to Public Comment<br />
<br />
==8. Open Issues==<br />
<br />
:* profile is off cycle from Radiology TC now<br />
:* IHE Documentation staff availability<br />
:* profile does not get to TI by November<br />
<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* No unsolvable hurdles foreseen<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* 20% to complete through Trial Implementation publication for FUNC<br />
:* MUE 10% - 3 hours at each of 3 TC meetings<br />
::* get to Public Comment version ready for publication (but not Public Comment review)<br />
<br />
Candidate Editor:<br />
: Teri Sippel Schmidt</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=110827Follow-up of Non Critical Actionable Findings - Proposal2018-08-08T17:22:30Z<p>Terisippel: /* 5. Discussion */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''STILL IN DEV!~!!!'''<br />
<br />
==1. Proposed Workitem: Completion of Follow-Up of Non-Critical Actionable Findings (FUNC) supplement ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
'''The IHE TC problem:''' The possibility exists that the Follow-Up of Non-Critical Actionable Findings (FUNC) profile was underestimated in 2016 for its level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR). As a result, the Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses is no less relevant or important than it was when the profile was originally introduced.<br />
<br />
'''Current state of FUNC supplement:'''<br />
The scope of the FUNC profile itself was nearly halved in terms of length (i.e., number of pages) when the Results Distribution profile was spun off. The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
'''FUNC Volume 1:'''<br />
:The use cases and background material in Volume 1 are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
'''FUNC Volume 2:'''<br />
:The basic architecture has been determined; after intense and lengthy discussions, the "Alert Reporter" actor is effectively also a FHIR server.<br />
:Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussions as FHIR has evolved significantly in the last two years.<br />
<br />
'''The FUNC clinical problem statement:'''<br />
<br />
Taken from Volume 1:<br />
<br />
In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications within affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover the situation where a notification has to be sent between entirely distinct and unaffiliated facilities,.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 findings, or "non-critical actionable findings". ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are therefore not covered in or addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is an HL7 v2.5.1. order message (ORM).<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources.<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC supplement link Volume 2 has extensive additional detail.<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 transaction have been moved to the RD profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==''''''5. Discussion==<br />
<br />
We estimate that FUNC Volume 1 development (writing) is 80% complete to get to Public Comment.<br />
<br />
We estimate that FUNC Volume 2 development (writing) is 50% complete to get to Public Comment. In particular, the FHIR resource definitions are still under development and, other than RAD-128, should be reconsidered as a FHIR transaction.<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* editor: 8 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align (assume moving v2 ORM to FHIR)<br />
:* TC: 8 more TC sessions 2h each to re-review Vol 1 and complete Vol 2 transactions (1- ORM?, 3- FHIR); vote for PC (16 HOURS TC)<br />
:* editor: 3 h to clean up Volume 1 and re-align<br />
:* editor: 15 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editors: 5 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h sessions); vote for approval to TI<br />
:* editors: 20 h of PC comment clean up<br />
:* TC or individually: re-review supplement to vote for TI: 4 hours<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized '''TC committee''' efforts:<br />
<br />
:* To get to publish for Public Comment: 16 hours<br />
:* To review Public Comments: 12 hours<br />
:* To get to vote to publish for Trial Implementation: 4 hours<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter<br />
::* Alert Aggregator<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-Y1 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
<br />
::* 6 new FHIR transactions, however 3 of them are "acks"<br />
::* 1 new HL7 v2 ORM transaction, including ack<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:*Need to complete RD<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
<br />
See work break down above.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (i.e., Elliot Silver).<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 changes dramatically again. STU-3 is currently frozen. FHIR DSTU-4 is approximately a year out.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products do not use FHIR.<br />
:* Need to get RD out the door and to TI to be able to focus on FUNC.<br />
:* Disagreement on FHIR Resources selected during Public Comment period. (ie., Communication and Communication Request)<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
:* IHE TC availability for conference calls to get to Public Comment<br />
<br />
==8. Open Issues==<br />
<br />
:* profile is off cycle from Radiology TC now<br />
:* IHE Documentation staff availability<br />
:* profile does not get to TI by November<br />
<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* No unsolvable hurdles foreseen<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* 20% to complete through Trial Implementation publication for FUNC<br />
:* MUE 10% - 3 hours at each of 3 TC meetings<br />
::* get to Public Comment version ready for publication (but not Public Comment review)<br />
<br />
Candidate Editor:<br />
: Teri Sippel Schmidt</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=110826Follow-up of Non Critical Actionable Findings - Proposal2018-08-08T17:15:02Z<p>Terisippel: /* 4. Standards and Systems */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''STILL IN DEV!~!!!'''<br />
<br />
==1. Proposed Workitem: Completion of Follow-Up of Non-Critical Actionable Findings (FUNC) supplement ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
'''The IHE TC problem:''' The possibility exists that the Follow-Up of Non-Critical Actionable Findings (FUNC) profile was underestimated in 2016 for its level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR). As a result, the Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses is no less relevant or important than it was when the profile was originally introduced.<br />
<br />
'''Current state of FUNC supplement:'''<br />
The scope of the FUNC profile itself was nearly halved in terms of length (i.e., number of pages) when the Results Distribution profile was spun off. The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
'''FUNC Volume 1:'''<br />
:The use cases and background material in Volume 1 are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
'''FUNC Volume 2:'''<br />
:The basic architecture has been determined; after intense and lengthy discussions, the "Alert Reporter" actor is effectively also a FHIR server.<br />
:Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussions as FHIR has evolved significantly in the last two years.<br />
<br />
'''The FUNC clinical problem statement:'''<br />
<br />
Taken from Volume 1:<br />
<br />
In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications within affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover the situation where a notification has to be sent between entirely distinct and unaffiliated facilities,.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 findings, or "non-critical actionable findings". ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are therefore not covered in or addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is an HL7 v2.5.1. order message (ORM).<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources.<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today. (note: the existing supplement has the Alert Reporter as all-FHIR based transactions already.)<br />
<br />
The FUNC supplement link Volume 2 has extensive additional detail.<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 transaction have been moved to the RD profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==5. Discussion==<br />
<br />
We estimate that FUNC Volume 1 development (writing) is 80% complete to get to Public Comment.<br />
<br />
We estimate that FUNC Volume 2 development (writing) is 50% complete to get to Public Comment. In particular, the FHIR resource definitions are still under development.<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* TC: 6 more TC conference calls 2h each to complete transactions (1- ORM, 3- FHIR); vote for PC<br />
:* editor: 10 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editor: 3 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h conference calls); vote for approval to TI<br />
:* editor: 20 h of PC comment clean up<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized TC committee efforts:<br />
<br />
:* To get to publish for Public Comment: 12 hours<br />
:* To get to publish for Trial Implementation after Public Comment period: 12 hours<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter<br />
::* Alert Aggregator<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-Y1 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
<br />
::* 6 new FHIR transactions, however 3 of them are "acks"<br />
::* 1 new HL7 v2 ORM transaction, including ack<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:*Need to complete RD<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
<br />
See work break down above.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (i.e., Elliot Silver).<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 changes dramatically again. STU-3 is currently frozen. FHIR DSTU-4 is approximately a year out.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products do not use FHIR.<br />
:* Need to get RD out the door and to TI to be able to focus on FUNC.<br />
:* Disagreement on FHIR Resources selected during Public Comment period. (ie., Communication and Communication Request)<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
:* IHE TC availability for conference calls to get to Public Comment<br />
<br />
==8. Open Issues==<br />
<br />
:* profile is off cycle from Radiology TC now<br />
:* IHE Documentation staff availability<br />
:* profile does not get to TI by November<br />
<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* No unsolvable hurdles foreseen<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* 20% to complete through Trial Implementation publication for FUNC<br />
:* MUE 10% - 3 hours at each of 3 TC meetings<br />
::* get to Public Comment version ready for publication (but not Public Comment review)<br />
<br />
Candidate Editor:<br />
: Teri Sippel Schmidt</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=110825Follow-up of Non Critical Actionable Findings - Proposal2018-08-08T17:13:11Z<p>Terisippel: /* 2. The Problem */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''STILL IN DEV!~!!!'''<br />
<br />
==1. Proposed Workitem: Completion of Follow-Up of Non-Critical Actionable Findings (FUNC) supplement ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
'''The IHE TC problem:''' The possibility exists that the Follow-Up of Non-Critical Actionable Findings (FUNC) profile was underestimated in 2016 for its level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR). As a result, the Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and was completed 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses is no less relevant or important than it was when the profile was originally introduced.<br />
<br />
'''Current state of FUNC supplement:'''<br />
The scope of the FUNC profile itself was nearly halved in terms of length (i.e., number of pages) when the Results Distribution profile was spun off. The FUNC supplement text is currently ~100 pages in length with RD removed. <br />
<br />
'''FUNC Volume 1:'''<br />
:The use cases and background material in Volume 1 are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
'''FUNC Volume 2:'''<br />
:The basic architecture has been determined; after intense and lengthy discussions, the "Alert Reporter" actor is effectively also a FHIR server.<br />
:Prior assumptions about keeping all intra-radiology department transactions as HL7 v2.x messages should be reopened for discussions as FHIR has evolved significantly in the last two years.<br />
<br />
'''The FUNC clinical problem statement:'''<br />
<br />
Taken from Volume 1:<br />
<br />
In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications within affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover the situation where a notification has to be sent between entirely distinct and unaffiliated facilities,.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 findings, or "non-critical actionable findings". ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are therefore not covered in or addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is an HL7 v2.5.1. order message (ORM).<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources.<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today.<br />
<br />
The FUNC supplement link Volume 2 has extensive additional detail.<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 transaction have been moved to the RD profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==5. Discussion==<br />
<br />
We estimate that FUNC Volume 1 development (writing) is 80% complete to get to Public Comment.<br />
<br />
We estimate that FUNC Volume 2 development (writing) is 50% complete to get to Public Comment. In particular, the FHIR resource definitions are still under development.<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* TC: 6 more TC conference calls 2h each to complete transactions (1- ORM, 3- FHIR); vote for PC<br />
:* editor: 10 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editor: 3 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h conference calls); vote for approval to TI<br />
:* editor: 20 h of PC comment clean up<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized TC committee efforts:<br />
<br />
:* To get to publish for Public Comment: 12 hours<br />
:* To get to publish for Trial Implementation after Public Comment period: 12 hours<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter<br />
::* Alert Aggregator<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-Y1 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
<br />
::* 6 new FHIR transactions, however 3 of them are "acks"<br />
::* 1 new HL7 v2 ORM transaction, including ack<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:*Need to complete RD<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
<br />
See work break down above.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (i.e., Elliot Silver).<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 changes dramatically again. STU-3 is currently frozen. FHIR DSTU-4 is approximately a year out.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products do not use FHIR.<br />
:* Need to get RD out the door and to TI to be able to focus on FUNC.<br />
:* Disagreement on FHIR Resources selected during Public Comment period. (ie., Communication and Communication Request)<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
:* IHE TC availability for conference calls to get to Public Comment<br />
<br />
==8. Open Issues==<br />
<br />
:* profile is off cycle from Radiology TC now<br />
:* IHE Documentation staff availability<br />
:* profile does not get to TI by November<br />
<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* No unsolvable hurdles foreseen<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* 20% to complete through Trial Implementation publication for FUNC<br />
:* MUE 10% - 3 hours at each of 3 TC meetings<br />
::* get to Public Comment version ready for publication (but not Public Comment review)<br />
<br />
Candidate Editor:<br />
: Teri Sippel Schmidt</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=110813Follow-up of Non Critical Actionable Findings - Proposal2018-08-07T17:55:19Z<p>Terisippel: /* 1. Proposed Workitem: Completion of Follow-Up of Non-Critical Actionable Findings (FUNC) supplement */</p>
<hr />
<div>__NOTOC__<br />
<br />
'''STILL IN DEV!~!!!'''<br />
<br />
==1. Proposed Workitem: Completion of Follow-Up of Non-Critical Actionable Findings (FUNC) supplement ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Marquette, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania, Kinson Ho/Change<br />
* Editor: Teri Sippel Schmidt/Marquette and Kinson Ho/Change<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
'''The IHE TC problem:''' The possibility exists that the Follow-Up of Non-Critical Actionable Findings (FUNC) profile was underestimated in 2016 for its level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR). As a result, the Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and went to public comment in June, 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses is no less relevant or important than it was when the profile was originally introduced.<br />
<br />
'''Current state of FUNC supplement:'''<br />
The scope of the FUNC profile itself was nearly halved in terms of length (i.e., number of pages) when the Results Distribution profile was spun off. The FUNC supplement text is currently ~100 pages in length with RD removed. More recently, focus and resources were redirected from FUNC to focus on actual completion of RD.<br />
<br />
'''FUNC Volume 1:'''<br />
:The use cases and background material in Volume 1 are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
'''FUNC Volume 2:'''<br />
:The basic architecture has been determined; after intense and lengthy discussions, the "Alert Reporter" actor is effectively also a FHIR server.<br />
:The exact FHIR resources continue to evolve for two of the transactions, in part because FHIR is still evolving, and in larger part because of the IHE Rad TC learning curve.<br />
<br />
'''The FUNC clinical problem statement:'''<br />
<br />
Taken from Volume 1:<br />
<br />
In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications within affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover the situation where a notification has to be sent between entirely distinct and unaffiliated facilities,.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 findings, or "non-critical actionable findings". ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are therefore not covered in or addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is an HL7 v2.5.1. order message (ORM).<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources.<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today.<br />
<br />
The FUNC supplement link Volume 2 has extensive additional detail.<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 transaction have been moved to the RD profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==5. Discussion==<br />
<br />
We estimate that FUNC Volume 1 development (writing) is 80% complete to get to Public Comment.<br />
<br />
We estimate that FUNC Volume 2 development (writing) is 50% complete to get to Public Comment. In particular, the FHIR resource definitions are still under development.<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* TC: 6 more TC conference calls 2h each to complete transactions (1- ORM, 3- FHIR); vote for PC<br />
:* editor: 10 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editor: 3 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h conference calls); vote for approval to TI<br />
:* editor: 20 h of PC comment clean up<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized TC committee efforts:<br />
<br />
:* To get to publish for Public Comment: 12 hours<br />
:* To get to publish for Trial Implementation after Public Comment period: 12 hours<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter<br />
::* Alert Aggregator<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-Y1 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
<br />
::* 6 new FHIR transactions, however 3 of them are "acks"<br />
::* 1 new HL7 v2 ORM transaction, including ack<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:*Need to complete RD<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
<br />
See work break down above.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (i.e., Elliot Silver).<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 changes dramatically again. STU-3 is currently frozen. FHIR DSTU-4 is approximately a year out.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products do not use FHIR.<br />
:* Need to get RD out the door and to TI to be able to focus on FUNC.<br />
:* Disagreement on FHIR Resources selected during Public Comment period. (ie., Communication and Communication Request)<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
:* IHE TC availability for conference calls to get to Public Comment<br />
<br />
==8. Open Issues==<br />
<br />
:* profile is off cycle from Radiology TC now<br />
:* IHE Documentation staff availability<br />
:* profile does not get to TI by November<br />
<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* No unsolvable hurdles foreseen<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* 20% to complete through Trial Implementation publication for FUNC<br />
:* MUE 10% - 3 hours at each of 3 TC meetings<br />
::* get to Public Comment version ready for publication (but not Public Comment review)<br />
<br />
Candidate Editor:<br />
: Teri Sippel Schmidt</div>Terisippelhttp://wiki.ihe.net/index.php?title=Follow-up_of_Non_Critical_Actionable_Findings_-_Proposal&diff=110812Follow-up of Non Critical Actionable Findings - Proposal2018-08-07T17:54:16Z<p>Terisippel: Created page with "__NOTOC__ '''STILL IN DEV!~!!!''' ==1. Proposed Workitem: Completion of Follow-Up of Non-Critical Actionable Findings (FUNC) supplement == * Proposal Editor: Teri Sippel Sc..."</p>
<hr />
<div>__NOTOC__<br />
<br />
'''STILL IN DEV!~!!!'''<br />
<br />
==1. Proposed Workitem: Completion of Follow-Up of Non-Critical Actionable Findings (FUNC) supplement ==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Vital Images, Steve Langer/ Mayo Clinic, Tessa Cook, MD PhD/ Univ of Pennsylvania<br />
* Editor: Teri Sippel Schmidt/Vital Images<br />
* Date: N/A (Wiki keeps history)<br />
* Version: N/A (Wiki keeps history)<br />
* Domain: Radiology <br />
<br />
[[Category:RAD]]<br />
<br />
==2. The Problem==<br />
<br />
'''The IHE TC problem:''' The possibility exists that the Follow-Up of Non-Critical Actionable Findings (FUNC) profile was underestimated in 2016 for its level of complexity, scope, global differences, as well as technical challenges in adopting a new and evolving technology (FHIR). As a result, the Results Distribution (RD- HL7 v2.5.1 ORU message) was separated from the FUNC profile and went to public comment in June, 2017. Despite a valiant effort, the FUNC profile itself remains incomplete, but the problem it addresses is no less relevant or important than it was when the profile was originally introduced.<br />
<br />
'''Current state of FUNC supplement:'''<br />
The scope of the FUNC profile itself was nearly halved in terms of length (i.e., number of pages) when the Results Distribution profile was spun off. The FUNC supplement text is currently ~100 pages in length with RD removed. More recently, focus and resources were redirected from FUNC to focus on actual completion of RD.<br />
<br />
'''FUNC Volume 1:'''<br />
:The use cases and background material in Volume 1 are fairly well developed and have been reviewed several times by the IHE Rad Technical Committee. These will need to be re-reviewed in light of RD having been separated, but should ultimately be decreased rather than increased.<br />
'''FUNC Volume 2:'''<br />
:The basic architecture has been determined; after intense and lengthy discussions, the "Alert Reporter" actor is effectively also a FHIR server.<br />
:The exact FHIR resources continue to evolve for two of the transactions, in part because FHIR is still evolving, and in larger part because of the IHE Rad TC learning curve.<br />
<br />
'''The FUNC clinical problem statement:'''<br />
<br />
Taken from Volume 1:<br />
<br />
In a University of Pennsylvania (HUP) two-year study presented at RSNA 2016 looking at recommendations for follow-up based on abdominal imaging, researchers found that 14% of such exams recommended follow-up imaging for non-critical, actionable findings (Cook2016). A substudy looking at six months of these recommendations noted that there was a 4:1 ratio of in-system to out-of-system physicians ordering abdominal imaging performed at this large academic medical center. Combining these results, it is estimated that, at least for abdominal imaging, approximately 3% of exams contain non-critical, actionable findings that need to be communicated outside a single health system. As such, these patients are automatically at a much higher risk of not having their findings communicated (because the communication may currently rely on faxing printed results or calling ordering physicians’ offices). Using the large, academic center in the study above as an example, this translates to approximately 30,000 at-risk patients every year at HUP.<br />
<br />
The original FUNC 2016 Profile Proposal can be found here: [[Critical_Finding_Follow-up_and_Communication]]<br />
<br />
The current FUNC supplement under development can be found here: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit Draft of FUNC Supplement for Public Comment]<br />
<br />
==3. Key Use Case==<br />
<br />
This profile focuses on alert notifications within affiliated facilities, for example, from a hospital to a referring provider group, or within a Canadian provincial healthcare domain, and between known enterprises, for example, from the Medical College of Wisconsin and the University of Wisconsin, where there is significant patient population overlap and exchange of patient information. This profile is not intended to cover the situation where a notification has to be sent between entirely distinct and unaffiliated facilities,.<br />
<br />
Specifically, FUNC addresses communication and feedback for ACR Category 3 findings, or "non-critical actionable findings". ACR Category 1 and 2 (urgent and emergent) findings require immediate human intervention (i.e., a phone call to the physician caring for the patient) and are therefore not covered in or addressed by this profile.<br />
<br />
The six use cases currently defined in Volume 1 are:<br />
:'''X.4.2 Use Cases: Follow-Up Alerts of Non-Critical Actionable Findings'''<br />
::X.4.2.1 Use Case 1: Simple case of follow-up within a single healthcare system<br />
::X.4.2.2 Use Case 2: Multiple providers to be notified<br />
::X.4.2.3 Use Case 3: Affiliated healthcare systems<br />
::X.4.2.4 Use Case 4: Multiple alerts within a plan<br />
::X.4.2.5 Use Case 5: Follow-up rejected by provider<br />
::X.4.2.6 Use Case 6: Expiration of follow-up alert plan<br />
<br />
==4. Standards and Systems==<br />
<br />
The transaction within the Radiology Department, to set up the alert notification, is an HL7 v2.5.1. order message (ORM).<br />
<br />
The transactions to communicate this alert throughout the enterprise are FHIR CommunicationRequest and Communication Resources.<br />
<br />
The Alert Report actor does not yet exist, at least en masse, using standards in the real world today.<br />
<br />
The FUNC supplement link Volume 2 has extensive additional detail.<br />
<br />
The FUNC Actor Transaction diagram is as follows. The Report Manager and RAD-Y1 transaction have been moved to the RD profile.<br />
<br />
[[File:FUNC.AT diagram.png]]<br />
<br />
==5. Discussion==<br />
<br />
We estimate that FUNC Volume 1 development (writing) is 80% complete to get to Public Comment.<br />
<br />
We estimate that FUNC Volume 2 development (writing) is 50% complete to get to Public Comment. In particular, the FHIR resource definitions are still under development.<br />
<br />
Estimates for additional time and effort required to complete FUNC include:<br />
<br />
:* TC: 6 more TC conference calls 2h each to complete transactions (1- ORM, 3- FHIR); vote for PC<br />
:* editor: 10 h to clean up Volume 1 and re-align<br />
:* editor: 20 h to clean up Volume 2 and re-align<br />
:* doc specialist: 5 h to publish for Public Comment<br />
:* TC: 6 h each member to review independently and submit comments for PC<br />
:* editor: 3 h to clean up and organize PC comments<br />
:* TC: 12 h of PC comment review (qty 6 - 2h conference calls); vote for approval to TI<br />
:* editor: 20 h of PC comment clean up<br />
:* doc specialist: 5 h to to publish for Trial Implementation<br />
<br />
Summarized TC committee efforts:<br />
<br />
:* To get to publish for Public Comment: 12 hours<br />
:* To get to publish for Trial Implementation after Public Comment period: 12 hours<br />
<br />
==5. Technical Approach==<br />
<br />
See current supplement at: [https://docs.google.com/document/d/1pEQAIWDuD0HPQisBLlzF_FaovG8aWuIKgl163I3kr8E/edit?usp=sharing FUNC Profile]<br />
<br />
<br />
===Existing actors===<br />
<br />
:* See Volume 1: Report Manager<br />
<br />
===New actors===<br />
<br />
:* See Volume 1: <br />
<br />
::* Follow up Source<br />
::* Alert Reporter<br />
::* Alert Aggregator<br />
<br />
===Existing transactions===<br />
<br />
:* See Volume 1:<br />
<br />
::* RD RAD-Y1 (Send Imaging Results)<br />
<br />
===New transactions (standards used)===<br />
<br />
:* See Volume 1:<br />
<br />
::* 6 new FHIR transactions, however 3 of them are "acks"<br />
::* 1 new HL7 v2 ORM transaction, including ack<br />
<br />
===Impact on existing integration profiles===<br />
<br />
:*Need to complete RD<br />
<br />
===New integration profiles needed===<br />
''<Indicate what new profile(s) might need to be created.>''<br />
<br />
===Breakdown of tasks===<br />
<br />
<br />
See work break down above.<br />
<br />
==6. Support & Resources==<br />
<br />
:* Need to continue to have support from FHIR knowledgeable developers (i.e., Elliot Silver).<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep beyond current A/T diagram<br />
:* FHIR STU-3 changes dramatically again. STU-3 is currently frozen. FHIR DSTU-4 is approximately a year out.<br />
:* FHIR Communication and Communication Request is a FHIR Maturity Level 2.<br />
:* Current existing products do not use FHIR.<br />
:* Need to get RD out the door and to TI to be able to focus on FUNC.<br />
:* Disagreement on FHIR Resources selected during Public Comment period. (ie., Communication and Communication Request)<br />
:* Very specific technical issues such as differences of agreement on Contained Resources.<br />
:* IHE TC availability for conference calls to get to Public Comment<br />
<br />
==8. Open Issues==<br />
<br />
:* profile is off cycle from Radiology TC now<br />
:* IHE Documentation staff availability<br />
:* profile does not get to TI by November<br />
<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
:* No unsolvable hurdles foreseen<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
:* 20% to complete through Trial Implementation publication for FUNC<br />
:* MUE 10% - 3 hours at each of 3 TC meetings<br />
::* get to Public Comment version ready for publication (but not Public Comment review)<br />
<br />
Candidate Editor:<br />
: Teri Sippel Schmidt</div>Terisippelhttp://wiki.ihe.net/index.php?title=Radiology_Proposals_2018-2019&diff=110811Radiology Proposals 2018-20192018-08-07T17:53:58Z<p>Terisippel: /* Brief Proposals */</p>
<hr />
<div><!--<br />
===Final Selection===<br />
The following Proposals are selected for development work in this cycle. <br />
<br />
The Proposals were ranked as follows by the (link to Planning Committee minute).<br />
<br />
===Short List/ Detailed Proposals===<br />
The Tech Cmte agreed to evaluate N proposals. The following Proposals were shortlisted by the (link to Planning Committee minute).<br />
<br />
The Proposals will be evaluated by the Tech Cmte, (see TC wiki calendar for details). <br />
:* A. [[Rad TF Maintenance 2018-19]] - Effort: x% - Automatically Selected<br />
<br />
'''Reviewers''': Please enter your comments under Risks and Open Issues section of the proposal by COB Sept xx, 2018<br />
<br />
'''Editors''': To convert your Brief Proposal to a Detailed Proposal:<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 />
* 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 />
Tech Cmte evaluations will be recorded at the bottom of each detailed proposal.<br />
--><br />
<br />
===Brief Proposals===<br />
<br />
The following Proposals were submitted by the August 10, 2018, midnight deadline. <br />
<br />
:* A. [[Rad TF Maintenance 2018-19]] - presented by TC Co-Chairs: TBD<br />
:* B. [[Encounter Based Imaging Workflow for Lightweight Devices - Proposal]]<br />
:* C. [[Import_and_Display_of_External_Priors-_Proposal]]<br />
:* D: [[Follow-up of Non Critical Actionable Findings - Proposal]]<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 2017-2018|last year]]''' or earlier.<br />
<br />
<br />
1. Enter the name of your proposal (e.g. Management of Fantastic Notions - Brief Proposal) and click the Create button.<br />
<br />
<createbox><br />
type=create<br />
buttonlabel=Create New Proposal<br />
preload=Brief Proposal Template<br />
editintro=Brief Proposal Instructions<br />
align=left<br />
width=45<br />
break=no<br />
</createbox><br />
''The Wiki extension that made this auto-page-create-with-template work went away some years ago. We should either re-install it or remove this element.''<br />
<br />
2. Finish editing your new page, then edit '''this''' page (see the edit button up at the top) to add a link to your new page to the Brief Proposal list above.<br />
<br />
<br />
Contact radiology@ihe.net with any questions.<br />
<br />
===Committee Links===<br />
[[Radiology Planning Committee]]<br />
<br />
[[Radiology Technical Committee]]</div>Terisippelhttp://wiki.ihe.net/index.php?title=Import_and_Display_of_External_Priors-_Proposal&diff=110604Import and Display of External Priors- Proposal2018-07-24T23:51:26Z<p>Terisippel: /* Existing actors */</p>
<hr />
<div>{{TOCright}}<br />
==1. Proposed Workitem: Import and Display of External Priors (IDEP)==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt<br />
* Proposal Contributors: David Koff, MD; Canada Health Infoway; Kevin O'Donnell<br />
* Editor: Jonathan Whitby (previously Teri Sippel Schmidt)<br />
* Contributors: David Koff, MD; Canada Health Infoway<br />
* Domain: Radiology<br />
<br />
This proposal was previously called "[[Foreign_Exam_Management_Direct_Import-_Proposal|Foreign Exam Management (FEM)]]".<br />
<br />
==2. The Problem==<br />
<br />
Prior imaging studies provide vital information and context to the radiologist when interpreting a current study, even resulting in a change of diagnosis. A "prefetch" step (to locate prior studies for the patient that may be relevant and make them immediately accessible to the radiologist during review) is common in imaging workflows. This works fairly well for priors that were performed locally, even if they have to be pulled back from longer term storage to be ready for the radiologist. <br />
<br />
Unfortunately, with the mobility of modern healthcare, '''it is very common for priors to be located outside the reading institution'''.<br />
<br />
Although there have been many improvements to the ability to exchange images between enterprises, or between departments within an enterprise, '''the ability to locate, access, and view priors for direct comparison, particularly during the short time frame required for them to be relevant to reading, is still not reliable'''.<br />
* patient portals - are unwieldy, slow to access, and on different monitors<br />
* web-based viewers - are not integrated into the diagnostic workstation so they '''don't permit side-by side image comparison and use of local hanging protocols''' or viewing tools<br />
* CD/DVD imports/viewers - are often not timely, sometimes do not import reliably, and are "reactive not proactive"<br />
* all suffer from issues with different Patient IDs, procedure codes, etc, questions of long term storage, and some mappings not addressed in IRWF.b. <br />
* radiology reports - there is no primary standard for radiology reports, and as a result, report formats vary dramatically effectively eliminating interoperability of report sharing<br />
<br />
<br />
A solution for this priors problem has been demonstrated to '''also reduce re-scanned patients''' (with cost and radiation implications) due to poor access to studies performed at other institutions.<br />
(Ref: Nagels, J., Macdonald, D. & Coz, C. J Digit Imaging (2017). https://doi.org/10.1007/s10278-017-9963-8)<br />
<br />
==3. Key Use Case==<br />
<br />
'''Order-driven priors:'''<br />
<br />
:* A physician orders a radiology study for a patient<br />
:* The Importer actor searches for prior images <'''MinUE out of scope:''' and reports> for that patient, both locally and beyond<br />
::* The Importer uses PIX/PDQ to get appropriate PIDs for searching<br />
:* The Importer uses order details and local rules to determine which priors are potentially relevant (this profile focuses on specifying metadata availability to enable)<br />
:* The Importer retrieves matching prior images <'''MinUE out of scope''': and reports> executes import logic to map/fix codes and attribute values<br />
:* The Importer stores the imported priors to the local PACS <'''MinUE Out of Scope:''' and Report Manager><br />
:* The radiologist reads the study, accessing all priors using their usual workflow, display, hanging protocols, and image tools<br />
:* Post-interpretation rules (e.g. purging prior images and reports) occur locally<br />
<br />
The Profile supports a variety of image sharing architectures, e.g. centralized archiving for a region or IDN, federated PACS with point-to-point DIMSE access, etc.<br />
<br />
'''The intent is to make the existing, installed base of PACS systems work better without necessitating any changes or upgrades. The burden is centralized in the Importer and Report Converter actors rather than distributed to every sending or receiving system.'''<br />
<br />
<br />
'''Human Version of the Clinical Use Case'''<br />
<br />
Dr. Smith, a radiologist at a busy Cancer Center, is reporting a large number of CT studies which require comparison to previous imaging often performed at remote (but secure network connected) sites in the region, mostly community hospitals, but also academic centres where the patient may have been seen. The radiologist has to evaluate changes over time in order to assess treatment efficiency, with previous performed usually 3 to 6 months earlier. There may be a series of previous studies at the same interval over a period of a few years.<br />
<br />
Dr. Smith needs to report on a lesion’s change in size and appearance, as well as interval development or resolution of other conditions such as metastatic disease, peritoneal seeding or pleural effusions. For accuracy and speed, Dr Smith has to be able to cross-reference his CT slices and MPRs in DICOM format, using his own measurement tools.<br />
<br />
Dr. Smth wants the remote CT(s) to be readily available in his patient folder on his own PACS, and the studies displayed using his hanging protocols. He wants the report to be available the same way he displays previous reports for studies performed in his institution. <br />
<br />
'''The Problem Case Today'''<br />
<br />
Dr. Smith has to access a separate website, maybe with a separate sign-on. He has to search a separate database, he has to wait for images to load, slowing him down through his very busy work day. To make things worse, Dr. Smith has to open two separate web interfaces, one for the images, another one for the report, as the VNA was not be able to move the report with the images. <br />
<br />
Even though studies are all stored on a central VNA or there is access to other DICOM PACS systems, Dr. Smith has to ask the remote site to print a CD/DVD with the images. He then asks his PACS team to upload these images into his local PACS to make sure that images are available when he reports the current study. Not only is this a tedious manual process, but it delays the time the study is reported sometimes up to a few days. And, using the CD/DVD method, it is common that the previous report is not available.<br />
<br />
==4. Standards and Systems==<br />
<br />
'''Real World Systems:'''<br />
:* EMPI (IHE: PIX/PDQ Manager)<br />
:* RIS/EMRs (IHE: SWF.b DSS/OF, Report Manager, Report Reader)<br />
:* VNA or Diagnostic Imaging Repository (DI-r) (IHE: Image Manager, Report Manager, XDS.b Document Registry+ Document Repository+Imaging Document Source, possibly Importer and/or Report Converter)<br />
:* PACS (IHE: Image Manager/Archive, Image Display, Report Manager, Report Reader, possibly Importer and/or Report Converter)<br />
:* Note: the Importer and Report Converter actors may be separate systems, combined with a system above, or combined together - See Deployment options in Volume 1<br />
<br />
<br />
'''Standards:'''<br />
:* IRWF.b - useful importation logic and data mappings (but that IRWF.b is passive and doesn't specify pre and post steps)<br />
:* PIX/PDQ - patient identification<br />
:* MIMA Vol 2 Appendix J - fully qualified Patient ID reconciliation <br />
:* HL7 v2.x ORM/OMI (RAD-4 + IRWF.b data mappings ) - access to orders for new studies at the local site <br />
:* DICOM Q/R and XDS.b-I (RAD-5 and ITI-18) - find images <br />
:* DICOM C-Move and XDS.b-I (RAD-5 and ITI-18) - retrieve images <br />
:* DICOM C-Store - store images locally (default)<br />
:* '''MinUE Out of scope:''' Mobile Health Documents (MHD) -FHIR query documents<br />
:* '''MinUE Out of scope:''' XDS.b retrieve - report retrieval<br />
:* '''MinUE Out of scope:''' HL7 v2.x ORU (RD:RAD-128) - store report locally as TEXT or PDF<br />
<br />
A Cross Profile Consideration section X.6 discusses how DICOMweb services could be integrated in the future for image access and retrieval. Recommend limiting the required transactions on primary installed base (ie., HL7 v2.x, DICOM, XDS.b).<br />
<br />
==5. Discussion==<br />
<br />
The most important discussion is a consistently agreed upon, and not deviated from, definition of SCOPE:<br />
<br />
'''Minimum Useful Effort (MinUE) Baseline scope:''' Complete the current IDEP supplement, but do NOT include:<br />
:* Reports, in any format, not even TEXT or PDF<br />
:* WIA (DICOMweb) query to access prior images (except as reference in Cross Profile Considerations X.6)<br />
:* Retain Importer actor, but remove Report Converter actor and transactions<br />
:* Retain Image Purge and Report Purge as Named Options with no transactions (only defined behavior)<br />
:* Complete the IHE Public Comment and Trial Implementation processes <br />
:* (NOTE: removal of the Report Converter actor will be a SIGNIFICANT amount of effort for the editor and will include many changes to sections which have already been reviewed in detail by the TC).<br />
<br />
'''Maximum Useful Effort (MaxUE) (Additional) Scope for 2018-2019:'''<br />
:* Retain WIA (DICOMweb) query to access prior reports ONLY as reference in Cross Profile Considerations X.6 (no new DICOMweb functionality within IDEP)<br />
:* Only address TEXT and PDF report formats in direct scope in MaxUE<br />
:* Retain all other report formats as Volume 1 Informative Appendix and nothing more in MaxUE<br />
<br />
SEE [https://docs.google.com/spreadsheets/d/1IAKNiKwKHk3kFEs-mByfuvx91riorZv6El2GDjrZmAA/edit?usp=sharing THIS SUMMARY] FOR SPECIFIC STATUS OF EACH SECTION OF CURRENT SUPPLEMENT.<br />
<br />
This is intended to be a Workflow profile with one primary use case and one of two back-end architectures (all-DICOM and XDS.b (XDS.b as named option)): <br />
<br />
'''Workflow steps to be addressed:'''<br />
:* patient identification and PID reconciliation<br />
:* receipt of new orders<br />
:* relevancy logic meta data identification<br />
:* image retrieval <br />
:* DICOM attribute mapping <br />
:* storage of imported image <br />
:* '''MinUE Out of scope:''' report retrieval <br />
:* '''MinUE Out of scope:''' HL7 v2 ORU report attribute mapping <br />
:* '''MinUE Out of scope:'''storage of imported reports <br />
:* local purging of foreign images and foreign reports as defined Option<br />
<br />
<br />
'''Scope/assumptions:''' <br />
<br />
Goal is to enable automated and contextually integrated VIEWING of foreign radiology priors at the local system.<br />
<br />
:* Focus is on simplicity and existing installed base ("old school") - DICOM, HL7 v2.x, and XDS. (not image access using DICOM web services, or storage of reports using FHIR, etc)<br />
:* Secure network already in place between facilities. (Cross- non-affiliated enterprises out of scope.)<br />
:* EMPI (PIX/PDQ) already in place between facilities. <br />
:* Access prior imaging studies using DIMSE DICOM, but have XDS-I as a named Option. This XDS-I option would also include the hybrid DICOM/XDS.b environment since DICOM is the default environment.<br />
:* Storage of imaging study limited to DIMSE DICOM to the local PACS. (ie., not direct XDS import to the local PACS)<br />
:* Other image types such as Raw JPEG, PDF, etc., are out of scope.<br />
:* '''MinUE Out of scope:''' Report formats are limited to TEXT and PDF.<br />
:* '''MinUE Out of scope:''' Access of prior reports is limited to FHIR query for reports.<br />
:* '''MinUE Out of scope:''' Storage of prior reports is limited to HL7 v2.5.1 ORU with TEXT or PDF content.<br />
:* '''MinUE Out of scope:''' Report '''semantic content''' is always out of scope, i.e., structured or unstructured, etc. This could cause non-interoperability (unable to view), but is still out of scope and must be managed locally.<br />
<br />
==5. Technical Approach==<br />
<br />
:* Focus "intelligence" and mapping in new IDEP actors (Importer and Report Converter). Limit changes to ancillary systems.<br />
:* Populate <specific data element>, but stay away from terminology mapping.<br />
:* Default: Define meta data to be able to determine relevancy, but do not define relevancy rules. Server side v. client side filtering. (IDEP would specify client side filtering.)<br />
:* No intention to map procedure codes, study description, etc. Discuss in X.4 Concepts sections.<br />
:* Do not over-specify display requirements; e.g., "Required to display "something" to indicate that it is an external study."<br />
:* Retain WIA for remote image access via web services in Cross Profile Considerations (X.6); but do not explicitly include.<br />
<br />
<br />
===Existing actors===<br />
<br />
* "Local" DSS/OF<br />
* "Local" Image Manager<br />
* '''MinUE Out of scope:''' "Local" Report Manager<br />
* PIX/PDQ Manager<br />
* "Remote" Image Manager <br />
* '''MinUE Out of scope:''' "Remote" Report Manager <br />
* XDS.b Registry<br />
* XDS.b Repository<br />
* XDS.b-I Imaging Document Source<br />
<br />
===New actors===<br />
* Importer (same actor as IRWF.b, but additional behaviors)<br />
* Report Converter<br />
<br />
===Existing transactions===<br />
<br />
Because this proposed profiles focuses on improving the functionality of the existing installed base, it focuses on HL7 v2, DICOM DIMSE Services, and XDS.b transactions.<br />
<br />
See IDEP transaction diagram. (ie., many transactions)<br />
<br />
===New transactions (standards used)===<br />
<br />
A new DICOM query (DICOM query transaction proliferation) transaction was written for "Query for Patient Studies".<br />
New mapping tables were created for the (1) Order (OMI) message data for relevancy, (2) Coercion of MHD data for External Prior Reports, and (3) HL7 v2 ORU for External Prior Reports Mapping.<br />
<br />
===Impact on existing integration profiles===<br />
<br />
IOCM is "out of sync" with IDEP in terms of versions of standards used.<br />
IRWF.b and IDEP have overlap, but are not inconsistent and can peacefully co-exist for now.<br />
IDEP is consistent with current SWF.b profile, but it would be good if SWF.b were fully integrated as Final Text because it is hard to put all of the pieces together.<br />
<br />
===New integration profiles needed===<br />
<br />
None.<br />
<br />
===Breakdown of tasks===<br />
<br />
The high level breakdown of tasks is:<br />
<br />
: 1.) MinUE Baseline or MaxUE scope must be determined and uniformly (and indelibly) agreed to.<br />
: 2.) If MinUE baseline only, editor has a lot of work to do to remove all references to reports (40% of document)<br />
: 3.) Complete internal TC-review prior to Public Comment on un-reviewed sections; obtain vote to proceed to Public Comment.<br />
: 4.) Public comment period<br />
: 5.) Public comment review by TC and incorporation by Editor<br />
: 6.) Internal TC-review and changes by Editor; obtain vote to proceed to Trial Implementation.<br />
<br />
Just as a ballpark:<br />
-IDEP is currently ~80 pages<br />
-at the IHE Rad TC April F2F 52 pages were reviewed in detail, including all of the most difficult/controversial sections<br />
-at the IHE Rad TC Feb F2F 25 pages were discussed in detailed, but not reviewed, but much of this is informative and mapping tables<br />
<br />
The specific status of each section is listed in this document:<br />
https://docs.google.com/spreadsheets/d/1IAKNiKwKHk3kFEs-mByfuvx91riorZv6El2GDjrZmAA/edit?usp=sharing<br />
<br />
==6. Support & Resources==<br />
<br />
Canada Health Infoway has been very active in development of this technology and has implemented it across several broad regions, resulting in real-world data and analytics.<br />
<br />
HCA in the States has expressed in supporting and reviewing a standard to implement the import and display of external priors. HCA's focus is on the proper display of priors for side-by-side comparison in a most useful and effective manner.<br />
<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep to closely related clinical issues such as Emergency Department transfer<br />
:* Scope creep related to incorporating additional report formats beyond TEXT and PDF.<br />
:* Scope creep related to incorporating semantic meaning of reports.<br />
:* Scope creep related to additional methods of image and/or report access or image and/or report storage to local systems.<br />
:* Defining too much logic behind the word "relevant" - vendor/product differentiation; define only mechanisms<br />
:* Legal differences across jurisdictions<br />
<br />
==8. Open Issues==<br />
<br />
Scope creeped. Need to rein it back in, especially in the area of report formats. While report formats and transmission is undeniably a mess, the goal of the IDEP profile was never to fix report interoperability, but rather to access at least some of the prior reports. Complete report interoperability should be its own profile.<br />
<br />
May even want to consider not including informative appendices in Volume 1 on additional report formats, even if it is a critical gap in products today.<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
* % for Maximum/Full Effort = imaging and reports (ONLY report access via FHIR and storage via HL7 ORU TEXT and PDF)<br />
* % for Minimum Useful Effort<br />
:* 1.) Focus strictly on external prior IMAGE access, coercion, and storage<br />
:* 2.) No reports, not even as HL7 ORU TEXT or PDF, possibly mention Reports in X.4 Concepts section - see bolded "MinUE Out of scope" notes<br />
<br />
Candidate Editor:<br />
:* Jonathan Whitby/Vital, with Teri Sippel Schmidt consulting for historical purposes</div>Terisippelhttp://wiki.ihe.net/index.php?title=Import_and_Display_of_External_Priors-_Proposal&diff=110603Import and Display of External Priors- Proposal2018-07-24T23:51:11Z<p>Terisippel: /* Existing actors */</p>
<hr />
<div>{{TOCright}}<br />
==1. Proposed Workitem: Import and Display of External Priors (IDEP)==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt<br />
* Proposal Contributors: David Koff, MD; Canada Health Infoway; Kevin O'Donnell<br />
* Editor: Jonathan Whitby (previously Teri Sippel Schmidt)<br />
* Contributors: David Koff, MD; Canada Health Infoway<br />
* Domain: Radiology<br />
<br />
This proposal was previously called "[[Foreign_Exam_Management_Direct_Import-_Proposal|Foreign Exam Management (FEM)]]".<br />
<br />
==2. The Problem==<br />
<br />
Prior imaging studies provide vital information and context to the radiologist when interpreting a current study, even resulting in a change of diagnosis. A "prefetch" step (to locate prior studies for the patient that may be relevant and make them immediately accessible to the radiologist during review) is common in imaging workflows. This works fairly well for priors that were performed locally, even if they have to be pulled back from longer term storage to be ready for the radiologist. <br />
<br />
Unfortunately, with the mobility of modern healthcare, '''it is very common for priors to be located outside the reading institution'''.<br />
<br />
Although there have been many improvements to the ability to exchange images between enterprises, or between departments within an enterprise, '''the ability to locate, access, and view priors for direct comparison, particularly during the short time frame required for them to be relevant to reading, is still not reliable'''.<br />
* patient portals - are unwieldy, slow to access, and on different monitors<br />
* web-based viewers - are not integrated into the diagnostic workstation so they '''don't permit side-by side image comparison and use of local hanging protocols''' or viewing tools<br />
* CD/DVD imports/viewers - are often not timely, sometimes do not import reliably, and are "reactive not proactive"<br />
* all suffer from issues with different Patient IDs, procedure codes, etc, questions of long term storage, and some mappings not addressed in IRWF.b. <br />
* radiology reports - there is no primary standard for radiology reports, and as a result, report formats vary dramatically effectively eliminating interoperability of report sharing<br />
<br />
<br />
A solution for this priors problem has been demonstrated to '''also reduce re-scanned patients''' (with cost and radiation implications) due to poor access to studies performed at other institutions.<br />
(Ref: Nagels, J., Macdonald, D. & Coz, C. J Digit Imaging (2017). https://doi.org/10.1007/s10278-017-9963-8)<br />
<br />
==3. Key Use Case==<br />
<br />
'''Order-driven priors:'''<br />
<br />
:* A physician orders a radiology study for a patient<br />
:* The Importer actor searches for prior images <'''MinUE out of scope:''' and reports> for that patient, both locally and beyond<br />
::* The Importer uses PIX/PDQ to get appropriate PIDs for searching<br />
:* The Importer uses order details and local rules to determine which priors are potentially relevant (this profile focuses on specifying metadata availability to enable)<br />
:* The Importer retrieves matching prior images <'''MinUE out of scope''': and reports> executes import logic to map/fix codes and attribute values<br />
:* The Importer stores the imported priors to the local PACS <'''MinUE Out of Scope:''' and Report Manager><br />
:* The radiologist reads the study, accessing all priors using their usual workflow, display, hanging protocols, and image tools<br />
:* Post-interpretation rules (e.g. purging prior images and reports) occur locally<br />
<br />
The Profile supports a variety of image sharing architectures, e.g. centralized archiving for a region or IDN, federated PACS with point-to-point DIMSE access, etc.<br />
<br />
'''The intent is to make the existing, installed base of PACS systems work better without necessitating any changes or upgrades. The burden is centralized in the Importer and Report Converter actors rather than distributed to every sending or receiving system.'''<br />
<br />
<br />
'''Human Version of the Clinical Use Case'''<br />
<br />
Dr. Smith, a radiologist at a busy Cancer Center, is reporting a large number of CT studies which require comparison to previous imaging often performed at remote (but secure network connected) sites in the region, mostly community hospitals, but also academic centres where the patient may have been seen. The radiologist has to evaluate changes over time in order to assess treatment efficiency, with previous performed usually 3 to 6 months earlier. There may be a series of previous studies at the same interval over a period of a few years.<br />
<br />
Dr. Smith needs to report on a lesion’s change in size and appearance, as well as interval development or resolution of other conditions such as metastatic disease, peritoneal seeding or pleural effusions. For accuracy and speed, Dr Smith has to be able to cross-reference his CT slices and MPRs in DICOM format, using his own measurement tools.<br />
<br />
Dr. Smth wants the remote CT(s) to be readily available in his patient folder on his own PACS, and the studies displayed using his hanging protocols. He wants the report to be available the same way he displays previous reports for studies performed in his institution. <br />
<br />
'''The Problem Case Today'''<br />
<br />
Dr. Smith has to access a separate website, maybe with a separate sign-on. He has to search a separate database, he has to wait for images to load, slowing him down through his very busy work day. To make things worse, Dr. Smith has to open two separate web interfaces, one for the images, another one for the report, as the VNA was not be able to move the report with the images. <br />
<br />
Even though studies are all stored on a central VNA or there is access to other DICOM PACS systems, Dr. Smith has to ask the remote site to print a CD/DVD with the images. He then asks his PACS team to upload these images into his local PACS to make sure that images are available when he reports the current study. Not only is this a tedious manual process, but it delays the time the study is reported sometimes up to a few days. And, using the CD/DVD method, it is common that the previous report is not available.<br />
<br />
==4. Standards and Systems==<br />
<br />
'''Real World Systems:'''<br />
:* EMPI (IHE: PIX/PDQ Manager)<br />
:* RIS/EMRs (IHE: SWF.b DSS/OF, Report Manager, Report Reader)<br />
:* VNA or Diagnostic Imaging Repository (DI-r) (IHE: Image Manager, Report Manager, XDS.b Document Registry+ Document Repository+Imaging Document Source, possibly Importer and/or Report Converter)<br />
:* PACS (IHE: Image Manager/Archive, Image Display, Report Manager, Report Reader, possibly Importer and/or Report Converter)<br />
:* Note: the Importer and Report Converter actors may be separate systems, combined with a system above, or combined together - See Deployment options in Volume 1<br />
<br />
<br />
'''Standards:'''<br />
:* IRWF.b - useful importation logic and data mappings (but that IRWF.b is passive and doesn't specify pre and post steps)<br />
:* PIX/PDQ - patient identification<br />
:* MIMA Vol 2 Appendix J - fully qualified Patient ID reconciliation <br />
:* HL7 v2.x ORM/OMI (RAD-4 + IRWF.b data mappings ) - access to orders for new studies at the local site <br />
:* DICOM Q/R and XDS.b-I (RAD-5 and ITI-18) - find images <br />
:* DICOM C-Move and XDS.b-I (RAD-5 and ITI-18) - retrieve images <br />
:* DICOM C-Store - store images locally (default)<br />
:* '''MinUE Out of scope:''' Mobile Health Documents (MHD) -FHIR query documents<br />
:* '''MinUE Out of scope:''' XDS.b retrieve - report retrieval<br />
:* '''MinUE Out of scope:''' HL7 v2.x ORU (RD:RAD-128) - store report locally as TEXT or PDF<br />
<br />
A Cross Profile Consideration section X.6 discusses how DICOMweb services could be integrated in the future for image access and retrieval. Recommend limiting the required transactions on primary installed base (ie., HL7 v2.x, DICOM, XDS.b).<br />
<br />
==5. Discussion==<br />
<br />
The most important discussion is a consistently agreed upon, and not deviated from, definition of SCOPE:<br />
<br />
'''Minimum Useful Effort (MinUE) Baseline scope:''' Complete the current IDEP supplement, but do NOT include:<br />
:* Reports, in any format, not even TEXT or PDF<br />
:* WIA (DICOMweb) query to access prior images (except as reference in Cross Profile Considerations X.6)<br />
:* Retain Importer actor, but remove Report Converter actor and transactions<br />
:* Retain Image Purge and Report Purge as Named Options with no transactions (only defined behavior)<br />
:* Complete the IHE Public Comment and Trial Implementation processes <br />
:* (NOTE: removal of the Report Converter actor will be a SIGNIFICANT amount of effort for the editor and will include many changes to sections which have already been reviewed in detail by the TC).<br />
<br />
'''Maximum Useful Effort (MaxUE) (Additional) Scope for 2018-2019:'''<br />
:* Retain WIA (DICOMweb) query to access prior reports ONLY as reference in Cross Profile Considerations X.6 (no new DICOMweb functionality within IDEP)<br />
:* Only address TEXT and PDF report formats in direct scope in MaxUE<br />
:* Retain all other report formats as Volume 1 Informative Appendix and nothing more in MaxUE<br />
<br />
SEE [https://docs.google.com/spreadsheets/d/1IAKNiKwKHk3kFEs-mByfuvx91riorZv6El2GDjrZmAA/edit?usp=sharing THIS SUMMARY] FOR SPECIFIC STATUS OF EACH SECTION OF CURRENT SUPPLEMENT.<br />
<br />
This is intended to be a Workflow profile with one primary use case and one of two back-end architectures (all-DICOM and XDS.b (XDS.b as named option)): <br />
<br />
'''Workflow steps to be addressed:'''<br />
:* patient identification and PID reconciliation<br />
:* receipt of new orders<br />
:* relevancy logic meta data identification<br />
:* image retrieval <br />
:* DICOM attribute mapping <br />
:* storage of imported image <br />
:* '''MinUE Out of scope:''' report retrieval <br />
:* '''MinUE Out of scope:''' HL7 v2 ORU report attribute mapping <br />
:* '''MinUE Out of scope:'''storage of imported reports <br />
:* local purging of foreign images and foreign reports as defined Option<br />
<br />
<br />
'''Scope/assumptions:''' <br />
<br />
Goal is to enable automated and contextually integrated VIEWING of foreign radiology priors at the local system.<br />
<br />
:* Focus is on simplicity and existing installed base ("old school") - DICOM, HL7 v2.x, and XDS. (not image access using DICOM web services, or storage of reports using FHIR, etc)<br />
:* Secure network already in place between facilities. (Cross- non-affiliated enterprises out of scope.)<br />
:* EMPI (PIX/PDQ) already in place between facilities. <br />
:* Access prior imaging studies using DIMSE DICOM, but have XDS-I as a named Option. This XDS-I option would also include the hybrid DICOM/XDS.b environment since DICOM is the default environment.<br />
:* Storage of imaging study limited to DIMSE DICOM to the local PACS. (ie., not direct XDS import to the local PACS)<br />
:* Other image types such as Raw JPEG, PDF, etc., are out of scope.<br />
:* '''MinUE Out of scope:''' Report formats are limited to TEXT and PDF.<br />
:* '''MinUE Out of scope:''' Access of prior reports is limited to FHIR query for reports.<br />
:* '''MinUE Out of scope:''' Storage of prior reports is limited to HL7 v2.5.1 ORU with TEXT or PDF content.<br />
:* '''MinUE Out of scope:''' Report '''semantic content''' is always out of scope, i.e., structured or unstructured, etc. This could cause non-interoperability (unable to view), but is still out of scope and must be managed locally.<br />
<br />
==5. Technical Approach==<br />
<br />
:* Focus "intelligence" and mapping in new IDEP actors (Importer and Report Converter). Limit changes to ancillary systems.<br />
:* Populate <specific data element>, but stay away from terminology mapping.<br />
:* Default: Define meta data to be able to determine relevancy, but do not define relevancy rules. Server side v. client side filtering. (IDEP would specify client side filtering.)<br />
:* No intention to map procedure codes, study description, etc. Discuss in X.4 Concepts sections.<br />
:* Do not over-specify display requirements; e.g., "Required to display "something" to indicate that it is an external study."<br />
:* Retain WIA for remote image access via web services in Cross Profile Considerations (X.6); but do not explicitly include.<br />
<br />
<br />
===Existing actors===<br />
<br />
* "Local" DSS/OF<br />
* "Local" Image Manager<br />
* '''MinUE Out of scope:''' "Local" Report Manager<br />
* PIX/PDQ Manager<br />
* "Remote" Image Manager <br />
* '''MinUE Out of scope:''' "Remote" Report Manager <br />
* XDS.b Registry<br />
* '''MinUE Out of scope:''' XDS.b Repository<br />
* XDS.b-I Imaging Document Source<br />
<br />
===New actors===<br />
* Importer (same actor as IRWF.b, but additional behaviors)<br />
* Report Converter<br />
<br />
===Existing transactions===<br />
<br />
Because this proposed profiles focuses on improving the functionality of the existing installed base, it focuses on HL7 v2, DICOM DIMSE Services, and XDS.b transactions.<br />
<br />
See IDEP transaction diagram. (ie., many transactions)<br />
<br />
===New transactions (standards used)===<br />
<br />
A new DICOM query (DICOM query transaction proliferation) transaction was written for "Query for Patient Studies".<br />
New mapping tables were created for the (1) Order (OMI) message data for relevancy, (2) Coercion of MHD data for External Prior Reports, and (3) HL7 v2 ORU for External Prior Reports Mapping.<br />
<br />
===Impact on existing integration profiles===<br />
<br />
IOCM is "out of sync" with IDEP in terms of versions of standards used.<br />
IRWF.b and IDEP have overlap, but are not inconsistent and can peacefully co-exist for now.<br />
IDEP is consistent with current SWF.b profile, but it would be good if SWF.b were fully integrated as Final Text because it is hard to put all of the pieces together.<br />
<br />
===New integration profiles needed===<br />
<br />
None.<br />
<br />
===Breakdown of tasks===<br />
<br />
The high level breakdown of tasks is:<br />
<br />
: 1.) MinUE Baseline or MaxUE scope must be determined and uniformly (and indelibly) agreed to.<br />
: 2.) If MinUE baseline only, editor has a lot of work to do to remove all references to reports (40% of document)<br />
: 3.) Complete internal TC-review prior to Public Comment on un-reviewed sections; obtain vote to proceed to Public Comment.<br />
: 4.) Public comment period<br />
: 5.) Public comment review by TC and incorporation by Editor<br />
: 6.) Internal TC-review and changes by Editor; obtain vote to proceed to Trial Implementation.<br />
<br />
Just as a ballpark:<br />
-IDEP is currently ~80 pages<br />
-at the IHE Rad TC April F2F 52 pages were reviewed in detail, including all of the most difficult/controversial sections<br />
-at the IHE Rad TC Feb F2F 25 pages were discussed in detailed, but not reviewed, but much of this is informative and mapping tables<br />
<br />
The specific status of each section is listed in this document:<br />
https://docs.google.com/spreadsheets/d/1IAKNiKwKHk3kFEs-mByfuvx91riorZv6El2GDjrZmAA/edit?usp=sharing<br />
<br />
==6. Support & Resources==<br />
<br />
Canada Health Infoway has been very active in development of this technology and has implemented it across several broad regions, resulting in real-world data and analytics.<br />
<br />
HCA in the States has expressed in supporting and reviewing a standard to implement the import and display of external priors. HCA's focus is on the proper display of priors for side-by-side comparison in a most useful and effective manner.<br />
<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep to closely related clinical issues such as Emergency Department transfer<br />
:* Scope creep related to incorporating additional report formats beyond TEXT and PDF.<br />
:* Scope creep related to incorporating semantic meaning of reports.<br />
:* Scope creep related to additional methods of image and/or report access or image and/or report storage to local systems.<br />
:* Defining too much logic behind the word "relevant" - vendor/product differentiation; define only mechanisms<br />
:* Legal differences across jurisdictions<br />
<br />
==8. Open Issues==<br />
<br />
Scope creeped. Need to rein it back in, especially in the area of report formats. While report formats and transmission is undeniably a mess, the goal of the IDEP profile was never to fix report interoperability, but rather to access at least some of the prior reports. Complete report interoperability should be its own profile.<br />
<br />
May even want to consider not including informative appendices in Volume 1 on additional report formats, even if it is a critical gap in products today.<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
* % for Maximum/Full Effort = imaging and reports (ONLY report access via FHIR and storage via HL7 ORU TEXT and PDF)<br />
* % for Minimum Useful Effort<br />
:* 1.) Focus strictly on external prior IMAGE access, coercion, and storage<br />
:* 2.) No reports, not even as HL7 ORU TEXT or PDF, possibly mention Reports in X.4 Concepts section - see bolded "MinUE Out of scope" notes<br />
<br />
Candidate Editor:<br />
:* Jonathan Whitby/Vital, with Teri Sippel Schmidt consulting for historical purposes</div>Terisippelhttp://wiki.ihe.net/index.php?title=Import_and_Display_of_External_Priors-_Proposal&diff=110602Import and Display of External Priors- Proposal2018-07-24T23:50:39Z<p>Terisippel: /* Existing actors */</p>
<hr />
<div>{{TOCright}}<br />
==1. Proposed Workitem: Import and Display of External Priors (IDEP)==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt<br />
* Proposal Contributors: David Koff, MD; Canada Health Infoway; Kevin O'Donnell<br />
* Editor: Jonathan Whitby (previously Teri Sippel Schmidt)<br />
* Contributors: David Koff, MD; Canada Health Infoway<br />
* Domain: Radiology<br />
<br />
This proposal was previously called "[[Foreign_Exam_Management_Direct_Import-_Proposal|Foreign Exam Management (FEM)]]".<br />
<br />
==2. The Problem==<br />
<br />
Prior imaging studies provide vital information and context to the radiologist when interpreting a current study, even resulting in a change of diagnosis. A "prefetch" step (to locate prior studies for the patient that may be relevant and make them immediately accessible to the radiologist during review) is common in imaging workflows. This works fairly well for priors that were performed locally, even if they have to be pulled back from longer term storage to be ready for the radiologist. <br />
<br />
Unfortunately, with the mobility of modern healthcare, '''it is very common for priors to be located outside the reading institution'''.<br />
<br />
Although there have been many improvements to the ability to exchange images between enterprises, or between departments within an enterprise, '''the ability to locate, access, and view priors for direct comparison, particularly during the short time frame required for them to be relevant to reading, is still not reliable'''.<br />
* patient portals - are unwieldy, slow to access, and on different monitors<br />
* web-based viewers - are not integrated into the diagnostic workstation so they '''don't permit side-by side image comparison and use of local hanging protocols''' or viewing tools<br />
* CD/DVD imports/viewers - are often not timely, sometimes do not import reliably, and are "reactive not proactive"<br />
* all suffer from issues with different Patient IDs, procedure codes, etc, questions of long term storage, and some mappings not addressed in IRWF.b. <br />
* radiology reports - there is no primary standard for radiology reports, and as a result, report formats vary dramatically effectively eliminating interoperability of report sharing<br />
<br />
<br />
A solution for this priors problem has been demonstrated to '''also reduce re-scanned patients''' (with cost and radiation implications) due to poor access to studies performed at other institutions.<br />
(Ref: Nagels, J., Macdonald, D. & Coz, C. J Digit Imaging (2017). https://doi.org/10.1007/s10278-017-9963-8)<br />
<br />
==3. Key Use Case==<br />
<br />
'''Order-driven priors:'''<br />
<br />
:* A physician orders a radiology study for a patient<br />
:* The Importer actor searches for prior images <'''MinUE out of scope:''' and reports> for that patient, both locally and beyond<br />
::* The Importer uses PIX/PDQ to get appropriate PIDs for searching<br />
:* The Importer uses order details and local rules to determine which priors are potentially relevant (this profile focuses on specifying metadata availability to enable)<br />
:* The Importer retrieves matching prior images <'''MinUE out of scope''': and reports> executes import logic to map/fix codes and attribute values<br />
:* The Importer stores the imported priors to the local PACS <'''MinUE Out of Scope:''' and Report Manager><br />
:* The radiologist reads the study, accessing all priors using their usual workflow, display, hanging protocols, and image tools<br />
:* Post-interpretation rules (e.g. purging prior images and reports) occur locally<br />
<br />
The Profile supports a variety of image sharing architectures, e.g. centralized archiving for a region or IDN, federated PACS with point-to-point DIMSE access, etc.<br />
<br />
'''The intent is to make the existing, installed base of PACS systems work better without necessitating any changes or upgrades. The burden is centralized in the Importer and Report Converter actors rather than distributed to every sending or receiving system.'''<br />
<br />
<br />
'''Human Version of the Clinical Use Case'''<br />
<br />
Dr. Smith, a radiologist at a busy Cancer Center, is reporting a large number of CT studies which require comparison to previous imaging often performed at remote (but secure network connected) sites in the region, mostly community hospitals, but also academic centres where the patient may have been seen. The radiologist has to evaluate changes over time in order to assess treatment efficiency, with previous performed usually 3 to 6 months earlier. There may be a series of previous studies at the same interval over a period of a few years.<br />
<br />
Dr. Smith needs to report on a lesion’s change in size and appearance, as well as interval development or resolution of other conditions such as metastatic disease, peritoneal seeding or pleural effusions. For accuracy and speed, Dr Smith has to be able to cross-reference his CT slices and MPRs in DICOM format, using his own measurement tools.<br />
<br />
Dr. Smth wants the remote CT(s) to be readily available in his patient folder on his own PACS, and the studies displayed using his hanging protocols. He wants the report to be available the same way he displays previous reports for studies performed in his institution. <br />
<br />
'''The Problem Case Today'''<br />
<br />
Dr. Smith has to access a separate website, maybe with a separate sign-on. He has to search a separate database, he has to wait for images to load, slowing him down through his very busy work day. To make things worse, Dr. Smith has to open two separate web interfaces, one for the images, another one for the report, as the VNA was not be able to move the report with the images. <br />
<br />
Even though studies are all stored on a central VNA or there is access to other DICOM PACS systems, Dr. Smith has to ask the remote site to print a CD/DVD with the images. He then asks his PACS team to upload these images into his local PACS to make sure that images are available when he reports the current study. Not only is this a tedious manual process, but it delays the time the study is reported sometimes up to a few days. And, using the CD/DVD method, it is common that the previous report is not available.<br />
<br />
==4. Standards and Systems==<br />
<br />
'''Real World Systems:'''<br />
:* EMPI (IHE: PIX/PDQ Manager)<br />
:* RIS/EMRs (IHE: SWF.b DSS/OF, Report Manager, Report Reader)<br />
:* VNA or Diagnostic Imaging Repository (DI-r) (IHE: Image Manager, Report Manager, XDS.b Document Registry+ Document Repository+Imaging Document Source, possibly Importer and/or Report Converter)<br />
:* PACS (IHE: Image Manager/Archive, Image Display, Report Manager, Report Reader, possibly Importer and/or Report Converter)<br />
:* Note: the Importer and Report Converter actors may be separate systems, combined with a system above, or combined together - See Deployment options in Volume 1<br />
<br />
<br />
'''Standards:'''<br />
:* IRWF.b - useful importation logic and data mappings (but that IRWF.b is passive and doesn't specify pre and post steps)<br />
:* PIX/PDQ - patient identification<br />
:* MIMA Vol 2 Appendix J - fully qualified Patient ID reconciliation <br />
:* HL7 v2.x ORM/OMI (RAD-4 + IRWF.b data mappings ) - access to orders for new studies at the local site <br />
:* DICOM Q/R and XDS.b-I (RAD-5 and ITI-18) - find images <br />
:* DICOM C-Move and XDS.b-I (RAD-5 and ITI-18) - retrieve images <br />
:* DICOM C-Store - store images locally (default)<br />
:* '''MinUE Out of scope:''' Mobile Health Documents (MHD) -FHIR query documents<br />
:* '''MinUE Out of scope:''' XDS.b retrieve - report retrieval<br />
:* '''MinUE Out of scope:''' HL7 v2.x ORU (RD:RAD-128) - store report locally as TEXT or PDF<br />
<br />
A Cross Profile Consideration section X.6 discusses how DICOMweb services could be integrated in the future for image access and retrieval. Recommend limiting the required transactions on primary installed base (ie., HL7 v2.x, DICOM, XDS.b).<br />
<br />
==5. Discussion==<br />
<br />
The most important discussion is a consistently agreed upon, and not deviated from, definition of SCOPE:<br />
<br />
'''Minimum Useful Effort (MinUE) Baseline scope:''' Complete the current IDEP supplement, but do NOT include:<br />
:* Reports, in any format, not even TEXT or PDF<br />
:* WIA (DICOMweb) query to access prior images (except as reference in Cross Profile Considerations X.6)<br />
:* Retain Importer actor, but remove Report Converter actor and transactions<br />
:* Retain Image Purge and Report Purge as Named Options with no transactions (only defined behavior)<br />
:* Complete the IHE Public Comment and Trial Implementation processes <br />
:* (NOTE: removal of the Report Converter actor will be a SIGNIFICANT amount of effort for the editor and will include many changes to sections which have already been reviewed in detail by the TC).<br />
<br />
'''Maximum Useful Effort (MaxUE) (Additional) Scope for 2018-2019:'''<br />
:* Retain WIA (DICOMweb) query to access prior reports ONLY as reference in Cross Profile Considerations X.6 (no new DICOMweb functionality within IDEP)<br />
:* Only address TEXT and PDF report formats in direct scope in MaxUE<br />
:* Retain all other report formats as Volume 1 Informative Appendix and nothing more in MaxUE<br />
<br />
SEE [https://docs.google.com/spreadsheets/d/1IAKNiKwKHk3kFEs-mByfuvx91riorZv6El2GDjrZmAA/edit?usp=sharing THIS SUMMARY] FOR SPECIFIC STATUS OF EACH SECTION OF CURRENT SUPPLEMENT.<br />
<br />
This is intended to be a Workflow profile with one primary use case and one of two back-end architectures (all-DICOM and XDS.b (XDS.b as named option)): <br />
<br />
'''Workflow steps to be addressed:'''<br />
:* patient identification and PID reconciliation<br />
:* receipt of new orders<br />
:* relevancy logic meta data identification<br />
:* image retrieval <br />
:* DICOM attribute mapping <br />
:* storage of imported image <br />
:* '''MinUE Out of scope:''' report retrieval <br />
:* '''MinUE Out of scope:''' HL7 v2 ORU report attribute mapping <br />
:* '''MinUE Out of scope:'''storage of imported reports <br />
:* local purging of foreign images and foreign reports as defined Option<br />
<br />
<br />
'''Scope/assumptions:''' <br />
<br />
Goal is to enable automated and contextually integrated VIEWING of foreign radiology priors at the local system.<br />
<br />
:* Focus is on simplicity and existing installed base ("old school") - DICOM, HL7 v2.x, and XDS. (not image access using DICOM web services, or storage of reports using FHIR, etc)<br />
:* Secure network already in place between facilities. (Cross- non-affiliated enterprises out of scope.)<br />
:* EMPI (PIX/PDQ) already in place between facilities. <br />
:* Access prior imaging studies using DIMSE DICOM, but have XDS-I as a named Option. This XDS-I option would also include the hybrid DICOM/XDS.b environment since DICOM is the default environment.<br />
:* Storage of imaging study limited to DIMSE DICOM to the local PACS. (ie., not direct XDS import to the local PACS)<br />
:* Other image types such as Raw JPEG, PDF, etc., are out of scope.<br />
:* '''MinUE Out of scope:''' Report formats are limited to TEXT and PDF.<br />
:* '''MinUE Out of scope:''' Access of prior reports is limited to FHIR query for reports.<br />
:* '''MinUE Out of scope:''' Storage of prior reports is limited to HL7 v2.5.1 ORU with TEXT or PDF content.<br />
:* '''MinUE Out of scope:''' Report '''semantic content''' is always out of scope, i.e., structured or unstructured, etc. This could cause non-interoperability (unable to view), but is still out of scope and must be managed locally.<br />
<br />
==5. Technical Approach==<br />
<br />
:* Focus "intelligence" and mapping in new IDEP actors (Importer and Report Converter). Limit changes to ancillary systems.<br />
:* Populate <specific data element>, but stay away from terminology mapping.<br />
:* Default: Define meta data to be able to determine relevancy, but do not define relevancy rules. Server side v. client side filtering. (IDEP would specify client side filtering.)<br />
:* No intention to map procedure codes, study description, etc. Discuss in X.4 Concepts sections.<br />
:* Do not over-specify display requirements; e.g., "Required to display "something" to indicate that it is an external study."<br />
:* Retain WIA for remote image access via web services in Cross Profile Considerations (X.6); but do not explicitly include.<br />
<br />
<br />
===Existing actors===<br />
<br />
* "Local" DSS/OF<br />
* "Local" Image Manager<br />
* MinUE Out of scope: "Local" Report Manager<br />
* PIX/PDQ Manager<br />
* "Remote" Image Manager <br />
* MinUE Out of scope: "' Remote Report Manager <br />
* XDS.b Registry<br />
* MinUE Out of scope: XDS.b Repository<br />
* XDS.b-I Imaging Document Source<br />
<br />
===New actors===<br />
* Importer (same actor as IRWF.b, but additional behaviors)<br />
* Report Converter<br />
<br />
===Existing transactions===<br />
<br />
Because this proposed profiles focuses on improving the functionality of the existing installed base, it focuses on HL7 v2, DICOM DIMSE Services, and XDS.b transactions.<br />
<br />
See IDEP transaction diagram. (ie., many transactions)<br />
<br />
===New transactions (standards used)===<br />
<br />
A new DICOM query (DICOM query transaction proliferation) transaction was written for "Query for Patient Studies".<br />
New mapping tables were created for the (1) Order (OMI) message data for relevancy, (2) Coercion of MHD data for External Prior Reports, and (3) HL7 v2 ORU for External Prior Reports Mapping.<br />
<br />
===Impact on existing integration profiles===<br />
<br />
IOCM is "out of sync" with IDEP in terms of versions of standards used.<br />
IRWF.b and IDEP have overlap, but are not inconsistent and can peacefully co-exist for now.<br />
IDEP is consistent with current SWF.b profile, but it would be good if SWF.b were fully integrated as Final Text because it is hard to put all of the pieces together.<br />
<br />
===New integration profiles needed===<br />
<br />
None.<br />
<br />
===Breakdown of tasks===<br />
<br />
The high level breakdown of tasks is:<br />
<br />
: 1.) MinUE Baseline or MaxUE scope must be determined and uniformly (and indelibly) agreed to.<br />
: 2.) If MinUE baseline only, editor has a lot of work to do to remove all references to reports (40% of document)<br />
: 3.) Complete internal TC-review prior to Public Comment on un-reviewed sections; obtain vote to proceed to Public Comment.<br />
: 4.) Public comment period<br />
: 5.) Public comment review by TC and incorporation by Editor<br />
: 6.) Internal TC-review and changes by Editor; obtain vote to proceed to Trial Implementation.<br />
<br />
Just as a ballpark:<br />
-IDEP is currently ~80 pages<br />
-at the IHE Rad TC April F2F 52 pages were reviewed in detail, including all of the most difficult/controversial sections<br />
-at the IHE Rad TC Feb F2F 25 pages were discussed in detailed, but not reviewed, but much of this is informative and mapping tables<br />
<br />
The specific status of each section is listed in this document:<br />
https://docs.google.com/spreadsheets/d/1IAKNiKwKHk3kFEs-mByfuvx91riorZv6El2GDjrZmAA/edit?usp=sharing<br />
<br />
==6. Support & Resources==<br />
<br />
Canada Health Infoway has been very active in development of this technology and has implemented it across several broad regions, resulting in real-world data and analytics.<br />
<br />
HCA in the States has expressed in supporting and reviewing a standard to implement the import and display of external priors. HCA's focus is on the proper display of priors for side-by-side comparison in a most useful and effective manner.<br />
<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep to closely related clinical issues such as Emergency Department transfer<br />
:* Scope creep related to incorporating additional report formats beyond TEXT and PDF.<br />
:* Scope creep related to incorporating semantic meaning of reports.<br />
:* Scope creep related to additional methods of image and/or report access or image and/or report storage to local systems.<br />
:* Defining too much logic behind the word "relevant" - vendor/product differentiation; define only mechanisms<br />
:* Legal differences across jurisdictions<br />
<br />
==8. Open Issues==<br />
<br />
Scope creeped. Need to rein it back in, especially in the area of report formats. While report formats and transmission is undeniably a mess, the goal of the IDEP profile was never to fix report interoperability, but rather to access at least some of the prior reports. Complete report interoperability should be its own profile.<br />
<br />
May even want to consider not including informative appendices in Volume 1 on additional report formats, even if it is a critical gap in products today.<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
* % for Maximum/Full Effort = imaging and reports (ONLY report access via FHIR and storage via HL7 ORU TEXT and PDF)<br />
* % for Minimum Useful Effort<br />
:* 1.) Focus strictly on external prior IMAGE access, coercion, and storage<br />
:* 2.) No reports, not even as HL7 ORU TEXT or PDF, possibly mention Reports in X.4 Concepts section - see bolded "MinUE Out of scope" notes<br />
<br />
Candidate Editor:<br />
:* Jonathan Whitby/Vital, with Teri Sippel Schmidt consulting for historical purposes</div>Terisippelhttp://wiki.ihe.net/index.php?title=Import_and_Display_of_External_Priors-_Proposal&diff=110601Import and Display of External Priors- Proposal2018-07-24T23:49:33Z<p>Terisippel: /* Existing actors */</p>
<hr />
<div>{{TOCright}}<br />
==1. Proposed Workitem: Import and Display of External Priors (IDEP)==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt<br />
* Proposal Contributors: David Koff, MD; Canada Health Infoway; Kevin O'Donnell<br />
* Editor: Jonathan Whitby (previously Teri Sippel Schmidt)<br />
* Contributors: David Koff, MD; Canada Health Infoway<br />
* Domain: Radiology<br />
<br />
This proposal was previously called "[[Foreign_Exam_Management_Direct_Import-_Proposal|Foreign Exam Management (FEM)]]".<br />
<br />
==2. The Problem==<br />
<br />
Prior imaging studies provide vital information and context to the radiologist when interpreting a current study, even resulting in a change of diagnosis. A "prefetch" step (to locate prior studies for the patient that may be relevant and make them immediately accessible to the radiologist during review) is common in imaging workflows. This works fairly well for priors that were performed locally, even if they have to be pulled back from longer term storage to be ready for the radiologist. <br />
<br />
Unfortunately, with the mobility of modern healthcare, '''it is very common for priors to be located outside the reading institution'''.<br />
<br />
Although there have been many improvements to the ability to exchange images between enterprises, or between departments within an enterprise, '''the ability to locate, access, and view priors for direct comparison, particularly during the short time frame required for them to be relevant to reading, is still not reliable'''.<br />
* patient portals - are unwieldy, slow to access, and on different monitors<br />
* web-based viewers - are not integrated into the diagnostic workstation so they '''don't permit side-by side image comparison and use of local hanging protocols''' or viewing tools<br />
* CD/DVD imports/viewers - are often not timely, sometimes do not import reliably, and are "reactive not proactive"<br />
* all suffer from issues with different Patient IDs, procedure codes, etc, questions of long term storage, and some mappings not addressed in IRWF.b. <br />
* radiology reports - there is no primary standard for radiology reports, and as a result, report formats vary dramatically effectively eliminating interoperability of report sharing<br />
<br />
<br />
A solution for this priors problem has been demonstrated to '''also reduce re-scanned patients''' (with cost and radiation implications) due to poor access to studies performed at other institutions.<br />
(Ref: Nagels, J., Macdonald, D. & Coz, C. J Digit Imaging (2017). https://doi.org/10.1007/s10278-017-9963-8)<br />
<br />
==3. Key Use Case==<br />
<br />
'''Order-driven priors:'''<br />
<br />
:* A physician orders a radiology study for a patient<br />
:* The Importer actor searches for prior images <'''MinUE out of scope:''' and reports> for that patient, both locally and beyond<br />
::* The Importer uses PIX/PDQ to get appropriate PIDs for searching<br />
:* The Importer uses order details and local rules to determine which priors are potentially relevant (this profile focuses on specifying metadata availability to enable)<br />
:* The Importer retrieves matching prior images <'''MinUE out of scope''': and reports> executes import logic to map/fix codes and attribute values<br />
:* The Importer stores the imported priors to the local PACS <'''MinUE Out of Scope:''' and Report Manager><br />
:* The radiologist reads the study, accessing all priors using their usual workflow, display, hanging protocols, and image tools<br />
:* Post-interpretation rules (e.g. purging prior images and reports) occur locally<br />
<br />
The Profile supports a variety of image sharing architectures, e.g. centralized archiving for a region or IDN, federated PACS with point-to-point DIMSE access, etc.<br />
<br />
'''The intent is to make the existing, installed base of PACS systems work better without necessitating any changes or upgrades. The burden is centralized in the Importer and Report Converter actors rather than distributed to every sending or receiving system.'''<br />
<br />
<br />
'''Human Version of the Clinical Use Case'''<br />
<br />
Dr. Smith, a radiologist at a busy Cancer Center, is reporting a large number of CT studies which require comparison to previous imaging often performed at remote (but secure network connected) sites in the region, mostly community hospitals, but also academic centres where the patient may have been seen. The radiologist has to evaluate changes over time in order to assess treatment efficiency, with previous performed usually 3 to 6 months earlier. There may be a series of previous studies at the same interval over a period of a few years.<br />
<br />
Dr. Smith needs to report on a lesion’s change in size and appearance, as well as interval development or resolution of other conditions such as metastatic disease, peritoneal seeding or pleural effusions. For accuracy and speed, Dr Smith has to be able to cross-reference his CT slices and MPRs in DICOM format, using his own measurement tools.<br />
<br />
Dr. Smth wants the remote CT(s) to be readily available in his patient folder on his own PACS, and the studies displayed using his hanging protocols. He wants the report to be available the same way he displays previous reports for studies performed in his institution. <br />
<br />
'''The Problem Case Today'''<br />
<br />
Dr. Smith has to access a separate website, maybe with a separate sign-on. He has to search a separate database, he has to wait for images to load, slowing him down through his very busy work day. To make things worse, Dr. Smith has to open two separate web interfaces, one for the images, another one for the report, as the VNA was not be able to move the report with the images. <br />
<br />
Even though studies are all stored on a central VNA or there is access to other DICOM PACS systems, Dr. Smith has to ask the remote site to print a CD/DVD with the images. He then asks his PACS team to upload these images into his local PACS to make sure that images are available when he reports the current study. Not only is this a tedious manual process, but it delays the time the study is reported sometimes up to a few days. And, using the CD/DVD method, it is common that the previous report is not available.<br />
<br />
==4. Standards and Systems==<br />
<br />
'''Real World Systems:'''<br />
:* EMPI (IHE: PIX/PDQ Manager)<br />
:* RIS/EMRs (IHE: SWF.b DSS/OF, Report Manager, Report Reader)<br />
:* VNA or Diagnostic Imaging Repository (DI-r) (IHE: Image Manager, Report Manager, XDS.b Document Registry+ Document Repository+Imaging Document Source, possibly Importer and/or Report Converter)<br />
:* PACS (IHE: Image Manager/Archive, Image Display, Report Manager, Report Reader, possibly Importer and/or Report Converter)<br />
:* Note: the Importer and Report Converter actors may be separate systems, combined with a system above, or combined together - See Deployment options in Volume 1<br />
<br />
<br />
'''Standards:'''<br />
:* IRWF.b - useful importation logic and data mappings (but that IRWF.b is passive and doesn't specify pre and post steps)<br />
:* PIX/PDQ - patient identification<br />
:* MIMA Vol 2 Appendix J - fully qualified Patient ID reconciliation <br />
:* HL7 v2.x ORM/OMI (RAD-4 + IRWF.b data mappings ) - access to orders for new studies at the local site <br />
:* DICOM Q/R and XDS.b-I (RAD-5 and ITI-18) - find images <br />
:* DICOM C-Move and XDS.b-I (RAD-5 and ITI-18) - retrieve images <br />
:* DICOM C-Store - store images locally (default)<br />
:* '''MinUE Out of scope:''' Mobile Health Documents (MHD) -FHIR query documents<br />
:* '''MinUE Out of scope:''' XDS.b retrieve - report retrieval<br />
:* '''MinUE Out of scope:''' HL7 v2.x ORU (RD:RAD-128) - store report locally as TEXT or PDF<br />
<br />
A Cross Profile Consideration section X.6 discusses how DICOMweb services could be integrated in the future for image access and retrieval. Recommend limiting the required transactions on primary installed base (ie., HL7 v2.x, DICOM, XDS.b).<br />
<br />
==5. Discussion==<br />
<br />
The most important discussion is a consistently agreed upon, and not deviated from, definition of SCOPE:<br />
<br />
'''Minimum Useful Effort (MinUE) Baseline scope:''' Complete the current IDEP supplement, but do NOT include:<br />
:* Reports, in any format, not even TEXT or PDF<br />
:* WIA (DICOMweb) query to access prior images (except as reference in Cross Profile Considerations X.6)<br />
:* Retain Importer actor, but remove Report Converter actor and transactions<br />
:* Retain Image Purge and Report Purge as Named Options with no transactions (only defined behavior)<br />
:* Complete the IHE Public Comment and Trial Implementation processes <br />
:* (NOTE: removal of the Report Converter actor will be a SIGNIFICANT amount of effort for the editor and will include many changes to sections which have already been reviewed in detail by the TC).<br />
<br />
'''Maximum Useful Effort (MaxUE) (Additional) Scope for 2018-2019:'''<br />
:* Retain WIA (DICOMweb) query to access prior reports ONLY as reference in Cross Profile Considerations X.6 (no new DICOMweb functionality within IDEP)<br />
:* Only address TEXT and PDF report formats in direct scope in MaxUE<br />
:* Retain all other report formats as Volume 1 Informative Appendix and nothing more in MaxUE<br />
<br />
SEE [https://docs.google.com/spreadsheets/d/1IAKNiKwKHk3kFEs-mByfuvx91riorZv6El2GDjrZmAA/edit?usp=sharing THIS SUMMARY] FOR SPECIFIC STATUS OF EACH SECTION OF CURRENT SUPPLEMENT.<br />
<br />
This is intended to be a Workflow profile with one primary use case and one of two back-end architectures (all-DICOM and XDS.b (XDS.b as named option)): <br />
<br />
'''Workflow steps to be addressed:'''<br />
:* patient identification and PID reconciliation<br />
:* receipt of new orders<br />
:* relevancy logic meta data identification<br />
:* image retrieval <br />
:* DICOM attribute mapping <br />
:* storage of imported image <br />
:* '''MinUE Out of scope:''' report retrieval <br />
:* '''MinUE Out of scope:''' HL7 v2 ORU report attribute mapping <br />
:* '''MinUE Out of scope:'''storage of imported reports <br />
:* local purging of foreign images and foreign reports as defined Option<br />
<br />
<br />
'''Scope/assumptions:''' <br />
<br />
Goal is to enable automated and contextually integrated VIEWING of foreign radiology priors at the local system.<br />
<br />
:* Focus is on simplicity and existing installed base ("old school") - DICOM, HL7 v2.x, and XDS. (not image access using DICOM web services, or storage of reports using FHIR, etc)<br />
:* Secure network already in place between facilities. (Cross- non-affiliated enterprises out of scope.)<br />
:* EMPI (PIX/PDQ) already in place between facilities. <br />
:* Access prior imaging studies using DIMSE DICOM, but have XDS-I as a named Option. This XDS-I option would also include the hybrid DICOM/XDS.b environment since DICOM is the default environment.<br />
:* Storage of imaging study limited to DIMSE DICOM to the local PACS. (ie., not direct XDS import to the local PACS)<br />
:* Other image types such as Raw JPEG, PDF, etc., are out of scope.<br />
:* '''MinUE Out of scope:''' Report formats are limited to TEXT and PDF.<br />
:* '''MinUE Out of scope:''' Access of prior reports is limited to FHIR query for reports.<br />
:* '''MinUE Out of scope:''' Storage of prior reports is limited to HL7 v2.5.1 ORU with TEXT or PDF content.<br />
:* '''MinUE Out of scope:''' Report '''semantic content''' is always out of scope, i.e., structured or unstructured, etc. This could cause non-interoperability (unable to view), but is still out of scope and must be managed locally.<br />
<br />
==5. Technical Approach==<br />
<br />
:* Focus "intelligence" and mapping in new IDEP actors (Importer and Report Converter). Limit changes to ancillary systems.<br />
:* Populate <specific data element>, but stay away from terminology mapping.<br />
:* Default: Define meta data to be able to determine relevancy, but do not define relevancy rules. Server side v. client side filtering. (IDEP would specify client side filtering.)<br />
:* No intention to map procedure codes, study description, etc. Discuss in X.4 Concepts sections.<br />
:* Do not over-specify display requirements; e.g., "Required to display "something" to indicate that it is an external study."<br />
:* Retain WIA for remote image access via web services in Cross Profile Considerations (X.6); but do not explicitly include.<br />
<br />
<br />
===Existing actors===<br />
<br />
* "Local" DSS/OF<br />
* "Local" Image Manager<br />
* ''MinUE Out of scope: "' "Local" Report Manager<br />
* PIX/PDQ Manager<br />
* "Remote" Image Manager <br />
* '''MinUE Out of scope: "' Remote Report Manager <br />
* XDS.b Registry<br />
* '''MinUE Out of scope: "' XDS.b Repository<br />
* XDS.b-I Imaging Document Source<br />
<br />
===New actors===<br />
* Importer (same actor as IRWF.b, but additional behaviors)<br />
* Report Converter<br />
<br />
===Existing transactions===<br />
<br />
Because this proposed profiles focuses on improving the functionality of the existing installed base, it focuses on HL7 v2, DICOM DIMSE Services, and XDS.b transactions.<br />
<br />
See IDEP transaction diagram. (ie., many transactions)<br />
<br />
===New transactions (standards used)===<br />
<br />
A new DICOM query (DICOM query transaction proliferation) transaction was written for "Query for Patient Studies".<br />
New mapping tables were created for the (1) Order (OMI) message data for relevancy, (2) Coercion of MHD data for External Prior Reports, and (3) HL7 v2 ORU for External Prior Reports Mapping.<br />
<br />
===Impact on existing integration profiles===<br />
<br />
IOCM is "out of sync" with IDEP in terms of versions of standards used.<br />
IRWF.b and IDEP have overlap, but are not inconsistent and can peacefully co-exist for now.<br />
IDEP is consistent with current SWF.b profile, but it would be good if SWF.b were fully integrated as Final Text because it is hard to put all of the pieces together.<br />
<br />
===New integration profiles needed===<br />
<br />
None.<br />
<br />
===Breakdown of tasks===<br />
<br />
The high level breakdown of tasks is:<br />
<br />
: 1.) MinUE Baseline or MaxUE scope must be determined and uniformly (and indelibly) agreed to.<br />
: 2.) If MinUE baseline only, editor has a lot of work to do to remove all references to reports (40% of document)<br />
: 3.) Complete internal TC-review prior to Public Comment on un-reviewed sections; obtain vote to proceed to Public Comment.<br />
: 4.) Public comment period<br />
: 5.) Public comment review by TC and incorporation by Editor<br />
: 6.) Internal TC-review and changes by Editor; obtain vote to proceed to Trial Implementation.<br />
<br />
Just as a ballpark:<br />
-IDEP is currently ~80 pages<br />
-at the IHE Rad TC April F2F 52 pages were reviewed in detail, including all of the most difficult/controversial sections<br />
-at the IHE Rad TC Feb F2F 25 pages were discussed in detailed, but not reviewed, but much of this is informative and mapping tables<br />
<br />
The specific status of each section is listed in this document:<br />
https://docs.google.com/spreadsheets/d/1IAKNiKwKHk3kFEs-mByfuvx91riorZv6El2GDjrZmAA/edit?usp=sharing<br />
<br />
==6. Support & Resources==<br />
<br />
Canada Health Infoway has been very active in development of this technology and has implemented it across several broad regions, resulting in real-world data and analytics.<br />
<br />
HCA in the States has expressed in supporting and reviewing a standard to implement the import and display of external priors. HCA's focus is on the proper display of priors for side-by-side comparison in a most useful and effective manner.<br />
<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep to closely related clinical issues such as Emergency Department transfer<br />
:* Scope creep related to incorporating additional report formats beyond TEXT and PDF.<br />
:* Scope creep related to incorporating semantic meaning of reports.<br />
:* Scope creep related to additional methods of image and/or report access or image and/or report storage to local systems.<br />
:* Defining too much logic behind the word "relevant" - vendor/product differentiation; define only mechanisms<br />
:* Legal differences across jurisdictions<br />
<br />
==8. Open Issues==<br />
<br />
Scope creeped. Need to rein it back in, especially in the area of report formats. While report formats and transmission is undeniably a mess, the goal of the IDEP profile was never to fix report interoperability, but rather to access at least some of the prior reports. Complete report interoperability should be its own profile.<br />
<br />
May even want to consider not including informative appendices in Volume 1 on additional report formats, even if it is a critical gap in products today.<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
* % for Maximum/Full Effort = imaging and reports (ONLY report access via FHIR and storage via HL7 ORU TEXT and PDF)<br />
* % for Minimum Useful Effort<br />
:* 1.) Focus strictly on external prior IMAGE access, coercion, and storage<br />
:* 2.) No reports, not even as HL7 ORU TEXT or PDF, possibly mention Reports in X.4 Concepts section - see bolded "MinUE Out of scope" notes<br />
<br />
Candidate Editor:<br />
:* Jonathan Whitby/Vital, with Teri Sippel Schmidt consulting for historical purposes</div>Terisippelhttp://wiki.ihe.net/index.php?title=Import_and_Display_of_External_Priors-_Proposal&diff=110600Import and Display of External Priors- Proposal2018-07-24T23:48:54Z<p>Terisippel: /* Breakdown of tasks */</p>
<hr />
<div>{{TOCright}}<br />
==1. Proposed Workitem: Import and Display of External Priors (IDEP)==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt<br />
* Proposal Contributors: David Koff, MD; Canada Health Infoway; Kevin O'Donnell<br />
* Editor: Jonathan Whitby (previously Teri Sippel Schmidt)<br />
* Contributors: David Koff, MD; Canada Health Infoway<br />
* Domain: Radiology<br />
<br />
This proposal was previously called "[[Foreign_Exam_Management_Direct_Import-_Proposal|Foreign Exam Management (FEM)]]".<br />
<br />
==2. The Problem==<br />
<br />
Prior imaging studies provide vital information and context to the radiologist when interpreting a current study, even resulting in a change of diagnosis. A "prefetch" step (to locate prior studies for the patient that may be relevant and make them immediately accessible to the radiologist during review) is common in imaging workflows. This works fairly well for priors that were performed locally, even if they have to be pulled back from longer term storage to be ready for the radiologist. <br />
<br />
Unfortunately, with the mobility of modern healthcare, '''it is very common for priors to be located outside the reading institution'''.<br />
<br />
Although there have been many improvements to the ability to exchange images between enterprises, or between departments within an enterprise, '''the ability to locate, access, and view priors for direct comparison, particularly during the short time frame required for them to be relevant to reading, is still not reliable'''.<br />
* patient portals - are unwieldy, slow to access, and on different monitors<br />
* web-based viewers - are not integrated into the diagnostic workstation so they '''don't permit side-by side image comparison and use of local hanging protocols''' or viewing tools<br />
* CD/DVD imports/viewers - are often not timely, sometimes do not import reliably, and are "reactive not proactive"<br />
* all suffer from issues with different Patient IDs, procedure codes, etc, questions of long term storage, and some mappings not addressed in IRWF.b. <br />
* radiology reports - there is no primary standard for radiology reports, and as a result, report formats vary dramatically effectively eliminating interoperability of report sharing<br />
<br />
<br />
A solution for this priors problem has been demonstrated to '''also reduce re-scanned patients''' (with cost and radiation implications) due to poor access to studies performed at other institutions.<br />
(Ref: Nagels, J., Macdonald, D. & Coz, C. J Digit Imaging (2017). https://doi.org/10.1007/s10278-017-9963-8)<br />
<br />
==3. Key Use Case==<br />
<br />
'''Order-driven priors:'''<br />
<br />
:* A physician orders a radiology study for a patient<br />
:* The Importer actor searches for prior images <'''MinUE out of scope:''' and reports> for that patient, both locally and beyond<br />
::* The Importer uses PIX/PDQ to get appropriate PIDs for searching<br />
:* The Importer uses order details and local rules to determine which priors are potentially relevant (this profile focuses on specifying metadata availability to enable)<br />
:* The Importer retrieves matching prior images <'''MinUE out of scope''': and reports> executes import logic to map/fix codes and attribute values<br />
:* The Importer stores the imported priors to the local PACS <'''MinUE Out of Scope:''' and Report Manager><br />
:* The radiologist reads the study, accessing all priors using their usual workflow, display, hanging protocols, and image tools<br />
:* Post-interpretation rules (e.g. purging prior images and reports) occur locally<br />
<br />
The Profile supports a variety of image sharing architectures, e.g. centralized archiving for a region or IDN, federated PACS with point-to-point DIMSE access, etc.<br />
<br />
'''The intent is to make the existing, installed base of PACS systems work better without necessitating any changes or upgrades. The burden is centralized in the Importer and Report Converter actors rather than distributed to every sending or receiving system.'''<br />
<br />
<br />
'''Human Version of the Clinical Use Case'''<br />
<br />
Dr. Smith, a radiologist at a busy Cancer Center, is reporting a large number of CT studies which require comparison to previous imaging often performed at remote (but secure network connected) sites in the region, mostly community hospitals, but also academic centres where the patient may have been seen. The radiologist has to evaluate changes over time in order to assess treatment efficiency, with previous performed usually 3 to 6 months earlier. There may be a series of previous studies at the same interval over a period of a few years.<br />
<br />
Dr. Smith needs to report on a lesion’s change in size and appearance, as well as interval development or resolution of other conditions such as metastatic disease, peritoneal seeding or pleural effusions. For accuracy and speed, Dr Smith has to be able to cross-reference his CT slices and MPRs in DICOM format, using his own measurement tools.<br />
<br />
Dr. Smth wants the remote CT(s) to be readily available in his patient folder on his own PACS, and the studies displayed using his hanging protocols. He wants the report to be available the same way he displays previous reports for studies performed in his institution. <br />
<br />
'''The Problem Case Today'''<br />
<br />
Dr. Smith has to access a separate website, maybe with a separate sign-on. He has to search a separate database, he has to wait for images to load, slowing him down through his very busy work day. To make things worse, Dr. Smith has to open two separate web interfaces, one for the images, another one for the report, as the VNA was not be able to move the report with the images. <br />
<br />
Even though studies are all stored on a central VNA or there is access to other DICOM PACS systems, Dr. Smith has to ask the remote site to print a CD/DVD with the images. He then asks his PACS team to upload these images into his local PACS to make sure that images are available when he reports the current study. Not only is this a tedious manual process, but it delays the time the study is reported sometimes up to a few days. And, using the CD/DVD method, it is common that the previous report is not available.<br />
<br />
==4. Standards and Systems==<br />
<br />
'''Real World Systems:'''<br />
:* EMPI (IHE: PIX/PDQ Manager)<br />
:* RIS/EMRs (IHE: SWF.b DSS/OF, Report Manager, Report Reader)<br />
:* VNA or Diagnostic Imaging Repository (DI-r) (IHE: Image Manager, Report Manager, XDS.b Document Registry+ Document Repository+Imaging Document Source, possibly Importer and/or Report Converter)<br />
:* PACS (IHE: Image Manager/Archive, Image Display, Report Manager, Report Reader, possibly Importer and/or Report Converter)<br />
:* Note: the Importer and Report Converter actors may be separate systems, combined with a system above, or combined together - See Deployment options in Volume 1<br />
<br />
<br />
'''Standards:'''<br />
:* IRWF.b - useful importation logic and data mappings (but that IRWF.b is passive and doesn't specify pre and post steps)<br />
:* PIX/PDQ - patient identification<br />
:* MIMA Vol 2 Appendix J - fully qualified Patient ID reconciliation <br />
:* HL7 v2.x ORM/OMI (RAD-4 + IRWF.b data mappings ) - access to orders for new studies at the local site <br />
:* DICOM Q/R and XDS.b-I (RAD-5 and ITI-18) - find images <br />
:* DICOM C-Move and XDS.b-I (RAD-5 and ITI-18) - retrieve images <br />
:* DICOM C-Store - store images locally (default)<br />
:* '''MinUE Out of scope:''' Mobile Health Documents (MHD) -FHIR query documents<br />
:* '''MinUE Out of scope:''' XDS.b retrieve - report retrieval<br />
:* '''MinUE Out of scope:''' HL7 v2.x ORU (RD:RAD-128) - store report locally as TEXT or PDF<br />
<br />
A Cross Profile Consideration section X.6 discusses how DICOMweb services could be integrated in the future for image access and retrieval. Recommend limiting the required transactions on primary installed base (ie., HL7 v2.x, DICOM, XDS.b).<br />
<br />
==5. Discussion==<br />
<br />
The most important discussion is a consistently agreed upon, and not deviated from, definition of SCOPE:<br />
<br />
'''Minimum Useful Effort (MinUE) Baseline scope:''' Complete the current IDEP supplement, but do NOT include:<br />
:* Reports, in any format, not even TEXT or PDF<br />
:* WIA (DICOMweb) query to access prior images (except as reference in Cross Profile Considerations X.6)<br />
:* Retain Importer actor, but remove Report Converter actor and transactions<br />
:* Retain Image Purge and Report Purge as Named Options with no transactions (only defined behavior)<br />
:* Complete the IHE Public Comment and Trial Implementation processes <br />
:* (NOTE: removal of the Report Converter actor will be a SIGNIFICANT amount of effort for the editor and will include many changes to sections which have already been reviewed in detail by the TC).<br />
<br />
'''Maximum Useful Effort (MaxUE) (Additional) Scope for 2018-2019:'''<br />
:* Retain WIA (DICOMweb) query to access prior reports ONLY as reference in Cross Profile Considerations X.6 (no new DICOMweb functionality within IDEP)<br />
:* Only address TEXT and PDF report formats in direct scope in MaxUE<br />
:* Retain all other report formats as Volume 1 Informative Appendix and nothing more in MaxUE<br />
<br />
SEE [https://docs.google.com/spreadsheets/d/1IAKNiKwKHk3kFEs-mByfuvx91riorZv6El2GDjrZmAA/edit?usp=sharing THIS SUMMARY] FOR SPECIFIC STATUS OF EACH SECTION OF CURRENT SUPPLEMENT.<br />
<br />
This is intended to be a Workflow profile with one primary use case and one of two back-end architectures (all-DICOM and XDS.b (XDS.b as named option)): <br />
<br />
'''Workflow steps to be addressed:'''<br />
:* patient identification and PID reconciliation<br />
:* receipt of new orders<br />
:* relevancy logic meta data identification<br />
:* image retrieval <br />
:* DICOM attribute mapping <br />
:* storage of imported image <br />
:* '''MinUE Out of scope:''' report retrieval <br />
:* '''MinUE Out of scope:''' HL7 v2 ORU report attribute mapping <br />
:* '''MinUE Out of scope:'''storage of imported reports <br />
:* local purging of foreign images and foreign reports as defined Option<br />
<br />
<br />
'''Scope/assumptions:''' <br />
<br />
Goal is to enable automated and contextually integrated VIEWING of foreign radiology priors at the local system.<br />
<br />
:* Focus is on simplicity and existing installed base ("old school") - DICOM, HL7 v2.x, and XDS. (not image access using DICOM web services, or storage of reports using FHIR, etc)<br />
:* Secure network already in place between facilities. (Cross- non-affiliated enterprises out of scope.)<br />
:* EMPI (PIX/PDQ) already in place between facilities. <br />
:* Access prior imaging studies using DIMSE DICOM, but have XDS-I as a named Option. This XDS-I option would also include the hybrid DICOM/XDS.b environment since DICOM is the default environment.<br />
:* Storage of imaging study limited to DIMSE DICOM to the local PACS. (ie., not direct XDS import to the local PACS)<br />
:* Other image types such as Raw JPEG, PDF, etc., are out of scope.<br />
:* '''MinUE Out of scope:''' Report formats are limited to TEXT and PDF.<br />
:* '''MinUE Out of scope:''' Access of prior reports is limited to FHIR query for reports.<br />
:* '''MinUE Out of scope:''' Storage of prior reports is limited to HL7 v2.5.1 ORU with TEXT or PDF content.<br />
:* '''MinUE Out of scope:''' Report '''semantic content''' is always out of scope, i.e., structured or unstructured, etc. This could cause non-interoperability (unable to view), but is still out of scope and must be managed locally.<br />
<br />
==5. Technical Approach==<br />
<br />
:* Focus "intelligence" and mapping in new IDEP actors (Importer and Report Converter). Limit changes to ancillary systems.<br />
:* Populate <specific data element>, but stay away from terminology mapping.<br />
:* Default: Define meta data to be able to determine relevancy, but do not define relevancy rules. Server side v. client side filtering. (IDEP would specify client side filtering.)<br />
:* No intention to map procedure codes, study description, etc. Discuss in X.4 Concepts sections.<br />
:* Do not over-specify display requirements; e.g., "Required to display "something" to indicate that it is an external study."<br />
:* Retain WIA for remote image access via web services in Cross Profile Considerations (X.6); but do not explicitly include.<br />
<br />
<br />
===Existing actors===<br />
<br />
* "Local" DSS/OF<br />
* "Local" Image Manager<br />
* ''MinUE Out of scope: "' "Local" Report Manager<br />
* PIX/PDQ Manager<br />
* "Remote" Image Manager <br />
* '''MinUE Out of scope: "' "Remote" Report Manager <br />
* XDS.b Registry<br />
* '''MinUE Out of scope: "' XDS.b Repository<br />
* XDS.b-I Imaging Document Source<br />
<br />
===New actors===<br />
* Importer (same actor as IRWF.b, but additional behaviors)<br />
* Report Converter<br />
<br />
===Existing transactions===<br />
<br />
Because this proposed profiles focuses on improving the functionality of the existing installed base, it focuses on HL7 v2, DICOM DIMSE Services, and XDS.b transactions.<br />
<br />
See IDEP transaction diagram. (ie., many transactions)<br />
<br />
===New transactions (standards used)===<br />
<br />
A new DICOM query (DICOM query transaction proliferation) transaction was written for "Query for Patient Studies".<br />
New mapping tables were created for the (1) Order (OMI) message data for relevancy, (2) Coercion of MHD data for External Prior Reports, and (3) HL7 v2 ORU for External Prior Reports Mapping.<br />
<br />
===Impact on existing integration profiles===<br />
<br />
IOCM is "out of sync" with IDEP in terms of versions of standards used.<br />
IRWF.b and IDEP have overlap, but are not inconsistent and can peacefully co-exist for now.<br />
IDEP is consistent with current SWF.b profile, but it would be good if SWF.b were fully integrated as Final Text because it is hard to put all of the pieces together.<br />
<br />
===New integration profiles needed===<br />
<br />
None.<br />
<br />
===Breakdown of tasks===<br />
<br />
The high level breakdown of tasks is:<br />
<br />
: 1.) MinUE Baseline or MaxUE scope must be determined and uniformly (and indelibly) agreed to.<br />
: 2.) If MinUE baseline only, editor has a lot of work to do to remove all references to reports (40% of document)<br />
: 3.) Complete internal TC-review prior to Public Comment on un-reviewed sections; obtain vote to proceed to Public Comment.<br />
: 4.) Public comment period<br />
: 5.) Public comment review by TC and incorporation by Editor<br />
: 6.) Internal TC-review and changes by Editor; obtain vote to proceed to Trial Implementation.<br />
<br />
Just as a ballpark:<br />
-IDEP is currently ~80 pages<br />
-at the IHE Rad TC April F2F 52 pages were reviewed in detail, including all of the most difficult/controversial sections<br />
-at the IHE Rad TC Feb F2F 25 pages were discussed in detailed, but not reviewed, but much of this is informative and mapping tables<br />
<br />
The specific status of each section is listed in this document:<br />
https://docs.google.com/spreadsheets/d/1IAKNiKwKHk3kFEs-mByfuvx91riorZv6El2GDjrZmAA/edit?usp=sharing<br />
<br />
==6. Support & Resources==<br />
<br />
Canada Health Infoway has been very active in development of this technology and has implemented it across several broad regions, resulting in real-world data and analytics.<br />
<br />
HCA in the States has expressed in supporting and reviewing a standard to implement the import and display of external priors. HCA's focus is on the proper display of priors for side-by-side comparison in a most useful and effective manner.<br />
<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep to closely related clinical issues such as Emergency Department transfer<br />
:* Scope creep related to incorporating additional report formats beyond TEXT and PDF.<br />
:* Scope creep related to incorporating semantic meaning of reports.<br />
:* Scope creep related to additional methods of image and/or report access or image and/or report storage to local systems.<br />
:* Defining too much logic behind the word "relevant" - vendor/product differentiation; define only mechanisms<br />
:* Legal differences across jurisdictions<br />
<br />
==8. Open Issues==<br />
<br />
Scope creeped. Need to rein it back in, especially in the area of report formats. While report formats and transmission is undeniably a mess, the goal of the IDEP profile was never to fix report interoperability, but rather to access at least some of the prior reports. Complete report interoperability should be its own profile.<br />
<br />
May even want to consider not including informative appendices in Volume 1 on additional report formats, even if it is a critical gap in products today.<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
* % for Maximum/Full Effort = imaging and reports (ONLY report access via FHIR and storage via HL7 ORU TEXT and PDF)<br />
* % for Minimum Useful Effort<br />
:* 1.) Focus strictly on external prior IMAGE access, coercion, and storage<br />
:* 2.) No reports, not even as HL7 ORU TEXT or PDF, possibly mention Reports in X.4 Concepts section - see bolded "MinUE Out of scope" notes<br />
<br />
Candidate Editor:<br />
:* Jonathan Whitby/Vital, with Teri Sippel Schmidt consulting for historical purposes</div>Terisippelhttp://wiki.ihe.net/index.php?title=Import_and_Display_of_External_Priors-_Proposal&diff=110599Import and Display of External Priors- Proposal2018-07-24T23:45:59Z<p>Terisippel: /* 9. Tech Cmte Evaluation */</p>
<hr />
<div>{{TOCright}}<br />
==1. Proposed Workitem: Import and Display of External Priors (IDEP)==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt<br />
* Proposal Contributors: David Koff, MD; Canada Health Infoway; Kevin O'Donnell<br />
* Editor: Jonathan Whitby (previously Teri Sippel Schmidt)<br />
* Contributors: David Koff, MD; Canada Health Infoway<br />
* Domain: Radiology<br />
<br />
This proposal was previously called "[[Foreign_Exam_Management_Direct_Import-_Proposal|Foreign Exam Management (FEM)]]".<br />
<br />
==2. The Problem==<br />
<br />
Prior imaging studies provide vital information and context to the radiologist when interpreting a current study, even resulting in a change of diagnosis. A "prefetch" step (to locate prior studies for the patient that may be relevant and make them immediately accessible to the radiologist during review) is common in imaging workflows. This works fairly well for priors that were performed locally, even if they have to be pulled back from longer term storage to be ready for the radiologist. <br />
<br />
Unfortunately, with the mobility of modern healthcare, '''it is very common for priors to be located outside the reading institution'''.<br />
<br />
Although there have been many improvements to the ability to exchange images between enterprises, or between departments within an enterprise, '''the ability to locate, access, and view priors for direct comparison, particularly during the short time frame required for them to be relevant to reading, is still not reliable'''.<br />
* patient portals - are unwieldy, slow to access, and on different monitors<br />
* web-based viewers - are not integrated into the diagnostic workstation so they '''don't permit side-by side image comparison and use of local hanging protocols''' or viewing tools<br />
* CD/DVD imports/viewers - are often not timely, sometimes do not import reliably, and are "reactive not proactive"<br />
* all suffer from issues with different Patient IDs, procedure codes, etc, questions of long term storage, and some mappings not addressed in IRWF.b. <br />
* radiology reports - there is no primary standard for radiology reports, and as a result, report formats vary dramatically effectively eliminating interoperability of report sharing<br />
<br />
<br />
A solution for this priors problem has been demonstrated to '''also reduce re-scanned patients''' (with cost and radiation implications) due to poor access to studies performed at other institutions.<br />
(Ref: Nagels, J., Macdonald, D. & Coz, C. J Digit Imaging (2017). https://doi.org/10.1007/s10278-017-9963-8)<br />
<br />
==3. Key Use Case==<br />
<br />
'''Order-driven priors:'''<br />
<br />
:* A physician orders a radiology study for a patient<br />
:* The Importer actor searches for prior images <'''MinUE out of scope:''' and reports> for that patient, both locally and beyond<br />
::* The Importer uses PIX/PDQ to get appropriate PIDs for searching<br />
:* The Importer uses order details and local rules to determine which priors are potentially relevant (this profile focuses on specifying metadata availability to enable)<br />
:* The Importer retrieves matching prior images <'''MinUE out of scope''': and reports> executes import logic to map/fix codes and attribute values<br />
:* The Importer stores the imported priors to the local PACS <'''MinUE Out of Scope:''' and Report Manager><br />
:* The radiologist reads the study, accessing all priors using their usual workflow, display, hanging protocols, and image tools<br />
:* Post-interpretation rules (e.g. purging prior images and reports) occur locally<br />
<br />
The Profile supports a variety of image sharing architectures, e.g. centralized archiving for a region or IDN, federated PACS with point-to-point DIMSE access, etc.<br />
<br />
'''The intent is to make the existing, installed base of PACS systems work better without necessitating any changes or upgrades. The burden is centralized in the Importer and Report Converter actors rather than distributed to every sending or receiving system.'''<br />
<br />
<br />
'''Human Version of the Clinical Use Case'''<br />
<br />
Dr. Smith, a radiologist at a busy Cancer Center, is reporting a large number of CT studies which require comparison to previous imaging often performed at remote (but secure network connected) sites in the region, mostly community hospitals, but also academic centres where the patient may have been seen. The radiologist has to evaluate changes over time in order to assess treatment efficiency, with previous performed usually 3 to 6 months earlier. There may be a series of previous studies at the same interval over a period of a few years.<br />
<br />
Dr. Smith needs to report on a lesion’s change in size and appearance, as well as interval development or resolution of other conditions such as metastatic disease, peritoneal seeding or pleural effusions. For accuracy and speed, Dr Smith has to be able to cross-reference his CT slices and MPRs in DICOM format, using his own measurement tools.<br />
<br />
Dr. Smth wants the remote CT(s) to be readily available in his patient folder on his own PACS, and the studies displayed using his hanging protocols. He wants the report to be available the same way he displays previous reports for studies performed in his institution. <br />
<br />
'''The Problem Case Today'''<br />
<br />
Dr. Smith has to access a separate website, maybe with a separate sign-on. He has to search a separate database, he has to wait for images to load, slowing him down through his very busy work day. To make things worse, Dr. Smith has to open two separate web interfaces, one for the images, another one for the report, as the VNA was not be able to move the report with the images. <br />
<br />
Even though studies are all stored on a central VNA or there is access to other DICOM PACS systems, Dr. Smith has to ask the remote site to print a CD/DVD with the images. He then asks his PACS team to upload these images into his local PACS to make sure that images are available when he reports the current study. Not only is this a tedious manual process, but it delays the time the study is reported sometimes up to a few days. And, using the CD/DVD method, it is common that the previous report is not available.<br />
<br />
==4. Standards and Systems==<br />
<br />
'''Real World Systems:'''<br />
:* EMPI (IHE: PIX/PDQ Manager)<br />
:* RIS/EMRs (IHE: SWF.b DSS/OF, Report Manager, Report Reader)<br />
:* VNA or Diagnostic Imaging Repository (DI-r) (IHE: Image Manager, Report Manager, XDS.b Document Registry+ Document Repository+Imaging Document Source, possibly Importer and/or Report Converter)<br />
:* PACS (IHE: Image Manager/Archive, Image Display, Report Manager, Report Reader, possibly Importer and/or Report Converter)<br />
:* Note: the Importer and Report Converter actors may be separate systems, combined with a system above, or combined together - See Deployment options in Volume 1<br />
<br />
<br />
'''Standards:'''<br />
:* IRWF.b - useful importation logic and data mappings (but that IRWF.b is passive and doesn't specify pre and post steps)<br />
:* PIX/PDQ - patient identification<br />
:* MIMA Vol 2 Appendix J - fully qualified Patient ID reconciliation <br />
:* HL7 v2.x ORM/OMI (RAD-4 + IRWF.b data mappings ) - access to orders for new studies at the local site <br />
:* DICOM Q/R and XDS.b-I (RAD-5 and ITI-18) - find images <br />
:* DICOM C-Move and XDS.b-I (RAD-5 and ITI-18) - retrieve images <br />
:* DICOM C-Store - store images locally (default)<br />
:* '''MinUE Out of scope:''' Mobile Health Documents (MHD) -FHIR query documents<br />
:* '''MinUE Out of scope:''' XDS.b retrieve - report retrieval<br />
:* '''MinUE Out of scope:''' HL7 v2.x ORU (RD:RAD-128) - store report locally as TEXT or PDF<br />
<br />
A Cross Profile Consideration section X.6 discusses how DICOMweb services could be integrated in the future for image access and retrieval. Recommend limiting the required transactions on primary installed base (ie., HL7 v2.x, DICOM, XDS.b).<br />
<br />
==5. Discussion==<br />
<br />
The most important discussion is a consistently agreed upon, and not deviated from, definition of SCOPE:<br />
<br />
'''Minimum Useful Effort (MinUE) Baseline scope:''' Complete the current IDEP supplement, but do NOT include:<br />
:* Reports, in any format, not even TEXT or PDF<br />
:* WIA (DICOMweb) query to access prior images (except as reference in Cross Profile Considerations X.6)<br />
:* Retain Importer actor, but remove Report Converter actor and transactions<br />
:* Retain Image Purge and Report Purge as Named Options with no transactions (only defined behavior)<br />
:* Complete the IHE Public Comment and Trial Implementation processes <br />
:* (NOTE: removal of the Report Converter actor will be a SIGNIFICANT amount of effort for the editor and will include many changes to sections which have already been reviewed in detail by the TC).<br />
<br />
'''Maximum Useful Effort (MaxUE) (Additional) Scope for 2018-2019:'''<br />
:* Retain WIA (DICOMweb) query to access prior reports ONLY as reference in Cross Profile Considerations X.6 (no new DICOMweb functionality within IDEP)<br />
:* Only address TEXT and PDF report formats in direct scope in MaxUE<br />
:* Retain all other report formats as Volume 1 Informative Appendix and nothing more in MaxUE<br />
<br />
SEE [https://docs.google.com/spreadsheets/d/1IAKNiKwKHk3kFEs-mByfuvx91riorZv6El2GDjrZmAA/edit?usp=sharing THIS SUMMARY] FOR SPECIFIC STATUS OF EACH SECTION OF CURRENT SUPPLEMENT.<br />
<br />
This is intended to be a Workflow profile with one primary use case and one of two back-end architectures (all-DICOM and XDS.b (XDS.b as named option)): <br />
<br />
'''Workflow steps to be addressed:'''<br />
:* patient identification and PID reconciliation<br />
:* receipt of new orders<br />
:* relevancy logic meta data identification<br />
:* image retrieval <br />
:* DICOM attribute mapping <br />
:* storage of imported image <br />
:* '''MinUE Out of scope:''' report retrieval <br />
:* '''MinUE Out of scope:''' HL7 v2 ORU report attribute mapping <br />
:* '''MinUE Out of scope:'''storage of imported reports <br />
:* local purging of foreign images and foreign reports as defined Option<br />
<br />
<br />
'''Scope/assumptions:''' <br />
<br />
Goal is to enable automated and contextually integrated VIEWING of foreign radiology priors at the local system.<br />
<br />
:* Focus is on simplicity and existing installed base ("old school") - DICOM, HL7 v2.x, and XDS. (not image access using DICOM web services, or storage of reports using FHIR, etc)<br />
:* Secure network already in place between facilities. (Cross- non-affiliated enterprises out of scope.)<br />
:* EMPI (PIX/PDQ) already in place between facilities. <br />
:* Access prior imaging studies using DIMSE DICOM, but have XDS-I as a named Option. This XDS-I option would also include the hybrid DICOM/XDS.b environment since DICOM is the default environment.<br />
:* Storage of imaging study limited to DIMSE DICOM to the local PACS. (ie., not direct XDS import to the local PACS)<br />
:* Other image types such as Raw JPEG, PDF, etc., are out of scope.<br />
:* '''MinUE Out of scope:''' Report formats are limited to TEXT and PDF.<br />
:* '''MinUE Out of scope:''' Access of prior reports is limited to FHIR query for reports.<br />
:* '''MinUE Out of scope:''' Storage of prior reports is limited to HL7 v2.5.1 ORU with TEXT or PDF content.<br />
:* '''MinUE Out of scope:''' Report '''semantic content''' is always out of scope, i.e., structured or unstructured, etc. This could cause non-interoperability (unable to view), but is still out of scope and must be managed locally.<br />
<br />
==5. Technical Approach==<br />
<br />
:* Focus "intelligence" and mapping in new IDEP actors (Importer and Report Converter). Limit changes to ancillary systems.<br />
:* Populate <specific data element>, but stay away from terminology mapping.<br />
:* Default: Define meta data to be able to determine relevancy, but do not define relevancy rules. Server side v. client side filtering. (IDEP would specify client side filtering.)<br />
:* No intention to map procedure codes, study description, etc. Discuss in X.4 Concepts sections.<br />
:* Do not over-specify display requirements; e.g., "Required to display "something" to indicate that it is an external study."<br />
:* Retain WIA for remote image access via web services in Cross Profile Considerations (X.6); but do not explicitly include.<br />
<br />
<br />
===Existing actors===<br />
<br />
* "Local" DSS/OF<br />
* "Local" Image Manager<br />
* ''MinUE Out of scope: "' "Local" Report Manager<br />
* PIX/PDQ Manager<br />
* "Remote" Image Manager <br />
* '''MinUE Out of scope: "' "Remote" Report Manager <br />
* XDS.b Registry<br />
* '''MinUE Out of scope: "' XDS.b Repository<br />
* XDS.b-I Imaging Document Source<br />
<br />
===New actors===<br />
* Importer (same actor as IRWF.b, but additional behaviors)<br />
* Report Converter<br />
<br />
===Existing transactions===<br />
<br />
Because this proposed profiles focuses on improving the functionality of the existing installed base, it focuses on HL7 v2, DICOM DIMSE Services, and XDS.b transactions.<br />
<br />
See IDEP transaction diagram. (ie., many transactions)<br />
<br />
===New transactions (standards used)===<br />
<br />
A new DICOM query (DICOM query transaction proliferation) transaction was written for "Query for Patient Studies".<br />
New mapping tables were created for the (1) Order (OMI) message data for relevancy, (2) Coercion of MHD data for External Prior Reports, and (3) HL7 v2 ORU for External Prior Reports Mapping.<br />
<br />
===Impact on existing integration profiles===<br />
<br />
IOCM is "out of sync" with IDEP in terms of versions of standards used.<br />
IRWF.b and IDEP have overlap, but are not inconsistent and can peacefully co-exist for now.<br />
IDEP is consistent with current SWF.b profile, but it would be good if SWF.b were fully integrated as Final Text because it is hard to put all of the pieces together.<br />
<br />
===New integration profiles needed===<br />
<br />
None.<br />
<br />
===Breakdown of tasks===<br />
<br />
The high level breakdown of tasks is:<br />
<br />
: 1.) MinUE Baseline or MaxUE scope must be determined and uniformly (and indelibly) agreed to.<br />
: 2.) If MinUE baseline only, editor has a lot of work to do to remove all references to reports (40% of document)<br />
: 3.) Complete internal TC-review prior to Public Comment on un-reviewed sections; obtain vote to proceed to Public Comment.<br />
: 4.) Public comment period<br />
: 5.) Public comment review by TC and incorporation by Editor<br />
: 6.) Internal TC-review and changes by Editor; obtain vote to proceed to Trial Implementation.<br />
<br />
<br />
The specific status of each section is listed in this document:<br />
<br />
==6. Support & Resources==<br />
<br />
Canada Health Infoway has been very active in development of this technology and has implemented it across several broad regions, resulting in real-world data and analytics.<br />
<br />
HCA in the States has expressed in supporting and reviewing a standard to implement the import and display of external priors. HCA's focus is on the proper display of priors for side-by-side comparison in a most useful and effective manner.<br />
<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep to closely related clinical issues such as Emergency Department transfer<br />
:* Scope creep related to incorporating additional report formats beyond TEXT and PDF.<br />
:* Scope creep related to incorporating semantic meaning of reports.<br />
:* Scope creep related to additional methods of image and/or report access or image and/or report storage to local systems.<br />
:* Defining too much logic behind the word "relevant" - vendor/product differentiation; define only mechanisms<br />
:* Legal differences across jurisdictions<br />
<br />
==8. Open Issues==<br />
<br />
Scope creeped. Need to rein it back in, especially in the area of report formats. While report formats and transmission is undeniably a mess, the goal of the IDEP profile was never to fix report interoperability, but rather to access at least some of the prior reports. Complete report interoperability should be its own profile.<br />
<br />
May even want to consider not including informative appendices in Volume 1 on additional report formats, even if it is a critical gap in products today.<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
* % for Maximum/Full Effort = imaging and reports (ONLY report access via FHIR and storage via HL7 ORU TEXT and PDF)<br />
* % for Minimum Useful Effort<br />
:* 1.) Focus strictly on external prior IMAGE access, coercion, and storage<br />
:* 2.) No reports, not even as HL7 ORU TEXT or PDF, possibly mention Reports in X.4 Concepts section - see bolded "MinUE Out of scope" notes<br />
<br />
Candidate Editor:<br />
:* Jonathan Whitby/Vital, with Teri Sippel Schmidt consulting for historical purposes</div>Terisippelhttp://wiki.ihe.net/index.php?title=Import_and_Display_of_External_Priors-_Proposal&diff=110598Import and Display of External Priors- Proposal2018-07-24T23:45:34Z<p>Terisippel: /* 8. Open Issues */</p>
<hr />
<div>{{TOCright}}<br />
==1. Proposed Workitem: Import and Display of External Priors (IDEP)==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt<br />
* Proposal Contributors: David Koff, MD; Canada Health Infoway; Kevin O'Donnell<br />
* Editor: Jonathan Whitby (previously Teri Sippel Schmidt)<br />
* Contributors: David Koff, MD; Canada Health Infoway<br />
* Domain: Radiology<br />
<br />
This proposal was previously called "[[Foreign_Exam_Management_Direct_Import-_Proposal|Foreign Exam Management (FEM)]]".<br />
<br />
==2. The Problem==<br />
<br />
Prior imaging studies provide vital information and context to the radiologist when interpreting a current study, even resulting in a change of diagnosis. A "prefetch" step (to locate prior studies for the patient that may be relevant and make them immediately accessible to the radiologist during review) is common in imaging workflows. This works fairly well for priors that were performed locally, even if they have to be pulled back from longer term storage to be ready for the radiologist. <br />
<br />
Unfortunately, with the mobility of modern healthcare, '''it is very common for priors to be located outside the reading institution'''.<br />
<br />
Although there have been many improvements to the ability to exchange images between enterprises, or between departments within an enterprise, '''the ability to locate, access, and view priors for direct comparison, particularly during the short time frame required for them to be relevant to reading, is still not reliable'''.<br />
* patient portals - are unwieldy, slow to access, and on different monitors<br />
* web-based viewers - are not integrated into the diagnostic workstation so they '''don't permit side-by side image comparison and use of local hanging protocols''' or viewing tools<br />
* CD/DVD imports/viewers - are often not timely, sometimes do not import reliably, and are "reactive not proactive"<br />
* all suffer from issues with different Patient IDs, procedure codes, etc, questions of long term storage, and some mappings not addressed in IRWF.b. <br />
* radiology reports - there is no primary standard for radiology reports, and as a result, report formats vary dramatically effectively eliminating interoperability of report sharing<br />
<br />
<br />
A solution for this priors problem has been demonstrated to '''also reduce re-scanned patients''' (with cost and radiation implications) due to poor access to studies performed at other institutions.<br />
(Ref: Nagels, J., Macdonald, D. & Coz, C. J Digit Imaging (2017). https://doi.org/10.1007/s10278-017-9963-8)<br />
<br />
==3. Key Use Case==<br />
<br />
'''Order-driven priors:'''<br />
<br />
:* A physician orders a radiology study for a patient<br />
:* The Importer actor searches for prior images <'''MinUE out of scope:''' and reports> for that patient, both locally and beyond<br />
::* The Importer uses PIX/PDQ to get appropriate PIDs for searching<br />
:* The Importer uses order details and local rules to determine which priors are potentially relevant (this profile focuses on specifying metadata availability to enable)<br />
:* The Importer retrieves matching prior images <'''MinUE out of scope''': and reports> executes import logic to map/fix codes and attribute values<br />
:* The Importer stores the imported priors to the local PACS <'''MinUE Out of Scope:''' and Report Manager><br />
:* The radiologist reads the study, accessing all priors using their usual workflow, display, hanging protocols, and image tools<br />
:* Post-interpretation rules (e.g. purging prior images and reports) occur locally<br />
<br />
The Profile supports a variety of image sharing architectures, e.g. centralized archiving for a region or IDN, federated PACS with point-to-point DIMSE access, etc.<br />
<br />
'''The intent is to make the existing, installed base of PACS systems work better without necessitating any changes or upgrades. The burden is centralized in the Importer and Report Converter actors rather than distributed to every sending or receiving system.'''<br />
<br />
<br />
'''Human Version of the Clinical Use Case'''<br />
<br />
Dr. Smith, a radiologist at a busy Cancer Center, is reporting a large number of CT studies which require comparison to previous imaging often performed at remote (but secure network connected) sites in the region, mostly community hospitals, but also academic centres where the patient may have been seen. The radiologist has to evaluate changes over time in order to assess treatment efficiency, with previous performed usually 3 to 6 months earlier. There may be a series of previous studies at the same interval over a period of a few years.<br />
<br />
Dr. Smith needs to report on a lesion’s change in size and appearance, as well as interval development or resolution of other conditions such as metastatic disease, peritoneal seeding or pleural effusions. For accuracy and speed, Dr Smith has to be able to cross-reference his CT slices and MPRs in DICOM format, using his own measurement tools.<br />
<br />
Dr. Smth wants the remote CT(s) to be readily available in his patient folder on his own PACS, and the studies displayed using his hanging protocols. He wants the report to be available the same way he displays previous reports for studies performed in his institution. <br />
<br />
'''The Problem Case Today'''<br />
<br />
Dr. Smith has to access a separate website, maybe with a separate sign-on. He has to search a separate database, he has to wait for images to load, slowing him down through his very busy work day. To make things worse, Dr. Smith has to open two separate web interfaces, one for the images, another one for the report, as the VNA was not be able to move the report with the images. <br />
<br />
Even though studies are all stored on a central VNA or there is access to other DICOM PACS systems, Dr. Smith has to ask the remote site to print a CD/DVD with the images. He then asks his PACS team to upload these images into his local PACS to make sure that images are available when he reports the current study. Not only is this a tedious manual process, but it delays the time the study is reported sometimes up to a few days. And, using the CD/DVD method, it is common that the previous report is not available.<br />
<br />
==4. Standards and Systems==<br />
<br />
'''Real World Systems:'''<br />
:* EMPI (IHE: PIX/PDQ Manager)<br />
:* RIS/EMRs (IHE: SWF.b DSS/OF, Report Manager, Report Reader)<br />
:* VNA or Diagnostic Imaging Repository (DI-r) (IHE: Image Manager, Report Manager, XDS.b Document Registry+ Document Repository+Imaging Document Source, possibly Importer and/or Report Converter)<br />
:* PACS (IHE: Image Manager/Archive, Image Display, Report Manager, Report Reader, possibly Importer and/or Report Converter)<br />
:* Note: the Importer and Report Converter actors may be separate systems, combined with a system above, or combined together - See Deployment options in Volume 1<br />
<br />
<br />
'''Standards:'''<br />
:* IRWF.b - useful importation logic and data mappings (but that IRWF.b is passive and doesn't specify pre and post steps)<br />
:* PIX/PDQ - patient identification<br />
:* MIMA Vol 2 Appendix J - fully qualified Patient ID reconciliation <br />
:* HL7 v2.x ORM/OMI (RAD-4 + IRWF.b data mappings ) - access to orders for new studies at the local site <br />
:* DICOM Q/R and XDS.b-I (RAD-5 and ITI-18) - find images <br />
:* DICOM C-Move and XDS.b-I (RAD-5 and ITI-18) - retrieve images <br />
:* DICOM C-Store - store images locally (default)<br />
:* '''MinUE Out of scope:''' Mobile Health Documents (MHD) -FHIR query documents<br />
:* '''MinUE Out of scope:''' XDS.b retrieve - report retrieval<br />
:* '''MinUE Out of scope:''' HL7 v2.x ORU (RD:RAD-128) - store report locally as TEXT or PDF<br />
<br />
A Cross Profile Consideration section X.6 discusses how DICOMweb services could be integrated in the future for image access and retrieval. Recommend limiting the required transactions on primary installed base (ie., HL7 v2.x, DICOM, XDS.b).<br />
<br />
==5. Discussion==<br />
<br />
The most important discussion is a consistently agreed upon, and not deviated from, definition of SCOPE:<br />
<br />
'''Minimum Useful Effort (MinUE) Baseline scope:''' Complete the current IDEP supplement, but do NOT include:<br />
:* Reports, in any format, not even TEXT or PDF<br />
:* WIA (DICOMweb) query to access prior images (except as reference in Cross Profile Considerations X.6)<br />
:* Retain Importer actor, but remove Report Converter actor and transactions<br />
:* Retain Image Purge and Report Purge as Named Options with no transactions (only defined behavior)<br />
:* Complete the IHE Public Comment and Trial Implementation processes <br />
:* (NOTE: removal of the Report Converter actor will be a SIGNIFICANT amount of effort for the editor and will include many changes to sections which have already been reviewed in detail by the TC).<br />
<br />
'''Maximum Useful Effort (MaxUE) (Additional) Scope for 2018-2019:'''<br />
:* Retain WIA (DICOMweb) query to access prior reports ONLY as reference in Cross Profile Considerations X.6 (no new DICOMweb functionality within IDEP)<br />
:* Only address TEXT and PDF report formats in direct scope in MaxUE<br />
:* Retain all other report formats as Volume 1 Informative Appendix and nothing more in MaxUE<br />
<br />
SEE [https://docs.google.com/spreadsheets/d/1IAKNiKwKHk3kFEs-mByfuvx91riorZv6El2GDjrZmAA/edit?usp=sharing THIS SUMMARY] FOR SPECIFIC STATUS OF EACH SECTION OF CURRENT SUPPLEMENT.<br />
<br />
This is intended to be a Workflow profile with one primary use case and one of two back-end architectures (all-DICOM and XDS.b (XDS.b as named option)): <br />
<br />
'''Workflow steps to be addressed:'''<br />
:* patient identification and PID reconciliation<br />
:* receipt of new orders<br />
:* relevancy logic meta data identification<br />
:* image retrieval <br />
:* DICOM attribute mapping <br />
:* storage of imported image <br />
:* '''MinUE Out of scope:''' report retrieval <br />
:* '''MinUE Out of scope:''' HL7 v2 ORU report attribute mapping <br />
:* '''MinUE Out of scope:'''storage of imported reports <br />
:* local purging of foreign images and foreign reports as defined Option<br />
<br />
<br />
'''Scope/assumptions:''' <br />
<br />
Goal is to enable automated and contextually integrated VIEWING of foreign radiology priors at the local system.<br />
<br />
:* Focus is on simplicity and existing installed base ("old school") - DICOM, HL7 v2.x, and XDS. (not image access using DICOM web services, or storage of reports using FHIR, etc)<br />
:* Secure network already in place between facilities. (Cross- non-affiliated enterprises out of scope.)<br />
:* EMPI (PIX/PDQ) already in place between facilities. <br />
:* Access prior imaging studies using DIMSE DICOM, but have XDS-I as a named Option. This XDS-I option would also include the hybrid DICOM/XDS.b environment since DICOM is the default environment.<br />
:* Storage of imaging study limited to DIMSE DICOM to the local PACS. (ie., not direct XDS import to the local PACS)<br />
:* Other image types such as Raw JPEG, PDF, etc., are out of scope.<br />
:* '''MinUE Out of scope:''' Report formats are limited to TEXT and PDF.<br />
:* '''MinUE Out of scope:''' Access of prior reports is limited to FHIR query for reports.<br />
:* '''MinUE Out of scope:''' Storage of prior reports is limited to HL7 v2.5.1 ORU with TEXT or PDF content.<br />
:* '''MinUE Out of scope:''' Report '''semantic content''' is always out of scope, i.e., structured or unstructured, etc. This could cause non-interoperability (unable to view), but is still out of scope and must be managed locally.<br />
<br />
==5. Technical Approach==<br />
<br />
:* Focus "intelligence" and mapping in new IDEP actors (Importer and Report Converter). Limit changes to ancillary systems.<br />
:* Populate <specific data element>, but stay away from terminology mapping.<br />
:* Default: Define meta data to be able to determine relevancy, but do not define relevancy rules. Server side v. client side filtering. (IDEP would specify client side filtering.)<br />
:* No intention to map procedure codes, study description, etc. Discuss in X.4 Concepts sections.<br />
:* Do not over-specify display requirements; e.g., "Required to display "something" to indicate that it is an external study."<br />
:* Retain WIA for remote image access via web services in Cross Profile Considerations (X.6); but do not explicitly include.<br />
<br />
<br />
===Existing actors===<br />
<br />
* "Local" DSS/OF<br />
* "Local" Image Manager<br />
* ''MinUE Out of scope: "' "Local" Report Manager<br />
* PIX/PDQ Manager<br />
* "Remote" Image Manager <br />
* '''MinUE Out of scope: "' "Remote" Report Manager <br />
* XDS.b Registry<br />
* '''MinUE Out of scope: "' XDS.b Repository<br />
* XDS.b-I Imaging Document Source<br />
<br />
===New actors===<br />
* Importer (same actor as IRWF.b, but additional behaviors)<br />
* Report Converter<br />
<br />
===Existing transactions===<br />
<br />
Because this proposed profiles focuses on improving the functionality of the existing installed base, it focuses on HL7 v2, DICOM DIMSE Services, and XDS.b transactions.<br />
<br />
See IDEP transaction diagram. (ie., many transactions)<br />
<br />
===New transactions (standards used)===<br />
<br />
A new DICOM query (DICOM query transaction proliferation) transaction was written for "Query for Patient Studies".<br />
New mapping tables were created for the (1) Order (OMI) message data for relevancy, (2) Coercion of MHD data for External Prior Reports, and (3) HL7 v2 ORU for External Prior Reports Mapping.<br />
<br />
===Impact on existing integration profiles===<br />
<br />
IOCM is "out of sync" with IDEP in terms of versions of standards used.<br />
IRWF.b and IDEP have overlap, but are not inconsistent and can peacefully co-exist for now.<br />
IDEP is consistent with current SWF.b profile, but it would be good if SWF.b were fully integrated as Final Text because it is hard to put all of the pieces together.<br />
<br />
===New integration profiles needed===<br />
<br />
None.<br />
<br />
===Breakdown of tasks===<br />
<br />
The high level breakdown of tasks is:<br />
<br />
: 1.) MinUE Baseline or MaxUE scope must be determined and uniformly (and indelibly) agreed to.<br />
: 2.) If MinUE baseline only, editor has a lot of work to do to remove all references to reports (40% of document)<br />
: 3.) Complete internal TC-review prior to Public Comment on un-reviewed sections; obtain vote to proceed to Public Comment.<br />
: 4.) Public comment period<br />
: 5.) Public comment review by TC and incorporation by Editor<br />
: 6.) Internal TC-review and changes by Editor; obtain vote to proceed to Trial Implementation.<br />
<br />
<br />
The specific status of each section is listed in this document:<br />
<br />
==6. Support & Resources==<br />
<br />
Canada Health Infoway has been very active in development of this technology and has implemented it across several broad regions, resulting in real-world data and analytics.<br />
<br />
HCA in the States has expressed in supporting and reviewing a standard to implement the import and display of external priors. HCA's focus is on the proper display of priors for side-by-side comparison in a most useful and effective manner.<br />
<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep to closely related clinical issues such as Emergency Department transfer<br />
:* Scope creep related to incorporating additional report formats beyond TEXT and PDF.<br />
:* Scope creep related to incorporating semantic meaning of reports.<br />
:* Scope creep related to additional methods of image and/or report access or image and/or report storage to local systems.<br />
:* Defining too much logic behind the word "relevant" - vendor/product differentiation; define only mechanisms<br />
:* Legal differences across jurisdictions<br />
<br />
==8. Open Issues==<br />
<br />
Scope creeped. Need to rein it back in, especially in the area of report formats. While report formats and transmission is undeniably a mess, the goal of the IDEP profile was never to fix report interoperability, but rather to access at least some of the prior reports. Complete report interoperability should be its own profile.<br />
<br />
May even want to consider not including informative appendices in Volume 1 on additional report formats, even if it is a critical gap in products today.<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
* % for Maximum/Full Effort = imaging and reports (ONLY report access via FHIR and storage via HL7 ORU TEXT and PDF)<br />
* % for Minimum Useful Effort<br />
:* 1.) Focus strictly on external prior IMAGE access, coercion, and storage<br />
:* 2.) No reports, not even as HL7 ORU TEXT or PDF, possibly mention Reports in X.4 Concepts section - see bolded "MinUE Out of scope" notes<br />
<br />
Candidate Editor:<br />
:* Jonathan Whitby/Vital</div>Terisippelhttp://wiki.ihe.net/index.php?title=Import_and_Display_of_External_Priors-_Proposal&diff=110597Import and Display of External Priors- Proposal2018-07-24T23:43:56Z<p>Terisippel: /* Impact on existing integration profiles */</p>
<hr />
<div>{{TOCright}}<br />
==1. Proposed Workitem: Import and Display of External Priors (IDEP)==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt<br />
* Proposal Contributors: David Koff, MD; Canada Health Infoway; Kevin O'Donnell<br />
* Editor: Jonathan Whitby (previously Teri Sippel Schmidt)<br />
* Contributors: David Koff, MD; Canada Health Infoway<br />
* Domain: Radiology<br />
<br />
This proposal was previously called "[[Foreign_Exam_Management_Direct_Import-_Proposal|Foreign Exam Management (FEM)]]".<br />
<br />
==2. The Problem==<br />
<br />
Prior imaging studies provide vital information and context to the radiologist when interpreting a current study, even resulting in a change of diagnosis. A "prefetch" step (to locate prior studies for the patient that may be relevant and make them immediately accessible to the radiologist during review) is common in imaging workflows. This works fairly well for priors that were performed locally, even if they have to be pulled back from longer term storage to be ready for the radiologist. <br />
<br />
Unfortunately, with the mobility of modern healthcare, '''it is very common for priors to be located outside the reading institution'''.<br />
<br />
Although there have been many improvements to the ability to exchange images between enterprises, or between departments within an enterprise, '''the ability to locate, access, and view priors for direct comparison, particularly during the short time frame required for them to be relevant to reading, is still not reliable'''.<br />
* patient portals - are unwieldy, slow to access, and on different monitors<br />
* web-based viewers - are not integrated into the diagnostic workstation so they '''don't permit side-by side image comparison and use of local hanging protocols''' or viewing tools<br />
* CD/DVD imports/viewers - are often not timely, sometimes do not import reliably, and are "reactive not proactive"<br />
* all suffer from issues with different Patient IDs, procedure codes, etc, questions of long term storage, and some mappings not addressed in IRWF.b. <br />
* radiology reports - there is no primary standard for radiology reports, and as a result, report formats vary dramatically effectively eliminating interoperability of report sharing<br />
<br />
<br />
A solution for this priors problem has been demonstrated to '''also reduce re-scanned patients''' (with cost and radiation implications) due to poor access to studies performed at other institutions.<br />
(Ref: Nagels, J., Macdonald, D. & Coz, C. J Digit Imaging (2017). https://doi.org/10.1007/s10278-017-9963-8)<br />
<br />
==3. Key Use Case==<br />
<br />
'''Order-driven priors:'''<br />
<br />
:* A physician orders a radiology study for a patient<br />
:* The Importer actor searches for prior images <'''MinUE out of scope:''' and reports> for that patient, both locally and beyond<br />
::* The Importer uses PIX/PDQ to get appropriate PIDs for searching<br />
:* The Importer uses order details and local rules to determine which priors are potentially relevant (this profile focuses on specifying metadata availability to enable)<br />
:* The Importer retrieves matching prior images <'''MinUE out of scope''': and reports> executes import logic to map/fix codes and attribute values<br />
:* The Importer stores the imported priors to the local PACS <'''MinUE Out of Scope:''' and Report Manager><br />
:* The radiologist reads the study, accessing all priors using their usual workflow, display, hanging protocols, and image tools<br />
:* Post-interpretation rules (e.g. purging prior images and reports) occur locally<br />
<br />
The Profile supports a variety of image sharing architectures, e.g. centralized archiving for a region or IDN, federated PACS with point-to-point DIMSE access, etc.<br />
<br />
'''The intent is to make the existing, installed base of PACS systems work better without necessitating any changes or upgrades. The burden is centralized in the Importer and Report Converter actors rather than distributed to every sending or receiving system.'''<br />
<br />
<br />
'''Human Version of the Clinical Use Case'''<br />
<br />
Dr. Smith, a radiologist at a busy Cancer Center, is reporting a large number of CT studies which require comparison to previous imaging often performed at remote (but secure network connected) sites in the region, mostly community hospitals, but also academic centres where the patient may have been seen. The radiologist has to evaluate changes over time in order to assess treatment efficiency, with previous performed usually 3 to 6 months earlier. There may be a series of previous studies at the same interval over a period of a few years.<br />
<br />
Dr. Smith needs to report on a lesion’s change in size and appearance, as well as interval development or resolution of other conditions such as metastatic disease, peritoneal seeding or pleural effusions. For accuracy and speed, Dr Smith has to be able to cross-reference his CT slices and MPRs in DICOM format, using his own measurement tools.<br />
<br />
Dr. Smth wants the remote CT(s) to be readily available in his patient folder on his own PACS, and the studies displayed using his hanging protocols. He wants the report to be available the same way he displays previous reports for studies performed in his institution. <br />
<br />
'''The Problem Case Today'''<br />
<br />
Dr. Smith has to access a separate website, maybe with a separate sign-on. He has to search a separate database, he has to wait for images to load, slowing him down through his very busy work day. To make things worse, Dr. Smith has to open two separate web interfaces, one for the images, another one for the report, as the VNA was not be able to move the report with the images. <br />
<br />
Even though studies are all stored on a central VNA or there is access to other DICOM PACS systems, Dr. Smith has to ask the remote site to print a CD/DVD with the images. He then asks his PACS team to upload these images into his local PACS to make sure that images are available when he reports the current study. Not only is this a tedious manual process, but it delays the time the study is reported sometimes up to a few days. And, using the CD/DVD method, it is common that the previous report is not available.<br />
<br />
==4. Standards and Systems==<br />
<br />
'''Real World Systems:'''<br />
:* EMPI (IHE: PIX/PDQ Manager)<br />
:* RIS/EMRs (IHE: SWF.b DSS/OF, Report Manager, Report Reader)<br />
:* VNA or Diagnostic Imaging Repository (DI-r) (IHE: Image Manager, Report Manager, XDS.b Document Registry+ Document Repository+Imaging Document Source, possibly Importer and/or Report Converter)<br />
:* PACS (IHE: Image Manager/Archive, Image Display, Report Manager, Report Reader, possibly Importer and/or Report Converter)<br />
:* Note: the Importer and Report Converter actors may be separate systems, combined with a system above, or combined together - See Deployment options in Volume 1<br />
<br />
<br />
'''Standards:'''<br />
:* IRWF.b - useful importation logic and data mappings (but that IRWF.b is passive and doesn't specify pre and post steps)<br />
:* PIX/PDQ - patient identification<br />
:* MIMA Vol 2 Appendix J - fully qualified Patient ID reconciliation <br />
:* HL7 v2.x ORM/OMI (RAD-4 + IRWF.b data mappings ) - access to orders for new studies at the local site <br />
:* DICOM Q/R and XDS.b-I (RAD-5 and ITI-18) - find images <br />
:* DICOM C-Move and XDS.b-I (RAD-5 and ITI-18) - retrieve images <br />
:* DICOM C-Store - store images locally (default)<br />
:* '''MinUE Out of scope:''' Mobile Health Documents (MHD) -FHIR query documents<br />
:* '''MinUE Out of scope:''' XDS.b retrieve - report retrieval<br />
:* '''MinUE Out of scope:''' HL7 v2.x ORU (RD:RAD-128) - store report locally as TEXT or PDF<br />
<br />
A Cross Profile Consideration section X.6 discusses how DICOMweb services could be integrated in the future for image access and retrieval. Recommend limiting the required transactions on primary installed base (ie., HL7 v2.x, DICOM, XDS.b).<br />
<br />
==5. Discussion==<br />
<br />
The most important discussion is a consistently agreed upon, and not deviated from, definition of SCOPE:<br />
<br />
'''Minimum Useful Effort (MinUE) Baseline scope:''' Complete the current IDEP supplement, but do NOT include:<br />
:* Reports, in any format, not even TEXT or PDF<br />
:* WIA (DICOMweb) query to access prior images (except as reference in Cross Profile Considerations X.6)<br />
:* Retain Importer actor, but remove Report Converter actor and transactions<br />
:* Retain Image Purge and Report Purge as Named Options with no transactions (only defined behavior)<br />
:* Complete the IHE Public Comment and Trial Implementation processes <br />
:* (NOTE: removal of the Report Converter actor will be a SIGNIFICANT amount of effort for the editor and will include many changes to sections which have already been reviewed in detail by the TC).<br />
<br />
'''Maximum Useful Effort (MaxUE) (Additional) Scope for 2018-2019:'''<br />
:* Retain WIA (DICOMweb) query to access prior reports ONLY as reference in Cross Profile Considerations X.6 (no new DICOMweb functionality within IDEP)<br />
:* Only address TEXT and PDF report formats in direct scope in MaxUE<br />
:* Retain all other report formats as Volume 1 Informative Appendix and nothing more in MaxUE<br />
<br />
SEE [https://docs.google.com/spreadsheets/d/1IAKNiKwKHk3kFEs-mByfuvx91riorZv6El2GDjrZmAA/edit?usp=sharing THIS SUMMARY] FOR SPECIFIC STATUS OF EACH SECTION OF CURRENT SUPPLEMENT.<br />
<br />
This is intended to be a Workflow profile with one primary use case and one of two back-end architectures (all-DICOM and XDS.b (XDS.b as named option)): <br />
<br />
'''Workflow steps to be addressed:'''<br />
:* patient identification and PID reconciliation<br />
:* receipt of new orders<br />
:* relevancy logic meta data identification<br />
:* image retrieval <br />
:* DICOM attribute mapping <br />
:* storage of imported image <br />
:* '''MinUE Out of scope:''' report retrieval <br />
:* '''MinUE Out of scope:''' HL7 v2 ORU report attribute mapping <br />
:* '''MinUE Out of scope:'''storage of imported reports <br />
:* local purging of foreign images and foreign reports as defined Option<br />
<br />
<br />
'''Scope/assumptions:''' <br />
<br />
Goal is to enable automated and contextually integrated VIEWING of foreign radiology priors at the local system.<br />
<br />
:* Focus is on simplicity and existing installed base ("old school") - DICOM, HL7 v2.x, and XDS. (not image access using DICOM web services, or storage of reports using FHIR, etc)<br />
:* Secure network already in place between facilities. (Cross- non-affiliated enterprises out of scope.)<br />
:* EMPI (PIX/PDQ) already in place between facilities. <br />
:* Access prior imaging studies using DIMSE DICOM, but have XDS-I as a named Option. This XDS-I option would also include the hybrid DICOM/XDS.b environment since DICOM is the default environment.<br />
:* Storage of imaging study limited to DIMSE DICOM to the local PACS. (ie., not direct XDS import to the local PACS)<br />
:* Other image types such as Raw JPEG, PDF, etc., are out of scope.<br />
:* '''MinUE Out of scope:''' Report formats are limited to TEXT and PDF.<br />
:* '''MinUE Out of scope:''' Access of prior reports is limited to FHIR query for reports.<br />
:* '''MinUE Out of scope:''' Storage of prior reports is limited to HL7 v2.5.1 ORU with TEXT or PDF content.<br />
:* '''MinUE Out of scope:''' Report '''semantic content''' is always out of scope, i.e., structured or unstructured, etc. This could cause non-interoperability (unable to view), but is still out of scope and must be managed locally.<br />
<br />
==5. Technical Approach==<br />
<br />
:* Focus "intelligence" and mapping in new IDEP actors (Importer and Report Converter). Limit changes to ancillary systems.<br />
:* Populate <specific data element>, but stay away from terminology mapping.<br />
:* Default: Define meta data to be able to determine relevancy, but do not define relevancy rules. Server side v. client side filtering. (IDEP would specify client side filtering.)<br />
:* No intention to map procedure codes, study description, etc. Discuss in X.4 Concepts sections.<br />
:* Do not over-specify display requirements; e.g., "Required to display "something" to indicate that it is an external study."<br />
:* Retain WIA for remote image access via web services in Cross Profile Considerations (X.6); but do not explicitly include.<br />
<br />
<br />
===Existing actors===<br />
<br />
* "Local" DSS/OF<br />
* "Local" Image Manager<br />
* ''MinUE Out of scope: "' "Local" Report Manager<br />
* PIX/PDQ Manager<br />
* "Remote" Image Manager <br />
* '''MinUE Out of scope: "' "Remote" Report Manager <br />
* XDS.b Registry<br />
* '''MinUE Out of scope: "' XDS.b Repository<br />
* XDS.b-I Imaging Document Source<br />
<br />
===New actors===<br />
* Importer (same actor as IRWF.b, but additional behaviors)<br />
* Report Converter<br />
<br />
===Existing transactions===<br />
<br />
Because this proposed profiles focuses on improving the functionality of the existing installed base, it focuses on HL7 v2, DICOM DIMSE Services, and XDS.b transactions.<br />
<br />
See IDEP transaction diagram. (ie., many transactions)<br />
<br />
===New transactions (standards used)===<br />
<br />
A new DICOM query (DICOM query transaction proliferation) transaction was written for "Query for Patient Studies".<br />
New mapping tables were created for the (1) Order (OMI) message data for relevancy, (2) Coercion of MHD data for External Prior Reports, and (3) HL7 v2 ORU for External Prior Reports Mapping.<br />
<br />
===Impact on existing integration profiles===<br />
<br />
IOCM is "out of sync" with IDEP in terms of versions of standards used.<br />
IRWF.b and IDEP have overlap, but are not inconsistent and can peacefully co-exist for now.<br />
IDEP is consistent with current SWF.b profile, but it would be good if SWF.b were fully integrated as Final Text because it is hard to put all of the pieces together.<br />
<br />
===New integration profiles needed===<br />
<br />
None.<br />
<br />
===Breakdown of tasks===<br />
<br />
The high level breakdown of tasks is:<br />
<br />
: 1.) MinUE Baseline or MaxUE scope must be determined and uniformly (and indelibly) agreed to.<br />
: 2.) If MinUE baseline only, editor has a lot of work to do to remove all references to reports (40% of document)<br />
: 3.) Complete internal TC-review prior to Public Comment on un-reviewed sections; obtain vote to proceed to Public Comment.<br />
: 4.) Public comment period<br />
: 5.) Public comment review by TC and incorporation by Editor<br />
: 6.) Internal TC-review and changes by Editor; obtain vote to proceed to Trial Implementation.<br />
<br />
<br />
The specific status of each section is listed in this document:<br />
<br />
==6. Support & Resources==<br />
<br />
Canada Health Infoway has been very active in development of this technology and has implemented it across several broad regions, resulting in real-world data and analytics.<br />
<br />
HCA in the States has expressed in supporting and reviewing a standard to implement the import and display of external priors. HCA's focus is on the proper display of priors for side-by-side comparison in a most useful and effective manner.<br />
<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep to closely related clinical issues such as Emergency Department transfer<br />
:* Scope creep related to incorporating additional report formats beyond TEXT and PDF.<br />
:* Scope creep related to incorporating semantic meaning of reports.<br />
:* Scope creep related to additional methods of image and/or report access or image and/or report storage to local systems.<br />
:* Defining too much logic behind the word "relevant" - vendor/product differentiation; define only mechanisms<br />
:* Legal differences across jurisdictions<br />
<br />
==8. Open Issues==<br />
<br />
Scope creeped. Need to rein it back in.<br />
<br />
May even want to consider not including informative appendices in Volume 1 on additional report formats, even if it is a critical gap in products today.<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
* % for Maximum/Full Effort = imaging and reports (ONLY report access via FHIR and storage via HL7 ORU TEXT and PDF)<br />
* % for Minimum Useful Effort<br />
:* 1.) Focus strictly on external prior IMAGE access, coercion, and storage<br />
:* 2.) No reports, not even as HL7 ORU TEXT or PDF, possibly mention Reports in X.4 Concepts section - see bolded "MinUE Out of scope" notes<br />
<br />
Candidate Editor:<br />
:* Jonathan Whitby/Vital</div>Terisippelhttp://wiki.ihe.net/index.php?title=Import_and_Display_of_External_Priors-_Proposal&diff=110596Import and Display of External Priors- Proposal2018-07-24T23:38:40Z<p>Terisippel: /* 1. Proposed Workitem: Import and Display of External Priors (IDEP) */</p>
<hr />
<div>{{TOCright}}<br />
==1. Proposed Workitem: Import and Display of External Priors (IDEP)==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt<br />
* Proposal Contributors: David Koff, MD; Canada Health Infoway; Kevin O'Donnell<br />
* Editor: Jonathan Whitby (previously Teri Sippel Schmidt)<br />
* Contributors: David Koff, MD; Canada Health Infoway<br />
* Domain: Radiology<br />
<br />
This proposal was previously called "[[Foreign_Exam_Management_Direct_Import-_Proposal|Foreign Exam Management (FEM)]]".<br />
<br />
==2. The Problem==<br />
<br />
Prior imaging studies provide vital information and context to the radiologist when interpreting a current study, even resulting in a change of diagnosis. A "prefetch" step (to locate prior studies for the patient that may be relevant and make them immediately accessible to the radiologist during review) is common in imaging workflows. This works fairly well for priors that were performed locally, even if they have to be pulled back from longer term storage to be ready for the radiologist. <br />
<br />
Unfortunately, with the mobility of modern healthcare, '''it is very common for priors to be located outside the reading institution'''.<br />
<br />
Although there have been many improvements to the ability to exchange images between enterprises, or between departments within an enterprise, '''the ability to locate, access, and view priors for direct comparison, particularly during the short time frame required for them to be relevant to reading, is still not reliable'''.<br />
* patient portals - are unwieldy, slow to access, and on different monitors<br />
* web-based viewers - are not integrated into the diagnostic workstation so they '''don't permit side-by side image comparison and use of local hanging protocols''' or viewing tools<br />
* CD/DVD imports/viewers - are often not timely, sometimes do not import reliably, and are "reactive not proactive"<br />
* all suffer from issues with different Patient IDs, procedure codes, etc, questions of long term storage, and some mappings not addressed in IRWF.b. <br />
* radiology reports - there is no primary standard for radiology reports, and as a result, report formats vary dramatically effectively eliminating interoperability of report sharing<br />
<br />
<br />
A solution for this priors problem has been demonstrated to '''also reduce re-scanned patients''' (with cost and radiation implications) due to poor access to studies performed at other institutions.<br />
(Ref: Nagels, J., Macdonald, D. & Coz, C. J Digit Imaging (2017). https://doi.org/10.1007/s10278-017-9963-8)<br />
<br />
==3. Key Use Case==<br />
<br />
'''Order-driven priors:'''<br />
<br />
:* A physician orders a radiology study for a patient<br />
:* The Importer actor searches for prior images <'''MinUE out of scope:''' and reports> for that patient, both locally and beyond<br />
::* The Importer uses PIX/PDQ to get appropriate PIDs for searching<br />
:* The Importer uses order details and local rules to determine which priors are potentially relevant (this profile focuses on specifying metadata availability to enable)<br />
:* The Importer retrieves matching prior images <'''MinUE out of scope''': and reports> executes import logic to map/fix codes and attribute values<br />
:* The Importer stores the imported priors to the local PACS <'''MinUE Out of Scope:''' and Report Manager><br />
:* The radiologist reads the study, accessing all priors using their usual workflow, display, hanging protocols, and image tools<br />
:* Post-interpretation rules (e.g. purging prior images and reports) occur locally<br />
<br />
The Profile supports a variety of image sharing architectures, e.g. centralized archiving for a region or IDN, federated PACS with point-to-point DIMSE access, etc.<br />
<br />
'''The intent is to make the existing, installed base of PACS systems work better without necessitating any changes or upgrades. The burden is centralized in the Importer and Report Converter actors rather than distributed to every sending or receiving system.'''<br />
<br />
<br />
'''Human Version of the Clinical Use Case'''<br />
<br />
Dr. Smith, a radiologist at a busy Cancer Center, is reporting a large number of CT studies which require comparison to previous imaging often performed at remote (but secure network connected) sites in the region, mostly community hospitals, but also academic centres where the patient may have been seen. The radiologist has to evaluate changes over time in order to assess treatment efficiency, with previous performed usually 3 to 6 months earlier. There may be a series of previous studies at the same interval over a period of a few years.<br />
<br />
Dr. Smith needs to report on a lesion’s change in size and appearance, as well as interval development or resolution of other conditions such as metastatic disease, peritoneal seeding or pleural effusions. For accuracy and speed, Dr Smith has to be able to cross-reference his CT slices and MPRs in DICOM format, using his own measurement tools.<br />
<br />
Dr. Smth wants the remote CT(s) to be readily available in his patient folder on his own PACS, and the studies displayed using his hanging protocols. He wants the report to be available the same way he displays previous reports for studies performed in his institution. <br />
<br />
'''The Problem Case Today'''<br />
<br />
Dr. Smith has to access a separate website, maybe with a separate sign-on. He has to search a separate database, he has to wait for images to load, slowing him down through his very busy work day. To make things worse, Dr. Smith has to open two separate web interfaces, one for the images, another one for the report, as the VNA was not be able to move the report with the images. <br />
<br />
Even though studies are all stored on a central VNA or there is access to other DICOM PACS systems, Dr. Smith has to ask the remote site to print a CD/DVD with the images. He then asks his PACS team to upload these images into his local PACS to make sure that images are available when he reports the current study. Not only is this a tedious manual process, but it delays the time the study is reported sometimes up to a few days. And, using the CD/DVD method, it is common that the previous report is not available.<br />
<br />
==4. Standards and Systems==<br />
<br />
'''Real World Systems:'''<br />
:* EMPI (IHE: PIX/PDQ Manager)<br />
:* RIS/EMRs (IHE: SWF.b DSS/OF, Report Manager, Report Reader)<br />
:* VNA or Diagnostic Imaging Repository (DI-r) (IHE: Image Manager, Report Manager, XDS.b Document Registry+ Document Repository+Imaging Document Source, possibly Importer and/or Report Converter)<br />
:* PACS (IHE: Image Manager/Archive, Image Display, Report Manager, Report Reader, possibly Importer and/or Report Converter)<br />
:* Note: the Importer and Report Converter actors may be separate systems, combined with a system above, or combined together - See Deployment options in Volume 1<br />
<br />
<br />
'''Standards:'''<br />
:* IRWF.b - useful importation logic and data mappings (but that IRWF.b is passive and doesn't specify pre and post steps)<br />
:* PIX/PDQ - patient identification<br />
:* MIMA Vol 2 Appendix J - fully qualified Patient ID reconciliation <br />
:* HL7 v2.x ORM/OMI (RAD-4 + IRWF.b data mappings ) - access to orders for new studies at the local site <br />
:* DICOM Q/R and XDS.b-I (RAD-5 and ITI-18) - find images <br />
:* DICOM C-Move and XDS.b-I (RAD-5 and ITI-18) - retrieve images <br />
:* DICOM C-Store - store images locally (default)<br />
:* '''MinUE Out of scope:''' Mobile Health Documents (MHD) -FHIR query documents<br />
:* '''MinUE Out of scope:''' XDS.b retrieve - report retrieval<br />
:* '''MinUE Out of scope:''' HL7 v2.x ORU (RD:RAD-128) - store report locally as TEXT or PDF<br />
<br />
A Cross Profile Consideration section X.6 discusses how DICOMweb services could be integrated in the future for image access and retrieval. Recommend limiting the required transactions on primary installed base (ie., HL7 v2.x, DICOM, XDS.b).<br />
<br />
==5. Discussion==<br />
<br />
The most important discussion is a consistently agreed upon, and not deviated from, definition of SCOPE:<br />
<br />
'''Minimum Useful Effort (MinUE) Baseline scope:''' Complete the current IDEP supplement, but do NOT include:<br />
:* Reports, in any format, not even TEXT or PDF<br />
:* WIA (DICOMweb) query to access prior images (except as reference in Cross Profile Considerations X.6)<br />
:* Retain Importer actor, but remove Report Converter actor and transactions<br />
:* Retain Image Purge and Report Purge as Named Options with no transactions (only defined behavior)<br />
:* Complete the IHE Public Comment and Trial Implementation processes <br />
:* (NOTE: removal of the Report Converter actor will be a SIGNIFICANT amount of effort for the editor and will include many changes to sections which have already been reviewed in detail by the TC).<br />
<br />
'''Maximum Useful Effort (MaxUE) (Additional) Scope for 2018-2019:'''<br />
:* Retain WIA (DICOMweb) query to access prior reports ONLY as reference in Cross Profile Considerations X.6 (no new DICOMweb functionality within IDEP)<br />
:* Only address TEXT and PDF report formats in direct scope in MaxUE<br />
:* Retain all other report formats as Volume 1 Informative Appendix and nothing more in MaxUE<br />
<br />
SEE [https://docs.google.com/spreadsheets/d/1IAKNiKwKHk3kFEs-mByfuvx91riorZv6El2GDjrZmAA/edit?usp=sharing THIS SUMMARY] FOR SPECIFIC STATUS OF EACH SECTION OF CURRENT SUPPLEMENT.<br />
<br />
This is intended to be a Workflow profile with one primary use case and one of two back-end architectures (all-DICOM and XDS.b (XDS.b as named option)): <br />
<br />
'''Workflow steps to be addressed:'''<br />
:* patient identification and PID reconciliation<br />
:* receipt of new orders<br />
:* relevancy logic meta data identification<br />
:* image retrieval <br />
:* DICOM attribute mapping <br />
:* storage of imported image <br />
:* '''MinUE Out of scope:''' report retrieval <br />
:* '''MinUE Out of scope:''' HL7 v2 ORU report attribute mapping <br />
:* '''MinUE Out of scope:'''storage of imported reports <br />
:* local purging of foreign images and foreign reports as defined Option<br />
<br />
<br />
'''Scope/assumptions:''' <br />
<br />
Goal is to enable automated and contextually integrated VIEWING of foreign radiology priors at the local system.<br />
<br />
:* Focus is on simplicity and existing installed base ("old school") - DICOM, HL7 v2.x, and XDS. (not image access using DICOM web services, or storage of reports using FHIR, etc)<br />
:* Secure network already in place between facilities. (Cross- non-affiliated enterprises out of scope.)<br />
:* EMPI (PIX/PDQ) already in place between facilities. <br />
:* Access prior imaging studies using DIMSE DICOM, but have XDS-I as a named Option. This XDS-I option would also include the hybrid DICOM/XDS.b environment since DICOM is the default environment.<br />
:* Storage of imaging study limited to DIMSE DICOM to the local PACS. (ie., not direct XDS import to the local PACS)<br />
:* Other image types such as Raw JPEG, PDF, etc., are out of scope.<br />
:* '''MinUE Out of scope:''' Report formats are limited to TEXT and PDF.<br />
:* '''MinUE Out of scope:''' Access of prior reports is limited to FHIR query for reports.<br />
:* '''MinUE Out of scope:''' Storage of prior reports is limited to HL7 v2.5.1 ORU with TEXT or PDF content.<br />
:* '''MinUE Out of scope:''' Report '''semantic content''' is always out of scope, i.e., structured or unstructured, etc. This could cause non-interoperability (unable to view), but is still out of scope and must be managed locally.<br />
<br />
==5. Technical Approach==<br />
<br />
:* Focus "intelligence" and mapping in new IDEP actors (Importer and Report Converter). Limit changes to ancillary systems.<br />
:* Populate <specific data element>, but stay away from terminology mapping.<br />
:* Default: Define meta data to be able to determine relevancy, but do not define relevancy rules. Server side v. client side filtering. (IDEP would specify client side filtering.)<br />
:* No intention to map procedure codes, study description, etc. Discuss in X.4 Concepts sections.<br />
:* Do not over-specify display requirements; e.g., "Required to display "something" to indicate that it is an external study."<br />
:* Retain WIA for remote image access via web services in Cross Profile Considerations (X.6); but do not explicitly include.<br />
<br />
<br />
===Existing actors===<br />
<br />
* "Local" DSS/OF<br />
* "Local" Image Manager<br />
* ''MinUE Out of scope: "' "Local" Report Manager<br />
* PIX/PDQ Manager<br />
* "Remote" Image Manager <br />
* '''MinUE Out of scope: "' "Remote" Report Manager <br />
* XDS.b Registry<br />
* '''MinUE Out of scope: "' XDS.b Repository<br />
* XDS.b-I Imaging Document Source<br />
<br />
===New actors===<br />
* Importer (same actor as IRWF.b, but additional behaviors)<br />
* Report Converter<br />
<br />
===Existing transactions===<br />
<br />
Because this proposed profiles focuses on improving the functionality of the existing installed base, it focuses on HL7 v2, DICOM DIMSE Services, and XDS.b transactions.<br />
<br />
See IDEP transaction diagram. (ie., many transactions)<br />
<br />
===New transactions (standards used)===<br />
<br />
A new DICOM query (DICOM query transaction proliferation) transaction was written for "Query for Patient Studies".<br />
New mapping tables were created for the (1) Order (OMI) message data for relevancy, (2) Coercion of MHD data for External Prior Reports, and (3) HL7 v2 ORU for External Prior Reports Mapping.<br />
<br />
===Impact on existing integration profiles===<br />
<br />
Some additional behaviour on transactions will be required, but there will be no impact on existing integration profiles.<br />
<br />
===New integration profiles needed===<br />
<br />
None.<br />
<br />
===Breakdown of tasks===<br />
<br />
The high level breakdown of tasks is:<br />
<br />
: 1.) MinUE Baseline or MaxUE scope must be determined and uniformly (and indelibly) agreed to.<br />
: 2.) If MinUE baseline only, editor has a lot of work to do to remove all references to reports (40% of document)<br />
: 3.) Complete internal TC-review prior to Public Comment on un-reviewed sections; obtain vote to proceed to Public Comment.<br />
: 4.) Public comment period<br />
: 5.) Public comment review by TC and incorporation by Editor<br />
: 6.) Internal TC-review and changes by Editor; obtain vote to proceed to Trial Implementation.<br />
<br />
<br />
The specific status of each section is listed in this document:<br />
<br />
==6. Support & Resources==<br />
<br />
Canada Health Infoway has been very active in development of this technology and has implemented it across several broad regions, resulting in real-world data and analytics.<br />
<br />
HCA in the States has expressed in supporting and reviewing a standard to implement the import and display of external priors. HCA's focus is on the proper display of priors for side-by-side comparison in a most useful and effective manner.<br />
<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep to closely related clinical issues such as Emergency Department transfer<br />
:* Scope creep related to incorporating additional report formats beyond TEXT and PDF.<br />
:* Scope creep related to incorporating semantic meaning of reports.<br />
:* Scope creep related to additional methods of image and/or report access or image and/or report storage to local systems.<br />
:* Defining too much logic behind the word "relevant" - vendor/product differentiation; define only mechanisms<br />
:* Legal differences across jurisdictions<br />
<br />
==8. Open Issues==<br />
<br />
Scope creeped. Need to rein it back in.<br />
<br />
May even want to consider not including informative appendices in Volume 1 on additional report formats, even if it is a critical gap in products today.<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
* % for Maximum/Full Effort = imaging and reports (ONLY report access via FHIR and storage via HL7 ORU TEXT and PDF)<br />
* % for Minimum Useful Effort<br />
:* 1.) Focus strictly on external prior IMAGE access, coercion, and storage<br />
:* 2.) No reports, not even as HL7 ORU TEXT or PDF, possibly mention Reports in X.4 Concepts section - see bolded "MinUE Out of scope" notes<br />
<br />
Candidate Editor:<br />
:* Jonathan Whitby/Vital</div>Terisippelhttp://wiki.ihe.net/index.php?title=Import_and_Display_of_External_Priors-_Proposal&diff=110595Import and Display of External Priors- Proposal2018-07-24T23:38:21Z<p>Terisippel: /* 9. Tech Cmte Evaluation */</p>
<hr />
<div>{{TOCright}}<br />
==1. Proposed Workitem: Import and Display of External Priors (IDEP)==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Jonathan Whitby<br />
* Proposal Contributors: David Koff, MD; Canada Health Infoway; Kevin O'Donnell<br />
* Editor: Jonathan Whitby (previously Teri Sippel Schmidt)<br />
* Contributors: David Koff, MD; Canada Health Infoway<br />
* Domain: Radiology<br />
<br />
This proposal was previously called "[[Foreign_Exam_Management_Direct_Import-_Proposal|Foreign Exam Management (FEM)]]".<br />
<br />
==2. The Problem==<br />
<br />
Prior imaging studies provide vital information and context to the radiologist when interpreting a current study, even resulting in a change of diagnosis. A "prefetch" step (to locate prior studies for the patient that may be relevant and make them immediately accessible to the radiologist during review) is common in imaging workflows. This works fairly well for priors that were performed locally, even if they have to be pulled back from longer term storage to be ready for the radiologist. <br />
<br />
Unfortunately, with the mobility of modern healthcare, '''it is very common for priors to be located outside the reading institution'''.<br />
<br />
Although there have been many improvements to the ability to exchange images between enterprises, or between departments within an enterprise, '''the ability to locate, access, and view priors for direct comparison, particularly during the short time frame required for them to be relevant to reading, is still not reliable'''.<br />
* patient portals - are unwieldy, slow to access, and on different monitors<br />
* web-based viewers - are not integrated into the diagnostic workstation so they '''don't permit side-by side image comparison and use of local hanging protocols''' or viewing tools<br />
* CD/DVD imports/viewers - are often not timely, sometimes do not import reliably, and are "reactive not proactive"<br />
* all suffer from issues with different Patient IDs, procedure codes, etc, questions of long term storage, and some mappings not addressed in IRWF.b. <br />
* radiology reports - there is no primary standard for radiology reports, and as a result, report formats vary dramatically effectively eliminating interoperability of report sharing<br />
<br />
<br />
A solution for this priors problem has been demonstrated to '''also reduce re-scanned patients''' (with cost and radiation implications) due to poor access to studies performed at other institutions.<br />
(Ref: Nagels, J., Macdonald, D. & Coz, C. J Digit Imaging (2017). https://doi.org/10.1007/s10278-017-9963-8)<br />
<br />
==3. Key Use Case==<br />
<br />
'''Order-driven priors:'''<br />
<br />
:* A physician orders a radiology study for a patient<br />
:* The Importer actor searches for prior images <'''MinUE out of scope:''' and reports> for that patient, both locally and beyond<br />
::* The Importer uses PIX/PDQ to get appropriate PIDs for searching<br />
:* The Importer uses order details and local rules to determine which priors are potentially relevant (this profile focuses on specifying metadata availability to enable)<br />
:* The Importer retrieves matching prior images <'''MinUE out of scope''': and reports> executes import logic to map/fix codes and attribute values<br />
:* The Importer stores the imported priors to the local PACS <'''MinUE Out of Scope:''' and Report Manager><br />
:* The radiologist reads the study, accessing all priors using their usual workflow, display, hanging protocols, and image tools<br />
:* Post-interpretation rules (e.g. purging prior images and reports) occur locally<br />
<br />
The Profile supports a variety of image sharing architectures, e.g. centralized archiving for a region or IDN, federated PACS with point-to-point DIMSE access, etc.<br />
<br />
'''The intent is to make the existing, installed base of PACS systems work better without necessitating any changes or upgrades. The burden is centralized in the Importer and Report Converter actors rather than distributed to every sending or receiving system.'''<br />
<br />
<br />
'''Human Version of the Clinical Use Case'''<br />
<br />
Dr. Smith, a radiologist at a busy Cancer Center, is reporting a large number of CT studies which require comparison to previous imaging often performed at remote (but secure network connected) sites in the region, mostly community hospitals, but also academic centres where the patient may have been seen. The radiologist has to evaluate changes over time in order to assess treatment efficiency, with previous performed usually 3 to 6 months earlier. There may be a series of previous studies at the same interval over a period of a few years.<br />
<br />
Dr. Smith needs to report on a lesion’s change in size and appearance, as well as interval development or resolution of other conditions such as metastatic disease, peritoneal seeding or pleural effusions. For accuracy and speed, Dr Smith has to be able to cross-reference his CT slices and MPRs in DICOM format, using his own measurement tools.<br />
<br />
Dr. Smth wants the remote CT(s) to be readily available in his patient folder on his own PACS, and the studies displayed using his hanging protocols. He wants the report to be available the same way he displays previous reports for studies performed in his institution. <br />
<br />
'''The Problem Case Today'''<br />
<br />
Dr. Smith has to access a separate website, maybe with a separate sign-on. He has to search a separate database, he has to wait for images to load, slowing him down through his very busy work day. To make things worse, Dr. Smith has to open two separate web interfaces, one for the images, another one for the report, as the VNA was not be able to move the report with the images. <br />
<br />
Even though studies are all stored on a central VNA or there is access to other DICOM PACS systems, Dr. Smith has to ask the remote site to print a CD/DVD with the images. He then asks his PACS team to upload these images into his local PACS to make sure that images are available when he reports the current study. Not only is this a tedious manual process, but it delays the time the study is reported sometimes up to a few days. And, using the CD/DVD method, it is common that the previous report is not available.<br />
<br />
==4. Standards and Systems==<br />
<br />
'''Real World Systems:'''<br />
:* EMPI (IHE: PIX/PDQ Manager)<br />
:* RIS/EMRs (IHE: SWF.b DSS/OF, Report Manager, Report Reader)<br />
:* VNA or Diagnostic Imaging Repository (DI-r) (IHE: Image Manager, Report Manager, XDS.b Document Registry+ Document Repository+Imaging Document Source, possibly Importer and/or Report Converter)<br />
:* PACS (IHE: Image Manager/Archive, Image Display, Report Manager, Report Reader, possibly Importer and/or Report Converter)<br />
:* Note: the Importer and Report Converter actors may be separate systems, combined with a system above, or combined together - See Deployment options in Volume 1<br />
<br />
<br />
'''Standards:'''<br />
:* IRWF.b - useful importation logic and data mappings (but that IRWF.b is passive and doesn't specify pre and post steps)<br />
:* PIX/PDQ - patient identification<br />
:* MIMA Vol 2 Appendix J - fully qualified Patient ID reconciliation <br />
:* HL7 v2.x ORM/OMI (RAD-4 + IRWF.b data mappings ) - access to orders for new studies at the local site <br />
:* DICOM Q/R and XDS.b-I (RAD-5 and ITI-18) - find images <br />
:* DICOM C-Move and XDS.b-I (RAD-5 and ITI-18) - retrieve images <br />
:* DICOM C-Store - store images locally (default)<br />
:* '''MinUE Out of scope:''' Mobile Health Documents (MHD) -FHIR query documents<br />
:* '''MinUE Out of scope:''' XDS.b retrieve - report retrieval<br />
:* '''MinUE Out of scope:''' HL7 v2.x ORU (RD:RAD-128) - store report locally as TEXT or PDF<br />
<br />
A Cross Profile Consideration section X.6 discusses how DICOMweb services could be integrated in the future for image access and retrieval. Recommend limiting the required transactions on primary installed base (ie., HL7 v2.x, DICOM, XDS.b).<br />
<br />
==5. Discussion==<br />
<br />
The most important discussion is a consistently agreed upon, and not deviated from, definition of SCOPE:<br />
<br />
'''Minimum Useful Effort (MinUE) Baseline scope:''' Complete the current IDEP supplement, but do NOT include:<br />
:* Reports, in any format, not even TEXT or PDF<br />
:* WIA (DICOMweb) query to access prior images (except as reference in Cross Profile Considerations X.6)<br />
:* Retain Importer actor, but remove Report Converter actor and transactions<br />
:* Retain Image Purge and Report Purge as Named Options with no transactions (only defined behavior)<br />
:* Complete the IHE Public Comment and Trial Implementation processes <br />
:* (NOTE: removal of the Report Converter actor will be a SIGNIFICANT amount of effort for the editor and will include many changes to sections which have already been reviewed in detail by the TC).<br />
<br />
'''Maximum Useful Effort (MaxUE) (Additional) Scope for 2018-2019:'''<br />
:* Retain WIA (DICOMweb) query to access prior reports ONLY as reference in Cross Profile Considerations X.6 (no new DICOMweb functionality within IDEP)<br />
:* Only address TEXT and PDF report formats in direct scope in MaxUE<br />
:* Retain all other report formats as Volume 1 Informative Appendix and nothing more in MaxUE<br />
<br />
SEE [https://docs.google.com/spreadsheets/d/1IAKNiKwKHk3kFEs-mByfuvx91riorZv6El2GDjrZmAA/edit?usp=sharing THIS SUMMARY] FOR SPECIFIC STATUS OF EACH SECTION OF CURRENT SUPPLEMENT.<br />
<br />
This is intended to be a Workflow profile with one primary use case and one of two back-end architectures (all-DICOM and XDS.b (XDS.b as named option)): <br />
<br />
'''Workflow steps to be addressed:'''<br />
:* patient identification and PID reconciliation<br />
:* receipt of new orders<br />
:* relevancy logic meta data identification<br />
:* image retrieval <br />
:* DICOM attribute mapping <br />
:* storage of imported image <br />
:* '''MinUE Out of scope:''' report retrieval <br />
:* '''MinUE Out of scope:''' HL7 v2 ORU report attribute mapping <br />
:* '''MinUE Out of scope:'''storage of imported reports <br />
:* local purging of foreign images and foreign reports as defined Option<br />
<br />
<br />
'''Scope/assumptions:''' <br />
<br />
Goal is to enable automated and contextually integrated VIEWING of foreign radiology priors at the local system.<br />
<br />
:* Focus is on simplicity and existing installed base ("old school") - DICOM, HL7 v2.x, and XDS. (not image access using DICOM web services, or storage of reports using FHIR, etc)<br />
:* Secure network already in place between facilities. (Cross- non-affiliated enterprises out of scope.)<br />
:* EMPI (PIX/PDQ) already in place between facilities. <br />
:* Access prior imaging studies using DIMSE DICOM, but have XDS-I as a named Option. This XDS-I option would also include the hybrid DICOM/XDS.b environment since DICOM is the default environment.<br />
:* Storage of imaging study limited to DIMSE DICOM to the local PACS. (ie., not direct XDS import to the local PACS)<br />
:* Other image types such as Raw JPEG, PDF, etc., are out of scope.<br />
:* '''MinUE Out of scope:''' Report formats are limited to TEXT and PDF.<br />
:* '''MinUE Out of scope:''' Access of prior reports is limited to FHIR query for reports.<br />
:* '''MinUE Out of scope:''' Storage of prior reports is limited to HL7 v2.5.1 ORU with TEXT or PDF content.<br />
:* '''MinUE Out of scope:''' Report '''semantic content''' is always out of scope, i.e., structured or unstructured, etc. This could cause non-interoperability (unable to view), but is still out of scope and must be managed locally.<br />
<br />
==5. Technical Approach==<br />
<br />
:* Focus "intelligence" and mapping in new IDEP actors (Importer and Report Converter). Limit changes to ancillary systems.<br />
:* Populate <specific data element>, but stay away from terminology mapping.<br />
:* Default: Define meta data to be able to determine relevancy, but do not define relevancy rules. Server side v. client side filtering. (IDEP would specify client side filtering.)<br />
:* No intention to map procedure codes, study description, etc. Discuss in X.4 Concepts sections.<br />
:* Do not over-specify display requirements; e.g., "Required to display "something" to indicate that it is an external study."<br />
:* Retain WIA for remote image access via web services in Cross Profile Considerations (X.6); but do not explicitly include.<br />
<br />
<br />
===Existing actors===<br />
<br />
* "Local" DSS/OF<br />
* "Local" Image Manager<br />
* ''MinUE Out of scope: "' "Local" Report Manager<br />
* PIX/PDQ Manager<br />
* "Remote" Image Manager <br />
* '''MinUE Out of scope: "' "Remote" Report Manager <br />
* XDS.b Registry<br />
* '''MinUE Out of scope: "' XDS.b Repository<br />
* XDS.b-I Imaging Document Source<br />
<br />
===New actors===<br />
* Importer (same actor as IRWF.b, but additional behaviors)<br />
* Report Converter<br />
<br />
===Existing transactions===<br />
<br />
Because this proposed profiles focuses on improving the functionality of the existing installed base, it focuses on HL7 v2, DICOM DIMSE Services, and XDS.b transactions.<br />
<br />
See IDEP transaction diagram. (ie., many transactions)<br />
<br />
===New transactions (standards used)===<br />
<br />
A new DICOM query (DICOM query transaction proliferation) transaction was written for "Query for Patient Studies".<br />
New mapping tables were created for the (1) Order (OMI) message data for relevancy, (2) Coercion of MHD data for External Prior Reports, and (3) HL7 v2 ORU for External Prior Reports Mapping.<br />
<br />
===Impact on existing integration profiles===<br />
<br />
Some additional behaviour on transactions will be required, but there will be no impact on existing integration profiles.<br />
<br />
===New integration profiles needed===<br />
<br />
None.<br />
<br />
===Breakdown of tasks===<br />
<br />
The high level breakdown of tasks is:<br />
<br />
: 1.) MinUE Baseline or MaxUE scope must be determined and uniformly (and indelibly) agreed to.<br />
: 2.) If MinUE baseline only, editor has a lot of work to do to remove all references to reports (40% of document)<br />
: 3.) Complete internal TC-review prior to Public Comment on un-reviewed sections; obtain vote to proceed to Public Comment.<br />
: 4.) Public comment period<br />
: 5.) Public comment review by TC and incorporation by Editor<br />
: 6.) Internal TC-review and changes by Editor; obtain vote to proceed to Trial Implementation.<br />
<br />
<br />
The specific status of each section is listed in this document:<br />
<br />
==6. Support & Resources==<br />
<br />
Canada Health Infoway has been very active in development of this technology and has implemented it across several broad regions, resulting in real-world data and analytics.<br />
<br />
HCA in the States has expressed in supporting and reviewing a standard to implement the import and display of external priors. HCA's focus is on the proper display of priors for side-by-side comparison in a most useful and effective manner.<br />
<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep to closely related clinical issues such as Emergency Department transfer<br />
:* Scope creep related to incorporating additional report formats beyond TEXT and PDF.<br />
:* Scope creep related to incorporating semantic meaning of reports.<br />
:* Scope creep related to additional methods of image and/or report access or image and/or report storage to local systems.<br />
:* Defining too much logic behind the word "relevant" - vendor/product differentiation; define only mechanisms<br />
:* Legal differences across jurisdictions<br />
<br />
==8. Open Issues==<br />
<br />
Scope creeped. Need to rein it back in.<br />
<br />
May even want to consider not including informative appendices in Volume 1 on additional report formats, even if it is a critical gap in products today.<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
* % for Maximum/Full Effort = imaging and reports (ONLY report access via FHIR and storage via HL7 ORU TEXT and PDF)<br />
* % for Minimum Useful Effort<br />
:* 1.) Focus strictly on external prior IMAGE access, coercion, and storage<br />
:* 2.) No reports, not even as HL7 ORU TEXT or PDF, possibly mention Reports in X.4 Concepts section - see bolded "MinUE Out of scope" notes<br />
<br />
Candidate Editor:<br />
:* Jonathan Whitby/Vital</div>Terisippelhttp://wiki.ihe.net/index.php?title=Import_and_Display_of_External_Priors-_Proposal&diff=110594Import and Display of External Priors- Proposal2018-07-24T23:34:46Z<p>Terisippel: /* 8. Open Issues */</p>
<hr />
<div>{{TOCright}}<br />
==1. Proposed Workitem: Import and Display of External Priors (IDEP)==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Jonathan Whitby<br />
* Proposal Contributors: David Koff, MD; Canada Health Infoway; Kevin O'Donnell<br />
* Editor: Jonathan Whitby (previously Teri Sippel Schmidt)<br />
* Contributors: David Koff, MD; Canada Health Infoway<br />
* Domain: Radiology<br />
<br />
This proposal was previously called "[[Foreign_Exam_Management_Direct_Import-_Proposal|Foreign Exam Management (FEM)]]".<br />
<br />
==2. The Problem==<br />
<br />
Prior imaging studies provide vital information and context to the radiologist when interpreting a current study, even resulting in a change of diagnosis. A "prefetch" step (to locate prior studies for the patient that may be relevant and make them immediately accessible to the radiologist during review) is common in imaging workflows. This works fairly well for priors that were performed locally, even if they have to be pulled back from longer term storage to be ready for the radiologist. <br />
<br />
Unfortunately, with the mobility of modern healthcare, '''it is very common for priors to be located outside the reading institution'''.<br />
<br />
Although there have been many improvements to the ability to exchange images between enterprises, or between departments within an enterprise, '''the ability to locate, access, and view priors for direct comparison, particularly during the short time frame required for them to be relevant to reading, is still not reliable'''.<br />
* patient portals - are unwieldy, slow to access, and on different monitors<br />
* web-based viewers - are not integrated into the diagnostic workstation so they '''don't permit side-by side image comparison and use of local hanging protocols''' or viewing tools<br />
* CD/DVD imports/viewers - are often not timely, sometimes do not import reliably, and are "reactive not proactive"<br />
* all suffer from issues with different Patient IDs, procedure codes, etc, questions of long term storage, and some mappings not addressed in IRWF.b. <br />
* radiology reports - there is no primary standard for radiology reports, and as a result, report formats vary dramatically effectively eliminating interoperability of report sharing<br />
<br />
<br />
A solution for this priors problem has been demonstrated to '''also reduce re-scanned patients''' (with cost and radiation implications) due to poor access to studies performed at other institutions.<br />
(Ref: Nagels, J., Macdonald, D. & Coz, C. J Digit Imaging (2017). https://doi.org/10.1007/s10278-017-9963-8)<br />
<br />
==3. Key Use Case==<br />
<br />
'''Order-driven priors:'''<br />
<br />
:* A physician orders a radiology study for a patient<br />
:* The Importer actor searches for prior images <'''MinUE out of scope:''' and reports> for that patient, both locally and beyond<br />
::* The Importer uses PIX/PDQ to get appropriate PIDs for searching<br />
:* The Importer uses order details and local rules to determine which priors are potentially relevant (this profile focuses on specifying metadata availability to enable)<br />
:* The Importer retrieves matching prior images <'''MinUE out of scope''': and reports> executes import logic to map/fix codes and attribute values<br />
:* The Importer stores the imported priors to the local PACS <'''MinUE Out of Scope:''' and Report Manager><br />
:* The radiologist reads the study, accessing all priors using their usual workflow, display, hanging protocols, and image tools<br />
:* Post-interpretation rules (e.g. purging prior images and reports) occur locally<br />
<br />
The Profile supports a variety of image sharing architectures, e.g. centralized archiving for a region or IDN, federated PACS with point-to-point DIMSE access, etc.<br />
<br />
'''The intent is to make the existing, installed base of PACS systems work better without necessitating any changes or upgrades. The burden is centralized in the Importer and Report Converter actors rather than distributed to every sending or receiving system.'''<br />
<br />
<br />
'''Human Version of the Clinical Use Case'''<br />
<br />
Dr. Smith, a radiologist at a busy Cancer Center, is reporting a large number of CT studies which require comparison to previous imaging often performed at remote (but secure network connected) sites in the region, mostly community hospitals, but also academic centres where the patient may have been seen. The radiologist has to evaluate changes over time in order to assess treatment efficiency, with previous performed usually 3 to 6 months earlier. There may be a series of previous studies at the same interval over a period of a few years.<br />
<br />
Dr. Smith needs to report on a lesion’s change in size and appearance, as well as interval development or resolution of other conditions such as metastatic disease, peritoneal seeding or pleural effusions. For accuracy and speed, Dr Smith has to be able to cross-reference his CT slices and MPRs in DICOM format, using his own measurement tools.<br />
<br />
Dr. Smth wants the remote CT(s) to be readily available in his patient folder on his own PACS, and the studies displayed using his hanging protocols. He wants the report to be available the same way he displays previous reports for studies performed in his institution. <br />
<br />
'''The Problem Case Today'''<br />
<br />
Dr. Smith has to access a separate website, maybe with a separate sign-on. He has to search a separate database, he has to wait for images to load, slowing him down through his very busy work day. To make things worse, Dr. Smith has to open two separate web interfaces, one for the images, another one for the report, as the VNA was not be able to move the report with the images. <br />
<br />
Even though studies are all stored on a central VNA or there is access to other DICOM PACS systems, Dr. Smith has to ask the remote site to print a CD/DVD with the images. He then asks his PACS team to upload these images into his local PACS to make sure that images are available when he reports the current study. Not only is this a tedious manual process, but it delays the time the study is reported sometimes up to a few days. And, using the CD/DVD method, it is common that the previous report is not available.<br />
<br />
==4. Standards and Systems==<br />
<br />
'''Real World Systems:'''<br />
:* EMPI (IHE: PIX/PDQ Manager)<br />
:* RIS/EMRs (IHE: SWF.b DSS/OF, Report Manager, Report Reader)<br />
:* VNA or Diagnostic Imaging Repository (DI-r) (IHE: Image Manager, Report Manager, XDS.b Document Registry+ Document Repository+Imaging Document Source, possibly Importer and/or Report Converter)<br />
:* PACS (IHE: Image Manager/Archive, Image Display, Report Manager, Report Reader, possibly Importer and/or Report Converter)<br />
:* Note: the Importer and Report Converter actors may be separate systems, combined with a system above, or combined together - See Deployment options in Volume 1<br />
<br />
<br />
'''Standards:'''<br />
:* IRWF.b - useful importation logic and data mappings (but that IRWF.b is passive and doesn't specify pre and post steps)<br />
:* PIX/PDQ - patient identification<br />
:* MIMA Vol 2 Appendix J - fully qualified Patient ID reconciliation <br />
:* HL7 v2.x ORM/OMI (RAD-4 + IRWF.b data mappings ) - access to orders for new studies at the local site <br />
:* DICOM Q/R and XDS.b-I (RAD-5 and ITI-18) - find images <br />
:* DICOM C-Move and XDS.b-I (RAD-5 and ITI-18) - retrieve images <br />
:* DICOM C-Store - store images locally (default)<br />
:* '''MinUE Out of scope:''' Mobile Health Documents (MHD) -FHIR query documents<br />
:* '''MinUE Out of scope:''' XDS.b retrieve - report retrieval<br />
:* '''MinUE Out of scope:''' HL7 v2.x ORU (RD:RAD-128) - store report locally as TEXT or PDF<br />
<br />
A Cross Profile Consideration section X.6 discusses how DICOMweb services could be integrated in the future for image access and retrieval. Recommend limiting the required transactions on primary installed base (ie., HL7 v2.x, DICOM, XDS.b).<br />
<br />
==5. Discussion==<br />
<br />
The most important discussion is a consistently agreed upon, and not deviated from, definition of SCOPE:<br />
<br />
'''Minimum Useful Effort (MinUE) Baseline scope:''' Complete the current IDEP supplement, but do NOT include:<br />
:* Reports, in any format, not even TEXT or PDF<br />
:* WIA (DICOMweb) query to access prior images (except as reference in Cross Profile Considerations X.6)<br />
:* Retain Importer actor, but remove Report Converter actor and transactions<br />
:* Retain Image Purge and Report Purge as Named Options with no transactions (only defined behavior)<br />
:* Complete the IHE Public Comment and Trial Implementation processes <br />
:* (NOTE: removal of the Report Converter actor will be a SIGNIFICANT amount of effort for the editor and will include many changes to sections which have already been reviewed in detail by the TC).<br />
<br />
'''Maximum Useful Effort (MaxUE) (Additional) Scope for 2018-2019:'''<br />
:* Retain WIA (DICOMweb) query to access prior reports ONLY as reference in Cross Profile Considerations X.6 (no new DICOMweb functionality within IDEP)<br />
:* Only address TEXT and PDF report formats in direct scope in MaxUE<br />
:* Retain all other report formats as Volume 1 Informative Appendix and nothing more in MaxUE<br />
<br />
SEE [https://docs.google.com/spreadsheets/d/1IAKNiKwKHk3kFEs-mByfuvx91riorZv6El2GDjrZmAA/edit?usp=sharing THIS SUMMARY] FOR SPECIFIC STATUS OF EACH SECTION OF CURRENT SUPPLEMENT.<br />
<br />
This is intended to be a Workflow profile with one primary use case and one of two back-end architectures (all-DICOM and XDS.b (XDS.b as named option)): <br />
<br />
'''Workflow steps to be addressed:'''<br />
:* patient identification and PID reconciliation<br />
:* receipt of new orders<br />
:* relevancy logic meta data identification<br />
:* image retrieval <br />
:* DICOM attribute mapping <br />
:* storage of imported image <br />
:* '''MinUE Out of scope:''' report retrieval <br />
:* '''MinUE Out of scope:''' HL7 v2 ORU report attribute mapping <br />
:* '''MinUE Out of scope:'''storage of imported reports <br />
:* local purging of foreign images and foreign reports as defined Option<br />
<br />
<br />
'''Scope/assumptions:''' <br />
<br />
Goal is to enable automated and contextually integrated VIEWING of foreign radiology priors at the local system.<br />
<br />
:* Focus is on simplicity and existing installed base ("old school") - DICOM, HL7 v2.x, and XDS. (not image access using DICOM web services, or storage of reports using FHIR, etc)<br />
:* Secure network already in place between facilities. (Cross- non-affiliated enterprises out of scope.)<br />
:* EMPI (PIX/PDQ) already in place between facilities. <br />
:* Access prior imaging studies using DIMSE DICOM, but have XDS-I as a named Option. This XDS-I option would also include the hybrid DICOM/XDS.b environment since DICOM is the default environment.<br />
:* Storage of imaging study limited to DIMSE DICOM to the local PACS. (ie., not direct XDS import to the local PACS)<br />
:* Other image types such as Raw JPEG, PDF, etc., are out of scope.<br />
:* '''MinUE Out of scope:''' Report formats are limited to TEXT and PDF.<br />
:* '''MinUE Out of scope:''' Access of prior reports is limited to FHIR query for reports.<br />
:* '''MinUE Out of scope:''' Storage of prior reports is limited to HL7 v2.5.1 ORU with TEXT or PDF content.<br />
:* '''MinUE Out of scope:''' Report '''semantic content''' is always out of scope, i.e., structured or unstructured, etc. This could cause non-interoperability (unable to view), but is still out of scope and must be managed locally.<br />
<br />
==5. Technical Approach==<br />
<br />
:* Focus "intelligence" and mapping in new IDEP actors (Importer and Report Converter). Limit changes to ancillary systems.<br />
:* Populate <specific data element>, but stay away from terminology mapping.<br />
:* Default: Define meta data to be able to determine relevancy, but do not define relevancy rules. Server side v. client side filtering. (IDEP would specify client side filtering.)<br />
:* No intention to map procedure codes, study description, etc. Discuss in X.4 Concepts sections.<br />
:* Do not over-specify display requirements; e.g., "Required to display "something" to indicate that it is an external study."<br />
:* Retain WIA for remote image access via web services in Cross Profile Considerations (X.6); but do not explicitly include.<br />
<br />
<br />
===Existing actors===<br />
<br />
* "Local" DSS/OF<br />
* "Local" Image Manager<br />
* ''MinUE Out of scope: "' "Local" Report Manager<br />
* PIX/PDQ Manager<br />
* "Remote" Image Manager <br />
* '''MinUE Out of scope: "' "Remote" Report Manager <br />
* XDS.b Registry<br />
* '''MinUE Out of scope: "' XDS.b Repository<br />
* XDS.b-I Imaging Document Source<br />
<br />
===New actors===<br />
* Importer (same actor as IRWF.b, but additional behaviors)<br />
* Report Converter<br />
<br />
===Existing transactions===<br />
<br />
Because this proposed profiles focuses on improving the functionality of the existing installed base, it focuses on HL7 v2, DICOM DIMSE Services, and XDS.b transactions.<br />
<br />
See IDEP transaction diagram. (ie., many transactions)<br />
<br />
===New transactions (standards used)===<br />
<br />
A new DICOM query (DICOM query transaction proliferation) transaction was written for "Query for Patient Studies".<br />
New mapping tables were created for the (1) Order (OMI) message data for relevancy, (2) Coercion of MHD data for External Prior Reports, and (3) HL7 v2 ORU for External Prior Reports Mapping.<br />
<br />
===Impact on existing integration profiles===<br />
<br />
Some additional behaviour on transactions will be required, but there will be no impact on existing integration profiles.<br />
<br />
===New integration profiles needed===<br />
<br />
None.<br />
<br />
===Breakdown of tasks===<br />
<br />
The high level breakdown of tasks is:<br />
<br />
: 1.) MinUE Baseline or MaxUE scope must be determined and uniformly (and indelibly) agreed to.<br />
: 2.) If MinUE baseline only, editor has a lot of work to do to remove all references to reports (40% of document)<br />
: 3.) Complete internal TC-review prior to Public Comment on un-reviewed sections; obtain vote to proceed to Public Comment.<br />
: 4.) Public comment period<br />
: 5.) Public comment review by TC and incorporation by Editor<br />
: 6.) Internal TC-review and changes by Editor; obtain vote to proceed to Trial Implementation.<br />
<br />
<br />
The specific status of each section is listed in this document:<br />
<br />
==6. Support & Resources==<br />
<br />
Canada Health Infoway has been very active in development of this technology and has implemented it across several broad regions, resulting in real-world data and analytics.<br />
<br />
HCA in the States has expressed in supporting and reviewing a standard to implement the import and display of external priors. HCA's focus is on the proper display of priors for side-by-side comparison in a most useful and effective manner.<br />
<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep to closely related clinical issues such as Emergency Department transfer<br />
:* Scope creep related to incorporating additional report formats beyond TEXT and PDF.<br />
:* Scope creep related to incorporating semantic meaning of reports.<br />
:* Scope creep related to additional methods of image and/or report access or image and/or report storage to local systems.<br />
:* Defining too much logic behind the word "relevant" - vendor/product differentiation; define only mechanisms<br />
:* Legal differences across jurisdictions<br />
<br />
==8. Open Issues==<br />
<br />
Scope creeped. Need to rein it back in.<br />
<br />
May even want to consider not including informative appendices in Volume 1 on additional report formats, even if it is a critical gap in products today.<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
* 40% for Maximum/Full Effort = imaging and reports (only as HL7 ORU text)<br />
* 25% for Minimum Useful Effort<br />
:* 1.) Select only XDS or DICOM environment<br />
:* 2.) Leave purging out of scope<br />
:* 3.) No reports, even as only an HL7 ORU text, Reports mentioned in X.4 Concepts section - added bolded "Out of scope" note to all references to reports (imaging only)<br />
<br />
Candidate Editor:<br />
: Teri Sippel Schmidt</div>Terisippelhttp://wiki.ihe.net/index.php?title=Import_and_Display_of_External_Priors-_Proposal&diff=110593Import and Display of External Priors- Proposal2018-07-24T23:33:43Z<p>Terisippel: /* 7. Risks */</p>
<hr />
<div>{{TOCright}}<br />
==1. Proposed Workitem: Import and Display of External Priors (IDEP)==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Jonathan Whitby<br />
* Proposal Contributors: David Koff, MD; Canada Health Infoway; Kevin O'Donnell<br />
* Editor: Jonathan Whitby (previously Teri Sippel Schmidt)<br />
* Contributors: David Koff, MD; Canada Health Infoway<br />
* Domain: Radiology<br />
<br />
This proposal was previously called "[[Foreign_Exam_Management_Direct_Import-_Proposal|Foreign Exam Management (FEM)]]".<br />
<br />
==2. The Problem==<br />
<br />
Prior imaging studies provide vital information and context to the radiologist when interpreting a current study, even resulting in a change of diagnosis. A "prefetch" step (to locate prior studies for the patient that may be relevant and make them immediately accessible to the radiologist during review) is common in imaging workflows. This works fairly well for priors that were performed locally, even if they have to be pulled back from longer term storage to be ready for the radiologist. <br />
<br />
Unfortunately, with the mobility of modern healthcare, '''it is very common for priors to be located outside the reading institution'''.<br />
<br />
Although there have been many improvements to the ability to exchange images between enterprises, or between departments within an enterprise, '''the ability to locate, access, and view priors for direct comparison, particularly during the short time frame required for them to be relevant to reading, is still not reliable'''.<br />
* patient portals - are unwieldy, slow to access, and on different monitors<br />
* web-based viewers - are not integrated into the diagnostic workstation so they '''don't permit side-by side image comparison and use of local hanging protocols''' or viewing tools<br />
* CD/DVD imports/viewers - are often not timely, sometimes do not import reliably, and are "reactive not proactive"<br />
* all suffer from issues with different Patient IDs, procedure codes, etc, questions of long term storage, and some mappings not addressed in IRWF.b. <br />
* radiology reports - there is no primary standard for radiology reports, and as a result, report formats vary dramatically effectively eliminating interoperability of report sharing<br />
<br />
<br />
A solution for this priors problem has been demonstrated to '''also reduce re-scanned patients''' (with cost and radiation implications) due to poor access to studies performed at other institutions.<br />
(Ref: Nagels, J., Macdonald, D. & Coz, C. J Digit Imaging (2017). https://doi.org/10.1007/s10278-017-9963-8)<br />
<br />
==3. Key Use Case==<br />
<br />
'''Order-driven priors:'''<br />
<br />
:* A physician orders a radiology study for a patient<br />
:* The Importer actor searches for prior images <'''MinUE out of scope:''' and reports> for that patient, both locally and beyond<br />
::* The Importer uses PIX/PDQ to get appropriate PIDs for searching<br />
:* The Importer uses order details and local rules to determine which priors are potentially relevant (this profile focuses on specifying metadata availability to enable)<br />
:* The Importer retrieves matching prior images <'''MinUE out of scope''': and reports> executes import logic to map/fix codes and attribute values<br />
:* The Importer stores the imported priors to the local PACS <'''MinUE Out of Scope:''' and Report Manager><br />
:* The radiologist reads the study, accessing all priors using their usual workflow, display, hanging protocols, and image tools<br />
:* Post-interpretation rules (e.g. purging prior images and reports) occur locally<br />
<br />
The Profile supports a variety of image sharing architectures, e.g. centralized archiving for a region or IDN, federated PACS with point-to-point DIMSE access, etc.<br />
<br />
'''The intent is to make the existing, installed base of PACS systems work better without necessitating any changes or upgrades. The burden is centralized in the Importer and Report Converter actors rather than distributed to every sending or receiving system.'''<br />
<br />
<br />
'''Human Version of the Clinical Use Case'''<br />
<br />
Dr. Smith, a radiologist at a busy Cancer Center, is reporting a large number of CT studies which require comparison to previous imaging often performed at remote (but secure network connected) sites in the region, mostly community hospitals, but also academic centres where the patient may have been seen. The radiologist has to evaluate changes over time in order to assess treatment efficiency, with previous performed usually 3 to 6 months earlier. There may be a series of previous studies at the same interval over a period of a few years.<br />
<br />
Dr. Smith needs to report on a lesion’s change in size and appearance, as well as interval development or resolution of other conditions such as metastatic disease, peritoneal seeding or pleural effusions. For accuracy and speed, Dr Smith has to be able to cross-reference his CT slices and MPRs in DICOM format, using his own measurement tools.<br />
<br />
Dr. Smth wants the remote CT(s) to be readily available in his patient folder on his own PACS, and the studies displayed using his hanging protocols. He wants the report to be available the same way he displays previous reports for studies performed in his institution. <br />
<br />
'''The Problem Case Today'''<br />
<br />
Dr. Smith has to access a separate website, maybe with a separate sign-on. He has to search a separate database, he has to wait for images to load, slowing him down through his very busy work day. To make things worse, Dr. Smith has to open two separate web interfaces, one for the images, another one for the report, as the VNA was not be able to move the report with the images. <br />
<br />
Even though studies are all stored on a central VNA or there is access to other DICOM PACS systems, Dr. Smith has to ask the remote site to print a CD/DVD with the images. He then asks his PACS team to upload these images into his local PACS to make sure that images are available when he reports the current study. Not only is this a tedious manual process, but it delays the time the study is reported sometimes up to a few days. And, using the CD/DVD method, it is common that the previous report is not available.<br />
<br />
==4. Standards and Systems==<br />
<br />
'''Real World Systems:'''<br />
:* EMPI (IHE: PIX/PDQ Manager)<br />
:* RIS/EMRs (IHE: SWF.b DSS/OF, Report Manager, Report Reader)<br />
:* VNA or Diagnostic Imaging Repository (DI-r) (IHE: Image Manager, Report Manager, XDS.b Document Registry+ Document Repository+Imaging Document Source, possibly Importer and/or Report Converter)<br />
:* PACS (IHE: Image Manager/Archive, Image Display, Report Manager, Report Reader, possibly Importer and/or Report Converter)<br />
:* Note: the Importer and Report Converter actors may be separate systems, combined with a system above, or combined together - See Deployment options in Volume 1<br />
<br />
<br />
'''Standards:'''<br />
:* IRWF.b - useful importation logic and data mappings (but that IRWF.b is passive and doesn't specify pre and post steps)<br />
:* PIX/PDQ - patient identification<br />
:* MIMA Vol 2 Appendix J - fully qualified Patient ID reconciliation <br />
:* HL7 v2.x ORM/OMI (RAD-4 + IRWF.b data mappings ) - access to orders for new studies at the local site <br />
:* DICOM Q/R and XDS.b-I (RAD-5 and ITI-18) - find images <br />
:* DICOM C-Move and XDS.b-I (RAD-5 and ITI-18) - retrieve images <br />
:* DICOM C-Store - store images locally (default)<br />
:* '''MinUE Out of scope:''' Mobile Health Documents (MHD) -FHIR query documents<br />
:* '''MinUE Out of scope:''' XDS.b retrieve - report retrieval<br />
:* '''MinUE Out of scope:''' HL7 v2.x ORU (RD:RAD-128) - store report locally as TEXT or PDF<br />
<br />
A Cross Profile Consideration section X.6 discusses how DICOMweb services could be integrated in the future for image access and retrieval. Recommend limiting the required transactions on primary installed base (ie., HL7 v2.x, DICOM, XDS.b).<br />
<br />
==5. Discussion==<br />
<br />
The most important discussion is a consistently agreed upon, and not deviated from, definition of SCOPE:<br />
<br />
'''Minimum Useful Effort (MinUE) Baseline scope:''' Complete the current IDEP supplement, but do NOT include:<br />
:* Reports, in any format, not even TEXT or PDF<br />
:* WIA (DICOMweb) query to access prior images (except as reference in Cross Profile Considerations X.6)<br />
:* Retain Importer actor, but remove Report Converter actor and transactions<br />
:* Retain Image Purge and Report Purge as Named Options with no transactions (only defined behavior)<br />
:* Complete the IHE Public Comment and Trial Implementation processes <br />
:* (NOTE: removal of the Report Converter actor will be a SIGNIFICANT amount of effort for the editor and will include many changes to sections which have already been reviewed in detail by the TC).<br />
<br />
'''Maximum Useful Effort (MaxUE) (Additional) Scope for 2018-2019:'''<br />
:* Retain WIA (DICOMweb) query to access prior reports ONLY as reference in Cross Profile Considerations X.6 (no new DICOMweb functionality within IDEP)<br />
:* Only address TEXT and PDF report formats in direct scope in MaxUE<br />
:* Retain all other report formats as Volume 1 Informative Appendix and nothing more in MaxUE<br />
<br />
SEE [https://docs.google.com/spreadsheets/d/1IAKNiKwKHk3kFEs-mByfuvx91riorZv6El2GDjrZmAA/edit?usp=sharing THIS SUMMARY] FOR SPECIFIC STATUS OF EACH SECTION OF CURRENT SUPPLEMENT.<br />
<br />
This is intended to be a Workflow profile with one primary use case and one of two back-end architectures (all-DICOM and XDS.b (XDS.b as named option)): <br />
<br />
'''Workflow steps to be addressed:'''<br />
:* patient identification and PID reconciliation<br />
:* receipt of new orders<br />
:* relevancy logic meta data identification<br />
:* image retrieval <br />
:* DICOM attribute mapping <br />
:* storage of imported image <br />
:* '''MinUE Out of scope:''' report retrieval <br />
:* '''MinUE Out of scope:''' HL7 v2 ORU report attribute mapping <br />
:* '''MinUE Out of scope:'''storage of imported reports <br />
:* local purging of foreign images and foreign reports as defined Option<br />
<br />
<br />
'''Scope/assumptions:''' <br />
<br />
Goal is to enable automated and contextually integrated VIEWING of foreign radiology priors at the local system.<br />
<br />
:* Focus is on simplicity and existing installed base ("old school") - DICOM, HL7 v2.x, and XDS. (not image access using DICOM web services, or storage of reports using FHIR, etc)<br />
:* Secure network already in place between facilities. (Cross- non-affiliated enterprises out of scope.)<br />
:* EMPI (PIX/PDQ) already in place between facilities. <br />
:* Access prior imaging studies using DIMSE DICOM, but have XDS-I as a named Option. This XDS-I option would also include the hybrid DICOM/XDS.b environment since DICOM is the default environment.<br />
:* Storage of imaging study limited to DIMSE DICOM to the local PACS. (ie., not direct XDS import to the local PACS)<br />
:* Other image types such as Raw JPEG, PDF, etc., are out of scope.<br />
:* '''MinUE Out of scope:''' Report formats are limited to TEXT and PDF.<br />
:* '''MinUE Out of scope:''' Access of prior reports is limited to FHIR query for reports.<br />
:* '''MinUE Out of scope:''' Storage of prior reports is limited to HL7 v2.5.1 ORU with TEXT or PDF content.<br />
:* '''MinUE Out of scope:''' Report '''semantic content''' is always out of scope, i.e., structured or unstructured, etc. This could cause non-interoperability (unable to view), but is still out of scope and must be managed locally.<br />
<br />
==5. Technical Approach==<br />
<br />
:* Focus "intelligence" and mapping in new IDEP actors (Importer and Report Converter). Limit changes to ancillary systems.<br />
:* Populate <specific data element>, but stay away from terminology mapping.<br />
:* Default: Define meta data to be able to determine relevancy, but do not define relevancy rules. Server side v. client side filtering. (IDEP would specify client side filtering.)<br />
:* No intention to map procedure codes, study description, etc. Discuss in X.4 Concepts sections.<br />
:* Do not over-specify display requirements; e.g., "Required to display "something" to indicate that it is an external study."<br />
:* Retain WIA for remote image access via web services in Cross Profile Considerations (X.6); but do not explicitly include.<br />
<br />
<br />
===Existing actors===<br />
<br />
* "Local" DSS/OF<br />
* "Local" Image Manager<br />
* ''MinUE Out of scope: "' "Local" Report Manager<br />
* PIX/PDQ Manager<br />
* "Remote" Image Manager <br />
* '''MinUE Out of scope: "' "Remote" Report Manager <br />
* XDS.b Registry<br />
* '''MinUE Out of scope: "' XDS.b Repository<br />
* XDS.b-I Imaging Document Source<br />
<br />
===New actors===<br />
* Importer (same actor as IRWF.b, but additional behaviors)<br />
* Report Converter<br />
<br />
===Existing transactions===<br />
<br />
Because this proposed profiles focuses on improving the functionality of the existing installed base, it focuses on HL7 v2, DICOM DIMSE Services, and XDS.b transactions.<br />
<br />
See IDEP transaction diagram. (ie., many transactions)<br />
<br />
===New transactions (standards used)===<br />
<br />
A new DICOM query (DICOM query transaction proliferation) transaction was written for "Query for Patient Studies".<br />
New mapping tables were created for the (1) Order (OMI) message data for relevancy, (2) Coercion of MHD data for External Prior Reports, and (3) HL7 v2 ORU for External Prior Reports Mapping.<br />
<br />
===Impact on existing integration profiles===<br />
<br />
Some additional behaviour on transactions will be required, but there will be no impact on existing integration profiles.<br />
<br />
===New integration profiles needed===<br />
<br />
None.<br />
<br />
===Breakdown of tasks===<br />
<br />
The high level breakdown of tasks is:<br />
<br />
: 1.) MinUE Baseline or MaxUE scope must be determined and uniformly (and indelibly) agreed to.<br />
: 2.) If MinUE baseline only, editor has a lot of work to do to remove all references to reports (40% of document)<br />
: 3.) Complete internal TC-review prior to Public Comment on un-reviewed sections; obtain vote to proceed to Public Comment.<br />
: 4.) Public comment period<br />
: 5.) Public comment review by TC and incorporation by Editor<br />
: 6.) Internal TC-review and changes by Editor; obtain vote to proceed to Trial Implementation.<br />
<br />
<br />
The specific status of each section is listed in this document:<br />
<br />
==6. Support & Resources==<br />
<br />
Canada Health Infoway has been very active in development of this technology and has implemented it across several broad regions, resulting in real-world data and analytics.<br />
<br />
HCA in the States has expressed in supporting and reviewing a standard to implement the import and display of external priors. HCA's focus is on the proper display of priors for side-by-side comparison in a most useful and effective manner.<br />
<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep to closely related clinical issues such as Emergency Department transfer<br />
:* Scope creep related to incorporating additional report formats beyond TEXT and PDF.<br />
:* Scope creep related to incorporating semantic meaning of reports.<br />
:* Scope creep related to additional methods of image and/or report access or image and/or report storage to local systems.<br />
:* Defining too much logic behind the word "relevant" - vendor/product differentiation; define only mechanisms<br />
:* Legal differences across jurisdictions<br />
<br />
==8. Open Issues==<br />
<br />
See Risks.<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
* 40% for Maximum/Full Effort = imaging and reports (only as HL7 ORU text)<br />
* 25% for Minimum Useful Effort<br />
:* 1.) Select only XDS or DICOM environment<br />
:* 2.) Leave purging out of scope<br />
:* 3.) No reports, even as only an HL7 ORU text, Reports mentioned in X.4 Concepts section - added bolded "Out of scope" note to all references to reports (imaging only)<br />
<br />
Candidate Editor:<br />
: Teri Sippel Schmidt</div>Terisippelhttp://wiki.ihe.net/index.php?title=Import_and_Display_of_External_Priors-_Proposal&diff=110592Import and Display of External Priors- Proposal2018-07-24T23:33:06Z<p>Terisippel: /* 7. Risks */</p>
<hr />
<div>{{TOCright}}<br />
==1. Proposed Workitem: Import and Display of External Priors (IDEP)==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Jonathan Whitby<br />
* Proposal Contributors: David Koff, MD; Canada Health Infoway; Kevin O'Donnell<br />
* Editor: Jonathan Whitby (previously Teri Sippel Schmidt)<br />
* Contributors: David Koff, MD; Canada Health Infoway<br />
* Domain: Radiology<br />
<br />
This proposal was previously called "[[Foreign_Exam_Management_Direct_Import-_Proposal|Foreign Exam Management (FEM)]]".<br />
<br />
==2. The Problem==<br />
<br />
Prior imaging studies provide vital information and context to the radiologist when interpreting a current study, even resulting in a change of diagnosis. A "prefetch" step (to locate prior studies for the patient that may be relevant and make them immediately accessible to the radiologist during review) is common in imaging workflows. This works fairly well for priors that were performed locally, even if they have to be pulled back from longer term storage to be ready for the radiologist. <br />
<br />
Unfortunately, with the mobility of modern healthcare, '''it is very common for priors to be located outside the reading institution'''.<br />
<br />
Although there have been many improvements to the ability to exchange images between enterprises, or between departments within an enterprise, '''the ability to locate, access, and view priors for direct comparison, particularly during the short time frame required for them to be relevant to reading, is still not reliable'''.<br />
* patient portals - are unwieldy, slow to access, and on different monitors<br />
* web-based viewers - are not integrated into the diagnostic workstation so they '''don't permit side-by side image comparison and use of local hanging protocols''' or viewing tools<br />
* CD/DVD imports/viewers - are often not timely, sometimes do not import reliably, and are "reactive not proactive"<br />
* all suffer from issues with different Patient IDs, procedure codes, etc, questions of long term storage, and some mappings not addressed in IRWF.b. <br />
* radiology reports - there is no primary standard for radiology reports, and as a result, report formats vary dramatically effectively eliminating interoperability of report sharing<br />
<br />
<br />
A solution for this priors problem has been demonstrated to '''also reduce re-scanned patients''' (with cost and radiation implications) due to poor access to studies performed at other institutions.<br />
(Ref: Nagels, J., Macdonald, D. & Coz, C. J Digit Imaging (2017). https://doi.org/10.1007/s10278-017-9963-8)<br />
<br />
==3. Key Use Case==<br />
<br />
'''Order-driven priors:'''<br />
<br />
:* A physician orders a radiology study for a patient<br />
:* The Importer actor searches for prior images <'''MinUE out of scope:''' and reports> for that patient, both locally and beyond<br />
::* The Importer uses PIX/PDQ to get appropriate PIDs for searching<br />
:* The Importer uses order details and local rules to determine which priors are potentially relevant (this profile focuses on specifying metadata availability to enable)<br />
:* The Importer retrieves matching prior images <'''MinUE out of scope''': and reports> executes import logic to map/fix codes and attribute values<br />
:* The Importer stores the imported priors to the local PACS <'''MinUE Out of Scope:''' and Report Manager><br />
:* The radiologist reads the study, accessing all priors using their usual workflow, display, hanging protocols, and image tools<br />
:* Post-interpretation rules (e.g. purging prior images and reports) occur locally<br />
<br />
The Profile supports a variety of image sharing architectures, e.g. centralized archiving for a region or IDN, federated PACS with point-to-point DIMSE access, etc.<br />
<br />
'''The intent is to make the existing, installed base of PACS systems work better without necessitating any changes or upgrades. The burden is centralized in the Importer and Report Converter actors rather than distributed to every sending or receiving system.'''<br />
<br />
<br />
'''Human Version of the Clinical Use Case'''<br />
<br />
Dr. Smith, a radiologist at a busy Cancer Center, is reporting a large number of CT studies which require comparison to previous imaging often performed at remote (but secure network connected) sites in the region, mostly community hospitals, but also academic centres where the patient may have been seen. The radiologist has to evaluate changes over time in order to assess treatment efficiency, with previous performed usually 3 to 6 months earlier. There may be a series of previous studies at the same interval over a period of a few years.<br />
<br />
Dr. Smith needs to report on a lesion’s change in size and appearance, as well as interval development or resolution of other conditions such as metastatic disease, peritoneal seeding or pleural effusions. For accuracy and speed, Dr Smith has to be able to cross-reference his CT slices and MPRs in DICOM format, using his own measurement tools.<br />
<br />
Dr. Smth wants the remote CT(s) to be readily available in his patient folder on his own PACS, and the studies displayed using his hanging protocols. He wants the report to be available the same way he displays previous reports for studies performed in his institution. <br />
<br />
'''The Problem Case Today'''<br />
<br />
Dr. Smith has to access a separate website, maybe with a separate sign-on. He has to search a separate database, he has to wait for images to load, slowing him down through his very busy work day. To make things worse, Dr. Smith has to open two separate web interfaces, one for the images, another one for the report, as the VNA was not be able to move the report with the images. <br />
<br />
Even though studies are all stored on a central VNA or there is access to other DICOM PACS systems, Dr. Smith has to ask the remote site to print a CD/DVD with the images. He then asks his PACS team to upload these images into his local PACS to make sure that images are available when he reports the current study. Not only is this a tedious manual process, but it delays the time the study is reported sometimes up to a few days. And, using the CD/DVD method, it is common that the previous report is not available.<br />
<br />
==4. Standards and Systems==<br />
<br />
'''Real World Systems:'''<br />
:* EMPI (IHE: PIX/PDQ Manager)<br />
:* RIS/EMRs (IHE: SWF.b DSS/OF, Report Manager, Report Reader)<br />
:* VNA or Diagnostic Imaging Repository (DI-r) (IHE: Image Manager, Report Manager, XDS.b Document Registry+ Document Repository+Imaging Document Source, possibly Importer and/or Report Converter)<br />
:* PACS (IHE: Image Manager/Archive, Image Display, Report Manager, Report Reader, possibly Importer and/or Report Converter)<br />
:* Note: the Importer and Report Converter actors may be separate systems, combined with a system above, or combined together - See Deployment options in Volume 1<br />
<br />
<br />
'''Standards:'''<br />
:* IRWF.b - useful importation logic and data mappings (but that IRWF.b is passive and doesn't specify pre and post steps)<br />
:* PIX/PDQ - patient identification<br />
:* MIMA Vol 2 Appendix J - fully qualified Patient ID reconciliation <br />
:* HL7 v2.x ORM/OMI (RAD-4 + IRWF.b data mappings ) - access to orders for new studies at the local site <br />
:* DICOM Q/R and XDS.b-I (RAD-5 and ITI-18) - find images <br />
:* DICOM C-Move and XDS.b-I (RAD-5 and ITI-18) - retrieve images <br />
:* DICOM C-Store - store images locally (default)<br />
:* '''MinUE Out of scope:''' Mobile Health Documents (MHD) -FHIR query documents<br />
:* '''MinUE Out of scope:''' XDS.b retrieve - report retrieval<br />
:* '''MinUE Out of scope:''' HL7 v2.x ORU (RD:RAD-128) - store report locally as TEXT or PDF<br />
<br />
A Cross Profile Consideration section X.6 discusses how DICOMweb services could be integrated in the future for image access and retrieval. Recommend limiting the required transactions on primary installed base (ie., HL7 v2.x, DICOM, XDS.b).<br />
<br />
==5. Discussion==<br />
<br />
The most important discussion is a consistently agreed upon, and not deviated from, definition of SCOPE:<br />
<br />
'''Minimum Useful Effort (MinUE) Baseline scope:''' Complete the current IDEP supplement, but do NOT include:<br />
:* Reports, in any format, not even TEXT or PDF<br />
:* WIA (DICOMweb) query to access prior images (except as reference in Cross Profile Considerations X.6)<br />
:* Retain Importer actor, but remove Report Converter actor and transactions<br />
:* Retain Image Purge and Report Purge as Named Options with no transactions (only defined behavior)<br />
:* Complete the IHE Public Comment and Trial Implementation processes <br />
:* (NOTE: removal of the Report Converter actor will be a SIGNIFICANT amount of effort for the editor and will include many changes to sections which have already been reviewed in detail by the TC).<br />
<br />
'''Maximum Useful Effort (MaxUE) (Additional) Scope for 2018-2019:'''<br />
:* Retain WIA (DICOMweb) query to access prior reports ONLY as reference in Cross Profile Considerations X.6 (no new DICOMweb functionality within IDEP)<br />
:* Only address TEXT and PDF report formats in direct scope in MaxUE<br />
:* Retain all other report formats as Volume 1 Informative Appendix and nothing more in MaxUE<br />
<br />
SEE [https://docs.google.com/spreadsheets/d/1IAKNiKwKHk3kFEs-mByfuvx91riorZv6El2GDjrZmAA/edit?usp=sharing THIS SUMMARY] FOR SPECIFIC STATUS OF EACH SECTION OF CURRENT SUPPLEMENT.<br />
<br />
This is intended to be a Workflow profile with one primary use case and one of two back-end architectures (all-DICOM and XDS.b (XDS.b as named option)): <br />
<br />
'''Workflow steps to be addressed:'''<br />
:* patient identification and PID reconciliation<br />
:* receipt of new orders<br />
:* relevancy logic meta data identification<br />
:* image retrieval <br />
:* DICOM attribute mapping <br />
:* storage of imported image <br />
:* '''MinUE Out of scope:''' report retrieval <br />
:* '''MinUE Out of scope:''' HL7 v2 ORU report attribute mapping <br />
:* '''MinUE Out of scope:'''storage of imported reports <br />
:* local purging of foreign images and foreign reports as defined Option<br />
<br />
<br />
'''Scope/assumptions:''' <br />
<br />
Goal is to enable automated and contextually integrated VIEWING of foreign radiology priors at the local system.<br />
<br />
:* Focus is on simplicity and existing installed base ("old school") - DICOM, HL7 v2.x, and XDS. (not image access using DICOM web services, or storage of reports using FHIR, etc)<br />
:* Secure network already in place between facilities. (Cross- non-affiliated enterprises out of scope.)<br />
:* EMPI (PIX/PDQ) already in place between facilities. <br />
:* Access prior imaging studies using DIMSE DICOM, but have XDS-I as a named Option. This XDS-I option would also include the hybrid DICOM/XDS.b environment since DICOM is the default environment.<br />
:* Storage of imaging study limited to DIMSE DICOM to the local PACS. (ie., not direct XDS import to the local PACS)<br />
:* Other image types such as Raw JPEG, PDF, etc., are out of scope.<br />
:* '''MinUE Out of scope:''' Report formats are limited to TEXT and PDF.<br />
:* '''MinUE Out of scope:''' Access of prior reports is limited to FHIR query for reports.<br />
:* '''MinUE Out of scope:''' Storage of prior reports is limited to HL7 v2.5.1 ORU with TEXT or PDF content.<br />
:* '''MinUE Out of scope:''' Report '''semantic content''' is always out of scope, i.e., structured or unstructured, etc. This could cause non-interoperability (unable to view), but is still out of scope and must be managed locally.<br />
<br />
==5. Technical Approach==<br />
<br />
:* Focus "intelligence" and mapping in new IDEP actors (Importer and Report Converter). Limit changes to ancillary systems.<br />
:* Populate <specific data element>, but stay away from terminology mapping.<br />
:* Default: Define meta data to be able to determine relevancy, but do not define relevancy rules. Server side v. client side filtering. (IDEP would specify client side filtering.)<br />
:* No intention to map procedure codes, study description, etc. Discuss in X.4 Concepts sections.<br />
:* Do not over-specify display requirements; e.g., "Required to display "something" to indicate that it is an external study."<br />
:* Retain WIA for remote image access via web services in Cross Profile Considerations (X.6); but do not explicitly include.<br />
<br />
<br />
===Existing actors===<br />
<br />
* "Local" DSS/OF<br />
* "Local" Image Manager<br />
* ''MinUE Out of scope: "' "Local" Report Manager<br />
* PIX/PDQ Manager<br />
* "Remote" Image Manager <br />
* '''MinUE Out of scope: "' "Remote" Report Manager <br />
* XDS.b Registry<br />
* '''MinUE Out of scope: "' XDS.b Repository<br />
* XDS.b-I Imaging Document Source<br />
<br />
===New actors===<br />
* Importer (same actor as IRWF.b, but additional behaviors)<br />
* Report Converter<br />
<br />
===Existing transactions===<br />
<br />
Because this proposed profiles focuses on improving the functionality of the existing installed base, it focuses on HL7 v2, DICOM DIMSE Services, and XDS.b transactions.<br />
<br />
See IDEP transaction diagram. (ie., many transactions)<br />
<br />
===New transactions (standards used)===<br />
<br />
A new DICOM query (DICOM query transaction proliferation) transaction was written for "Query for Patient Studies".<br />
New mapping tables were created for the (1) Order (OMI) message data for relevancy, (2) Coercion of MHD data for External Prior Reports, and (3) HL7 v2 ORU for External Prior Reports Mapping.<br />
<br />
===Impact on existing integration profiles===<br />
<br />
Some additional behaviour on transactions will be required, but there will be no impact on existing integration profiles.<br />
<br />
===New integration profiles needed===<br />
<br />
None.<br />
<br />
===Breakdown of tasks===<br />
<br />
The high level breakdown of tasks is:<br />
<br />
: 1.) MinUE Baseline or MaxUE scope must be determined and uniformly (and indelibly) agreed to.<br />
: 2.) If MinUE baseline only, editor has a lot of work to do to remove all references to reports (40% of document)<br />
: 3.) Complete internal TC-review prior to Public Comment on un-reviewed sections; obtain vote to proceed to Public Comment.<br />
: 4.) Public comment period<br />
: 5.) Public comment review by TC and incorporation by Editor<br />
: 6.) Internal TC-review and changes by Editor; obtain vote to proceed to Trial Implementation.<br />
<br />
<br />
The specific status of each section is listed in this document:<br />
<br />
==6. Support & Resources==<br />
<br />
Canada Health Infoway has been very active in development of this technology and has implemented it across several broad regions, resulting in real-world data and analytics.<br />
<br />
HCA in the States has expressed in supporting and reviewing a standard to implement the import and display of external priors. HCA's focus is on the proper display of priors for side-by-side comparison in a most useful and effective manner.<br />
<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep to closely related clinical issues such as ED transfer<br />
:* Scope creep related to incorporating additional report formats beyond TEXT and PDF.<br />
:* Scope creep related to incorporating semantic meaning of reports.<br />
:* Scope creep related to additional methods of image and/or report access or image and/or report storage to local systems.<br />
:* Defining too much logic behind the word "relevant" - vendor/product differentiation; define only mechanisms<br />
:* Legal differences across jurisdictions<br />
<br />
==8. Open Issues==<br />
<br />
See Risks.<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
* 40% for Maximum/Full Effort = imaging and reports (only as HL7 ORU text)<br />
* 25% for Minimum Useful Effort<br />
:* 1.) Select only XDS or DICOM environment<br />
:* 2.) Leave purging out of scope<br />
:* 3.) No reports, even as only an HL7 ORU text, Reports mentioned in X.4 Concepts section - added bolded "Out of scope" note to all references to reports (imaging only)<br />
<br />
Candidate Editor:<br />
: Teri Sippel Schmidt</div>Terisippelhttp://wiki.ihe.net/index.php?title=Import_and_Display_of_External_Priors-_Proposal&diff=110591Import and Display of External Priors- Proposal2018-07-24T23:31:00Z<p>Terisippel: /* New transactions (standards used) */</p>
<hr />
<div>{{TOCright}}<br />
==1. Proposed Workitem: Import and Display of External Priors (IDEP)==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Jonathan Whitby<br />
* Proposal Contributors: David Koff, MD; Canada Health Infoway; Kevin O'Donnell<br />
* Editor: Jonathan Whitby (previously Teri Sippel Schmidt)<br />
* Contributors: David Koff, MD; Canada Health Infoway<br />
* Domain: Radiology<br />
<br />
This proposal was previously called "[[Foreign_Exam_Management_Direct_Import-_Proposal|Foreign Exam Management (FEM)]]".<br />
<br />
==2. The Problem==<br />
<br />
Prior imaging studies provide vital information and context to the radiologist when interpreting a current study, even resulting in a change of diagnosis. A "prefetch" step (to locate prior studies for the patient that may be relevant and make them immediately accessible to the radiologist during review) is common in imaging workflows. This works fairly well for priors that were performed locally, even if they have to be pulled back from longer term storage to be ready for the radiologist. <br />
<br />
Unfortunately, with the mobility of modern healthcare, '''it is very common for priors to be located outside the reading institution'''.<br />
<br />
Although there have been many improvements to the ability to exchange images between enterprises, or between departments within an enterprise, '''the ability to locate, access, and view priors for direct comparison, particularly during the short time frame required for them to be relevant to reading, is still not reliable'''.<br />
* patient portals - are unwieldy, slow to access, and on different monitors<br />
* web-based viewers - are not integrated into the diagnostic workstation so they '''don't permit side-by side image comparison and use of local hanging protocols''' or viewing tools<br />
* CD/DVD imports/viewers - are often not timely, sometimes do not import reliably, and are "reactive not proactive"<br />
* all suffer from issues with different Patient IDs, procedure codes, etc, questions of long term storage, and some mappings not addressed in IRWF.b. <br />
* radiology reports - there is no primary standard for radiology reports, and as a result, report formats vary dramatically effectively eliminating interoperability of report sharing<br />
<br />
<br />
A solution for this priors problem has been demonstrated to '''also reduce re-scanned patients''' (with cost and radiation implications) due to poor access to studies performed at other institutions.<br />
(Ref: Nagels, J., Macdonald, D. & Coz, C. J Digit Imaging (2017). https://doi.org/10.1007/s10278-017-9963-8)<br />
<br />
==3. Key Use Case==<br />
<br />
'''Order-driven priors:'''<br />
<br />
:* A physician orders a radiology study for a patient<br />
:* The Importer actor searches for prior images <'''MinUE out of scope:''' and reports> for that patient, both locally and beyond<br />
::* The Importer uses PIX/PDQ to get appropriate PIDs for searching<br />
:* The Importer uses order details and local rules to determine which priors are potentially relevant (this profile focuses on specifying metadata availability to enable)<br />
:* The Importer retrieves matching prior images <'''MinUE out of scope''': and reports> executes import logic to map/fix codes and attribute values<br />
:* The Importer stores the imported priors to the local PACS <'''MinUE Out of Scope:''' and Report Manager><br />
:* The radiologist reads the study, accessing all priors using their usual workflow, display, hanging protocols, and image tools<br />
:* Post-interpretation rules (e.g. purging prior images and reports) occur locally<br />
<br />
The Profile supports a variety of image sharing architectures, e.g. centralized archiving for a region or IDN, federated PACS with point-to-point DIMSE access, etc.<br />
<br />
'''The intent is to make the existing, installed base of PACS systems work better without necessitating any changes or upgrades. The burden is centralized in the Importer and Report Converter actors rather than distributed to every sending or receiving system.'''<br />
<br />
<br />
'''Human Version of the Clinical Use Case'''<br />
<br />
Dr. Smith, a radiologist at a busy Cancer Center, is reporting a large number of CT studies which require comparison to previous imaging often performed at remote (but secure network connected) sites in the region, mostly community hospitals, but also academic centres where the patient may have been seen. The radiologist has to evaluate changes over time in order to assess treatment efficiency, with previous performed usually 3 to 6 months earlier. There may be a series of previous studies at the same interval over a period of a few years.<br />
<br />
Dr. Smith needs to report on a lesion’s change in size and appearance, as well as interval development or resolution of other conditions such as metastatic disease, peritoneal seeding or pleural effusions. For accuracy and speed, Dr Smith has to be able to cross-reference his CT slices and MPRs in DICOM format, using his own measurement tools.<br />
<br />
Dr. Smth wants the remote CT(s) to be readily available in his patient folder on his own PACS, and the studies displayed using his hanging protocols. He wants the report to be available the same way he displays previous reports for studies performed in his institution. <br />
<br />
'''The Problem Case Today'''<br />
<br />
Dr. Smith has to access a separate website, maybe with a separate sign-on. He has to search a separate database, he has to wait for images to load, slowing him down through his very busy work day. To make things worse, Dr. Smith has to open two separate web interfaces, one for the images, another one for the report, as the VNA was not be able to move the report with the images. <br />
<br />
Even though studies are all stored on a central VNA or there is access to other DICOM PACS systems, Dr. Smith has to ask the remote site to print a CD/DVD with the images. He then asks his PACS team to upload these images into his local PACS to make sure that images are available when he reports the current study. Not only is this a tedious manual process, but it delays the time the study is reported sometimes up to a few days. And, using the CD/DVD method, it is common that the previous report is not available.<br />
<br />
==4. Standards and Systems==<br />
<br />
'''Real World Systems:'''<br />
:* EMPI (IHE: PIX/PDQ Manager)<br />
:* RIS/EMRs (IHE: SWF.b DSS/OF, Report Manager, Report Reader)<br />
:* VNA or Diagnostic Imaging Repository (DI-r) (IHE: Image Manager, Report Manager, XDS.b Document Registry+ Document Repository+Imaging Document Source, possibly Importer and/or Report Converter)<br />
:* PACS (IHE: Image Manager/Archive, Image Display, Report Manager, Report Reader, possibly Importer and/or Report Converter)<br />
:* Note: the Importer and Report Converter actors may be separate systems, combined with a system above, or combined together - See Deployment options in Volume 1<br />
<br />
<br />
'''Standards:'''<br />
:* IRWF.b - useful importation logic and data mappings (but that IRWF.b is passive and doesn't specify pre and post steps)<br />
:* PIX/PDQ - patient identification<br />
:* MIMA Vol 2 Appendix J - fully qualified Patient ID reconciliation <br />
:* HL7 v2.x ORM/OMI (RAD-4 + IRWF.b data mappings ) - access to orders for new studies at the local site <br />
:* DICOM Q/R and XDS.b-I (RAD-5 and ITI-18) - find images <br />
:* DICOM C-Move and XDS.b-I (RAD-5 and ITI-18) - retrieve images <br />
:* DICOM C-Store - store images locally (default)<br />
:* '''MinUE Out of scope:''' Mobile Health Documents (MHD) -FHIR query documents<br />
:* '''MinUE Out of scope:''' XDS.b retrieve - report retrieval<br />
:* '''MinUE Out of scope:''' HL7 v2.x ORU (RD:RAD-128) - store report locally as TEXT or PDF<br />
<br />
A Cross Profile Consideration section X.6 discusses how DICOMweb services could be integrated in the future for image access and retrieval. Recommend limiting the required transactions on primary installed base (ie., HL7 v2.x, DICOM, XDS.b).<br />
<br />
==5. Discussion==<br />
<br />
The most important discussion is a consistently agreed upon, and not deviated from, definition of SCOPE:<br />
<br />
'''Minimum Useful Effort (MinUE) Baseline scope:''' Complete the current IDEP supplement, but do NOT include:<br />
:* Reports, in any format, not even TEXT or PDF<br />
:* WIA (DICOMweb) query to access prior images (except as reference in Cross Profile Considerations X.6)<br />
:* Retain Importer actor, but remove Report Converter actor and transactions<br />
:* Retain Image Purge and Report Purge as Named Options with no transactions (only defined behavior)<br />
:* Complete the IHE Public Comment and Trial Implementation processes <br />
:* (NOTE: removal of the Report Converter actor will be a SIGNIFICANT amount of effort for the editor and will include many changes to sections which have already been reviewed in detail by the TC).<br />
<br />
'''Maximum Useful Effort (MaxUE) (Additional) Scope for 2018-2019:'''<br />
:* Retain WIA (DICOMweb) query to access prior reports ONLY as reference in Cross Profile Considerations X.6 (no new DICOMweb functionality within IDEP)<br />
:* Only address TEXT and PDF report formats in direct scope in MaxUE<br />
:* Retain all other report formats as Volume 1 Informative Appendix and nothing more in MaxUE<br />
<br />
SEE [https://docs.google.com/spreadsheets/d/1IAKNiKwKHk3kFEs-mByfuvx91riorZv6El2GDjrZmAA/edit?usp=sharing THIS SUMMARY] FOR SPECIFIC STATUS OF EACH SECTION OF CURRENT SUPPLEMENT.<br />
<br />
This is intended to be a Workflow profile with one primary use case and one of two back-end architectures (all-DICOM and XDS.b (XDS.b as named option)): <br />
<br />
'''Workflow steps to be addressed:'''<br />
:* patient identification and PID reconciliation<br />
:* receipt of new orders<br />
:* relevancy logic meta data identification<br />
:* image retrieval <br />
:* DICOM attribute mapping <br />
:* storage of imported image <br />
:* '''MinUE Out of scope:''' report retrieval <br />
:* '''MinUE Out of scope:''' HL7 v2 ORU report attribute mapping <br />
:* '''MinUE Out of scope:'''storage of imported reports <br />
:* local purging of foreign images and foreign reports as defined Option<br />
<br />
<br />
'''Scope/assumptions:''' <br />
<br />
Goal is to enable automated and contextually integrated VIEWING of foreign radiology priors at the local system.<br />
<br />
:* Focus is on simplicity and existing installed base ("old school") - DICOM, HL7 v2.x, and XDS. (not image access using DICOM web services, or storage of reports using FHIR, etc)<br />
:* Secure network already in place between facilities. (Cross- non-affiliated enterprises out of scope.)<br />
:* EMPI (PIX/PDQ) already in place between facilities. <br />
:* Access prior imaging studies using DIMSE DICOM, but have XDS-I as a named Option. This XDS-I option would also include the hybrid DICOM/XDS.b environment since DICOM is the default environment.<br />
:* Storage of imaging study limited to DIMSE DICOM to the local PACS. (ie., not direct XDS import to the local PACS)<br />
:* Other image types such as Raw JPEG, PDF, etc., are out of scope.<br />
:* '''MinUE Out of scope:''' Report formats are limited to TEXT and PDF.<br />
:* '''MinUE Out of scope:''' Access of prior reports is limited to FHIR query for reports.<br />
:* '''MinUE Out of scope:''' Storage of prior reports is limited to HL7 v2.5.1 ORU with TEXT or PDF content.<br />
:* '''MinUE Out of scope:''' Report '''semantic content''' is always out of scope, i.e., structured or unstructured, etc. This could cause non-interoperability (unable to view), but is still out of scope and must be managed locally.<br />
<br />
==5. Technical Approach==<br />
<br />
:* Focus "intelligence" and mapping in new IDEP actors (Importer and Report Converter). Limit changes to ancillary systems.<br />
:* Populate <specific data element>, but stay away from terminology mapping.<br />
:* Default: Define meta data to be able to determine relevancy, but do not define relevancy rules. Server side v. client side filtering. (IDEP would specify client side filtering.)<br />
:* No intention to map procedure codes, study description, etc. Discuss in X.4 Concepts sections.<br />
:* Do not over-specify display requirements; e.g., "Required to display "something" to indicate that it is an external study."<br />
:* Retain WIA for remote image access via web services in Cross Profile Considerations (X.6); but do not explicitly include.<br />
<br />
<br />
===Existing actors===<br />
<br />
* "Local" DSS/OF<br />
* "Local" Image Manager<br />
* ''MinUE Out of scope: "' "Local" Report Manager<br />
* PIX/PDQ Manager<br />
* "Remote" Image Manager <br />
* '''MinUE Out of scope: "' "Remote" Report Manager <br />
* XDS.b Registry<br />
* '''MinUE Out of scope: "' XDS.b Repository<br />
* XDS.b-I Imaging Document Source<br />
<br />
===New actors===<br />
* Importer (same actor as IRWF.b, but additional behaviors)<br />
* Report Converter<br />
<br />
===Existing transactions===<br />
<br />
Because this proposed profiles focuses on improving the functionality of the existing installed base, it focuses on HL7 v2, DICOM DIMSE Services, and XDS.b transactions.<br />
<br />
See IDEP transaction diagram. (ie., many transactions)<br />
<br />
===New transactions (standards used)===<br />
<br />
A new DICOM query (DICOM query transaction proliferation) transaction was written for "Query for Patient Studies".<br />
New mapping tables were created for the (1) Order (OMI) message data for relevancy, (2) Coercion of MHD data for External Prior Reports, and (3) HL7 v2 ORU for External Prior Reports Mapping.<br />
<br />
===Impact on existing integration profiles===<br />
<br />
Some additional behaviour on transactions will be required, but there will be no impact on existing integration profiles.<br />
<br />
===New integration profiles needed===<br />
<br />
None.<br />
<br />
===Breakdown of tasks===<br />
<br />
The high level breakdown of tasks is:<br />
<br />
: 1.) MinUE Baseline or MaxUE scope must be determined and uniformly (and indelibly) agreed to.<br />
: 2.) If MinUE baseline only, editor has a lot of work to do to remove all references to reports (40% of document)<br />
: 3.) Complete internal TC-review prior to Public Comment on un-reviewed sections; obtain vote to proceed to Public Comment.<br />
: 4.) Public comment period<br />
: 5.) Public comment review by TC and incorporation by Editor<br />
: 6.) Internal TC-review and changes by Editor; obtain vote to proceed to Trial Implementation.<br />
<br />
<br />
The specific status of each section is listed in this document:<br />
<br />
==6. Support & Resources==<br />
<br />
Canada Health Infoway has been very active in development of this technology and has implemented it across several broad regions, resulting in real-world data and analytics.<br />
<br />
HCA in the States has expressed in supporting and reviewing a standard to implement the import and display of external priors. HCA's focus is on the proper display of priors for side-by-side comparison in a most useful and effective manner.<br />
<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep to closely related clinical issues such as ED transfer<br />
:* '''Out of scope:''' Selecting too many report meta data formats to incorporate<br />
:* Defining too much logic behind the word "relevant" - vendor/product differentiation; define only mechanisms<br />
:* Legal differences across jurisdictions<br />
<br />
==8. Open Issues==<br />
<br />
See Risks.<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
* 40% for Maximum/Full Effort = imaging and reports (only as HL7 ORU text)<br />
* 25% for Minimum Useful Effort<br />
:* 1.) Select only XDS or DICOM environment<br />
:* 2.) Leave purging out of scope<br />
:* 3.) No reports, even as only an HL7 ORU text, Reports mentioned in X.4 Concepts section - added bolded "Out of scope" note to all references to reports (imaging only)<br />
<br />
Candidate Editor:<br />
: Teri Sippel Schmidt</div>Terisippelhttp://wiki.ihe.net/index.php?title=Import_and_Display_of_External_Priors-_Proposal&diff=110590Import and Display of External Priors- Proposal2018-07-24T23:27:17Z<p>Terisippel: /* Existing transactions */</p>
<hr />
<div>{{TOCright}}<br />
==1. Proposed Workitem: Import and Display of External Priors (IDEP)==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Jonathan Whitby<br />
* Proposal Contributors: David Koff, MD; Canada Health Infoway; Kevin O'Donnell<br />
* Editor: Jonathan Whitby (previously Teri Sippel Schmidt)<br />
* Contributors: David Koff, MD; Canada Health Infoway<br />
* Domain: Radiology<br />
<br />
This proposal was previously called "[[Foreign_Exam_Management_Direct_Import-_Proposal|Foreign Exam Management (FEM)]]".<br />
<br />
==2. The Problem==<br />
<br />
Prior imaging studies provide vital information and context to the radiologist when interpreting a current study, even resulting in a change of diagnosis. A "prefetch" step (to locate prior studies for the patient that may be relevant and make them immediately accessible to the radiologist during review) is common in imaging workflows. This works fairly well for priors that were performed locally, even if they have to be pulled back from longer term storage to be ready for the radiologist. <br />
<br />
Unfortunately, with the mobility of modern healthcare, '''it is very common for priors to be located outside the reading institution'''.<br />
<br />
Although there have been many improvements to the ability to exchange images between enterprises, or between departments within an enterprise, '''the ability to locate, access, and view priors for direct comparison, particularly during the short time frame required for them to be relevant to reading, is still not reliable'''.<br />
* patient portals - are unwieldy, slow to access, and on different monitors<br />
* web-based viewers - are not integrated into the diagnostic workstation so they '''don't permit side-by side image comparison and use of local hanging protocols''' or viewing tools<br />
* CD/DVD imports/viewers - are often not timely, sometimes do not import reliably, and are "reactive not proactive"<br />
* all suffer from issues with different Patient IDs, procedure codes, etc, questions of long term storage, and some mappings not addressed in IRWF.b. <br />
* radiology reports - there is no primary standard for radiology reports, and as a result, report formats vary dramatically effectively eliminating interoperability of report sharing<br />
<br />
<br />
A solution for this priors problem has been demonstrated to '''also reduce re-scanned patients''' (with cost and radiation implications) due to poor access to studies performed at other institutions.<br />
(Ref: Nagels, J., Macdonald, D. & Coz, C. J Digit Imaging (2017). https://doi.org/10.1007/s10278-017-9963-8)<br />
<br />
==3. Key Use Case==<br />
<br />
'''Order-driven priors:'''<br />
<br />
:* A physician orders a radiology study for a patient<br />
:* The Importer actor searches for prior images <'''MinUE out of scope:''' and reports> for that patient, both locally and beyond<br />
::* The Importer uses PIX/PDQ to get appropriate PIDs for searching<br />
:* The Importer uses order details and local rules to determine which priors are potentially relevant (this profile focuses on specifying metadata availability to enable)<br />
:* The Importer retrieves matching prior images <'''MinUE out of scope''': and reports> executes import logic to map/fix codes and attribute values<br />
:* The Importer stores the imported priors to the local PACS <'''MinUE Out of Scope:''' and Report Manager><br />
:* The radiologist reads the study, accessing all priors using their usual workflow, display, hanging protocols, and image tools<br />
:* Post-interpretation rules (e.g. purging prior images and reports) occur locally<br />
<br />
The Profile supports a variety of image sharing architectures, e.g. centralized archiving for a region or IDN, federated PACS with point-to-point DIMSE access, etc.<br />
<br />
'''The intent is to make the existing, installed base of PACS systems work better without necessitating any changes or upgrades. The burden is centralized in the Importer and Report Converter actors rather than distributed to every sending or receiving system.'''<br />
<br />
<br />
'''Human Version of the Clinical Use Case'''<br />
<br />
Dr. Smith, a radiologist at a busy Cancer Center, is reporting a large number of CT studies which require comparison to previous imaging often performed at remote (but secure network connected) sites in the region, mostly community hospitals, but also academic centres where the patient may have been seen. The radiologist has to evaluate changes over time in order to assess treatment efficiency, with previous performed usually 3 to 6 months earlier. There may be a series of previous studies at the same interval over a period of a few years.<br />
<br />
Dr. Smith needs to report on a lesion’s change in size and appearance, as well as interval development or resolution of other conditions such as metastatic disease, peritoneal seeding or pleural effusions. For accuracy and speed, Dr Smith has to be able to cross-reference his CT slices and MPRs in DICOM format, using his own measurement tools.<br />
<br />
Dr. Smth wants the remote CT(s) to be readily available in his patient folder on his own PACS, and the studies displayed using his hanging protocols. He wants the report to be available the same way he displays previous reports for studies performed in his institution. <br />
<br />
'''The Problem Case Today'''<br />
<br />
Dr. Smith has to access a separate website, maybe with a separate sign-on. He has to search a separate database, he has to wait for images to load, slowing him down through his very busy work day. To make things worse, Dr. Smith has to open two separate web interfaces, one for the images, another one for the report, as the VNA was not be able to move the report with the images. <br />
<br />
Even though studies are all stored on a central VNA or there is access to other DICOM PACS systems, Dr. Smith has to ask the remote site to print a CD/DVD with the images. He then asks his PACS team to upload these images into his local PACS to make sure that images are available when he reports the current study. Not only is this a tedious manual process, but it delays the time the study is reported sometimes up to a few days. And, using the CD/DVD method, it is common that the previous report is not available.<br />
<br />
==4. Standards and Systems==<br />
<br />
'''Real World Systems:'''<br />
:* EMPI (IHE: PIX/PDQ Manager)<br />
:* RIS/EMRs (IHE: SWF.b DSS/OF, Report Manager, Report Reader)<br />
:* VNA or Diagnostic Imaging Repository (DI-r) (IHE: Image Manager, Report Manager, XDS.b Document Registry+ Document Repository+Imaging Document Source, possibly Importer and/or Report Converter)<br />
:* PACS (IHE: Image Manager/Archive, Image Display, Report Manager, Report Reader, possibly Importer and/or Report Converter)<br />
:* Note: the Importer and Report Converter actors may be separate systems, combined with a system above, or combined together - See Deployment options in Volume 1<br />
<br />
<br />
'''Standards:'''<br />
:* IRWF.b - useful importation logic and data mappings (but that IRWF.b is passive and doesn't specify pre and post steps)<br />
:* PIX/PDQ - patient identification<br />
:* MIMA Vol 2 Appendix J - fully qualified Patient ID reconciliation <br />
:* HL7 v2.x ORM/OMI (RAD-4 + IRWF.b data mappings ) - access to orders for new studies at the local site <br />
:* DICOM Q/R and XDS.b-I (RAD-5 and ITI-18) - find images <br />
:* DICOM C-Move and XDS.b-I (RAD-5 and ITI-18) - retrieve images <br />
:* DICOM C-Store - store images locally (default)<br />
:* '''MinUE Out of scope:''' Mobile Health Documents (MHD) -FHIR query documents<br />
:* '''MinUE Out of scope:''' XDS.b retrieve - report retrieval<br />
:* '''MinUE Out of scope:''' HL7 v2.x ORU (RD:RAD-128) - store report locally as TEXT or PDF<br />
<br />
A Cross Profile Consideration section X.6 discusses how DICOMweb services could be integrated in the future for image access and retrieval. Recommend limiting the required transactions on primary installed base (ie., HL7 v2.x, DICOM, XDS.b).<br />
<br />
==5. Discussion==<br />
<br />
The most important discussion is a consistently agreed upon, and not deviated from, definition of SCOPE:<br />
<br />
'''Minimum Useful Effort (MinUE) Baseline scope:''' Complete the current IDEP supplement, but do NOT include:<br />
:* Reports, in any format, not even TEXT or PDF<br />
:* WIA (DICOMweb) query to access prior images (except as reference in Cross Profile Considerations X.6)<br />
:* Retain Importer actor, but remove Report Converter actor and transactions<br />
:* Retain Image Purge and Report Purge as Named Options with no transactions (only defined behavior)<br />
:* Complete the IHE Public Comment and Trial Implementation processes <br />
:* (NOTE: removal of the Report Converter actor will be a SIGNIFICANT amount of effort for the editor and will include many changes to sections which have already been reviewed in detail by the TC).<br />
<br />
'''Maximum Useful Effort (MaxUE) (Additional) Scope for 2018-2019:'''<br />
:* Retain WIA (DICOMweb) query to access prior reports ONLY as reference in Cross Profile Considerations X.6 (no new DICOMweb functionality within IDEP)<br />
:* Only address TEXT and PDF report formats in direct scope in MaxUE<br />
:* Retain all other report formats as Volume 1 Informative Appendix and nothing more in MaxUE<br />
<br />
SEE [https://docs.google.com/spreadsheets/d/1IAKNiKwKHk3kFEs-mByfuvx91riorZv6El2GDjrZmAA/edit?usp=sharing THIS SUMMARY] FOR SPECIFIC STATUS OF EACH SECTION OF CURRENT SUPPLEMENT.<br />
<br />
This is intended to be a Workflow profile with one primary use case and one of two back-end architectures (all-DICOM and XDS.b (XDS.b as named option)): <br />
<br />
'''Workflow steps to be addressed:'''<br />
:* patient identification and PID reconciliation<br />
:* receipt of new orders<br />
:* relevancy logic meta data identification<br />
:* image retrieval <br />
:* DICOM attribute mapping <br />
:* storage of imported image <br />
:* '''MinUE Out of scope:''' report retrieval <br />
:* '''MinUE Out of scope:''' HL7 v2 ORU report attribute mapping <br />
:* '''MinUE Out of scope:'''storage of imported reports <br />
:* local purging of foreign images and foreign reports as defined Option<br />
<br />
<br />
'''Scope/assumptions:''' <br />
<br />
Goal is to enable automated and contextually integrated VIEWING of foreign radiology priors at the local system.<br />
<br />
:* Focus is on simplicity and existing installed base ("old school") - DICOM, HL7 v2.x, and XDS. (not image access using DICOM web services, or storage of reports using FHIR, etc)<br />
:* Secure network already in place between facilities. (Cross- non-affiliated enterprises out of scope.)<br />
:* EMPI (PIX/PDQ) already in place between facilities. <br />
:* Access prior imaging studies using DIMSE DICOM, but have XDS-I as a named Option. This XDS-I option would also include the hybrid DICOM/XDS.b environment since DICOM is the default environment.<br />
:* Storage of imaging study limited to DIMSE DICOM to the local PACS. (ie., not direct XDS import to the local PACS)<br />
:* Other image types such as Raw JPEG, PDF, etc., are out of scope.<br />
:* '''MinUE Out of scope:''' Report formats are limited to TEXT and PDF.<br />
:* '''MinUE Out of scope:''' Access of prior reports is limited to FHIR query for reports.<br />
:* '''MinUE Out of scope:''' Storage of prior reports is limited to HL7 v2.5.1 ORU with TEXT or PDF content.<br />
:* '''MinUE Out of scope:''' Report '''semantic content''' is always out of scope, i.e., structured or unstructured, etc. This could cause non-interoperability (unable to view), but is still out of scope and must be managed locally.<br />
<br />
==5. Technical Approach==<br />
<br />
:* Focus "intelligence" and mapping in new IDEP actors (Importer and Report Converter). Limit changes to ancillary systems.<br />
:* Populate <specific data element>, but stay away from terminology mapping.<br />
:* Default: Define meta data to be able to determine relevancy, but do not define relevancy rules. Server side v. client side filtering. (IDEP would specify client side filtering.)<br />
:* No intention to map procedure codes, study description, etc. Discuss in X.4 Concepts sections.<br />
:* Do not over-specify display requirements; e.g., "Required to display "something" to indicate that it is an external study."<br />
:* Retain WIA for remote image access via web services in Cross Profile Considerations (X.6); but do not explicitly include.<br />
<br />
<br />
===Existing actors===<br />
<br />
* "Local" DSS/OF<br />
* "Local" Image Manager<br />
* ''MinUE Out of scope: "' "Local" Report Manager<br />
* PIX/PDQ Manager<br />
* "Remote" Image Manager <br />
* '''MinUE Out of scope: "' "Remote" Report Manager <br />
* XDS.b Registry<br />
* '''MinUE Out of scope: "' XDS.b Repository<br />
* XDS.b-I Imaging Document Source<br />
<br />
===New actors===<br />
* Importer (same actor as IRWF.b, but additional behaviors)<br />
* Report Converter<br />
<br />
===Existing transactions===<br />
<br />
Because this proposed profiles focuses on improving the functionality of the existing installed base, it focuses on HL7 v2, DICOM DIMSE Services, and XDS.b transactions.<br />
<br />
See IDEP transaction diagram. (ie., many transactions)<br />
<br />
===New transactions (standards used)===<br />
<br />
It is not clear that any new transactions will be necessary.<br />
Additional behaviour may be required on existing actors in existing transactions in the Expected Actions section.<br />
'''Out of scope:''' Additional data mappings will be required, especially for report conversions, if we decide to include that within scope.<br />
<br />
===Impact on existing integration profiles===<br />
<br />
Some additional behaviour on transactions will be required, but there will be no impact on existing integration profiles.<br />
<br />
===New integration profiles needed===<br />
<br />
None.<br />
<br />
===Breakdown of tasks===<br />
<br />
The high level breakdown of tasks is:<br />
<br />
: 1.) MinUE Baseline or MaxUE scope must be determined and uniformly (and indelibly) agreed to.<br />
: 2.) If MinUE baseline only, editor has a lot of work to do to remove all references to reports (40% of document)<br />
: 3.) Complete internal TC-review prior to Public Comment on un-reviewed sections; obtain vote to proceed to Public Comment.<br />
: 4.) Public comment period<br />
: 5.) Public comment review by TC and incorporation by Editor<br />
: 6.) Internal TC-review and changes by Editor; obtain vote to proceed to Trial Implementation.<br />
<br />
<br />
The specific status of each section is listed in this document:<br />
<br />
==6. Support & Resources==<br />
<br />
Canada Health Infoway has been very active in development of this technology and has implemented it across several broad regions, resulting in real-world data and analytics.<br />
<br />
HCA in the States has expressed in supporting and reviewing a standard to implement the import and display of external priors. HCA's focus is on the proper display of priors for side-by-side comparison in a most useful and effective manner.<br />
<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep to closely related clinical issues such as ED transfer<br />
:* '''Out of scope:''' Selecting too many report meta data formats to incorporate<br />
:* Defining too much logic behind the word "relevant" - vendor/product differentiation; define only mechanisms<br />
:* Legal differences across jurisdictions<br />
<br />
==8. Open Issues==<br />
<br />
See Risks.<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
* 40% for Maximum/Full Effort = imaging and reports (only as HL7 ORU text)<br />
* 25% for Minimum Useful Effort<br />
:* 1.) Select only XDS or DICOM environment<br />
:* 2.) Leave purging out of scope<br />
:* 3.) No reports, even as only an HL7 ORU text, Reports mentioned in X.4 Concepts section - added bolded "Out of scope" note to all references to reports (imaging only)<br />
<br />
Candidate Editor:<br />
: Teri Sippel Schmidt</div>Terisippelhttp://wiki.ihe.net/index.php?title=Import_and_Display_of_External_Priors-_Proposal&diff=110589Import and Display of External Priors- Proposal2018-07-24T23:26:41Z<p>Terisippel: /* 5. Technical Approach */</p>
<hr />
<div>{{TOCright}}<br />
==1. Proposed Workitem: Import and Display of External Priors (IDEP)==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Jonathan Whitby<br />
* Proposal Contributors: David Koff, MD; Canada Health Infoway; Kevin O'Donnell<br />
* Editor: Jonathan Whitby (previously Teri Sippel Schmidt)<br />
* Contributors: David Koff, MD; Canada Health Infoway<br />
* Domain: Radiology<br />
<br />
This proposal was previously called "[[Foreign_Exam_Management_Direct_Import-_Proposal|Foreign Exam Management (FEM)]]".<br />
<br />
==2. The Problem==<br />
<br />
Prior imaging studies provide vital information and context to the radiologist when interpreting a current study, even resulting in a change of diagnosis. A "prefetch" step (to locate prior studies for the patient that may be relevant and make them immediately accessible to the radiologist during review) is common in imaging workflows. This works fairly well for priors that were performed locally, even if they have to be pulled back from longer term storage to be ready for the radiologist. <br />
<br />
Unfortunately, with the mobility of modern healthcare, '''it is very common for priors to be located outside the reading institution'''.<br />
<br />
Although there have been many improvements to the ability to exchange images between enterprises, or between departments within an enterprise, '''the ability to locate, access, and view priors for direct comparison, particularly during the short time frame required for them to be relevant to reading, is still not reliable'''.<br />
* patient portals - are unwieldy, slow to access, and on different monitors<br />
* web-based viewers - are not integrated into the diagnostic workstation so they '''don't permit side-by side image comparison and use of local hanging protocols''' or viewing tools<br />
* CD/DVD imports/viewers - are often not timely, sometimes do not import reliably, and are "reactive not proactive"<br />
* all suffer from issues with different Patient IDs, procedure codes, etc, questions of long term storage, and some mappings not addressed in IRWF.b. <br />
* radiology reports - there is no primary standard for radiology reports, and as a result, report formats vary dramatically effectively eliminating interoperability of report sharing<br />
<br />
<br />
A solution for this priors problem has been demonstrated to '''also reduce re-scanned patients''' (with cost and radiation implications) due to poor access to studies performed at other institutions.<br />
(Ref: Nagels, J., Macdonald, D. & Coz, C. J Digit Imaging (2017). https://doi.org/10.1007/s10278-017-9963-8)<br />
<br />
==3. Key Use Case==<br />
<br />
'''Order-driven priors:'''<br />
<br />
:* A physician orders a radiology study for a patient<br />
:* The Importer actor searches for prior images <'''MinUE out of scope:''' and reports> for that patient, both locally and beyond<br />
::* The Importer uses PIX/PDQ to get appropriate PIDs for searching<br />
:* The Importer uses order details and local rules to determine which priors are potentially relevant (this profile focuses on specifying metadata availability to enable)<br />
:* The Importer retrieves matching prior images <'''MinUE out of scope''': and reports> executes import logic to map/fix codes and attribute values<br />
:* The Importer stores the imported priors to the local PACS <'''MinUE Out of Scope:''' and Report Manager><br />
:* The radiologist reads the study, accessing all priors using their usual workflow, display, hanging protocols, and image tools<br />
:* Post-interpretation rules (e.g. purging prior images and reports) occur locally<br />
<br />
The Profile supports a variety of image sharing architectures, e.g. centralized archiving for a region or IDN, federated PACS with point-to-point DIMSE access, etc.<br />
<br />
'''The intent is to make the existing, installed base of PACS systems work better without necessitating any changes or upgrades. The burden is centralized in the Importer and Report Converter actors rather than distributed to every sending or receiving system.'''<br />
<br />
<br />
'''Human Version of the Clinical Use Case'''<br />
<br />
Dr. Smith, a radiologist at a busy Cancer Center, is reporting a large number of CT studies which require comparison to previous imaging often performed at remote (but secure network connected) sites in the region, mostly community hospitals, but also academic centres where the patient may have been seen. The radiologist has to evaluate changes over time in order to assess treatment efficiency, with previous performed usually 3 to 6 months earlier. There may be a series of previous studies at the same interval over a period of a few years.<br />
<br />
Dr. Smith needs to report on a lesion’s change in size and appearance, as well as interval development or resolution of other conditions such as metastatic disease, peritoneal seeding or pleural effusions. For accuracy and speed, Dr Smith has to be able to cross-reference his CT slices and MPRs in DICOM format, using his own measurement tools.<br />
<br />
Dr. Smth wants the remote CT(s) to be readily available in his patient folder on his own PACS, and the studies displayed using his hanging protocols. He wants the report to be available the same way he displays previous reports for studies performed in his institution. <br />
<br />
'''The Problem Case Today'''<br />
<br />
Dr. Smith has to access a separate website, maybe with a separate sign-on. He has to search a separate database, he has to wait for images to load, slowing him down through his very busy work day. To make things worse, Dr. Smith has to open two separate web interfaces, one for the images, another one for the report, as the VNA was not be able to move the report with the images. <br />
<br />
Even though studies are all stored on a central VNA or there is access to other DICOM PACS systems, Dr. Smith has to ask the remote site to print a CD/DVD with the images. He then asks his PACS team to upload these images into his local PACS to make sure that images are available when he reports the current study. Not only is this a tedious manual process, but it delays the time the study is reported sometimes up to a few days. And, using the CD/DVD method, it is common that the previous report is not available.<br />
<br />
==4. Standards and Systems==<br />
<br />
'''Real World Systems:'''<br />
:* EMPI (IHE: PIX/PDQ Manager)<br />
:* RIS/EMRs (IHE: SWF.b DSS/OF, Report Manager, Report Reader)<br />
:* VNA or Diagnostic Imaging Repository (DI-r) (IHE: Image Manager, Report Manager, XDS.b Document Registry+ Document Repository+Imaging Document Source, possibly Importer and/or Report Converter)<br />
:* PACS (IHE: Image Manager/Archive, Image Display, Report Manager, Report Reader, possibly Importer and/or Report Converter)<br />
:* Note: the Importer and Report Converter actors may be separate systems, combined with a system above, or combined together - See Deployment options in Volume 1<br />
<br />
<br />
'''Standards:'''<br />
:* IRWF.b - useful importation logic and data mappings (but that IRWF.b is passive and doesn't specify pre and post steps)<br />
:* PIX/PDQ - patient identification<br />
:* MIMA Vol 2 Appendix J - fully qualified Patient ID reconciliation <br />
:* HL7 v2.x ORM/OMI (RAD-4 + IRWF.b data mappings ) - access to orders for new studies at the local site <br />
:* DICOM Q/R and XDS.b-I (RAD-5 and ITI-18) - find images <br />
:* DICOM C-Move and XDS.b-I (RAD-5 and ITI-18) - retrieve images <br />
:* DICOM C-Store - store images locally (default)<br />
:* '''MinUE Out of scope:''' Mobile Health Documents (MHD) -FHIR query documents<br />
:* '''MinUE Out of scope:''' XDS.b retrieve - report retrieval<br />
:* '''MinUE Out of scope:''' HL7 v2.x ORU (RD:RAD-128) - store report locally as TEXT or PDF<br />
<br />
A Cross Profile Consideration section X.6 discusses how DICOMweb services could be integrated in the future for image access and retrieval. Recommend limiting the required transactions on primary installed base (ie., HL7 v2.x, DICOM, XDS.b).<br />
<br />
==5. Discussion==<br />
<br />
The most important discussion is a consistently agreed upon, and not deviated from, definition of SCOPE:<br />
<br />
'''Minimum Useful Effort (MinUE) Baseline scope:''' Complete the current IDEP supplement, but do NOT include:<br />
:* Reports, in any format, not even TEXT or PDF<br />
:* WIA (DICOMweb) query to access prior images (except as reference in Cross Profile Considerations X.6)<br />
:* Retain Importer actor, but remove Report Converter actor and transactions<br />
:* Retain Image Purge and Report Purge as Named Options with no transactions (only defined behavior)<br />
:* Complete the IHE Public Comment and Trial Implementation processes <br />
:* (NOTE: removal of the Report Converter actor will be a SIGNIFICANT amount of effort for the editor and will include many changes to sections which have already been reviewed in detail by the TC).<br />
<br />
'''Maximum Useful Effort (MaxUE) (Additional) Scope for 2018-2019:'''<br />
:* Retain WIA (DICOMweb) query to access prior reports ONLY as reference in Cross Profile Considerations X.6 (no new DICOMweb functionality within IDEP)<br />
:* Only address TEXT and PDF report formats in direct scope in MaxUE<br />
:* Retain all other report formats as Volume 1 Informative Appendix and nothing more in MaxUE<br />
<br />
SEE [https://docs.google.com/spreadsheets/d/1IAKNiKwKHk3kFEs-mByfuvx91riorZv6El2GDjrZmAA/edit?usp=sharing THIS SUMMARY] FOR SPECIFIC STATUS OF EACH SECTION OF CURRENT SUPPLEMENT.<br />
<br />
This is intended to be a Workflow profile with one primary use case and one of two back-end architectures (all-DICOM and XDS.b (XDS.b as named option)): <br />
<br />
'''Workflow steps to be addressed:'''<br />
:* patient identification and PID reconciliation<br />
:* receipt of new orders<br />
:* relevancy logic meta data identification<br />
:* image retrieval <br />
:* DICOM attribute mapping <br />
:* storage of imported image <br />
:* '''MinUE Out of scope:''' report retrieval <br />
:* '''MinUE Out of scope:''' HL7 v2 ORU report attribute mapping <br />
:* '''MinUE Out of scope:'''storage of imported reports <br />
:* local purging of foreign images and foreign reports as defined Option<br />
<br />
<br />
'''Scope/assumptions:''' <br />
<br />
Goal is to enable automated and contextually integrated VIEWING of foreign radiology priors at the local system.<br />
<br />
:* Focus is on simplicity and existing installed base ("old school") - DICOM, HL7 v2.x, and XDS. (not image access using DICOM web services, or storage of reports using FHIR, etc)<br />
:* Secure network already in place between facilities. (Cross- non-affiliated enterprises out of scope.)<br />
:* EMPI (PIX/PDQ) already in place between facilities. <br />
:* Access prior imaging studies using DIMSE DICOM, but have XDS-I as a named Option. This XDS-I option would also include the hybrid DICOM/XDS.b environment since DICOM is the default environment.<br />
:* Storage of imaging study limited to DIMSE DICOM to the local PACS. (ie., not direct XDS import to the local PACS)<br />
:* Other image types such as Raw JPEG, PDF, etc., are out of scope.<br />
:* '''MinUE Out of scope:''' Report formats are limited to TEXT and PDF.<br />
:* '''MinUE Out of scope:''' Access of prior reports is limited to FHIR query for reports.<br />
:* '''MinUE Out of scope:''' Storage of prior reports is limited to HL7 v2.5.1 ORU with TEXT or PDF content.<br />
:* '''MinUE Out of scope:''' Report '''semantic content''' is always out of scope, i.e., structured or unstructured, etc. This could cause non-interoperability (unable to view), but is still out of scope and must be managed locally.<br />
<br />
==5. Technical Approach==<br />
<br />
:* Focus "intelligence" and mapping in new IDEP actors (Importer and Report Converter). Limit changes to ancillary systems.<br />
:* Populate <specific data element>, but stay away from terminology mapping.<br />
:* Default: Define meta data to be able to determine relevancy, but do not define relevancy rules. Server side v. client side filtering. (IDEP would specify client side filtering.)<br />
:* No intention to map procedure codes, study description, etc. Discuss in X.4 Concepts sections.<br />
:* Do not over-specify display requirements; e.g., "Required to display "something" to indicate that it is an external study."<br />
:* Retain WIA for remote image access via web services in Cross Profile Considerations (X.6); but do not explicitly include.<br />
<br />
<br />
===Existing actors===<br />
<br />
* "Local" DSS/OF<br />
* "Local" Image Manager<br />
* ''MinUE Out of scope: "' "Local" Report Manager<br />
* PIX/PDQ Manager<br />
* "Remote" Image Manager <br />
* '''MinUE Out of scope: "' "Remote" Report Manager <br />
* XDS.b Registry<br />
* '''MinUE Out of scope: "' XDS.b Repository<br />
* XDS.b-I Imaging Document Source<br />
<br />
===New actors===<br />
* Importer (same actor as IRWF.b, but additional behaviors)<br />
* Report Converter<br />
<br />
===Existing transactions===<br />
<br />
Because this proposed profiles focuses on improving the functionality of the existing installed base, it focuses on HL7 v2, DICOM DIMSE Services, and XDS.b transactions.<br />
<br />
See IDEP transaction diagram.<br />
<br />
===New transactions (standards used)===<br />
<br />
It is not clear that any new transactions will be necessary.<br />
Additional behaviour may be required on existing actors in existing transactions in the Expected Actions section.<br />
'''Out of scope:''' Additional data mappings will be required, especially for report conversions, if we decide to include that within scope.<br />
<br />
===Impact on existing integration profiles===<br />
<br />
Some additional behaviour on transactions will be required, but there will be no impact on existing integration profiles.<br />
<br />
===New integration profiles needed===<br />
<br />
None.<br />
<br />
===Breakdown of tasks===<br />
<br />
The high level breakdown of tasks is:<br />
<br />
: 1.) MinUE Baseline or MaxUE scope must be determined and uniformly (and indelibly) agreed to.<br />
: 2.) If MinUE baseline only, editor has a lot of work to do to remove all references to reports (40% of document)<br />
: 3.) Complete internal TC-review prior to Public Comment on un-reviewed sections; obtain vote to proceed to Public Comment.<br />
: 4.) Public comment period<br />
: 5.) Public comment review by TC and incorporation by Editor<br />
: 6.) Internal TC-review and changes by Editor; obtain vote to proceed to Trial Implementation.<br />
<br />
<br />
The specific status of each section is listed in this document:<br />
<br />
==6. Support & Resources==<br />
<br />
Canada Health Infoway has been very active in development of this technology and has implemented it across several broad regions, resulting in real-world data and analytics.<br />
<br />
HCA in the States has expressed in supporting and reviewing a standard to implement the import and display of external priors. HCA's focus is on the proper display of priors for side-by-side comparison in a most useful and effective manner.<br />
<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep to closely related clinical issues such as ED transfer<br />
:* '''Out of scope:''' Selecting too many report meta data formats to incorporate<br />
:* Defining too much logic behind the word "relevant" - vendor/product differentiation; define only mechanisms<br />
:* Legal differences across jurisdictions<br />
<br />
==8. Open Issues==<br />
<br />
See Risks.<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
* 40% for Maximum/Full Effort = imaging and reports (only as HL7 ORU text)<br />
* 25% for Minimum Useful Effort<br />
:* 1.) Select only XDS or DICOM environment<br />
:* 2.) Leave purging out of scope<br />
:* 3.) No reports, even as only an HL7 ORU text, Reports mentioned in X.4 Concepts section - added bolded "Out of scope" note to all references to reports (imaging only)<br />
<br />
Candidate Editor:<br />
: Teri Sippel Schmidt</div>Terisippelhttp://wiki.ihe.net/index.php?title=Import_and_Display_of_External_Priors-_Proposal&diff=110588Import and Display of External Priors- Proposal2018-07-24T23:23:02Z<p>Terisippel: /* 5. Technical Approach */</p>
<hr />
<div>{{TOCright}}<br />
==1. Proposed Workitem: Import and Display of External Priors (IDEP)==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Jonathan Whitby<br />
* Proposal Contributors: David Koff, MD; Canada Health Infoway; Kevin O'Donnell<br />
* Editor: Jonathan Whitby (previously Teri Sippel Schmidt)<br />
* Contributors: David Koff, MD; Canada Health Infoway<br />
* Domain: Radiology<br />
<br />
This proposal was previously called "[[Foreign_Exam_Management_Direct_Import-_Proposal|Foreign Exam Management (FEM)]]".<br />
<br />
==2. The Problem==<br />
<br />
Prior imaging studies provide vital information and context to the radiologist when interpreting a current study, even resulting in a change of diagnosis. A "prefetch" step (to locate prior studies for the patient that may be relevant and make them immediately accessible to the radiologist during review) is common in imaging workflows. This works fairly well for priors that were performed locally, even if they have to be pulled back from longer term storage to be ready for the radiologist. <br />
<br />
Unfortunately, with the mobility of modern healthcare, '''it is very common for priors to be located outside the reading institution'''.<br />
<br />
Although there have been many improvements to the ability to exchange images between enterprises, or between departments within an enterprise, '''the ability to locate, access, and view priors for direct comparison, particularly during the short time frame required for them to be relevant to reading, is still not reliable'''.<br />
* patient portals - are unwieldy, slow to access, and on different monitors<br />
* web-based viewers - are not integrated into the diagnostic workstation so they '''don't permit side-by side image comparison and use of local hanging protocols''' or viewing tools<br />
* CD/DVD imports/viewers - are often not timely, sometimes do not import reliably, and are "reactive not proactive"<br />
* all suffer from issues with different Patient IDs, procedure codes, etc, questions of long term storage, and some mappings not addressed in IRWF.b. <br />
* radiology reports - there is no primary standard for radiology reports, and as a result, report formats vary dramatically effectively eliminating interoperability of report sharing<br />
<br />
<br />
A solution for this priors problem has been demonstrated to '''also reduce re-scanned patients''' (with cost and radiation implications) due to poor access to studies performed at other institutions.<br />
(Ref: Nagels, J., Macdonald, D. & Coz, C. J Digit Imaging (2017). https://doi.org/10.1007/s10278-017-9963-8)<br />
<br />
==3. Key Use Case==<br />
<br />
'''Order-driven priors:'''<br />
<br />
:* A physician orders a radiology study for a patient<br />
:* The Importer actor searches for prior images <'''MinUE out of scope:''' and reports> for that patient, both locally and beyond<br />
::* The Importer uses PIX/PDQ to get appropriate PIDs for searching<br />
:* The Importer uses order details and local rules to determine which priors are potentially relevant (this profile focuses on specifying metadata availability to enable)<br />
:* The Importer retrieves matching prior images <'''MinUE out of scope''': and reports> executes import logic to map/fix codes and attribute values<br />
:* The Importer stores the imported priors to the local PACS <'''MinUE Out of Scope:''' and Report Manager><br />
:* The radiologist reads the study, accessing all priors using their usual workflow, display, hanging protocols, and image tools<br />
:* Post-interpretation rules (e.g. purging prior images and reports) occur locally<br />
<br />
The Profile supports a variety of image sharing architectures, e.g. centralized archiving for a region or IDN, federated PACS with point-to-point DIMSE access, etc.<br />
<br />
'''The intent is to make the existing, installed base of PACS systems work better without necessitating any changes or upgrades. The burden is centralized in the Importer and Report Converter actors rather than distributed to every sending or receiving system.'''<br />
<br />
<br />
'''Human Version of the Clinical Use Case'''<br />
<br />
Dr. Smith, a radiologist at a busy Cancer Center, is reporting a large number of CT studies which require comparison to previous imaging often performed at remote (but secure network connected) sites in the region, mostly community hospitals, but also academic centres where the patient may have been seen. The radiologist has to evaluate changes over time in order to assess treatment efficiency, with previous performed usually 3 to 6 months earlier. There may be a series of previous studies at the same interval over a period of a few years.<br />
<br />
Dr. Smith needs to report on a lesion’s change in size and appearance, as well as interval development or resolution of other conditions such as metastatic disease, peritoneal seeding or pleural effusions. For accuracy and speed, Dr Smith has to be able to cross-reference his CT slices and MPRs in DICOM format, using his own measurement tools.<br />
<br />
Dr. Smth wants the remote CT(s) to be readily available in his patient folder on his own PACS, and the studies displayed using his hanging protocols. He wants the report to be available the same way he displays previous reports for studies performed in his institution. <br />
<br />
'''The Problem Case Today'''<br />
<br />
Dr. Smith has to access a separate website, maybe with a separate sign-on. He has to search a separate database, he has to wait for images to load, slowing him down through his very busy work day. To make things worse, Dr. Smith has to open two separate web interfaces, one for the images, another one for the report, as the VNA was not be able to move the report with the images. <br />
<br />
Even though studies are all stored on a central VNA or there is access to other DICOM PACS systems, Dr. Smith has to ask the remote site to print a CD/DVD with the images. He then asks his PACS team to upload these images into his local PACS to make sure that images are available when he reports the current study. Not only is this a tedious manual process, but it delays the time the study is reported sometimes up to a few days. And, using the CD/DVD method, it is common that the previous report is not available.<br />
<br />
==4. Standards and Systems==<br />
<br />
'''Real World Systems:'''<br />
:* EMPI (IHE: PIX/PDQ Manager)<br />
:* RIS/EMRs (IHE: SWF.b DSS/OF, Report Manager, Report Reader)<br />
:* VNA or Diagnostic Imaging Repository (DI-r) (IHE: Image Manager, Report Manager, XDS.b Document Registry+ Document Repository+Imaging Document Source, possibly Importer and/or Report Converter)<br />
:* PACS (IHE: Image Manager/Archive, Image Display, Report Manager, Report Reader, possibly Importer and/or Report Converter)<br />
:* Note: the Importer and Report Converter actors may be separate systems, combined with a system above, or combined together - See Deployment options in Volume 1<br />
<br />
<br />
'''Standards:'''<br />
:* IRWF.b - useful importation logic and data mappings (but that IRWF.b is passive and doesn't specify pre and post steps)<br />
:* PIX/PDQ - patient identification<br />
:* MIMA Vol 2 Appendix J - fully qualified Patient ID reconciliation <br />
:* HL7 v2.x ORM/OMI (RAD-4 + IRWF.b data mappings ) - access to orders for new studies at the local site <br />
:* DICOM Q/R and XDS.b-I (RAD-5 and ITI-18) - find images <br />
:* DICOM C-Move and XDS.b-I (RAD-5 and ITI-18) - retrieve images <br />
:* DICOM C-Store - store images locally (default)<br />
:* '''MinUE Out of scope:''' Mobile Health Documents (MHD) -FHIR query documents<br />
:* '''MinUE Out of scope:''' XDS.b retrieve - report retrieval<br />
:* '''MinUE Out of scope:''' HL7 v2.x ORU (RD:RAD-128) - store report locally as TEXT or PDF<br />
<br />
A Cross Profile Consideration section X.6 discusses how DICOMweb services could be integrated in the future for image access and retrieval. Recommend limiting the required transactions on primary installed base (ie., HL7 v2.x, DICOM, XDS.b).<br />
<br />
==5. Discussion==<br />
<br />
The most important discussion is a consistently agreed upon, and not deviated from, definition of SCOPE:<br />
<br />
'''Minimum Useful Effort (MinUE) Baseline scope:''' Complete the current IDEP supplement, but do NOT include:<br />
:* Reports, in any format, not even TEXT or PDF<br />
:* WIA (DICOMweb) query to access prior images (except as reference in Cross Profile Considerations X.6)<br />
:* Retain Importer actor, but remove Report Converter actor and transactions<br />
:* Retain Image Purge and Report Purge as Named Options with no transactions (only defined behavior)<br />
:* Complete the IHE Public Comment and Trial Implementation processes <br />
:* (NOTE: removal of the Report Converter actor will be a SIGNIFICANT amount of effort for the editor and will include many changes to sections which have already been reviewed in detail by the TC).<br />
<br />
'''Maximum Useful Effort (MaxUE) (Additional) Scope for 2018-2019:'''<br />
:* Retain WIA (DICOMweb) query to access prior reports ONLY as reference in Cross Profile Considerations X.6 (no new DICOMweb functionality within IDEP)<br />
:* Only address TEXT and PDF report formats in direct scope in MaxUE<br />
:* Retain all other report formats as Volume 1 Informative Appendix and nothing more in MaxUE<br />
<br />
SEE [https://docs.google.com/spreadsheets/d/1IAKNiKwKHk3kFEs-mByfuvx91riorZv6El2GDjrZmAA/edit?usp=sharing THIS SUMMARY] FOR SPECIFIC STATUS OF EACH SECTION OF CURRENT SUPPLEMENT.<br />
<br />
This is intended to be a Workflow profile with one primary use case and one of two back-end architectures (all-DICOM and XDS.b (XDS.b as named option)): <br />
<br />
'''Workflow steps to be addressed:'''<br />
:* patient identification and PID reconciliation<br />
:* receipt of new orders<br />
:* relevancy logic meta data identification<br />
:* image retrieval <br />
:* DICOM attribute mapping <br />
:* storage of imported image <br />
:* '''MinUE Out of scope:''' report retrieval <br />
:* '''MinUE Out of scope:''' HL7 v2 ORU report attribute mapping <br />
:* '''MinUE Out of scope:'''storage of imported reports <br />
:* local purging of foreign images and foreign reports as defined Option<br />
<br />
<br />
'''Scope/assumptions:''' <br />
<br />
Goal is to enable automated and contextually integrated VIEWING of foreign radiology priors at the local system.<br />
<br />
:* Focus is on simplicity and existing installed base ("old school") - DICOM, HL7 v2.x, and XDS. (not image access using DICOM web services, or storage of reports using FHIR, etc)<br />
:* Secure network already in place between facilities. (Cross- non-affiliated enterprises out of scope.)<br />
:* EMPI (PIX/PDQ) already in place between facilities. <br />
:* Access prior imaging studies using DIMSE DICOM, but have XDS-I as a named Option. This XDS-I option would also include the hybrid DICOM/XDS.b environment since DICOM is the default environment.<br />
:* Storage of imaging study limited to DIMSE DICOM to the local PACS. (ie., not direct XDS import to the local PACS)<br />
:* Other image types such as Raw JPEG, PDF, etc., are out of scope.<br />
:* '''MinUE Out of scope:''' Report formats are limited to TEXT and PDF.<br />
:* '''MinUE Out of scope:''' Access of prior reports is limited to FHIR query for reports.<br />
:* '''MinUE Out of scope:''' Storage of prior reports is limited to HL7 v2.5.1 ORU with TEXT or PDF content.<br />
:* '''MinUE Out of scope:''' Report '''semantic content''' is always out of scope, i.e., structured or unstructured, etc. This could cause non-interoperability (unable to view), but is still out of scope and must be managed locally.<br />
<br />
==5. Technical Approach==<br />
<br />
:* Populate <specific data element>, but stay away from terminology mapping.<br />
:* Default: Define meta data to be able to determine relevancy, but do not define relevancy rules. Server side v. client side filtering. (IDEP would specify client side filtering.)<br />
:* No intention to map procedure codes, study description, etc. Discuss in X.4 Concepts sections.<br />
:* Do not over-specify display requirements; e.g., "Required to display "something" to indicate that it is an external study."<br />
:* Retain WIA for remote image access via web services in Cross Profile Considerations (X.6); but do not explicitly include.<br />
<br />
<br />
Minimum Use Effort:<br />
<br />
:* 1.) Select only XDS or DICOM environment<br />
:* 2.) Leave purging out of scope<br />
<br />
===Existing actors===<br />
<br />
* "Local" DSS/OF<br />
* "Local" Image Manager<br />
* ''Out of scope: "' "Local" Report Manager<br />
* PIX Manager<br />
* "Remote" Image Manager <br />
* '''Out of scope: "' "Remote" Report Manager <br />
* XDS.b Registry<br />
* '''Out of scope: "' XDS.b Repository<br />
* XDS.b-I Imaging Document Source<br />
<br />
===New actors===<br />
* Importer (same actor as IRWF.b, but additional behaviors)<br />
* Report Converter<br />
<br />
===Existing transactions===<br />
<br />
Because this proposed profiles focuses on improving the functionality of the existing installed base, it focuses on HL7 v2, DICOM DIMSE Services, and XDS.b transactions.<br />
<br />
See IDEP transaction diagram.<br />
<br />
===New transactions (standards used)===<br />
<br />
It is not clear that any new transactions will be necessary.<br />
Additional behaviour may be required on existing actors in existing transactions in the Expected Actions section.<br />
'''Out of scope:''' Additional data mappings will be required, especially for report conversions, if we decide to include that within scope.<br />
<br />
===Impact on existing integration profiles===<br />
<br />
Some additional behaviour on transactions will be required, but there will be no impact on existing integration profiles.<br />
<br />
===New integration profiles needed===<br />
<br />
None.<br />
<br />
===Breakdown of tasks===<br />
<br />
The high level breakdown of tasks is:<br />
<br />
: 1.) MinUE Baseline or MaxUE scope must be determined and uniformly (and indelibly) agreed to.<br />
: 2.) If baseline only, editor has a lot of work to do to remove all references to reports (40% of document)<br />
: 3.) Complete internal TC-review prior to Public Comment; obtain vote to proceed to Public Comment.<br />
: 4.) Public comment period<br />
: 5.) Public comment review by TC and incorporation by Editor<br />
: 6.) Internal TC-review and changes by Editor; obtain vote to proceed to Trial Implementation.<br />
<br />
<br />
The specific status of each section is:<br />
<br />
Reviewed in detail by TC in April, 2018, F2F meeting in Oak Brook:<br />
<br />
==6. Support & Resources==<br />
<br />
Canada Health Infoway has been very active in development of this technology and has implemented it across several broad regions, resulting in real-world data and analytics.<br />
<br />
HCA in the States has expressed in supporting and reviewing a standard to implement the import and display of external priors. HCA's focus is on the proper display of priors for side-by-side comparison in a most useful and effective manner.<br />
<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep to closely related clinical issues such as ED transfer<br />
:* '''Out of scope:''' Selecting too many report meta data formats to incorporate<br />
:* Defining too much logic behind the word "relevant" - vendor/product differentiation; define only mechanisms<br />
:* Legal differences across jurisdictions<br />
<br />
==8. Open Issues==<br />
<br />
See Risks.<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
* 40% for Maximum/Full Effort = imaging and reports (only as HL7 ORU text)<br />
* 25% for Minimum Useful Effort<br />
:* 1.) Select only XDS or DICOM environment<br />
:* 2.) Leave purging out of scope<br />
:* 3.) No reports, even as only an HL7 ORU text, Reports mentioned in X.4 Concepts section - added bolded "Out of scope" note to all references to reports (imaging only)<br />
<br />
Candidate Editor:<br />
: Teri Sippel Schmidt</div>Terisippelhttp://wiki.ihe.net/index.php?title=Import_and_Display_of_External_Priors-_Proposal&diff=110568Import and Display of External Priors- Proposal2018-07-23T20:10:08Z<p>Terisippel: /* 5. Discussion */</p>
<hr />
<div>{{TOCright}}<br />
==1. Proposed Workitem: Import and Display of External Priors (IDEP)==<br />
<br />
* Proposal Editor: Teri Sippel Schmidt/Jonathan Whitby<br />
* Proposal Contributors: David Koff, MD; Canada Health Infoway; Kevin O'Donnell<br />
* Editor: Jonathan Whitby (previously Teri Sippel Schmidt)<br />
* Contributors: David Koff, MD; Canada Health Infoway<br />
* Domain: Radiology<br />
<br />
This proposal was previously called "[[Foreign_Exam_Management_Direct_Import-_Proposal|Foreign Exam Management (FEM)]]".<br />
<br />
==2. The Problem==<br />
<br />
Prior imaging studies provide vital information and context to the radiologist when interpreting a current study, even resulting in a change of diagnosis. A "prefetch" step (to locate prior studies for the patient that may be relevant and make them immediately accessible to the radiologist during review) is common in imaging workflows. This works fairly well for priors that were performed locally, even if they have to be pulled back from longer term storage to be ready for the radiologist. <br />
<br />
Unfortunately, with the mobility of modern healthcare, '''it is very common for priors to be located outside the reading institution'''.<br />
<br />
Although there have been many improvements to the ability to exchange images between enterprises, or between departments within an enterprise, '''the ability to locate, access, and view priors for direct comparison, particularly during the short time frame required for them to be relevant to reading, is still not reliable'''.<br />
* patient portals - are unwieldy, slow to access, and on different monitors<br />
* web-based viewers - are not integrated into the diagnostic workstation so they '''don't permit side-by side image comparison and use of local hanging protocols''' or viewing tools<br />
* CD/DVD imports/viewers - are often not timely, sometimes do not import reliably, and are "reactive not proactive"<br />
* all suffer from issues with different Patient IDs, procedure codes, etc, questions of long term storage, and some mappings not addressed in IRWF.b. <br />
* radiology reports - there is no primary standard for radiology reports, and as a result, report formats vary dramatically effectively eliminating interoperability of report sharing<br />
<br />
<br />
A solution for this priors problem has been demonstrated to '''also reduce re-scanned patients''' (with cost and radiation implications) due to poor access to studies performed at other institutions.<br />
(Ref: Nagels, J., Macdonald, D. & Coz, C. J Digit Imaging (2017). https://doi.org/10.1007/s10278-017-9963-8)<br />
<br />
==3. Key Use Case==<br />
<br />
'''Order-driven priors:'''<br />
<br />
:* A physician orders a radiology study for a patient<br />
:* The Importer actor searches for prior images <'''MinUE out of scope:''' and reports> for that patient, both locally and beyond<br />
::* The Importer uses PIX/PDQ to get appropriate PIDs for searching<br />
:* The Importer uses order details and local rules to determine which priors are potentially relevant (this profile focuses on specifying metadata availability to enable)<br />
:* The Importer retrieves matching prior images <'''MinUE out of scope''': and reports> executes import logic to map/fix codes and attribute values<br />
:* The Importer stores the imported priors to the local PACS <'''MinUE Out of Scope:''' and Report Manager><br />
:* The radiologist reads the study, accessing all priors using their usual workflow, display, hanging protocols, and image tools<br />
:* Post-interpretation rules (e.g. purging prior images and reports) occur locally<br />
<br />
The Profile supports a variety of image sharing architectures, e.g. centralized archiving for a region or IDN, federated PACS with point-to-point DIMSE access, etc.<br />
<br />
'''The intent is to make the existing, installed base of PACS systems work better without necessitating any changes or upgrades. The burden is centralized in the Importer and Report Converter actors rather than distributed to every sending or receiving system.'''<br />
<br />
<br />
'''Human Version of the Clinical Use Case'''<br />
<br />
Dr. Smith, a radiologist at a busy Cancer Center, is reporting a large number of CT studies which require comparison to previous imaging often performed at remote (but secure network connected) sites in the region, mostly community hospitals, but also academic centres where the patient may have been seen. The radiologist has to evaluate changes over time in order to assess treatment efficiency, with previous performed usually 3 to 6 months earlier. There may be a series of previous studies at the same interval over a period of a few years.<br />
<br />
Dr. Smith needs to report on a lesion’s change in size and appearance, as well as interval development or resolution of other conditions such as metastatic disease, peritoneal seeding or pleural effusions. For accuracy and speed, Dr Smith has to be able to cross-reference his CT slices and MPRs in DICOM format, using his own measurement tools.<br />
<br />
Dr. Smth wants the remote CT(s) to be readily available in his patient folder on his own PACS, and the studies displayed using his hanging protocols. He wants the report to be available the same way he displays previous reports for studies performed in his institution. <br />
<br />
'''The Problem Case Today'''<br />
<br />
Dr. Smith has to access a separate website, maybe with a separate sign-on. He has to search a separate database, he has to wait for images to load, slowing him down through his very busy work day. To make things worse, Dr. Smith has to open two separate web interfaces, one for the images, another one for the report, as the VNA was not be able to move the report with the images. <br />
<br />
Even though studies are all stored on a central VNA or there is access to other DICOM PACS systems, Dr. Smith has to ask the remote site to print a CD/DVD with the images. He then asks his PACS team to upload these images into his local PACS to make sure that images are available when he reports the current study. Not only is this a tedious manual process, but it delays the time the study is reported sometimes up to a few days. And, using the CD/DVD method, it is common that the previous report is not available.<br />
<br />
==4. Standards and Systems==<br />
<br />
'''Real World Systems:'''<br />
:* EMPI (IHE: PIX/PDQ Manager)<br />
:* RIS/EMRs (IHE: SWF.b DSS/OF, Report Manager, Report Reader)<br />
:* VNA or Diagnostic Imaging Repository (DI-r) (IHE: Image Manager, Report Manager, XDS.b Document Registry+ Document Repository+Imaging Document Source, possibly Importer and/or Report Converter)<br />
:* PACS (IHE: Image Manager/Archive, Image Display, Report Manager, Report Reader, possibly Importer and/or Report Converter)<br />
:* Note: the Importer and Report Converter actors may be separate systems, combined with a system above, or combined together - See Deployment options in Volume 1<br />
<br />
<br />
'''Standards:'''<br />
:* IRWF.b - useful importation logic and data mappings (but that IRWF.b is passive and doesn't specify pre and post steps)<br />
:* PIX/PDQ - patient identification<br />
:* MIMA Vol 2 Appendix J - fully qualified Patient ID reconciliation <br />
:* HL7 v2.x ORM/OMI (RAD-4 + IRWF.b data mappings ) - access to orders for new studies at the local site <br />
:* DICOM Q/R and XDS.b-I (RAD-5 and ITI-18) - find images <br />
:* DICOM C-Move and XDS.b-I (RAD-5 and ITI-18) - retrieve images <br />
:* DICOM C-Store - store images locally (default)<br />
:* '''MinUE Out of scope:''' Mobile Health Documents (MHD) -FHIR query documents<br />
:* '''MinUE Out of scope:''' XDS.b retrieve - report retrieval<br />
:* '''MinUE Out of scope:''' HL7 v2.x ORU (RD:RAD-128) - store report locally as TEXT or PDF<br />
<br />
A Cross Profile Consideration section X.6 discusses how DICOMweb services could be integrated in the future for image access and retrieval. Recommend limiting the required transactions on primary installed base (ie., HL7 v2.x, DICOM, XDS.b).<br />
<br />
==5. Discussion==<br />
<br />
The most important discussion is a consistently agreed upon, and not deviated from, definition of SCOPE:<br />
<br />
'''Minimum Useful Effort (MinUE) Baseline scope:''' Complete the current IDEP supplement, but do NOT include:<br />
:* Reports, in any format, not even TEXT or PDF<br />
:* WIA (DICOMweb) query to access prior images (except as reference in Cross Profile Considerations X.6)<br />
:* Retain Importer actor, but remove Report Converter actor and transactions<br />
:* Retain Image Purge and Report Purge as Named Options with no transactions (only defined behavior)<br />
:* Complete the IHE Public Comment and Trial Implementation processes <br />
:* (NOTE: removal of the Report Converter actor will be a SIGNIFICANT amount of effort for the editor and will include many changes to sections which have already been reviewed in detail by the TC).<br />
<br />
'''Maximum Useful Effort (MaxUE) (Additional) Scope for 2018-2019:'''<br />
:* Retain WIA (DICOMweb) query to access prior reports ONLY as reference in Cross Profile Considerations X.6 (no new DICOMweb functionality within IDEP)<br />
:* Only address TEXT and PDF report formats in direct scope in MaxUE<br />
:* Retain all other report formats as Volume 1 Informative Appendix and nothing more in MaxUE<br />
<br />
SEE [https://docs.google.com/spreadsheets/d/1IAKNiKwKHk3kFEs-mByfuvx91riorZv6El2GDjrZmAA/edit?usp=sharing THIS SUMMARY] FOR SPECIFIC STATUS OF EACH SECTION OF CURRENT SUPPLEMENT.<br />
<br />
This is intended to be a Workflow profile with one primary use case and one of two back-end architectures (all-DICOM and XDS.b (XDS.b as named option)): <br />
<br />
'''Workflow steps to be addressed:'''<br />
:* patient identification and PID reconciliation<br />
:* receipt of new orders<br />
:* relevancy logic meta data identification<br />
:* image retrieval <br />
:* DICOM attribute mapping <br />
:* storage of imported image <br />
:* '''MinUE Out of scope:''' report retrieval <br />
:* '''MinUE Out of scope:''' HL7 v2 ORU report attribute mapping <br />
:* '''MinUE Out of scope:'''storage of imported reports <br />
:* local purging of foreign images and foreign reports as defined Option<br />
<br />
<br />
'''Scope/assumptions:''' <br />
<br />
Goal is to enable automated and contextually integrated VIEWING of foreign radiology priors at the local system.<br />
<br />
:* Focus is on simplicity and existing installed base ("old school") - DICOM, HL7 v2.x, and XDS. (not image access using DICOM web services, or storage of reports using FHIR, etc)<br />
:* Secure network already in place between facilities. (Cross- non-affiliated enterprises out of scope.)<br />
:* EMPI (PIX/PDQ) already in place between facilities. <br />
:* Access prior imaging studies using DIMSE DICOM, but have XDS-I as a named Option. This XDS-I option would also include the hybrid DICOM/XDS.b environment since DICOM is the default environment.<br />
:* Storage of imaging study limited to DIMSE DICOM to the local PACS. (ie., not direct XDS import to the local PACS)<br />
:* Other image types such as Raw JPEG, PDF, etc., are out of scope.<br />
:* '''MinUE Out of scope:''' Report formats are limited to TEXT and PDF.<br />
:* '''MinUE Out of scope:''' Access of prior reports is limited to FHIR query for reports.<br />
:* '''MinUE Out of scope:''' Storage of prior reports is limited to HL7 v2.5.1 ORU with TEXT or PDF content.<br />
:* '''MinUE Out of scope:''' Report '''semantic content''' is always out of scope, i.e., structured or unstructured, etc. This could cause non-interoperability (unable to view), but is still out of scope and must be managed locally.<br />
<br />
==5. Technical Approach==<br />
<br />
:* Populate <specific data element>, but stay away from terminology mapping.<br />
:* Default: Define meta data to be able to determine relevancy, but do not define relevancy rules. Server side v. client side filtering. (IDEP would specify client side filtering.)<br />
:* No intention to map procedure codes, study description, etc. Discuss in X.4 Concepts sections.<br />
:* Do not over-specify display requirements; e.g., "Required to display "something" to indicate that it is an external study."<br />
:* Retain WIA for remote image access in Cross Profile Considerations (X.6). <br />
<br />
<br />
Minimum Use Effort:<br />
<br />
:* 1.) Select only XDS or DICOM environment<br />
:* 2.) Leave purging out of scope<br />
<br />
===Existing actors===<br />
<br />
* "Local" DSS/OF<br />
* "Local" Image Manager<br />
* ''Out of scope: "' "Local" Report Manager<br />
* PIX Manager<br />
* "Remote" Image Manager <br />
* '''Out of scope: "' "Remote" Report Manager <br />
* XDS.b Registry<br />
* '''Out of scope: "' XDS.b Repository<br />
* XDS.b-I Imaging Document Source<br />
<br />
===New actors===<br />
* Importer (same actor as IRWF.b, but additional behaviors)<br />
* Report Converter<br />
<br />
===Existing transactions===<br />
<br />
Because this proposed profiles focuses on improving the functionality of the existing installed base, it focuses on HL7 v2, DICOM DIMSE Services, and XDS.b transactions.<br />
<br />
See IDEP transaction diagram.<br />
<br />
===New transactions (standards used)===<br />
<br />
It is not clear that any new transactions will be necessary.<br />
Additional behaviour may be required on existing actors in existing transactions in the Expected Actions section.<br />
'''Out of scope:''' Additional data mappings will be required, especially for report conversions, if we decide to include that within scope.<br />
<br />
===Impact on existing integration profiles===<br />
<br />
Some additional behaviour on transactions will be required, but there will be no impact on existing integration profiles.<br />
<br />
===New integration profiles needed===<br />
<br />
None.<br />
<br />
===Breakdown of tasks===<br />
<br />
The high level breakdown of tasks is:<br />
<br />
: 1.) MinUE Baseline or MaxUE scope must be determined and uniformly (and indelibly) agreed to.<br />
: 2.) If baseline only, editor has a lot of work to do to remove all references to reports (40% of document)<br />
: 3.) Complete internal TC-review prior to Public Comment; obtain vote to proceed to Public Comment.<br />
: 4.) Public comment period<br />
: 5.) Public comment review by TC and incorporation by Editor<br />
: 6.) Internal TC-review and changes by Editor; obtain vote to proceed to Trial Implementation.<br />
<br />
<br />
The specific status of each section is:<br />
<br />
Reviewed in detail by TC in April, 2018, F2F meeting in Oak Brook:<br />
<br />
==6. Support & Resources==<br />
<br />
Canada Health Infoway has been very active in development of this technology and has implemented it across several broad regions, resulting in real-world data and analytics.<br />
<br />
HCA in the States has expressed in supporting and reviewing a standard to implement the import and display of external priors. HCA's focus is on the proper display of priors for side-by-side comparison in a most useful and effective manner.<br />
<br />
<br />
==7. Risks==<br />
<br />
:* Scope creep to closely related clinical issues such as ED transfer<br />
:* '''Out of scope:''' Selecting too many report meta data formats to incorporate<br />
:* Defining too much logic behind the word "relevant" - vendor/product differentiation; define only mechanisms<br />
:* Legal differences across jurisdictions<br />
<br />
==8. Open Issues==<br />
<br />
See Risks.<br />
<br />
==9. Tech Cmte Evaluation==<br />
<br />
Technical Evaluation:<br />
<br />
Effort Evaluation (as a % of Tech Cmte Bandwidth):<br />
* 40% for Maximum/Full Effort = imaging and reports (only as HL7 ORU text)<br />
* 25% for Minimum Useful Effort<br />
:* 1.) Select only XDS or DICOM environment<br />
:* 2.) Leave purging out of scope<br />
:* 3.) No reports, even as only an HL7 ORU text, Reports mentioned in X.4 Concepts section - added bolded "Out of scope" note to all references to reports (imaging only)<br />
<br />
Candidate Editor:<br />
: Teri Sippel Schmidt</div>Terisippel