Health IT as an Ultra Large-Scale System

This week I want to discuss a technical report that was issued in 2003, but that (I think) can help us understand why getting to an interoperable health IT system is so hard, and why we are not advocating for a single health care IT system.

We often see health care systems (and the IT in health care) as different and not comparable to work that has been done in other areas. However, I think there is a lot that we can learn from other industries.

Coordinating a billion lines of code

The Software Engineering Institute’s (SEI) report, “Ultra-Large-Scale Systems: The Software Challenge of the Future” sought to answer the question:

As more and more systems become interconnected and have to work together, how do we manage an interacting code base that exceeds 1 billion lines of code?”

The reality is that different health IT systems (when they are connected together and interoperable) could collectively represent much more than 1 billion lines of code.

How the SEI Report Can Help us Understand the Challenges of HIEs

The report suggests that we need to change the way we look at these large, interconnected “systems of systems.”

Ultra-large scale systems are not about a single software application, or a couple of applications working together, but rather an “ecosystem” of interacting software systems. In health care, small practices may have:

  • a billing system
  • a clinical system
  • email
  • web portals, and
  • other IT systems.

Most medical centers have 20 or 30 different computer programs that work together to take care of patients.  Take 20 or 30 different programs, multiply that by the number of medium to large medical centers in the country, add in the small practices, and we are talking about thousands of programs that need to work together.

Building that from the top down isn’t going to work. The report argues that we need to think differently about how we create ecosystems in the health IT industry.

How Health IT Interoperability is Like Designing a City

In some sense, health IT interoperability is like the difference between constructing a building and designing a city.

While a blueprint with detailed floor plans of plumbing, electrical and heating/cooling systems makes sense for a single building, it doesn’t work if you try to do the same thing for an entire city.

Similarly, going from designing a piece of software for a health care practice to designing how all of those different pieces of software interact across the country is a very different process.  It isn’t about engineering and blueprints and construction plans, but about zoning laws, roads and infrastructure, rules and governance, safety and protection.

Like Other Ultra-Large Scale Systems, Health IT cannot be Managed Top Down

The SEI report goes on to describe the characteristics of an ultra-large scale system that actually has an eerie similarity to the challenges we face in the overall health IT industry.   It suggests that ultra large scale systems cannot be managed “top down” in a monolithic way, but will require a coordinated, decentralized way of meeting local needs, while keeping all of the systems working together.  Different parts of the system will be in different stages of evolution at any given time.

We see this with IT in healthcare. Rural hospitals will have different capabilities (and very different requirements) than large, urban, academic medical centers.  We will need to find solutions that recognize these differences while we simultaneously provide a common set of building blocks to support both small and large medical practices.

Healthcare is also Constantly Evolving

In addition to the differences in capabilities among different providers, medicine, medical care delivery, and the IT to support health care are all constantly evolving.  There are changes in medical delivery and payment models reflected in the Affordable Care Act, while at the same time, we are seeing more consumer-focused health care devices and dramatic changes in how we use communication technology in society (who knew we would need to summarize our life in 140 characters?). I often talk about taking the “path of least regret” in the standards work that we do at ONC, and it’s intended to be a humble acknowledgement that we want to do the right thing now, and still make it possible to accommodate changing needs in the future.

We also can’t Build Systems Without Thinking about the User

There are two other key points the SEI report makes. First, we have to realize that in the complex world of an ultra-large scale system, we can’t build systems without considering the people who will be interacting with those systems.

People don’t interact with the health care system – they are PART of the health care system. This means we have to make sure that we consider providers as part of the health IT system – user interfaces and workflow integration can’t be considered nice-to-have features, but an integral part of the success of these systems.

We cannot leave the patient out of the equation – patients are not simply the objects upon which the health care systems operate. They are a central part of the success of health IT systems. It’s why access to data and inclusion of patients in the health IT ecosystem is such an important focus of health IT.

Interconnected Systems Will Never be Perfect

Finally, the SEI report says that in complex, interactive, tightly-coupled systems, failures will occur. We have to understand that these systems will never be perfect, and we should be prepared for potential problems. We will never be able to completely eliminate defects in the system. Some standards for interoperability won’t work the first time. Security and data breaches will happen.

We can’t let “perfect be the enemy of good,” but we must also work hard to respond quickly to problems, disseminate patches and solutions and aim not for a perfect system, but one that is robust, resilient and that can quickly recover from problems that might occur.

ONC’s Approach to Health IT

There is a lot that we are doing at ONC that fits into this notion of an ultra-large scale system.

1.      We support flexible standards

We have not tried to develop a large, centralized, top down approach to interoperability. Instead, through the Standards & Interoperability Framework, we are developing and harmonizing a portfolio of standards, services, and policies that provide flexible ways of meeting the challenge of having different systems in different setting talk with one another.

2.      We try to pick standards that work for the future

