Podcast: The Power of Enterprise Architecture
Hi, I’m Dave Dejewski, the Chief for Defense Business Transformation in the Military
Healthcare System. I will be your host for this edition of the MHS Defense Business
Today’s subject is the Power of Enterprise Architecture. Some of you have already heard a
presentation about enterprise architecture before. You may have come away from that
discussion frustrated. Well you’re in good company, and you’re in the right place, because
I’m betting this podcast that many people have been frustrated – mostly because EA really
is complicated and the perception is that it’s not directly related to them. For your ten
minute investment, I plan to round it all up for you and bring it home. I’ll even show how
EA, with your help, can solve real clinical problems.
We in the Defense Business Transformation office care about this subject, not only because
the law says that we must assert compliance with the Enterprise Architecture, but because
if we do this right, Enterprise Architecture has the power to act as a force multiplier, to put
government leadership in control of complex and diffused development efforts, to ensure
that technology is responsive to the needs of the people who rely upon it, and to ensure
that our medical information technology meets the right standards of quality. Enterprise
Architecture helps us to achieve legal, technical and regulatory compliance; and it frees up
our energy to pursue other things that lead to a quality, safe, and satisfying healthcare
When a pilot of an aircraft configures an autopilot, that pilot expects that the autopilot will
manage thousands of tiny course corrections and control inputs required to keep the aircraft
on course & straight and level. This autopilot device is just like an extra set of arms in the
cockpit that leaves the pilot in control and simultaneously frees up the pilot’s attention to
focus on other things like communicating on the radio, calculating how much fuel is left,
keeping aware of how the weather is changing around the craft, and mentally rehearsing
Very much like an autopilot on an airplane, if you configure your Enterprise Architecture to
manage the thousands of details of your building and process control activities, government
leadership remains in control and a surplus of energy and attention can be re-directed to
other important matters.
The autopilot metaphor works pretty well for describing how, by transferring a set of
instructions to a force multiplying device, we can accomplish more.
But the metaphor breaks down when we consider the massive scale of the healthcare
enterprise we’re trying to manage. We’re not talking about a single aircraft here. No matter
how complex the task of flying an aircraft can be, it isn’t in same league as providing a
quality, safe, and satisfying healthcare experience to more than 9 million patients around
the world. The number of moving parts in that equation is unimaginable.
Before we get into how Enterprise Architecture will help us manage this complexity and
keep government leadership in control, I should tell you what Enterprise Architecture is. Are
you ready? Here it is: Enterprise Architecture, also known as ―EA,‖ is a standard notation for
describing the people, tools and rules of an enterprise. Congratulations, you may now print
the Defense Business Transformation EA graduation certificate. Unless you’re an architect,
what more do you need to know about the technical details? You want to know how the EA
is going to help you, and how what you do today affects what the architecture looks like
I’d like to talk directly to the critics of Enterprise Architecture for about 90 seconds. I hear it
all the time… The Enterprise Architecture is too complicated. It’s full of eye charts. It’s not
written in English!
If you’re a medical person making these comments, I encourage you to take a moment and
look around your space. Somewhere nearby, you’re going to find a book titled Gray’s
Anatomy. Drop that three and a half inch brick on your foot, and I bet you’ll break a toe.
Not only that, a lot of it is written in Latin, it took hundreds of years to write, it cost
thousands of people their lives, and it’s still not perfect.
If you don’t like that example, look a few books down and pull out the physicians’ desk
reference, flip to the chemical formula for Prylosec, and guaranteed, before a non-medical
person gets past the second carbon molecule, they’re going to need a prescription. Just
thinking about reading that book gives me indigestion.
The point is: every domain, from pilots with their excruciatingly detailed diagrams of their
aircraft & maneuvers, to medical professionals with anatomy and physiology, to engineers
with their blueprints and specifications—every professional needs a way to describe the
details of their domain. How complex do you think a set of documents needs to be to
describe an evolving environment like the military healthcare system?
Enterprise Architecture can help us to solve clinical problems; to enforce laws, policies and
regulations; to overcome communications challenges; to ensure compliance with standards;
and more. Once the architecture is properly configured, compliance with the architecture is
like deploying an army everywhere you need them into the enterprise. That army continues
to work as you sleep and long after people rotate to new duty stations.
You want to know how. So let’s go to an imaginary place where we have learned to use the
force multiplying and communication powers of the Enterprise Architecture to convert a
medical tragedy into focused growth and improved capabilities for the Military Health
A US soldier with shrapnel wounds to his neck is air-lifted to a field MASH unit in Iraq.
Upon arrival, the medical team notes that he is bleeding from the mouth, and seconds
later, he loses consciousness.
A field medic who kept the soldier alive during transport tells the MASH team that the
soldier was peppered with shrapnel when a roadside bomb exploded near his patrol.
Although only small lacerations are visible, the medical team knows that embedded
shrapnel can cause serious injuries. The soldier is moved quickly through triage and x-
ray to the operating room. The x-ray arrives in the operating room just as the surgeon
does. A quick look at the x-ray reveals that an artery was torn by a millimeter-wide
piece of shrapnel. While the surgeon calculates her strategy, other members of the
medical team contact a nearby Military Treatment Facility in an attempt to obtain the
soldier’s medical records, but they’re unable to find what they are looking for. The
support team draws some blood, runs a type and cross to determine the soldier’s blood
type, and prepares to begin surgery. The anesthesiologist delivers the medication
required in order to keep the soldier from experiencing any pain. The surgeon opens to
repair the artery and stop the bleeding. However, the soldier immediately codes, surgery
is put on hold and resuscitation efforts begin. The team is unable to revive the soldier.
It is later determined that the soldier had an allergic reaction to the anesthesia that was
exacerbated by blood loss from the shrapnel injury.
The last line of the after action report reads: Readily accessible electronic Emergency
Medical information is required, to give the medical team the ability to provide accurate
emergency treatment and prevent complications.
Now to make sure this problem doesn’t happen again, Enterprise Architecture works for
us and weaves the lessons learned back into in the fabric of our enterprise. People are
informed of the changes necessary, and the tools and rules (also known as the
technology solutions and policies) across the enterprise are updated.
From the scenario or ―use case‖ we just explored, we can extract a clear problem
statement, such as: ―Care providers in the field do not consistently have quick and ready
access to patient clinical data, which diminishes the accuracy of emergency treatment
decisions and increases the chance of complications.‖ That problem statement, coupled
with the context that the use case provides, is raw material for compliance statements.
A skilled architect might decompose this raw material into Enterprise Architecture
compliance criteria that can be expressed in the architecture and used to make decisions
For the next section, it may be helpful to click on the Web site and download the script
that accompanies this podcast. I’m going to run pretty quickly through the criteria that
we might draw from this scenario, and it may help you to follow along with me on paper.
With problem statement in hand and criteria expressed in the architecture, all applicants
who seek to modernize, enhance, or develop IT business systems that play a role in
sharing information between Clinical Data Management Staff and Care Provider in the
field will be responsible for complying with the following criteria:
– IT System shall provide real-time interface between Clinical Data
Management Staff and Care Provider in the field to exchange Health
Care Information, specifically the required fields as indicated below.
– (To protect privacy concerns) Data exchanges shall use Health Level 7
(HL7) messaging standard to send information between systems as
mandated by the Technical View 1, otherwise known as TV1, on the
following page. (Don’t let terms like TV-1 scare you. This just refers to
a spreadsheet that includes all of the technical standards that an IT
system must adhere to.
Laws, Policies, and Regulations Criteria:
– All applicants seeking to build IT systems shall submit an ―as-is‖ TV-1
(to demonstrate compliance against standards criteria)
– The mandatory data fields listed below must be transmitted to Care
Provider in the field via the interface described above.
Enterprise Data Specific Fields
Personnel Information Name
Address of Record
Demographic Data Gender
Health Status Blood Type
Past Medical History
Elsewhere in the architecture, we also have to describe the characteristics of those data
fields. That’s just to make sure that fields like ―Allergies‖ isn’t populated with a value that
says ―yes‖ or ―no,‖ but actually contains the things that a patient is allergic to.
Once the Enterprise Architecture is configured with these criteria, and because the law says
that every IT investment must assert compliance with the architecture, from this point
forward, no business IT solution will be approved unless it does the things necessary to
diminish the risk that another soldier will die due to a lack of this basic information.
The compounding effect of configuring the architecture like this over time is powerful.
Architecture and architecture compliance criteria can come from anywhere in the medical
enterprise. If you’ve been exposed to a situation where automation may have helped, and
you took the time to draft a lessons learned after action report, there’s a chance that your
situation may contribute to way we configure our architecture in the future.
You may be thinking, okay, Enterprise Architecture does sound useful, but who is actually
making decisions about what goes in to the architecture? There is already a tri-service
Enterprise Architecture Board (the EAB) that acts as the O-6 level gatekeeper to the MHS
Architecture. The EAB reports directly to a two star tri-service governing body. And the two-
stars report to the three star, DASD and ASD level governance body.
For more information about the power of Enterprise architecture, visit our Web site at
www.osd.ha.mil/dbt and keep an eye out for other podcasts on this subject. One of our
podcast programs coming up will handle the subject of EA Compliance Criteria all by itself.
Listening to this program is a great way to find out more about the process of turning
experience into action through the use of Enterprise Architecture.
And that concludes this edition of the MHS Defense Business Transformation program.
Please come visit us at www.ha.osd.mil/dbt. You can e-mail us at MHS_DBT@tma.osd.mil. We’ll
be expanding these podcasts in the future to include Q&A and answers to your e-mail. Until
next time, help us to keep transformation moving forward and remember that good
government is a team sport.