Wednesday, July 17, 2013

Sharing Versus Centralized Data

The VA and DOD have been working off and on to setup one centralized healthcare record for military personnel.  It makes sense: someone starts as a GI under DOD's control and, after retirement or separation, moves to be under VA's control. 

In the hearing I linked to it seems that Congress still wants that one record to rule them all, while DOD and VA are leaning more to sharing data.  I assume the idea is that if the VA can pull data from DOD records and display them to VA personnel, that's good enough.

During my government career, I was involved in both "sharing" and "centralizing" efforts. We worked for some years on trying to transfer files of ASCS data to SCS computers, basically to enable policing of the sod/swamp provisions of the 86 farm bill.  And the effort which eventually became SCIMS was based on the idea of a central customer/client record serving all the service center agencies. 

Neither effort worked out, at least not during my career.  I'm not sure what lessons to derive from that fact.  I mention this history because doing such things as implementing Obamacare or immigration reform (E-Verify) raise similar issues of system design.  

If you can design the interfaces, it's probably easier and faster to do the sharing, perhaps particularly these days with the availability of syncing software.  The biggest advantage of centralized data is not just avoiding redundant data load; it's avoiding the problem of stale data.  For example, a death gets reported in system A, but never propagated to systems B...Z.   The problem with sharing/communication is that the unspoken and unidentified assumptions in system A may trip you up in the other systems.  The problem with centralized systems is you have to understand a whole lot more about all the business rules. And it's difficult to have modular development.


No comments: