EP1774448A2 - Systeme et methode permettant de coupler des donnees de patient avec des systemes de support de decision a directives executables - Google Patents

Systeme et methode permettant de coupler des donnees de patient avec des systemes de support de decision a directives executables

Info

Publication number
EP1774448A2
EP1774448A2 EP05776290A EP05776290A EP1774448A2 EP 1774448 A2 EP1774448 A2 EP 1774448A2 EP 05776290 A EP05776290 A EP 05776290A EP 05776290 A EP05776290 A EP 05776290A EP 1774448 A2 EP1774448 A2 EP 1774448A2
Authority
EP
European Patent Office
Prior art keywords
data
accordance
exchanged
providing
nodes
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP05776290A
Other languages
German (de)
English (en)
Inventor
Yasser Alsafadi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Koninklijke Philips NV
Original Assignee
Koninklijke Philips Electronics NV
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Koninklijke Philips Electronics NV filed Critical Koninklijke Philips Electronics NV
Publication of EP1774448A2 publication Critical patent/EP1774448A2/fr
Ceased legal-status Critical Current

Links

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
    • G16H70/00—ICT specially adapted for the handling or processing of medical references
    • G16H70/20—ICT specially adapted for the handling or processing of medical references relating to practices or guidelines
    • 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

  • the present invention relates generally to decision support systems, and more particularly to a decision support system for use in assisting in providing healthcare to a patient using executable clinical guidelines.
  • DSS Decision support systems
  • MLMs Medical Logic Modules
  • the MLM was provided with a special section in which terms used by the DSS were surrounded by additional terms for providing a mapping to terms used by the local information storage system.
  • the additional terms are known as curly braces.
  • the mapping between the MLM terms and the local information storage systems is institution specific and requires much custom tailoring. Hence the burden of preparing and using the mapping is commonly referred to as the "curly braces problem”.
  • the cost and effort of building a DSS is very high, and its customization for use with a local information storage system is time consuming, interfering with the objective of sharing a DSS with many institutions.
  • the present invention is therefore directed to the problem of developing a system and method in which a DSS may be coupled to many information systems and deployed at many institutions.
  • the system includes a local information storage system storing a plurality of first data elements associated with respective data relating to a plurality of patients, and an executable guideline decision support system executable on at least one processor.
  • the decision support system includes an executable guideline storage system for storing a plurality of executable guidelines, and an execution engine for executing the guidelines, including processing at least data associated with a second data element.
  • the decision support system includes a search module executable on the at least one processor for generating a request to exchange data associated with the second data element between the local information system, the decision support system and a patient knowledge base.
  • the patient knowledge base is executable on the at least one processor for determining a first data element of the plurality of first data elements that corresponds to the second data element, and at least one interoperability parameter defining how the first and second data elements correspond.
  • the patient knowledge base is further executable for processing the data being exchanged in accordance with the determined at least one interoperability parameter for establishing semantic interoperability between the first and second data elements.
  • a coupling is provided for transmitting the data being exchanged between the first and second data elements.
  • the method includes the steps of providing for generating a request to exchange data between the local information system and the decision support system, wherein the data being exchanged is included in the data associated with the second data element, and providing for determining a first data element of the plurality of first data elements that corresponds to the second data element and at least one interoperability parameter defining how the first and second data elements correspond.
  • the method further includes the steps of; providing for processing the data being exchanged in accordance with the determined at least one interoperability parameter for establishing semantic interoperability between the first and second data elements; and providing for transmitting the data being exchanged between the first and second data elements.
  • FIG. 1 shows a block diagram of an exemplary system including a decision support system coupled to a local information storage system in accordance with the present invention.
  • FIG. 2 shows a flowchart of steps performed during operation of the system shown in FIG. 1, where the decision support system requests data retrieval from the local information support system; and
  • FIG. 3 shows a flowchart of steps performed during operation of the system shown in FIG. 1, where the decision support system updates data stored by the local information storage system.
  • the present invention describes a system having a decision support system for executing an executable clinical guideline for providing clinical guidance to a user in the treatment of a patient.
  • the decision support system is coupled to a local information storage system storing data relating to a plurality of patients and/or their treatment. Data stored in the patient information storage system is needed by the decision support system for executing the guidance, and the decision support system may need to update data stored by the local information storage system.
  • the decision support system includes a patient knowledge base which semantically matches information stored by the local information storage system with queries or updates generated by the decision support system for providing semantic interoperability between the decision support system and the local information storage system. The semantic interoperability ensures that the decision support system and the local information storage system have a common understanding of the meaning of requested or exchanged data and/or actions for preventing misinterpretations and ultimately faulty medical decisions.
  • FIG. 1 shows a preferred embodiment of an exemplary system 10 having a decision support system coupled to a local information storage system for use in assisting in providing decision support in the healthcare of a patient.
  • the system 10 includes an executable guideline decision support system (DSS) 12, which includes an executable guideline storage system 14, a DSS execution engine 16, a user interface (UI) 18, a domain knowledge base (DKB) 22, a patient knowledge base (PKB) 24, and a request module 30.
  • the system 10 further includes an interface module 28 and a local information storage system (LISS) 26 storing data related to at least one patient and/or treatment of the at least one patient.
  • DSS executable guideline decision support system
  • UI user interface
  • DKB domain knowledge base
  • PDB patient knowledge base
  • the execution engine 16 includes a request module 30 for generating queries or requests for searching through the PKB 24 for finding semantically correct data needed for the execution of a guideline, or for determining a semantically correct way to use data processed by the execution engine 16, such as for updating the LISS 26.
  • the term storage system refers to a system for storing and accessing information, such as one or more databases or repositories, where the storage system may be structured and/or not structured.
  • the DSS 12 is implemented using at least one processor and at least one storage medium accessible by the at least one processor.
  • the components of the system 10 e.g. the local information storage system 26; the interface module 28; and the DSS 12 and its components (e.g., the evidence guideline storage system 14, the DSS execution engine 16, the user interface 18, the domain knowledge base 22, the patient knowledge base 24 and the request module 30)
  • wired or wireless couplings 31 which may be provided by one or more networks, such as a LAN, a WAN, an intranet, the Internet or a combination thereof.
  • the respective components of the system 10 may share resources of the at least one processor and the at least one storage medium, or may have exclusive use of one or more of the resources.
  • the at least one processor may include, for example, a personal computer, a microprocessor, a handheld computing device, a server, etc.
  • the at least one storage medium may include, for example, a hard drive, a CD-ROM, RAM, flash memory, volatile memory, non- volatile memory, etc.
  • the LISS 26 is preferably selectable from a plurality of LISSs of different types, where the DSS is capable of exchanging information with the various LISSs of the different types of LISSs.
  • the LISS 26 stores data related to a plurality of patients and their treatment, which may include patient information, lab results, imaging results, etc., which are preferably stored as a plurality of first data elements that are configured in accordance with at least one of the types of standard electronic medical records.
  • the DSS 12, or a portion thereof, may reside on a server or on storage accessible thereby, where the server is accessible by a plurality of computers.
  • a user may operate a workstation, such as a personal computer, in order to use the DSS 12, where execution of the DSS 12 is performed at the server or at the workstation.
  • the DSS may reside on one or more workstations or on storage accessible thereby.
  • the DSS 12 may be embedded within or linked to another system, such as an administrative information storage system (e.g., for a hospital, nursing home, laboratory, etc.).
  • Exemplary applications for the DSS 12 include assistance in resource management, planning and/or quality assurance.
  • the guideline storage system 14 stores a plurality of executable guidelines.
  • the guidelines stored in the executable guideline storage system 14 are preferably evidence- based, and developed in accordance with experience and research of experts in the field.
  • the guidelines are encoded by appropriate encodings, such as ASBRU, GLIF, EON, GUIDE, PRODIGY and PROforma, etc.
  • the guideline storage system 14 is preferably searchable for finding a particular guideline or the guideline that best meets criteria, typically the guideline that provides clinical guidance for treatment within a context best matching a combination of at least one of patient context, user context, care context, etc.
  • the DSS 12 accesses a selected guideline from the guideline information system 14.
  • the guideline may be selected by the user by instructing the DSS 12 to access the selected guideline, and/or the guideline may be selected by the DSS 12 in accordance with clinical context related data available to the DSS 12, such as the context of the patient's present state, medical history, care provided so far, etc.
  • a clinical application may be used to submit clinical context data to the DSS 12, or the user interface 18 may be used to allow the user to enter clinical context data.
  • a copy of the selected guideline or links thereto may be stored temporarily or permanently, such as at the user's work station, with the patient's data in the local information storage system 26, and/or in a workspace provided by and/or accessible by the executable guideline system 14 or the DSS 12.
  • the stored copy may be customized for the individual, such as by eliminating or bypassing certain steps of the guideline, e.g., by using a guideline editing tool.
  • the respective guidelines include at least one series of steps, each series including at least one step.
  • the individual steps of the guideline include a variety of types of steps.
  • One type of step is an action step instructing a user (e.g., clinician, nurse, hospital administrator, technician, etc.) or a component of the system 10 to perform an action. Examples of actions include gathering information, performing tests, providing treatment, and jumping to another step of the guideline or of a different guideline.
  • Another type of step is a choice step for prompting a user to make a decision, such as deciding the next step to be performed from a choice of at least two steps.
  • Another type of step is a state step representing the current state of the patient, an entity related to the patient or the patient's treatment, or the execution process.
  • Still another type of step is a case step, where at least one algorithm is performed for making a determination, such as for deciding which step to perform next. Information gathering, such as from the LISS 26, may be performed during execution of the various types of steps.
  • the guideline being executed is presented to the user via the guideline user interface 18.
  • the guideline user interface 18 may generate a display, such as for display on a screen of a handheld or desktop computing device, and process input from an input device, such as a pointing device and/or a keyboard, etc.
  • the guideline user interface 18 may generate a graphical user interface (GUI), but is not limited thereto.
  • GUI graphical user interface
  • the guideline user interface 18 may provide an interface including a voice activated system that provides menu choices and/or prompts via audio messages, such as for use via a telephone.
  • User responses may be provided by key pushes and/or voice responses, and voice recognition technology may be used to process the responses.
  • the execution engine 16 of the DSS 12 executes at least one executable guideline stored in the guideline storage system 14.
  • Execution of the at least one executable guideline typically includes accessing and processing data stored in the domain knowledge base 22 and/or the local information storage system 26.
  • the patient knowledge base provides semantic interoperability for ensuring that the requesters (e.g., the execution engine 16) and providers of information (e.g., the LISS 26) have a common understanding of the meaning of the requested data and services.
  • Semantic interoperability implies a semantic matching process which is highly context dependent, and may include compensation as necessary to ensure compatibility between the requesters and providers of information. Semantic matching applies to the definition of a concept as well as its instantiation. Examples of semantic differences include differences in numeric representation, units, techniques and conditions of measurement, precision of measurement, degrees of error, sources of information (e.g., expert physician versus computer algorithm), degree of confidence for a value or diagnosis, demographic conditions (e.g., gender, weight, height, skin color, ethnicity), clinical conditions, ambient conditions, point of reference, use and scope of terminology, etc.
  • the PKB 24 and the DKB 22 are both populated information storage systems, preferably configured as ontologies.
  • knowledge about the domain of patient data is represented in a declarative language.
  • the set of objects that can be represented by the declarative language is called the universe of discourse.
  • the ontology defines a set of representational terms and provides formal axioms that constrain the interpretation and well-formed use of these terms, as described below.
  • the interface module 28, which interfaces between the PKB 24 and the LISS 26, may be implemented using specifications that are available, such as HL7 Templates or Australian Archtypes specifications.
  • the PKB 24 stores data nodes holding patient related data; relationships between the data nodes; and attributes associated with respective data nodes.
  • the data may be configured in accordance with standard medical data models (e.g., HL7, DICOM, etc.).
  • the relationships such as semantic links, show how the data nodes are related, such as via causal, temporal and/or group membership relationships.
  • the attributes include information that describes the context and semantic meaning of the data for constraining the interpretation and use of the data, such as how the data was obtained, how the data is represented, etc.
  • the attributes may describe characteristics about the data, such as usage of numeric representation, units, techniques and conditions of measurement, precision of measurement, degrees of error, sources of information (e.g., expert physician versus computer algorithm), degree of confidence for a value or diagnosis, demographic conditions, related clinical conditions, ambient conditions, point of reference, terminology and scope thereof, etc.
  • the attributes may include an LISS indicator for indicating when a data node corresponds to a data element of a local information storage system and/or which local information storage system.
  • the DKB 22 stores information that is not related to specific patients, such as data that is related to particular diseases, drugs, treatments, etc.
  • the information may include algorithms and/or equations which are useful for establishing semantic interoperability, such as for defining relationships and/or compensating between incompatible uses of information, e.g., compensating for differences in units, points of reference, ambient conditions, etc.
  • the DKB 22 provides semantic links between stored information.
  • the DKB 22 may include a domain for obstetrics including the elements abdominal circumference (AC) of a fetus and estimated fetal weight (EFW).
  • a semantic link may be provided between the AC and EFW elements for establishing that AC may be used for deriving EFW.
  • the elements femur length (FL) and menstrual age (MA) may be included within the same domain or another domain, such as orthopedics.
  • Another semantic link may be provided between the FL and MA elements establishing that FL is a function of MA.
  • a flowchart 200 is provided showing steps performed during operation of the system 10, where the DSS 12 requests data from the LISS 26.
  • the request module 30 generates a PKB query including a request for retrieving data stored by the LISS 26 which corresponds to a particular second data element being processed by the execution engine 16 while maintaining semantic interoperability with the particular second data element.
  • the desired data which to be retrieved in accordance with the request is data that is to be exchanged between the LISS 26 and the DSS 12.
  • the PKB query is more specifically requesting that the PKB 24 find information about how to find the desired data in one of the first data elements stored in the LISS 26, and determine how the data found can be used while maintaining semantic interoperability with the execution engine 16.
  • the attributes of the second data element which maintain semantic interoperability with the second data element being processed by the execution engine 16, are known by the PKB 24.
  • the PKB query could provide the attributes by consulting the DKB 22, since the attributes have already been specified when defining the data elements of the guideline.
  • the PKB query may request retrieval of data that corresponds to more than one first data element and/or more than one second data element, however for the purpose of clarity, the following explanation relates to the case of retrieving data corresponding to one first data element and one second data element.
  • the PKB 24 processes the PKB query.
  • the PKB 24 accesses a first data node that corresponds to the second data element.
  • the PKB 24 determines a second data node that is related to the first data node, and that correlates to a first data element stored by the LISS 26.
  • the second data node is located by processing the at least one relationship associated with the first data node and checking for correlation to a first data element stored by the LISS 26. Correlation to the first data element stored by the LISS 26 may be determined by checking the LISS indicator, if included with the data nodes of the PKB 24. Otherwise, a list provided of the plurality of first data elements or the LISS 26 itself may be consulted.
  • the best data node is selected to be second data node in accordance with predetermined conditions, such as in accordance with user selection, simplest relationship, having attributes most common to the first node, etc.
  • the PKB 24 determines at least one interoperability parameter defining how the first and second data elements correspond, which is indicated by the relationships between the first and second nodes.
  • the interoperability parameter includes at least one of at least one relationship defining how the first and second data elements are related; and at least one set of at least one rule of compensation for defining how to compensate between the first and second data elements.
  • the at least one relationship is determined in accordance with the relationships configured between the first and second nodes, and may include the identifier used by the LISS 26 to identify the data element of interest.
  • the rule(s) of compensation are determined by comparing the attributes of the first data node (which corresponds to the second data element) and the second data node (which corresponds to the first data element).
  • the rules of compensation are determined by determining differences in the attributes of the first node relative to the attributes of the second node, and creating rules to compensate for the determined difference for providing semantic interoperability between the first and second data elements, and/or to provide the ability to derive information from data available in the LISS 26.
  • the PKB queries are configured as descriptive logic based queries. It is preferable that the request module 30 include at least one artificial intelligence module for formulating the PKB queries.
  • the PKB 24 may consult the DKB 22 or intelligent agent(s) for determining the second data node and the interoperability attributes.
  • the interoperability parameters may be stored temporarily or permanently in association with at least the second data element or the first node for subsequent use thereof. Storage of the determined relationships and the determined rales of compensation, or access thereto, may be provided by the PKB 24 and the DKB 22, in accordance with design choice. If the interoperability parameters have been stored and are available, instead of determining them, they are retrieved from storage.
  • the PKB generates a LISS query in accordance with the determined at least one relationship interoperability parameter for querying the LISS 26 to retrieve data associated with the first data element.
  • the at least one relationship interoperability parameter is used for locating the first data element within the LISS.
  • the interface module 28 translates the LISS query into a format that is understood by the LISS 26.
  • the LISS 26 responds to the LISS query by providing results to the interface module 28, where the results include data associated with the first data element.
  • the interface module 28 further translates the results of the LISS query into a format that is intelligible to the PKB 24 as appropriate.
  • the interface module 28 provides the translated results to the PKB 24.
  • the PKB 24 upon receiving the results, applies the determined rules of compensation to the results data for compensating the data in order for the results data to be semantically interoperable with the second data element, for ensuring accurate processing by the execution engine 16 of the DSS 12.
  • the PKB 24 provides the semantically interoperable data to the executable engine 16, which the executable engine 16 may use for processing and/or for updating the evidence guideline storage system 14.
  • a flowchart 300 is provided showing steps performed during operation of the system 10, where the DSS 12 updates data stored in the LISS 26.
  • the PKB 24 receives an update request from the execution engine 16 to update a data element of the LISS 26 with data of a second data element, which is the data being exchanged.
  • the update request may request an update that corresponds to more than one first data element and/or more than one second data element, however for the purpose of clarity, the following explanation relates to the case of retrieving data corresponding to one first data element and one second data element.
  • the PKB 24 accesses a first data node that corresponds to the second data element.
  • the PKB 24 determines a second data node that is related to the first data node, and that correlates to a first data element stored by the LISS 26.
  • the PKB 24 determines at least one interoperability parameter defining how the first and second data elements correspond, which is indicated by the relationships between the first and second nodes. If the interoperability parameters have been stored and are available, instead of determining them, they are retrieved from storage.
  • the PKB 24 applies the determined rules of compensation to the data associated with the second data element for compensating the data in order for the data to be semantically interoperable with the first data element.
  • the PKB generates a LISS update request in accordance with the determined at least one relationship interoperability parameter for instructing the LISS 26 to update the first data element with the compensated data.
  • the at least one relationship interoperability parameter is used for locating the first data element and their corresponding elements in the LISS 26.
  • the interface module 28 translates the LISS update request into a format that is understood by the LISS 26 in accordance with conventions used by the LISS 26 for properly updating the first data element.
  • the LISS 26 updates the first data element with the appropriate compensated data.
  • the DSS 12 When developing the DSS 12, it is preferable to prepare the DSS 12 by using semantics conventions used by most available LISSs 26.
  • the PKB 24 When developing the PKB 24, it does not need to exhaustively replicate the LISS 26 which it is to be used with.
  • the PKB 24 is populated with knowledge in accordance with anticipated incompatibilities between the DSS 12 and a wide variety of LISSs 26. The universe of discourse of the PKB 24 needs to be large enough or expanded to accommodate the data it processes, e.g., data originating from the DSS 12 and data stored in the LISS 26 which correspond to the data originating in the DSS 12.
  • the PKB may be developed as it is being used. For example, upon detection of an interoperability problem that has not been successfully rectified, user intervention may be requested. If the user input is determined successful, the execution module 16, PKB 24 and/or interface module 28 of the system 10, as appropriate, may be updated with the suggested solution (permanently or temporarily) for future use. Alternatively, upon detection of a similar problem, an intelligent agent may be queried to provide a solution. The intelligent agent's recommended solution, if determined successful, may be used to update the system 10 as appropriate. It is further contemplated that an update to a system 10, such as described above, may be uploaded to a server which is connected to a plurality of systems 10. The update may be downloaded to systems 10 of the plurality of systems 10 that might be prone to encountering a similar interoperability problem. The uploading and downloading of updates may be automatic or supervised by system administrators of the respective systems.

