An SVG pattern is used to fill any SVG element such as a circle, line or rectangle. In this post I will give several examples of SVG patterns, and describe how they are constructed. The technical documentation on SVG 1.1 (Second Edition) can be found at http://www.w3.org/TR/SVG11/pservers.html.

Basic Setup of an SVG Pattern

The pattern is defined in a defs element in an svg element, and referenced in the fill attribute of the SVG element using a url link to the pattern. Shown below is a simple dot pattern. The dot pattern is made up of a circle element in a pattern element.

SVG Diagonal Dot Pattern

SVG Diagonal Circle Pattern

SVG Diagonal Stripes Pattern

SVG Grid Pattern

Permission System Advantages

The integration of the new permission system into Cleo allows us to:

1. Know who is logged into the application.
2. Know what requests users have made to the application, and provides a log of those requests.
3. Check that staff members have permission to view, add, change and/or update information in the database.
4. Create permissions that meet the needs of the organization using Cleo.

Permission System Roll-out

The permission system is being rolled out in phases.

• The first phase involved implementing the permission system in the administrative application admin, implementing the creation and control of staff member accounts and their permissions, and creating a reset password application to allow users to reset their passwords.
• In the second phase, the permission system was implemented in the Explore application. Each request by a staff member is checked by the permission system.
• In the third phase, the permission system will be implemented in the Operations application. Finer control of staff member permissions will be available to Cleo’s administrators.

Treatment queries are under the Query tab in Cleo’s Explore application; see Figure 1. Creating a Treatment query is a two step process. First the contents of the treatment table are selected. Then, the treatment table is filtered.

Figure 1
Queries Tab in Cleo’s Explore Application

Queries tab in Colabrativ’s Clinical Entry and Operations (Cleo) Explore application before the creation of any treatment tables, or any queries have been run.

Selecting Treatments Table Content

Treatments in the treatments tables are grouped by patient, and chronologically ordered by the start date of each treatment. There are a number of options that control the contents of a treatments table; each option is reviewed below.

Treatment Table Options

Option	Description
Treatments Included	Single Treatment adds a single treatment to each row in the treatments table, and is the default for the Treatments Included option. The Treatment and Post-treatment option adds both a treatment and the next treatment (post-treatment) to each row of the treatments table. If the treatment is the last treatment and if a Deceased or Last Contact or Lost to Follow Up event is after the last treatment, then the Deceased or Last Contact or Lost to Follow Up event is added as the post-treatment. The Pre-treatment to Post-treatment option adds three treatments to each row in the treatment table. As with the Treatment and Post-treatment option above, Deceased or Last Contact or Lost to Follow Up events can be the final “post-treatment” for a patient. The All Treatment option puts all of a patient’s treatments in a single row. As with the Treatment and Post-treatment and Pre-treatment to Post-treatment options above, Deceased, Last Contact or Lost to Follow Up events can be the final “post-treatment” for a patient.
There are five therapy types that can be included in a treatments table.
Include Chemotherapies	If checked, chemoetherapy events will be included in the treatments table.
Include Complementary Therapies	If checked, complementary therapy events will be included in the treatments table, such as treatments with Curcumin.
Hormone Therapies	If checked, hormone therapy events will be included in the treatments table, such as treatments with Tamoxifen.
Include Immunotherapies	If checked, immunotherapy events will be included in the treatments table.
Include Vaccines	If checked, vaccine events will be included in the treatments table, such as MUC1 Dendritic Cell Vaccine treatments.
The next four Include options add additional information to the treatment table, including the patient’s immunohistochemistry (IHC) and genetic results.
Include Agent 0 1 Columns	If checked, agent columns will be added to the treatments table. Each treatment agent in a treatment will have a 1 in the column labeled with that agent’s name. This option was designed to facilitate cluster analysis.
Include IHC Results	If checked, the H-score for each IHC test run on the patient’s specimen collected just prior to the treatment. e.g. pretreatment specimen, will be added to a column that uses the IHC test code as the column header.
Include Full IHC Results	If checked, the intensity, percent positive cells and H-score for each IHC test run on the patient’s pretreatment specimen will be added to the columns that use the IHC test code as prefix for the column header.
Include Genetic Results	If checked, the results for each genetic test, such as polymerase chain reaction (PCR), fluorescent in situ hybridization (FISH) or next generation sequencing run on the patient’s pretreatment specimen will be added to a column that uses the test code as the column header.
There are a number of situations in which one might not want to include the next treatment in a table. The next five options allow one to merge a number of difference treatment types into the treatment added to the treatments table.
Merge Neoadjuvant Treatments	If checked, neoadjuvant treatments will be merged with the following treatment. The start date of the neoadjuvent treatment will be used as the start for the merged treatment, if it is before the start of the treatment. A Neo flag will be added to the Flag column when a neoadjuvent merge is performed.
Merge HIPEC Treatments	If checked, Heated Intraperitoneal Chemoperfusion (HIPEC) treatments will be merged with the following treatment. The start date of the HIPEC treatment will be used as the start for the merged treatment, if it is before the start of the treatment. A HIPEC flag will be added to the Flag column when a HIPEC merge is performed.
Merge Maintenance Treatments	If checked, maintenance treatments will be merged with the previous treatment. The end date of the maintenance treatment will be used as the end date for the merged treatment, if it is after the end date of the treatment. A Main flag is be added to the Flag column when a maintenance merge is performed.
Merge Continuation Treatments	If checked, continuation treatments will be merged with the previous treatment. The end date of the continuation treatment will be used as the end date for the merged treatment, if it is after the end date of the treatment. A Cont flag is be added to the Flag column when a continuation merge is performed.
Simultaneous Treatments	If checked, treatments that overlap in time, but are of different treatment event types, e.g. a chemotherapy and a hormone therapy, will be treated as simultaneous. The agents in the simultaneous treatment will be added to an inserted Simultaneous Agents column.

