Wikipedia: hospital information system

A hospital information system (HIS), variously also called clinical information system (CIS) is a comprehensive, integrated information system designed to manage the administrative, financial and clinical aspects of a hospital. This encompasses paper-based information processing as well as data processing machines.

As an area of medical informatics the aim of an HIS is to achieve the best possible support of patient care and administration by electronic data processing.

It can be composed of one or a few software components with specialty-specific extensions as well as of a large variety of sub-systems in medical specialties (e.g. Laboratory Information System, Radiology Information System).

CISs are sometimes separated from HISs in that the former concentrate on patient-related and clinical-state-related data (electronic patient record) whereas the latter keeps track of administrative issues.

The World Health Organization "List of Errors to Avoid" in Planing, Developing and Installing Hospital Information Systems

The World Health Organization (WHO) published a list of errors to avoid when designing, installing or supporting an Healthcare Information System / Hospital Information System / HIS:

1. Don't depend too much on one pioneering innovator, and do not leave any such innovator in charge - they will become too rigid and narrow-minded in their views, and stifle change and development.
2. Don't spend a large amount of time creating a detailed, rigid specification - it will be out of date before being designed, built, and implemented; rather, specify core principles and functionality together with a design-and-build or prototyping methodology.
3. Don't leave performance criteria, both in terms of functions provided and maximum percentage downtime to chance, but include them in the procurement contract.
4. Don't forget error correction and maintenance - write minimum standards into supply contracts, and ensure that there are sanctions, e.g., part of procurement payment held back until satisfactory functioning over a specified period; maintenance payments paid partly at the end of each period with reductions for loss of service.
5. Don't let the supplier determine needs or performance; instead, ensure that the customer remains in control.
6. Don't exploit your supplier - whilst the customer should lead, an aggrieved supplier provides a poor service and a bankrupted supplier disappears and leaves the customer stranded.
7. Don't impose "solutions" on end users and data suppliers; rather, ensure that they feel they are valued and want the system.
8. Don't automate today's paper processes - look at what new functions and methods automated Information Systems can undertake.
9. Don't specify too futuristically - there is a limit to how much people or an organization can change in one move; instead allow an evolutionary path.
10. Don't treat the organization or the specification as rigid structure, but instead allow for organizational and end-user learning, as well as technological and environmental change.
11. Don't stop evaluation at the point of installation testing - there will be ongoing organizational and personal behavioral change that must be identified and appropriate adjustments made.
12. Don't stop investing in a "successful" system - it will soon become out-of-date, and disillusionment will set in thus, to the dismay of users and paying parties, the "success" will soon evaporate.
13. Don't be complacent with a "successful" system - the very word of its success will increase usage, overload access, and degrade performance — this applies to all elements, including data networks and communications.
14. Don't confuse Education (concerned with changing professional practice and performance) with Training (about how to operate a system).
15. Don't change practice and switch on a system in one activity, but also don't computerize old practice - separate the two change processes, even though this will mean a short period of dysfunctional working, so as to ensure that the different changes are fully understood, and any problems can be traced to the correct source to facilitate rapid adjustment.
16. Don't rely on memory or suppliers - persons can forget, become ill, or leave; suppliers can go out of business or be taken over. Ensure that everything is properly documented, including performance agreements, and all systems specifications, functionalities, applications, and operational routines — the constant test must be "Could a new person take over that task tomorrow?".
17. Don't overlook the need for convincing answers on confidentiality - it will be a prime question from all health professionals before they use a system.
18. Don't think that removing names from records creates confidentiality - other factual combinations in records can effectively identify indirectly by implication or circumstance.
19. Don't assume that any types of data item are of low confidentiality - for some individuals any specific item may be very confidential because of personal circumstances, e.g., address or blood group.
20. Don't touch anything which does not run on open standards, is of a closed proprietary nature, or cannot accommodate modern recognized data and other standards - any short-term gain will be minimal compared with the cost of the dead end up which you are committing your organization.
21. Don't think that any Information System project is ever finished - if it successful, people will want more of it; if it unsuccessful, adjustments are clearly needed; and in any eventuality circumstances will change.

This list, named "A Don't List in Setting Up an Healthcare Information System", first appeared in the manual Setting up Healthcare Services Information Systems: A Guide for Requirement Analysis, Application Specification, and Procurement, edited in 1999 by PAHO (Pan American Health Organization) - a branch of the World Health Organization (WHO).