Design by Contract - Implications for Healthcare Computing

A contract is an agreement between two or more parties for the doing or not doing of something specified. The agreement may be formal, informal, implicit, or tacit. In fact, any situation in which there is an expectation of behavior or performance bears some similarity to a contract. There are conditions that must be satisfied - pre-conditions met or the activity cannot start and post-conditions fulfilled or the activity is not completed.

Imagine that you're going to your favorite restaurant tonight for their chef's signature dish. Assuming the most likely sequence of events, you will arrive, get seated, place your order, enjoy a great meal, and then depart. There is an implied contract between you and the chef: the chef will prepare a perfect meal, serve it on time, and provide superb service and you will exhibit good manners, pay the bill, and perhaps extol the restaurant to your friends. You probably don't make your order contingent on receiving detailed information about where and when the groceries were purchased, how many assistants there are in the kitchen, whether a microwave is used to heat something, etc.; those are things you leave to the chef. At McDonald's payment is a precondition, at Chez Henri it's a post-condition. If you arrive at the ER by ambulance, unconscious and bleeding, financial screening is not a pre-condition of treatment but if you're coming to the hospital for elective surgery, it is.

This scenario has been translated into the sphere of software development by Bertrand Meyer, the founder of Eiffel Software. "Eiffel Software is the pioneer of Design by Contract (DbC) and the Component Revolution. …DbC is a metaphor on how elements of a software system collaborate with each other, on the basis of mutual obligations and benefits," according to the company. The metaphor comes from business life, as described above. Both parties must satisfy certain obligations, such as laws and regulations, applying to all contracts.

Many aspects of healthcare delivery and business operations can be re-imagined in terms of this metaphor. The admitting department of a hospital has only a few obligations: fulfill requests to admit or transfer patients by returning a bed assignment or a reservation, respond to requests for patient location, produce the official census at the required times, and communicate effectively with housekeeping and maintenance regarding bed and room availability. The organization's side of the contract primarily involves making patient identifiers and demographics available and providing a mechanism for communicating transfer and discharge requests to admitting.

Does every staff member of the organization need access to the database of beds? Of course not, and it probably wouldn't be allowed anyway although some functions might be delegated to nursing. So - why does a simple, small function like ADT, with which only a small number of staff interact, need to be part of a giant centralized hospital information system? If your goal was to get one system that does everything then it would seem to make sense. An equally good, if not better, argument can be made for keeping sets of related functions in semi-independent modules. Doing so allows other goals to be realized more easily such as lower cost and complexity and the flexibility to upgrade modules selectively.

Design-by-contract can help to bring clarity to complex, hard-to-solve problems.