Treatments Table Creation

Once treatments table options have been selected, the table can be created without applying any filtering to it by clicking on the “Create” button; see Figure 2. This is the only action that can be taken for the “All Treatment” Treatments Option. The treatments table creation options are disabled after a treatments table has been created, but the options used to create the treatments table are still displayed.

Prior to the creating the treatments table it is a good idea to supply a title in the “Query Title” box. The title may also be added after creating the table by filling in the “Query Title” box and clicking the “Update Title” button.

Once the treatments table has been created, it can be downloaded as a tab separated values (TSV) table by clicking on the green link. For the All Treatments table in Figure 2, the link is PatientTherapies_2013-11-29_09-45-05.tsv.

Figure 2
Queries Tab in Cleo’s After Creating an All Treatments Table

The Queries tab in Colabrativ’s Clinical Entry and Operations (Cleo) application after creating an All Treatments table. The treatments table creation options have been disabled, but still display the options that were selected when creating the treatments table, PatientTherapies_2013-11-29_09-45-05.tsv.

Filtering the Treatments Table

Filters are applied to a treatments table by selecting a filter from the “Select Filter” pull-down menu. There are a number of filters that can be applied to a treatments table. Each filter is shown below.

Treatment Table Filters

Once an agent name has been entered in the Chemotherapy Agents box, a new box will be created for an additional agent name. If the wild-card (*) is added as an agent then the filter will not remove treatment rows that match the agents supplied, but table row may have additional agents. Without a wildcard, the number of agents must match the number of agents supplied in the filter.

After setting up the desired filters for treatments table click on the “Run Query” button. The filtering will be applied to a preexisting treatments table, or a new treatments table will be created from the treatments table options which have been selected. The starting treatments table can be downloaded using the green link supplied for it. See Figure 3, in which the start treatment table link is Treatments_2013-11-28_11-08-16.tsv. The number of patients, specimens and treatments are provided for before and after the filtering. The filtered table can also be downloaded using the green link supplied for it. See again Figure 3, in which the query results table link is Query_2013-11-28_11-08-16.tsv.

Figure 3
Queries Tab in Cleo’s After Filtering Treatments Table

The Queries Builder after using a specimen type filter of O and P on a treatments table. The treatments tables created before and after filtering are Treatments_2013-11-28_11-08-16.tsv, and Query_2013-11-28_11-08-16.tsv, respectively.

Multiple filters can be run at the same time by simply selecting another filter from the “Select Filter” pull-down menu. After a Query has been run, additional filtering can be performed. For example, one might want to first filter on Cancer Codes and then Patient Histologies initially, and then to use the resulting filtered treatments table as the starting table for several treatment agents filterings.

Select Query

