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.

Dead Customers--Warning to Government List Managers

I stumbled on this while reading an FSA notice:

"The Death Master File Report identifies customers who were updated as deceased in Business Partner during the initial migration. This was a one -time process run from the Death Master File (DMF) from the Social Security Administration (SSA) and approximately 1.7 million customers were updated as deceased. County Offices will not receive work list items for customers on this list as all customers were updated with a date of death and the death was automatically confirmed."

What it says is FSA's master name and address file, probably about 6-8 million names, wasn't being maintained for deaths, so when FSA matched the file against SSA's records, 1.7 records fell out.   I suspect this is a hazard for all lists maintained by big organizations: there's no immediate apparent cost to keeping a record on file and there's an obvious cost removing it.  It takes time to remove a record or flag it as dead, and there's always the chance of error.  So it's easier, cheaper, and safer not to touch the file.

Problem is, leaving the dead on file leads to mistakes, most notoriously payments to dead farmers, and potential security problems.  How many thrillers have you read where someone establishes a fake identity using the name/ID of a dead person?

I believe, back in the old days before System/36, the KCMO mainframe files were routinely matched against SSA death files.  But when we went to the 36, because that process was done once a year or so, it fell through the cracks.  As we used to say in the Army: sorry bout that.

VA, DOD, and Me

Though I'm a veteran, I've stayed away from the VA, not much there for me.

But I've watched with interest through the years, particularly in the pages of the Washington Monthly, as the VA has worked on incorporating computers into their health record system, then later as the DOD and VA have tried and failed, so far, to come up with one health record system which will follow the military person from active duty to the VA hospital to the grave.

In skimming the papers this morning I note DOD Secretary Hagel was getting flak for wanting to study the issue further, someone in Congress said we needed not VA and DOD systems which could interoperate but one system.  Though my bias has always been towards one system, as I've aged I wonder whether that's right.  In my USDA days with Infoshare we were trying to build one system which could serve at least ASCS, FmHA, SCS, and possibly FCIC and Extension.  Needless to say we failed.  The best I understand these days MIDAS is an FSA initiative, with little or no carryover to NRCS, and none to RD.

Maybe back in the day we would have been better off just focusing on file transfers of data, use more brute force and keep interconnections looser rather than tighter.  Certainly with DOD and VA they've spent years and millions and failed.  I don't know.

Doesn't Anyone Know How to [Do Big Systems]?

I'm probably misremembering, but I believe Casey Stengel, when he was manager of the expansion NY Mets, asked something like: "doesn't anyone know how to play this game?" 

Anyhow, that saying, whatever its source, came to mind when I read that after 4 years of effort by DOD and VA to have one system of health records for the military and military veterans, they're giving up. Only $1 billion shot to hell.

USDA Performance Measures

Forgive my asking,but aren't we now in FY13, nearing the end of the first quarter?  Having nothing better to do, I was trolling through the performance.gov site for USDA.  

When I copy the data over, I lose the formatting but these relate to MIDAS and OCE, and they seem to be a tad out of date. Tsk, tsk.

Initial Operating Capability (IOC) Deployment

IOC Release 1 acquisition and detailed planning will occur in FY11 Q3-Q4. Releases will follow SAP ASAP methodology (project prep, blueprint, realization, final prep and go live). Less

2011-07-01

2012-09-30

$119098