Landscapes

  • Health & Medical Sciences (AREA)
  • Engineering & Computer Science (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)
  • Bioethics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

L'invention concerne un système et une méthode permettant d'échanger des données entre un système de stockage (26) d'informations locales stockant des premiers élément de données associés à des données respectives, et un système de support (12) de décision à directives exécutables sur au moins un processeur afin de stocker une pluralité de directives exécutables et de les exécuter, et de traiter au moins des données associées à un second élément de données. Ladite méthode consiste: à générer une demande d'échange de données entre le système d'informations locales et le système de support (12) de décision; à déterminer un premier élément de données d'une pluralité de premiers élément de données qui correspond au second élément de données, et au moins un paramètre d'interopérabilité définissant la manière dont les premier et second éléments de données correspondent; à traiter les données échangées en fonction du paramètre d'interopérabilité déterminé; et à transmettre les données échangées entre les premier et second éléments de données.
EP05776290A 2004-07-26 2005-07-21 Systeme et methode permettant de coupler des donnees de patient avec des systemes de support de decision a directives executables Ceased EP1774448A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US59107604P 2004-07-26 2004-07-26
PCT/IB2005/052447 WO2006013516A2 (fr) 2004-07-26 2005-07-21 Systeme et methode permettant de coupler des donnees de patient avec des systemes de support de decision a directives executables