We have constantly tried to pick that “path of least regret” in advancing interoperability, but providing for future flexibility to accommodate new payment models and new information technology.  We have made patients a central part of our solution through empowering consumers, developing a standardized way of using Blue Button, and we have emphasized that usability and work flow integration are a key part of success in interoperability because it recognizes that people are part of the system, not just interacting with it.

3.      We make incremental changes with community feedback

Finally, we have tried to take an incremental approach that engages the community to help us identify problems and quickly come up with new solutions.  We know that there will be challenges and things that don’t work as we intend, but as with any ultra-large scale system, we are working to develop and support a robust, self-correcting health IT system.

We are not developing a blueprint of a single, health care IT building. We are developing a city with variation, heterogeneity, robust infrastructure and wonderful unique neighborhoods that will entice all of us to participate. It’s a very different way to look at the problem, but one that I think gives us a lot of interesting food for thought.

What do you think about ONC’s approach to Health IT standards? We would love to hear your thoughts below.

Next week: A Preview of HIMSS 2013

Read other blogs by Dr. Fridsma on standards development and harmonization, coordination of federal and private efforts toward interoperability and health information exchange, and health IT innovations.


  1. I’m glad to see the effort being made to at least get some kind of standard platform for medical IT.

  2. To achieve Interopreatbility as well as proceed with multiple (sometimes conflicting) priorities, the utilization of a robust Data De-Identification software is critical. Data should be consistently de-identified across all ACO participants (according to OCR specifications) and NO real PHI should leave any ACO participant. This will ensure robust testing to ensure proper patient care, reporting to the government as well as individual participant management and also support Big Data and Cloud initiatives.

  3. Robert Barker says:

    I liked your entire piece and the strategy of ONC’s approach to Health IT Interoperability and Standards. One of the key points I think you make is you recognize ‘unique neighborhoods’. For instance, when a CCDA is sent from a Cardiology Neighborhood to a Pediatric Neighborhood and then on to the PCP, the data requirements vary for both what is collected and exported (and hopefully ultimately imported). Hopefully in MU3 we will see more baseline content for CCDA regarding specialties. But having the CCDA as an ‘infrastructure’ piece with the Minimum data set, with defined transports and baseline security applying to all of the software inhabitants, we will see more plug and play sooner rather than later in HIT.

  4. Jason Czaplewski says:

    You’re in a tough spot. One perspective is begging for you to enforce standards in a more strict way, while another is asking you to work collaboratively.

    One might look at the history of the weakly enforced, arguably widely varied implementaiton of HL.7 and say, well, we’ve tried bottom-up collaborativeefforts and still can’t seem to lick this. Do we think this is a fair statement of our past? It sure feels like it.

    Do you think we will finally prove we can somehow accomplish a bottom up approach that can work? It would make it a whole lot easier to focus on delivering value to those poor folks interacting with our systmes as they take part in the healthcare those systems deliver.

  5. Jim Kretz says:

    Permit me to suggest that we may not need blueprints for the entire city. To follow the analogy a bit further, what we need to make sure that the same set of essential services can be provided to all structures are standards, in this context, called building code, plumbing code, electrical code, etc. It does not appear to me that we have billions of lines of code interacting willy nilly, or even a billing programs that can initiate modules in one’s laboratory system, for example. Instead what we seem to be grasping for that would constitute interoperability, is a universally understood lingua franca, otherwise known as the consilidated CDA.

    The killer is that unless the current set of HL7 CDA templates are modified to require structured data that corresponds to SNOMED, LOINC, and RxNorm and permit unstructured data if and only if structured data is present, the task is hopeless, not because we have billions of lines of code but rather the incoming data stream will prove unparsible. The second essential change that must be made to the templates is that they must include the licensed/liable professionals national ID and the organization ID with which that provider was working. In other words, the provenance of the data must be maintained at the detailed template level or it will be lost upon incorporation and subsequent retransmission of the next C-CDA for that patient.

    The typical explanation for why provenence data cannot be maintained at the template level is largely a self-serving assertion that this would be too difficult to implement. The trouble with such assertions is that they seem to assume that extensive audit records and trails can be maintained but the pieces of the very same data cannot be part of the atomic level clinical record.

  6. E. Santos says:

    I liked your entire piece and the strategy of ONC’s approach to Health IT Interoperability and Standards.

  7. Mary Smith says:

    Why is it that the medical field is so far behind on information exchange technology. I realize that security is a big issue. However, the amount of time wasted by medical staff and patients because of the lack of information exchange is ridiculous. It is a HUGE waste of resources. The sooner they get the HIT in place the better!

  8. I think you could consider sharepoint for webportal solution for health sector – you people at least need portal and ready made portal for aggregate the information anyhow so next part is application you also can design application with it but having everything on cloud is ideal.

  9. As an IT professional I like the question: “how do we manage an interacting code base that exceeds 1 billion lines of code”. I agree that a bottom up approach would be ideal. Health care IT building has interesting approaches in Europe…

  10. Brian Ahier says:

    I think you are definitely on the right track :-)

Leave a ReplyComment Policy