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)
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
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.
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.
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.
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
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:
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.
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
Click here to see more detailed description of Encounter Management.
"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.
Click here to see more detailed description of Order Management.
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.