BMC Genomics 2006, 7:93 http://www.biomedcentral.com/1471-2164/7/93 that all patients will be genotyped at some point in their lives, and that gene expression levels will be measured for many serious ailments. Concurrently with these signifi- cant technical developments, the Internet has made patients markedly more autonomous in medical decision making, perhaps even more knowledgeable than care pro- viders, particularly in the realm of genetic testing [9-12]. A new type of clinical data Currently, the most efficient way to genotype "most of"a human being is to genotype tag SNPs according to the HapMap [13], which is expected to highlight close to 600,000 SNPs that identify most of the clinically-useful genetic diversity. In addition, specific, larger mutations need to be checked, including large deletions or inser- tions. Considering necessary redundancy for indexing of partial records, the size of a single patient's genome sequence might quickly reach 3 or 4 megabytes. Gene expression level datasets like the popular Affymetrix U133 Plus 2.0 platform [14] consider close to 54,000 RNA tran- scripts, which requires approximately 500 kilobytes of storage, including indexing. For long-term quality assur- ance, one may want to store raw instrumentation data, which increases the size of a single transcriptome to 12 megabytes. The size of these data, though much larger than typical diagnostic tests, is not entirely unprece- dented: MRIs and other imaging results can require many megabytes of storage, too. The key difference is in the granularity of the data. While an MRI is generally shared as an atomic block of data, a patient will not likely want to share his entire genomic data, as it has been shown that a mere 20 randomly chosen SNPs are enough for unique, perpetual identification [15]. Instead, within these tens of megabytes of genomic data, a patient might want to share a few SNPs with his doctor, nothing more. Even the exist- ence of test results against other SNPs, particularly as the genomic tests are not yet complete scans of the HapMap, should remain private. Thus, genomic data should be treated as a very large sequence of small results. Each result is clinically mean- ingful (e.g. a BRCA1 allele), and a small handful of results is enough to genomically fingerprint an individual. In other words, the management of genomic data presents a significant challenge: how can we efficiently store and retrieve patient genomic data while respecting strong pri- vacy constraints? Implementation Extension of PING GenePING, as its name implies, is an extension to the Per- sonal Internetworked Notary and Guardian (PING) health record management system [16,17]. PING allows patients and health-care providers to share health record data with access control rules defined by the patient. All data is exchanged in XML with publicly-defined schemas, and the protocol is implemented using XML over HTTP (preferably HTTPS). The data store itself persists as a set of encrypted objects, thereby reducing the threat of disclo- sure from discarded or mismanaged disk drives that have been widely reported [18]. PING also includes a Java cli- ent, PING Display, which GenePING also extends to present the user interface. Other groups are developing alternative open source PING clients, including ones that use dynamic HTML. On the back-end, GenePING is a revamp of the PING low-level storage and high-level med- ical document organization, in order to enable the secure storage of fine-grained genomic data. The threat model is left unchanged: the PING server remains a semi-trusted information broker with the keys to an encrypted data store. In addition, the new GenePING storage system addresses the specific threats of genomic data leakage combined with the efficiency requirements. On the front-end, GenePING integrates into the default PING client (Figure 1). Patients can view their genotype labs listed much as typical lab results (Figure 2). A single lab can be browsed incrementally, one set of SNPs at a time (Figure 3). Data storage GenePING defines a variable-size, keyed-block, low-level storage interface. This interface behaves much like a per- sistent hash table, and the underlying implementation of this interface is expected to support hundreds of millions of records. Possible implementations of this storage inter- face include a raw filesystem, a SQL database, an object store, or some distributed storage mechanism. The default GenePING uses Berkeley DB for Java [19], a transactional block store whose functionality maps closely to the PING interface API. Before the data is stored via this low-level interface, it may be altered for various purposes. The GenePing Store interface supports generic extensions, each of which can, in turn, modify the name and value of the stored record. Once these extensions are registered, the name-and-value changes are applied automatically upon interaction with the block storage interface. Storage exten- sions can be particularly useful for data compression, data encryption, and obfuscation. Security and obfuscation The GenePING server requires two cryptographic keys to find and decrypt its data: an HMAC key [20] for hashta- ble-name obfuscation, and an AES key [21] for hashtable- data encryption. Without both these keys, the raw storage is useless (to an attacker, for example). In a production GenePING installation, these two keys are expected to be loaded into RAM from an administrator's secure token. They should never be stored on disk. Page 2 of 10 (page number not for citation purposes)