Demonstration of Electronic Health Records (EHR) on Java Card 3.0 Technology-Based Devices

Transcription

1 BOF-4576 Demonstration of Electronic Health Records (EHR) on Java Card 3.0 Technology-Based Devices Nicolas Anciaux Jean-Jacques Vandewalle

2 Overview Show a real deployment of Java Card 3 devices in the context of an experimental health care system Consortium (called PlugDB) supported by builds the system Leader: DBMS technology Java Card 3 devices Health app. Data integration Practitioners organizations Experimental deployment (called DMSP) supported by the French authority of the Yvelines district Field deployment starting Oct. 2009

3 Agenda > Functional description: a health care systems with one personal server per patient to store her medical records > Technical details about the personal server architecture > The Java Card 3 platform > The embedded DBMS > Live demonstration > Discussion

4 Agenda > Functional description: a health care systems with patient s personal server to store their medical records > Technical details about the personal server architecture > The Java Card 3 platform > The embedded DBMS > Live demonstration > Discussion

5 E-health records (EHRs) requirements > Availability at patient s home > Accesses to EHRs must be guaranteed at patient homes > Even without a (secure, fast and reliable) a network link > Care coordination between practitioners > Centralizing data on a server provides completeness, internet access, consistency, durability > But citizens may be reluctant to adhere because of a justified or perceived loss of control > Protection and sharing of patient data > Enabling patients to control their sensitive data while allowing data sharing

6 Availability at patient s home > EHR on a personal server > Access from a browser (on a netbook) by patient s visitors (doctors & social workers, family ) Personal Server Disconnected access to Personal Servers (1 / patient)

7 Care coordination between practitioners > EHRs on a central server > Web access & exchange > Sync. via Smart Badges > No data re-entered > No network link required > EHR on a personal server > Access from a browser (on a netbook) by patient s visitors (doctors & social workers, family ) External Personal Server Sync. with central server via Smart Badges (1 / practitioner) Smart Badge

8 Protection and sharing of patient data > Patients control the sharing of their data by deciding among 3 levels of accessibility > A solution compatible with care coordination Regular Data Stored classically on the central server, replicated in the personal server Confined Shared among a reduced circle of trusted persons. Stored encrypted on the central server; encryption keys are stored in the smart badges or in the personal server Authentication via Smart Badges Secret Data Stored exclusively on the personal server

9 The personal server complements the central server > Better coordination of care > Simple and fast access everywhere (with or without) a network link > Synchronized content in disconnected and connected servers > Increases the patient s trust in the EHR system > Patients can mask their data by deciding among 3 levels of accessibility > Sound and innovative technologies > Similar software chain on personal servers and central server > Compliance with standard protocols and development tools Real-life experimentation with a field deployment Oct in the context of a medical & social network providing medical care and social services at home for elderly people

10 Focus on personal server > Embeds a Java Card 3 platform and a DBMS in a secure chip with a large storage capacity Javacard 3 Serveur web + + DBMS SGBD Smart chip FLASH Health care records

11 Agenda > Functional description: a health care systems with patient s personal server to store their medical records > Technical details about the personal server architecture > The Java Card 3 platform > The embedded DBMS > Live demonstration > Discussion

12 Usage of Java Card 3 Serveur web + SGBD Java Card 3 UI web app Smart chip JDBC API DBMS FLASH Health care records Patient s personal server Sync. web app Java Card 3 Smart chip Sync. files File System API FLASH Practitioner s smart badge

13 Java Card 3 web apps > Sync. web app. on practitioner s smart badge > Opens an HTTPS client connection to target server (patient s personal server or central server) > Authenticates with TLS > Fetches or sends a synchronization file from/to the target server > UI web app. on patient s personal server > Works through an HTTPS server connection > Checks user s credentials with TLS > Enables to read/add patient data via HTML pages and forms (same GUI as the one on the central server) > Reads/adds records to the DB through the JDBC API

14 Value added to Java Card 3 DB records FLASH > A complete embedded software chain usually found on traditional servers > Web Apps Web container JDBC API - DBMS DB records on Flash > Compliance with standard protocols and development tools Web App Web App Servlet Servlet Servlet Servlet Servlet API Web Container HTTP(S) SSL (TLS) TCP/IP USB JDBC API DBMS Not in the JC 3 specs

15 Java Card 3 JDBC API: a subset of the Java 2 JDBC API > Supports DML SQL statements that are enriched with hints > Hints are passed as comments at the end of the SQL query > Hints are used by the DBMS query processor to generate execution plans > Supports few java.sql.types > CHAR(512), VARCHAR(512), DATE, NUMBER and BINARY > Supports subsets of java.sql classes for > Connecting (Connection, Driver, DriverManager) > Executing statements (Statement, PreparedStatemant) > Retrieving execution results (ResultSet, ResultSetMetadata) > Consistency (Date, SQLException, )

