1. Health Informatics Series
Software Selection
Mark H. Spohr, MD,
Health Care Informatics IER/HIS, World Health Organization, 20, Avenue Appia, CH-1211 Geneva 27 SWITZERLAND
Learning Objectives:
- To understand the process of software selection
- To understand characteristics of the software market
- To understand software contracting
Performance Objectives:
- List the steps to specifying software
- List the desired elements of software contracts
One of the most common questions we receive is: "How to I select the software I need?"
Our answer to this question is usually to look at the information needs, business processes and workflows first then look at software.
The real first question should be: "What data do I need to make better decisions?" In order to answer this question, the Enterprise Architecture is a good approach that looks at the existing data architecture, information needs, institutional capabilities and puts these into the context of the guiding organizational principles.
We will assume that you have undergone a process such as the Enterprise Architecture approach prior to embarking on this Software Selection process.

2. Why Health Informatics?
Health Informatics provides information to make decisions
Better information leads to better decisions
Health care, management, planning and policy all need good information
Health care, health management, health policy and health planning all depend on having good information to make decisions.
I have been working in health informatics for thirty years. Twenty years of that have been in international health. I firmly believe that improving information leads to better health.
The Health Informatics Series will explore different dimensions of informatics to give you information you can use to build better information systems and improve health.
I have degrees in engineering and medicine. I started by founding a company in the US which gave doctors health information tools. I have worked internationally with The World Bank, The Asian Development Bank, The World Health Organization and bilateral aid organizations including USAID, Australia AID.

3. Enterprise Architecture
Before selecting software for specific functions, you should undertake an overall assessment of your health information systems and develop an architecture, framework and principles as well as a requirements management governance organization.
The Enterprise Architecture approach does a good job of covering this ground and will give you the organization and structure necessary to move forward on software selection and implementation.
For more information on Enterprise Architecture methodology, you can view the EA presentation in this series.

4. Software Industry Characteristics
Information Technology is a "Network Industry" with these characteristics:
Complementarities, compatibility and standards
Consumption externalities [network effects]
Switching costs and lock-in
Significant economies of scale in production
Before we delve into the software selection process, we should understand a few things about the software industry that will help put the process in context. If you have a good understanding of these characteristics, it will help you make better software decisions.
The primary characteristic is that software is a network industry which is different from many other industries such as food, stock markets and many manufactured goods.
A network industry depends on complementarities, compatibility and standards and gains benefits from externalities (network effects).
It is subject to switching costs and lock-in. It benefits from economies of scale.

5. Complementarities, compatibility and standards
IT is a System that consists of:
Complementary products (computers, monitors, keyboards, software, operating systems)
All of these must be compatible to work together
They all must follow standards to work together
Vendors should follow these standards
Often vendors try to limit your options by producing proprietary computers, software, operating systems, and data formats that do not follow standards and do not work well together.
Computers and not useful without keyboards and monitors or software. These are complementary products.
All of these are required to be compatible with standards.

6. Network Effects
These are known in economics as "consumption externalities"
One telephone is useless, two are useful, three are a network
The value of the network increases exponentially as more "nodes" are added.
The potential for network effects in health information systems and patient care management is huge.  Physicians would value other physicians (and patients) being on the same network so that they could share data and coordinate patient care. Patients would like to communicate with their physicians and to coordinate care for themselves. Managers can benefit from information about patient health status and the operation of the health system.

7. Switching Costs and Lock-in
Users can be prevented from switching by various factors:
Contracts
Training and learning
Data conversion
Search cost
Loyalty cost
Adherence to standards can help address some of these costs
Contracts: Users are sometimes locked into contracts for service, supplying parts, and buying spare parts….
Training and learning: Consumers are trained to use products operating on a specific standard.  Switching costs would include learning and training people, as well as lost productivity resulting from adopting a new system.
Data conversion: Each piece of software generates files that are saved using a particular digital format.  Once a new software is introduced a conversion software may be needed in order to be able to use it. Notice that the resulting switching cost increases over time as the collection of data may grow over time.
Search cost: One reason why people do not switch very often is that they would like to avoid the cost of searching and shopping for new products.
Loyalty cost: Switching technology may result in losing some benefits such as preferred customers’ programs, for example, frequent-flyer mileage.

8. Economies of Scale
Software is the ultimate product when it comes to economies of scale
The first copy is very expensive (design, coding, testing)
All subsequent copies cost nothing to produce
(Implementation, however, does have costs)
Software is the ultimate product when it comes to economies of scale.
The first copy of the software is incredibly expensive to produce, requiring the investment of many thousands of hours of design, coding and testing.
The second copy (and all subsequent copies) cost nothing to produce.
Open source software takes advantage of these economies. As soon as one person makes the investment in software, all others can benefit. In the corporate for-profit world, this is a disadvantage. In the public sector, this is a great advantage.

9. Data Economy Data is expensive to collect
The cost to copy and communicate data is very low
Must have data standards to have meaningful communication

10. Open Source Economy
Free Open Source Software (FOSS) allows sharing of high development costs
The public sector can benefit greatly by sharing their contribution to software development

11. Now that you understand the market…
You can use your understanding of these market characteristics to your benefit when selecting software:
The value of Standards
How to benefit from Network effects
Lock-in (and how to avoid it)
The true cost of software and data

12. Health Information System Life Cycle Methodology
The overall health information system life cycle consists of three phases:
Strategic and Information Systems Planning (such as the Enterprise Architecture Approach)
Strategic planning (What information will I need?)
Information and systems planning (How will I collect that information?)
Software Selection Project (this lecture):
Requirements Definition
Business justification
Software selection
Implementation (after selection)
Implementation Planning
System design
System Implementation

13. Overview of Software Selection
Define functional and technical requirements
Research software vendors
Conduct vendor evaluations
Plan for the implementation of the selected software
Define functional and technical requirements:
Identify requirements
Define and prioritize business requirements
Assess current systems and processes
Research software vendors or development options
Survey software
Conduct vendor research
Prepare business case scenarios
Define short list
Evaluate and select software
Conduct first round of vendor demos
Confirm finalists (short list)
(At this point, the business case may need to be modified in light of the capabilities and limitations of the existing software options.)
Conduct business case presentations
Negotiate and Plan Implementation
Reference checks and negotiations
Plan implementation

14. Preliminary Considerations
Does an information system plan exist?
Is software the answer to this problem?
Does software exist or will the project require custom software or extensive modification of existing software?
Does an IS plan exist?
There should be an overall information systems plan and architecture to avoid randomly purchasing and implementing software that is not suitable.
Is software the answer?
Look carefully at the data needs and goals for the business. Consider that new software may not be the best solution to this problem. A change in business processes may achieve the same (or better) results.
Does software exist?
Common applications will have a range of capable software available. If the particular business requirements are unusual, existing software may need to be modified or new software will need to be created. Consider open source software in all cases for ease of modification since software will need to be modified in most (all) cases.
Does everyone understand the project's impacts?
Selecting and implementing software takes significant time and resources as well as process disruption. Everyone should understand this at the start to avoid unrealistic expectations.

15. Understanding the Project
Does everyone understand the project in terms of cost, timeline, internal resource commitments, impact on the organization and the need to change processes?

16. Define the Scope What functions/data are needed?
Is this within the overall information architecture vision?
What is the business case?
What are the process impacts?

17. Assess and Plan Review current information systems and processes
Design the "To Be" information systems and processes
Design and document changes (how to get from "As Is" to "To Be")
Current IS systems and processes:
An assessment of the existing systems and processes must be performed. This will document the existing data collection, workflows, decisions, and responsibilities. In addition, the installed infrastructure should be assess to understand what human resources, information technology, and communication resources are in place currently.
After the assessment, the desired end point "To Be" information system and processes should be mapped.
Finally, the gaps between the "As Is" and "To Be" should be listed. These can be categorized into technology hardware, software, communications, business processes, data standards and interoperability, and human resource capabilities.
Note that this software selection process will address only the "Software" and data standards and interoperability gaps but all of the other gaps will need to be addressed during implementation.

18. List and plan to address gaps in:
Mind the Gaps
List and plan to address gaps in:
Computer hardware
Software
Communications
Business processes
Human resources
Data Standards and Interoperability

19. Evaluate Software
Using the "To Be" system design, create a list of software functional requirements tailored to your specific needs.
Data elements captured
Data input screens
Data access screens
Workflow capabilities
Interoperability capabilities – functionality
Standards supported
Evaluation matrix should have some type of scale to represent each software option and how well it corresponds to the requirements.
This could be on a scale of 1 to 5 where 1="does not meet requirements" and 5="exceeds requirements". This scale could also be a range of 1 to 3 to make evaluation easier where there is less to differentiate.
Alternatively, this could be a simple "yes or no" tick box for basic functionality.

20. Compare Software
Create an evaluation matrix to compare the various software options against each other.

21. Make or Buy? You always have the option of building your own software
This should only be considered when you cannot find adequate software or the software is too expensive or would require extensive modifications

22. Modify
Consider that open source software will be easier to modify and will give you more control of the product
All software will require some modification. Always look at how easy it is to modify the software and who will do the modifications.

23. Make vs. Buy… Or Modify Buy Software Build Software Modify
May not be an exact fit to your needs
Build Software
Long expensive process not guaranteed to succeed.
Modify
Start with open source software that you can modify
This may meet only part of your needs but can be modified to meet your exact requirements
Everyone benefits from your investment in the software
Often the decision on software is presented as a "build vs. buy" decision where you look for software that meets your needs and then buy it or you don't find software that meets your needs and then you have to build it from scratch.
There is another option that is increasingly attractive. This is the "modify" option. You can start with software that meets some of your needs or which has a useful basic architecture and then modify it to meet all of your needs. This option is difficult with commercial proprietary software which requires that the vendor be agreeable to make the changes. (Often local vendors are not skilled or not permitted to make changes.) However, with open source software, you have access to the underlying instructions "source code" to the software so it becomes a much more feasible project to make the changes yourself or to hire someone to make the changes.
Another advantage of this option is that the investment you make in changes to the software accrue to the benefit of you and others who use the software, rather than being locked up in a proprietary system

24. IT Resources
Most organizations will need additional IT people for new IT projects
Consider contracting with an outside specialized IT service for new projects or modifications to existing IT projects
Baseline IT needs can be staffed by in- house personnel
Even if you have an adequate IT department, it will take additional resources to implement new software or build/modify software for new functions.
It is probably wise to consider contracting with outside services for episodic IT needs and keep your in-house IT department staffed to deal with "baseline" needs.

25. How and Who? Who should evaluate software? How?
Persons familiar with the business processes
People who will use the information
Technology people who will implement
Experts in technology
How?
Consider a broad "landscaping" to gather all potential solutions
First pass to eliminate weak solutions
Second pass to decide on finalists

26. Software Selection Factors
Software Capabilities
Vendor strength and capabilities
Size of vendor
Length of time in business
Experience with this application
Vendor references
The software selection matrix will help you compare software capabilities.
However, there are other factors which go into selecting a vendor and software.
If you choose open source software, you may have a choice of several vendors who can support that software. This will give you more options for the present and also for the future where the initial vendor may not be performing well. You can then replace the vendor with another who is also familiar with the software but may be more responsive to your needs.
Vendor strengths and capabilities
Clearly you want a vendor who has the people experience to support your application. You should get an idea of the size of the vendor from the number of employees, the number of projects they have under contract, the length of time they have been in business, their experience with this specific application (it will be difficult if this is their first installation of the application). Vendor experience with the software platform (operating system and programming language and database) is important.
It is important to obtain references from the vendor of current and former clients. These should be checked carefully with questions that probe the performance and responsiveness of the vendor. Inquire specifically about any problems and how these were resolved. Be suspicious if there were no issues or if the answers are vague.
Finally, all software will require some degree of customization or modification to meet your needs. You should carefully evaluate the vendor's ability to modify software. This is where speaking with prior clients of the vendor can be valuable. They can give you a good idea of how capable and responsive to requests for customization the vendor will be. Here again, using open source software can give you more options in this area.

27. Modification and Support
Alternative support options (open source can provide the option of multiple vendors for support)
Customization and software modification capabilities

28. Vendor Negotiations
Initial software purchase costs – what is included?
Definition of "users" (concurrent, named, development, active)
Number of users or sites
Ongoing support costs
Response time
Maintenance costs
Cap on support costs
Often it is desirable to have two vendors selected as finalists for negotiation. This will improve your position if one vendor becomes difficult during negotiations.
Often software is licensed by number of users or by number of sites (or some combination). It is important to define these terms. Development and testing users and sites are often not included in the costs but make sure this is spelled out. When counting users, ask if they count concurrent users (users at the same time), active users (users who have been active within a defined period of time), or named users (everyone who could possible access the application). You will have to understand these conditions and relate them to your usage pattern to calculate the cost.
Ongoing support costs will be significant and should be carefully negotiated.
There should be a specified cost and response time for dealing with problems.
Maintenance updates should be scheduled with a response time.
The rate for support is usually a percentage of the cost of the software. Ensure that this rate is capped to prevent unreasonable increases in the future.
When you have open source software, it gives you more flexibility in dealing with vendors since you are not locked into a particular vendor and can choose a different vendor if one becomes unreasonable.
There should also be a specified rate for customization and modifications to the software.

29. Vendor Implementation Assistance
The contract should spell out:
Number of days of configuration assistance
Number of days of user training (when, where, cost)
General technical assistance
Specific technical assistance (hardware selection and conversion costs)
Training materials and implementation tools
Availability of vendor support hours

30. Cost Core charges typically include: Software, hardware and services
Per system base charge
Charges for additional modules
Per user charges ("seats)
Software, hardware and services
Implementation and training
Cost for Changes

31. Payment schedule: 50% on signing
20% on installation (after "acceptance")
30% upon completion and ready for "go-live"

32. Acceptance Criteria
System performance levels (response time under expected load)
Document custom work that will be done
Functional Specification
"Out clause" for non-performance
If the vendor cannot or does not perform, there need to be set criteria and time deadlines to recognize that fact and terminate the contract.
The system should have specified performance levels. This can include screen response times under heavy load and users.
Any custom work that is necessary should be specified clearly along with a statement of the cost and payment schedule.

33. Essential Contract Elements
Clear definition of objective criteria to define a successful implementation
Contractual remedies for failure to meet acceptance criteria
Change Management Process defined
Customer-clients regularly come to me with contracts that have:
1. no objective criteria to measure success/failure
2. all of the liability for delays, failure to perform, etc. allocated to the Customer
3. do not have sufficient input from the technical people that will actually be working on the project.
4. no contractual remedies for failure.
5. no change management process.
Point #1 is the most important. In this case, if there were objective criteria to measure success, then the breach of contract case is simple to prove. It is like engaging in the design/plan phase of development before you even sign the contract. If a customer can't figure out what objective criteria it needs, it's probably not a good time to enter a $40M contract. Take for example, the objective criteria that the EDS software will meet the minimum process per second with 150 active users. Easy, does it do? If not, see points 2 and 4.
Point #2 is often overlooked. Customers regularly sign contracts that permit a vendor to deliver something non- conforming on the delivery date and not be in breach. The contracts are also usually written so that the additional time spent correcting the non-conforming deliverables are paid by the Customer. These are usually sneakily inserted under the "right to cure" a breach provision. At some point, the vendor (not the customer) should be paying.
Point #3 is necessary in order to establish point #1 and point #2. Management has this idea: oh we need ___ system. Let's find a vendor of ___ system. However, it is the technical people that need to set the objective criteria and then be able to test that it was met.
Point #4 is the stick with which you beat the Vendor into meeting those requirements. Every customer should be asking, "what happens if they don't deliver?" I say, "show me the money." Of course, you can customize however you see fit. Customers however don't usually ask.
Finally, point #5 is so painful its hard to write about. A lot of time and money is lost because the customer does not have a good internal change management process. In addition, the customer does not put that change management process in writing with the vendor. Any change management process should be coordinated through a project manager. The process should require 1. estimates of cost and 2. affect on time line. These should require signature of someone higher up the chain than the project manager if there is a big impact on price or time--what constitutes a "big impact" should be spelled out (e.g., more than $10,000 or more than a 1 week).

34. Contract Process Technical people must review and accept contract
Legal Review of Contract
Clear statement that delivering software that does not meet criteria is a breach and payment will not be made
As a last tidbit: technology people need to STOP SIGNING AGREEMENTS WITHOUT A REAL LEGAL REVIEW. This includes the stupid little EULAs that you click ok to. That includes the purchase of off the shelf software. That includes signing up a third party for professional services. Those words mean things. Spending $1-3K now saves a boat load on the backend.

35. Change Management Process
No specification is ever perfect
All software requires changes
Change management
Clear written description of the change
Cost for the change
Timeline for the change
Approvals by all parties
One of the most common areas for conflicts in software is the failure to clearly define a change management process.
All software will require changes as the system is developed.
No specification is ever perfect.
The change management process should define how changes to the software will be specified, approved, and costed with the impact on the timeline for delivery.

36. Health Informatics Series
Mark H. Spohr, MD
Lectures in this series:
Introduction to Health Informatics
Enterprise Architecture
Interoperability
National Health Information Systems
Patient Identifiers
Software Selection