Just below the Query Builder banner is the “Select Query” pull-down menu (see Figure 3). All of the queries that have been run are displayed in this pull-down menu with their time-stamps plus their queries titles. To clear the query, an empty query can be selected from the “Select Query” pull-down menu. When a query is selected, the Query Builder panel will be cleared and replaced with the selected query’s information.

I will be participating in Wheel to Survive, a 6 hour indoor cycling event, to raise money for The Clearity Foundation, which helps ovarian cancer patients and their physicians make better-informed treatment decisions based on the molecular profile of the tumors.

Ovarian Cancer

Ovarian cancer is the most lethal gynecological cancer affecting 1 in 70 women.  Today more than 70% of ovarian cancer patients will die of their disease, compared to less than 20% of breast cancer patients.  When ovarian cancer is detected and treated early, the five year survival rate is greater than 92%.  Sadly though, symptoms are vague and subtle, so most patients are diagnosed at later stages and less than 50% will survive longer than 5 years after their diagnosis.

The Clearity Foundation

The Clearity Foundation, a 501 (c)(3) organization, supports women battling ovarian cancer by providing personalized information to individualize treatment decisions.  By providing tumor blueprints to patients, Clearity is bringing the future of cancer treatments to women who need help today.

Wheel to Survive Fundraising

Wheel to Survive fundraising is a 6-hour indoor cycling event sponsored by the Be The Difference Foundation.  Be The Difference Foundation mission is to help women increase their chance of survival of ovarian cancer.

How You Can Help

I truly appreciate any support you can provide.  It will benefit a great cause.   You can also help me reach my goal by sharing this page on Facebook and Twitter.  Or, send an e-mail to friends you think might be interested in contributing and include a link to my page.  Sign up and ride with me.  Thank you for your generous support and joining me to Be the Difference in the fight against ovarian cancer.  Our mothers, daughters, sisters, grandmothers and girlfriends are counting on us.

Colabrativ, Inc.’s Clinical Entry and Operations Application

For the past two years, Colabrativ, Inc. has been working with The Clearity Foundation to build a custom enterprise application to store and manage the clinical information gathered while profiling a patient's tumor.  The application, Clinical Entry and Operations (Cleo) was put into production on October 30, 2012.  More information on Cleo is available by viewing my blogs on The Clearity Foundation is in Production with Colabrativ’s Clinical Entry and Operations and Cleo (Clinical Entry and Operations) Version 2 Released.  The Clearity Foundation staff logs about five hours of work for each patient they profile.  Our goal is to lower the number of hours per patient, so that the foundation can help more patients.

I appreciate your support,
Marc Whitlow, Ph.D.
President and CEO
Colabrativ, Inc.

Server Configuration

Creating and installing a Secure Sockets Layer (SSL) certificate on a server should be a relatively simple task. However, most of the documentation relating to this task is confusing. Most of the confusion arises from the fact that there are a multitude of different server configurations that utilize the SSL to complete secure transactions over the web. In order not to add to this confusion, the following tutorial will refer to the following server configuration:

In this post I will describe:

1. Creating a Java Keystore
2. Certificate Signing Request (CSR) Generation
3. Check the Certificate Signing Request (CSR)
4. Loading the Certificates into the Java Keystore
5. Extracting the Key from the Keystore
6. Configuring Apache Server (HTTPD) ssl.conf
7. Adding Keystore to Tomcat’s server.xml

Creating of a Java Keystore

Here we will use a Java KeyStore to generate and store the SSL key and certificates. One of the limitations to this approach is that you must start by creating the KeyStore first. SSL utilities such as Java keytool and OpenSSL do not have the ability to create a keystore from an existing certificate and key. In particular, there is no way to put the key in the keystore.

$ sudo mkdir /etc/pki/tls/keystore
$ cd /etc/pki/tls/keystore
$ sudo keytool -genkey -alias demo -keyalg RSA -keystore demo.colabrativ.com.jks -keysize 2048
Enter keystore password: password
Re-enter new password: password
What is your first and last name?
  [Unknown]:  demo.colabrativ.com
What is the name of your organizational unit?
  [Unknown]:  
What is the name of your organization?
  [Unknown]:  Colabrativ, Inc.
What is the name of your City or Locality?
  [Unknown]:  Orinda
What is the name of your State or Province?
  [Unknown]:  California
What is the two-letter country code for this unit?
  [Unknown]:  US
Is CN=demo.colabrativ.com, OU=Developmemt, O=Colabrativ, Inc., L=Orinda, ST=California, C=US correct?
  [no]:  yes

