Tidepool Informational Pre-submission Meeting Prepared for FDA CDRH June 2, 2015 Tidepool attendees: Howard Look, President and CEO (phone) Brandon Arbiter, VP Product and BizDev (phone) Sheila Ramerman, Consultant
Agenda: Mission Goals Strategy Quality System Overview
Agenda Review Tidepool Milestones and Timelines Review Tidepool s Current Applications: Blip, Blip Notes and Tidepool Uploader Review Tidepool s Regulatory Pathway Overview of Tidepool Architecture (data integrity, security and HIPAA compliance) Review Tidepool s Quality System and Development Practices 1) Tools 2) Processes.
Our Mission Tidepool s mission is to deliver software that will reduce the burden of managing T1D. Non-profit: Everything we do must benefit the entire T1D community. Open: Everything we do is open for inspection at all times. Code, processes, strategy, quality system. Apps: We will deliver applications that reduce the burden of managing T1D. Platform: Our applications won t be the only ones. Our platform enables an ecosystem of diabetes applications for PwDs, healthcare providers and researchers.
Development and Quality System Strategy and Goals Engage early and often - be transparent about everything that we do. Use agile software development - iterate based on feedback to make our products and platform better. Implement a quality system that embraces agile and uses modern software development tools. We are inspired by patterns in AAMI TIR-45. Make our software and quality system freely and openly available so that it can have maximum benefit.
Regulatory Pathway Based on in-person review with FDA, October 13, 2014 (links: Pre-submission, Approved Notes) Tidepool Uploader: MDDS Blip: Choosing (and documenting) Class-I/Exempt Registering Tidepool and Listing Blip, Blip Notes, Tidepool Uploader, Tidepool Platform, establish AER + CAPA Internally Documenting per 11 CFR 820 Preparing to support Class-II and Class-III products built upon Tidepool Platform. Will file Master File with first partner.
Tidepool Apps and Timeline
Tidepool Uploader + Medtronic CareLink Compatible Development made possible by
Tidepool Uploader Indications for Use The Tidepool Uploader is intended for use by Users wishing to access and upload data from diabetes devices including insulin pumps, continuous glucose monitors and blood glucose meters for the purpose of making that data available to other devices or software applications. Users includes, but is not limited to: People with diabetes aged 13 and up using diabetes devices, researchers, clinicians and caregivers. The Tidepool Uploader may be used anywhere diabetes devices are used and an Internet connection is available.
Blip The hub of your diabetes data. Designed in partnership with UCSF Currently in IRB-approved pilot study at UCSF Currently in use for Jaeb ReplaceBG study Apps like Blip and Nutshell help make diabetes self-care more visualized, educational and effective. - Jiangfang Fei, JDRF
Blip Indications for Use Blip is intended for use by Users wishing to review data from one or more diabetes devices including insulin pumps, continuous glucose monitors and blood glucose meters. Users includes, but is not limited to: People with diabetes aged 13 and up using diabetes devices, researchers, clinicians and caregivers. Blip may be used anywhere an Internet connection is available.
Tidepool Platform Indications for Use The Tidepool Platform is intended for use by cloudbased software systems and services to store and retrieve diabetes data. Diabetes data may also include contextual information and other personal health data. The Tidepool Platform may be used anywhere an Internet connection is available.
Milestone Timeline 2013-03 - Tidepool Founded 2013-06 - Tidepool Funded 2013-10 - Team hired, Development underway 2014: Asante, Dexcom, Insulet, Tandem, Abbott 2014-05: Blip Pilot Study at UCSF 2014-10: FDA Regulatory Pathway defined 2015-01: Blip and Uploader Closed Beta begin 2015-03: Jaeb/T1DExchange Replace BG study begins TARGET Summer 2015: Blip and Tidepool Uploader Open Beta
Architecture Security Data Authenticity
Public Internet Amazon Web Services Production Production Environment Environment Staging Staging Environment Environment Development Environment MongoDB Master MongoDB Slave MongoDB Slave Production DB Cluster S3 Backup HIPAA-Compliant Dedicated Instances Ephemeral Encryption Availability Zones MongoDB Master Staging/Dev DB
Public Internet Elastic Load Balancer (ELB) and Firewall Software Load Balancer Styx Software Load Balancer Styx Service Registration and Discovery Hakken Service-oriented architecture. Small pieces, loosely joined. Private, internal network. Can (and do) deploy services independently. User Accounts Shoreline User Permissions Gatekeeper User Metadata Seagull User Confirmations (new account, passwords) Hydrophone Device Data Ingestion Jellyfish Device Data Access Tide Whisperer Device Data Query Octopus Messages/Notes Application Server
Security Physical: Provided by Amazon Server Process: All services behind firewall, no public access Encryption x 4: Transport, User Metadata, Device Data, Filesystem Data in Transit: All data carried over https/tls Data Separation: PII, Meta Data, Device Data encrypted separately with one-way hash Encryption at rest: Ephemeral filesystems by Amazon Employee Practices Strong passwords, 2-factor authentication, encrypted filesystems
One-way Data Encryption User Data User Metadata Patient Data Device Upload Key: User ID Key: Metadata ID Private Patient ID Private Upload ID Email address (unique ID) Password hash User Profile User s Groups Private Patient ID + hash PHI - Diagnosis Date PHI - Demographics Uploaded Data Private User ID + hash Private Data ID + hash Encrypted with UserID hash System-level encryption with long deploy salt Group Group ID Members Ephemeral Filesystem Encryption (keys unknown to Tidepool)
Tools
Using Modern Tools Tenet: Use modern tools that enable rapid, iterative agile development while conforming to FDA and ISO quality system requirements Tools we use: Google Docs - versioned document tracking Trello - requirements tracking, project management and bug tracking GitHub - source code control Digital Signature Requirement: Two-factor auth + unique IDs + password + encryption
Google Docs All document edits and revisions maintained. All documents retained in perpetuity. Enterprise-level backups. Two-factor authentication required. Documents under change control by user: Only authorized individuals can make edits. Examples: Blip Requirements Specifications. Verification Tests. Design History File.
Trello Trello Boards track requirements (at epic and task level) and execution against requirements Design History File references Trello cards. One Board per Sprint. Each sprint lasts 2-3 weeks. Each board has Lists : Epic, Potential for Sprint, In Sprint, Ready for Review, Ready for Deploy, Deployed to Dev, Deployed to Staging, Deployed to Prod Audit trail of all changes maintained. Authentication via Google two-factor auth. Complete redundant backups with all changes and audit trails maintained
Trello - Sprint Board (requirements and tasks)
Trello - Sprint Board (verification, validation and release)
Design History File = Trello Cards + Google Sheet
GitHub Modern, versioned Source Code Control system Version history for all changes maintained Pull Request - a request to review and incorporate a change ( please pull my change ). Only authorized Tidepool employees can review and merge changes. Tidepool is the curator for all changes. Tags for each deployment build - can track exactly which version of software was deployed Two-factor authentication for all Tidepool employees and contractors.
GitHub Tags: Complete Representation of Release
Verification and Validation Verification: Does it work as specified? Automated + Manual Testing Validation: Does it solve the customer s needs? Prior to development: User interviews Beta participant validation: Homework assignments
Testing Tools Automated Builds and Tests Travis CI, Jenkins Tests run with every GitHub commit, even work in progress Primary source of data and code verification Manual Tests UI Functionality Verification Philosophy: When a bug occurs, ask What is the automated test that could have caught that?
Automated Tests Repository Description Language Production Version Latest Travis Build # Passing Tests (lower bound) jellyfish data ingestion API JavaScript 0.8.6 277 700 tideline data Visualization in Blip JavaScript 0.1.20 200 343 chrome-uploader Tidepool Uploader chrome app JavaScript 0.117.0 982 311 shoreline logins and user accounts JavaScript 0.5.1 170 107 sundial time-handling utility library JavaScript 1.1.8 157 106 platform-client browser-side library for interacting with the tidepool platform JavaScript 0.16.5 88 36 octopus data query API Go 0.3.1 121 34 message-api notes, messages JavaScript 0.3.11 192 30 hydrophone notifications API to send messages to users for things like forgotten passwords, initial signup, Go 0.3.5 220 19 go-common common functionality Go v0.0.10 85 13 blip Blip application JavaScript v0.5.14 1549 1
Manual Tests (each has multiple sub-tests) Blip Daily View Test Script Template Blip - Data Visualization Module: Daily View - Notes 1.0 Blip Global Navigation Test Script Template Blip - Global: Navigation 1.0 Blip Select a Person Test Script Template Blip - Select a Person 1.0 Blip Daily View - BG and CGM [Incomplete] Test Script Template Blip - Data Visualization Module: Daily View - BG Blip Daily View - BG and CGM and CGM 1.0 [Incomplete] Test Script Template Blip - Data Visualization Module: Daily View - Basal Blip Sign Up: Account Creation 1.0 Test Script Template Blip - Sign Up: Account Creation 1.0 Blip Weekly View Test Script Template Blip - Data Visualization Module: Weekly View 1.0 Blip Trends View Test Script Template Blip - Data Visualization Module: Trends View 1.1 Blip User Settings: Profile Test Script Template Blip - User Settings: Profile 1.0 Blip User Settings: Account Test Script Template Blip - User Settings: Account Settings 1.0 Blip Device Settings [Incomplete] Test Script Template Blip - Data Visualization Module: Device Settings Blip Daily View - BG and CGM 1.0 Test Script Template Blip - Data Visualization Module: Daily View - Bolus 1.0 Blip Log In: Email Verification Test Script Template Blip - Log In: Email Verification 1.0 Blip Forgot my Password Test Script Template Blip - Forgot My Password 1.0 Blip Sign Up: Data Storage Test Script Template Blip - Sign Up: Data Storage 1.0 Blip Log In: Primary Splash Test Script Template Blip - Log In: Primary Splash 1.0 Blip Sign Up: Terms of Use Test Script Template Blip - Sign Up: Terms of Use 1.0 Blip Trends View Test Script Template Blip - Data Visualization Module: Trends View 1.0 Blip Metrics Test Script Template Blip - Metrics 1.0 Blip The Basics Test Script Template Blip - Data Visualization Module: The Basics 1.0 Blip + Uploader Comprehensive Smoke Test [In Progress] Rapid/Smoke Test for PC/Mac and all applications V1 Uploader Omnipod Test Script Template Uploader - Omnipod V1.3 Uploader Dexcom Test Script Template Uploader - Dexcom V1.0
Standard Operating Procedures SOP Reference Title SOP-0001 Control of Documents SOP-0002 SOP-0003 SOP-0004 SOP-0005 Control of Records Employee Qualifications and Training Corrective and Preventive Action Design, Development and Release