Clinical Operations Workgroup: Image Sharing Recommendations Jamie Ferguson John Halamka December 6, 2013

Clinical Operations Members 12/6/2013 Office of the National Coordinator for Health Information Technology 1 WG Members Jaime Ferguson, Kaiser Permanente John Halamka, Beth Israel Deaconess Medical Center Don Bechtel, Siemens Martin Harris, Cleveland Clinic Stanley Huff, Intermountain Healthcare Kevin Hutchinson, My-Villages Inc Elizabeth Johnson, Tenet Health John Kimek, NCPDP Rebecca Kush, CDISC Nancy Orvis, Department of Defense Marjorie Rallins, American Medical Association Wes Rishel, Gartner Christopher Ross, Mayo Clinic Joyce Sensmeier, HIMMS Karen Trudel, HHS/CMS Dan Vreeman, Regenstrief Institute Ex Officio Members Jay Crowley, FDA/HHS Marjorie Greenburg, HHS/CDC Clem McDonald, National Library of Medicine Terrie Reed, FDA/HHS

Agenda 12/6/2013 Office of the National Coordinator for Health Information Technology 2 Welcome Charge Discuss recommendations on Image Sharing based on HITSC feedback Clinical Operations Workgroup Update Public Comment

CHARGE 12/6/2013 Office of the National Coordinator for Health Information Technology 3 How full image sets or designated key images are shared between different facilities and specialists: the high level architecture e.g. role PACS, Archives, and EMRs How this is deployed with central and distributed reading facilities What methods and technical standards are used to push, pull, or view images in one place that originated or were interpreted in another place Issues encountered sharing reports and interpretations, or auditing, with or alongside the images themselves Inclusion of time series data in scope in addition to radiological images

Recommendations for Image Sharing Tier 1. Radiology Reports and low res/ Non-Diagnostic images: Specify a document syntax and vocab standard, likely HL7+, for radiology reports. Separately, for non-diagnostic images specify a few acceptable formats e.g. PDF/A or TIFF. Specify HIE methods for exchange of these artifacts - Direct and SOAP Exchange and RESTful paradigms. Tier 2. Key Diagnostic Images as designated by a reader/interpreter: Implementation guide for DICOM image objects. Query and push modalities required but need to be very loose, perhaps silent, on allowable transport. Preference for RESTful approaches to sharing in the long term should not constrain current exchange implementation, architectures, and innovation. Tier 3. Full image sets. Implementation guide for DICOM image objects. Query modality only. Same transport approach as #2. Office of the National Coordinator for Health Information Technology 4

HIT Standards Committee Clinical Operations WG Update Image Sharing September 18, 2013 Jamie Ferguson John Halamka

Use Case Framework For Image Sharing VIEWDOWNLOADTRANSMIT TO 3 rd PARTY Each Use Case Scenario Must Define: Actors: Clinician, Care Team, Patient Actions: Clinical Decision, Report, Audit Content: Full Set, Key Images, Report Initiation: Manual, Triggered, Automatic Systems: EHR, PHR, PACS, Archives Before Analyzing and Recommending: Payload Packages Protocols and Modalities Image Quality Etc... Adapted from Clinical Operations discussions with thanks to David Clunie Office of the National Coordinator for Health Information Technology 6

Image Sharing Use Cases Encompassed by View/Download/Transmit (VDT): – View – select, navigate, display, interact, measure, analyze – Download – to local machine or media – use, archive, share – Transmit – to 3 rd party – provider, archive, analysis service For Each: – Who – imager, clinician (ordering, referral), “team”, patient – What – complete set, subset, key images, report, other ‘ologies – When – manual or automatic (triggered) – Where – EHR, PHR, PACS, VNA, HIE Archive, … – Why – reporting, diagnosis (clinical decision), review, audit, … Scenarios Inform Requirements For Protocols/Modalities – push/pull, payload, protocol, image quality, speed, identifiers Office of the National Coordinator for Health Information Technology 7

Example of Protocol Considerations View (Pull) What does “zero footprint” mean? Zero footprint – No helper apps, plugins, applets, Flash or SilverLight Absolute zero – HTML pre-5, frames, tables, images Almost zero – JavaScript +/- HTML5 Canvas Pretending to be zero – Flash (etc.) dependency Not zero - thick client spawned by browser (or EHR “app”) Office of the National Coordinator for Health Information Technology 8

Example of Protocol Considerations, Continued View (Pull) Separation of requestor from performer – EHR/PHR/etc. user requests viewing of study – PACS/VNA/etc. actually performs it Very common proprietary pattern – e.g., encrypted URLs – identify, authorize, time-limited – n:m permutations of requestor/performer to customize Storing fully qualified links (URLs) – go stale Office of the National Coordinator for Health Information Technology 9

Architecture Considerations Push “architecture” – easy, tempting – duplication (stored many places) – change management (wrong patient, side marker, etc.) Pull “architecture” – federated/distributed queries v. centralized registries – centralized image storage v. expose locally at edges – links go stale, enterprises go out of business, etc. “Brokered” “hybrid” “clearing house” – intermediary holds images transiently (possible encrypted) – sender pushes, then recipient notified and pulls – analogous to DropBox file sharing service, Filelink 10

Other Considerations Learn from global experience – Canada (DI-r) … regional repositories – UK (IEP) … point-to-point push –> brokered –> centralized Report in scope or not? Agility to adapt to rapidly changing technology (mobile) Transition from local to remote experience How to leverage the installed base 11

Next Steps COWG to better define a few use cases for image sharing Identify for each use case – Minimum recommended bundle of standards – Needed improvements to standards Further HITSC discussion Office of the National Coordinator for Health Information Technology 12

Office of the National Coordinator for Health Information Technology 13