Enter key password for 
        (RETURN if same as keystore password):

$ ls -lt
total 4
-rw-r--r-- 1 marc users 2246 Aug 30 08:53 demo.colabrativ.com.jks

Generating the Certificate Signing Request (CSR)

$ keytool -certreq -alias demo -keystore demo.colabrativ.com.jks -file demo.colabrativ.com.csr
Enter keystore password: password

$ ls -lt
total 8
-rw-r--r-- 1 marc users 1039 Aug 30 08:55 demo.colabrativ.com.csr
-rw-r--r-- 1 marc users 2246 Aug 30 08:53 demo.colabrativ.com.jks

Check the Certificate Signing Request (CSR)

Loading the Certificates into the Java Keystore

$ keytool -import -trustcacerts -alias root -file intermediate.crt -keystore demo.colabrativ.com.jks
Enter keystore password: password
Certificate was added to keystore

$ keytool -import -trustcacerts -alias demo -file demo.colabrativ.com.crt -keystore demo.colabrativ.com.jks
Enter keystore password: password
Certificate was added to keystore

Extracting the Key from the Keystore

$ sudo keytool -importkeystore -srckeystore demo.colabrativ.com.jks -destkeystore demo.colabrativ.com.pkcs12 -deststoretype PKCS12
Enter destination keystore password: password
Re-enter new password: password
Enter source keystore password: password
Entry for alias tomcat successfully imported.
Import command completed:  1 entries successfully imported, 0 entries failed or cancelled

$ sudo openssl pkcs12 -in demo.colabrativ.com.pkcs12 -out demo.colabrativ.com.pem -nodes
Enter Import Password: password
MAC verified OK

$ sudo cp demo.colabrativ.com.pem demo.colabrativ.com.key
$ sudo vi demo.colabrativ.com.key

$ ls -lt
total 20
-rw-r--r-- 1 marc users 1224 Aug 30 13:57 demo.colabrativ.com.key
-rw-r--r-- 1 marc users  509 Aug 30 13:53 demo.colabrativ.com.pem
-rw-r--r-- 1 marc users  509 Aug 30 13:50 demo.colabrativ.com.pkcs12
-rw-r--r-- 1 marc users 2246 Aug 30 13:48 demo.colabrativ.com.jks
-rw-r--r-- 1 marc users 1039 Aug 30 13:46 demo.colabrativ.com.crt
-rw-r--r-- 1 marc users 1039 Aug 30 13:45 intermediate.crt
-rw-r--r-- 1 marc users 1039 Aug 30 08:55 demo.colabrativ.com.csr

$ sudo mv intermediate.crt /etc/pki/tls/certs/.
$ sudo mv demo.colabrativ.com.crt /etc/pki/tls/certs/.
$ sudo mv demo.colabrativ.com.key /etc/pki/tls/private/.

Configuring Apache Server (HTTPD) ssl.conf

