Don't Move It, Don't Lose It

The recent data breaches involving the Department of Veterans Administration, the U.S. Department of Commerce, the U.S. Department of Agriculture and other agencies have been quite the security wake-up call. And what a sound, peaceful sleep it had been.

For years, government agencies have been lax about where data resides. In May 2006, millions of veterans' records left a secure database and wound up on a contractor's laptop. This practice is ordinary -- agency workers regularly pull data out of where it should be and float it around the Internet. Yes, the Internet. Once that data leaves the database, all bets are off. Once it's gone, it's compromised.

Data must be stored behind a firewall in a database, where access can be controlled -- and secured -- on various levels.


Data Sharing
We wouldn't have this problem if data sharing and exchange weren't absolutely necessary. The critical question is how to enable data exchange without compromising security. Most sharing today is done by downloading data, transmitting it to another location, and storing it where it was not originally meant to be stored -- on a laptop or desktop outside of the organization proper. Obviously that model must change.

Enter the federated data model.

From a 30,000-foot perspective, a federated data model lets agencies access and present data without actually moving it from its local database. Federated data technology creates indexes and pointers for data stored in multiple source systems. It's like a virtual arrow that says, "Data, this way."

Data sharing within a federated data model means the owner of each source database decides exactly what data will be shared with others -- inside and outside of the organization. Access rules continue to be applied because the data has not moved.

The implications are tremendous.

The security arguments are overwhelming, as a federated data model may have prevented not only the aforementioned breaches, but also the breaches that are likely happening as you read this.

Privacy and regulatory arguments are equally overwhelming. The data does not move from the database, and can only be accessed with permission using existing policy, organizational and database rules.


Real-World Uses
This type of data model is already in use today, in more instances than you might realize.

U.S. Health Care
In the health-care industry, patient records are critically private. Yet rarely does one person -- with an entire history of medical visits and procedures -- stay in one place without moving or traveling. The challenge in the health-care industry is to let hospitals and other health-care facilities share critical patient records without compromising them.

Some say this challenge could be solved by developing a National Patient Identifier. This would be something similar to a Social Security number, but one that would be used specifically to identify individuals in the context of their medical history.

Using a federated data model provides the same results at a fraction of the cost, confusion and logistical difficulties. In fact, the health-care industry is one of the first users of a federated data model to begin meeting its security challenges.

One of today's most advanced regional and national health information networks was created by the Massachusetts Simplifying Healthcare Among Regional Entities program -- dubbed MA-SHARE. This collaborative initiative is run by the Massachusetts Health Data Consortium, which consists of public and private health-care organizations in the state.

In its work with Computer Sciences Corp., the recipient of an award to help create a national health information network demonstration project, and the public-private collaborative Connecting for Health, MA-SHARE has participated in a three-state prototype health-information network linking about 20 million medical records associated with 500,000 patients across networks in