Beginnings

When Kevin Tremper was recruited as chair of the Department of Anesthesiology at the University of Michigan in 1991, he negotiated the inclusion of a clinical information system as a condition of his employment. Dr. Tremper realized that in order to manage an enterprise as complex as the surgical service for a large academic medical center he would need an information system, not only to provide data to allow better management of the enterprise but to execute the business functions required to make the surgical services profitable. At the time, there did not appear to be a computer system that would suit these purposes. Nonetheless, it was clear that essentially every business was using information systems to help them operate their businesses and it was only a matter of time before the same technology would be applied to the anesthesia care area. By 1995, a number of companies had introduced anesthesia information systems and Dr. Tremper therefore decided to proceed with choosing a vendor and implementing a system. A Request for Information document (RFI) was prepared and sent to various vendors who then came and provided demonstrations. Following this information gathering stage, a Request For Proposals (RFP) was prepared and disseminated to potential vendors.

The name MorCARE was derived because during the time that we were having vendors come and provide demonstrations of their anesthesia care record keepers the project was referred to as Michigan Operating Room Data Management System, the acronym for which was MORDMS or “Mordims”, a name that made the project sound like it was already dead; we therefore determined that we needed a better name. Since the University of Michigan has an HMO known as M-CARE, Dr. Tremper came up with the projects in operating room data management system new name, MorCARE. In 1995, Dr. Michael O’Reilly was appointed the director of the MorCARE project.

After an exhaustive review of the responses to the RFP, a company was chosen as the vendor. After attempting to implement the vendor’s system, it became apparent, for various reasons, that the relationship was not a good fit and the vendor and the University of Michigan mutually agreed that we would proceed with the project with the number two vendor. We proceeded to work with the second vendor for a period of about a year and a half and at that time, we agreed with that vendor that it was not a particularly good fit either. The problem with each vendor had to do with their system architecture, database design and configurability.