16 Challenges of the embedded context From the DBMS point of view A few KBs of RAM to manage large amount of data (MBs to GBs) RAM NAND not part of the secure chip Security DBMS Query processing Transactions Access control Cryptography Indexation / Storage RAM CPU NOR FLASH Crypto BUS NAND FLASH Health care records Updates Issues with NAND: Erase block before rewrite page Write sequentially in Flash blocks (64 pages) Limited lifetime (10^5 erase ops) Same issues with NOR (at different granularity)

17 DBMS features and challenges (1/2) SELECT queries > Joins and selections queries to recompose the GUI forms SELECT E.date, D.name, L.label, L.value FROM Form F, Doctor D, Event E, Line L WHERE F.id=E.fid AND D.id=E.did AND E.id=L.eid AND // joins F.name= X AND // selection(s)... // + control accesses > Efficient execution of selections and joins requires > Lots of working memory (computed hash tables ) > To maintain indexes (high rate random write structures) RAM Updates

18 Design approach Illustrated on query processing > Favoring sequential scheme for storage and indexing > Indexes are built from sequential summaries (patented) > UPDATE, DELETE: avoid rewrite in-place > Updated records are logged in NAND and indexed in NOR > Then, logs are read only when necessary > Massive indexation of joins (particular kinds of indexes) > climbing index similar to star join indexes in data warehouse > descending index store relations between tables Updates RAM

19 DBMS features and challenges (2/2) Other illustrations > INSERT, UPDATE, DELETE queries > A lot of updates required for indexes maintenance > Processing of synchronization files > Performance: batch processing of INSERT, UPDATE, DELETE > Support of transactions needed because a full HTML form is stored via a set of INSERT queries > Atomicity: Flash provides no guaranty against write/erase failure > Complex access control for health care enforced by law > Even more complex queries (with implicit joins and selects) Updates > Crypto protected data in Flash > Crypto works on large grain, DBMS on small grain Security

20 Summary of technologies used for the embedded DBMS Massive indexation; Join indexes are climbing / descending indexes DBMS Query processing Transactions Access control Cryptography Indexation / Storage Local atomicity and recovery by undoing last actions; Durability by synchronization A new masking model called E-BAC (Event-based access control) Encryption scheme enabling processing on encrypted values (equality-selections) Update/delete out of place (log in NAND); Indexes build of sequential summaries

21 Agenda > Functional description: a health care systems with patient s personal server to store their medical records > Technical details about the personal server architecture > The Java Card 3 platform > The embedded DBMS > Live demonstration (beware! French language inside ) > Discussion

22 Demonstration scenario One patient (PAT) equipped with a personal server One doctor (DOC) equipped with a smart badge One central server auth. sees 1. PAT browses her records on her personal server at PAT s home PAT authenticates with her PIN code PAT sees all the records 2. DOC browses the PAT s records on the PAT s personal server at PAT s home DOC authenticates with his own smart badge DOC sees only medical records (and not social records) DOC adds a new medical record DOC uploads a synchronization file from the PAT s personal server to his own smart badge auth. sees adds sync. 3. DOC browses the PAT s records on the central server from his office DOC authenticates with his own smart badge DOC sees PAT s records on the central server DOC uploads the synchronization file from his own smart badge to the central server DOC sees the new record added thanks to the synchronization auth. sees sync.

23 Agenda > Functional description: a health care systems with patient s personal server to store their medical records > Technical details about the personal server architecture > The Java Card 3 platform > The embedded DBMS > Live demonstration > Discussion

24 What you ve seen > Real life use case of Java Card 3 Connected Edition with a health care smart USB key > EHR data stored on a NAND-flash managed by an embedded DBMS > Accessed by Java Card 3 web apps using a JDBC subset > Hosted on a Java Card 3 Connected Edition Web platform > Java Card 3 web apps reproduce identically the central server health care application > Synchronized with remote servers via usage of practitioners smart badges > Hardware: smartcard microcontroller + NAND Flash > Form factor: USB Key and SmartBadge (but not limited to)

25 What you may wonder > In the health care sector, decentralized personal servers have a value as complementary to central servers > Could such a solution also complement initiatives like Google Health or Microsoft Vault? > Data on personal server could also be mashup ed with remote data while there are accessed at a connected point? > Could it be applied to other business sectors? > Embedded Flash-based DBMS and Java Card 3 Connected Edition are key technologies for personal server in small chips: web platform + database on Flash > What are the technical alternatives for personal servers?

26 Wrap Up > Java Card 3 Connected Edition is a mature technology for embedded personal server applications > Embedding DBMS with data in NAND Flash enables management of complex data even in small chips > We hope coming back next year, discussing ROE about this first deployment starting Oct. 2009

27 Contacts INRIA Nicolas Anciaux +33 (0) Gemalto Jean-Jacques Vandewalle +33 (0) More information at Jean François Navarre +33 (0)

28