Community Forum

September 28th, 2016�11:00 AM - 12:00 PM Eastern Daylight Time

Agenda

• Compliance efforts
• Plans for sharing SOPs (currently focused on 21 CFR Part 11: Electronic Records)
• FDA 510(k) position
• Recent Cornerstone improvements
• Web Workers
• Image Decoding
• Image Creation Refactoring
• WADO-RS Retrieve Frame
• Demo from (http://www.statrad.com/)
• Standalone Viewer
• Recent contributions
• (http://www.ascendhit.com/)

Compliance Efforts

Compliance: Goals

• Goals
• Simplify the compliance process for applications built with Cornerstone and/or the OHIF ecosystem
• Allow Cornerstone ecosystem to be treated as a Commercial Off-the-shelf (COTS) product in future FDA 510(k) applications
• Ease compliance work for other compliance requirements
• e.g. HIPAA (Health Insurance Portability and Accountability Act) and 21 CFR Part 11 (electronic records), European CE Mark
• We have no plans to obtain 510(k) clearance for the OHIF Viewer itself
• Costly
• May leave OHIF open to liability issues
• We will not sell the Viewer, so we don’t need to have it cleared

Compliance: Background

• User Requirements
• Describes what the equipment is intended to do and all essential requirements
• Risk is assigned at the User Requirement level
• E.g. “Web viewer shall display DICOM images”�https://ohiforg.atlassian.net/browse/OHIF-96
• Functional Requirements
• Describes the detailed functionality of the equipment
• E.g. “Images shall be displayed as intended and described by the DICOM standard”�https://ohiforg.atlassian.net/browse/OHIF-84
• Functional Requirements have descriptions and subtasks
1. Images shall be displayed at the maximum resolution possible
2. Images' photometric interpretation shall be respected for display
3. Color images shall be viewable
4. Grayscale images shall be viewable (etc…)

�http://www.fda.gov/RegulatoryInformation/Guidances/ucm085281.htm#_Toc517237937

Compliance: Background

• Verification
• Does the software meet the specification?
• Verification tests can be part of the software library
• Validation
• Can the requirements for the intended use can be consistently fulfilled?
• Validation is manually performed by the manufacturer
• Traceability
• Explicit links needs to be present between:
• Hazards (risk) & user requirements
• User requirements & functional requirements
• User requirements & test cases
• Functional requirements and system design documentation

​

​

�http://www.fda.gov/RegulatoryInformation/Guidances/ucm085281.htm#_Toc517237937

Compliance: Plans

1. Use open OHIF JIRA for requirements, design, & qualification tracking
• Benefits:
• Allows projects to pull only the documentation that they need
• Allow for generation of traceability matrices between:
• User Requirements & Functional Requirements
• Software Requirements and Verification Tests�
• What we’re working on:
• Creating high-level User Requirements and detailed Functional Requirements
• Assigning risk to each User Requirement
• Creating manually-executable Test Cases for User Requirements
• Designing test cycles to validate for IHE Basic Image Review capabilities

https://ohiforg.atlassian.net/projects/OHIF/summary

Compliance: Plans

2. Release Standard Operating Procedure (SOP) documents*
• Software Development
• Software Validation
• Configuration Management
• Change Management
• Quality Assurance Plan
• Risk Management�
3. Use these SOPs on all OHIF development

​

• Incident Management
• Corrective and Preventive Action (CAPA)
• Document Control
• Record Retention
• Periodic Validation Review
• Software Vendor Qualification

• � (https://www.precisionmetrics.org/) is generously donating these!

*

Compliance: Plans

• Occasionally make releases of the OHIF toolkit and documentation
• Triage bug reports & feature requests using Github Issues
• Development issue tracking on JIRA
• Documentation releases will be tied to specific releases of Cornerstone libraries and OHIF packages
• Release cycle length has not yet been determined

​

https://ohiforg.atlassian.net/projects/OHIF/summary

Compliance: Common Questions

• How would I make my application a cleared medical device?
• Retrieve relevant user & functional requirements and test cases from the OHIF JIRA
• Add user & functional requirements and tests for whatever new features you add
• Use OHIF Standard Operating Procedures as a template
• Seek guidance from a 510(k) QA consultant
• Perform your own validation
• Apply for 510(k) clearance as the manufacturer of your device�
• Will my application be a cleared medical device if I build it using the OHIF platform?
• No, you need to explicitly perform your own validation and apply for 510(k) clearance yourself

Recent Cornerstone Improvements

Cornerstone Improvements

Web Workers

Image decoding

Image creation code refactored

WADO-RS Retrieve Frame

​

Web Workers

What

• Execute logic on background threads

Benefits

• Avoid locking up the UI
• Take advantage of multicore CPUs

Web Worker

Web Worker API’s

Web Worker Framework

Documentation:

https://github.com/chafey/cornerstoneWADOImageLoader/blob/dev/docs/WebWorkers.md

Example:

https://rawgit.com/chafey/cornerstoneWADOImageLoader/dev/examples/customWebWorkerTask/index.html

Example / Demo

Codecs

All codecs are now in /codecs

​

Build process produces a concatenated codecs file and a minified codecs file:

/dist/cornerstoneWADOImageLoaderCodecs.js

/dist/cornerstoneWADOImageLoaderCodecs.min.js

​

OpenJPEG library updated to latest version (2.1.1)

Codec Performance - Native

Image: 3063x4664 MG JPEG2000 Image (MG1 from dclunie’s compression samples)

Test Environment: MacBook Pro (Retina, 15-inch Mid 2014 2.8 GHz Intel Core i7 macOS Sierra):

​

​

Kakadu Speedpack (vs7_8-01480C) decompress with 8 threads - .259 seconds

Kakadu Speedpack (vs7_8-01480C) decompress with 1 thread – 1.186 seconds

Kakdu (v7_8-01480C) decompress with 8 threads - .345 seconds

Kakdu (v7_8-01480C) decompress with 1 thread – 1.7862 seconds

OpenJPEG (master) decompress with 1 thread – 4.165 seconds

OpenJPEG (master) decompress with 8 threads – 2.113 seconds

OpenJPEG (2.1.1) decompress with 1 thread – 4.847 seconds

Grok (master) decompress with 1 thread– 2.810 seconds

​

​

Codec Performance - JavaScript

OpenJPEG (2.1.1) decompress with 1 thread – 4.847 seconds

Cornerstone (master) on Chrome 53 – 20.370 seconds

Cornerstone (dev) on Chrome 53 – 6.693 seconds

Cornerstone (dev) on FireFox 48 – 6.832 seconds

Cornerstone (dev) on Safari 10 – 8.040 seconds

Cornerstone (dev) on Opera 39 – 6.882 seconds

Cornerstone (dev) on Chrome 53 in Windows 7 VM – 7.899 seconds

Cornerstone (dev) on IE 11 in Windows 7 VM – 17.832 seconds

Cornerstone (dev) on Edge in Windows 10 VM – 11.994 seconds

​

​

​

> 300% Speed Improvement!

Only 50% slower than Native!

Image Creation Code Refactoring

ImageFrame object

• Describes the image frame independent of the actual metadata
• Created by cornerstoneWADOImageLoader.getImageFrame()
• Which populates object by calling metadata provider

CreateImage() API

• Actually creates the image
• Dependency on ImageFrame allows code to be reused between different image loaders
• Currently used by wadouri, wadors and dicomfile image loaders

Dealing with Bad DICOM

Two approaches to dealing with bad DICOM:

• Add logic to deal with every case (dcmtk)
• Strictly standards compliant with hooks to override (cornerstone)

How to override?

• Metadata provider!

​

MetaData Providers

An optional priority can be specified when registering the metadata provider

• Metadata providers are invoked from highest priority to lowest
• Built in metadata providers use default (0)

​

To override DICOM, use a priority higher than the default (0)

• Otherwise the default metadata provider will respond

​

MetaData Providers are the future

All CornerstoneTools will be updated to use metadata provider

Image object may change (e.g. pixel spacing removed)

​

WADO-RS Retrieve Frame

Test data now included

Bug fixes

Refactored to use new image creation flow

Still has not been validated against any real implementations

• Help?

Demo

chafey@statrad.com for more information

Standalone Viewer

Standalone Viewer

• Developed with Meteor and bundled for client-only usage
• No study list, no user accounts, just a basic viewer
• Easily embeddable into your applications
• Currently uses built-in route
• Example:
• baseUrl.com/testId will attempt to load a JSON file from baseUrl.com/api/testId
• Available on Github in OHIF/Viewers repository:
• https://github.com/OHIF/Viewers/tree/master/StandaloneViewer
• Loads studies from JSON description with Image URLs
• Uses CornerstoneWADOImageLoader and CornerstoneWebImageLoader to support various file types

Standalone Viewer

• Example JSON:�

{

"studies": [{

"studyInstanceUid": "23.23.21.3.32",

"patientName": "Patient Name",

"seriesList": [{

"seriesInstanceUid": "1.33.2.32.1.2.1.3.2",

"seriesDescription": "COR T-1",

"instances": [

{

"sopInstanceUid": "1.2.3.2.32.18.10",

"url": "dicomweb://cornerstonetech.org/images/ClearCanvas/MRStudy/1.2.840.113619.2.5.1762583153.215519.978957063.136.dcm"

}

]

}]

}]

}

Recent Contributions

Recent Contributions

​

• Focused on Cardiovascular IT & Structured Reporting
• Contributions
• Improved display set navigation in viewports
• Added next / previous display set buttons and hotkeys
• Improved CINE dialog usability, especially for US Echo
• Always visible play controls, streamlined UI
• Application-level configuration
• Added optional configuration for sidebar display behaviour
• Improved thumbnails for multi-frame
• Clarified display set details
• Now includes includes instance number and number of frames
• Added multi-frame support in Hanging Protocols

​

(http://www.ascendhit.com/)

Questions?

https://groups.google.com/forum/#!forum/cornerstone-platform