Send comments on this topic. | Back to Introduction - All Topics | Help Version 17.5.11.1
The following topics provide general information about the Health Level-Seven Context Management Architecture (CMA). They are designed to help familiarize developers with the concepts and standards created by the Clinical Context Object Workgroup (CCOW) committee within the HL7 group.
The CCOW architecture defines methods, concepts and procedures to facilitate interoperability and synchronization in clinically significant ways. The goal is to create visually integrated healthcare applications on end-user devices (i.e. personal computers that serve as clinical desktops).
More detailed technical specifications and the latest version of the “CCOW” Standard is available on line at the HL7 Bookstore (www.hl7.org).
The goal of HL7 CCOW is to provide mechanisms for developing standards that create a unified view of information held in disparate healthcare applications on clinical workstations. Creating a common context that applications can share accomplishes these goals. Examples of contexts are patient, user, clinical encounter etc. These common contexts become the context identification for a session. As a result, when a clinician signs on to an application within a group of applications connected within a CCOW environment, all of the other applications within the group simultaneously execute the sign-on. Similarly, when the clinician selects a patient, all the applications in the CCOW environment populate the patient selection. This eliminates the need to log on to multiple applications and creates a combined view of the patient information -- enabling a visually integrated user interface.
The following list describes some of the primary concepts of the CCOW Context Management Architecture.
A clinical context is state information that a user establishes and modifies while interacting with healthcare applications at the point-of-use (e.g., a clinical desktop). The context is called common because it establishes those parameters that uniformly affect the behavior or operation of multiple healthcare applications. The context needs to be managed so that the user has a way of controlling it, and applications have a way of robustly coordinating their behavior as the context changes.
The context manager coordinates applications each time there is a context change transaction. It is also maintains the authentic context data for a common context system. Implement the Leadtools.Ccow.IContextManager interface and the Leadtools.Ccow.IContextManger to create a context manager in your application.
A context participant is an application that gets or sets context data from a context manager. Participants must follow specific policies of behavior to be considered proper context management “citizens”. LEADTOOLS provides the Leadtools.Ccow.IContextParticipant interface to create context participants in your application.
A context agent is a component in the Context Management Architecture that provides services to participants. To easily create Agents create classes that inherit the Leadtools.Ccow.IContextAgent interface There are three types of agents:
A context session begins when the first application requests to join a context. This is accomplished through the Leadtools.Ccow.IContextSession. When an application creates and activates a context manager. The context session ends when the last application leaves the context. Applications can join a context by sending a request to the context manager. A single point-of-use device can host multiple context sessions. However, only one session can be active at any given time. This means that a user is able to have multiple sessions on a desktop, or different users can each have their own session on the same device.
The Context Management Architecture allows applications to establish links based on clinical subjects with a common interest. These links enable applications to cooperate and maintain synchronization when the user changes the values of one or more of the subjects of interest. The degree of synchronization is variable and depends on the needs of the applications.Use Leadtools.Ccow.Subject and Leadtools.Ccow.ContextItem.
In general, healthcare applications identify the same real world objects and concepts differently. Context annotations and context actions expand the capabilities for an application to synchronize by allowing the addition of information to define real world identities or concepts. Context annotations provide a means of representing the attributes of an identified context subject. Context actions provide a means for the end-user to perform context-sensitive interactive tasks involving multiple applications. The CCOW standard keeps these mechanisms architecturally distinct so applications are able to use a subset of the CMA's context-centered capabilities to meet specific requirements.
The Authentication Repository is an additional clinical context system component. It facilitates secure authentication of the applications that are unable to sign on a user only using a logon name. It does not authenticate users. Instead, it provides applications with a means of obtaining the authentication data. An Authentication Repository is created by creating a class that implements the Leadtools.Ccow.IAuthenticationRepository interface.
CCOW leverages existing investments. Health care providers can realize the benefits of a single sign-on, patient-focused information system without re-investing in new technologies.