Publications (1)

Publication Number Publication Date
EP1774448A2 true EP1774448A2 (fr) 2007-04-18

Family

ID=35355951

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05776290A Ceased EP1774448A2 (fr) 2004-07-26 2005-07-21 Systeme et methode permettant de coupler des donnees de patient avec des systemes de support de decision a directives executables

Country Status (4)

Country Link
EP (1) EP1774448A2 (fr)
JP (1) JP5475231B2 (fr)
CN (1) CN1989504B (fr)
WO (1) WO2006013516A2 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8527293B2 (en) 2007-03-30 2013-09-03 General Electric Company Method and system for supporting clinical decision-making
US20130117219A1 (en) * 2011-11-03 2013-05-09 Microsoft Corporation Architecture for knowledge-based data quality solution
US20140358570A1 (en) * 2013-06-04 2014-12-04 Koninklijke Philips N.V. Healthcare support system and method
EP3326054A4 (fr) * 2015-07-21 2019-03-27 The Arizona Board of Regents On Behalf of the University of Arizona Systèmes et procédés d'analyse de données de soins de santé

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH02267631A (ja) * 1989-04-07 1990-11-01 Fujitsu Ltd 決定木生成処理方式
JPH06168129A (ja) * 1992-11-30 1994-06-14 Mitsubishi Electric Corp 知識抽出装置
JPH0773038A (ja) * 1993-09-06 1995-03-17 Toshiba Corp 知識表現変換装置
US6163781A (en) * 1997-09-11 2000-12-19 Physician Weblink Technology Services, Inc. Object-to-relational data converter mapping attributes to object instance into relational tables
JP2003108377A (ja) * 2001-10-01 2003-04-11 Seiko Epson Corp 知識ルール変換装置、エキスパートシステム、知識ルール変換プログラムおよびエキスパートシステムの構築方法
JP4451037B2 (ja) * 2001-12-06 2010-04-14 株式会社ユニバーサルエンターテインメント 情報検索システム及び情報検索方法
US20040122787A1 (en) * 2002-12-18 2004-06-24 Avinash Gopal B. Enhanced computer-assisted medical data processing system and method
AU2003286345A1 (en) * 2002-12-19 2004-07-14 Koninklijke Philips Electronics N.V. Method and apparatus for selecting the operating parameters for a medical imaging system

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
HAO DING ET AL: "A vision on semantic retrieval in P2P network", ADVANCED INFORMATION NETWORKING AND APPLICATIONS, 2004. AINA 2004. 18T H INTERNATIONAL CONFERENCE ON FUKUOKA, JAPAN 29-31 MARCH 2004, PISCATAWAY, NJ, USA,IEEE, vol. 1, 29 March 2004 (2004-03-29), pages 177 - 182, XP010695414, ISBN: 978-0-7695-2051-3 *
S.W. TU AND M.A. MUSEN: "From guideline modeling to guideline execution: defining guideline-based decision-support services", 8 November 2000 (2000-11-08), pages 863 - 867, Retrieved from the Internet <URL:http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2243940/> [retrieved on 20130911] *
See also references of WO2006013516A2 *

