CADSE/FIU Team: Vidya Bhat Steve Jimenez Gordon Osborne Jinny Uppal                              Steve Luis

BHSSF Team: Kent Wreder Eric Butler Edmundo Hernandez Eric Navarro

The healthcare domain is a vast and complicated field. It is now at a critical point where high standards of patient care must be maintained, in addition to retaining positive cash flows. Hospitals are increasingly becoming aware of the advances in the field of information technology and use varied devices, instruments and systems that collect and maintain patient information and data. These devices, instruments, systems etc. are not only vendor specific but they are also geographically distributed. Transferring the patient information automatically between care sites will speed delivery, reduce duplicate testing and prescribing. The study of clinical information collected from large population of patients across distributed care-sites will help in analyzing the relationship between investments in health care resources and the actual health outcome. This is very important from the business perspective. Automatic reminders will reduce errors, improve productivity and benefit patient care. All this would require interaction between the distributed components. These distributed components, along with the people, rules and procedures, communication and support facilities form the 'Computerized Patient Record' (CPR) system.

The HealthCare industry is characterized by an abundance of standards addressing practically every aspect of HC functionality. However, most of these standards are message based, they were meant for systems that communicated via explicit messages. However, this approach does not allow systems implementing these standards to be flexible, extensible. Also different interpretations of the same message based standard have given rise to incompatible systems even though they use the same standard.

The approach we chose is to look at Health Care as a large complex system with the following typical requirements:

• Distributed:
  A large organization, health care or otherwise, typically has several divisions/sites/branches. They are typically distributed over a geographically large area and might still need to interact with each other. Moreover, information is typically spread out over several departments within the same division. Hence, any system built for an organization of this type is inherently distributed and must as such distributed storage, access and manipulation of information.
  
  
• Interoperable:
  A large system typically grows incrementally. (Relatively) small pieces of individual components are built one or a few at a time. These subsystems/components are also typically built by different vendors. Therefore compatibility between different components from different vendors is often a problem. An ideal solution should be provide the means to build a system so that communication between subsystems is smooth and produces required and results in a consistent manner.
  
  
• Flexible:
  As mentioned before the incremental growth of a system also requires that subsystems be flexible, that is building additional functionality at a later time should be cost effective. Extension of functionality should be as fuss-free as possible.
  
  
• Legacy Systems Compatible:
  Many large system will already have major investments in legacy systems, it is important that the proposed system be (or make possible) backward compatible with existing systems. This allows an initial co-existence between the two (possibly different) technologies (which justifies the previous leverages) and eventual graceful withdrawal of legacy systems if so desired.
  
  
• Integration:
  Even though the proposed system may be composed of several largely independent subsystems, integration should be well defined and seamless. There should not be any information redundancy (even if there is, it should be finely controlled and not due to over-sight in design). The communication between subsystems should be well defined, well documented and standard.
  
  
• Implementation across a wide variety of platforms:
  A large organization makes investments in a large number of platforms over its lifetime. Many of these platforms can be expected to be heterogeneous. The proposed system should provide a method for cross platform communication.

CORBAmed, BHS and CADSE:
CORBAmed is the healthcare Domain Task Force (DTF) of the Object Management Group (OMG) dedicated to improve the quality of care and reduce costs by the use of CORBA technologies in the heterogeneous and evolving healthcare environment. It has over fifty members representing vendors, healthcare providers, payers and end users. Baptist Health Systems of South Florida (BHS) is one such member of CORBAmed.

BHS had adopted the CPR approach as defined and developed by OMG's CORBAmed. The near-term objective of BHS is to solidify their CPR architectural approach by growing it into an, open and standardized, OMA-based CPR Architecture via the OMG standardization process and CORBAmed. We are assisting BHS to reach their objective.

We are using an architecture-centered approach to address the complex and difficult problems in distributed healthcare system design, integration, and migration from legacy systems based on standard-based distributed object technology. We justify our approach in the following lines:

Why Architecture-Centric?
It has been proved time and again, that systems with a good architecture (and with well documented specifications) can withstand the vagaries of extension, modifications, technology changes better than systems without one. An architecture-driven approach will help us identify components in the system and their interdependencies. So far we have identified and begun work on two of these components, Order Management and Encounter Management. We elaborate further on these two tightly integrated components in the following pages.

Why OO?
With proper abstraction at the analysis and design phase, a system may be built so that it is extensible, flexible and manageable, even when huge. In other words, such a system will have all the benefits of OOtechnology, most notable of which is reuse. We use OO concepts like abstraction, encapsulation, reuse, polymorphism to achieve some of the above stated goals. Abstraction allows easy extension/modification as the system evolves. Encapsulation hides implementation (and/or platform) details and helps focus on behavior. Reuse saves resources by allowing one component or service to be used again and again. Polymorphism allows us to messages to invoke different (implementation) behavior, thus allowing different objects to support the same interface.

Why Standard Based?
As for the existing solutions, none meet all the above requirements. Most systems from vendors are built independent of the other existing systems. Due to the sheer number of vendors, and in the absence of a universal standard or interoperability language, it is, at best, difficult to build functionality that lets one system talk to all others. This only serves to make every system unvialbly bulky. We propose the adoption of a standard based technology (ex. CORBA) to build standard APIs and a standard interoperability language for systems with requirements such as above. Such a system will have the property that its components can, with proper interfaces in place, communicate with each other in a standard way.

Overview
"Encounter" is one of the most used but ill-defined concept in any discussion of the CPR. Nevertheless, there is some agreement of what an encounter does for the CPR and the health care system as a whole. An encounter begins, what may be described as, a period of interaction between the Patient and the HCP during which the patient is under the care of the HCP. During this process, a lot of information about the patient and the treatment is directly or indirectly generated. This information directly or indirectly helps other components of a healthcare system perform their tasks. Information, like orders, is taken care of under the category of Order management. Other information, like the patient guarantor helps determine who is going to pay for the treatment (Billing system). The relationships between the patient and care providers (Physician, Physician group) helps the Security component determine access restrictions. Encounters may be considered as the starting point of quality care delivery.

Overview
Order management is an important part of a clinical system. Orders are 'instructions' written for a particular patient on what should be done to improve their health and care. In other words, every test or procedure performed on the patient has to be initiated by an order from a physician. For example, "Perform a CT scan" is an order. Thus orders play a central role in every clinical encounter. Every clinical encounter consists of registration and admission before the patient enters the clinical environment. Once this is done, the patient then goes through a number of tests or procedures, each one initiated by an order from a physician. These orders could come from different sources and have to be routed to different recipients, i.e. the different departments. All the orders placed should be maintained in some form of data store and be easily accessible. The management of these and other related functions encompasses Order Management.