% of Field Offices with WAN Acceleration Monthly % 80 -- 2012-02-28 % of Field Office with centralized file services Monthly % 55 -- 2012-02-28 % of Field Office on centralized backup Monthly % 55 -- 2012-02-28 % of infrastructure components out of life cycle (goal is to refresh prior to out of life cycle so l More.. Monthly % 55 -- 2012-02-28 % End Users Satisfied with OCE-related IT Infrastructure Components Monthly % 55 -- 2012-02-28 % of Field Offices with Telephone systems upgraded Monthly % 75 -- 2012-02-28

The question is, is anybody looking at the measures?

USDA and OIP

FCW refers to the 6-month review of the digital government strategy.  Via links, I come on this page from USDA.  From what I see, it appears USDA is bragging on the Office Information Profile system.

I'm amazed, really amazed. OIP was a result of work in the 1990's, Paul Whitmore from FSA and someone from NRCS and RD, which had actually evolved from Gerry Deibert's efforts to construct a database of USDA offices back in the day when Sec. Madigan was trying to consolidate field offices.

Unfortunately, it got done as a separate silo from SCIMS, which was unfortunate, or at least I thought so then.  Anyhow over the years I've occasionally looked at the OIP page(s) just to see what's happened.  I could swear, though I might be wrong, that NRCS had dropped the links to it, though it seems to be back now.  It's not evident on the USDA web page.

It looks to me as if maybe they blew the dust off the old software, added in the link to the Bing map  (which is good) and resurrected it.  I wonder what sort of usage statistics USDA maintains on it.  Pardon my doubts, but I think the design too closely reflects the bureaucracies involved, rather than meeting the needs of the user.  If I'm looking for an FSA/NRCS/RD office:

• I might be looking for the closest one to my current location, or a specific location.  In that case, I'd be best off if office locations were integrated with Google maps (and Bing, etc.). In other words, if I stick Reston, VA in Google maps, and add the ": FSA office", it should flag the closest office.  Or if I add ":gov", it should show the closest government offices.  Seems to me this would be good for OMB or whoever to work on.  I tried this sort of search a few times and the results vary.  The closest FSA office to Reston is at 14th and Independence, but it didn't show the county offices.  RD and NRCS didn't get that result.
• if I want to know which office services a specific geographic area, the OIP does okay, except for the fact you need to drill down through state, to county, to agency.  If you ask Google: "what FSA office serves Mills County, IA?, I get the state office, not the county office.

The Progress of New Terminology and Technology

Reading Notice CP-686 on the forthcoming use of MIDAS with GIS for acreage reporting, replacing CARS. 

Two terms new to me: "subfield" and "cross-over commodity".

Remembering the fiasco of the ASCS-578 in 1985 (and 86, and 87) I wish them luck.  Actually, I hope over the years the number of problems has been reduced, but acreage reporting was probably the  area where the conflict between national standards and local conditions was most obvious. Before computers, much of the conflict was hidden from the national office; State and county offices made things work.  Introduce the computer and local variation becomes a problem.

I suspect, without any evidence whatsoever, that part of the resistance to "electronic health records" on the part of doctors and others is based on this sort of thing. 

Poor Software Design: British Style

A couple blogs I follow have noted a report over in the UK that there are 17,000 pregnant men in the National Health System.  At least one of the blogs commented it's a reminder of how easy it is to get garbage into an automated system and thus we should be careful in our reliance on reports. 

That's all true, but the problem really is a design problem: apparently there's no validations on the entries for this particular field, or at least there's insufficient validations.  One could presumably also find in the report some women with prostate problems and men with gynecological problems.  Absence of thought is a universal.

The Importance of Data Modeling

And thinking outside the box.  The NYTimes has a piece on how American retailers are trying to open up their websites to foreign customers.  Turns out it's not simply a matter of trusting shipments to UPS or FedEx.  For one thing, some foreign countries have postal codes which aren't 5 digits.  Imagine that!

I mock, yet the longer I live the more I see that my own data modeling efforts in the 90's were horribly limited by assumptions and chauvinism.

Future for FSA Software

Haven't discussed FSA in relation to the farm bill recently.  There's discussion that it will be impossible to pass a new farm bill this year, given the election year politics, the debate over the deficit, etc. That would be good; it'd allow more time for FSA to implement their new software systems.  There's also discussion, as here in Farm Policy, about having crop-specific programs, rather that one program which covers what we used to call "the program crops", the major field crops.  That's bad.  Newly designed programs don't take on their final shape until the last minute, making it very hard to implement software for them (see ACRE), and having to implement 3 or 4 differently shaped programs for different crops further complicates the matter.  Add to that the loss of historical memory and expertise from the loss of Washington program experts. End result: "interesting times" ahead.

How Good Is FSA's Management?

Federal Computer Weekly has a piece on a GAO report which analyzed why seven big IT projects were successful. 

• The most common factor was the involvement of program officials, particularly in ensuring the participation of internal and external stakeholders. 
• The next most factor was the knowledge and skills of the program officials and the support of senior management.

Niedermayer Retires: ASCS History

Speaking of retiring employees, Chris Niedermayer is retiring from HUD.   Perhaps my clearest memory of Chris is probably from early 1986 or so, in Kansas City Management Office, specifically in the testing section, when we were both working late at night, he probably testing price support software, I involved with production adjustment software. It was the first time our paths crossed, though I'd seen him in the hallways in the South Building.

If I remember correctly, Chris had been separated from a statistical agency (maybe NASS) during one of Reagan's attempts to downsize government. Those fired got help in finding openings elsewhere, so he got picked up by ASCS, initially in the in-house statistical/policy branch of the division I was in. As we started to implement the System/36 he became the go-to person for the price support program automation.  Part of the time I was his counterpart for production adjustment. So that night in 1986 while I knew who Chris was from DC, it was the first time I realized how heavily involved he was in the price support automation.

Perhaps as a reflection of differences in persons, price support automation operated differently than production adjustment:

• price support separated the functions of doing policy (regulations and procedures) from doing automation (user requirements, working with programmers, testing). For a while, maybe 1986-89. For a while Chris was the automation guru, then he became responsible for all of price support.
• meanwhile on the PA side we mostly had people wearing two hats, doing both automation and the procedures. 

Personally I thought the PA model was better; of course that was my personality, trying to do everything.  It was also my background; while I didn't have county experience I did have several years developing regulations and writing procedures. I didn't have much real computer experience, doing some COBOL programs on mainframes was all, but that was enough to make me dangerous to Kansas City.   Conversely my impression is that Chris had much less hands-on experience with procedure before getting involved in price support automation.  He definitely picked up on the System/36 operation faster and in more detail than I did.

As time went on, things became more specialized on the PA side: program specialists would focus on either procedure or automation, and different units handled different areas,  but until I retired the same shop would cover both sides of the subject.  I've no idea which setup works best for the field, or whether there is any difference in the end result.

Anyhow by the late 80's the IT guys were worried about the System/36; they had underestimated the extent to which we'd load the System/36 so there was a continuous process of upgrading and moving to bigger models of the System/36, but they feared running out of room.  So Chris moved to IRMD and  was named the "Trail Boss" for the System/36 replacement, "trail boss" being a then-new, now-obsolete concept GSA had for the process of determining needs and handling procurements of big IT systems. So in 1990-92 Chris managed about 15 people trying to analyze ASCS data and operations, do a cost-benefit analysis to justify procurement of replacement hardware and software, and manage the conversion.  In other words, a precursor of the current MIDAS effort, except it was bigger, since the administrative and financial side was also covered by Chris's project.

Unfortunately, Chris couldn't move the project fast enough, so when Clinton won the election and Secretary Espy assumed office, it was subject to not-invented-here syndrome.  A part of the intra-office politics of the time was the "ins" versus the "outs". Chris IMHO had antagonized some of the Democratic outs, so when they became the "ins"  they weren't inclined to keep his project going.  Chris ended up moving to the Department level for several years, then to HUD, becoming deputy CIO, which is the job from which he's retiring.

Planning Ahead and the Auditors

This Federal Computer Week piece describes a conflict between Social Security Administration's management and its OIG: the IG wants SSA to plan its online services more thoroughly, more completely and for a longer period.  SSA is resisting.

I remember back in the day, maybe 1981 or so, either GAO or the USDA IG tore ASCS up over the issue of programmable calculators.  For you whippersnappers,  at one time calculators were the hot electronics item.  This was, I think, back in the day when integrated chips were first being made on a large scale, and companies found they could stick a chip in a case with a numeric keypad and a small display and sell it for big bucks (particularly when you consider inflation, probably several hundred by today's values). 

There were a slew of such manufacturers, some in the US, in Japan.  As Moore's law kicked in, the manufacturers hotly competed by adding features and lowering prices.  But that's a side story. Anyway by the late 70's we had programmable calculators costing in the low hundreds.  And a few ASCS employees, mostly CED's, found they could save a lot of time by buying one and  creating a formula for such things as calculating the deficiency payment, cutting the work down to just keying in the data.  These guys (almost all male I think) used available funds and shared their work.

By the time GAO got involved, ASCS had an investment in programmable calculators of  maybe $3 million (all facts herein based on an aging memory) and one person in DC who tried (rather ineffectually IMHO) to coordinate usage, encouraging sharing of programs, etc.  GAO took a look at the situation and issued a bad report.  They wanted DC to assess which county offices needed the calculators, make one national purchase to save money, and provide standard programs to the counties.

I got involved in drafting the response, which pushed back against the idea.  I'm not sure how well the response would stand up over time--whether we mostly argued for a do nothing approach based on inertia, or whether we were more perceptive..  What we (and GAO) didn't know was that the first CED's were about to buy, or  already had bought, personal computers (maybe an Apple II, maybe a Commodore, maybe a Trash 80) to play with and possibly apply to ASCS business.  My perception is that led to a push from the field which combined with leadership from DC, eventuated in the purchase of the IBM System/36.

Anyhow, our response should have pointed to Moore's law and the rapid transformation of the field and our lack of comprehension of what was happening (always hard for bureaucrats to admit we don't know).  In such a situation, it made sense to stay flexible and relatively decentralized. 

That episode was one of my learning experiences, which sometimes counters my tendency to believe, like IG's do, that good bureaucrats located at the center can establish patterns and systems which work best for the field.  The truth is, it all depends.

On Silos and Data Models

FSA issued a notice BU-729.  It seems to me, though I may be wrong, it's just another example of data silos, and a reason why, in 1990's terms, FSA should have developed an integrated data model.  Essentially the question is the relationship of geographic areas (counties) with administrative jurisdictions (county committees and local administrative areas) and county offices (of various types, shared management, etc.).  To administer county elections you need part of that relationship, to administer funds you need an overlapping part, to administer real and personal property inventories you need a third picture, to coordinate with NRCS and RD offices and jurisdictions you need others.  Unfortunately in my days at FSA each of those was administered by a separate office (or no office at all) and there was no overall coordination.  Apparently from BU-729 there still is no coordination.  My technocratic (Kevin Drum has a meditation on technocracy) heart is sore.

MIDAS Strawman

I wonder what NASCOE's members thought of the MIDAS strawman (actually "limited preview") at their recent convention. 

I call it "strawman" because it reminded me of the Infoshare strawman Greg Montgomery created back in 1991.  He had a indexing software package which could do hyperlinks as we know them now--remember 1991 was before the advent of World Wide Web browsers. Tim Berners-Lee put the first website up about a month before Greg did his stuff. Anyhow, while Greg couldn't do WYSIWYG interfaces, he was able to model a lot of ASCS operations running on a PC.   Of course, Infoshare, like other similar efforts since, turned out to be a dead end. 

My first reactions to watching a couple of the MIDAS demos is:

• I like the software which was used to create the demo.
• Most of my reactions to the actual FSA software being demoed is probably personal feelings along the lines of NIH. 
• The one really big (as Ed Sullivan used to say) thing I'd raise is: where is the ability for FSA field personnel to discuss and provide feedback?  They can and will point out the problems in what's being developed, and you need that input as early as possible. 

I'll probably have more reaction later if my energy and interest holds up and I don't get distracted.

SSA Bureaucrat

The Post had a laudatory article on a Social Security bureaucrat Thursday. It seems she figured out that not all diseases/disabilities are the same. By segregating  out and fast tracking those disabilities which are in some sense obvious (i.e., Lou Gehrig's disease--ALCS, etc.) she drastically improved the turnaround time for the claims.

This fits one of my mantras I developed over the years.  If you tried to design a software system which would handle all possible situations, you rapidly got yourself into the weeds, lost in a maze of conditions and with software which would be hard to test, hard to train on, and late to deliver.  The better strategy was trying to handle 80 percent of the cases with something simple and fast.  The big advantage was intangible: software developers felt lots better because they were accomplishing something to help the county offices, the users; the users felt better because they got something halfway timely which helped them.

What's Bad for the Military Is Bad for Civilians

Tom Ricks The Best Defense has a post citing a book by a Vietnam-era general:

Prudent military planners should draw the obvious conclusion that operations which span two administrations may lose their support in midstream. Very short operations like Grenada are about perfect. Long inconclusive operations like Vietnam are now known to be doomed. We may take this to be a legitimate consideration in connection with the doctrine governing operational art. It is a political refinement which is no less organic to the problem.

 I'd paraphrase this to say that prudent bureaucratic planners should draw the obvious conclusion that IT projects which span two administrations may lose their support in midstream.  (That's a conclusion reinforced by my review of the new Civil Rights Assessment report at USDA. )  It's not really a question of politics, but of Not Invented Here.  I hope they plan for MIDAS to be complete by Jan 20, 2013.

Cutting the Deficit, Cutting Safety

Part of the fallout from 2011 budget fight is described in this article in the Washington Times:

The Justice Department is freezing efforts to create a single radio network that allows its various agencies to talk to each other — a key recommendation of the Sept. 11 panel.

 I remember blogging on the need for such a network way back near the beginning of this blog.

MIDAS Presentation II

Some more random thoughts on the MIDAS presentation::

Two things struck me about the geographic distribution of the field people they've brought in to work on it:

• there's no one from the western third of the country.
• there's only one person from the southeast.

Now I understand that with the phaseout of tobacco and peanut programs and the establishment of Freedom to Farm direct payments regional differences in agriculture and in landownership and operation aren't as significant as they used to be. And I know all the hard-headed SOB's capable specialists who used to staff the state offices have now retired. So what you have in the state offices are easy-going types anxious to improve operations.  But gee, just for small p political purposes it'd be good to have a more diverse set of people.

Another nit to pick: the presentation refers to "SAP" as if everyone knows what/who they are. 

And finally, it seems I won't be able to restrain myself from commenting on MIDAS, so I've added a label for it.

SAIC and USDA

SAIC picked up another IT contract with USDA.  This one's for RMA support, the previous one was for FSA and MIDAS.

[Updated: I may be wrong--it seems SRA may have gotten the MIDAS contract.]