We will place all the SSL information for this server in the ssl.conf file in the /etc/httpd/conf.d directory. The ssl.conf file is loaded into the Apache Server (HTTPD) from the command “include conf.d/*.conf” in httpd.conf in directory /etc/httpd/conf. You should check to be sure that this command is in your httpd.conf file.

$ cd /etc/httpd/conf.d
$ sudo cp –p ssl.conf ssl.conf.orig
$ sudo vi ssl.conf
$ sudo diff ssl.conf.orig ssl.conf
19a20,21
> NameVirtualHost *:443
>
74c76,77
> <VirtualHost _default_:443>
---
> #<VirtualHost _default_:443>
> <VirtualHost *:443>
78a82
> ServerName demo.colabrativ.com:443
85a90,100
> #
> # Proxy Server directives. Uncomment the following lines to
> # enable the proxy server:
> #
> ProxyRequests Off
> ProxyPass        /admin   https://demo.colabrativ.com:8443/admin
> ProxyPass        /demoapp https://demo.colabrativ.com:8443/demoapp
>
> SSLProxyEngine on
>
105c120,121
< SSLCertificateFile /etc/pki/tls/certs/localhost.crt
---
> #SSLCertificateFile /etc/pki/tls/certs/localhost.crt
> SSLCertificateFile /etc/pki/tls/certs/demo.colabrativ.com.crt
112c128,129
< SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
---
> #SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
> SSLCertificateKeyFile /etc/pki/tls/private/demo.colabrativ.com.key
143c143
< #SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
---
> SSLCACertificateFile /etc/pki/tls/certs/intermediate.crt

Adding Keystore to Tomcat’s server.xml

$ cd /etc/tomcat7
$ sudo cp -p server.xml server.xml.orig
$ sudo vi server.xml
$ sudo diff server.xml.orig server.xml
84,88c84,92
<     <!--
<     <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
<                maxThreads="150" scheme="https" secure="true"
<                clientAuth="false" sslProtocol="TLS" /&gt
<     -->
---
>
>     <Connector port="8443"
>                protocol="HTTP/1.1"
>                SSLEnabled="true"
>                maxThreads="150"
>                scheme="https" secure="true"
>                clientAuth="false" sslProtocol="TLS"
>                keystoreFile="/etc/pki/tls/keystore/demo.colabrativ.com.jks"
>                keystorePass="password" />

Useful Resources

1. SSL Shopper’s The Most Common Java Keytool Keystore Commands
2. SSL Shopper’s The Most Common OpenSSL Commands
3. Wikipedia’s page on X.509

State of California Supplier # 1753901

Colabrativ is a custom software development company, with experience in clinical operations and biomedical research & development. We are looking to collaborate with companies that are doing business with the State of California.

Software Development

Projects

• Clinical Entry and Operations (Cleo)
• iExperiment – Enterprise Electronic Notebook

Clients and Collaborators

Medical Record Summaries

Our goal for Cleo version 2 was to migrate Clearity’s patient medical record summaries from a Microsoft Access database to Cleo. In the process, we built medical record-specific objects to handle the specific needs of each class of medical record. To meet the foundation goals each medical record event has two display modes in a chronological list under the History tab. The “single” line display summaries the most important information, such as a CA-125 diagnostic procedure result, see Figure 1. The detailed display mode can be quickly accessed for any history event, by clicking on the Green “Open Panel” button on the left side of each history event box.

Figure 1
History Tab in Cleo Application “Single Line” Display Mode

History tab in Colabrativ’s Clinical Entry and Operations (Cleo) application displaying a fictitious ovarian cancer patient history in single line display mode. All of the personal information displayed in this figure is fictitious, and does not represent a real individual or their medical history.

All history events have a common set of information about the event, including: date of the event, notes on the event and the source of the information. The source of the information can be: Medical Records, Pathology Reports, Imaging Records, Patient and Physician Communications. The source of the information can be uploaded into the history event, and are securely stored on an encrypted drive.

Both display modes have access to any medical record documents that have been uploaded in a history event. In the “single” line mode a file icon can be clicked on to download the medical record file. In the detailed display mode the full name of the file is a download link to the file, see Figure 2. Multiple files can be uploaded for any history event. This is commonly done for surgical records and their associated pathology reports.

Diagnostic Procedure

A diagnostic procedure, such as the determination of the patient CA-125 level, used to monitor ovarian cancer patient response to therapy. In addition to the basic information described above, a Diagnostic Procedure history event has information on the test used, and its result. If there is evidence for any change in the patient’s status then that information is collected, along with who made the determination that the patient status had changed.

Figure 2
Single Line and Detailed Displays of Diagnostic Procedure History Event

A fictitious ovarian cancer patient Diagnostic Procedure history event shown in single line display mode (A) and detailed display mode (B) in Colabrativ’s Clinical Entry and Operations (Cleo) application. All of the personal information displayed in this figure is fictitious, and does not represent a real individual or their medical history.

Imaging Procedure

An Imaging Procedure history event has information on the procedure type, the Body Region imaged and the observations made from the images. Like Diagnostic Procedure events, an Imaging Procedures can have “Evidence For” any change in the patient’s status.

Figure 3
Detailed Displays of Imaging Procedure History Event

Imaging Procedure history event shown in detailed display mode in Colabrativ’s Clinical Entry and Operations (Cleo) application. All of the personal information displayed in this figure is fictitious, and does not represent a real individual or their medical history.

Biopsy and Centesis

Both Biopsy and Centesis history events use the same panel structure. In addition to the basic information described above, these history events have information on the procedure used, and if there was evidence for any change in the patient’s status. In addition, the pathological analysis of any material collected, e.g. Cancer type, Histology, Stage and Grade can be entered. If the pathological analysis is the “Patient’s Staging Information Source”, then one can check this box and the patient’s Summary at the top of the history will be populated with this information. This option is also available for surgical events.

Figure 4
Detailed Displays of Biopsy History Event

A fictitious ovarian cancer patient Summary and Biopsy history event shown in the detailed display mode in Colabrativ’s Clinical Entry and Operations (Cleo) application. All of the personal information displayed in this figure is fictitious, and does not represent a real individual or their medical history.

Surgery

Surgery history events are similar to Biopsies and Centeses, in that they all can have pathological analysis of any sample collected, e.g. Cancer type, Histology, Stage and Grade can be entered, and that information can be used to populate the patient’s Summary. They differ in that multiple procedures can be performed during a surgery, and they do not have “Evidence For” patient change in the status option.

Figure 5
Detailed Displays of Surgery History Event

Surgery history event shown in the detailed display mode with an uploaded medical record and pathology report in Colabrativ’s Clinical Entry and Operations (Cleo) application. All of the personal information displayed in this figure is fictitious, and does not represent a real individual or their medical history.

Chemotherapy

Chemotherapy events contain information on the chemotherapy agents used and the cycles of chemotherapy that were performed. A typical chemotherapy cycle is three consecutive weeks of treatment, followed by a week off. The cycle information is traced using the first to last cycle. This allows for changes in treatment, such as dropping an agent after the first cycle and replacing it with a new agent on the second cycle or when a drug dose is lowered. Some patients are enrolled in clinical trials, in which one may not know what treatment the patient received, due to the blind nature of the clinical trial.

Figure 6
Detailed Displays of Chemotherapy History Event

Chemotherapy history event shown in the detailed display mode in Colabrativ’s Clinical Entry and Operations (Cleo) application. All of the personal information displayed in this figure is fictitious, and does not represent a real individual or their medical history.

Other History Events Supported

The other history events that Colabrativ’s Clinical Entry and Operations (Cleo) application support are shown below.

Public Policy in the Age of Big Data

Public policy needs to find a way of protecting peoples’ health records while still allowing the biomedical research community access to medical records for the potential identification of new diagnostic and therapeutic products. What Dr. Erlich’s work has shown is that restricting the information available on public genomic data does not ensure anonymity of an individual’s genome. Further restrictions would only lower the value of the data provided to the biomedical research community. The solution to this problem is to shift the burden of protecting the anonymity of the data from the repository to the user.

• The identity and intent of the users of publicly available genomic data needs to be recorded with the data repository.
• The users of the data need to be identified using protocols that are the best practices in the security industry, beyond the standard email confirmation. Out-of-network identity confirmation or the use of devices that remain in the control of the user should be employed.
• The user authentication should be done every time a user requests information from a public medical repository.

Potential Benefits to the Individual Supplying Their Genomic Sequences

One of the guiding principles of research on humans is that there must be a potential benefit to the individuals participating in the research. Researchers using public genomic data should try to identify potential benefits to the individuals whose information they are using. This information could be returned to the individual through the genomic repository.

Marketing based on an Individual’s Genome

Prescription drug marketing is already regulated by the Food and Drug Administration (FDA). What if a company wanted to market to people that have a particular genetic signature? Should they be able to use public or private genomic data to identify these individuals, and market to them directly, or to their physicians? I would think that some individuals would want this and others would find it invasive. There needs to be a way of allowing individuals to opt-in to contact by various organizations through the repository. Once again we see that the repository is acting as an intermediary between the individual and organizations analyzing their genome.

Expansion Genomics Repository Responsibilities

What I’m suggesting is that genomic repositories become hubs that manage more than the depositing individual’s data. Instead of allowing anyone access to the data, repositories should ensure that they know who is requesting data and for what propose. Finally, the repositories should distribute information about the potential benefits of new technologies to the individual whose information they have been entrusted with.

Identifying Individuals Methodology

Dr. Ehlich’s group started from public sequence data of an individual. From the supporting meta data they were able to obtain:

1. The individual’s year of birth
2. sex
3. state of residence

They developed a short tandem repeat (STR) profiler² that allowed them to identify the Y-chromosome STR of male individuals, and fed this information into a surname search on the genetic genealogy sites.

Having the most probable surname, year of birth and the state of residence they used publicly available web services, such as USearch.com and PeopleFinders.com to locate the best potential matches, and did subsequent followup studies using public resources to confirm their results.

Of the 1000 Y-chromosome STR data sets Dr. Ehlich’s group examined, they were able to “completely” identify almost 5% of the individuals.

Reference

1. Identifying Personal Genomes by Surname Inference. Gymrek M., McGuire A.L., Golan D., Halperin E., Erlich Y. Science. 339, 321-4.
2. lobSTR: A Short Tandem Repeat Profiler for Personal Genomes. Gymrek M., Golan D., Saharon S., Erlich Y. Genome Research 22, 1154-1162.

Colabrativ’s Role in Small-Angle X-ray Scattering Experiments

Colabrativ’s role in this work started at the conceptual level during discussions with the Biogen Idec scientists about structural approaches to compare the FVIII and rFVIIIFc proteins. Crystallization was an obvious choice, but due to the flexible linker between the FVIII and the Fc in rFVIIIFc, crystallization of the rFVIIIFc was considered to have a low probability of success. SAXS had it own challenges, i.e. obtaining aggregate free samples of both proteins at reasonable concentrations. Early on while evaluating SAXS as an analysis option, we contacted Dr. John Tainer, who put us in touch with Dr. Susan Tsutakawa at SIBYLS beamline 12.3.1 at the Advanced Light Source (ALS). We made the contractual arrangements with the ALS and worked with the Biogen Idec staff to prepare and submit a successful SAXS proposal. We worked with both the Biogen Idec and ALS staffs on the preparation and shipping of the protein to the ALS. Working with Dr. Tsutakawa, we purified both proteins at the ALS by size-exclusion chromatography, prepared in a range of concentrations, and collected the SAXS data on the samples and their corresponding filtrates all in the same day.

Analysis of Factor VIII and Factor VIII-Fc SAXS Data

The analysis of the SAXS data and model refinement was performed by Dr. Tsutakawa beginning with initial models supplied by Biogen Idec.

The Guinier plots of the SAXS data for FVIII and rFVIIIFc showed both samples to be monodisperse; i.e. they have linear Guinier plot slopes. The radii of gyration (Rg) for FVIII and rFVIIIFc from the Guinier plots are 38Å and 51Å, respectively. The Electron Pair Distributions have a Dmax of 125Å and 175Å for FVIII and rFVIIIFc, respectively.

Models of FVIII and rFVIIIFc used the crystallographic structures of Factor VIII (3CDZ.pdb) and Fc as starting models. The program BILBOMD was used to identify a small set of conformations for these starting coordinates that best match the experimental SAXS data. Missing loops and carbohydrate chains were added to improve the fit to the SAXS data. For FVIII, the Chi value improved from 3.5 to 1.8 after modeling the missing loops and optimizing the conformation with BILBOMD, and to 1.5 after modeling the missing carbohydrate structures; see Figure 1.

Figure 1
Modeling of the FVIII Structure in Solution

The molecular dynamics simulation program BILBOMD was used to model conformers of BDD FVIII and compare their theoretical X-ray scattering curves to experimental scattering data. Three models are shown: The crystal structure of BDD FVIII (3CDZ.pdb – Chi=3.5), BDD FVIII with loops (Chi=1.8), and BDD FVIII with addition of N-linked carbohydrate (Chi=1.5). The fit of the three FVIII models to the experimental SAXS data is shown in the left panel.

The rFVIIIFc BILBOMD model has two conformations contributing to the best fit of SAXS data when only the missing loops were added. Unlike the FVIII modeling, the fit to the SAXS data did not improve when the carbohydrate structures were modeled and optimized with BILBOMD; see Figure 2.

Figure 2
Modeling of the rFVIIIFc Structure in Solution

BILBOMD was used to generate a minimal ensemble of structures for which theoretical X-ray scattering curves optimally fit experimental scattering data. Two models are shown: The rFVIIIFc model based on the BDD and Fc crystal structures with surface loops but lacking N glycans has a (Chi=1.5), and the same model with of N-linked carbohydrate present (Chi=1.6). The fit of the two rFVIIIFc models to the experimental SAXS data is shown in the upper-left panel.

Conclusion

The Fc domain in rFVIIIFc extends away from the regions in FVIII that are essential for interaction with elements of the Xase complex (anionic phospholipids, Factor IXa, and Factor X) and von Willebrand factor. This result is consistent with the conclusions from the H/DX study that shows that the fusion of Fc to FVIII does not perturb the structure of either the FVIII or Fc elements of rFVIIIFc.