Early hospital information systems (HIS) such as HELP (Health Evaluation through Logical Processes) or RMRS (Regenstrief Medical Record System) were designed as monolithic mainframe applications which supported many departments inside a hospital. Those systems were successful from a clinical perspective, but inflexible regarding hardware and update of department specific components. The following generation of HIS relied upon integration of "best-of-breed" department applications into a large information system. The idea of a single vendor HIS was abandoned. Today a HIS is rather a framework of several applications supplying the needed functionality [1]. (e.g. Diogene2 and several US-university HIS). But the integration of subsystems in a HIS remains difficult despite HL7 and other communication standards [2,3]. At Mulnster University Hospital (UKM) we took a different approach. We installed a commercial HIS replacing specialised department applications. In fact we are returning to a single vendor HIS. This approach requires a high degree of flexibility of the HIS which we tested replacing two running specialised department applications (endoscopy and cranio-maxillofacial surgery). The endoscopy system was designed in conjunction with the vendor. This module is integrated into the order entry and result reporting communication and integrates documentation of accounting data. It has by now reached product status. Acceptance is high in both the medical and surgical endoscopy units due to integrated structured result reporting and integrated photo documentation. The application for cranio-maxillofacial surgery was developed by UKM staff alone, replacing the old system in December 2000. Today it is used for all cranio-maxillofacial surgery inpatients. The application supports integrated diagnosis classification and graphical display of the dental status. What do we require from a commercial HIS to achieve such success ? I. The HIS must permit flexible design of new applications. In our case the HIS is based upon forms that can be designed freely and adapted as needed. An endoscopy application e.g. presents to the user in shape of a request form, a scheduling form and a result report form which can be visualised and printed. 2. The HIS must be able to support clinical workflows. For endoscopy a workflow was defined consisting of requests, patient scheduling, examination and reporting. A further workflow for the optional pathology request may be added. 3. The HIS must support transparent integration of applications with accounting data, materials supply etc.. E.g. when writing an endoscopy report appropriate accounting and DRG classification data is generated in the background. In …