Entity Relationship Diagram for HC and HCIT Policy | [node:field-byline] | Healthcare Blogs Skip to content Skip to navigation

Entity Relationship Diagram for HC and HCIT Policy

November 13, 2009
by Joe Bormel
| Reprints



I'm sharing this in the spirit of "Wow, did you see this?" The contained title for me is not the point. Although we all know that healthcare delivery, it's financing, the HCIT requirements to get to

STEEEP (IOM's well stated values), national policy, and legislative structure is complicated, we rarely see a diagram that attempts to bring it all together.

Could someone with a deeper background in business modeling break the color code for me?



Thanks for your comment.
It spurred me to follow your lead, and try to break the code. I decided that, for any working system, there would need to be clear definitions (and therefore perhaps colors, use of shapes, and arrow directions) for accountability, risk-assumption, and clear (transparent) communication and reporting.

That leads to clarity that standards are critical. And that, led me to realize that, if we're serious about making the complexity manageable, we would need the modeling unambiguous, and that means UML. And, there is an already sanctioned modeling and color coding for the four major classes in healthcare:

The lack of recognition of the value and importance of starting with the clearest possible definitions and adherence to standards where possible is a policy problem.  I dont want to believe that further obfuscation of a complex system is intentional.

I hope that the ONC and subordinate committees have a better diagram than the Joint Economic Committee of Congress!  That could and perhaps should start with tightening up the opening diagram.

The only thing I can tell you is that everything in red deals with funding or something money related. Sounds like the right color for a government model. Frighteningly complex.


Thanks for your read of the diagram, and your read on the bigger game being played.

I've got a basic question though. Do we need a business model diagram that's reasonably complete?

If we were building an enterprise class application, the answer would be a resounding "yes."

But, if we were diagramming a phone system from the 1950s, there might be 900 hundred entities with essentially, a complete point-to-point mesh. The diagram would create no value.

Your statement around cross subsidies got me thinking. If the diagram captured everything that the CBO has considered, like broad scale deployment of medical home, the diagram would need to show possibly much more detail than could be useful.

Your thoughts?

The more that I look at this, the more it upsets me.

Note how it has been constructed such that consumers and their providers are on opposite sides, separated by all kids of boxes in between. Note also that consumers and providers are ACTUALLY only separated by one box, the HIE. It appears however that "governmet" is driving a "wedge" between patients and their doctors.

Note also that nearly all red lines point to or originate from the comsumers, even when those lines are subsidies.

The IRS gets a bigger font than the IOM, Accountable Care Organizations or Medicare/Medicaid.

In one sense, this is a brilliant piece of marketing and FUD. In another sense, it is a piece of slander and smear.

Before I get a feedback on the graphic above, my intent was to show just the backbone, i.e. Entity, Role, Participation and ACT. They carry the four colors into the explosion of the more detailed RIM. The argument would follow that a similar explosion ought to be possible for the Health Plan above.

For example, if the performance measures for the government are "owned" (sanctioned, whatever the right word is) by the government thru CMS, and NQF is the primary contractor, with AMA subcontracted around the coding, there ought to be clarity about that, and illustratable in a diagram. In too many discussions and articles these days, there are other agencies (including NGOs) that are articulating incompatible sources of truth on measurement for reimbursement.

[Revised.  Interesting little glitch there. I wrote everything only once, but somehow it came out three times. Here it is, de-duped:]

As the BI guy, I have a love for "drill-down" and as an architect I have a love for "cartoons" and as a former scientist, I have a love for "models".

That means I try to understand, and represent, the world through pictures layered on top of one another, each successively either more detailed or more abstract.

So, to answer your question, one giant diagram with _everything_ in it would be overwhelming and useless as a teaching tool. It would, however, be _incredibly_ valuable as a database from which to extract/overlay "views", "models" and "abstractions" (subtle difference, models are top-down and abstractions are bottom-up). These views, models and abstractions are immensely valuable in teaching, comprehension, problem-solving, problem-anticipation, rational design and so-on.

I respectfully disagree with your assertion that a diagram of a 1950's point-to-point telephone network would create no value. That mesh when presented visually makes the case far more compellingly than any number of words or numbers could of the inefficiency and irrationality of that type of architecture. If diagrams like that had been made in the 1950's we might have had hub-and-spoke, p2p or ESB architectures much sooner.

One other point about this type of "global" view, from the perspective of each of the entities, their own architecture might have looked entirely rational and efficient. It is only once that "siloed" view of the world is broken and the entities are enabled to see the overall system costs of their silo that momentum for rational and perhaps initially costly change can be built. Bringing it back around to one of my favorite metaphors, it is in many ways exemplary of the "tragedy of the commons", where each individual actor must step back and assess the systemic impact of their individual optimal actions, rational behavior will lead to irrational results.

Thanks for your perspective. I agree that there would be communication value in creating a visual of the 1950s phone system. That presupposes, of course, that it would have been part of an "options elaboration" process that showed the alternatives you described. Sadly, in our age and many others, people often don't elaborate and evaluate their options. They just leap forward on a single option and get a sub-standard result.

When I first saw the Healthcare diagram, I was hopeful that it might clarify the relationships.  There is, of course, the alternative use of diagrams to obfuscate the relationships, and to belittle those proposing a change by crying "see all of the needless and wasteful complexity?" 

I put the "Don't Panic" graphic in to soften the use of diagrams below.  The net of the discussion is simply that using diagrams, in this case 'signal flow graph' (SFG) diagrams, it's possible to model something, and then accurately simplify the diagram with a little algebra:

Graphics came from here:

The cool thing is that it is possible to see the impact of feedback on a system with this approach that is otherwise not clear.

And that is why I was hopeful that it might be worthwhile to have a diagram that captures a bit of the necessary complexity.

Thanks for digging this up Joe,

and for starting the conversation. One important point not to overlook is that this graphic was created by JEC Republican Staff on behalf of the ranking Republican member. In other words, this is the REPUBPLICAN'S VIEW of the DEMOCRATIC PLAN.

Politics does neither seek truth nor impartiality. I suspect that there is a great deal of complication, obfuscation and misrepresentation in this diagram. I also suspect that the finance boxes were purposefully done in red and that the color-coding was chosen to highlight Republican criticisms and aims rather than to illuminate and illustrate.

That being said, this isn't actually all that complicated a diagram. Anyone one who has spent time with data, information, network or business architectures would look at this as a pretty high-level abstraction.