Rev: 01 Feb 2002.
This document outlines our general approach to designing information technology solutions for patient care.
We believe that improving quality is easy, but improving productivity is hard -- so we focus on improving productivity first. Often quality improvements are easy to insert into the framework of productivity improvements; but if one starts with quality improvements first then productivity may be exceedingly hard to fix. There are typically many paths to quality improvement, but relatively few paths to productivity improvement.
All solution spaces have a variety of constraints. In doing design we seek to identify constraints, design both within and outside of the constraints, and consider the impact on design of varying those constraints.
Clinical systems have an unusually diverse and complex range of regulatory, legal, and financial constraints -- all of which may vary substantially from region to region or day to day. A change in the organization and delivery of health care, new regulations, or legal precedents may at any time make a design feasible or impossible.
Understand the economic foundations (health care financing and implications of changes to the financing model).
Review applicable aspects of the project and corporate business plan (ROI estimates, financing, market analysis). Identify dependencies, critical success factors and key assumptions (e.g. financing environment, cost of transactions, time for transaction partners to complete contracts, etc.). At each checkpoint in product development reevaluate the business plan -- do the assumptions still hold, does the product still make sense?
Identify the unique aspects of the clinical context. Context in this case is closely related to constraints. For example: designs that make a great deal of sense in a capitated environment can be nonsensical in a fee-for-service setting.
Identify the pain points, scope for significant productivity enhancement, and scope for major error reduction. We favor interventions and designs which product early productivity gains for the primary users at low costs; in some cases we may advocate an immediate smaller gain of this type over larger productivity gains which are deferred, don't accrue to the primary user, or require significant process reengineering to achieve.
Some designers advocate disregarding the tools available for implementation, and designing without regard to what is available or what is affordable. This method works for some people, but it does not work for us. We need to understand the potential tools and technologies and to explore the technology domain. Sometimes this means looking for a technology to solve a problem, sometimes (heresy!) it means looking starting with a technology and looking around for a problem it can solve.
We prefer to work in multiple directions simultaneously. This means early discussions with end users (as well as later validation of fundamental designs and prototypes), early input from stakeholders, early discussions with sales and marketing, review of the academic literature, survey of competitive "best practices" and lightweight gap analysis (if indicated), informal discussions with industry veterans and careful reviews of any past projects -- including discussions with the principals involved in prior projects. We strongly favor involving engineers and developers from the very beginning of the design process. It also means simultaneously identifying the core concepts and underlying ontology, abstracting the problem away from the clinical context to a broader problem space, and creating models from simple diagrams to basic object-design methodologies up to semantic network models based on the underying ontology of the problem.
We often assemble very early and immature prototypes; we have found that it is very difficult for persons to participate in a discussion without something to look at and play with. In most cases this early prototype will be completely discarded.
In all cases we stay focused on the core building blocks of clinical applications: clinical concepts (terminologies, codes) and the flow and the reuse of a core set of clinical concepts throughout the application, workflow, transactions and transaction partners, messaging and user views into the information space.
During the design process we value many informal one-on-one discussions with multiple participants, these are supplemented with a limited number of more formal reviews throughout development.
We expect that the "final" design will in fact change significantly during implementation; substantial changes require revisions and reevaluation of models, constraints, assumptions and critical success factors. We've been told we "think out of the box"; we take that as a compliment.
We like to do very early and very lightweight usability testing rather than late and very expensive testing. We are fans of Jakob Nielsen. We believe aesthetics are important to the user experience, but we believe an application which is to be used thousands of times under potentially very stressful circumstances should be subdued, calming, and clear. We are not graphic artists and we recommend input from a thoughtful and experienced graphic designer with a strong aesthetic sense and a feel for industrial design.
Obtaining large scale benefits from information technology means that a business has to change its processes and functions to suit the technology. This is an unfortunate truth: humans are far more flexible than software. This process change is reengineering -- even though that name is now in disfavor.
That said, we believe reengineering should be approached with great caution. It is very difficult to change the engine in a vehicle that can't stop, especially if that vehicle is "under enemy fire". Our goal is to design solutions that provide early and measurable benefits with limited changes to workflow and user roles. If a system has delivered those returns customers may be willing to make more extensive changes for greater yields (e.g. reengineering), or they may prefer to focus their energies elsewhere.
We don't believe in perfect and eternal solutions to the design of clinical information technology solutions. Even if a design were perfect for one customer in one context, it would be decidedly unsuited to another customer. We seek to create designs which can be extended, which can evolve naturally, and which are not tightly coupled. In a modular application each module should potentially be separable and reusable -- in practice this means that a messaging layer between modules is part of the underlying architecture.
Some problems (e.g. Evaluation and Management coding) are inherently complex -- but often with intensive study relatively simple approaches can be devised. It takes serious work to create simple solutions, and great discipline to stay simple. Of course in software implementation even "simple" projects can be extremely challenging ... Our preference is to design for an extensible solution, but to introduce a very simple initial implementation. In the real world the simple implementation may suffice, and if more complexity and power is needed then the architecture will be in place to support it.
The above principles are all very well, but in the real world time is short and resources are limited. Shortcuts and hacks are inevitable.
Our goal is to identify when something is a hack or shortcut, to ensure that everyone realizes the sizeable price that will be paid down the road, and to seek a hack that is at least fixable and is ideally the first step towards a more architecturally correct design.
Hacks and other shortcuts should not be taken without due consideration -- but a well-chosen hack may mean the difference between corporate success and failure. Even if the cost of fixing the hack is 10 times the initial project cost, that may be well worth bearing at a future point in the business cycle.
Since Google does not use indexing information stored in meta tags, I've reproduced some of the meta tags here to facilitate indexing.
<meta name="author" content="John G. Faughnan">
<meta name="keywords" content="design,methodology,clinical application, problem solving, jfaughnan,jgfaughnan,.en-us,.us,english">