+

Developing Software for Mobile HealthCare Ian Darwin

Centre for Global eHealth Innovation

UHN, Toronto

Outline

  What are the special challenges and benefits of developing in a healthcare setting?

  How are the rules different, and why?

  Who are the standardization/regulatory players and how do they affect development process?

  What are the main mobile platforms, and what limits do they impose on what we can do?

My background

  Mainframe Systems Prog, Unix Admin/Network Dev

  Java dev (Java Cookbook)

  Android dev (Android Cookbook)

  M.Sc (research in Java V&V tools)

  Freelance instructor with Learning Tree Int'l

  Currently at UHN's Centre for Global eHealth Innovation

+ Why are we here?

April, 1915

Fail

January 2012

Fail

November, 1940

Fail

1907 and 1916

Fail Fail

June 23, 2012

Fail

July 6, 2013

Fail

July 6, 2013

Fail

1980’s

Therac-25

Fail

Where does this disaster movie lead?

  People do stupid things

  We establish standards and/or pass laws

  People still do stupid things, but less often

  Transportation, building, and medicine get greatest scrutiny   Not to mention politics, “wars to end all wars”, …

  We don’t give up on technologies even when they sometimes fail: we must learn and move on

The Mobile Opportunity

  Current mobile platforms lower barriers to entry of new entrepreneurs   Help people – vast opportunities

  Save the health care system money - huge

  Make money – possibility of massive sales x small profit on each

  At the same time…   Avoid the mistakes of the past!

Ways of classifying mobile apps

  Those that use special hardware (weight scale, glucose, BP, pulse, pedometer)

  Those that use a RESTful web service for data

  Those that give medical advice

+PART I: Standards and Regulators

IEC 62304

  "Medical device software: Software life cycle processes"

  International Electrotechnical Commission, Geneva, Switzerland

  Mandates a Quality Management System, Risk Mgmt, Software Safety Classification

  Describes software dev process: planning, requirements, architecture, software design, unit implementaiton & testing, system testing, release, maintenance.

  Emphasis on risk management, problem resolution

  62304 not a requirement, but a "gold sticker"

  Due to be updated: 2e due 2014-01-31

ISO 13485:2003

  ISO std for "Medical devices: Quality management systems"

  Adopted as "National Standard of Canada CAN/CSA-ISO 13485:03"

  Applies to an organization; harmonized with ISO 9000 certification but specific to medical devices

  Not technically mandatory, but the easiest way to medical device approval for licensing

  Focus: documenting all the steps of development

13485 Requirements for a Quality Management System   Focus is on documentation and risk mitigation

  Requires:   Project charter

  Product Requirements Document

  Design and Development Plan

  Verification/Test Plan

  Risk Management Plan

  Design Files History – hardware and software change logs

  Product Change Management process documentation

  Extra requirements for implantable devices, sterile devices/supplies, etc., in the medical area.

  Get expert consultant/auditor involved early!

13485 Requirement for Control

  Using outside services not under your control   Not allowed (unless 13485 certified, or you audit…)

  e.g., we had to switch from private account on public GitHub.com, to GitHub Enterprise in-house, on our own server

  In-house contractors   OK if individuals are trained in, and agree to follow, 13485 process

  Outsourcing   Possible - Only to reputable companies that are 13485 certified

  Offshoring   A definite no-no as you cannot usually reliably verify their

processes

Health Canada

  Regulations SOR/98-282   supporting Canada's "Food and Drug Act"

  regulates medical devices

  Four categories (I is least risk, IV is most); 6 pages of rules

  Examples:   Class I: Physical contact e.g., surgical instruments

  Class II: Full-time contact, some invasiveness, e.g., contact lenses, ultrasound scanner

  Class III: More invasive, deep implantation, e.g., orthopedic implants, hemodialysis machines

  Class IV: Total dependence, e.g., cardiac pacemakers

FDA

  United States Food and Drug Agency

  USA Your biggest market?

  FDA's Center for Devices and Radiological Health (CDRH) regulates Medical Devices

  Class I: General controls, e.g., surgical instruments

  Class II: General controls with special controls: performance expectations w/ no harm, e.g., hemodialysis machines

  Class III: General controls and premarket approval; most risk, e.g., cardiac pacemaker

