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

Demonstration of

Electronic Health Records

(EHR) on Java Card™ 3.0

Technology-Based Devices

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

Experimental deployment (called DMSP)

supported by the French authority of

the Yvelines

district

Overview

Practitioners’ organizations Leader: DBMS technology Java Card 3 devices Health app. Data integration

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

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

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

>

EHR on a personal server

>

Access from a browser (on

a netbook) by patient’s

visitors (doctors & social

workers, family…)

Availability at patient’s home

Personal Server

Disconnected access to Personal Servers

Care coordination between

practitioners

@

>

EHR on a personal server

>

Access from a browser (on

a netbook) by patient’s

visitors (doctors & social

workers, family…)

>

EHRs on a central server

>

Web access & exchange

>

Sync. via Smart Badges

> No data re-entered

> No network link required

Sync. with central server via Smart Badges

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

Confined data

@

Secret Data

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

Stored classically on the central server, replicated in the personal server Stored exclusively on the personal server Authentication via Smart Badges

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. 2009 in the context of a medical & social network

Focus on personal server

>

Embeds a Java Card 3 platform and a DBMS in a

secure chip with a large storage capacity

Health care records Serveur web + SGBD FLASH Smart chip Javacard 3 + DBMS

>

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

Usage of

Java Card 3

Sync. web app

Java Card 3

Java Card 3

UI web app

Java Card 3

Java Card 3 Smart _chip FLASH

J D B C A P I Smart chip FLASH Practitioner’s smart badge Health care records DBMS

File System API Sync.

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)

Not in the JC 3 specs

Value added to Java Card 3

>

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

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

> CHAR(512), VARCHAR(512), DATE, NUMBER and BINARY

>

Supports subsets of

classes for

> Connecting (Connection, Driver, DriverManager)

> Executing statements (Statement, PreparedStatemant)

> Retrieving execution results (ResultSet, ResultSetMetadata)

Same issues with NOR (at different granularity) A few KBs of RAM to manage large amount of data (MBs to GBs)

RAM CPU Crypto Query processing Transactions Cryptography Indexation / Storage Access control

D

B

M

S

Issues with NAND:

• Erase block before rewrite page

• Write sequentially in Flash blocks (64 pages) • Limited lifetime (10^5 erase ops)

NOR FLASH

NAND not part of the secure chip

BUS

RAM

Updates Security

Challenges of the embedded

context

>

Joins and selections queries to recompose the GUI forms

>

Efficient execution of selections and joins requires

> Lots of working memory (computed hash tables…)

> To maintain indexes

(high rate random write structures)

DBMS features and challenges

(1/2)

SELECT

queries

RAM

Updates

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

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

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)

> Crypto protected data in Flash

> Crypto works on large grain, DBMS on small grain

Updates

Encryption scheme enabling processing on

encrypted values (equality-selections) Massive indexation;

Join indexes are climbing / descending indexes

Query processing Transactions Cryptography Indexation / Storage Access control

D

B

M

S

Summary of technologies used

for the embedded DBMS

A new masking model called E-BAC (Event-based access control)

Update/delete out of place (log in NAND);

Indexes build of sequential summaries

Local atomicity and recovery by undoing last

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

One patient (PAT) equipped with a personal server One doctor (DOC) equipped with a smart badge One central server

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

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

Demonstration scenario

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

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

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

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

Contacts

INRIA

Nicolas Anciaux

[email protected] +33 (0)1 39 63 56 35

Jean François Navarre [email protected] +33 (0)1 39 07 79 28

More information at

Gemalto

[email protected]