Imagine the following scenario: A physician logs onto his computer, selects a particular patient, and all the appropriate information comes up onscreen: laboratory results, medications, diagnostic reports, even images. Several vendors have made attempts
Imagine the following scenario: A physician logs onto his computer, selects a particular patient, and all the appropriate information comes up onscreen: laboratory results, medications, diagnostic reports, even images. Several vendors have made attempts to implement an electronic medical record system that allows one-click access to the complete record, with limited success. Based on activity at several recent tradeshows, however, it looks as though EMRs might actually become a reality in the next couple of years.
Generally speaking, there are three different approaches to implementing an EMR. First, a single vendor could present all applications as a single, integrated entity and provide a single view to the user. This could be on one screen, with particular information in particular places or with sub-windows to which a user might be able to zoom in or scroll for more information.
There is also the single-vendor semiproprietary approach in which one vendor provides access to several applications while running them in totally separate windows on a single desktop. This approach is considered semiproprietary because the applications typically communicate with one another via some vendor-specific protocol.
The disadvantage of both these approaches is that a potential user relies on a single vendor to provide the necessary multiapplication functionality. But how to display information from multivendor systems when they are integrated on a single desktop? It is very likely that an application from vendor A dealing with laboratory results will not be able to communicate with an application from vendor B dealing with diagnostic reports. Thus if a user has three windows on his or her desktop and wants to display information about Mrs. Johnson in all three windows, three separate selections and/or searches (one in each application) for Mrs. Johnson are required. Even worse, if each window displays data for different patients, it is very easy to get confused and mix up the information.
Fortunately, the HL7 committee recently added a specification called CCOW (clinical context object working group) that enables different applications to exchange certain information among themselves, which in turn allows context changes to occur. Say a user has three windows open on the desktop and selects next patient in window 1 to display the lab results of the next patient; the system can now communicate this change in context with the other applications so they can make the transition as well.
In essence, CCOW allows a user to pick the best of breed for each application among the various applications vendors. The exchange protocol is defined as part of the HL7 standard and also typically requires a context manager to keep track of the context and its changes. This part of the standard is relatively simple. Even so, as with many standards, it will become widely implemented only if more users become educated about its importance and demand support from vendors.
Comments/questions: Herman Oosterwijk at firstname.lastname@example.org