Don't Move It, Don't Lose It

The federated data model is a promising method for keeping valuable data both secure and accessible.

by / February 2, 2007
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 Massachusetts, Indiana and California.

Canadian Health Care
Canada's health-care industry also uses federated data technology in its nationwide electronic health records (EHR) initiative. Canada plans to have half of the country using an interoperable EHR system by 2010. Critical to this plan is Canada Health Infoway -- an independent, not-for-profit organization making strategic investments in public-sector EHR projects nationwide.

The plan involves several provincial, regional and territorial Canadian jurisdictions implementing a client/patient registry. The registry will link all identifiers and their associated data elements within and across all applications -- regardless of their disparate or similar characteristics -- to provide a complete patient care imprint at any point of service in the region, province or territory.

U.S. Law Enforcement
In the United States, law enforcement uses federated data technology as well. Such software solutions are being implemented nationwide, linking case data from multiple agencies -- federal, state and local -- to provide information about criminal suspects through a single search portal.

This system segments the data so law enforcement officials within a specific state or locality can share information with each other and with federal agencies, but not with other states. Each jurisdiction has its own set of security policies, procedures and governance boards regarding how -- and with whom -- to share data.

The Federated Approach
Various approaches to data sharing have been used over time. To distinguish the federated model from others, let's first take a look at the more traditional transactional method.

A Transactional Approach
With a transactional approach, data is shared through a transactional hub system. This type of system physically stores data from multiple source systems in a centralized database and shares it with users enterprisewide. This data-sharing solution is certainly effective, but can also be rather costly and time consuming. It may take years, and millions of dollars, to redesign data systems, data models and data flow. Additionally it requires moving the data from its original database and restructuring data ownership. Any time data is restructured or moved, risk becomes a factor.

A Federated Approach
A federated approach incorporates aspects of centralization, while letting individual units retain local control for security, regulatory and other mission-process purposes. A federated system establishes a central enterprisewide master index that includes accurate information about personnel and other mission data derived from heterogeneous data sources maintained by separate but affiliated systems or organizations.

The federated system unifies and distributes data -- but only the information necessary for any given user interaction in accordance with privacy, access control, data ownership and other agency policies.

Unlike a transactional hub approach, a federated solution does not require replication, migration or modification of pre-existing data. Legacy systems that maintain agency information continue to function as originally intended; the model does not modify existing enterprisewide processes. Instead the system leaves data intact in central and remote servers -- enabling individual units to maintain data ownership for security and compliance purposes -- and links data to its master index.

Rules are generated to govern data selection, qualification and filtering to ensure only the appropriate information is presented to any given user at any given time. And because rules are established using a software interface, administrators can alter them anytime to accommodate new mission requirements and regulations.

The Federated Advantage
The federated model offers several benefits, including the following:

  • Noninvasive integration. Unlike other integration methods, the federated model is noninvasive to existing management systems. Typical customer relationship management (CRM) and enterprise resource planning (ERP) applications can still be quite risky, even 20 years after their introduction. According to a 2003 report by the Standish Group, 15 percent of these types of large ERP and CRM IT projects fail; 51 percent don't deliver the desired results on time or within budget; and only 34 percent succeed. A federated data model refers to the data already in place -- there is no data- or system-forklift -- and uses security rules and regulations already in place. Ultimately you control just how much integration is allowed. Simply put, this less invasive model means less risk.

  • Quicker stand-up time. Going back to the CRM and ERP comparison, you can implement a federated-data system in a much shorter period of time. Because a federated model relies on the data already in place, it boasts a deployment time as short as three months. Conversely "real transformational ERP efforts usually run between one and three years," according to The ABCs of ERP, an article published in CIO magazine's ERP Resource Center.

  • Flexibility. No two agencies have the same mission, and likewise, no two agencies have the same security rules and requirements. To expect one type of solution to fit a wide range of regulatory and security requirements is unrealistic. With a federated model, nothing is set in stone. Your staff can make system changes as needed.

    Remember, in a federated model, the data does not move. The integration project is noninvasive, and therefore a low-risk proposition.

    Moving to a Federated Model
    A few proven federated data systems products are available today. Agencies interested in implementing one of them should take a long, hard look at the product and the vendor to ensure its history of providing this type of data integration. Don't be fooled by claims and bravado -- obtain as many references as you can.

    As for individual features, the following are a must:

  • Flexible architecture -- The federated system must let agencies organize data according to their own mission requirements, priorities and processes;
  • Accurate identification -- The system must resolve duplications and discrepancies among disparate and redundant data sources, and retrieve accurate details to provide a complete single view.
  • Standardization -- The system must provide consistent information about each entity, regardless of the computing platform or application that uses it within the enterprise.
  • Scalability -- The solution must scale to support hundreds of millions of records to accommodate future growth and expansion; it must continue to provide accurate information as the system scales; and it must accommodate new processors to support revised computing requirements.

    Final Thoughts
    The time we had to get that restful sleep is over. The alarm has gone off. Now is the time to wake up, smell the potential security breaches, and do something about them. There are no official mandates encouraging the move to a federated approach. In fact, there are no regulations suggesting we do anything differently to guarantee more secure data exchange.

    We don't have to implement a federated data model. It just makes good sense. And it goes a long way toward ensuring a much tighter security model while still satisfying the data-sharing mandate.
    Scott Schumacher Contributing Writer