Classifications

• • 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
  • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
  • G16H50/20—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for computer-aided diagnosis, e.g. based on medical expert systems
• • 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
  • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
  • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records

Definitions

• This invention relates to networked computer systems, in particular to networked computer systems with object-oriented software for the personalized presentation and formatting of computerized patient records.
• CPR Computerized patient records
• alphanumeric data such as free text and structured reports
• non-alphanumeric data such as medical images, video streams, monitoring signals, voice dictation, and other graphics.
• CPR information for a given patient includes demographics, admission, discharge and transfer reports, laboratory results, radiology reports, images, ordered medications, operative and procedure notes, progress notes, the status of orders and procedures, and so forth.
• Application programming has also been enabled by the use of rule-based techniques.
• An example of such techniques is the representation of an organization policies and practices by business rules.
• writing, interpreting and maintaining business rules has often been difficult for the business analysts that are responsible for specifying business rules.
• business rules have been historically embedded directly in the procedural flow of application programs. This approach has the disadvantage that it is very difficult to change the rules to cope with chancing business conditions.
• Business rules have also been implemented in database procedures known as database triggers. Database triggers and stored procedures are modular and isolate the business rules from the application logic. However, they require SQL programming. It is often difficult to interpret the business logic by looking at the SQL code. Database triggers are also hard to maintain and change for adapting to changing business policies.
• an object of this invention is methods and systems for efficient and effective integrated storage, management, distribution, and presentation of all the various forms of medical data in a flexible and evolving manner by coordinated and novel use of the technologies of networked computer systems, distributed object-oriented technologies, and rules-based processing for data distribution, personalization, and presentation.
• the methods and systems of this invention are not limited to medical institutions, but can also be advantageously employed outside of the medical arena.
• Method and systems are described for personalization and formatting the presentation of CPR data depending on a user's role in a medical institution and a user's end- user devices, from personal digital assistants to powerful workstations.
• Personalized visualization of CPR information provides users with relevant information that is targeted for them and their end-user devices. For example, clinical users can use the present invention to access medical records quickly from a variety of networked end-user devices across the medical enterprise as well as at home and traveling.
• the personalization and formatting of CPR data is performed in accordance with recommendations returned from a plurality of business rules which take into account the policies and practices or an institution as well as system and device capabilities.
• these rules and other policy and business logic are centralized in the rules engine and rules modules. This is different from the conventional approach of embedding business rules as code in application programs.
• Centralizing business rules in a rules engine has benefits including allowing the medical institution to react quickly to operating and regulatory conditions. Separating business logic from application logic allows organizations to change business policies without rewriting or recompiling application code. This architecture is particularly suitable for distributed environments because it eliminates the need to upgrade client software every time there is a change in business policy. This architecture can also better support changing rules because personalization and decision support logic resides outside of the application logic. Other distributed application using complex business logic are also well suited for the methods of this invention.
• this invention utilizes a networked computer system functionally differentiated into a three-tiered architecture and linked by distributed object-oriented technology, such as the Common Object Request Broker ("CORBA") of the OMG.
• CORBA Common Object Request Broker
• the invention includes rules-based business-server objects, a plurality of rules modules, and a rules engine.
• the rules-based business-server objects receive user requests for data or results, load relevant rules and pass them to the rules engine, and process the user requests by following the recommendations returned from the rules engine.
• Different rule-based server objects are implemented for different rule modules to improve scalability and maintenance.
• the rule-based business-server objects have static or dynamic CORBA interfaces.
• the rules are generally divided into personalization and decision support rule families which are centrally stored as rule modules accessed only by the business-server objects and the rules engine server. Use of many modules improves performance and avoid undesirable interaction between certain rules.
• the personalization rule modules preferably include an orders and forms rule module, a printing rule module, a help rule module, and a GUI layout rule module.
• the decision support rule modules preferably include an alerts and reminders rule module, a drug-drug interaction rule module, and a diagnosis and interpretation rule module.
• the rules engine is adapted to process the rules and return processing recommendations to the business-server objects.
• the system is coded in Java 1 " 1 .
• the end-user devices interface to the user by Java 011 applets inside a browser or as a standalone application.
• the present invention includes an object-oriented system for computerized patient record (CPR) presentation to a user at an end-user device, the object-oriented system for implementation on computers connected by a network, the system comprising: one or more medical-records-server objects comprising CPR-request methods that input requests for CPR data, access requested data in CPR databases, and return requested CPR data, a presentation application resident in the end-user device that accepts user requests, invokes methods of business-server objects with parameters representing user requests, and displays responses returned by the business-server object methods, one or more business-server objects comprising the business-server object methods invoked by said presentation application, wherein the business-server object methods process input parameters to determine if CPR data is to be obtained, and if so which CPR data, authorize access to the determined CPR data, invoke the CPR-request methods of said medical-records- server objects to obtain authorized CPR data, format a response including any returned CPR data, and return the response to said presentation application, and wherein the authorizing
• the present invention includes a method of presenting computerized patient records (CPR) on an end-user device by an object-oriented system implemented on computers connected by a network, the method comprising: accepting a user request and invoking one or more methods of business-server objects, wherein parameters input to the business-server object methods represent the user request, and wherein said accepting and invoking are performed by a presentation application in the end-user device, determining if CPR data is to be obtained for the user, and if so which CPR data, wherein said determining is performed by the business-server objects according to the input parameters, authorizing the determined CPR data according to authorization recommendations returned from processing both of access-control rules retrieved from a rules database and also of personalization data retrieved from a personalization database, wherein said authorizing is performed by the business-server objects, invoking one or more methods of medical-records-server objects, wherein parameters input to the medical-records- server objects represent the authorized CPR data, wherein the medical-records-server objects
• FIGs. 1 A-B illustrate exemplary system infrastructure utilized by the present invention
• Fig. 2 illustrates a preferred distributed object-oriented infrastructure with rules binding
• Fig. 3 illustrates structure according of the present invention
• Fig. 4 illustrates the general processing sequence of the present invention.
• the methods and systems of this invention achieve the networked distribution and personalized presentation of computerized patient record ("CPR") data on a wide variety of first-tier, end-user devices from a variety of third-tier back-end data-storage systems by using second-tier object-oriented server systems.
• CPR computerized patient record
• the distributed, networked systems and object-oriented software infrastructures of the present invention are described first in the following. Described second are the rule-based server objects which reside on the second- tier server systems and carry out the distribution and personalized presentation on end-user devices.
• CPR data is taken to include the entire gamut of medical information collected for patients at one or more medical institutions or providers and capable of computer storage.
• CPR data for a patient can include past and present information, perhaps spanning the patient's entire life, of the following types: patient demographics; admissions, discharges and transfers; medical progress notes and discharge summaries; notes of operative and other procedures; radiology reports; laboratory results; medications; x-ray, magnetic resonance, ultrasound, and other images; the status of ordered procedures and medications; and so forth.
• General Distributed Systems Infrastructure Fig. 1A illustrates an exemplary embodiment of the distributed system infrastructure utilized by the present invention. This figure illustrates only the general classes of computers, devices, communication links, and networks utilized in the present invention; the particular connections illustrated are merely exemplary.
• the system infrastructure includes network- connected computers functioning primarily (but not necessarily exclusively) either as third- tier back-end computers, second-tier server computers, or first-tier end-user computers or devices.
• Back-end computers such as computers 10 and 11, are adapted for permanent storage of CPR data. They are advantageously provided with adequate with processing resources, main memory, and storage facilities, such as disk storage 12 which may be magnetic or optical, and with database and application software, either legacy software or software initially designed as object-oriented, for managing attached storage facilities and presenting its contents.
• Server computers such as computers 13 and 14, are adapted to host the rule- based server objects of the present invention, which are invoked by requests from end-user devices and which in turn invoke data-server objects on the back-end computers.
• server computer are provided with processing, memory, and storage resources adequate to demands of the rule-based server objects and of the distributed object- oriented infrastructure also resident on these computers.
• the computers and end-user devices of this invention are networked using physical links of various types.
• Fig. 1A illustrates network 15 providing for general connectivity, such as the public Internet or one or more private intranets implementing the Internet suite of communication protocols including TCP/IP.
• Terminal links 16 to computers 10, 11, 13, and 14 can be high-speed telephone lines suitable for data server traffic.
• FIG. 1 A also illustrates exemplary end-user devices 28 including: personal computers (“PC") 17 and 18, which have now standard architectures and operating systems: television set 22 with Internet interface device 22'; and highly portable end-user devices such as display pager 21 , cell-phone 20 with display capability ("screen-phone”), and personal digital assistant 19 ("PDA").
• Terminal network links to these end-user devices can have widely varying characteristics and bandwidth.
• terminal PC links 27 can be switched telephone lines; terminal TV link can be a residential cable; terminal pager and cell-phone links 24 and 25 will certainly be wireless, while terminal PDA link 26 can be alternately wireless or wired.
• the present invention is compatible with end-user devices that both can request and display World Wide Web (“WWW”) content, for example documents formatted in Hypertext Markup Language (“HTML”) and distributed according to Hypertext Transfer Protocol (“HTTP”), and also have sufficient resident software to be able to interact with the distributed, object-oriented infrastructure of the present invention.
• WWW World Wide Web
• HTML Hypertext Markup Language
• HTTP Hypertext Transfer Protocol
• a broad range of such devices having specialized functionality and portability are now available. Further such devices continue to be developed. After study of the subsequent description, it will be apparent to one of skill in the art that such devices can be utilized in the present invention in a routine manner simply by providing the device with a browser program capable of running Java tm applets and a Java 1 " 1 object request broker (“ORB”).
• Fig. IB illustrates exemplary computer 36 with one or more processors 30, main memories 31, storage interfaces 32 with permanent storage devices 33 utilizing magnetic and optical technologies, external interfaces 34 to user displays and communication links, and buses or switches 35 interconnecting these components.
• Computers and operating and database software are widely available from, e.g., Sun Microsystems, Compaq, IBM, Microsoft, Redhat Software, and Oracle.
• End-user devices of specialized functionalities have evolving structures and operating software.
• Exemplary devices are available from, e.g., Philips Electronics, Nokia, 3Com, and Psion, with software from, e.g., Microsoft (Windows CE), the Symbian joint venture, and Sun Microsystems (Java 1 " 1 Development Kit).
• Microsoft Windows CE
• Sun Microsystems Java 1 " 1 Development Kit.
• the present invention includes software objects of functions to be described, which utilize a distributed object-oriented infrastructure for communication between networked computers.
• Objects and object-oriented infrastructures are known to those of skill in the art. See, e.g., Vogel et al., 1998, Java tm Programming with CORBA. John Wiley & Sons, Inc., New York; Object Management Group, Inc. ("OMG”) (Newton, MA; and http://www.omg.org).
• software objects are encapsulated collections of procedures, referred to as methods, and data acted on by the methods. Encapsulation means that, preferably, an object's external interface is limited only to invocations of its public methods. Accordingly, each object's data remains preferably hidden to programs other than the object's methods.
• Fig. IB illustrates exemplary objects 37 resident in memory 31 of computer 36.
• Objects 37 consist of collections of object data 39 and object methods 38, here denoted by opl(.), op2(.), and op3(.).
• object methods 38 here denoted by opl(.), op2(.), and op3(.).
• the only external interface presented by objects 37 consists of the methods opl(.), op2(.), and op3(.), and only by invoking these methods can another program gain even indirect access to object data 39.
• Objects are usually designed to model real-world entities.
• Object data describes and models aspects of the state of the corresponding real -world entities, and object methods model actions on the corresponding real- world entities by causing changes of state and producing outputs in response to input parameters that are similar to real -world actions on the real- world entities.
• invoking a method produces changes object data and produces results in a manner corresponding to a real-world action performed on a real- world entity.
• an object resident in a computer's memory causes the computer to simulate the real- world entity modeled by the object.
• Processing of a system structured as a plurality of client objects resident in computer memories which invoke methods of a plurality of server objects, also resident in the computer memories cause the computers to successively simulate the client and server real-world entities modeled by the client and server objects, respectively.
• Client, server, and other interacting objects need not only be co-resident on one computer, but can also be resident in the memories of a plurality of networked computers.
• the routing remote method invocations between client and server objects is managed by software components referred to as object request brokers ("ORB").
• ORB object request brokers
• An ORB resident in the memory of each networked computer achieves location transparency and portability by activating necessary instances of server objects, transparently managing the communication details of remote method invocations, and optionally providing other services such as object persistence and object replication.
• object request brokers object request brokers
• the objects of this invention are preferably programmed in any programming language providing object oriented features.
• the C++ language is preferred; the Java 1 " 1 language is even more preferred.
• Various commercially available distributed object-oriented infrastructures can be used in this invention.
• the preferred distributed infrastructures conform to the CORBA family of standards developed by the Object Management Group, Inc. ("OMG").
• CORBA- compliant infrastructures are widely available, and include products of, wter alia, Inprise, Inc. (http://www.inprise.com), IONA Technologies, Ltd. (Dublin, Ireland; http://www.iona.com), and ORL (http://www.cam-orl.co,uk ).
• the Java 1 " 1 language development kit available from Sun Microsystems also includes a Java" 11 ORB.
• IDL Interface Definition Language
• IDL is a standardized, purely declarative language which program language bindings for defining object interfaces in a object-oriented system. Compiling IDL object definitions generates client IDL stubs 103 and server IDL skeletons 105.
• the client IDL stubs called by client object 109, include code to marshal a method call and its parameters into a linear form for network transmission to the server object by the communication ORBS.
• the server skeletons include code so that server objects 110 can receive the marshaled method call and convert them into the static interfaces of the server objects.
• CORBA provides two types of object interfaces.
• the static interface which is more efficient but less flexible, is used if the invoked server-object methods are available as IDL definitions at compile time.
• the dynamic interface which is less efficient but more flexible, allows a server objects methods to be discovered at run time.
• Client object 109 invokes dynamic invocation interface 102 to discover how to invoke dynamically bound methods through dynamic skeleton invocation interface 106.
• ORB Object Request Broker
• API application programming interfaces
• ORB core provides basic location transparency.
• CORBA ORBs resident on networked computers communicate using the generalized inter-orb protocol ("GIOP") over, for example, communication link 113, for routing method invocations.
• GIOP generalized inter-orb protocol
• HOP Internet Inter-orb Protocol
• the ORB includes component interface repository 101, implementation repository 102, and object adapter 107.
• the interface repository provides services for dynamically storing, accessing, and updating object-description ("metadata”) information.
• the implementation repository is a run-time repository of information about server object classes, instantiated (in other words, activated) objects and object references, and object location in the network.
• the object adapter records in the implementation repository object references of instantiated server objects.
• the ORB uses the implementation repository to activate server objects and to locate already activated objects.
• the object adapter provides additional services to server objects, such as support for instantiating (or, activating) server objects, passing them method invocations, and assigning them network addresses known as object references.
• a CORBA implementation may include standardized server objects defined in CORBA Common Services and Common Facilities standards.
• One such service is a standardized user authentication and security service.
• Rules modules 111 and rules engine 112 are not part of the CORBA standard, and are described subsequently as part of the present invention.
• Fig. 3 illustrates the preferred allocation of the software functions and objects of the present invention within the distributed object-oriented infrastructure linking the networked system computers.
• the preferred allocation illustrated is referred to herein as "three tier", since it includes a third tier of back-end computers, a second or middle tier of server computers, and a first tier of end-user devices or computers.
• Each tier is described next, followed by more detailed descriptions of the business-server objects, preferably allocated to server computers, and associated software functions and data.
• the First Tier - End-user Devices The first tier includes interactive, end-user devices. Illustrated in Fig. 3 are specialized end-user device 50, which can be a Web attached TV, a personal digital assistant, or a cell-phone or pager with display capability, and so forth, and PC 51, which can be a Intel/Windows-based computer.
• the specialized end-devices are particularly appropriate for applications such as telemedicine or remote consultation.
• an HTML browser program refers to client software that functions to retrieve and display requested HTML documents from an HTML server according to the TCP/IP-based HTTP protocol.
• the HTML document includes an embedded Java 1 " 1 applet, the browser automatically downloads the applet's Java tm byte-codes from an applet store and execute them in its Java 11 " virtual machine environment.
• a separate, stand-alone program of similar function preferably also written in Java tm
• Java tm can be used together with an installed Java tm virtual machine.
• Such a stand-alone program would include similar end-user device display management capabilities, screen definitions similar to any downloaded HTML pages, and internal routines with function equivalent to any downloaded Java 1 " 1 applets.
• the browser be capable of communicating information, for example, its type and version number, so that its capabilities can be determined from stored information, preferably in the personalization database.
• the IP address of an end- user device can be used to determine its capabilities and the capabilities of its display from stored information keyed by IP address, again preferably in the personalization database.
• FIG. 3 illustrates browser program 52 designed for specialized device 50 communicating with middle-tier server 65 over communication path 53, and browser program 54 designed for PC 51 communicating with HTTP server 65 over communication path 55.
• Object-oriented Java 1111 applets 56 and 57 running in a Java 1 " 1 virtual machine environment provided in the respective browser programs, interact with middle-tier business- server objects 67 to respond to user requests.
• An alternative to using the browser's virtual machine it to use browser plug-in technology available from Sun Microsystem's (http://www.javasoft.com/products/plugin/). This technology allows use of Sun Microsystem's most recent Java 1 " 1 runtime environment instead of the browser's default virtual machine.
• these applets receive end-user requests, including those for CPR data, determine which business-server object that can respond to the request according to the request's type, remotely invoke methods of that business-server object, and receive the results returned, including any CPR data. Personalized views of the requested data, for example resident in buffers 58 and 59, are then displayed.
• Data presentation and personalization tasks which are important to this invention and are subsequently described in detail, alternately either can be performed entirely by the business-server object or can be shared between the business-object server and the object-oriented end-user device applet in the case of more capable end-user devices. These tasks personalize displayed results according to end-user characteristics and format them according to the capabilities of the end-user device.
• Remote invocations of middle-tier business-server object methods by the object-oriented end-user device applets are automatically managed, as previously described, by the communicating ORBs, such as Java 1 " 1 ORBs 60 and 61 resident in the end-user memories, and Java 1111 ORB resident in the memory of the middle-tier server computer 76.
• the invocations can advantageously employ either the static or the dynamic CORBA interface, or other CORBA facilities and features.
• inter-ORB communication utilizes the TCP/IP- based protocol HOP. Since browser program communication is also TCP/IP based, all communication between the end-user devices and the middle-tier computers, for example over communication paths 53, 55, 62, and 63, can easily share a single physical network, since TCP/IP protocol stacks (not shown) resident in the memory of each computer and end- user device multiplexes the communication paths onto single links.
• the software functions illustrated in Fig. 3 in the end-user devices are established after successful end-user logon.
• the browser program retrieves HTML logon pages, obtains the user's authenticating information, and verifies it with a middle-tier security server.
• the logon pages include object-oriented Java 1 " 1 applets which remotely invoke authentication methods in security-server objects 70.
• one or more HTML pages are retrieved by the browser programs, direct downloading of Java"" applets 66 and 67, and commence end-user interaction.
• Personal smart cards can also be used in this invention to provide certain user authentication information as well as certain personalization information (in the case where the end-user device shares personalization tasks).
• Smart cards are credit card sized devices which contain a processor, temporary memory, and permanent memory, a certain portion of which is secured from tampering or unauthorized access. Authentication information can be stored in the secured portion, while general personalization information can be stored in the remainder of permanent memory.
• Middle-tier software functions illustrated in Fig. 3, respond to remote method invocations from end-user device applets with various requested results, including partially or entirely formatted and personalized CPR data fetched from back-end data-server objects. Because of the location transparency of the distributed object-oriented software infrastructure, the various middle-tier and other object system functions can be allocated freely to one or more computers. Middle-tier software components are now sequentially described.
• Security server 70 includes objects providing methods for user authentication.
• Logon HTML pages gather user authentication information, such as user-id and password.
• Java tm applets also part of the logon pages, remotely invoke the authentication methods with the gathered authentication information as parameters. Successful authentication allows completion of logon and commencement of interactive usage; unsuccessful logon blocks further response from the system.
• Various kinds of user authentication information can be used in this invention, including information read from a user's smart card by an end-user device card reader or biometric information obtained by a biometric scanner.
• Business-server objects 67 are remotely invoked by end-user device applets 56 and 57 to process the various types of user requests, including requests for CPR data, for data entry, for alerts and reminders, and for decision support functions. Requests processing is summarized here and described in greater detail in connection with the business objects themselves. For all requests, the business-server objects proceed only after first ascertaining that the user has the authorization or access privileges needed to make the request.
• the business-server objects After determining user access privileges, retrieve the requested and authorized data by remotely invoking methods of data-server objects resident in the memories of back-end systems. They then, optionally in cooperation with the end-user device applets, personalize and format data for display.
• each business object demultiplexes requests for all types of CPR data, directing each to the appropriate data-server object.
• the end-user device applet is simplified in that it needs to address a CPR data requests to one class of business-server object.
• each type of CPR data is retrieved by a separate class of business objects.
• the end-user device applet itself must direct the request according to the type of CPR data requested.
• the business-server For data entry requests, perhaps concerning a patient of an end-user, the business-server, after authorization checking, retrieves the appropriate data-entry forms or instructions from the responsible data-entry-server object, provides these to the end-user applet, and returns entered data to the responsible server object.
• the business-server object itself is responsible for data entry.
• Business objects can also provide decision support capabilities to authorized users. For such requests, they can interactively obtain necessary input information from an end-user and then invoke decision support processing by, for example, medically-directed expert systems.
• Business-server objects can also generate alerts and reminders for a requesting end-user.
• the business-server object reviews CPR data for patients associated with that end-user and issues appropriate alerts and reminders.
• Alerts can be generated by applying decision support processing to CPR data. For example, a physician can be alerted to possible drug interactions based on drug interaction decision rules applied to CPR data including current medications for a patient being treated.
• Reminders can simply be end-user entries placed in the patient records for later, timed display.
• system of this invention is open to the addition of other types of end-user requests in a routine manner.
• end-user applets can be modified to provide for the display of the new type of request and for entry of its associated parameters, and a new business-server object can be added to the middle-tier to process the new request, perhaps in cooperation with data retrieved from back-end data-server objects.
• HTTP server 65, HTML store 66, and applet store 67 have been previously described in connection with first-tier components.
• Rules engine 68, rule modules 71 and 72, and personalization database 69 are subsequently described in connection with the business- server objects themselves.
• Persistent CPR data of all types are stored on back-end server computer systems, which make the stored data available as data-server objects, such as system 77.
• the business-server objects of the middle-tier remotely invoke methods of data- server objects 73 resident in memories of back-end computers during the processing of their own methods, which were, in turn, remotely invoked by end-user applets resident in the memories of the end-user devices. Where the data-server objects are remote, this invocation is managed by middle-tier resident ORB 64 communicating with third-tier resident ORB 74.
• Third-tier data server-objects can either be components of a system initially designed to be object-oriented or they can be legacy systems with interface software (a "wrapper") for transforming legacy programming interfaces into object-oriented method interfaces.
• a "wrapper" is known in the art. See, for example, U.S. patent application 09/096694, filed June 12, 1998.
• Legacy systems 75 include, for example, Picture Archiving and Communication System (PACS), Hospital Information System (HIS), Radiology Information System (RIS), Cardiology Information System (CIS), laboratory system, etc. Details of such object- wrapped, legacy systems are not shown in Fig. 1.
• PPS Picture Archiving and Communication System
• HIS Hospital Information System
• RIS Radiology Information System
• CIS Cardiology Information System
• Business-server objects processing is preferably rule based.
• User requests and their associated parameters are processing according to request type by following recommendations resulting from application of stored rules to end-user personalization data.
• the personalization data includes at least information concerning user characteristics, such as user role and user privileges, and concerning user environment, such as the type of end-user device, the network link to the device, the device's display capabilities, browser program capabilities, and the room location.
• Rules are advantageous for such decision-making because, at least, they are a known, modular, and extendable programming method for decision making.
• rules can be modularized so that changing decision criteria can be met by routine modification of specific modules without any need to modify code.
• rules processing can provide decision support services.
• rule-based processing is preferred in this invention, it will be apparent to one of skill in the art that this invention can also employ similar known, modular, and extendable decision-making processing methods, or combination of such methods, known in the artificial intelligence arts.
• the effect of rules processing herein can be achieved by methods based on a first-order predicate logic knowledge representation and associated inference engine. See, e.g., Russell et al., 1995, Artificial Intelligence - A Modern Approach, Prentice-Hall, Inc., ch. 7-10.
• rules used by the business-server objects are preferably expressed with a limited set of programming language constructs expressed in standard syntax, including variables, boolean expression, and statement including "if-then-else" statements, assignment statements, and rule invocation statements.
• standard syntax including variables, boolean expression, and statement including "if-then-else" statements, assignment statements, and rule invocation statements.
• the informal access rule that "if the user is a physician and if the user is the physician of the current patient then the user can see the records of the patient” can be expressed in a precise syntax in the following manner: RULE SeeRecord ⁇ Valueproperty case;
• Exact rule syntax varies depending on the exact rule language and the rules engine used in a particular embodiment. Rules semantics is simply related to the understanding of their syntax common to those of skill in the art. Each rule is typically an "if-then-else" statement, which can be optionally nested. Rule evaluation begins with evaluation of the Boolean "if-condition" based on data values input or assigned to rule variables. The "if-then-else" of the rule body is evaluated and any statements in the "taken" branch are performed. For example, performing assignment statement routinely sets the values of one or more rule variables to the value of an expression. Performing rule invocation statements routinely chain rules, so that a first rule can invoke a second rule. The rule to be evaluated next can be selected sequentially from a list of rules, or according to a priority assignment which can be dynamically updated, or by a rule invocation statement.
• a rules engine evaluates rules presented to it.
• the rules engine simply interprets rules presented in a plain-text form.
• rules are stored separately from the business-server objects in rule databases, or rulebases. Needed rules are retrieved from the rulebases by business-server objects or the rules engine as needed.
• rule modules are advantageously grouped together into rule-sets; related rule-sets are also advantageously grouped together into files known as rule modules.
• Grouping rules into rules modules is advantageous for the following reasons. First, undesirable interactions between certain rules can be avoided by putting those interacting rules into separate modules separately presented to the rules engine. Second, rule modules and rule sets can be assigned priorities which helps to order their evaluation. Third, smaller rule modules improve performance because only a subset of the rules and object are used at any given time and need to be stored in memory. Finally, rule modules also facilitate rule update and maintenance, since each rule module can be maintained by the most knowledgeable person. For, example, administrators can update policy and practice rules; domain experts can update decision support rules; and users can update their personal rules.
• rule module instead of having one bulky cumbersome rule module for a whole medical institution, several separate rule modules representing different aspects of the institution's policies and practices are preferable. Accordingly, related rules for personalization and decision support are grouped into a plurality of smaller rule modules having different functions.
• Rules used in this invention can be programmed with various commercially available knowledge-based application generators, including, ter alia, ART* Enterprise (Brightware), LiveModel (Intellicorp), Elements/ Advisor (Neuron Data) and AionDS (Platinum Technology). Each of these have their own specific syntax for specifying rules. Also, the Arden syntax has been developed for general uses in medical knowledge applications, and has been adopted as a standard for health knowledge representation. See, e.g. , http://www.cpmc.columbia.edu resources/arden.
• a preferable commercial knowledge-based system provides graphic rules editors for defining new rules and modifying existing rules, so that even non-programmers can view and update rules. Such a product also provides tools for checking the consistency of the rules.
• initial accesses of an embodiment of this invention by a user causes the browser program, which is resident in the first-tier end-user device, to contact HTTP server 65 at the second tier, whereupon the primary, or root, HTML page is automatically downloaded from HTML store 66 at first download step 81.
• second download step 82 the end-user device applet referenced in this primary HTML page is downloaded from applet store 67, and applet execution is initialized and started in the browser program. From this step onward until end-user logoff, the object-oriented Java 1 " 1 applet manages the user-interface in the end-user device and responds to user requests by making remote invocations of methods in second-tier server-objects.
• the first action of the end-user device applet is authentication step 83 during which the user is authenticated to the system.
• the end-user applet remotely invokes authentication methods in second-tier security-server objects 70. If the security-server objects do not authenticate the user, appropriate security actions are undertaken to safeguard system integrity and confidentiality. Further, system security is provided by well known protocols which use digital signatures, authentication, and document alteration prevention techniques.
• processing continues with subsequent steps 84 to 94, which implement the user-request-processing loop.
• This loop is executed until user logoff is detected at test 94.
• the end-user device After logoff, at step 95, the end-user device returns to a neutral state.
• the user-request-processing loop begins at wait step 84, where it waits for a user request.
• wait step 84 Upon entry of a user request, after which the end-user device applet gathers the request type and associated parameters, and determines the appropriate business-server object to service request of the input type.
• the request and parameters are passed from the first-tier end-user device applet to appropriate second-tier business-server object 67.
• Each second-tier business-server object generally processes remote method invocations according to steps 86-90.
• business-server object 67 reads stored rules modules that recommend the processing of the entered request type.
• Rules modules of this invention are generally considered either as belonging part to the decision support rules module family 71 or to the personalization rules module family 72, each of these families having the exemplary members illustrated in Fig. 3. These rules modules and related request types are subsequently described in more detail. Rules modules are read in the order of their assigned priority for efficiency and for control of the processing order. As the business-server object reads rules of each rules module, it also reads from the personalization database values for personalization data types referenced in each rule and pertaining to the particular end-user. This read access is represented in Fig. 3 by paths from business-server objects 67 to personalization database 69 and to rules modules families 71 and 72.
• the business-server object read rule modules and referenced personalization database values.
• the business-server object can read both rules primarily related to authorizing and satisfying the entered user request as well as personalization and formatting rules and referenced data. Alternatively, it can defer reading the latter rules and data until they are needed at format step 90.
• the business-server object then calls, or otherwise arranges to pass, the retrieved rules and the user's personalization data-type values to rules engine 68 for processing. Because of rule chaining, rules initially passed to rules engine 68 may requires further access to additional rules modules and personalization data-type values. This access is illustrated in Fig. 3 by paths from rules engine 68 to personalization database 69 and to rules module families 71 and 72.
• rule-based server object processing is also illustrated in Fig. 2.
• methods of server object 110 illustrated read rules modules 111 and pass them to rules engine 112, which returns processing recommendations to these methods. Because of rule chaining, it may be necessary for rules engine 112 to directly read rules modules 111, as illustrated.
• this invention is not limited to this particular rules access structure, but comprehends other access structures that make needed rule modules and personalization data type values available to the rules engine.
• test step 88 distinguishes two processing cases depending on the type of entered request and recommendations returned by the rules engine. In one case, no access to actual CPR data is needed. For example, in the case of a CPR data request, the rules engine may recommend denial of the user access request. In the case of a decision support request, all needed data may be entered as request parameters by the end- user.
• business-server objects 67 make remote method invocations to methods in appropriate third-tier, data-server objects 73.
• Data-server objects 73 access CPR data, either directly from object-oriented CPR database systems or indirectly through wrapper code from legacy CPR database systems 75, which are typically non-object-oriented.
• the data or results are personalized and formatted according to recommendations returned by rules engine 68 upon processing personalization and format related rules modules and data.
• These modules and data can be either read in prior step 86 or deferred to this step.
• a formatting recommendation may be to format a medical image at a resolution of 640x480.
• the personalized data or results are returned to the first-tier, end-user device applet, thereby completing the remote method invocation of the business- server object initiated at step 85. Finally, returned data or results are displayed to the end- user at display step 93.
• certain data or results formatting operations can be advantageously offloaded to the end-user PC.
• certain local rules modules and personalization data typically machine specific formatting rules and machine characteristic data, and a local rules engine.
• the local rules are coded in Java 0 " and are downloaded as an applet.
• End-user device applet 54 before final display, would interact with the local rules engine, in a manner similar to the interaction of business-serve objects 67 with rules engine 68, and would further format returned data or results according to recommendations derived from the resident rules and returned by the local rules engine.
• an entire high-resolution medical image can be downloaded to PC 51 , with final formatting at the resolution of the attached display, either as a whole or in segments as the user pans across the image, deferred to the PC.
• this alternative advantageously shifts processing load away from the second-tier server to first- tier end-user devices.
• the personalization database contains values for data of varied types that are referenced by the stored system rules that guide business-server object processing. Exemplary data types typically present in the personalization database are discussed individually as in the classes that follow.
• USER ATTRIBUTES CLASS Data of the user attributes class indicates the relationship of the user to the medical institution or to particular patients, as well as the user's interests and preferences. Preferably, users are divided into the categories of staff, patient and visitor, with the following subcategories:
• Data of the user privileges class indicates CPR data access allowed to the user.
• this data are organized into the following categories:
• Data of the computer and network characteristics class indicates the hardware and software characteristics of the user's computer and of the network connection of the computer to the system.
• this data are organized into the following categories and subcategories: - Type (SUN (Ultra 1, Sparc 20, etc.), PC (Pentium, etc.), Mac, etc.).
• Data of the display characteristics class indicates the characteristics of the display of the user's computer. Preferably, this data are organized into the following categories and subcategories: - Spatial resolution (2Kx2K, lKxlK, XGA, SVGA, VGA, etc.). Physical size. Monochrome or color. Modulation transfer function.
• Data of the browser characteristics class indicates the software capabilities of the browser resident in the end-user device. Preferably, this data are organized into the following categories and subcategories:
• Data of the room characteristics class indicates any limitations due to user's current room location.
• this data are organized into the following categories and subcategories:
• Lighting conditions dark room, bright room, etc.
• Audio characteristics sound room, quiet room, etc.
• Personalization database 69 This database advantageously includes a plurality of storage structures appropriate for the types of data being stored. Persistent data, which is useful across several user sessions, can be stored either as a structured database or alternately as one or more files, or certain portions can optionally be stored in a user smart-card. Transient data, which is useful only for the current user session, can be stored as convenient, perhaps as in memory data records associated with the user session representation. Accordingly, the storage of personalization database information is preferably adapted to the type of information and to its persistence.
• Information is entered in the personalization database by various methods, including, inter alia, through forms and from dynamically available session information.
• the system can query a user upon first accesses to enter persistent self-descriptive information. This information can be updated on user request.
• the system will display a HTML form, perhaps with Java 1 " 1 applets, seeking information about the user's department or section, function, specialty, interest, education level, default browser, and so forth.
• the user can enter details concerning persistent preferences for screen layout, help presentation, printing formats, presentation of alerts and reminders, and so forth.
• system administrators can enter sensitive persistent data controlling the user's authorizations and access authorities so that they are consistent with the medical institutions policies and practices.
• IP address of the client is obtained from the IP address of the client, client-server browser communication, smart cards, active badges, and so forth. IP addresses of clients requesting information from the server, where they are statically rather than dynamically assigned, uniquely identify the end-user device. In such situations, the IP address of the end-user device is automatically detected by the web server when a user logs on, and then computer, network, and environment information is retrieved from a database or files at the second-tier server which includes such information indexed by IP address.
• the IP address can be used to identify the computer type (e.g. SUN, PC, MAC, etc.), its add-on capabilities (e.g. sound card, video decoding hardware, etc.), its lowest bandwidth connection link to the web server (e.g. ATM, Ethernet, ISDN, wireless, etc.), the resolution of the display to which it is attached (e.g. 2Kx2K, lKxlK, XGA, SVGA, VGA, etc.), the location of the computer (provided it is not mobile), and constraints imposed by the location. System administrators of the hospital's computing facilities would update such system resource databases as necessary.
• the computer type e.g. SUN, PC, MAC, etc.
• add-on capabilities e.g. sound card, video decoding hardware, etc.
• its lowest bandwidth connection link to the web server e.g. ATM, Ethernet, ISDN, wireless, etc.
• the resolution of the display to which it is attached e.g. 2Kx2K, lKxlK,
• the browser program running in the end-user device can detect device and browser capabilities and can communicate these to the second-tier server.
• the previously listed computer, add-on, and display capabilities, as well as browser capabilities support for Java 1 " 1 , ActiveX, versions of HTML and HTTP, plug-ins, etc.
• browser capabilities support for Java 1 " 1 , ActiveX, versions of HTML and HTTP, plug-ins, etc.
• information in a smart card carried by a user can be read to provide certain user attributes as well as to prove user identity.
• the rules of this invention which are separately stored in rule databases and are retrieved by the business-server objects and the rules engine, are advantageously grouped into and retrieved as rule modules, which are collections of rules and rule-sets directed to similar situational analysis.
• the rules modules are assigned to two families of rules modules, namely decision support rules module family 71 (Fig. 3) which are directed to providing decision support services to end-users, and personalization rules module family 72 which are directed to personalizing and formatting system data and results.
• the personalization rules module family is described first followed by the decision support rules module family. The following are examples of constraints imposed in personalizing the content:
• the specialty, such as cardiology, of a physician user should be taken into account so that the physician receives only the news and information which is likely to be of interest.
• - Information should only be provided to users with sufficient access privileges.
• a computer that does not have a sound card should not receive audio files in any case.
• a laptop with a low-speed modem and a small screen should not be exposed to large movie files or large images.
• personalization rules module family 72 preferably includes at least an alerts & reminder rule module, an access privileges rules module, a platform rules module, a graphic user interface ("GUI") layout rules module, a help rules module, a help rule module, an order & forms rules modules, a printing rule module, and such other personalization rules modules as a medical institution finds advantageous.
• the rules of the access privileges rules module determine which user is authorized to view which information concerning which patients.
• access privileges depend on federal and state regarding patient confidentiality law.
• Each medical institution hospital may also have local protocols for ensuring patient confidentiality, data integrity, and security (digital signatures, authentication, and document alteration prevention techniques).
• the system administrator of the hospital is responsible for maintaining such policies and rules for information access.
• Access privileges also depend on the user function, role and relationship to the patient (i.e. patient's attending physician, consulting physician, attending nurse, etc.). For example, not only do different occupations/specialties need different "views" of the CPR which are tailored to their needs but different patient relationships may influence the level of detail presented in sensitive areas. For example, all physicians who treat a patient may see that the patient is undergoing psychiatric treatment, but the details of any psychiatric treatment may be viewable only by the attending psychiatrist and the patient. Also, access to records for certain "NIP" patients (politicians, actors, etc.) may be further restricted than for normal patients, due to the increased potential for adverse publicity and blackmail. Patients should be able to see their own CPRs, in full detail.
• the rules of the platform rules module determines how content should be personalized formatted for a particular end-user device connected on a particular network link. Such personalization and formatting is independent of user requested personalization because many users (physicians, in particular) may have many types of equipment and network links, e.g. at the office, the hospital, and at home, which have widely varying abilities. Further, the system can include end-user devices which are not assigned to particular end-users for public use, e.g., by referring physicians visiting their in-patients. Therefore, the business-server objects, acting on recommendations of the platform rules module, personalizes and formats information presented to be consistent with an end-user device's location and capabilities. As discussed, some information on these capabilities is gathered at user login.
• the content can be dynamically generated and automatically customized to match the capability of the client browser, display, and link bandwidth.
• images and sound files are personalized and formatted (full resolution or minified) and compressed for transmission (none, loss less, lossy/quality) according to the link bandwidth and the capabilities of end-user devices, so that a user need not wait for large transfers at locations with low speed connections.
• the display of an end- user device can not handle high-resolution images, then low-resolution images are presented on this device, even if the user has requested otherwise.
• the network connection of the user is slow, then low resolution images should be transmitted, unless the user has indicated acceptance of the necessary wait for full resolution images.
• Scaling and layered video coding schemes are one method which can be used to multicast one single compressed video stream across heterogeneous networks, computers, and displays.
• the routers can then send the appropriate number of compressed video layers to the appropriate machines for software or hardware decoding. For example, a high-end workstation with a high resolution display and high bandwidth connection will receive the base layer plus all the enhancement layers.
• An intermediate computer with a moderate resolution display and a moderate bandwidth connection can receive the base layer plus some of the enhancement layers.
• a low-end workstation with a low resolution display and a wireless connection will receive only the base layer.
• the rules of the GUI (graphical user interface) rules module determine how content to be presented should be arranged on the display screen of an end-user device for a particular end-user. These rules can interpret user preferences stored in the personalization database. Alternatively, a user may personalize the rules themselves.
• Rules of this module can determine the overall layout of an end-user device screen display. For example, screen displays can be partitioned to accommodate different information categories in different regions. A large portion of the screen will be reserved for personalized and formatted information requested by the user. Another portion of the screen will be reserved for general information which should be seen by everyone at a medical institution. Finally, a third portion will be reserved for personal information, such as, for example, the web sites and content which the user visits most frequently.
• rules of this module can determine how these screen portions are formatted in detail. For example, a user can specify a flag to view numerical results in tabular form or in a graphical plot. The user can request not to view images. The user can specify the positioning of information items (for example, show the present lab results next to the previous lab result, with the most recent lab results on the left).
• HELP RULES MODULE The rules of the help rules module determines how the on-line help system of this invention is personalized to provide the most efficient assistance to an end-user.
• the help and explanation provided can be personalized based on the level and experience of the user.
• the user information that is stored in the personalization database can have a "user level" attribute for each user to differentiate expert CPR users from novice ones.
• the system can use the audit trails and/or track users to figure out the level of each user.
• the rules of the help rules module adapt the screen display to create a personalized help system.
• Which help system components are displayed can be context sensitive and depend on the task that the user is performing (e.g. viewing, reporting, ordering, updating, etc.) and the information category that being acted on (Lab, pharmacy, radiology, etc.).
• ORDERS & FORMS RULES MODULE can be context sensitive and depend on the task that the user is performing (e.g. viewing, reporting, ordering, updating, etc.) and the information category that being acted on (Lab, pharmacy, radiology, etc.).
• the rules of the orders & forms rules module determines which users have privileges to access the system capabilities to fill in orders and submit admitting and other forms from end-user devices.
• the present invention provides the capabilities for the large number of forms and orders relating to patient care in a medical institution to be filled-in from end-user devices. Different users have different roles and capabilities for filling-in forms. For example, only physicians can enter order for medications or treatments.
• the rules of this module control access to forms and the ability to fill-in or modify them based on user attributes similar to those governing general access privileges. PRINTLNG RULES MODULE:
• the rules of the printing rules module determines print formats in accordance with a user's printing preferences stored in the personalization database. Therefore, upon a user print request, the business-server objects can print pages personalized and formatted according to the user's specifications. For example, these rules can specify that images not be printed or be printed only at a reduced size. The users can change their own printing preferences.
• the rules of the alerts & reminders rules module determines personalization, formatting, and presentation of the results generated by the alerts & reminders rules module of the decision support family.
• Personalization and formatting rules determine the physical layout and screen presentation of alerts and reminders. Presentation rules can also determine the manner of transmission of these messages, which may be a function of the priority indicated for the message. For example, a rule of this module may specify: IF the message is an urgent alert, THEN page me and send me e-mail with the alert appropriately formatted. Another exemplary rule may specify: IF the message is a reminder, THEN send me formatted e-mail only. Rules Module - Decision Support Family
• decision support functions can be easily integrated into the structure of business-server objects 67 (Fig. 3), rules engine 68, and rules modules by simply introducing additional rules modules which provide decision support reasoning capabilities.
• decision support rules module family 71 typically includes at least an alerts & reminder rule module, a diagnosis and interpretation rules module, and a drug interaction rules module.
• the knowledge-base of decision support rule modules is typically obtained and maintained by domain experts.
• One of skill in the art will understand how other decision support services that a medical institution finds advantageous can be implemented in additional decision support rules modules to be added to this family and knowledge base.
• ALERTS AND REMINDERS RULE MODULE ALERTS AND REMINDERS RULE MODULE:
• the rules alerts & reminders rules module of the decision support family determines decision support functions available to notify care givers of generally urgent or notable events.
• decision support alerts are generated to draw the user's attention to urgent events, e.g. abnormal test results, urgent orders or medications not processed, possible drug interactions, etc.
• a rule may be: IF white cell count is greater than 20,000, THEN generate an alert message.
• Decision support reminder messages are generated for more routine and less urgent events, or can be entered by the user for latter display as a "tickler" message.
• These rules are patient, episode and user specific. They allow only certain classes of patients to be examined with a certain frequency for certain types of events to generate certain alerts and reminders.
• a physician may wish to routinely scan only diabetic patients for abnormal glucose trend events and only patients being administered cancer chemotherapeutic for dangerous white cell count events.
• Rules of the "Alerts and Reminders" module allow a user to choose which events rank as more urgent alerts and which events are adequately addressed by less urgent reminders. Further, these rules can also specify which alerts require urgent attention, and which event are not urgent and are adequately addressed by reminders. For example, some physicians may want to be alerted about certain events on a particular patient whereas others may only want reminders. Alerts and reminders can optionally be assigned a priority. For example, an alert may be marked as "urgent". DIAGNOSIS & INTERPRETATION RULES MODULE:
• the diagnosis & inte ⁇ retation rules module includes rules representing diagnostic support and inte ⁇ retation of particular conditions and results. These rules can scan a CPR of a particular patient and provide suggested diagnoses or inte ⁇ retations.
• the drug interaction rules module includes rules representing known adverse drug interactions and can provide warnings of potential adverse interactions in a particular patient given information on the medications of that patient.
• rule and rule modules are prioritized and are processed by the rules engine in priority order.
• the highest priority rule modules are the access privileges and the orders & forms rule modules.
• the GUI rules module has a lower priority, because, if a user is not authorized to view certain types of information for a particular patient, then that 3 Q information should not be accessible even if the user indicates otherwise in the screen layout preferences in the GUI rules module. Similarly, if a user is not authorized to order for a particular patient, then that user should not be able to display orders and forms menus on a display screen.
• the platform rules module At the next level of priority modules is the platform rules module. If the capability of the platform can not handle certain information, e.g., high-resolution images, then rules which deal with the formatting and personalization of that information, e.g., preferences for how to display high resolution images, need not be evaluated.
• rules modules of this invention are duplicated on several second- tier server systems or where certain of the rules modules have been downloaded to capable end-user computers, it is preferable to update in a coordinated fashion all copies of the rules modules. It is similarly preferably to update other software components that are necessarily duplicated on various computers and device of this system. Such updates are done by installation means.
• Push technologies are generally taken herein to mean technologies that maintain information on where software components are or should be in a system, and, when presented with a new software component or an updated existing software component, will automatically place this component in the appropriate locations in a system.
• push technologies can copy an updated rules module to all middle-tier server systems and to all end-user devices to which it has been downloaded.
• One preferable push technology is available in the Castanet System of
• Push technologies have further applications for providing medical news channels and information, medical education, medical reference information, and so forth to end-users at end-user devices from news servers on the Internet. Where such broadcast is provided, the type and formatting of the broadcast information can be controlled by additional personalization rules modules in the manners previously described.
• the systems and methods of his invention are not limited to the preferred domain of the activities of medical institutions.
• One of skill will understand how the same systems and methods can be applied to the activities of other institutions, such as, for WO 00/57339 j PCT/EPOO/02753 example, banks, insurance companies, airlines, hotels, manufacturing co ⁇ orations, and so forth.
• the first steps are to create rules and rule-based business server objects.
• Different rule-based business-server objects can be implemented for different rule modules to improve scalability and maintenance.
• different business-server objects can be created for handling help, for orders & forms, for diagnosis & inte ⁇ retation, and so forth.
• the rules can also be compiled to create Java 011 classes.

Landscapes

• Engineering & Computer Science (AREA)
• Health & Medical Sciences (AREA)
• Medical Informatics (AREA)
• Public Health (AREA)
• Epidemiology (AREA)
• Biomedical Technology (AREA)
• Primary Health Care (AREA)
• General Health & Medical Sciences (AREA)
• Data Mining & Analysis (AREA)
• Pathology (AREA)
• Databases & Information Systems (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
• Computer And Data Communications (AREA)
• Medical Treatment And Welfare Office Work (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=23051986

Family Applications (1)

Country Status (3)

Cited By (3)

Families Citing this family (43)

• 2000
  • 2000-03-23 EP EP00922563A patent/EP1145179A2/en not_active Withdrawn
  • 2000-03-23 JP JP2000607143A patent/JP2003526136A/ja active Pending
  • 2000-03-23 WO PCT/EP2000/002753 patent/WO2000057339A2/en not_active Application Discontinuation

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events