A dated discussion of Medical Information Technology

2. Medical Information Technology
And Acquisition Strategy
2 Feb 98
Colonel Frank W Meissner MD
Assistant Program Director
Human Systems Program Office
DSN 240-3475
Internet:
fmeissner@diamond.brooks.af.mil

3. Agenda
●Why talk about acquisition strategy?
●Acquisition quality and reform
●Requirements generation
●Current realities
●Core problems
●An alternative future
●How do we get there?

4. Why Acquisition Strategy?
Because the quality of our
acquisition process determines our
success or failure in obtaining and
exploiting information technology.

5. AIS acquisition quality?
●Cost ($400M invested annually)
●Schedule (comparable to MILCON)
●System performance (lags requirements)
●Value (performance / cost) - no one else uses
our systems (voluntarily)
●Responsiveness (change / time)
Ask the customer!
“Yesterday’s technology solving today’s problems
tomorrow”

6. Acquisition Reform:
lessons
●Simplify processes to reduce cost, cycle time
●Performance-based specifications -- statement
of objectives -- what we need; not how to build it
●New approaches to source selection
●Reduced documentation; management overhead
●Substantial elimination of Mil Specs and Stds
●Manage risk; don’t seek to eliminate it
●Exploit commercial practices and technology
base

7. Requirements generation
issues
●Express requirements for systems (not
capabilities) defined by functions (not core
processes)
●Requirements are defined far from the
workplace and driven by legacy - migration
imperative
●Unstated premise: custom application code
●Complex, rigid, detailed “architectural”
approach rather than evolutionary, adaptive
metaphor
●Business process improvement methodology is
it improving our competitive position?

8. Lessons about requirements
from the private sector
● Change is relentless; requirements are dynamic
● Focus on core processes not enterprise integration
● Computers are becoming commodities
● Communications networks are becoming utilities
● Business value (competitive advantage) is in software and
data (process and knowledge base)
● The “software crisis” is pervasive in corporations
○ Programmable COTS (e.g., work flow, document
management) increasingly used to meet needs

9. The “software crisis”
“Most corporate software is obsolete long
before it’s ever delivered, and it’s usually
incapable of evolving to meet future needs.
Studies of this problem indicate that in some
cases as little as five percent of all software
development projects result in working
systems; the rest are sent back for
reconstruction, abandoned after delivery, or
never even completed.”

10. Custom software in
perspective
CUSTOM
SOFTWARE
CUSTOM
DEVELOPMENT
APPLICATION SOFTWARE
HIGHLY CUSTOMIZABLE COTS
APPLICATION SOFTWARE (“Groupware”)
STANDARD COTS APPLICATION SOFTWARE
(“Office Automation”)
COTS HARDWARE AND SYSTEM SOFTWARE
(“Infrastructure”)

11. ●Why talk about acquisition strategy?
●Acquisition quality and reform
●Requirements generation
●Current realities
●Core problems
●An alternative future
●How do we get there?
Agenda

12. Current Realities
●Mired in Executive Agent (EA) process / structure
●CHCS is an albatross; can we afford CHCS II ...?
●Contractors drive our requirements, and sometimes
our appropriations--e.g. PACMEDNET
●Our legacy systems will not go away in 1997
●Health Affairs leads among DOD's PSAs in
aggressive implementation of CIM strategies
○Do the other PSAs know something we don’t?
○CIM success stories from industry?

13. Our core problems
●We manage software requirements
generation as a specification process but it is
a learning activity
“Software exists in logical space. . . . There are an infinite
number of things you can do. . . . Software is the reflection
of an often unarticulated, incoherent, not well understood
set of human needs, desires, and goals.”
--Dr Edward A. Feigenbaum, Chief Scientist, USAF
“It is no accident that most organizations learn poorly. The
way they are designed and managed . . . create[s]
fundamental learning disabilities.”
--The Fifth Discipline, Peter M. Senge

14. Core Problems (cont.)
●Our acquisition strategy is geared to big
automated information systems (AIS), i.e.,
software tied to dedicated infrastructure;
thus:
○Our infrastructure is fragmented
○Our systems are not interoperable
○Our data is not easily accessed and shared
○Our software development cannot keep up
with our “brain capital”
○We pay too much money to the wrong
sources

15. Core Problems (cont.)
●We fail to achieve clarity of concept and purpose
in our acronyms & information technology
advocacy
“I learned very early the difference between knowing the
name of something and knowing something.”
-The Making of a Scientist
“For a successful technology, reality must take precedence
over public relations, for Nature cannot be fooled.”
-Appendix F, Report of the Presidential Commission
on the Space Shuttle Challenger Disaster
--What Do You Care What Other People Think?, Richard P. Feynman

