The MIDAS touch

A couple of weeks ago, it was revealed that the Multidimensional Insurance Data Analytics System, or MIDAS, the database used by the Obamacare system, maintains its data permanently. The data in question includes a wide variety of personal information, including insurance applications, personal financial information related to qualification for federal subsidies, and Medicare eligibility information. There’s no question, being as the database itself is used purely for the purpose of conducting insurance transactions, that the data in question is related to an insurance transaction. And the data in question doesn’t just involve current enrollees, either. If you go even partway through the application process, your data is there, apparently forever.

The problem with this is that the federal government itself has promulgated the HIPAA privacy regulations, which expressly provide that personal data related to insurance transaction be maintained no longer than is necessary for the original purpose for which it was collected. So, we have the spectacle of the federal government in flagrant violation of its own regulations that everyone else in the country has spent billions of dollars trying to comply with. And given this last week’s revelations of the massive data breaches in federal IT systems, this over-retention ought to be cause for some concern amongst the millions of people who have used the Obamacare website or one of its state analogues.

This points to the problem with a lot of regulatory requirements, particularly as they apply to very large information technology systems: sometimes it’s a lot easier to pass a law telling people that they should do something then it is to actually do that something. And the federal government in this case has run up against exactly the same problem but everybody else has – parsing out the data in its MIDAS system into the sort of convenient, easily managed stacks of different types of information that you can then apply the rules to isn’t very easy and isn’t very cheap. Or maybe they’ve run into the second problem with trying to apply this sort of requirement to this sort of system: the people who designed the system simply didn’t think about the privacy requirement when they designed the architecture, and so they’ve baked in the impossibility of compliance. Or maybe they’ve run into the third problem: the people who oversee the process and system just don’t care, or think the rules don’t apply to them.  Or maybe they’ve run into the fourth problem:  rigging the system to be compliant would be so expensive it’d break the budget, and so is a practical impossibility.

Any way it turns out, the feds are a pickle: they look hypocritical for not bothering to comply with something they’ve beat everybody else over the head with, or they look incompetent because they don’t know how to comply, or they look arrogant because they didn’t think they needed to bother complying, or they concede that complying with their own rules is so expensive it can’t be done. It’s an object lesson in the inherent conflict between granular regulation and the way big IT systems are built. And it’s an object lesson in the need to do a reality check, both when you architect the system and you write the regulations.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *