Health Informatics Series

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

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

3. Enterprise Architecture

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

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.

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.

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

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)

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

13. Overview of Software Selection • Define functional and technical requirements • Research software vendors • Conduct vendor evaluations • Plan for the implementation of the selected software

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?

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")

18. 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

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 • 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

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

25. How and Who? • Who should evaluate software? • 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

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

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: • 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

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

34. Contract Process • Technical people must review and accept contract • Legal Review of Contract

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

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