HealthManagement, Volume 1 / Issue 2 2005

Author

Udo Poth

IT Director of the Isar Hospital at the

Technical University of Munich, Munich, Germany

E-mail: [email protected]


Strategy for the Integration of PDMS (Patient Data Management Systems)

The efficiency of clinical processes depends to a significant degree on the information systems supporting them. All important, patient-related information should be available to clinicians at the earliest possible time, including, of course, during the daily routine.

 

In the Isar Hospital (University Hospital on the Right Bank of the River Isar) at the Technical University of Munich, anaesthesia and intensive care medicine receive only minimal support through appropriate, integrative information processing procedures. Stand-alone systems and handwritten documents are widespread, which means that certain information either becomes redundant or is not recorded in full.

 

The introduction of a PDMS (PatientData Management System) in the intensivecare wards of the Isar Hospital willdeliver a system for recording, presentingand disseminating information, whichwill provide a range of different quantitativeand qualitative supports for the treatmentprocess.

 

The overriding objective of the PDMS is to increase efficiency in clinical services by providing:

_ comprehensive medical information in parallel with the clinical process;

_ consistent process-oriented support for work processes;

_ the rapid transfer of recent research findings into the clinical diagnostics process; and

_ a homogenous IT structure.

 

The existing homogenous IT systems environment for the MRI system will form the basis for the technical and functional integration of the system. However, this raises an important question, namely, how will the PDMS be integrated into the existing IT systems environment, particularly given the substantial technological and architectural differences between these systems? Should the hospital opt for the traditional approach of HL7, communication servers and stand-alone screen surfaces or should the systems be treated as components of the hospital information system, with real surface integration, and XML/XSL technology for data communications?

 

Integration of Partial Processes

Adapting the current IT systems used in MRI to the daily changes arising from legislation and, to a greater degree, continuous improvements in individual processes would be a relatively expensive undertaking.

 

The hospital’s entire order-entry and result-reporting procedures are performed electronically on a clinical system used for laboratory, microbiology, imaging and so forth. The encryption of diagnosis and procedures is confined to the IT system used. Clearly, therefore, this IT structure has important consequences for the PDMS integration project.

 

Service-oriented architectures possess the theoretical attraction of being able to simplify the IT-based problems arising from the integration of diverse satellite systems within a heterogeneous systems environment and, in so doing, reduce the outlay on development and maintenance.

 

Unfortunately, the project to develop a service-oriented total system is not brought to a conclusion with the selection and purchase of a suitable product for facilitating the possible assignment of individual functions between the hospital information system and the PDMS. Based on principles involved in the Service Oriented Architecture (SOA) paradigm, this requires the “encapsulation” of applications.

 

Problems: Fragmentation of the Overall System, Duplication of Functions and Data, PACS Connection

In trying to split the overall system into disparate functions, it becomes clear that assigning these individual functions is not a clear-cut procedure. There is an area of cross-sectoral functionality in which both systems compete directly with each other (see table: Allocation of Functions).

 

This interface is currently the subject of a detailed analysis in the MRI for the purpose of ensuring the various functions can be assigned to the most suitable system. The redundancy of functions, taking into consideration the responsibility for processes and their outcomes, as well as the responsibility in terms of the electronic patient file, should be avoided, where possible. To maintain data integrity the database schema of the participating systems must be modular and adaptable to change.

 

Another focus of the project involves addressing the question: to what extent does it make sense, taking into account the availability of hardware and software, to have deliberate duplication of functions and data in a PDMS or hospital information system?

 

This question is particularly relevant in the context of:

a) The laboratory connection in the PDMS.

b) Visualisation of the intensive care curve.

c) Calculation of scores.

d) Information for infusion therapy. In the leading HIS, it is relevant in the context of:

a) The use of the existing laboratory interface.

b) The use of the takeover function in the discharge letter.

c) The cumulative findings of the laboratory.

 

A similar problem arises in respect to the PACS connection. In this context, it is necessary to integrate a viewer interface, with the requisite access algorithms, in the PDMS. However, existing and available functionalities must also be integrated. These include, for example, the orderentry functionality and all relevant secondary management processes.

 

Does Service Orientation Make Economic Sense?

This global overview demonstrates that even a simplified analysis of the diverse functionalities will throw up a complex picture. If the individual functions are transformed into a workflow scenario that features the diverse partial processes in intensive care medicine, a question arises as to whether service orientation can still be considered a sensible approach from an architecture and economic point of view.

 

The current hospital information system and the standard PDMS do not meet the requirements of a service-oriented architecture. One option for overcoming this problem is to use “wrapped services”. This involves implementing the individual partial processes as reusable, independent and loosely connected platforms.

 

In view of the different implementation phases required for the full system, the MRI is still at the design stage in terms of the encapsulation of the various processes, for example, master file data, case data and movement data services, basic medical documentation, diagnosis, procedures, services and information on additional patient charges, etc. For this reason, a decision has still not been taken on the type of integration to be applied. While the option of using conventional data sharing to enable integration to take place with the assistance of a suitable web service may not correspond to “pure service- oriented architecture“ theory, nevertheless, it is our view that this is a feasible approach, particularly given the possibility to integrate systems which will not support service-oriented architecture in the immediate future.

 
Allocation of Functions

Conclusion

In view of the problematic complexity of integrating the medical subsystem within the existing hospital information system in the MRI department, it was and is necessary to pursue an application strategy based on monolithic architecture, in other words, the focus of the strategy was and is to produce a completely stable application. The new tools open up opportunities to pursue a more flexible integration strategy and may offer a vision for dynamic use in future. The IT department of the Isar Hospital intends to meet this challenge head on. As none of the PDMS software on the market supports serviceoriented application architecture, the department, in co-operation with a PDMS provider, is seeking a project solution which may, for the first time ever, deliver a product for release on the market. Only then will it possible to determine whether it really is possible to realise a service-oriented application system.

«« Healthcare IT Providers Need To Do More To Solicit User Feedback