Also Published As

Publication number Publication date
JP5475231B2 (ja) 2014-04-16
CN1989504B (zh) 2013-06-19
WO2006013516A2 (fr) 2006-02-09
JP2008507785A (ja) 2008-03-13
CN1989504A (zh) 2007-06-27
WO2006013516A3 (fr) 2006-04-06

Similar Documents

Publication Publication Date Title
US20080097791A1 (en) System and Method for Coupling Patient Data with Executable Guideline Decision Support System
US11410775B2 (en) Structured support of clinical healthcare professionals
Terenziani et al. A modular approach for representing and executing clinical guidelines
US6988088B1 (en) Systems and methods for adaptive medical decision support
US20140324457A1 (en) Integrated health care predicting system
US20070130206A1 (en) System and Method For Integrating Heterogeneous Biomedical Information
US20140214451A1 (en) Adaptive Medical Documentation System
US10490306B2 (en) Medical information translation system
EP1996069A2 (fr) Affichage et procédé pour la sélection d&#39;une procédure médicale
US20200058408A1 (en) Systems, methods, and apparatus for linking family electronic medical records and prediction of medical conditions and health management
US11710572B2 (en) Experience engine-method and apparatus of learning from similar patients
Miller et al. OptiPres: a distributed mobile agent decision support system for optimal patient drug prescription
Zhang et al. Computable eligibility criteria through ontology-driven data access: a case study of hepatitis C virus trials
US20090276240A1 (en) Patient Problem Data Structure and Processing System
Gaebel et al. Accessing patient information for probabilistic patient models using existing standards
US20240145054A1 (en) Ontological Standards Based Approach To Charting Utilizing A Generic Concept Content Based Framework Across Multiple Localized Proprietary Domains
EP1774448A2 (fr) Systeme et methode permettant de coupler des donnees de patient avec des systemes de support de decision a directives executables
Bilykh et al. Using the clinical document architecture as open data exchange format for interfacing EMRs with clinical decision support systems
EP3659150B1 (fr) Dispositif, système et procédé pour optimiser le flux de production d&#39;acquisition d&#39;images
JP2018514862A (ja) オンデマンドリアルタイム患者固有データ解析計算プラットフォームを提供するシステムおよび方法
KR20230076936A (ko) 의료 정보 분석 시스템이 업데이트에 따른 인허가 필요성을 판단하는 방법
Li et al. Artificial Intelligence in Evidence-based Medicine: Challenges and Opportunities
Jamil et al. Empowering patients with hipaa aware personal health libraries
US20150066522A1 (en) Systems and Methods of Generating Patient Notes with Inherited Preferences
US20240331816A1 (en) Code generator for accessing differing health record systems

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20070226

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

R17P Request for examination filed (corrected)

Effective date: 20070226

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20080828

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: KONINKLIJKE PHILIPS N.V.

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20161118