The digital health space refers to the integration of technology and health care services to improve the overall quality of health care delivery. It encompasses a wide range of innovative and emerging technologies such as wearables, telehealth, artificial intelligence, mobile health, and electronic health records (EHRs). The digital health space offers numerous benefits such as improved patient outcomes, increased access to health care, reduced costs, and improved communication and collaboration between patients and health care providers. For example, patients can now monitor their vital signs such as blood pressure and glucose levels from home using wearable devices and share the data with their doctors in real-time. Telehealth technology allows patients to consult with their health care providers remotely without having to travel to the hospital, making health care more accessible, particularly in remote or rural areas. Artificial intelligence can be used to analyze vast amounts of patient data to identify patterns, predict outcomes, and provide personalized treatment recommendations. Overall, the digital health space is rapidly evolving, and the integration of technology in health

Tuesday, October 22, 2013

HEALTHCARE.GOV: IT COULD BE WORSE

 

That is a title in the New Yorker Magazine by Rusty Foster, on October 21st 2013.

His article implies, “what did you expect?” given the history of U.S. IT efforts in the past, including the development of the DHS (Homeland Security) centralized data bases for the FBI CIA FEMA, State Databases, and more.

Here is another troubled scenario that has taken over a decade to work. While Health Benefit Exchanges may not be as complex, the story has interesting comparisons

“On September 11, 2001, the F.B.I. was still using a computer system that couldn’t store or display pictures; entering data was time-consuming and awkward, and retrieving it even more so. A 9/11 Commission staff report concluded that “the FBI’s primary information management system, designed using 1980s technology already obsolete when installed in 1995, limited the Bureau’s ability to share its information internally and externally.” But an overhaul of that system had already begun in the months leading up to 9/11. In June, 2001, the F.B.I. awarded the contractor Science Applications International Corp. (S.A.I.C.) a fourteen-million-dollar contract to upgrade the F.B.I.’s computer systems. The project was called Virtual Case File, or V.C.F., and it would ultimately cost over six hundred million dollars before finally being abandoned, in early 2005, unfinished and never deployed. V.C.F. was then replaced with a project called Sentinel, expected to launch in 2009, which was “designed to be everything V.C.F. was not, with specific requirements, regular milestones and aggressive oversight,” according to F.B.I. officials who spoke to the Washington Post in 2006. But by 2010, Sentinel was also being described as “troubled,” and only two out of a planned four phases had been completed. Sentinel was finally deployed on July 1, 2012, after the F.B.I. took over the project from the contractor Lockheed-Martin in 2010, bringing it in-house for completion—at an ultimate cost of at least four hundred and fifty-one million dollars. In the end, the upgrade took the F.B.I. more than a decade and over a billion dollars.

My first question would be, “What decade of IT was the HBE software developed?

Developing good software is a complex and sometimes unpredictable process.

Healthcare.gov is not so much a Web site as an interface for accessing a collection of databases and information systems. Behind the nicely designed Web forms are systems to create accounts, manage user logins, and collect insurance-application data. There’s a part that determines subsidy eligibility, a part that sends applications to the right insurance company, and other parts that glue these things together. Picture the dashboard of your car, which has a few knobs and buttons, some switches, and a big wheel—simple controls for a lot of complex machinery under the hood. All of these systems, whether in your car or on Healthcare.gov, have to communicate the right information at the right time for any of it to work properly.

For large software projects, failure is generally determined early in the process, because failures almost exclusively have to do with planning: the failure to create a workable plan, to stick to it, or both. Healthcare.gov reportedly involved over fifty-five contractors, managed by a human-services agency that lacked deep experience in software engineering or project management. The final product had to be powerful enough to navigate any American through a complex array of different insurance offerings, secure enough to hold sensitive private data, and robust enough to withstand peak traffic in the hundreds of thousands, if not millions, of concurrent users. It also had to be simple enough so that anyone who can open a Web browser could use it. In complexity, this is a project on par with the F.B.I.’s V.C.F. or Sentinel.

Healthcare.gov was given only twenty-two months from contract award to launch—less than two years for a project similar to one that took the F.B.I. more than ten years and over twice the budget.

 

Early in a project, there is a phase in which the client and the contractor work together to create a description of what is to be built. This is called the specification, and building a complex software product without a clear, fixed set of specifications is impossible. The Times reported that

the biggest contractor, CGI Federal, was awarded its $94 million contract in December 2011. But the government was so slow in issuing specifications that the firm did not start writing software code until this spring…. As late as the last week of September, officials were still changing features of the Web site.

This is like being told to build a skyscraper without any blueprints, while the client keeps changing the desired location of things like plumbing and wiring.

“Train wrecks” are never a surprise to anyone working on them. They are not discrete events; they are part of drawn out processes. We only saw the wreckage of Healthcare.gov on October 1st, but the contractors have been working on a wreck for almost two years.

 

The inevitable political overtones are, inevitable, “the political people in the administration do not understand how far behind they are.

The Democrats and Mr.Obama have written a check that cannot be cashed.

The case for semantic interoperability.

Even as the ONC promotes interoperability amongs EMR providers and a national network to support that function, HHS the very agency that has incentivized acquisition of EMR and Health Information Exchange has stumbled in it s own path to Health Benefit Exchange.

The opening of the national exchange has been a disaster. CMS lacks its own expertise to build such a system to interface multiple data bases.

One major problem slowing repairs, people close to the program say, is that the Centers for Medicare and Medicaid Services, the federal agency in charge of the exchange, is responsible for making sure that the separately designed databases and pieces of software from 55 contractors work together. It is not common for a federal agency to assume that role, and numerous people involved in the project said the agency did not have the expertise to do the job and did not fully understand what it entailed.

The case for semantic interoperability.

Even as the ONC promotes interoperability amongs EMR providers and a national network to support that function, HHS the very agency that has incentivized acquisition of EMR and Health Information Exchange has stumbled in it s own path to Health Benefit Exchange.

The opening of the national exchange has been a disaster. CMS lacks its own expertise to build such a system to interface multiple data bases.

One major problem slowing repairs, people close to the program say, is that the Centers for Medicare and Medicaid Services, the federal agency in charge of the exchange, is responsible for making sure that the separately designed databases and pieces of software from 55 contractors work together. It is not common for a federal agency to assume that role, and numerous people involved in the project said the agency did not have the expertise to do the job and did not fully understand what it entailed.

Speaking in the Rose Garden this morning, President Obama acknowledged the problems with Healthcare.gov, but said that “the Web site’s gonna get fixed.” He echoed the “surge” language in his statement, saying, “We’ve got people working overtime, twenty-four-seven to boost capacity and address the problems…. We’ve had some of the best I.T. talent in the entire country join the team, and we’re well into a tech surge to fix the problem.”

Can a “tech surge” work? In his seminal book on software project management, “The Mythical Man-Month,” Fred Brooks writes that “adding manpower to a late software project makes it later.” This is known as Brooks’s Law, and it is taken as gospel by programmers because it is usually true: it takes so much time for new coders to comprehend the system that they’re supposed to be fixing that typically it would have been faster not to include them at all.”

The obvious analogy here is the “Troop surge” in Afghanistan, with more boots on the ground….Let’s hope they can ‘re-boot’  Healthcare.gov

Rusty Foster is a computer programmer and writer who lives in Maine.

attributions:  New Yorker Magazine

No comments:

Post a Comment