16. Core Problems (cont.)
“Having failed to distinguish thoughts
from things, we then fail to distinguish
words from thoughts. We think that if we
can label a thing, we have understood it.”
--Anon, in TechnoVision, Charles B.
●We fail to achieve clarity of concept and
purpose in our acronyms and “marketing
pitches”

17. Examples on clarity
Which of the following accurately describes
Composite Health Care System II (CHCS II)?
●a. A clinical information system
●b. A system of systems
●c. An “umbrella program”
●d. A Program Executive Office (PEO)
●e. A POM strategy for “Emerald City”
●f. An organization to replace DMSSC
●g. All of the above, and maybe more

18. Examples on clarity (cont.)
For which of the following tasks is an Executive
Agent (EA) appointed by OSD(HA) responsible?
●a. Requirements definition
●b. Acquisition program management
●c. Infrastructure funding
●d. POM development
●e. Functional proponency
●f. Service legacy system management
●g. Functional policies and procedures

19. Examples on clarity (cont.)
The Venn diagram on the right defines relationships
among which of the following?
Theate
r
Theate
r
Theate
r
Logisti
cs
Clinica
l
Resourc
es
Executive
Information
/
Decision
Support
●a. Information systems
●b. Functional activities
●c. Infrastructures
●d. Logical data bases
●e. Physical data bases
●f. Executive Agents
●g. Acquisition programs
DISN
COE GCS
S
Defense / Health
Information
Infrastructure
DII

20. Agenda
●Why talk about acquisition strategy?
●Acquisition quality and reform
●Requirements generation
●Current realities
●Core problems
●An alternative future
●How do we get there?

21. Alternative Future
●We evolve our information requirements through an
iterative learning process, in concert with our
corporate strategy, goals and objectives
○ Communicate the vision
○ Identify, define corporate “thrust areas”
○ Assemble teams with appropriate expertise (Tri-Service, academic,
private)
○ Select test beds (MTF, MAJCOM, LA)
○ Provide tools: data standards, development environment, contractors,
methodology, “board of directors”
○ Execute iterative prototypes by rapid evolutionary development
○ Report results; “manufacture” and deploy success stories

22. Alternative Future (cont.)
●We standardize, deploy, manage and maintain
MTF information infrastructure as an
integrated, mission-critical utility
○ Elevate Technical Integration Working Group (TIWG)
○ Broaden definition of “infrastructure” to include servers,
PCs, printers, COTS software, etc . . .
○ Get performance needs from current and planned programs
○ All Services complete infrastructure surveys; use HIRS as
repository; keep up-to-date; accessible to MTFs, PMs
○ Consolidate / coordinate MTF LAN management (COMSSC
initiative); establish configuration management
○ POM (DHP) for MTF infrastructure; execution by Services

23. Alternative Future (cont.)
●We build the business case for infrastructure
on the benefits models and FEAs of the
software applications that will share it
○ Involve RMO representatives from each Service early
○ Include savings from capacity management, reduced
duplication
○ Apply benefits from all systems that will run on or can be
transitioned to common infrastructure
○ Incorporate economies from standardization and centralized
management
○POM 98-03 if possible; else next cycle

24. Alternative Future (cont.)
●We fully exploit COTS software capabilities
before developing custom applications
○ Establish process to manage convergence to common
application suites for office automation, and groupware
(e-mail, scheduling, document management, workflow
software)
○ Promote streamlining of high-payback processes with
selected groupware
○ Provide a “brokerage” (Web Server?) for exchange of local,
MAJCOM or LA-developed macros and programs

25. Alternative Future (cont.)
●We tailor acquisition to support rapid evolutionary
development of software and data bases that meet
our requirements and run on our infrastructure
○ Adapt and improve evolutionary (organic) metaphor for both
centralized and local development efforts
○ Enforce adherence to corporate data models and exploitation of
existing data bases through HIRS
○ Build joint application development (JAD) partnerships between
acquisition teams, contractors, and “test bed” MTFs
○ Favor ACAT III and IV “skunk works” initiatives over unwieldy ACAT I
programs
■ Separating software from infrastructure lowers ACAT
thresholds

26. Alternative Future (cont.)
●We measure and evaluate:
○Infrastructure deployment and management
○Software acquisition process quality
○System performance and benefits

27. How do we shape this
change?
●Consensus among AFMS leadership
○TOC analysis?
○Buy-in from AF/SC
●Find the boundaries of AFMS authority
●Carry the discussion forward
○DMIM / CIOs
○MHSS IM Proponent Committee
○TEC