Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
  • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
  • G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
  • G06F3/0481—Interaction techniques based on graphical user interfaces [GUI] based on specific properties of the displayed interaction object or a metaphor-based environment, e.g. interaction with desktop elements like windows or icons, or assisted by a cursor's changing behaviour or appearance
• • G—PHYSICS
  • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
  • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
  • G16H30/00—ICT specially adapted for the handling or processing of medical images
  • G16H30/20—ICT specially adapted for the handling or processing of medical images for handling medical images, e.g. DICOM, HL7 or PACS
• • G—PHYSICS
  • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
  • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
  • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
  • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
  • G16H40/63—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for local operation

Definitions

• the present invention is directed to a method and system for coordinating multiple software components to communicate and share a portion of a computer monitor or display.
• a windows manager Numerous program display control systems have been used to coordinate the display of some number of programs on a single (virtual or real) display/monitor, h the X Windows environment, such a control system is called a windows manager.
• windows managers include: FVWM, FVWM95, TWM/VTWM, MWM, CTWM, OLWM/OLVWM, wm2/wmx, AfterStep, AmiWM, Enlightenment, WindowMaker, SCWM, IceWM, Sawfish, and Blackbox.
• certain windowing parameters e.g., windows locations and colors
• libraries of various re-usable components have been built to standardize the look and feel of various components within a graphical user interface.
• Such libraries include OpenLook and Motif and implement "widgets" having a variety of functions (e.g., buttons and menus).
• the present invention is directed to a method and system for displaying synchronized data across plural independently developed components, h one embodiment of the present invention, the access to the data is read-only; however, in an alternate embodiment, at least a portion of the data is writeable by one of the components.
• This and other objects of the present invention are addressed by providing a series of components that can be instantiated with a series of run-time display parameters.
• at least one component can either (1) signal other components of a change in data of common interest or (2) kill the other components and restart them with new run-time parameters such that the display areas of the components form a single consistent display.
• Figure 1 is a block diagram of a network of computers sharing a common information storage system that is accessed via information integration tools and/or interfaces such that domain-specific interfaces can be developed more rapidly and consistently;
• Figure 2 is a component diagram of exemplary applet-based implementation techniques for implementing the displays of Figure 1;
• Figure 3 is an exemplary user interface created for an exemplary medical application in which patient textual and graphic information is coordinated between the several components;
• Figure 4 is a schematic illustration of a computer system for use as any one of the user displays of Figure 1;
• Figures 5A and 5B are an exemplary patient description grammar representing relationships between various client information;
• Figure 6 is an entity-relationship diagram representing relationships between various layout components within the system;
• Figure 1 A is a schematic illustration of a network of computers 100a, 100b, and 100c that share a common information storage system 210 that is accessed via information integration tools and/or application programming interfaces (APIs) 200.
• Domain-specific user interfaces can be developed using the APIs 200.
• the exemplary DSUIs of computers 100a, 100b, and 100c are (a) an orthopedics display, (b) an intensive care unit (ICU) display, and (c) an internal medicine display, respectively.
• ICU intensive care unit
• Other DSUIs are also possible, in both the medical domain as well as other domains, where the displays of multiple components need to be kept in synchronization, either (1) in their independent windows or (2) within the bounds of a single integrated window.
• data is generated by many sources and stored within the information storage system 210 in a variety of formats.
• radiological data maybe stored in a first database as images and other patient information (e.g., EKG traces or pathological results) information may stored in a second database as at least one of images and text.
• Demographic information may be stored in the same or a different database and is associated with the other patient information.
• read and write access to the data of the information storage system 210 is preferable for at least one component.
• Data preferably is also communicated in a variety of formats (e.g., DICOM, HL7), wherein representations facilitating use by the components directly are the most preferable.
• XML extensible Markup Language
• XML provides a simple and robust extendible standard for data representation and exchange. Since XML file are distributed with their own descriptions, XML creates an integrated information object. Thus, XML is (1) structured, (2) extensible and (3) provides validation. XML provides a structure to store and identify information (e.g., patient information in a medical context or suspect/criminal information in a criminal context). The information is structured hierarchically much like objects within the software design. The XML structure can be extended as new information becomes available. XML provides mechanisms to ensure data validity and can be searched directly using query language tools such as XMLSQL.
• Figure IB is a data flow model that illustrates the information flow to people or agents (e.g., using a Web browser or other GUI interface). That model includes several high-level steps (each which may be implemented with additional sub-steps or optional steps) including: (1) login, (2) object selection (e.g., patient selection), (3) information display, and (4) user preference management.
• a user's login information can be validated in any manner (e.g., NT authentication or CORBA Security Services).
• an Authentication Agent acts as a gatekeeper between users and data.
• the authentication process allows a user to access user preferences for those features of a DSUI that are customizable. More importantly, though, once authenticated, the user is given the type and scope of access that corresponds to the access rights authorized by the system. Some users may have read-only access, while others have read and write access. Moreover, not all users will be able to see all the data of a system. For example, while hospital administrators may be able to see billing information about a patient's visit, the actual radiographic or diagnostic information is not available. Thus, in one embodiment, the Authentication Agent acts as a continuous middleman during the process of selecting patient records.
• Such selection can be through a number of mechanisms (e.g., by number, by location).
• the Authentication Agent sends the patient record selection information to an Integration Agent. This selection information will be used to build patient info ⁇ nation for display and return to the user.
• a Display Agent also accesses that customization infomiation to properly format the results to be displayed.
• users of a standard interface may rearrange that interface in order to suit the user's preference.
• One such rearrangement includes the internationalization of the interface to accommodate languages read right-to-left instead of left-to-right.
• Figure IC further illustrates how data is combined from several locations to create the finally rendered layout with the requested data.
• the Integration Agent accesses infomiation from at least one source to build a patient description data block (preferably using XML).
• the interfaces for accessing each data source in its own native standard may be implemented as separate modules or within a single module, but preferably such implementation choices are hidden behind a database abstraction that also hides a physical location of the data.
• this agent utilizes known horizontal component services (e.g., Patient Identification Services provided by CORBAMed).
• a Repository or other centralized data store including either or both of database- and file-based systems) is utilized.
• the Display Agent accesses a local store of Layout structures (e.g., in an XML- format). These structures are developed by the layout editor (see Figure 11) and stored in a portion of the database that co ⁇ esponds to display constraints.
• the data and layout are combined (i.e., rendered) by the Rendering component.
• This process combines the retrieved Patient information with the layout info ⁇ nation.
• the Rendering component may also utilize context information about the info ⁇ nation to be displayed (e.g., a patient's records) before forwarding the complete report to the user.
• the single integrated window is used as a component-based application within a web-based architecture.
• the component architecture allows system developers to create reusable, portable software components that are designed for a specific purpose. Preferably, those components are small, easy to understand and maintain, and fulfill a narrow function within a larger application.
• the applications developer can then have a library of common components that can be used to build up applications rapidly. By keeping the functionality of components narrow, individual components may be used (or reused) by many applications. The resulting componentware can be developed more rapidly and can accommodate portability.
• Java virtual machines and bytecodes increases portability for component-based software systems in an environment of multiple operating systems and diverse development languages.
• higher level components manage the presentation and integration of the lower-level components.
• Cross platform portability is enhanced by a variety of complementary technologies which include Java, Enterprise Java Beans (EJB) and CORBA.
• object models e.g., DCOM
• CORBA provides mechanisms to distribute components among disparate systems, addition it provides services (e.g., security, naming, transaction processing) to further insulate applications from the details of components' implementation.
• EJB goes one step further than CORBA by providing a container that acts as a Web Operating System. The container maintains the details of an implementation, providing an additional layer of abstraction for applications.
• Non-applet based technologies are also possible, as described in greater detail below with reference to Figures 13-17.
• One such DSUI is the pulmonologist interface illustrated in Figure 3. That DSUI provides a variety of display controls, including six tabs 250, six panels 260, and an information status bar 270. Each of the six tabs 250 co ⁇ esponds to a page selection (much like selecting tabbed index cards from a box). Each of the six panels 260 is kept in synchronization with the infonnation contained in the status bar 270, and vice versa.
• the user of the pulmonologist interface changes to a different user using one display control (e.g., by selecting a new visit from a visit list (e.g., implemented as any one of a textual list, a drop-down box, a scrolling list and a set of radio buttons)), all the remaining display controls are controlled to change accordingly (e.g., using messaging as described below).
• a visit list e.g., implemented as any one of a textual list, a drop-down box, a scrolling list and a set of radio buttons
• FIG. 4 is a schematic illustration of a computer system for providing coordinated image and data display.
• a computer 100 implements the method of the present invention, wherein the computer housing 102 houses a motherboard 104 which contains a CPU 106, memory 108 (e.g., DRAM, ROM, EPROM, EEPROM, SRAM, SDRAM, and Flash RAM), and other optional special purpose logic devices (e.g., ASICs) or configurable logic devices (e.g., GAL and reprogrammable FPGA).
• the computer 100 also includes plural input devices, (e.g., a keyboard 122 and mouse 124), and a display card 110 for controlling monitor 120.
• the computer system 100 further includes a floppy disk drive 114; other removable media devices (e.g., compact disc 119, tape, and removable magneto-optical media (not shown)); and a hard disk 112, or other fixed, high density media drives, connected using an appropriate device bus (e.g., a SCSI bus, an Enhanced IDE bus, or a Ultra DMA bus).
• the computer 100 may additionally include a compact disc reader 118, a compact disc reader/writer unit (not shown) or a compact disc jukebox (not shown).
• compact disc 119 is shown in a CD caddy, the compact disc 119 can be inserted directly into CD-ROM drives which do not require caddies.
• a printer (not shown) also provides printed listings of reports from the coordinated displays.
• the system includes at least one computer readable medium.
• Examples of computer readable media are compact discs 119, hard disks 112, floppy disks, tape, magneto-optical disks, PROMs (EPROM, EEPROM, Flash EPROM), DRAM, SRAM, SDRAM, etc.
• the present invention includes software for controlling both the hardware of the computer 100 and for enabling the computer 100 to interact with a human user.
• Such software may include, but is not limited to, device drivers, operating systems and user applications, such as development tools.
• Such computer readable media further includes the computer program product of the present invention for providing coordinated control of display controls or components.
• the computer code devices of the present invention can be any interpreted or executable code mechanism, including but not limited to scripts (including CGI scripts), interpreters, dynamic link libraries, Java classes, Java beans, Active X controls, CCOW-compliant controls and complete executable programs.
• the computer code devices can be downloaded dynamically from a computer network adapter acting as an equivalent to a computer readable medium.
• the number of components that are implemented by a single computer code device, or the number of computer code devices that are required to make up a single component can vary from component-to-component.
• components can be divided by functionality.
• An exemplary division of labor includes (1) components to access and store information in existing hospital systems, (2) components to configure information using XML meta-structures, and (3) components to handle data presentations (e.g., graphing components, image components for displaying images in a variety of formats (e.g., TIFF, GIF, JPEG, bitmap)).
• data presentations e.g., graphing components, image components for displaying images in a variety of formats (e.g., TIFF, GIF, JPEG, bitmap)).
• Such a set of components also allows security to be addressed separately.
• At least two general approaches are possible for Security.
• the security features implemented within components themselves can be used. Basically, this means that security is not an issue of the overall system, but rather of the components utilized by the system. As the security capabilities of components evolve, the system automatically incorporate these components.
• the second approach utilizes a "security component" or uses one of the horizontal services provided by CORBA.
• a security component can take responsibility for validating user access and can mediate communications by components to ensure that security policies are enforced.
• This approach provides a greater level of security but requires increased cooperation from other components. Use of such a security component as well as CORBA services thus needs to be standardized, thereby reducing the ability to utilize 3rd party components.
• a hierarchical component organization also localizes specialized access and display programming. When no access standard is in place, access to the proprietary information can be isolated in a manageable location.
• XML provides mechanisms (e.g., CSS, XSLT, XSL) to render info ⁇ nation for display. Those mechanisms allow the same information to be associated with different display characteristics depending on the user and the task. For example, a patient's age may place him/her in a low risk group for one characteristic or disease but in a high risk group for another characteristic or disease.
• components can be configured with an additional level of indirection.
• the name of the tag i.e., the programming variable
• Components within the system of the present invention are assumed to be "well- behaved.” Accordingly, such components are assumed to enforce data integrity (e.g., concu ⁇ ency control), utilize authentication (e.g., user-level authentication for patient and exam information), and co-operate with dissimilar component types (CORBA, EJB and DCOM). For components that are not considered to be well behaved or are found to not enforce assumptions of the system, those components are isolated from the other components to prevent data corruption, etc.
• data integrity e.g., concu ⁇ ency control
• authentication e.g., user-level authentication for patient and exam information
• CORBA, EJB and DCOM co-operate with dissimilar component types
• domain-specific information e.g., patient information
• layout information e.g., layout information
• context information e.g., context information
• FIGs 5 A and 5B An exemplary structure for patient description language is illustrated in Figures 5 A and 5B. (By using XML and DOM to hold the patient information, named tags can be associated with components).
• the tabs 250 represent six different information views: (1) Pulmonologist: a view that provides summary information, (2) Drugs: a listing of the patient's medications, (3) Bronchoscopy: views of visible light images of the bronchus, (4) CR: views of CR images, (5) CT: views of CT images, and (6) ECG: views of scanned ECG images.
• each of those tabs is at least partially configurable (e.g., configuring the name tab, the order of the views, and the contents of the view).
• the context of a DSUI provides a consistent view of the information among all of the tabbed pages as the end-user interacts with the information, hi a medical environment, a context may include variables such as Active Visit', 'Active CRStudy', 'Active Series', etc.
• a component can be configured to track (or remain consistent with) a Context Variable. Utilizing the example of Figure 3, information related to a visit on 1/11/99 is displayed.
• the first view in the layout, the Pulmonologist view includes the visit list component, the visit summary component, the study list component and two image display components. Each of those components displays information related to the 1/11/99 visit.
• there is a demographic component that displays information in a status bar that is related to the patient. That component contains information that does not change with the visit. Additional views (not shown), for example the CR view, may also contain information relevant to the 1/11/99 visit.
• the visit list component of the Pulmonologist view changes so that the components that relate to the visit also change (e.g., the visit summary component provides information about the 10/3/99 visit, the study list component displays a list of studies for the 10/3/99 visit, the images change to coincide with the study being displayed, and other views that relate to the active visit change).
• views on other pages may be updated as well.
• the CR view (4th tab) remains consistent with the Pulmonologist view (first tab) which contains information relevant to the 10/3/99 visit after the change.
• some display elements do not change info ⁇ nation (e.g., demographic information may not change (and should not change in the illustrated example) between visits for the same person).
• a component can be configured to track a Context Variable or to remain set to a static view. For example, the CR Study viewer above tracks the active visit. The same component can be configured to display only the most recent CR Study. Therefore, when the user changes the active visit, the most recent CR study will always be displayed.
• the structure of the Context Variables is also stored in a hierarchical structure (e.g., a structure similar to the Patient description language).
• the Context Structure contains a variable for each branch in the patient-tree structure. By doing this, the active portion of the patient information can be tracked.
• a component includes three types of information stored in the form of properties: View, Status and Implementation properties.
• this component model is applicable to either (1) an implementation that stores data independently from the components (as described above) or (2) an implementation that stores data with the components (e.g., by storing the configuration of a Java Bean within the Bean itself).
• exemplary properties include: (1) the minimum height and width, MinHeight and MinWidth, respectively, in which the component should be displayed and (2) the optimal background color, BGColor.
• the StatusProperties of components describe how the component should behave in the context of the application.
• Exemplary properties refer to initial setting specifying how the component will be invoked.
• Other status properties describe how the component behaves as the user works. That behavior includes changing the state of the overall system, e.g., by selecting a new active visit from a VisitList Component.
• the Active property is a boolean expression that describes if the component should change with the active status or if it should remain at its initial settings throughout the duration of the session. A "Yes” status indicates that the component should change to follow the settings of other components. A “No” status indicates that the component should remain at its initial settings.
• the TagToFollow property indicates the lowest level tag in the status hierarchy that should be used to modify the component's state. For example, the CRImage Viewer tracks the status tag CRStudy. Whenever the user selects a different CRStudy (i.e., the status of CRStudy changes) the CRImage Viewer will change to track the value of CRStudy.
• the Implementation property describes the actual implementation of the component. It allows the system to create a wrapper to invoke the actual run-time component with the proper parameters.
• the BuilderClass property describes the type of the component. As described above, numerous types (e.g., JavaClasses) of implementation technologies can be used according to the present invention.
• the Path property describes the location of the software to be executed.
• the Parameter property provides any additional start-up parameters that are not specified in StatusProperties.InitialSettings variables (e.g., user identification and passwords).
• the properties are described using an XML-based grammar.
• the view properties and status properties of Figure 6 are specified with exemplary values for a Study List Component that displays information about CR and Derm Studies.
• the minimum height and width of the components are specified as 180 and 320 pixels, respectively.
• the background color is specified as black.
• Visit and study both utilize the most recent values (i.e., the most recent visit and study, respectively).
• the component is active so that it tracks changes in other components by following the visit variable.
• the highest level of the description language contains identifying information about the patient. It allows demographics and visit info ⁇ nation to be expandable therefrom.
• the patient description language is essentially taken from the DICOM view of the 'real world'. It connects patient information with visits. Visits are used to group care episodes into meaningful chunks, especially in a hospital setting, h an outpatient or clinic setting a more useful grouping might be Diagnostic Code or some other piece of information that groups patient information into episodes of care. For example, it would group information related to a broken leg together and logically separate that information from information about a heart condition.
• This information could also be stored in the format of another standard - like the HL7 PJM model. However, this information does not need to be structured in the same format as it is structured in the database as long as its structure supports the task.
• Context Variables within the application are maintained for points where the patient structure tree branches. If a branch of the tree is maintained for each type of study (e.g., CRStudy, DermStudy, CTStudy), context information can be maintained for these variables since it is known which study is active at any given time. Visit variables contain information about visits (e.g., what group studies a visit co ⁇ esponds to and what medications were utilized or prescribed). [0064] CRStudy contains only CR Modality information. It contains some general information about the study and one or more Series elements. The actual images are contained at the Series level.
• ECGStudy element parallels that of the CRStudy. Again, the highest level contains general information about the study, and there are one or more Series elements. The images are contained at the Series level.
• components that are modality specific are separated from those which are modality independent.
• Modality specific components will generally be those which control physical hardware processes unique to a given modality.
• these components will control transducers or digital I/O interfaces that are necessary for controlling the generation of radiation, mechanical operation or other hardware activities.
• these components should be designed to provide a common interface to the next layer of abstraction that is independent of any modality.
• Modality independent software may include DICOM communications and formatting software components, file management components, systems management and maintenance tools, DICOM modality worklist components, DICOM MPPS components, etc (see Figure 8).
• Such an implementation allows for more general purpose definition of DSUIs through "layouts" for user-interfaces for modalities that are customized to individual needs (e.g., hospital sites or individual medical professionals (e.g., doctors, nurses and medical administrators)).
• the design, creation and modification of custom layouts may be accomplished by end-users working with a layout editor tool.
• New layouts, or management/maintenance layout may further be downloaded using standard web communications protocols. Maintenance layouts may access specialized components that are not accessible to end-users layouts.
• a single page of a layout is described by a hierarchical structure that contains a recursive nesting of panels. This enables a layout to become a sub-layout transparently to the layout, simply by referencing the layout in a "higher level" layout. At each level the panel has display properties to help control and reference the layout. Exemplary properties are illustrated in Figure 10B.
• the Title property is an optional property that may be used to associate a name to be displayed as part of a particular layout.
• the Model property is utilized for determining whether the area assigned to the component will be sub-divided. Exemplary types of Model parameters include:
• HHALF horizontal half: The panel will be divided horizontally into two panels;
• VHALF vertical half
• HTHIRD horizontal third: The panel will be divided horizontally into three panels;
• VTHIRD vertical third: The panel will be divided vertically into three panels.
• the Location property can include Directional coordinates such as North, South, East, and West. These indicate which panels are being referenced within the properties.
• FIGS 9A-9D various panels (which may incorporate sub-panels) can be specified for various functions.
• the Full model may be used for image display.
• the Horizontal Half model may be used to display two comparison images.
• the Vertical Third model may be used to display a study list and two images.
• Layout Editor uses component information (e.g., stored in a local data source).
• the component information describing the layout is stored in an XML structure as described above. Since panels can include panels as components, the layouts can be created rather quickly.
• An exemplary grammar for describing layouts is illustrated in Figure 12. Such a grammar describes the elements of a layout and in what order the elements are to appear (including any repetitions or optional elements).
• a first alternate implementation technique includes a native windows application. The basic structure of the software would remain the same but the container would be changed from an applet to an application.
• a second alternate implementation technique includes a thin client, as shown in Figure 13. It is this alternate implementation technique that is described in greater detail below. Such a technique may utilize servlets, DHTML, CSS and COM.
• Both such implementations may be extended to allow applications, including third-party software, to share a common context (e.g., information about an active patient or visit) that can change.
• Applications written to expressly handle such sharing messages are refe ⁇ ed to hereinafter as "context-aware” applications.
• Integrated sharing is hindered by applications that were not written to expect events or communications from sources other than input devices (e.g., the keyboard and mouse).
• Such applications are refe ⁇ ed to hereinafter as “context- unaware” applications.
• sharing can be achieved by utilizing a context or display manager (CDM) that terminates the context-unaware applications and restarts them with the appropriate parameters.
• CDM context or display manager
• One messaging standard that can be used for context-aware applications is CCOW, as discussed above, and tools (e.g., from Sentillion) facilitate creation of such CCOW-based applications.
• the Sentillion development package contains:
• Context Participant A DLL that can be embedded within an application that implements most of the context participant application behaviors defined in the CCOW standard.
• Context Manager A development-only version of a Context Manager.
• Context Manager enables clinical applications to be synchronized around a common clinical context.
• the Context Manager runs as a server process and acts as the broker for CCOW messages. Herein, it is refe ⁇ ed to as the Clinical Context.
• Figure 13 illustrates a conceptual model using a thin client architecture that distributes services between a client (e.g., using a browser as a client interface) and at least one server.
• a series of HTML pages are used, including a first set of pages that interact with a server (e.g., using a Login Servlet) to validate the user and determine the patient.
• the second set of pages includes plural frames (e.g., 3 frames).
• An exemplary page generated according to the present invention was discussed above with reference to Figure 3.
• Each of the frames interacts with the server (using servlets).
• context information is kept within the client and is based on a messaging protocol (e.g., CCOW).
• the client context is maintained within a context server on the client, and the components interact directly with the client context.
• the thin-client is constructed in a two-phase initialization process.
• the first phase of the initialization builds a layout (e.g., using an HTML page) of the components to be used in the DSUI, and in the second phase, the client activates the components thereof.
• a user can interact with each of the control component (e.g., by selecting tabs from the tab bar of Figure 3). This changes the page of information that is being displayed.
• the user can also interact directly with components. These components communicate directly with the context manager or context object.
• Figure 14 illustrates the sequence diagram for the construction of the component page.
• the client interface is the only software component on the client that need be active in the initial building of the page.
• the client interface requests login information (e.g., (1) authentication code or (2) user id and password) from a user.
• the server e.g., using a login servlet
• authenticates the user and returns a patient selection list and a DisplayLayout that refers to structured display list file (e.g., an XML file) on the server).
• the user selects a patient, and the ActivePatient reference and display layout are sent to the server (e.g., a Frame Servlet).
• the server e.g., a Frame Servlet
• the server uses the ActivePatient reference to construct patient information in the patient description language.
• the server then creates page layout controls (e.g., a set of frames) that co ⁇ espond with the display layout and the ActivePatient and returns the page skeleton to the client interface.
• Page layout controls of the page skeleton include references to the servlets that will fill in the page layout control areas along with the necessary parameter information.
• three frames i.e., a selector panel frame, a component panel frame, and a demo panel frame
• the SelectorPanel Frame includes a reference to the SelectorPanel Servlet with a display layout parameter.
• the SelectorPanel Servlet sends back a control layout (labeled SelectorPanelHTML) that produces the tab bar at the top of the interface.
• the tab bar is implemented in DHTML so all visual changes to the tab bar take place on the client (e.g., the tabs changing color when the cursor moves over them).
• the component panel frame includes a reference to the ComponentPanel Servlet.
• the client interface activates the ComponentPanel Servlet reference with the ActivePatient and display layout information.
• the ComponentPanel further subdivides its display area to co ⁇ espond with a specified layout (e.g., divided in vertical or horizontal halves, or vertical or horizontal thirds).
• the ComponentPanel Servlet then inserts a fully qualified reference to the component (e.g., the ActiveX component) in each of the frames that it has created.
• This control layout (labeled ComponentPanelHTML) is returned to the client interface for display.
• the DemoPanel Frame includes a reference to the DemoPanel Servlet.
• the client interface activates the DemoPanel Servlet reference with the ActivePatient parameter.
• the DemoPanel Servlet creates a patient demographic display from the patient description language structure.
• the three servlets process independently and produce display pages (e.g., HTML) as an output. It is very simple to change the look of thin- client by changing the display pages that are output. For example, the tab panel can be moved to the bottom, font and background colors can be easily changed, and frame and font sizes can be modified by simply changing the style sheet.
• display pages e.g., HTML
• Figure 15 illustrates a sequence diagram that shows the second part of the activation phase.
• the client interface activates the components with the parameters that are specified in their page layout references.
• the context-aware components then join the common context. This enables components to receive later context update messages and request the current context.
• the context is returned as a series of name value pairs.
• Figures 16 and 17 illustrate the sequence of steps used in the changes and interactions, respectively.
• SelectorPanelFrame create the initial display for the tab bar in the CIMR display, h such an embodiment, the frame contains dynamic control (e.g., DHTML) and all cursor movement and display update occurs within the display through scripts (e.g., through JavaScript-based DHTML), h one embodiment, each of the tabs is a "submit button" that, when selected by the user, sends a message to a Servlet.
• SelectorPanel Servlet determines which page of the DisplayLayout corresponds with each tab. The identification for the DisplayLayout page is inserted into the dynamic control reference that corresponds with the "submit button" related to the tab display.
• the dynamic control takes care of changes in the display (e.g., highlighting the tab when the cursor moves over it, making the selected tab appear to be displayed in the front of the other tabs) and the SelectorPanel display co ⁇ esponds directly with the ComponentPanel Servlet.
• the client interface activates the ComponentPanel Servlet reference with information that is contained within the "submit button" reference. As it did in the initialization, the control layout further subdivides its display area to correspond with the active page (e.g., divided in vertical or horizontal halves, vertical or horizontal thirds). The ComponentPanel Servlet then inserts a fully qualified reference to the component in each of the controls that it has created. This control layout is returned to the client interface for display (e.g., as an HTML page).
• the client interface activates the related components in the same manner that is described in Figure 15.
• Each of the components joins the active context and gets the active context from the Clinical Context object
• the second type of user interaction involves the user interacting directly with a component.
• the component not the user, interacts with the shared environment by sending and receiving context information from the context manager or context object, hi one embodiment, the context-changing interaction occurs completely on the client without communication with the server side.
• context-changing may occur with communication to the server (e.g., to record when components were interacted with).
• Figure 17 illustrates a sequence diagram for a successful context change using a context manager/object.
• the sequence begins when a user selects a new context variable in a component.
• the context variable is the visit.
• the context- aware component then begins a protocol to insure that only one application can change context simultaneously and that no changes are lost.
• the context-aware component sends a StartChanges message to the context manager/object. This locks out other applications from beginning a context change and gives the initiating application a blank context area to begin work.
• the application then sends a series of messages to set the new context variables followed by the EndChanges message. When the EndChanges message is received, the context manager/object is free to accept other requests for message changes.
• the context manager/object then sends a message to all other applications that are members of the context (i.e., that have joined the context) that there is a new context pending, h the exemplary embodiment of Figure 17, all applications accept the new context (although other responses are possible). If all of the applications accept the new context, the context manager/object sends a message to the initiating component indicating that all applications accepted. The initiating component sends a message to the clinical context to replace the current context with the accepted context. The clinical context sends out to all members of the context that the new context is now active. The applications then request the new context and make the required changes.
• Busy The context manager has determined that the application is still running but is unable to answer (e.g., the application is single-threaded and has a modal dialog open).
• the initiating components are provided with a succinct but informative descriptions (including names) of any applications that are busy. This information is provided by the Clinical Context on behalf of these applications, as they are unable to do so for themselves.
• the initiating application can choose to display an informational message to the user.
• the context changer utilizes a token in order to make any changes.
• the context participant that is making changes must be able to deal with busy participants.
• the application must include either code to make a decision regarding whether the context change should proceed or code to prompt the user as to whether or not to proceed with a context change.
• code to make the decision automatically may not be practical.

Landscapes

• Engineering & Computer Science (AREA)
• General Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Human Computer Interaction (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• User Interface Of Digital Computer (AREA)
• Medical Treatment And Welfare Office Work (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=25168839

Family Applications (1)

Country Status (3)

Cited By (1)

Families Citing this family (43)

Citations (7)

Family Cites Families (9)

• 2001
  • 2001-03-02 US US09/796,703 patent/US6889363B2/en not_active Expired - Lifetime
• 2002
  • 2002-03-04 JP JP2002057903A patent/JP2002358361A/ja active Pending
  • 2002-03-04 WO PCT/US2002/006572 patent/WO2002075512A1/en not_active Ceased
• 2008
  • 2008-04-16 JP JP2008107171A patent/JP4909936B2/ja not_active Expired - Lifetime

Patent Citations (7)

Also Published As

Similar Documents

Legal Events