So where does this leave mobile apps?

  HC: If the medical device can be used normally without the need for the computer or smartphone, then the software on the computer or smartphone is not part of the medical system, is not a medical device, and is therefore not regulated.   This is the case for our application bant.  The meter can operate without bant,

so bant is not medical device.

  FDA "accessory rule": a smartphone connected to medical device creates a medical system.  The software on the computer and/or smartphone is also a medical device and must be licensed.

  In either country, software providing "decision-making" or "sophisticated decision-support” can be ruled a medical device.  E.g. software that recommends a a diagnosis, therapeutic course of action, medications, etc. that could be potentially life-threatening given errors in the software.  Such software must be built using a quality system (ISO13485) and obtain a license as a medical device.

Agile Development Process

-- http://agilemanifesto.org/

Can you do Agile under 13485?

  Yes.

Canada Health InfoWay

  Quasi-government body funded by Govt of Canada

  In support of adoption of technology, EHR/EMR, etc.

  "Infoway works as a strategic investor of funds provided by the Federal Government, in collaboration with the provinces and territories."   e.g, disburses funding to researchers and startups

  Certification, testing, working with startups

Continua

  Works on standards for inter-operability of medical devices and controllers (smartphones, tablets, computers)

  Holds inter-operability tests around the world

  All major equipment vendors are on-board with this

IEEE

  Institute for Electrical and Electronic Engineers publish standards for electronic communications   Ethernet

  802.11

  Currently working on standardization for communication with Insulin Pump and Glucometer, to allows pluggable components in JDRF Artificial Pancreas program   Two of these standards being developed by Centre staff!

Organizational Regulations and REB's

  University and Hospitals have own rules about e.g., experiments

  Research Ethics Board must approve any experimentation involving human subjects, no matter how simple

  E.g, we can't even do "coffee shop prototyping" without REB!   Unless it's for a new app

  For existing app, need approval, must document, must use Change Reporting (13485) for resulting changes

+PART II: Mobile Platforms and eHealth

Mobile Platforms

  As Mike O’Dell said (long ago, talking about Unix platforms):   “If you think there will ever be a single platform vendor, you

should be out selling pencils.”

  Currently we have:   Android

  iOS

  BlackBerry (7 is dying; 10 is new but small)

  Windows 8 Mobile

Cross-platform or platform-specific Apps?

  Possible to build simple apps as HTML5 web app and repackage as a mobile app   Not suitable for most health apps that need external devices

  See my one-hour talk on cross-platform mobile dev

  See http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

Android

  Great platform for ease of entry   Many languages: Java, C/C++, Ruby, Python, LISP-based, etc

  Free tools: sdk, Maven, Eclipse+ADT, IntelliJ Android Studio

  App market $25 per company, fast acceptance, post-testing

  Pro   Many good devices to choose from (many vendors)

  Open platform

  Con   Replaced entire Bluetooth stack recently

  No platform-wide support for BLE until fall 2013

Apple

  Good platform for ease of entry   Your choice of Objective C or Objective C (or HTML5)

  free tools XCode

  App Store $??, slow acceptance - pre-testing

  Need to sign in even to find the price :=(

  Pro: Largest single market sector

  Con: Funny connectors that keep changing - hardware engineering

BlackBerry 10

  BlackBerry finally (late) switches to *Nix platform QNX

  Good platform for ease of entry   Free tools (Eclipse-based)

  C++ with Qt and Cascades or Flash or HTML5

  App market free, medium acceptance

  Pro:   Good devices and software (teething pain)

  N.B. Good support for BLE

  Only con: Lack of consumer confidence

Two Birds, One Stone?

  Android apps can be re-packaged for BB10   No recompilation!

  Free tools for this too

  Downside:   No Bluetooth

  No "native library" code

  Not platform-centric (doesn’t “look” like native BB app, no integration with BB value-adds like Hub, Messaging).

  Best use: quick get-started app, or, app with only network requirements (no devices, no platform code)

Windows 8 Mobile

  Last but by no means least (currently in fourth place)

Conclusions

  Medical App Dev is a terrific opportunity!

  Medical App Dev is more regulated than most fields

  You should follow ISO-13485 from the outset

  You MAY need Health Canada/FDA licensing