Why Every Citizen Should Care About MDM
Posted by 
Share this Post
As a citizen, demand that your data remains private, even when mailed
From the annals of “why should every citizen care about MDM…”
The Sacramento Bee recently had a story on how the California Dept of Health Care Services had inadvertently breached the privacy of 49,352 people who receive adult day-care services from the state . It seems that DHCS mailed letters to Medi-Cal beneficiaries with their Social Security numbers on the address label.
Yup, that is what I call a breach of privacy. This is not an isolated incident; in 2007 CalPERS mistakenly published the Social Security numbers of 445,000 state retirees on brochures announcing an upcoming election.
Having not worked in a state health agency or a state retirement agency, I have no basis to speculate on why this happened. But, I can tell you that it is not surprising that these things happen. The scale of these organizations and the complexities of the procedures involved make it highly likely that such lapses will occur.
Clearly the answer is not just “better” technology or “smarter” employees. CalPers for instance, is the perfect example of an organization badly in need of practical data governance. Designing a practical data governance would start with analyzing what are the “must not be allowed to happen” events for the institution.
In other words what are your priorities? Now walk backwards from your priorities to accomplishing them.
For example, if making sure the SSN of 450,000 retirees does not end up on brochures is a priority, your next task would be to understand the different avenues for this breach to happen. Soon you realize that it is not possible to individually fix every point of breach on a system as large and complex as CalPERS or DHCS.
This is where MDM comes in to the picture. You might start by understanding how many different systems store patient or retiree information. An MDM solution will help you consolidate the data across these multiple systems such that you now have a trusted system that offers the most current view of a patient or a retiree.
This is just the beginning. Lots of IT projects end up standardizing on SSN as a unique identifier for person information. While this is convenient, it sets one up for the kind of privacy breach seen in these articles.
An alternative would be to generate a unique ID specific to the institution. Even if this happens to be printed on the outside of an envelope or election brochure, it is of no use to the reader.
Generating a unique ID that can tie data across complex IT infrastructures is not easy and not something that should be built from scratch at the last minute, but fortunately it is exactly the kind of problem a MDM solution is built to solve.
In summary, there are no quick fixes to solve identity breaches that occur in massive organizations, be it state department or large credit card companies. That does not mean there is no hope though.
An elegant and effective solution is possible. It involves a capable data architect (with the right authority) working to understand the data needs of the multiple business units (mailing, claims processing, marketing, etc) and translating those needs into practical data governance policies.
The application of these policies is facilitated by using trusted data from a MDM solution. At the end of the day, this is something every citizen should care about because our taxes are being used to provide us with state and federal services. It is then our fiscal responsibility as share holders to demand transparency and efficiency from these organizations.
We can start small by demanding an end of privacy breaches. Who knows where that will lead us.
5 Responses »
Trackbacks
Leave a Response
Entries(RSS)
On Twitter, Henrik Sørensen commented:
It's very different in Denmark. In Denmark we have a citizen hub with a unique citizen ID used for every citizen role accessed by all authorities. However the Citizen ID should not be exposed to other citizens without a legal reason, such as being an employer, providing financial service, or giving credit.
Amar
Really good post. I agree with everything save for one minor point:
This is just the beginning. Lots of IT projects end up standardizing on SSN as a unique identifier for person information. While this is convenient, it sets one up for the kind of privacy breach seen in these articles.
Few organizations use employee SSN as the unique ID because of HIPAA constraints. They opt instead (or at least probably should) for a separate, unique number.
@ Crysta - Interesting bit about hubs in Denmark. I assume that breaches are still possible but, with fewer systems, they're probably less likely.
Phil,
Good catch. Point taken. I was trying to shed light on the temptation to start a project by using SSN as a unique ID since it seems ready made for that. As you rightly stated, It can only be taken so far since it is clearly in violation of the privacy acts such as HIPAA and FERPA.
Amar, good points, and glad you have brought this to light.
Like you said, this is a lack of Data Governance. Where does this fall ? Data Quality ? Data Delivery ? MDM ? Security ? Data Modeling ?
Well, in all sense of the problem, they all are responsible. There is a new trend coming down the pipe, where MDM and Data Quality (and oh yes Data Governance) will have to tie into its complex web of tasks a new set of policies around Compliance.
Compliance in the access management, audit trail, reporting and prevention of data intrusion will be part of the grand scheme of Enterprise MDM.
Using tools like Guardium (www.guardium.com) provide set of templates, and policies that can be adopted by organizations that prevent the advent of SSN ids being populated on a address form. Allowing new technologies to comb the traffic, monitor the activities and alert possible issues (like sensitive data being sent to a address label application) will enhance the value and position of MDM and any Enterprise Data project.
As MDM continues to evolve, we are starting to see the emergence of tools that help establish policies which could become the stewards, and in turn feed into Data Governance... and as we know creating Data Governance is tough enough as it is... anything we can do to help it along (like tooling) will only help it come to fruition...
Good article... thanks for sharing.