US20120215560A1 - System and methods for facilitating computerized interactions with emrs - Google Patents

System and methods for facilitating computerized interactions with emrs Download PDF

Info

Publication number
US20120215560A1
US20120215560A1 US13/208,417 US201113208417A US2012215560A1 US 20120215560 A1 US20120215560 A1 US 20120215560A1 US 201113208417 A US201113208417 A US 201113208417A US 2012215560 A1 US2012215560 A1 US 2012215560A1
Authority
US
United States
Prior art keywords
emr
information
patient
individual
context
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.)
Abandoned
Application number
US13/208,417
Inventor
Ziv Ofek
Shiri Ben-Tal
Yuri Ackerman
Yehonatan Mazar
Yinon Zohar
Dmitry Sigalov
Ohad Young
Ziv Gome
Boris Giterman
David Boaz
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.)
dbMotion Ltd
Allscripts Software LLC
Original Assignee
dbMotion Ltd
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
Priority claimed from US12/840,806 external-priority patent/US20110288877A1/en
Priority to US13/208,417 priority Critical patent/US20120215560A1/en
Application filed by dbMotion Ltd filed Critical dbMotion Ltd
Assigned to dbMotion Ltd. reassignment dbMotion Ltd. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: GOME, ZIV, SIGALOV, DMITRY, BEN-TAL, SHIRI, BOAZ, DAVID, GITERMAN, BORIS, MAZAR, YEHONATAN, OFEK, ZIV, YOUNG, OHAD, ACKERMAN, YURI, ZOHAR, YINON
Publication of US20120215560A1 publication Critical patent/US20120215560A1/en
Priority to US14/145,903 priority patent/US10325335B1/en
Priority to US14/145,906 priority patent/US10733684B1/en
Priority to US14/145,908 priority patent/US10789662B1/en
Priority to US14/145,904 priority patent/US10297343B1/en
Priority to US14/145,905 priority patent/US10755802B1/en
Assigned to dbMotion Ltd. reassignment dbMotion Ltd. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: GOME, ZIV, BEN-TAL, SHIRI, OFEK, ZIV, WARTENFELD, ROBERT, GREENBERG, EYAL
Assigned to ALLSCRIPTS SOFTWARE, LLC reassignment ALLSCRIPTS SOFTWARE, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: GREENBERG, EYAL
Priority to US15/648,096 priority patent/US10726088B1/en
Priority to US16/391,371 priority patent/US11636928B1/en
Priority to US16/443,843 priority patent/US11380426B1/en
Abandoned legal-status Critical Current

Links

Images

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
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/22—Social work
    • 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
    • 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
    • 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
    • G16H15/00—ICT specially adapted for medical reports, e.g. generation or transmission thereof
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/40—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management of medical equipment or devices, e.g. scheduling maintenance or upgrades
    • 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
    • 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

Definitions

  • the present invention relates generally to systems for processing medical information and more particularly to computerized interactions with EMRs.
  • an EMR may know how to import lab results from an HIES.
  • An EMR may provide a tab in its main application, sometimes known as the “community tab” which enables a user to view, but not manipulate or import, HIE-provided information about a patient. Varying medical technology between the HIE and EMR, combined with a lack of ability to semantically resolve the variation, may impose limitations to these modes of information transfer.
  • an Enterprise Master Patient Index is “a form of customer data integration (CDI) specific to the healthcare industry. Healthcare organizations or groups of them will implement EMPI to identify, match, merge, de-duplicate, and cleanse patient records to create a master index that may be used to obtain a complete and single view of a patient.
  • the EMPI will create a unique identifier for each patient and maintain a mapping to the identifiers used in each record's respective system.” It has been claimed that by using an EMPI for “correctly matching patient records from disparate systems and different organizations”, it is possible to obtain “a complete view of a patient”.
  • CMOS complementary metal-oxide-semiconductor
  • CMOS complementary metal-oxide-semiconductor
  • Non-Patent Literature describing health information exchange through the use of semantic technology includes:
  • Certain embodiments of the present invention seek to provide a technical solution for the problem of allowing medical data to be effectively retrieved, stored, and presented to medical service providing users where the medical data exists in digital form within a plethora of non-compatible, partially overlapping software systems which are constantly being updated.
  • Certain embodiments of the present invention seek to provide an interoperability solution for medical databases, providing a health information exchange system typically storing complete, single and harmonized patient records, and easing access thereto by bringing relevant information to a user at points in time in which that information is useful and as part of her or his workflows.
  • Certain embodiments of the present invention seek to bring relevant context-based information from inside the health information exchange system to a user e.g. physician's working environment and workflows (typically EMR), rather having the physician leave his working environment and search for the information he needs in a Clinical Viewer as an external application.
  • a user e.g. physician's working environment and workflows (typically EMR), rather having the physician leave his working environment and search for the information he needs in a Clinical Viewer as an external application.
  • Certain embodiments of the present invention seek to enhance effective software compatibility including reducing dependency on EMR vendors to customize their software products in order to integrate with the health information exchange system platform (Button, Smart Access, and other services).
  • Certain embodiments of the present invention seek to provide easy and efficient access to specific context-based patient information eliminating the need to navigate through many patient's views in an external application.
  • HIE Health Information Exchange
  • HIE Health Information Exchange
  • EMR Electronic medical Records
  • HIE provides the capability to electronically move clinical information among disparate health care information systems while maintaining the meaning of the information being exchanged.
  • the goal of HIE is to facilitate access to and retrieval of clinical data to provide safer, more timely, efficient, effective, equitable, patient-centered care.
  • HIE providers develop computerized infrastructures and applications that enable the information exchange and viewing of exchanged information.
  • HIE solutions complement the EMR applications, the EMR and HIE vendors are looking for ways to integrate with each other in order to enable:
  • Certain embodiments of the present invention seek to provide an SOA-based platform that enables healthcare organizations and health information exchanges (HIEs) to integrate their information assets, through the creation of a virtual patient record by logically connecting a group of care providers and organizations without requiring the replacement of existing information systems.
  • HIEs health information exchanges
  • a single, virtual patient record contains complete and harmonized patient data by logically connecting a group of care providers and organizations without requiring the replacement of existing information systems. Smooth and easy access to the care-critical information stored in the HIE should be facilitated, by providing a user with relevant patient information at the point in time it is needed, as part of the clinical workflow.
  • the SmartAgent is a client application that is designed to meet the EMR users' need to get comprehensive and relevant clinical information on patients from sources of information which are not in their EMR, and in addition to serve as a gateway to HIE applications and solutions.
  • the client application typically installed on the user's machine, is termed herein a SmartAgent client.
  • Examples of use scenarios include but are not limited to the following:
  • Smart Button within User, Patient and System Context User opens a patient record in his EMR. SmartAgent, which is installed in his client machine, “captures” the patient identifier (MRN), the User Context (Username/Role) and the System context (SystemID) and calls a VPO Analyzer web service or Virtual Patient Object Clinical Data Web Service) that identifies the System, user and the patient. The user is authorized and the patient is found in the health information exchange system.
  • the Client SmartAgent gets the response and presents a Floating Button.
  • the Floating button includes Link to Launch Viewer with user and patient context. The User presses the button and seamlessly accesses the health information exchange system's Clinical Viewer. 2.
  • VPO Analyzer attention rules In order to bring more relevant information to the user, smart evaluations are typically provided on the VPO in the context of the user, patient and system.
  • One of the Analyzer's attention rules may be “Exclude System Data” which excludes from the VPO Data that exists in the physician's own system.
  • the response is “Clean” data excluding what a user can see in his EMR, which may be presented within the Results or Viewer Panes.
  • the rule is typically constructed and operative to analyze the patient's clinical data and to alert the user in the SmartAgent client application that information that meets the rule exists and is available for viewing.
  • Semantic Search A user may for example be looking for data on Diabetes in the health information exchange system.
  • the clinical aspects and actual presented data may constitute a link to a relevant page in the health information exchange system's Clinical Viewer.
  • the user can see under a Laboratory Results menu, a result for hbA1c from, say, a previous week. Aside from the result, 2 buttons may be provided, one to open the Laboratory Clinical View and another to open the Lab Result Page with the hbA1c history.
  • b. A system according to embodiment a wherein the user's work environment includes at least one EMR.
  • c. A system according to embodiment b which does not require customization of the EMR.
  • d. A system according to embodiment ‘a’ which supplies information without requiring the user to navigate through multiple clinical views in an external application.
  • e. A system according to embodiment ‘a’ wherein the system includes a proactive apparatus which operates proactively, responsive to user context operations, to present relevant clinical information.
  • a system wherein the system includes a processor operative to select relevant information including performing a computerized analysis of a computerized patient record and deriving, from the analysis, relevant clinical information which is presented to the user, whereas other clinical information is not presented to the user.
  • a system operative to select relevant information including performing a computerized analysis of a computerized patient record and deriving, from the analysis, relevant clinical information which is presented to the user, whereas other clinical information is not presented to the user.
  • a system f’ wherein differentiation of relevant clinical information from other clinical information is based on at least one of the following: user context, profile, patient illness, ward context, EMR Workflow Context.
  • h A system according to embodiment ‘a’ and wherein the system is operative to provide information, within the workflow, on overall patient events and evaluations for each individual physician or user.
  • i A system according to embodiment ‘a’ and also comprising at least some aspects of a skin application shown and described herein.
  • a computerized method for supplying a human user with relevant, context-based patient information within the user's work environment and workflows k.
  • m. A method according to embodiment T which supplies information without requiring the user to navigate through multiple clinical views in an external application.
  • n. A method according to embodiment T wherein the method includes a proactive apparatus which operates proactively, responsive to user context operations, to present relevant clinical information.
  • a method according to embodiment T wherein the method includes a processor operative to select relevant information including performing a computerized analysis of a computerized patient record and deriving, from the analysis, relevant clinical information which is presented to the user, whereas other clinical information is not presented to the user.
  • p A method according to embodiment ‘o’ wherein differentiation of relevant clinical information from other clinical information is based on at least one of the following: user context, profile, patient illness, ward context, EMR Workflow Context.
  • q A method according to embodiment ‘a’ and wherein the system is operative to provide information, within the workflow, on overall patient events and evaluations for each individual physician or user.
  • s A computer program product, comprising a computer usable medium having a computer readable program code embodied therein, the computer readable program code adapted to be executed to implement any of the methods shown and described herein.
  • Certain embodiments of the present invention seek to provide a decision making system including a system of logic including hierarchical semantic relationships, a plurality of systems of medical information which are provided in a plurality of local terminologies respectively, and a decision making apparatus for transforming the medical information in the local terminologies to transformed information usable by the system of logic and for using the system of logic to make at least one decision based on the transformed information, without translating the system of logic into the plurality of local terminologies.
  • the term “terminology” is intended to include any scheme for representing medical information. The following terms and other terms defined herein may be construed either in accordance with any definition thereof appearing in the prior art literature or in accordance with the specification, or as follows:
  • Classification Type A base set of classifications which all others derive from. The existing classifications are:
  • DEM data event monitor e.g. as described herein
  • VIA a commercial Virtual Identity Aggregation service provided by DBMotion Inc., Israel
  • ACEI angiotensin-converting enzyme inhibitor
  • DBMotion refers to a functionality which is either commercially available from DBMotion Inc., Israel and/or is shown and described herein. Other definitions, acronyms, and abbreviations useful in understanding certain embodiments of the present invention, are provided in the table of FIG. 2 .
  • a health information exchange system comprising an apparatus for archiving health information using a health information encoding procedure only if the health information fulfills a criterion of frequent use; and an apparatus for using a first procedure to respond to queries pertaining to the health information which fulfills the criterion of frequent use and using a second procedure to respond to queries not pertaining to the health information which fulfills the criterion of frequent use.
  • a health information exchange system comprising an ontological apparatus for defining and storing ontological link elements ontologically linking between individual health care information items within a first population of health care information items; an apparatus for receiving a second population of health care information items and for associating at least some individual items in the second population, with corresponding individual items within the first population of health care information items; and an apparatus for responding to queries regarding particular information items in the second population including translating the particular information items into items in the first population corresponding to the particular information items and using link elements linking the items in the first population corresponding to the particular information items to generate data pertaining to the particular information items in the second population.
  • a system comprising an apparatus for making at least one health decision based on the queries.
  • a system also comprising apparatus for implementing the at least one health decision.
  • a system also comprising apparatus for making at least one health decision based on the queries.
  • a system also comprising apparatus for implementing the at least one health decision.
  • a health information exchange method comprising archiving health information using a health information encoding procedure only if the health information fulfills a criterion of frequent use; and using a first procedure to respond to queries pertaining to the health information which fulfills the criterion of frequent use and using a second procedure to respond to queries not pertaining to the health information which fulfills the criterion of frequent use.
  • a health information exchange method comprising defining and storing link elements linking between individual health care information items within a first population of health care information items; receiving a second population of health care information items and associating at least some individual items in the second population, with corresponding individual items within the first population of health care information items; and responding to queries regarding particular information items in the second population including translating the particular information items into items in the first population corresponding to the particular information items and using link elements linking the items in the first population corresponding to the particular information items to generate data pertaining to the particular information items in the second population.
  • a method also comprising making at least one health decision based on the queries.
  • a method also comprising implementing the at least one health decision.
  • a method also comprising making at least one health decision based on the queries.
  • a method also comprising implementing the at least one health decision.
  • a computer program product comprising a computer usable medium having a computer readable program code embodied therein, the computer readable program code adapted to be executed to implement a health information exchange method comprising archiving health information using a health information encoding procedure only if the health information fulfills a criterion of frequent use; and using a first procedure to respond to queries pertaining to the health information which fulfills the criterion of frequent use and using a second procedure to respond to queries not pertaining to the health information which fulfills the criterion of frequent use.
  • a computer program product comprising a computer usable medium having a computer readable program code embodied therein, the computer readable program code adapted to be executed to implement a health information exchange method comprising defining and storing link elements linking between individual health care information items within a first population of health care information items; receiving a second population of health care information items and for associating at least some individual items in the second population, with corresponding individual items within the first population of health care information items; and responding to queries regarding particular information items in the second population including translating the particular information items into items in the first population corresponding to the particular information items and using link elements linking the items in the first population corresponding to the particular information items to generate data pertaining to the particular information items in the second population.
  • a computer program product wherein the method also comprises making at least one health decision based on the queries.
  • a computer program product wherein the method also comprises implementing the at least one health decision.
  • a computer program product wherein the method also comprises making at least one health decision based on the queries.
  • a computer program product wherein the method also comprises implementing the at least one health decision.
  • the baseline terminology is semantically enriched by associating semantic information therewith, the method also comprising generating conclusions about health information expressed in at least one local terminology by using the semantic information rather than by defining semantic relations for the local terminology.
  • the apparatus for responding to queries uses a first procedure to respond to queries pertaining to the subset and uses a second procedure to respond to queries not pertaining to the universe of health information but not pertaining to the subset.
  • a system also including an end user interface allowing end users to define rules; and a decision support subsystem (DSS) interacting with the end user interface and using semantic capabilities of a baseline terminology in which the first population of health information items is encoded, to simplify definition of rules by the end users.
  • DSS decision support subsystem
  • the decision support subsystem comprises an Enterprise DSS which has a process cycle and which uses DSS rules to define all phases in the process cycle.
  • a method wherein the translating and the using is applied to a use case involving a SmartWatch System, the use case including at least one of processing and monitoring health of the system.
  • the health information encoding procedure includes mapping health information expressed in at least one local terminology to a baseline terminology to enable terminology interoperability and storing ontological information interrelating health information items expressed in the baseline terminology.
  • the ontological apparatus includes interrelationships between clinical-level information items.
  • the clinical-level information item comprises at least one health care information item specifying at least one of a disease, rather than only a class thereof, and a medication, rather than only a class thereof, such as “Left Ventricular Heart Failure”, rather than “Cardio-vascular disorder”, and “Amoxicillin 250 MG Oral Capsule [Amoxymed]”, rather than “Antibiotic”, respectively.
  • the ontological apparatus maps at least one legacy concept expressed in local terminology to at least one ontology concept expressed in a baseline terminology thereby allowing queries on the level of a single legacy concept to be responded to, for example, the following legacy concept: (System: ICD9, Code: 428.9, Designation: HEART FAILURE NOS) may be mapped to the following Ontology concept: (System: SNOMED-CT; Code: 84114007; Designation: Heart failure (disorder). Very generic examples of classifications are “Disorder”, “Medicine”, “Procedure”; more specific classification examples are “Cardio-vascular disorder”, “Antibiotics” etc.
  • Classifications do not identify a patient's clinical status; for example, it is not enough to say in a clinical record that the patient has “Cardio-vascular disorder” as there are many types of such disorders, and it is typically useful to know which disorder the patient suffers from, to decide how to treat it.
  • Examples of clinical-level information items are “Left Ventricular Heart Failure”, “Amoxicillin 250 MG Oral Capsule [Amoxymed]”; these information items are sufficiently detailed to describe aspects of an individual patient's clinical status and/or treatment rather than mere classifications thereof.
  • a computer program product comprising a typically non-transitory computer usable medium or computer readable storage medium, typically tangible, having a computer readable program code embodied therein, said computer readable program code adapted to be executed to implement any or all of the methods shown and described herein. It is appreciated that any or all of the computational steps shown and described herein may be computer-implemented. The operations in accordance with the teachings herein may be performed by a computer specially constructed for the desired purposes or by a general purpose computer specially configured for the desired purpose by a computer program stored in a typically non-transitory computer readable storage medium.
  • Any suitable processor, display and input means may be used to process, display e.g. on a computer screen or other computer output device, store, and accept information such as information used by or generated by any of the methods and apparatus shown and described herein; the above processor, display and input means including computer programs, in accordance with some or all of the embodiments of the present invention.
  • processors workstation or other programmable device or computer or electronic computing device, either general-purpose or specifically constructed, used for processing; a computer display screen and/or printer and/or speaker for displaying; machine-readable memory such as optical disks, CDROMs, magnetic-optical discs or other discs; RAMs, ROMs, EPROMs, EEPROMs, magnetic or optical or other cards, for storing, and keyboard or mouse for accepting.
  • processor includes a single processing unit or a plurality of distributed or remote such units.
  • the above devices may communicate via any conventional wired or wireless digital communication means, e.g. via a wired or cellular telephone network or a computer network such as the Internet.
  • the apparatus of the present invention may include, according to certain embodiments of the invention, machine readable memory containing or otherwise storing a program of instructions which, when executed by the machine, implements some or all of the apparatus, methods, features and functionalities of the invention shown and described herein.
  • the apparatus of the present invention may include, according to certain embodiments of the invention, a program as above which may be written in any conventional programming language, and optionally a machine for executing the program such as but not limited to a general purpose computer which may optionally be configured or activated in accordance with the teachings of the present invention. Any of the teachings incorporated herein may wherever suitable operate on signals representative of physical objects or substances.
  • the term “computer” should be broadly construed to cover any kind of electronic device with data processing capabilities, including, by way of non-limiting example, personal computers, servers, computing system, communication devices, processors (e.g. digital signal processor (DSP), microcontrollers, field programmable gate array (FPGA), application specific integrated circuit (ASIC), etc.) and other electronic computing devices.
  • processors e.g. digital signal processor (DSP), microcontrollers, field programmable gate array (FPGA), application specific integrated circuit (ASIC), etc.
  • DSP digital signal processor
  • FPGA field programmable gate array
  • ASIC application specific integrated circuit
  • Any suitable input device such as but not limited to a sensor, may be used to generate or otherwise provide information received by the apparatus and methods shown and described herein.
  • Any suitable output device or display may be used to display or output information generated by the apparatus and methods shown and described herein.
  • Any suitable processor may be employed to compute or generate information as described herein e.g. by providing one or more modules in the processor to perform functionalities described herein.
  • Any suitable computerized data storage e.g. computer memory may be used to store information received by or generated by the systems shown and described herein.
  • Functionalities shown and described herein may be divided between a server computer and a plurality of client computers. These or any other computerized components shown and described herein may communicate between themselves via a suitable computer network.
  • FIG. 1A is a simplified functional block diagram illustration of a health information exchange and integration system constructed and operative in accordance with certain embodiments of the present invention.
  • FIG. 1B is a table of sequence interaction descriptions useful in understanding the operation of the system of FIG. 1A according to certain embodiments of the present invention.
  • FIGS. 2 and 3 are a table and a diagram useful in understanding an embodiment of the CTS sub-system of FIG. 1A , a knowledge framework sub-system and a smart-watch sub-system, which interact with a core platform for processing medical information, such as the core platform product available from DBMotion Inc., Israel.
  • FIGS. 4A-8C are diagrams and other illustrations useful in understanding an embodiment of the knowledge framework sub-system of FIG. 1A .
  • FIGS. 14-17 are diagrams and other illustrations useful in understanding an embodiment of the Smart-watch sub-system of FIG. 1A .
  • FIGS. 18A-137 are diagrams and other illustrations which, particularly in conjunction with FIGS. 9-13 , are useful in understanding an example health information exchange and integration system constructed and operative in accordance with certain embodiments of the present invention. Specifically:
  • FIGS. 18A-105 are diagrams and other illustrations useful in understanding an example implementation of the CTS sub-unit of FIG. 1A .
  • FIGS. 106A-137 are diagrams and other illustrations useful in understanding an example implementation of the smart-watch sub-unit of FIG. 1A . Specifically:
  • FIG. 106A is a simplified functional block diagram illustration of the smart-watch sub-unit constructed and operative to certain embodiments of the present invention.
  • FIG. 106B is a table describing operations, some or all of which may be performed by the system of FIG. 106A .
  • FIGS. 106C-114 are diagrams and other illustrations useful in understanding an example implementation of the smart-watch service unit of FIG. 106A .
  • FIGS. 115-123 are diagrams and other illustrations useful in understanding an example implementation of the data event monitor of FIG. 106A .
  • FIGS. 124-130 are diagrams and other illustrations useful in understanding an example implementation of the person identity service of FIG. 106A .
  • FIGS. 131-134 are diagrams and other illustrations useful in understanding an example implementation of the temporal monitor of FIG. 106A .
  • FIGS. 135-137 are diagrams and other illustrations useful in understanding an example implementation of the action manager of FIG. 106A .
  • FIG. 138 is a SmartWatch-wide high level use case diagram of SmartWatchService use cases and their associated actors provided in accordance with certain embodiments of the present invention.
  • FIG. 139 is a use-case focused diagram of the smart watch service illustrating SmartWatchService use cases provided in accordance with certain embodiments of the present invention.
  • FIG. 140 is a diagram of an example Knowledge-Module Entities Model from which a knowledge base repository for the KFW sub-system of FIG. 1A may be derived.
  • FIG. 141 is a table of typically conventional ontological relationships serving as an example of semantic relationships which may be used by the CTS subsystem of FIG. 1A .
  • FIG. 142 is an example of a pattern rule comprising a subscription snippet, in XML format.
  • FIG. 143 is an example of a pattern rule comprising a definition snippet, in XML format.
  • FIGS. 144A-153 are diagrams and other illustrations useful in understanding an example Enterprise Clinical Decision Support System which may utilize the SmartWatch subunit of FIG. 1A .
  • FIGS. 144A-153 are diagrams and other illustrations useful in understanding an example Enterprise Clinical Decision Support System which may utilize the SmartWatch subunit of FIG. 1A .
  • FIGS. 144A-153 are diagrams and other illustrations useful in understanding an example Enterprise Clinical Decision Support System which may utilize the SmartWatch subunit of FIG. 1A .
  • FIGS. 144A-153 are diagrams and other illustrations useful in understanding an example Enterprise Clinical Decision Support System which may utilize the SmartWatch subunit of FIG. 1A .
  • FIGS. 144A-153 are diagrams and other illustrations useful in understanding an example Enterprise Clinical Decision Support System which may utilize the SmartWatch subunit of FIG. 1A .
  • FIGS. 144A-153 are diagrams and other illustrations useful in understanding an example Enterprise Clinical Decision Support System which may utilize the SmartWatch subunit of FIG. 1A .
  • FIGS. 144A-144C illustrate an example HF (heart failure) patients classification including triggering rules and other characteristics for entry and exit tasks.
  • FIGS. 145A-145D illustrate example admitted HF patient sub-classifications, including triggering rules and other characteristics for entry and exit tasks.
  • FIGS. 146A-146B illustrate an example of an LVS function evaluation method, including triggering rules and other characteristics for a monitoring task.
  • FIGS. 147-150 illustrate an example ACEI or ARB for LVSD.
  • FIGS. 151-152B illustrate an example sub-classification for temp discharged HF patients including triggering rules and other characteristics for entry and exit tasks.
  • FIG. 153 is a table of Example vocabulary codes useful in the system of FIGS. 144A-152 b.
  • FIG. 154 a is a simplified functional block diagram of a high level architecture of a smart agent system constructed and operative in accordance with certain embodiments of the present invention.
  • FIG. 154 b is a table summarizing an example set of functional requirements of a content/VPO analyzer included in the apparatus shown and described herein.
  • FIG. 154 c is a table summarizing an example set of functional requirements of a content capturing and sharing functionality included in the apparatus shown and described herein.
  • FIG. 154 d is a table summarizing an example set of functional requirements of a semantic search functionality included in the apparatus shown and described herein.
  • FIG. 154 e is a table summarizing an example set of functional requirements of a floating application included in the apparatus shown and described herein.
  • FIG. 155 a is a table summarizing an example set of non-functional auditing, security and localization requirements of apparatus shown and described herein.
  • FIG. 155 b is a table summarizing an example set of non-functional topological and pre-requisite requirements of the apparatus shown and described herein.
  • FIG. 155 c is a table summarizing an example set of non-functional performance requirements of apparatus shown and described herein.
  • FIG. 155 d is a table summarizing an example set of non-functional reusability and integrability requirements of the apparatus shown and described herein.
  • FIG. 156 a is an example user interface useful in entering a patient file and launching the SmartAgent system provided according to certain embodiments of the present invention, including an example of how a smart agent may position itself vis a vis an E.H.R. according to certain embodiments.
  • FIG. 156 b is a simplified pictorial illustration of an example user interface for a FloatingClosed functionality
  • FIG. 156 c is an example object table useful in understanding the functionality of the user interface of FIG. 156 b.
  • FIG. 156 d is a simplified pictorial illustration of an example user interface for a FloatingSearchOpen functionality.
  • FIG. 157 a illustrates the SmartAgent application, according to certain embodiments of the present invention, hovering on top of an example EMR (Allscripts Sunrise—commercially available EMR) in an expanded mode, e.g. by presenting the smart agent's clinical data on top of the EMR e.g. as described herein with reference to FIGS. 156 a - 156 c.
  • EMR Allscripts Sunrise—commercially available EMR
  • FIG. 157 b is an enlarged view of the expanded SmartAgent panel, according to certain embodiments of the present invention.
  • FIG. 157 c is an example object table useful in understanding the functionality of the user interface of FIG. 157 b.
  • FIG. 157 d is an example Object Table.
  • FIG. 158 is an example user interface for a laboratory screenshot of a preview panel useful in accordance with certain embodiments of the present invention.
  • FIG. 159 a is a simplified pictorial illustration of an example method for highlighting of the background of a patient's name field.
  • FIG. 159 b is a table presenting an example set of basic rules.
  • FIG. 159 c is a table presenting an example set of rule combinations.
  • FIG. 160 a is a table of an example set of presentation use cases.
  • FIG. 160 b is a table of an example set of context interception use cases.
  • FIG. 160 c is a table of an example set of system health use cases.
  • FIG. 160 d is a table of an example set of data preparation, configuration & deployment, and extension development use cases.
  • FIG. 161 illustrates an Interaction example—User context interception sequence, in Enterprise Architect UML format.
  • FIGS. 162 , 163 a - 163 c , 164 - 166 present an example use case model useful in conjunction with the system of FIG. 154 a.
  • FIG. 165 is an example table suitable for storing a timestamp per user and per patient according to certain embodiments.
  • FIG. 168 is a diagram of an example Design Model of a smart agent constructed and operative in accordance with certain embodiments of the present invention.
  • FIG. 169 is a logical diagram of the smart agent of FIG. 168 according to certain embodiments.
  • FIG. 170 is a logical diagram of the context entities of FIG. 169 according to certain embodiments.
  • FIG. 171 is a logical diagram of the ScreenCapturing functionality of FIG. 169 according to certain embodiments.
  • FIG. 172 is a pictorial diagram of a medical domain comprising an interconnected network of entities according to certain embodiments.
  • FIG. 173 is a table of the InterceptionEventDispatcher's operations according to certain embodiments.
  • FIG. 174 is a Logical diagram of controllers according to certain embodiments.
  • FIG. 175 is a table of Operations, some or all of which may be performed by the InterceptorsFactory functionality of FIG. 174 .
  • FIG. 176 is a logical diagram of Context Interception functionality provided according to certain embodiments.
  • FIG. 177 is a diagram of example Framework and Contracts pertaining to the VPOAnalyzer of FIG. 154 a.
  • FIG. 178 is an example Logical diagram for the SystemIdentity functionality of FIG. 177 .
  • FIG. 179 is a logical diagram of Service & business layers provided according to certain embodiments.
  • FIG. 180 is an example logical diagram of the rules functionality of FIG. 179 .
  • FIG. 181 is an Identify Patient UC (use case) realization sequence diagram illustrating an example Use Case (UC) Realization process.
  • FIG. 182 is a sequence diagram of an example server operative to identify patient UC realization.
  • FIG. 183 is a top-level simplified flowchart illustration of a method of operation for the smart agent system of FIG. 154 a , according to an embodiment of the present invention.
  • FIG. 184 is a pictorial diagram showing parameters useful for defining EMR Agent shell window position relative to EMR application window according to certain embodiments.
  • FIG. 185 a is a table of example origins of Baseline Ontology Terminology Components in an example HIE according to certain embodiments.
  • FIG. 185 b is a table of Terminology Maps that map between Local Terminologies according to certain embodiments.
  • FIG. 186 is a simplified functional block diagram illustration of an embodiment of the invention showing a smart agent which may be constructed and operative in accordance with any of the embodiments shown and described herein.
  • FIG. 187 is a diagram illustration of an example CCOW context Interceptor according to certain embodiments.
  • FIG. 188 is a diagram illustrating filtering of clinical information whose source of information is a given EMR according to certain embodiments.
  • Computational components described and illustrated herein can be implemented in various forms, for example, as hardware circuits such as but not limited to custom VLSI circuits or gate arrays or programmable hardware devices such as but not limited to FPGAs, or as software program code stored on at least one intangible computer readable medium and executable by at least one processor, or any suitable combination thereof.
  • a specific functional component may be formed by one particular sequence of software code, or by a plurality of such, which collectively act or behave or act as described herein with reference to the functional component in question.
  • the component may be distributed over several code sequences such as but not limited to objects, procedures, functions, routines and programs and may originate from several computer files which typically operate synergistically.
  • Data can be stored on one or more intangible computer readable media stored at one or more different locations, different network nodes or different storage devices at a single node or location.
  • Suitable computer data storage or information retention apparatus may include apparatus which is primary, secondary, tertiary or off-line; which is of any type or level or amount or category of volatility, differentiation, mutability, accessibility, addressability, capacity, performance and energy use; and which is based on any suitable technologies such as semiconductor, magnetic, optical, paper and others.
  • E.H.R, EMR In the present specification and claims, these are used generally interchangeably in that any reference to one might also refer to the other, mutatis mutandis.
  • a repository of computerized health/medical data including a multiplicity of patient records and an interface allowing a user e.g. physician to access such data and, typically, manipulate such data.
  • HIE health information exchange (HIE) system such as DBMotion's HIES, typically including computerized apparatus accepting and storing information from, and providing information to, a plurality of EMRs.
  • HIE health information exchange
  • Context includes information which may be shared by or derived from a computerized system such as an EMR. This information may include who is operating the (e.g.) EMR (user context), who is the patient whose data is currently being processed/displayed by the EMR (patient context) and what operation (e.g. prescription, referral, other) the user is currently performing.
  • Context interception obtaining, for a first computerized system such as a HIES, context from a second computerized system such as an EMR, e.g. by sharing or deriving, typically including a determination of how the information from the second computerized system is to be used or related to by the first computerized system.
  • Example of context interception provided according to certain embodiments of the present invention:
  • the smart agent may retrieve the patient identifier e.g. by first recognizing the EMR page through which the patient user accesses the medical records and then, e.g. using prior knowledge re the location of the patient identifier on that page, capturing the user identifier.
  • Business rule or business layer As defined in Wikipedia, this term of the art simply refers to a computerized processing rule or layer of computerized processing respectively and does not have any financial connotation whatever.
  • Mrn patient ID e.g. Medical record number.
  • EMR electronic medical record
  • a computerized output device for providing patient record data, pertaining to said individual patient, to said health provider.
  • Context sharing used by Healthcare systems such as EMR and HIE solution's Context Interception processes are used commonly in the healthcare industry in order to insure synchronization for the clinical data presented for a given provider.
  • the context is commonly referred to a healthcare system (such as HIE or EMR)
  • patient and user identifiers are intercepted by the HIE or EMR and are used to authenticate and authorize to user by given user context, to resolve the patient by the given patient identifiers, and to enable an automation of opening the patient file in the EMR.
  • FIG. 186 is a diagram of an example component model, as well as in FIGS. 161 , 166 - 167 , 170 , 174 , 176 .
  • said patient record data includes at least one information item which is tagged to indicate a source EMR which provided said information item to said health information exchange system and wherein said patient record data provided to said health provider is filtered so as to filter out said at least one information item if said information item's source EMR equals said individual EMR.
  • An HIE system may be built to aggregate a patient's clinical information from various sources (such as EMRs, lab systems, radiology systems, etc.), in order to enable a provider to view a complete set of clinical information on a given patient at the point of care.
  • the clinical data aggregated into the HIE may additionally include Metadata that enables unique identification of the source system of each specific clinical data element (e.g. specific lab test done for a given patient, or prescribed medication).
  • the HIE may enable the clinical data web services to get as an input the EMR identifier which can be retrieved by the computerized context interception process described above.
  • the response of the web service then typically excludes the EMR data.
  • the HIE has the metadata of the given EMR which includes the source system identifier, in which case the clinical data service is able to exclude this EMR information, e.g. as described below with reference to FIGS. 154 a and 177 .
  • a method according to embodiment 1 wherein said intercepting and identifying includes using a context management protocol.
  • the Common Context Management protocol in the healthcare industry refers to HL7 CCOW.
  • a SmartAgent CCOW Context interceptor is typically provided which is operative to register to a given CCOW Context Manager (e.g. Sentillion) and get synchronized with the context the Context Manager receives from other EMR or clinical systems register to the Context Manager.
  • the methods for context interception from a context manager may include some or all of the following HL7 CCOW standard operations: Join context, Leave context, Follow context, Handle context termination and Handle “ping” request.
  • FIG. 176 An example architecture of the SmartAgent CCOW context Interceptor is illustrated in FIG. 176 .
  • a diagram illustration of an example CCOW context Interceptor is provided in FIG. 187 .
  • the Endpoints in the mid area of FIG. 187 are optional SmartAgent Context intercepors, which may be an integral part of the SmartAgent Client of FIGS. 154 a and 176 .
  • a method according to embodiment 1 wherein said identifying includes:
  • Suitable methods for capturing information from said display screen are known e.g. in Windows operating systems which provide native API for elements displayed in the screen such as Windows, UI controls, and text within these controls. Additional available computerized solutions such as ScreenScraping Studio, described online at the following http location: screen-scraper.deskperience.com, capture elements from the screen in various different ways. Screen Scrapping tools such as Screen Scrapping studio, enable stating of a location within a screen or in correlation to an application's position on a given screen, and interception of the data within it.
  • the SmartAgent context interceptors infrastructure may enable a Screen scraping context interceptor designed to intercept relevant context elements such as user and patient context, to apply suitable rules to refine and to validate intercepted information and to pass the intercepted information to the SmartAgent for application, user and patient resolving.
  • the SmartAgent ScreenScrapping context interceptor typically intercepts both user and patient context.
  • a method according to embodiment 1 wherein said providing patient record data includes subscribing to events exchanged between the individual EMR and an operating system serving the EMR, ascertaining in real time at least one current EMR display operation and mimicking the EMR display operation when providing the patient record data.
  • the SmartAgent windows state interceptor of FIG. 176 typically uses operating system events to identify a relevant EMR now displayed. This identification is used by the SmartAgent to position itself on top of the EMR, e.g. by applying suitable position algorithms such as but not limited to providing a SmartAgent User Interface Shell container for a desktop application which uses some or all of the following parameters which are defined pictorially in FIG. 184 :
  • FIG. 156 a is an example of a smart agent positioning itself vis a vis an E.H.R.
  • the EMR is Allscripts Sunrise and the SmartAgent position in the top right, tuned by number of pixels from the top right corner of the EMR Application angles.
  • Interception configuration may be loaded at runtime from InterceptionConfig.xml file.
  • the file may contain a list of configurations for known EMR applications. Every configuration may specify some or all of: Launch interceptor class type, Window state interceptor class type, Context interceptor class type and Shell container class type. Custom configuration XML blocks may be specified for each interceptor.
  • SmartAgent runtime manager When a SmartAgent runtime manager instantiates an interceptor, the manager typically gets the interceptor's configuration class type and then deserializes custom XML block into instance of this configuration class type.
  • the SmartAgent runtime manager may process the configuration by performing some or all of the following steps:
  • a method according to embodiment 7 wherein said EMR display operation comprises at least one of a translation along a display screen, a minimization of size and a maximization of size.
  • the position of the SmartAgent on top of the EMR is typically determined relative to the EMR's position and/or state on the screen e.g. as shown herein in FIGS. 156 a (minimized) and 157 a (maximized).
  • a windows state interceptor functionality “listens” for any change in the state of the EMR window which may have occurred and changes the state of the SmartAgent accordingly. For example:
  • a method according to embodiment 1 wherein said intercepting and identifying includes screen-capturing EMR context.
  • said patient record data includes at least one information item which is tagged to indicate a category of information to which said information item pertains
  • said capturing includes capturing screen information indicative of a category of information currently being viewed by the health provider
  • said patient record data presented to said health provider is filtered so as to filter out said at least one information item pertaining to a category of information other than the category of information currently being viewed by the health provider.
  • Context based viewing is typically based on information collected during the screen capturing. Presentation of information in a system based on context in a different system may be achieved by using screen capturing e.g. according to the following example workflow:
  • a method according to embodiment 10 wherein said category of information includes at least one of the following group of categories: laboratory information, medicines, allergies, procedures, vital signs, pathologies, imaging results, clinical documents, immunizations, problems, and diagnosis.
  • a method for using a health information exchange system storing patient record data regarding a multiplicity of patients, to serve a first plurality of EMRs each interacting with an EMR community including a set of at least one EMR, the method comprising:
  • a processor to apply at least one predetermined rule involving intercepted EMR context and using a computerized output device to provide an alerting indication drawing the health provider's attention to at least some of said patient record data according to said predetermined rule.
  • HIE systems consolidate typically large amounts of information per patient, from a wide variety of information systems such as EMRs, lab systems, imaging systems, etc.
  • SmartAgent rules are typically applied on patient information arriving from the HIE to filter out irrelevant clinical information or information that already exits in the system the health provider is working on, e.g. a given EMR. These rules may apply various combinations of filters on the Patient Clinical data. Filters may for example include:
  • Time filters filtering out information that is outdated in the sense of healthcare; for example, 5 year old lab results are almost always irrelevant hence typically have a display priority which is lower than 5 year old allergy records which are often relevant; and/or
  • Source filters filter out information whose source system is the EMR itself.
  • VPO Analyzer may be applied by the VPO Analyzer component e.g. as shown and described herein with reference to FIGS. 154 a - 154 b , 159 c , 177 , 180 and 188 .
  • a method according to embodiment 12 wherein said generating an alerting indication comprises presenting patient record data, pertaining to said individual patient, to said health provider.
  • said predetermined rule comprises alerting said health provider's attention if said patient record data includes at least one item of information not included in said individual EMR.
  • Attention rules are components which may be provided, typically on the EMR Agent server side which typically runs rules on clinical acts in each VPO and marks clinical acts which meet the rule's conditions.
  • the SmartAgent client application typically checks for pre-selected clinical acts and performs an action such as a basic “blink” action or “Expand the SmartAgent” or “Make Clinical acts Bold” if certain clinical acts meet certain rules.
  • An attention rule (“Rule 1”) states: “Mark (i.e. select) clinical acts NOT from my EMR”. Assume only Act 1 meets this rule. Act 1 is then marked in the VPO a Rule 1 annotation.
  • the SmartAgent may then be configured to perform an action of flashing if it finds at least one clinical act that meet a certain rule e.g. rule 1 in the present example.
  • Such provider identification may be performed by the User Context interceptor of FIG. 181 .
  • a method wherein items of information included in said patient record data are stored in computerized storage, in association with respective information source tags indicating an information source supplying each said item, and wherein a determination is made, based on said information source tags, of whether or not said patient record data includes at least one item of information not included in said individual EMR.
  • the VPO Analyzer which is part of the SmartAgent service may use Clinical Data provided by the Clinical Data Services as described above, and metadata of each clinical data element (e.g. Specific Allergy) in order to filter clinical information whose source of information is a given EMR e.g. as shown in FIG. 188 .
  • the VPO Analyzer may apply “Exclude my EMR” data and filter out clinical information whose source system, according to its metadata, is identical to the EMR identifier provided by the EMR Interceptor.
  • a method wherein a list of information sources supplying an individual EMR is stored in computerized storage and wherein said determination includes determining whether all items in said patient record data are supplied by one of: said individual EMR; and an information source appearing in the list of information sources supplying the individual EMR.
  • EMR Systems which serve as data providers or sources for an HIE, also receive clinical data from other systems.
  • a common example is Lab Results clinical data that may be recorded in dedicated (non EMR) lab information systems.
  • the lab results are sent by the lab system and may be received by EMRs and also by the HIE.
  • EMRs may be received by EMRs and also by the HIE.
  • a configuration may be provided which determines which EMR served as a source, which received information from other sources (e.g. a lab system).
  • this configuration may be used, so in addition to filtering clinical information from specific source, a filter is applied on sources that act as a source of the given EMR.
  • clinical information which arrives from the lab system which is acting as a source of the given EMR may be filtered.
  • said predetermined rule comprises alerting said health provider's attention if said patient record data includes at least one item of information which was not seen by the health provider identified by said identifier when he was last served by said health information exchange system.
  • SmartAgent's user context interceptor intercepts user identifier e.g. as described herein with reference to FIG. 181 .
  • SmartAgent's patient context interceptor intercepts patient information and identifies the patient.
  • systems get the Timestamp on which the user last accessed this patient
  • SmartAgent service runs service clinical data service and gets patient's clinical data.
  • SmartAgent service runs the “new acts since last seen” VPO Analyzer rule. If at least 1 clinical act date is later than the timestamp, the rule is applied, the correlated clinical record is marked with the relevant annotation of the rule, and the SmartAgent identifies those acts which are later than the timestamp and enables the alert.
  • SmartAgent saves the timestamp of the last time the provider saw the patient's data in the SmartAgent. f. Save last viewed timestamp for the given user and given patient.
  • the timestamp per user and per patient can for example be stored in the table of FIG. 165 .
  • CCOW and screen capturing are suitable methods to intercept user context as described above.
  • User context intercepted thereby may include a user identifier which is used by information systems to automatically authenticate and authorize the user, including passing the user context to the information system security system for user resolution and authentication.
  • User authentication may proceed as described herein with reference to FIGS. 154 a , 163 b , and 166 - 167 .
  • a single sign on process is advantageous because it facilitates a health provider's workflow by not requiring log-in credentials to be provided separately for each health system being used e.g. in the SmartAgent.
  • a method according to embodiment 15 wherein said identifying said health provider's user name includes capturing said health provider's identifier from a screen display employed by said health provider.
  • a method according to embodiment 1 wherein said intercepting and identifying includes providing an architecture which interacts with at least one context interception adaptor and, when operating in conjunction with a specific EMR having a specific context sharing capability, using an adaptor adapted to utilize said specific context sharing capability as said context interception adaptor.
  • the Context interceptor architecture typically enables creation of a separate custom interceptor for each EMR, in the event that no out-of-the-box context interceptor meets the interception requirements of a given EMR.
  • FIG. 171 is an example of an architecture of a custom context interceptor, termed a “Corner Context interceptor” that inherits interception capabilities from a parent class of EMR context interceptors. This custom context interceptor may be a plug-in into the SmartAgent Client service.
  • a method wherein said context intercepted includes an indication of at least one display characteristic characterizing a graphic user interface being generated by the EMR and wherein said providing patient record data includes generating a graphic user interface for displaying said patient record data which shares said display characteristic.
  • the ability, also termed herein “skins”, to modify the look and feel of GUI based applications is often part of Development frameworks such as .Net and Java.
  • the term “skins” refers to different colors, fonts, or other appearance preferences in which the application can be configured to be presented.
  • the SmartAgent enables different appearance configurations to be applied for each EMR, e.g. as described in FIG. 160 d (“Configure and personalize presentation options”), since different EMRs more often than not have different appearance characteristics.
  • a method according to embodiment 22 wherein said at least one display characteristic includes at least one of: a color characteristic, a texture characteristic, a text font, a text size, and a characteristic of an icon such as a button.
  • a system for using a health information exchange system storing patient record data regarding a multiplicity of patients, to serve a first plurality of EMRs each interacting with an EMR community including a set of at least one EMR, the system comprising:
  • a record-call up identifying processor operative, for each individual EMR within said first plurality of EMRs, to automatically identify an event whereby a health provider using said individual EMR calls up an individual patient's record from said individual EMR;
  • an intercepted context rule applying processor applying at least one predetermined rule involving intercepted EMR context and controlling a computerized output device to provide an alerting indication drawing the health provider's attention to at least some of said patient record data according to said predetermined rule.
  • a record-call up identifying processor operative, for each individual EMR within said first plurality of EMRs, for performing a computerized context interception process using a processor to intercept context from the individual EMR and to identify therewithin an event whereby a health provider using said individual EMR calls up an individual patient's record from said individual EMR;
  • a record call-up identifying processor-driven output device controller operative, responsive to identification of said event, to control a computerized output device for providing patient record data, pertaining to said individual patient, to said health provider.
  • FIG. 1A is a simplified functional block diagram illustration of a health information exchange and integration system constructed and operative in accordance with certain embodiments of the present invention.
  • FIG. 1B is a table of sequence interaction descriptions useful in understanding the operation of the system of FIG. 1A according to certain embodiments of the present invention.
  • the health information exchange and integration system of FIG. 1A includes 3 typically symbiotic sub-systems namely a CTS sub-system, a knowledge framework sub-system and a smart-watch sub-system, which interact with a core platform for processing medical information, such as the core platform product available from DBMotion Inc., Israel.
  • Embodiments of these subsystems are now described with reference to FIGS. 2-3 , FIGS. 4A-8C and FIGS. 14-17 respectively. Detailed descriptions of example implementations of these three subsystems are described further on with reference to FIGS. 18A-105D , 9 - 13 C and 106 A- 137 respectively.
  • the CTS sub-system is also termed herein the SeNS or “Semantic Network Services” and may also be termed “semantic framework” and may include some or all of the following units, each preceded by their reference numeral in FIG.
  • 3 302 Query Façade; 304 Extendable specific query interface framework; 306 Metadata interface; 308 Generic query interface; 310 Get Concept; 312 Get Baseline; 314 Get SameAs; 316 Get ValueSet; 318 Custom Interfaces; 320 CTS Access Control; 322 Query processor; 324 Reasoner; 326 Local terminology; 328 Persistence layer; 330 Global Ontology; 332 Value Set; 334 Metadata service; 336 Notification engine; 338 Ontology extension; 340 Management Application; 342 Management Façade; 344 Navigation tool; 346 Mapping tool; 348 Approval process; 350 Add local concept interface; 352 CRUD interface for ValueSets; and 354 CTS Kernel.
  • the chief functional breakdown of the CTS subsystem's function is Ontology (content), Querying and Management.
  • the representation of medical information is a key issue in the use of computerized systems in healthcare.
  • medical concepts are represented by words and phrases.
  • This form of information representation allows a high degree of freedom but is difficult to use in computer systems. Phrases might be too long and are often inconsistent: ‘pain in lower abdomen’ could also be described as ‘complains of recurring pain in the lower part of the abdomen’.
  • medical information saved in computer systems is codified.
  • the process of codifying medical information involves the representation of medical concepts, such as observations or procedures, using a fixed code instead of free text.
  • a platform which addresses this by providing some or all of: robust information model, a repository of standard vocabularies, tools for searching for concepts, mapping tools to help map proprietary vocabularies to standard ones, tools for defining semantic neighborhoods and relation patterns between concepts, routine updates to vocabularies when released by the standards-development organization, and a set of semantic services such as some or all of: Managing local and Control Terminologies, Semantic Maps (mapping) between local and baseline (standard) concepts, Semantic Business Services, VPO Enrichment, Semantic Navigation (in Semantic Networks).
  • Semantic Interoperability includes ensuring that information exchanged between systems is understandable in the manner in which it was intended by the original creator of that information. It may enable systems to aggregate information from different sources and process it in a meaningful manner.
  • Semantic Interoperability between heterogeneous healthcare information systems is provided in accordance with certain embodiments.
  • One of the primary obstacles to interoperability is the use of independent sets of terms and codes by the participating systems.
  • consumers of data e.g. physicians, EMRs, workflows, Decision Support Systems, BI tools and more
  • semantic information is lacking.
  • System goals may include some or all of:
  • the system described herein may comprise the integration point for data, and is privy to data that the various source systems are not.
  • the system of the invention typically can provide enhanced decision support on top of the decision support that the source EMRs provide. This is done by creating solutions for the knowledge-representation and inference capabilities of existing commercial CDSSs.
  • EMR A An example of what may be achieved is the population of an electronic medical record or EMR A with an allergy—documented in EMR B—that patient Y has to medication X, the result of which is the ability of the decision-support component of EMR A to fire a drug-allergy alert when the physician writes a prescription for patient Y for a medication in the same allergy class as medication X.
  • EMR A understands the code used for medication X and has knowledge about the relationships between drugs and their allergy class, it cannot fire such an alert.
  • a semantic interoperability paradigm may be based on some or all of the following harmonized elements:
  • Unified Medical Schema Ontology of medical knowledge that describes the information and semantics of a medical domain and maintains relations between different domains.
  • Vocabulary Ontology A natural continuation of the UMS, which describes the medical terminology ontology. This ontology utilizes and adheres to well-adopted and advanced standards and methodologies (such as SNOMED, LOINC, HL7 v3, UMLS etc.).
  • CTS Common Terminology services
  • Semantic Network Services services based on medical terminology ontology, providing semantic navigation capabilities that allow interpretation of medical information. Therefore, CTS and SeNS are used herein generally interchangeably.
  • the platform described herein typically enables clinicians to draw conclusions based on a meaningful and unambiguous presentation of information, and serves as the foundation for clinical rules and alerts based on the aggregated information.
  • the system is typically vocabulary agnostic, working with a broad range of standards, coding methods, and vocabularies.
  • the first step in accomplishing the sharing of patient information and clinical decision support solutions may include Unified Medical Schema such as the UMS of DBMotion as a uniform structure for data.
  • the UMS is, in the terminology of data modeling, a logical data model.
  • the UMS may be created by using the HL7 version 3 Reference Information Model as a starting point.
  • the Vocabulary Ontology describes the medical terminology network.
  • the vocabulary ontology is based on a data model that represents concepts, concept relations, coding systems and contexts.
  • the content of the ontology typically includes some or all of:
  • UMS such as dbMotion UMS's, domains and related concepts together with coding systems and other attributes associated with them
  • This ontology may serve as a foundation for the CTS subsystem.
  • CTS subsystem includes some or all of the following functionalities:
  • mappings may be created to the RxNorm code for atorvastatin 80 mg oral tablet (259255) to translate data between EMRs at UPMC: 7427 to 259255 and 045772 to 259255.
  • the CTS subsystem typically provides some or all of the following functionalities pertaining to relations between concepts and searching capabilities:
  • the business layer may decide what is the codes' information to be listed in the business output schema e.g. local code, baseline code, both, calculated typically according to different business rules, code's neighborhood, and hierarchy. In order to do so, the business typically online queries the CTS requesting the relevant information.
  • the codes' information e.g. local code, baseline code, both, calculated typically according to different business rules, code's neighborhood, and hierarchy. In order to do so, the business typically online queries the CTS requesting the relevant information.
  • Another CTS use of the business layer may be for advanced filtering—when there is a need to retrieve information according to one concept code (e.g. “give me all WBC lab results”) or according to a context (e.g. “give me all beta blocker medications”). Another possible use is to retrieve all information that is related according to relation patterns (e.g. “give me all relevant information for the contra indication pattern”—which would result in all medications, conditions, procedures, etc. that have contra indication to a certain drug).
  • one concept code e.g. “give me all WBC lab results”
  • a context e.g. “give me all beta blocker medications”.
  • Another possible use is to retrieve all information that is related according to relation patterns (e.g. “give me all relevant information for the contra indication pattern”—which would result in all medications, conditions, procedures, etc. that have contra indication to a certain drug).
  • a Data Integration layer may operate to recognize concept codes during loading and to load new concept code.
  • a query to the CTS typically results in information regarding this code if such exists or indication that this code is new.
  • the new code is sent to the Vocabulary Ontology for further processing such as but not limited to being mapped to the right concept or adding new contexts.
  • the knowledge expert may query the CTSTM and SeNSTM for various terminology operations (e.g., translation of a code between vocabularies, identification of semantic relationships between codes).
  • KM decision logic If the patient is treated with Coumadin Medication AND has a Diagnosis of Bioprosthetic Mitral valve AND the duration of the treatment is more than 3 months, then send message to stop Coumadin.
  • CTS interaction Search medication—the knowledge engineer provides CTS with the name “Coumadin” and requests all relevant codes.
  • the CTS may retrieve 34 different codes from which the user chooses the appropriate one, say Coumadin Tab 5 mg—RxNorm code—209081.
  • Diagnosis the knowledge engineer navigates from Coumadin on the “May Prevent by” relation and may retrieve a list of Diagnosis. The user chooses, say, the Bioprosthetic Mitral valve diagnosis.
  • the knowledge engineer enters a suitable duration for the selected diagnosis (Bioprosthetic Mitral valve): 3 months. Then Action—the knowledge engineer writes the “Then” clause: send message to stop Coumadin.
  • Event Monitor Consumers of CTS services in SmartWatch, other than KFW, typically include the Event Monitor described herein.
  • Event Monitor may support a limited number of such pattern rules, and may monitor a large number of specific triggering rules using parameterized subscriptions to these pattern rules. Event Monitor typically does not make final decisions, but rather triggers the evaluation of the patient using KFW. For that reason, when at risk of ambiguity—it is usually better to have false positives (false alarms) over false negatives (missing a
  • the action manager component is typically operative to communicate SmartWatch findings to the external world, to care providers and external systems.
  • the Event Monitor gets the message across to the receiving end in a way that is as easy as possible
  • the Action Manager typically expects the CTS to convert in runtime from baseline terminology in which information was provided, into the terminology the external system uses, probably a local code system.
  • a third SmartWatch consumer for CTS may be a SmartGuard manager tool described herein, in which SmartGuards are defined. Within this tool rules are defined on which SmartWatch makes decisions and captures relevant pieces of information. Application-specific needs here may be similar to the application-specific KFW needs.
  • Vocabulary administrators may use the vocabulary management tool in order to manage all vocabulary aspects.
  • a user by using the mapping tool, may perform the actual mapping of the local concept codes to the dbMotion Vocabulary Ontology.
  • Vocabulary human experts typically include a specialist e.g. MD familiar in a clinical area serving as an authority for clinical terms and deciding whether mapping is correct.
  • the Vocabulary experts use the vocabulary management tool to approve the mappers' suggested mapping using the vocabulary management tool and also may provide suggestions for improvement of the dbMotion Vocabulary Ontology.
  • the local vocabulary information is typically located into commercially available dbMotion (e.g.) Vocabulary Ontology.
  • dbMotion e.g.
  • Vocabulary Ontology e.g.
  • each organization provides dbMotion a list of all local coding systems with all their concept codes (manual process). All the local code systems' concept codes from the predefined file/s are imported to the dbMotion Vocabulary Ontology and each code is assigned to a vocabulary domain.
  • Production stage including an offline process and an online process, typically including loading of vocabulary codes on a fluent basis.
  • the vocabulary elements can be loaded to the system both in offline process e.g. using a vocabulary management tool and ⁇ or in online process (automatic during messages loading using the Data Integration Layer).
  • the updates or the whole list of codes can be transformed to a predefined file/s format in a manual process and may be imported to the Vocabulary Ontology using a vocabulary manager tool. Alternatively, when only a few changes occur, changes may be effected manually in the vocabulary management tool.
  • Deleted vocabulary elements Obsolete local vocabulary elements that are not acting in any record in the CDR can be removed manually from the Vocabulary Ontology using a vocabulary manager tool.
  • a new Local code enters a CDR through a message, it is loaded to the CDR and assigned to a pre-defined concept domain according to the message type and related field.
  • the CDR contains only the Local Codes as received from the legacy systems. No mapping process may take place in the Data Integration process.
  • the new local code is marked as new in the Vocabulary Ontology and an event is sent to the Event log for the Vocabulary administrator to monitor it on a regular basis.
  • the administrator can relate the concept to a UMS sub domain and map the code to the Vocabulary Ontology.
  • a code arriving in a message is always associated with a codeSystem and may also be associated with an effectiveDate for the cases when codes in the coding system are editable i.e. can change their meaning over time, such as ICD9 and CPT4 codes.
  • the Vocabulary Ontology takes this into account.
  • Mapping allows a user to map between Local Concept codes and the Vocabulary Ontology (e.g. baseline concept code) in the context of UMS Domains.
  • the process of mapping is executed using the vocabulary manager tool.
  • the local code can be mapped to one entry point in the dbMotion Vocabulary Ontology.
  • the mapper chooses local code or bulk of local codes for mapping.
  • the mapper can apply different filters/parameters for the mapping.
  • a mapping process that occurs in the Mapping Tool provides mapping suggestions to each of the selected codes with scoring. These suggestions can be approved/rejected by the Mapper.
  • the mapping approval includes also the decision of what vocabulary domain to assign.
  • Mapping to a post-coordinated baseline concept typically refers to mapping in which a combination of more than one baseline codes together give the exact mapping—and relation between a collection of baseline codes when mapped to a local code.
  • a. Manage versions When there is new version of a coding system, the version's validation start date is updated for any vocabulary object that was updated according to the new version updates. Until the new version is activated, the Vocabulary Ontology maintains both old and new information. When retrieving changed code information, the system may check if the retrieved code's information is up-to-date. Typically, only if it is, the information is retrieved.
  • Concept codes are maintained on a regular basis. If changes occur in a coding system, this change may be analyzed and imported to the Vocabulary Ontology in a predefined format. The vocabulary manager tool may manage the different versions. When the change is of a baseline code, it is the responsibility of the commercially available dbMotion product to provide those updates when they occur. If it is a change in a local coding system, then it is the responsibility of each node separately.
  • the vocabulary manager tool may allow the change of relations between concepts—creating new relations and deleting relations no longer existing. This change is effected in the level of the Vocabulary Ontology and is typically approved before being activated.
  • the vocabulary manager tool may allow the changing of mapping of local codes to the Vocabulary Ontology. This change typically must be approved before being activated and versioned.
  • the vocabulary manager tool may allow the creation and update of contexts and value sets. Each change typically must be approved before being activated and versioned.
  • the vocabulary manager tool may allow the change of UMS domain information, when sub-domains are being updated. When updating a sub-domain, its related concept codes may no longer be relevant and other concept codes may now be relevant. When deleting sub-domain, the vocabulary administrator typically first decides what to do with all its related concept codes. All changes typically must be approved and versioned before being activated.
  • Publish changes to subscribers Any change in a subscribed concept may be published to the subscribers in a predefined format.
  • A. retrieve codes according to a given context In each node, if the given context exists in its CDR, a process that generates the list of all valid concept codes that are assigned to this domain or to one of its sub-domains, is executed. For each of the generated codes, a process that retrieves the relevant data from a Vocabulary Ontology is executed.
  • B. retrieve Codes according to a specific code within a specific context In the initiator node, if the given code exists in the CDR's vocabulary domain, and is also assigned to the given domain or to one of its sub-domains, a process that retrieves the valid code's baselines is executed. This baseline code is then passed to all the network's nodes. In each node, a process that generates the list of the baseline's mapped local codes is executed. The mapped codes are all the local codes that are mapped to the baseline code. For each of the generated codes, typically including the baseline, a process that retrieves the relevant data from the CDR is executed. A relevant data is the information in the CDR that has the generated code in one of its predefined attributes.
  • Input Parameters may include some or all of the following:
  • Search string a string (not case sensitive) that is the motivation of the search. Search typically finds items related to it.
  • Domains/sub domains context limit the search to pre-defined domains and sub-domains. If null, search the entire database. Use the internal mapping/created list of domains.
  • Context string limit the search to the provided context string.
  • the output result may include the related codes/concepts as well. In the output, indicate those as “related” and provide the relation type. If null, no related concepts are retrieved, “All” may retrieve all related concepts.
  • Relation pattern the searching is done according to the given relation pattern which defines the semantic navigation pattern.
  • Input language the language in which the search string is provided.
  • Output language(s) The code/concept designation language(s).
  • D. Dynamic querying A user might build a specific query. dbMotion SeNSTM may allow building of such a query, save it and enable to reuse it when appropriate.
  • dbMotion SeNSTM may include a query control tool.
  • This tool may address all application-specific requirements for searching and querying using a dedicated GUI for this purpose.
  • the user may be able to effect some or all of the following functionalities: Build a dynamic query, and save it for later use; Use existing queries; Use a template for creating a query; Update existing queries; Navigate graphically in the dbMotion Vocabulary Ontology, in order to find, and select concepts; and Define Value set of concepts from a query result.
  • the CTS subsystem typically includes a mapping tool which allows a user to match between string, codes and phrases to the right place within the Vocabulary Ontology by using a dedicated GUI.
  • a mapping tool which allows a user to match between string, codes and phrases to the right place within the Vocabulary Ontology by using a dedicated GUI.
  • the user may be able to perform some or all of the following functionalities: Mapping local codes to standards (dbMotion Vocabulary Ontology) with high performance and quality; match the best suggested mapping according to a map ranking for each suggested mapping; and apply different search methods or algorithms as appropriate.
  • Concept refers to or points to a terminology element that describes one item of classification knowledge such as a specific drug or disease, like congestive heart failure.
  • a “classification concept” points to a higher level, typically more general, knowledge element, such as a cardio-vascular disorder.
  • a “Node” as used hereinabove refers to a software deployment component that provides some or all of the system functionality described herein for an individual medical organization.
  • a Node may contain one or more physical servers and is usually but not necessarily installed in each hospital within a medical enterprise.
  • Each Node typically has its own Clinical Data Repository (CDR) that stores information collected from this specific facility.
  • CDR Clinical Data Repository
  • KFW Knowledge Framework
  • the KFW system may enable knowledge-based interpretation of clinical data to facilitate automatic decision support capabilities.
  • the KFW may comprise a tool set, services, and repositories that enable its users and consumers to acquire, maintain, store, and apply knowledge to data in a meaningful way.
  • the system of the present invention typically enables healthcare organizations to securely share and exchange medical information, creating a Virtual Patient Object (VPO) by logically connecting a group of care providers and organizations without enforcing data centralization or replacement of existing information systems.
  • VPO Virtual Patient Object
  • the information flowing from the network shown and described herein can leverage development of services that go beyond sharing and exchange of information for purposes such as presentation. Moreover, to avoid overloading care providers with increasing amounts of raw data, it is desired to have services that can interpret raw data, e.g. hemoglobin lab test measurements, into more meaningful concepts at different levels of abstraction, e.g. anemia state, which is derived from consequent hemoglobin lab test results.
  • raw data e.g. hemoglobin lab test measurements
  • SmartWatch enables continuous monitoring of a population, e.g. patients, within a defined medical information space.
  • the SMW framework is utilized by application-specific and/or customer-specific Enterprise Clinical Decision Support Systems (ECDSS). These SMW-based ECDS systems, also known as SmartGuards, are outside the scope of certain embodiments of the present invention and suitably employ core platformabilities of certain embodiments of the present invention and services as well as consuming new services which may be provided by the KFW.
  • the core platform of certain embodiments of the present invention provides a unified holistic view of the patient clinical state manifested by the Virtual Patient Object (VPO) while the KFW provides the ability to interpret the data contained within the VPO to generate healthcare delivery recommendations.
  • VPO Virtual Patient Object
  • FIGS. 144A-153 An example of an Enterprise Clinical Decision Support System which may utilize the SmartWatch subunit shown and described herein is described herein in detail with reference to FIGS. 144A-153 .
  • the KFW may utilize the holistic view of a patient as captured in the VPO provided by certain embodiments of the present invention to enable knowledgeable abstraction of data to meaningful concepts.
  • This data abstraction ability serves as a key vehicle to support the creation of clinical decision support services. For example, improve the quality of medical care by creating Enterprise Clinical Decision Support Systems (ECDSS) that consume data interpretation results to generate recommendations to care providers and administrators.
  • EDSS Enterprise Clinical Decision Support Systems
  • Another example might be to generate a VPO schema recommendation that takes into consideration preferences such as clinician specialty, e.g. cardiologist, and patient clinical state, e.g. congestive heart failure (CHF), to address specific requests for information.
  • clinician specialty e.g. cardiologist
  • CHF congestive heart failure
  • Another goal of the KFW is to facilitate the dissemination and utilization of clinical expertise to improve the quality of care.
  • Clinical expertise is accumulated by clinical experts at different medical domains over years of experience.
  • the KFW may enable clinical experts to play an active role during the knowledge acquisition process while collaborating with other actors, e.g. knowledge engineers.
  • the KFW is typically operative to provide computerized support e.g. to one or more medical domain experts, researchers, clinicians, nurses, social workers, administrators, knowledge engineers and other, non-human consumers, such as EMR, workflow, CPOE process, another DSS, to interpret raw data in order to reach meaningful conclusions at different levels of abstractions otherwise hidden in the data.
  • the KFW typically facilitates application of knowledge to data to reach meaningful concepts at different levels of abstractions which are useful in computerized clinical decision support.
  • FIG. 4A An example list of users is provided in the table of FIG. 4A .
  • An example User environment is described in the table of FIG. 4B .
  • Typical Key Stakeholder/User-defined Needs are set out in the table presented in FIGS. 5A-5H , taken together.
  • KFW Knowledge Framework
  • the KFW typically utilizes services provided by the core platform shown and described herein.
  • the KFW is responsible to provide services to acquire, maintain, store, and apply knowledge to data to reach meaningful conclusions at different levels of abstraction.
  • the KFW may provide its services according to the Service Oriented Architecture (SOA) principles. These services may be available to systems shown and described herein and applications internally, e.g. business domains developed using Business Layer infrastructure shown and described herein, as well as to other healthcare IT applications externally, such as 3 rd party Electronic Medical Records (EMR).
  • SOA Service Oriented Architecture
  • SMW is a framework that enables continuous monitoring of a population, e.g. patients, within a defined medical information space.
  • the SMW framework allows the development of Enterprise Clinical Decision Support Systems (ECDSS).
  • ECDSS Enterprise Clinical Decision Support Systems
  • SmartGuards These SMW-based ECDSS, also known as SmartGuards, capitalize on core platform abilities shown and described herein as well as consuming new services which may be provided by the KFW.
  • the core platform shown and described herein provides a holistic view of the patient clinical state manifested by the Virtual Patient Object (VPO) while the KFW provides the ability to interpret the data contained within the VPO to generate healthcare delivery recommendation.
  • VPO Virtual Patient Object
  • the KFW may serve other components shown and described herein as well.
  • the business layer may consume its services as part of a business process modeled in a business domain and accessible through a business method.
  • the business method outputs including the knowledge evaluation results generated by the KFW can be displayed using a Clinical View created using the Presentation Layer shown and described herein.
  • a 3rd party EMR or other healthcare application can consume these same services of the KFW similarly.
  • the new system may interface with the existing platform core shown and described herein to utilize several of its existing services. These services may include but are not limited to:
  • the KFW may provide SOA-based public interfaces to consume the services it provides, such as creating of a new Knowledge Module (KM) or evaluating a Knowledge Module giving specific patient data, to internal and external applications and authorized users of the system shown and described herein as shown in FIG. 6 which is a context diagram for the knowledge framework unit.
  • the KFW System may comprise a Knowledge Acquisition Tool (KAT) and a suit of Management tools client components, a KFW Access Service, Knowledge-Base repository and one or more Inference Engines server components as illustrated in FIG. 7 which is a system overview of the knowledge framework according to certain embodiments.
  • KFW main functional units may include some or all of: a management functional unit also termed herein “KAT” and “PCT management tools”, access service (SOA), knowledge base repository, PCT management tools suit, and inference engines.
  • a KM or Knowledge Module comprises a knowledge evaluation rule, an input data model, an output data mode and terminology/ontology elements that are used by the KM.
  • the server component resides on a variety of servers including an application server that hosts the KFW Access Service, an application server that hosts one or more Inference Engines, such as but not limited to RatHat's JBoss Drools engine, and a data server that hosts the Knowledge-Base repository.
  • the server component may interface with existing components shown and described herein e.g. as detailed previously. This interface is supported by the existing SDK shown and described herein, although it may be extended or even enriched with new functionality if application-specific requirements arise.
  • KFW's knowledge base repository may be derived from a suitable Knowledge-Module Entities Model such as, for example, that of FIG. 140 and a suitable programming technique, such as Hibernate, an open source Java persistence framework project, may be employed to convert business objects into DB structures, such that no DB modeling need be done explicitly.
  • the client components reside on personal computers either as web-based thin clients or as full-blown desktop applications using technologies such as ASP.NET and SmartClient technologies respectively. Once the client component is installed on the PC, the user may access the KFW System from the PC through the network shown and described herein or via a secured Internet access following a successful authentication and authorization process.
  • FIGS. 8A-8C The table presented in FIGS. 8A-8C , taken together, identifies capabilities, all of which are typically but not necessarily provided, of the KFW System in terms of benefits and features. The features are further described hereinbelow.
  • the KFW may receive as input (1) an identifier of a Knowledge Module to evaluate, e.g. definition of chronic hypertension, and relevant patient data, e.g. blood pressure measurements.
  • the KFW may process the data and knowledge using an inference engine of some kind, e.g. a temporal reasoning engine.
  • the KFW may generate a conclusion e.g. patient had chronic hypertension during last year.
  • the KFW enables its consumers to provide it with the data it uses to perform a Knowledge Module evaluation in an iterative manner.
  • a possible intermediate evaluation result is the fact that additional data is to be provided to complete the current evaluation request processing. Then, after the consumer collected the missing data, it sends another evaluation request to the KFW.
  • the intermediate result may be marked as not final.
  • Each conclusion result may optionally contain an explanation of the knowledge and facts that lead to it. This explanation may be in a human-readable and machine-interpretable format.
  • One of the evaluation request arguments may explicitly direct the KFW whether to generate such an explanation or not, as part of its output. For example, the hematocrit and haptoglobin serum levels of a patient, leading to the conclusion of having ongoing hemolysis, may be presented together with the definition of what an ongoing hemolysis is.
  • FEAT8.3 Temporal Reasoning Capability A special type of inference capability that the KFW may support is temporal reasoning. A common feature of many healthcare information types is having a time stamp.
  • the valid time of a WBC lab test result, the request time to perform a MRI imaging study and gestation condition start time are only some examples.
  • the temporal reasoning method enables to interpret large sets of time-stamped raw data into meaningful concepts at different levels of abstraction. This may include abstraction of individual time points to longitudinal time intervals, computation of trends and gradients from series of consequent measurements, and detection of different types of patterns, which may be otherwise hidden in the raw data.
  • FEAT8.4 Probabilistic Reasoning Capability Another type of inference is undeterministic or probabilistic reasoning.
  • insufficient, incomplete, or less reliable data is input to an inference process.
  • non-deterministic data abstraction methods such as fuzzy logic may optionally be applied including reflecting the data quality implications on the final output in terms of confidence level.
  • fuzzy logic may optionally be applied including reflecting the data quality implications on the final output in terms of confidence level.
  • probabilistic algorithms such as Bayesian Networks or Belief Networks, exist which reflect the data quality implications on the final output in terms of confidence level.
  • This optional capability typically utilizes a specialized knowledge representation model that captures the probabilistic nature of the knowledge and corresponding inference mechanisms.
  • a special type of evaluation result is a recommendation to an information schema of a Virtual Patient Object (VPO).
  • VPO schema can be generated when given as inputs the clinical state of a patient, e.g. current problem list, and possibly the preferences of a care provider, e.g. clinical specialty. This custom-tailored VPO may benefit the care provider by decreasing the amount of information to review during a care delivery session.
  • FEAT8.6 Knowledge Evaluation Simulator A helpful feature to a knowledge editor is to simulate the evaluation process of a Knowledge Module. The simulator typically supports debug-like mode enabling to find problems in the Knowledge Module definition or inference engine. In addition, the simulator may have a capability to generate a representative data set that covers possible inference execution branches.
  • FEAT9.1 Descriptive Information Traits A section common to all types of Knowledge Modules is the one that contains descriptive information about the Knowledge Module.
  • the Knowledge Module metadata describes its scope, goal, function, etc. This may include its creation date, modification dates, authors, version details, and classification keywords, whether codified or not. This information serves as the basis to search and retrieve Knowledge Modules by submitting search queries that comprise the descriptive information traits.
  • FEAT9.2 Standard Boolean Expressions Simple rule-based clinical knowledge is often expressed using straightforward Boolean expressions, i.e. and/or clauses. Thus, the KFW may support the representations of such expressions.
  • Clinical knowledge can be divided into two main types, declarative and procedural knowledge.
  • the declarative knowledge type defines meaningful clinical concepts related to the patient's clinical state.
  • blood pressure state Knowledge Module definition i.e., low, medium, or high
  • the procedural knowledge type usually defines clinical workflows and procedures. This may be for instance a recommendation of treatment for patients suffering from high blood pressure (e.g., routine blood pressure monitoring). It usually involves the explicit specification of control structure such as do-in-parallel, decision steps, or mandatory actions.
  • the KFW may provide specific knowledge representation (KR) models to capture these two distinct types of knowledge to support a broad range of Clinical Decision Support Systems (CDSS). Moreover, the KR models used to capture these knowledge definitions may be based, or at least adhere, to existing healthcare standards such as HL7 GLIF for declarative and procedural knowledge respectively.
  • KR knowledge representation
  • a Knowledge Module definition often comprises terms and concepts originating from controlled medical vocabularies. These concepts are typically found both in the metadata section of a Knowledge Module, e.g. an applicable clinical state such as diabetes mellitus using coded keywords from SNOMED, and in its knowledge definition section, e.g. referring to a certain type of blood lab test such as WBC count using LOINC codes.
  • the KR model of a Knowledge Module provides special placeholders enabling to embed terms and concepts during the knowledge acquisition process.
  • embedding terms and concepts originating from well-accepted and commonly-used terminologies facilitates sharing and reuse of Knowledge Modules at different clinical settings.
  • a Knowledge Module definition often relates to knowledge definitions of other Knowledge Modules. To ease and simplify the knowledge acquisition process an ability to interrelate Knowledge Modules may be provided.
  • Common Knowledge Module interrelations include inheritance and composition.
  • the Proteinuria state Knowledge Module i.e., protein levels in urine
  • the HELLP syndrome Knowledge Module comprises hemolysis state, liver enzymes state, and platelet state Knowledge Modules, each being valuable on its own too.
  • the KR may cater for this by enabling to base the definition of one Knowledge Module on other Knowledge Modules via common interrelations such as specialization (i.e., is-a) and composition (i.e., part-of).
  • FEAT9.6 Automatic Triggering Events Extraction The evaluation process of a Knowledge Module may impose on the requesting consumer to perform preliminary operations, for example gathering data according to application-specific Knowledge Module data requirements, which are costly in terms of time and computational resources (e.g., network traffic). In addition, in some cases it is critical to evaluate a Knowledge Module as soon as one of its comprising data elements changes in the CDR. Therefore, from a Knowledge Module definition, a consumer may be able to automatically extract events, in terms of data changes in a CDR (e.g., arrival of a new WBC lab test message), which trigger the necessity to evaluate the Knowledge Module.
  • a CDR e.g., arrival of a new WBC lab test message
  • Knowledge Module Search Engine There may be a mechanism that enables to search and retrieve Knowledge Modules. During runtime, before requesting to evaluate a Knowledge Module, it first may be retrieved and explored to provide application-specific data requirements as input. During design-time, to maintain the Knowledge Module definition, a knowledge editor may be able to locate it before editing.
  • the Knowledge Module search engine allows searching and retrieving of Knowledge Modules by submitting search queries. These search queries capitalize on the descriptive information section of a Knowledge Module. Two possible search queries are free-text search query or a context-based search query. The free text search query contains a single search string to be matched against any text-based section of a Knowledge Module.
  • the context-based search query comprises a structured query, for example XML, which defines for each searchable attribute or trait of a Knowledge Module its expected value. For example, a search for Knowledge Modules of John Foster may use the Author descriptive information trait. Another example is a search for Knowledge Modules that expect to receive a certain LOINC-coded lab test typically using the data requirements' Knowledge Module attribute.
  • FEAT10.2 Knowledge Module Definition Import and Export Mechanism A mechanism that enables to import and export Knowledge Module definitions in or out of a KB repository.
  • An XML schema defines the Knowledge Module file format and allows a Knowledge Module to be imported from one KB and exported into another KB.
  • FEAT11 Knowledge Acquisition Tool One of the KFW client components is the Knowledge Acquisition Tool (KAT) that facilitates domain experts and knowledge engineers, acting as knowledge editors, to collaboratively acquire, edit, and maintain the knowledge definitions and descriptive information of Knowledge Modules stored in the KFW knowledge-base repository. Besides knowledge editing capabilities, the KAT may contain several other features, as described hereinbelow.
  • FEAT11.2 UMS Explorer The underlying clinical information model of the KFW is the UMS shown and described herein. Hence, the definition of any Knowledge Module typically comprises UMS entities such as LabResult, Diagnosis (type of Condition entity), and Medication.
  • the UMS information model is relatively large in scope and contains diverse attributes, complex data types, and various relations between its entities.
  • the KAT may contain a specialized module, named UMS Explorer, to explore the UMS information model and assist the knowledge editor to navigate and find UMS entities and attributes that comprise a Knowledge Module definition.
  • UMS Explorer a specialized module
  • the functionality expected of the UMS explorer includes: free-text search and context-based search of UMS entity and attribute (e.g., entities that use a certain vocabulary domain), descriptive information, and navigation according to relations (e.g., related-act).
  • a Knowledge Module definition may relate to another Knowledge Module. Different types of relations can exist between Knowledge Modules, including specialization (i.e., is-a) and aggregation (i.e., part-of).
  • the Hypertension Knowledge Module which defines the clinical state of having elevated blood pressure, can be derived by another Knowledge Module to define gestational hypertension.
  • the KAT may contain a specialized module, named Knowledge Module Explorer, to explore the KB repository and assist the knowledge editor to navigate and find Knowledge Modules during the knowledge acquisition process.
  • the functionality expected of the Knowledge Module explorer includes: free-text search and context-based search of Knowledge Modules (e.g., all Knowledge Modules that use a certain SNOMED code), descriptive information, and navigation according to relations (e.g., is-a).
  • a Knowledge Module definition may contain terms and concepts originating from controlled medical vocabularies (e.g., LOINC code for WBC count). Different types of terminology relations exist serving different coding habits. For example, the SNOMED terminology is usually used to code diagnosis terms, signs and symptoms. Thus, the KAT may contain a specialized module, named Concept Explorer, to explore the variety of terminologies and assist the knowledge editor to navigate and find concepts to embed in a Knowledge Module definition.
  • the functionality expected of the Concept explorer includes: free-text search and context-based search of concepts (e.g., diabetes code in SNOMED), descriptive information, and navigation according to relations (e.g., is-a), if such exist, between concepts.
  • the KFW provides a secured and controlled environment at design-time and runtime. Users and consumers may be authenticated and receive authorization before accessing KFW services and knowledge. Special roles and rules may be defined for the KFW to cater for its unique services and protect its special resources. For example, a knowledge editor role may be defined as well as a rule determining who can edit a certain Knowledge Module.
  • the KFW provides a robust and flexible audit and log capability.
  • the level of auditing and logging can be changed according to different scenarios, for example testing vs. production.
  • Special auditing and logging policies can be applied to different services and resources of the KFW, for instance applying a meticulous auditing and logging policy to knowledge creation and maintenance operations.
  • the KFW functionality is largely based on the functionality specified in the HSSP DSS SFM as described hereinabove to facilitate interoperation with KFW services.
  • FIGS. 14-17 An embodiment of the smart-watch sub-system is now described generally with reference to FIGS. 14-17 .
  • FIGS. 14-17 An embodiment of the Smartwatch subunit of FIG. 1A is now described with reference to FIGS. 14-17 .
  • clinical decision support systems are very complex. The challenge of creating such systems is even greater in a heterogeneous and distributed environment where the data—the cornerstone of any decision support system—exists in different locations (often hard to access) with different structures, standards and terminologies, often lacking any common semantics.
  • Many of the existing EMR systems provide a rich set of decision support functionalities but these rely on each system's limited data.
  • an enterprise-wide decision support framework co-exists with the EMR CDSS modules.
  • the dbMotion Platform product may be employed, thereby achieving interoperability, and presenting medical information from disparate sources as if it originated from one normalized source, using common representation, terminology and semantics. This enables the creation of an advanced infrastructure for an enterprise-wide clinical decision support framework termed herein the SmartWatch Subsystem.
  • the Enterprise Clinical Decision Support System also termed herein the SmartWatch subsystem, may work in conjunction with the commercially available dbMotion platform.
  • the SmartWatch subsystem addresses the challenge in such a way that no centralized database is mandatory, thus enabling enterprise decision support services both in a fully distributed as well as centralized model (and any hybrid in between).
  • the SmartWatch subsystem is not intended to replace existing clinical decision support systems currently running within any of the existing EMRs, or any other systems in the organization. Instead, it aims to address problems that cannot be tackled by any operational/legacy system (e.g. EMR) that often has access only to a partial subset of the patient's clinical information.
  • EMR operational/legacy system
  • the SmartWatch subsystem may facilitate both the design time and runtime activities involved in the creation and use of ECDSS. These activities may include some or all of: knowledge elicitation, eligibility determination, continuous patient monitoring providing timely alerts, notifications and more. Care providers are then able to carry out the appropriate actions, in a timely manner, thereby increasing the quality of healthcare and lowering costs that might arise from possible deterioration in a patient's condition.
  • SmartWatch does not aim to replace the physicians' role in complex decision making Instead it is targeted at giving help and support with decision making—performing time-consuming, data-driven or time-driven tasks, and bringing the human factor into the picture only when human involvement is inevitable.
  • the SmartWatch subsystem may rely on a built-in knowledge base, maintained by medical professionals. This knowledge base allows The SmartWatch subsystem definitions (matching rules, etc) to be set in an abstract, high level language, rather than having to code rules in computer language.
  • the SmartWatch subsystem is a platform for developing services that facilitate an enterprise-wide clinical decision support system (ECDSS) that utilizes the Service Oriented Architecture (SOA) environment provided by the dbMotion platform.
  • EDSS enterprise-wide clinical decision support system
  • SOA Service Oriented Architecture
  • the subsystem is geared to identify a target population according to eligibility rules, and monitor the state of the target population members over time, according to another set of monitoring rules, and eventually trigger proper actions such as alerts or reminders when a rule is matched.
  • the subsystem may facilitate both the design time and runtime activities involved in the creation and use of ECDSS. These activities include knowledge elicitation, eligibility determination, monitoring patient state continuously, providing timely alerts, notifications and more. Consequently, care providers can carry out suitable actions when appropriate, thereby increasing the quality of healthcare and lowering costs arising from deterioration in the patients' condition.
  • the SmartWatch subsystem is intended to rely on a built-in knowledge base, maintained by medical professionals. This knowledge base allows the SmartWatch subsystem definitions (matching rules, etc) to be set in an abstract, high level language, rather than having to code rules in computer language.
  • the SmartWatch subsystem can serve as a complementary framework that may benefit other systems.
  • cutting edge EMR systems provide CDSS capabilities usually during data entry (i.e. in real time) although they are dependent on the data available to the EMR itself.
  • SmartWatch's design enables retrospective CDSS capabilities offering a near real-time response.
  • a preferred model for The SmartWatch subsystem is one of synergy in which the SmartWatch subsystem provides a continual monitoring of clinical information and notification services to other applications.
  • SmartWatch does not aim to replace the physicians' role in complex decision making, but to provide help and support in decision making by performing time-consuming, data-driven or time-driven tasks, and bringing the human factor into the picture only when needed.
  • the SmartWatch model may include 4 logical layers as follows:
  • FIG. 14 A high level conceptual view of SmartWatch, based on the 4 layers mentioned above is illustrated in FIG. 14 . As illustrated, there is communication between the 4 logical SmartWatch layers. Each layer depends on preceding layer artifacts. In addition, SmartWatch communicates with dbMotion platform services such as security services, EMPI, and the management layer. Also illustrated is the dependency of SmartWatch on the Knowledge Framework in supporting clinical decision making.
  • dbMotion platform services such as security services, EMPI, and the management layer.
  • SmartWatch may employ several storage elements that include SmartWatch Metadata, in which the SmartGuard (the SmartWatch Solution) properties are retained, population and possibly VPO storage, in which the population and information are stored.
  • the Knowledge Framework may add storage—a knowledge base—of its own.
  • the VPO storage system is used to store ePHI, and for that reason careful thought may be taken on how to store them without compromising patient and business security and privacy.
  • SmartWatch provides services to external parties, allowing complementary applications to fit in and form a solution.
  • the knowledge-framework role is to allow SmartGuards to be defined in terms of clinical concepts and abstractions, rather than referring directly to raw UMS data.
  • the knowledge framework may be able to connect a concept, or a knowledge module, to data and to a suitable computation mechanism.
  • the SmartGuard can be thought of as a single SmartWatch subsystem solution, monitoring a specific population.
  • the SmartWatch subsystem may host several SmartGuards running simultaneously. Each such SmartGuard may contain all the details it uses in order to operate: the population criteria, information to be employed, the rules to be matched, and the actions to take when rules fire.
  • SmartGuards are tools for retrieving information between hospitals. To make sure that no unauthorized query is performed in a hospital repository, SmartGuards may require hospital approval to operate.
  • FIG. 15 presents such a solution that includes a dbMotion platform that provides the application-specific required data for the SmartGuards, SmartWatch itself, and a clinical application that users interact with in their daily routine, such as a CPOE or EMR.
  • This clinical application interacts with SmartWatch, and provides the user with a subscription mechanism, a message viewer (e.g., view SmartWatch patient messages within the patient file; action items for the physician after login to the system and so on), and an ability to close the loop (e.g. by marking a checkbox verifying that the message was addressed, by simply viewing the message, or by initiating a process tracking the patient condition). None of these interfaces is mandatory, but failing to provide one may result in the creation of a partial solution only.
  • a clinical application as shown in FIG. 15 may be referred to here as a complementary application.
  • This document assumes the existence of such an application, provided by dbMotion or by an external provider, to form a complete solution.
  • messages sent to users directly via for example SMS or Email protocols. Messages sent to human users in this form, would usually be accompanied by a corresponding message to the complementary application, while providing elementary information and directing the user to view the full message details in the complementary application.
  • FIG. 16 presents a domain model for SmartWatch, implying both its static service-oriented structure, as well as the dynamic processes involved. It shows SmartWatch containing several SmartGuards, maintaining their properties through services, as well as the dynamic messages coming into the SmartGuard process from dbMotion network, and out of the process to users and systems. Also shown is a clinical knowledge base, and its editor, CDSS that may be called by SmartWatch during patient records analysis.
  • SmartWatch relies on the dbMotion infrastructure as its main data source and relies on some or all of the following dbMotion Services: Security, Auditing and Logging (STL, CEB).
  • SmartWatch relies on its decision logic in the Knowledge Framework component for modeling clinical knowledge, and in applying that knowledge to patient data.
  • SmartWatch is a service-based product, that assumes the existence of complementary applications (not necessarily part of the basic SmartWatch) from which users can actually subscribe to SmartGuards, view the artifacts—resulting messages, and let SmartWatch know when the issue is addressed (close the loop).
  • SmartWatch analysis assumes the existence of an EMPI service, with a one-to-one relationship between the EMPI cluster and the virtual patient SmartWatch refers to. Even if there are more than one (several) clusters returned from the EMPI, SmartWatch may use only one of them. If the EMPI clustering quality is poor, SmartWatch's decision quality may be affected, as it may miss patient records or be confused by records actually related to another patient.
  • SmartWatch assumes each EMPI vendor supplies the “member-of” functionality, whose input is an index and its output is the cluster the input belongs to, along with all cluster indexes. This converts an operational system patient index into a virtual patient which contains all indexes in the cluster. SmartWatch assumes that EMPI vendors do not supply a change log service, detailing clusters whose state has changed. However, if such a service is available, keeping up with patient EMPI state may be made much easier and may simplify the process.
  • GUI GUI
  • SOA SOA based infrastructure
  • Medical records may be gathered for specified groups of patients (population), providing proactive messages based on the records collected.
  • SmartWatch may provide an enterprise-wide view of patients and an ability to analyze the information, apply rules to them, and as a result perform actions in which messages are sent to external actors to respond to SmartWatch findings.
  • the response time (measured starting from an event happening in real life, and ending as user views the resulting message) expectation is at most near real-time.
  • SmartWatch may be supplied with an existing content that covers common medical cases.
  • each SmartGuard may be a deployable unit, packed and deployed together.
  • SmartWatch may depend on the knowledge framework in formulating & executing its clinical rules and decisions.
  • Functionalities of the knowledge framework which may interact with SmartWatch or otherwise be used thereby, may include some or all of the following functionalities A-G:
  • the authorizing tools are employed to facilitate verification that outgoing messages are authorized.
  • the SmartGuard may always send the minimal data set that is relevant to the context of the specific SmartGuard.
  • Subscription security authorization SmartWatch enforces authorization for subscribing to SmartWatch actions to get messages, to avoid unauthorized access to confidential patient information as a result of notification 4.
  • SmartWatch management tools security and auditing SmartWatch controls access to its management tools and audit user activities for several reasons: a) sensitive information may be accessible to users of these tools, for example through auditing messages sent b) changing security-related settings can cause HIPAA violation (for example if patient consent policy setting is altered) and c) changing SmartWatch settings definitions may jeopardize the proper functioning of the system.
  • SmartWatch may therefore provide and manage secure access (authentication and authorization) to Smart Watch management tools. 5.
  • Access data across the enterprise (using dbMotion) in a secure manner SmartWatch is typically operative to access data across the enterprise (using dbMotion) in a secure manner, utilizing a secure channel, authentication and authorization—for example, a need to prevent SmartWatch from accessing unauthorized data domains.
  • Enterprise business security SmartWatch introduces an amplification of all the barriers found in the dbMotion core with regard to ownership.
  • SmartWatch may enable auditing of all operations that relate in any way to accessing patient information (ePHI).
  • An audit entry may include details of the user, the time the operation took place, and the ability to generate audit reports—with the option to audit any changes in SmartGuard settings, any operation in SmartGuard or SW management, and any message that was sent.
  • audit of SmartWatch Actions may include ALL the information about a recommendation/notification/alert, including its content and narrative explanation (mainly for medico-legal reasons).
  • SmartWatch may be designed to deliver messages to both secured systems and to people over potentially unsecured channels such as Email, Fax or SMS. Provisions are typically made both for protecting patient privacy in the message content and for technologically securing the channel. For example, Email could be signed and encrypted, an SMS message may include partial, non-confidential information, directing the user to view the full notification in a secured system, to which the message was sent in parallel. The recommended practice is using secure channels only. 10.
  • Patient consent to be incorporated into the SmartWatch process SmartWatch may find a way to take into account patient consent considerations when deciding on including a patient in a SmartGuard.
  • SmartGuards can be established at enterprise or SmartGuard level that may include (but are not limited to) opt-in, opt-out, no consent required.
  • SmartWatch may utilize the dbMotion core PAS.
  • SmartWatch may use dbMotion Product Security and Auditing, as much as possible, for meeting security and privacy needs.
  • SmartWatch may not have its own Security Layer, but rather utilize dbMotion core security. Since there are many cases where there is no cross-enterprise unique patient identifier, patient identity is not deterministic. This may impose some or all of the following constraints 1-3 on SmartWatch: 1. SmartWatch cannot assume patient clustering is stable. When using records collected at different points in time, SmartWatch cannot assume that patient identity has not changed, i.e. that the patient's cluster as determined by the EMPI system is the same as before.
  • SmartWatch typically employs cluster consistency procedures to verify that the patient cluster has not changed along the way.
  • Patient enrollment scenario When a physician selects a patient cluster/index retrieved from the EMPI system—the selection may be stored in SmartWatch. Proposal: save a leading index whose cluster may be used as the virtual patient. 3. SmartWatch may be able to work in an environment that has a unique patient identifier for all systems, without EMPI. This applies to some European countries and Israel.
  • FIGS. 18A-137 An example of health information exchange and integration system constructed and operative in accordance with certain embodiments of the present invention is now described with reference to FIGS. 18A-137 which may operate in conjunction with healthcare information integration software commercially available from dbMotion Inc., US Steel Tower, 600 Grant Street, Suite 22017, Pittsburgh, Pa. 15219, such as dbMotion's service oriented architecture (SOA) based dbMotionTM Solution.
  • SOA service oriented architecture
  • Unified Modeling Language is a standardized general-purpose modeling language in the field of software engineering used in generating the above drawings. The standard is managed, and was created by, the Object Management Group. UML includes a set of graphic notation techniques to create visual models of systems with software components.
  • FIGS. 18A-105D The CTS sub-unit of the example health information exchange and integration system is first described with reference to FIGS. 18A-105D .
  • FIGS. 18A-18B taken together, illustrate a Use Case Model—(Use Case diagram).
  • FIG. 19 illustrates an Actor View—(Use Case diagram).
  • FIG. 20 illustrates a CTS Runtime Use Case View—(Use Case diagram).
  • FIG. 21 illustrates CTS Metadata Service Use Cases—(Use Case diagram).
  • FIG. 22 illustrates a Get Service Address functionality (Use Case diagram).
  • FIG. 23 illustrates a Manage Extension functionality—(Use Case diagram).
  • FIG. 24 illustrates a Manage Named Query Metadata functionality—(Use Case diagram).
  • FIG. 18A-18B taken together, illustrate a Use Case Model—(Use Case diagram).
  • FIG. 19 illustrates an Actor View—(Use Case diagram).
  • FIG. 20 illustrates a CTS Runtime Use
  • FIG. 25 illustrates CTS Extension Use Cases—(Use Case diagram).
  • FIG. 26 illustrates a Fill Concept Information in Vocabulary Business Aspect—(Activity diagram).
  • FIG. 27 illustrates CTS Extended Solution Use Cases—(Use Case diagram).
  • FIG. 28 illustrates CTS First Analysis Use Cases—(Package diagram).
  • FIG. 29 illustrates a CTS Management Use Case View—(Use Case diagram).
  • FIG. 30 illustrates an Add Local Code functionality—(Activity diagram).
  • FIG. 31 illustrates a CTS Metadata Use Case View—(Use Case diagram).
  • FIG. 32 illustrates a Design Model—(Logical diagram).
  • FIG. 33 illustrates a Logical Model—(Logical diagram).
  • FIG. 34 illustrates a System—(Logical diagram).
  • FIG. 35 illustrates Services—(Package diagram).
  • FIG. 36 illustrates a Query Service—(Logical diagram).
  • FIG. 37 illustrates Service Contracts—(Logical diagram).
  • FIG. 38 illustrates an Execute Command functionality—(Sequence diagram).
  • FIG. 39 illustrates a Get Next Response functionality—(Sequence diagram).
  • FIG. 40 illustrates a Query Processor—(Logical diagram).
  • FIG. 41 illustrates a Service Contract—(Logical diagram).
  • FIG. 42 illustrates Metadata Services—(Logical diagram).
  • FIG. 43 illustrates an Information Service—(Logical diagram).
  • FIG. 44 illustrates a Management functionality—(Package diagram).
  • FIG. 45 illustrates an Analysis functionality—(Package diagram).
  • FIG. 46 illustrates Business Entities—(Logical diagram).
  • FIG. 47 illustrates a Client—(Logical diagram).
  • FIG. 48A illustrates a Service—(Logical diagram).
  • FIG. 48B illustrates Tools—(Logical diagram).
  • FIG. 49 illustrates a Framework—(Logical diagram).
  • FIGS. 50A and 50B illustrate a Tool API—(Logical diagram).
  • FIG. 51 illustrates a Shared—(Logical diagram).
  • FIGS. 52-57 taken together, illustrate an Information Model—(Logical diagram).
  • FIGS. 58-63 taken together, illustrate a Management Information Model—(Logical diagram).
  • FIG. 64 illustrates Management Data Contracts—(Logical diagram).
  • FIG. 65 illustrates Management Query Data Contract—(Logical diagram).
  • FIG. 66 illustrates a Management Query Data Contract—Functions Specification—(Logical diagram).
  • FIG. 67 illustrates Metadata—(Logical diagram).
  • FIG. 68 illustrates Metadata Query Objects—(Logical diagram).
  • FIG. 69 illustrates Metadata Schema Objects—(Logical diagram).
  • FIG. 70 illustrates Metadata PlugIn Objects—(Logical diagram).
  • FIG. 71 illustrates a Query—(Logical diagram).
  • FIG. 72 illustrates a Request Data Contract—Query Function Area—(Logical diagram).
  • FIGS. 73-78 taken together, illustrate a Request Data Contract—Query Functions Specification—(Logical diagram).
  • FIG. 79A illustrates a Response Data Contract—(Logical diagram).
  • FIG. 79B illustrates a Client—(Logical diagram).
  • FIGS. 80-83 taken together, illustrate Service Access Total Diagrams—(Logical diagram).
  • FIG. 79C illustrates a Management functionality—(Logical diagram).
  • FIGS. 84-86 taken together, illustrate Service Access functionality—(Logical diagram).
  • FIG. 87 illustrates a Query—(Logical diagram).
  • FIGS. 88-89B taken together, illustrate a Service Access—(Logical diagram).
  • FIG. 90 illustrates Client Basic Scenarios—(Use Case diagram).
  • FIG. 91 illustrates Execute Query functionality—(Sequence diagram).
  • FIG. 92 illustrates a Fill Query Data Set—(Sequence diagram).
  • FIG. 93A illustrates a Put Cached Items to Result and Correct the Bulk Parameters—(Sequence diagram).
  • FIG. 93B illustrates a Service—(Logical diagram).
  • FIG. 93C a Query Processor—(Logical diagram).
  • FIGS. 94-96 taken together, illustrate a Query Processor—Abstract Model—(Logical diagram).
  • FIG. 97 illustrates a Shared functionality—(Logical diagram).
  • FIG. 98A illustrates a Session Management functionality—(Logical diagram).
  • FIG. 98B illustrates System Services—(Logical diagram).
  • FIG. 98C illustrates a Metadata Service—(Logical diagram).
  • FIG. 98D illustrates a Query Processor—(Logical diagram).
  • FIG. 99 illustrates Frameworks—(Logical diagram).
  • FIG. 100 illustrates a Common functionality—(Logical diagram).
  • FIG. 101 illustrates Service Contracts—(Logical diagram).
  • FIG. 102 illustrates a Data Model—(Logical diagram).
  • FIG. 103 illustrates an Implementation Model—(Component diagram).
  • FIG. 104 illustrates a CTS (Logical diagram).
  • FIG. 105A illustrates a management functionality—(Logical diagram).
  • FIG. 105B illustrates a parameter—(Logical diagram).
  • FIG. 105C illustrates an exception—(Logical diagram).
  • FIG. 105D illustrates a model—(Logical diagram).
  • the CTS query use case Responsibility may include that it provides information about concepts in dbMotion ontology including Concept details and/or Search mechanism.
  • the CTS metadata service use case Responsibility may include that it provides metadata information about CTS service for consumer-services for integration in the design and runtime.
  • An Extension framework may provide the following Use Cases: Creation and developing of CTS extensions; and/or Internal product simple basic query extensions.
  • the first determining step may include some or all of the following operations:
  • the Design Model may include at least the Logical Model and the Data Model.
  • the Logical model included the System and Framework sections. Both may include classes and artifacts which define the structure of the code used in the application under development.
  • the Logical Model is a model of the software system under construction. It may include classes which generally have a direct relationship to source code or other software artifacts that can be grouped together into executable components.
  • the system package contains the classes and artifacts which are being built or designed as part of the current model.
  • the Frameworks package generally contains classes and components that have been designed and built earlier and are being reused as part of the current project.
  • current cache-optimization may include the following steps:
  • an Analyser may be operative for parsing and logical analyzing of query text.
  • Factory query object may work through Analyser.
  • a schema package typically contains a logical grouping of tablets.
  • This model describes the data which must be stored and retrieved as part of the overall system design.
  • this will mean relational database models which describe the tables and data in detail and allow generation of DDL scripts to create and setup databases.
  • the implementation Model defines how classes, artifacts and other low level elements are collected into high level components and the interfaces and connections between them.
  • Components are compiled software artifacts that work together to provide the required behavior within the operating constraints defined in the requirements model.
  • Components may be deployed to varying hardware platforms e.g. as described in the Deployment Model.
  • the Components package contains modeled components and their structural constituents. These include additional exposed interfaces, ports and other gateways or internal structural components. The connectivity and internal structure of these are further modeled in the internal Structures and Connections packages.
  • Internal structures provide a detailed view of possible internal workings and dependencies of a component. Using a Composite Structure diagram, they illustrate how the component fulfils its behavioral contracts and provides interface behavior to other components within the system.
  • the Connections package models the dependencies and connectivity between the various components, and how each is used as part of a co-operative system to accomplish required tasks.
  • Components expose interfaces and API's which are used by other Components.
  • the knowledge framework sub-unit of the example health information exchange and integration system is now described, referring back to FIGS. 9-13C .
  • the illustrated embodiment is an example implementation of the KFW subunit of FIG. 1A which is not intended to be limiting.
  • a Knowledge-Framework and Knowledge-Module Static Model are described, including business identifiers described with reference to FIG. 10A , an artifact described with reference to FIG. 10B , and a knowledge-Module Entities Model described with reference to FIGS. 10C-10F .
  • a KFW Business-Object-Model (BOM) is described with reference to FIGS. 11A and 11B .
  • a KFW Evaluation Interface is described generally with reference to FIG. 12A .
  • An Evaluation Request for the KFW Evaluation Interface of FIG. 12A is described with reference to FIGS. 12B-12C .
  • An Evaluation Response for the KFW Evaluation Interface of FIG. 12A is described with reference to FIGS. 12D-12E .
  • a KFW-Evaluation Process described with reference to FIG. 13A .
  • An Evaluation Plug-in Mechanism is described with reference to FIGS. 13B-13C .
  • KFW Knowledge-Framework
  • a KM contains a piece of clinical business-logic.
  • a KM has a well defined contract: a set of specified input data and a set of results.
  • KMs are modular and can be re-used, i.e., the output of one KM, can be used as input for another one.
  • the body of a KM is its decision-logic.
  • the decision-logic is based on input data and set the KM evaluation-results.
  • the decision-logic is created and managed by knowledge-experts (e.g., clinicians).
  • the decision-logic may use CTS ontology concepts. These concepts are defined implicitly as queries (commands) over dbMotion's CTS ontology only.
  • KFW consumers send requests to evaluate actual patient data.
  • the raw patient data is stored in dbMotion database using its local terminology.
  • the data e.g., a lab result
  • the data is pre-processed and enriched with a mapping to dbMotion's CTS ontology.
  • KFW asks CTS to evaluate the pre-defined CTS queries.
  • CTS returns a list of CTS ontology concepts.
  • KFW may check whether the patient actual data corresponds to one of the concepts in the result of the expected query.
  • KFW defines the following interfaces and allowed operations on CTS objects:
  • FW identifies its entities using identifiers, e.g. two types of identifiers, (a) and (b), as shown in FIG. 10A :
  • EntityIdentitifer identifies main entities and may include:
  • Artifact e.g. as shown in FIG. 10B , is used to store not-structured data or data that KFW is agnostic to its structure.
  • KFW internally operates on ‘Entities’.
  • KFW-Entities is an object-model mapped to a relational database.
  • the main entity in KFW is the ‘KnowledgeModule’ (KM).
  • KM extends from ‘ScopedEntity’ and hence is identified by an ‘EntityIdentifier’ (see above).
  • a KM may include some or all of the following members:
  • a CTS command is the main object to query CTS, e.g. as illustrated in FIG. 10F .
  • the command state is created at design-time by browsing CTS metadata service and selecting (or creating) a command.
  • the command is saved in an artifact.
  • the ctsItem calls CTS Query Service passing the command.
  • CTS returns a flat list of CTS ontology concepts that satisfy the command.
  • the method checks if the given item is included in this result list.
  • CTSExtensionalListItem typically comprises a hard-coded list of CTS ontology concepts and implements the contains( ) operation.
  • CTSIntensionalSingleItem typically comprises a hard-coded single CTS ontology concept and implements the sameConcept( ) operation.
  • KFW business-Object-Model
  • the data reaches KFW service as xml documents (in dbMotion's format) and is transformed internally into (Java) objects.
  • the model of this data is called the ‘Business-Object-Model’, or BOM in short.
  • Condition is a class in the BOM.
  • the BOM may refer to CTS concepts.
  • Condition.Code is coded using CS class.
  • CS class represents a CTS concept. At its root level it contains code and codeSystem attributes to identify a concept in a local terminology.
  • the CDTranslations composition contains translations of this concept to other terminologies. In particular, this collection contains the translation to dbMotion's CTS ontology.
  • CS class also implements the CTSConceptRT interface. Hence, operations sameConcept( ) and contains( ) that were defined on KM CTSItems can be applied on BOM attribute values.
  • the sameConcept(other) method in CS class is implemented by comparing the other.code+codeSystem attributes to CS root level attributes, or by finding an element in CDTranslations that satisfies sameConcept(other).
  • FIG. 11 is a diagram of an example class condition.
  • KFW Evaluation Interface is now described.
  • the evaluation interface of FIG. 12A is an example of a suitable interaction between KFW service and CTS.
  • the interface of FIG. 12A defines four evaluation methods. The flow in all methods may be similar, so for simplicity only the flow of the first method—evaluate( ) is described hereinbelow.
  • the method receives an EvaluationRequest and returns an EvaluationResponse.
  • An example EvaluationRequest is now described with reference to FIG. 12B .
  • KMEvaluationRequests includes a list of KM ids to evaluate in this request.
  • DRIData includes a list of patient data to use in the evaluation.
  • Each DRI in the request object refers to DRI of an existing KM (using DRI ID).
  • the data itself is enveloped in a SemanticPayload which includes a payload of data in xml element format.
  • the informationModelSSId specifies the actual format of the data.
  • FIG. 12C is an example of an EvaluationRequest in xml format. This is a request to evaluate a single KM, with a single DataRequirementItemData (DRIData) of type ‘Conditions’ which contains (in this example) a single ‘Condition’.
  • DRIData DataRequirementItemData
  • Condition.value is a CS element that carries a local (i.e., from legacy system) concept code.
  • CDTranslation element specifies a mapping to a dbMotion's ontology concept. This translated code may correspond to the CTS codes expected by the KM.CTSItems.
  • FIG. 12B An example EvaluationResponse is now described with reference to FIG. 12D .
  • FIG. 12B An example EvaluationResponse is now described with reference to FIG. 12D .
  • FIG. 12E illustrates an example of a KM evaluation result.
  • FIG. 13A is a top level simplified flow diagram of an example evaluation process.
  • EvaluationLocalBean is the class that implements the Evaluation interface. Typically:
  • FIG. 13B is a diagram of an example class manager. In the embodiment of FIG. 13B :
  • FIG. 13C A typical KFW-plug-in evaluation process is illustrated in FIG. 13C in which an AtomicEvaluationPlan is the implementation class of EvaluationPlan interface for evaluating a single KM.
  • a KM entity is passed in the constructor call. If the KM does not contain a compiled artifact, the sources have to be compiled. In practice, a compiled artifact is usually already set in production systems (it may be null only during the KM authoring stage).
  • EvaluationPluginManagerImpl is a singleton object that contains a map of decisionLogicType strings to DecisionLogicPluginProvider objects. This map is initialized from configuration. The plan asks the provider to get a compiler object. The compiler gets the KM entity and returns a compiled artifact. This compiled artifact is stored.
  • the plan asks the provider to provide an Evaluator object.
  • the Evaluator object is constructed from KM entity (expecting a not null compiledArtifact).
  • the Evaluator.evaluate( ) method is called passing the driData (extracted from the request).
  • the evaluator is state-less and the same evaluator can be used several times to evaluate different requests of the same KM.
  • FIG. 106A is a simplified functional block diagram illustration of the SmartWatch sub-unit constructed and operative to certain embodiments of the present invention.
  • FIG. 106B is a table describing operations, some or all of which may be performed by the system of FIG. 106A .
  • the SmartWatch sub-unit of FIG. 1A typically includes some or all of a SmartWatchservice unit, a data event monitor, a person identity service, a temporal monitor and an action manager.
  • a SmartWatchservice unit typically includes some or all of a SmartWatchservice unit, a data event monitor, a person identity service, a temporal monitor and an action manager.
  • These functional units are now described in detail herein, with reference to FIGS. 106C-114 , 115 - 123 , 124 - 130 , 131 - 134 , 135 - 137 respectively.
  • Various architectural views are provided, such as one or more, as appropriate, of the following UML-defined view: use-case view, a logical view, a process view, a deployment view, an implementation view and a data view, where:
  • the architecture of the SmartWatch service unit is typically designed to be a focal point of lifetime management/storage of all Guard instances and to concurrently process multiple Guard evaluation tasks for an assortment of member/task combinations, all as described in detail below.
  • Use-Case View Certain SmartWatchService use cases illustrating functions of the service based upon its population processing activities, some or all of which functions may be provided in any given embodiment, are now described. These use cases, referred to herein as use cases (i)-(x), and their associated actors are shown in the SmartWatch-wide high level use case diagram of FIG. 138 and in the use-case focused diagram of the SmartWatchservice of FIG. 139 .
  • the following use-cases employ multiple applications of the SmartWatch system, which may include SmartWatch Management GUI, Person Identity Service, and other components of the total system.
  • FIG. 106C Architectural Design Elements are now described (logical view), e.g. as shown in overview in FIG. 106C .
  • two layers, a business logic layer and a data access layer share a common set of entities.
  • the business logic layer (BLL) of the SmartWatchService contains a group of managers that perform at least certain functionalities of SmartWatchService.
  • the MonitorBrokerManager orchestrates requests from the other managers within the business logic layer to the external monitors for triggering rule matching and subscribing services.
  • the ServiceBrokerManager orchestrates requests to other external services.
  • the CallbackManager serves as a point for external services to send information to the SmartWatchService. Services for the business logic layer may include some or all of:
  • the processing manager receives items which contain both a member and a list of tasks that are to be processed for them. Each task contains a list of rules which are to be evaluated.
  • the MemberProcessingManager communicates with a Rule Evaluator to complete this, and returns a set of activities to execute for each member. An example of an activity could be to change a member's classification, or the send an action to the ActionManager.
  • the Data Access Layer typically handles storage for various entities. Entities stored here may include some or all of:
  • Processing of a known population element may comprise some or all of the following steps, suitably ordered e.g. as follows:
  • Processing of a general population element may comprise some or all of the following steps, suitably ordered e.g. as follows:
  • the data event monitor is now described with reference to FIGS. 115-123 .
  • the data event monitor (DEM) and Temporal Monitors typically provide a way to trigger patient evaluations in SMW. Any suitable implementation of such triggers may be employed, which may differ from those specifically described herein e.g. due to specifics of the interlaying system such as how the CDR is built and what other capabilities are. For example, triggering may occur when the incoming message is being processed rather than as described herein.
  • Subscriber accesses the subscription service. Subscriber may provide:
  • Patient Indices including the instructions for inclusion (population monitoring) or exclusion (population discovery).
  • Ping Interval What is the minimum time allowed between pings from the event monitor when triggering rules fire. This may be the anti-flood mechanism.
  • Processing may include the following operations:
  • Updates may be performed, e.g. as illustrated herein the diagrams of FIGS. 116-117A .
  • FIGS. 117A-117B are diagrams illustrating a basic flow of UpdateSubscription and UpdateSubscriptionIdentities functionalities respectively.
  • Event collection service manages all of the events that it gets from the providers. Providers work uncoupled from the Event Collection Service by knowing how to collect data from whatever source they are in charge of Modes may include a Push mode which is operative to receive data from source in real-time (ala CEBEventListener); and a Pull mode which is operative to retrieve proactively from source (ala CDR).
  • new events are collected from the source using a suitable conventional event collecting functionality such as the TableLookupEventProvider or OnlineCommandEventLoader Functionalities mentioned in FIG. 118A .
  • Record retrieval may be based on a sort of handle, which can be: timestamps, record number, or other identifier of the information source.
  • Activation is time-based.
  • OnlineCommandEventLoader adheres to the Online Source's policies. For example, proof may be demanded that the patient is actually being treated by a user of SmartWatch.
  • the Event Provider maps the new event data into the object model, and passes the object(s) to the Event Collection Service.
  • FIG. 118A is a diagram of a basic flow of a new event collection functionality.
  • FIG. 118B is a diagram of a basic flow of a by-criteria event collection functionality.
  • FIG. 119 illustrates a basic flow for an old event collection process.
  • consumer instructs Data Event Monitor to collect and process all data events based on a timeframe (issues a “Bootstrap” command).
  • Bootstrap command
  • the subscription may already exist separately before a Bootstrap is requested. All subscriptions for a subscriber are bootstrapped. Query the Data Provider for the events, typically by performing some or all of the following steps, suitably ordered e.g. as shown:
  • Harmonization and Matching proceed as normal, and when the “bootstrap” exclusion phase later runs within the matching processor, it may strip out any results for events that were triggered by any other subscription ID.
  • Results when delivered, may be sent at the subscriber level, or at a more finer-grained level, such as results for a specific task for a subscriber.
  • the bookmark is the batch number of the last batch that was closed during the last results retrieval.
  • the Data Event Monitor is called for more results with this batch number, it increments the number, and provides results from batch+1 onward, to the new most-recently-closed batch.
  • Event Handler looks at every result, and identifies the subscription id's for subscriptions and the ping time, if any. Attempt to add subscriber to “ping list” along with when the ping may happen. Set a timer at the subscriber level so that the ping will sound when it is supposed to. If the subscriber is already on the “ping list”, then if the pinging interval for this subscription is supposed to happen sooner than the “time left” on the ping list for that subscriber, overwrite the entry on the ping list. Otherwise, do nothing.
  • a Matcher then performs some or all of the following operations:
  • An example of a pattern rule processor might be a stored procedure in the working table.
  • Rule Processors are “keyed” in such a way as to say what working tables they support, and what subscription tables they support.
  • the matcher may compare the results against the members that the subscribers already have in the populations, and may remove these results from the final result set.
  • Another removal step is the “bootstrap removal phase,” where the matching processor removes results that were generated by subscriptions other than the subscription for which the event is keyed.
  • Another removal step is performed for deactivated subscriptions. This is typically performed as a separate step because patient monitoring rules abstract the individual patient when doing the matching, and only join them after the rule fires.
  • Results are delivered to the results table.
  • FIG. 121 is a diagram showing a basic flow for an event provision process operative in accordance with one embodiment of the present invention.
  • a New Pattern Rule is designed, typically by a human operator and translated into a Rules Processor (for example, a stored procedure).
  • Subscriber orders a “stop” for its subscriptions. This may affect all subscriptions that the subscriber has. Persist the “IsActive” field for each subscription object to false.
  • FIGS. 123A and 123B are subscription activation and de-activation basic flows, useful for implementing control rule execution use case (ix) according to certain embodiments of the present invention.
  • SmartWatch is operative to achieve automated decision support focused around population with common characteristics. SmartWatch relies on the functionality of gathering clinical data from diverse systems. SmartWatch is designed to operate under a significant design constraint—the reality in which a patient does not have a unique identifier across the enterprise. To meet this constraint SmartWatch communicates with conventional EMPI (Enterprise Master Patient Index) systems that know how to cluster patient identifiers (indexes) based mostly on probabilistic algorithms.
  • EMPI Enterprise Master Patient Index
  • the SmartWatch Person Identity Service serves as an arbitrator between SmartWatch and conventional EMPI systems.
  • the Person Identity Service is typically different to VIA, which is a commercial Virtual Identity Aggregation service provided by DBMotion, Israel. While VIA is an abstraction layer from concrete EMPI vendor implementation allowing dbMotion components to make an EMPI call using a unified API, Person Identity Service (PERIS), on the other hand, implements at least one additional functionality that is not part of the services proposed by EMPI vendors, namely a subscription capability to effect changes in person identity.
  • PERIS Person Identity Service
  • the Person Identity Service is typically operative to:
  • EMPI Enterprise Master Patient Index
  • clustering information about specific sets of people (patients) e.g. up to date cluster state information (on demand) and clustering changes information (publish subscriber pattern).
  • EMPI Enterprise Master Patient Index clustering changes over time is a constraint stemming from the nature of the distributed healthcare environment without a unique patient identifier. Since EMPI cluster changes, the service is operative to help its consumer(s) such as SmartWatch manage the information it keeps for the long run on patients, in various points in time, as such changes may change decisions being made.
  • a Use-Case View of the Person Identity Service is shown in FIG. 124 .
  • EMPI Enterprise Master Patient Index
  • the entry point is an index, related to as the principal index, and the outcome is the set of indexes currently associated with it by the EMPI provider.
  • VIA a commercial Virtual Identity Aggregation service provided by DBMotion, Israel
  • the EMPI provider is the sole authority according to which later decisions are made.
  • ARM Identity change rules subscriptions
  • ARM Accept subscription changes from consumers, and reflect them in the subscription database. This may include new subscriptions and modifications to existing subscriptions.
  • the subscriptions are meant to allow service consumers to be aware of changes to identity changes of persons (patients) that the consumer is interested in. For example, the consumer (SmartWatch Service) would like to be notified whenever EMPI (Enterprise Master Patient Index) system has made any change to a given patient of his (a member) such as join or split.
  • EMPI Enterprise Master Patient Index
  • the subscription includes a person index that identifies the person for the consumer and is also termed herein the “principal index”.
  • Use cases iii and iv are Deliver results use cases (ARM).
  • v. Maintain Patient Identities synchronizes system's knowledge of person cluster state with the EMPI (Enterprise Master Patient Index) provider.
  • EMPI Enterprise Master Patient Index
  • workflows may be employed here, depending on the capabilities of the EMPI provider, on performance requirements and allowed latency. Workflows may include: receiving regular updates on all person identity changes from EMPI provider (push updates); receive a snapshot of the cluster database from EMPI provider (push snapshot); proactively request cluster state for selected person(s)—whose state was not checked for a relatively long period of time (pull proactively); or some hybrid of the above.
  • the diagram of FIG. 125 illustrates the significant design packages and subsystems of the service.
  • the design packages of FIG. 125 typically include:
  • a. Business Logic Layer implements the business logic and provides the services described above.
  • ClusterResolvingService allows consumers to retrieve a person cluster which comprises a set of indexes that currently represent the same person according to an EMPI (Enterprise Master Patient Index) provider. This call may yield a call to EMPI provider (EMPI-Get), but may also be resolved within the service itself, in case the cluster is already known and reasonably up-to-date. Consumers may specify a time interval, which defines what ‘reasonably up-to-date’ means from their perspective.
  • EMPI-Get EMPI provider
  • Consumers may specify a time interval, which defines what ‘reasonably up-to-date’ means from their perspective.
  • ClusterResolvingService a service which allows EMPI (Enterprise Master Patient Index) providers, or some mediator process on their behalf, to communicate clustering changes to the system.
  • SubscriptionService implements publish subscriber pattern, allowing consumers to subscribe to identity change rules for selected people that they are interested in.
  • the subscription includes a principal person index as the identifier of the person of interest.
  • Data Layer A layer which handles the storage of the various entities in order for the system to function. Entities to be stored may include Subscriptions & subscribers (people of interest to subscribers); Indexes and their current clusters; and Results (i.e. indexes which changed and the subscriber relations.)
  • EMPI Enterprise Master Patient Index
  • Adaptors A package (typically a shared dll), overviewed in FIG. 126 , which contains interface as well as an out-of-the-box adapter operative to retrieve a cluster from the EMPI provider.
  • the EMPI adaptors package abstracts away from the system the exact details of how a “get” operation that retrieves a cluster, given that an index is performed in the specific project.
  • the implementing classes may be customized at the project level to accommodate the different EMPI configurations at different customer sites.
  • ClusterResolvingService a call is made to ClusterResolvingService. Within such a call the service may first check whether the cluster can be found at the DAL, and whether it is “fresh” enough for consumer requirements if any. If not, the cluster is retrieved from EMPI (Enterprise Master Patient Index) provider, stored and returned to consumer. In parallel, this starts an analysis process of cluster changes by the changes manager, one embodiment of which is illustrated in FIGS. 127A-127B .
  • EMPI Enterprise Master Patient Index
  • FIGS. 128A-128B An alternative flow, as shown in FIGS. 128A-128B , is returning the cluster together with changes being made that the consumer (also a subscriber) may be aware of.
  • the consumer supplies also subscriber id and a handle (timestamp or record number) to retrieve results by, the handle typically representing the latest knowledge of consumer for the given person.
  • ARM Identity change rules subscriptions
  • An UpdateSubscriptions call is made to Person Identity Service's Subscription service.
  • the service “persists” the subscriber, with its person interest in its subscription storage; typically this involves the service saving the subscription, comprising a subscriber or patient to be monitored, in storage.
  • FIG. 29 An example proactive flow is illustrated in FIG. 29 .
  • the proactive flow of FIG. 29 is significant when the EMPI (Enterprise Master Patient Index) vendor is unable to push updates to the system. It is realized by a call from a scheduling system to the ClusterUpdatesService typically under a suitable specialized interface termed herein ProactiveClusterUpdatesService.
  • EMPI Enterprise Master Patient Index
  • the passive flows (pushes from EMPI (Enterprise Master Patient Index) provider or a mediator on their behalf) are realized by calls to the ClusterUpdatesService, as illustrated in FIGS. 130A-130B .
  • the proactive flow (main flow) is realized by an internal process which looks for persons whose identity is outdated and queries them with EMPI vendor to update the system knowledge of the cluster state.
  • PersonIdentityService is deployed in one node and SmartWatchService(s) calls it remotely.
  • SmartWatchService wherever an individual SmartWatchService is deployed, PatientIdentityService is deployed as well, serving only that individual “local” SmartWatch system.
  • the two embodiments may be suitably combined.
  • the SmartWatch Temporal Monitor is now described, with reference to FIGS. 131-134 .
  • the monitor creates a component to facilitate SmartWatch execution of event driven tasks.
  • the monitor typically provides mechanisms for subscribing, publishing, and delivering the results using a pull and push model, all without losing results and without pushing results to wrong consumers.
  • FIG. 131A A Use-Case View of the SmartWatch temporal monitor is provided in FIG. 131A . An overview thereof is provided in FIG. 131B . Use cases of the temporal monitor may include some or all of the following:
  • SmartGuard Service requests the Temporal Monitor system to subscribe for one or more triggering rules.
  • ii. Schedule Tasks The use case starts with the “Manage Guard runtime” use case, when a guard is activated. At that time, typically, the system ensures guard tasks are being run according to schedule defined within the guard. The system would subscribe these requests similar to i. Manage triggering rules subscriptions use case.
  • This use case is triggered by a timer when the time calculated based on a subscription triggering rule elapses.
  • the elapse time event triggers a workflow typically including some or all of the following steps:
  • This use case starts as a result of receiving a consumer request for getting results delivered after the execution of prospective tasks scheduled based on the submitted by the consumer triggering rules.
  • the system searches the results repository using the criteria specified by the consumer.
  • the use case ends as the system delivers the results.
  • v. Notify consumers of new results The use case starts when the calculated subscription triggering rule fires and the subscription delivery preference is to use a push method. The results are pushed to the URI specified by the consumer. The use case ends as the system delivers the results.
  • FIG. 131B is a logical view of the temporal monitor according to certain embodiments of the present invention.
  • the temporal monitor typically comprises a service layer which exposes services and/or packages to its consumer e.g. SmartWatch, such as one or more of the following services and packages:
  • SubscriptionService service which provides functionality for managing the subscriptions and delivering the results to SmartWatch as a consumer.
  • SchedulingService façade that allows consumers (SmartWatch service) to store and remove subscriptions. Receives a scheduling request, validates it, and stores it into the subscription repository.
  • PatternRuleManagementService A service providing functionality for managing the Temporal Monitor triggering rules used by the system to create the subscription's prospective tasks executed by business layer at runtime.
  • a Business Layer encapsulates the Temporal Monitor business logic exposed as subsystems.
  • the subsystems include internal service providing functionality for managing subscriptions, monitoring execution of prospective tasks based on the subscription's triggering rules, and delivering the results to the consumer.
  • Functionalities which may be provided may include one, some or all of the following: a.
  • SubscriptionManager responsible for managing the subscription's lifecycle. Also the subsystem notifies the Runtime Manager subsystem of new subscriptions that need an initial prospective task to be stored in the prospective tasks repository and are ready for execution.
  • ResultManager (not shown): delivers results per user request or pushes the results to a consumer defined location (URI).
  • RuntimeManager Subscribes for notification events coming from the Subscription Manager subsystem or a prospective task elapsed time event. A business logic is applied to each event and a set of actions is executed. The next RR occurrence is computed and results are pushed to consumers.
  • a Data Access Layer (DAL) manages database access for the business layer.
  • DAL Data Access Layer
  • FIG. 132 is a diagram showing the basic flow of the Update Subscription functionality also termed herein the “schedule tasks” functionality.
  • the workflow is operative to manage triggering rules subscriptions.
  • the system receives a set of triggering rules subscriptions including the results delivery preferences (pull or push method).
  • the subscriptions are validated based on predefined business logic and stored in the subscriptions database.
  • the use case ends after the subscriptions are saved and a new Subscription Event is fired for all new subscriptions entering the system.
  • the event triggers the execution of a workflow that calculates the triggering rules e.g.
  • Calculate Rules use case iii of the temporal monitor. This results in creation of a new record in the prospective tasks repository and if the time of the new prospective task is closer than the “closest event” time held so far, the time is reset to the new prospective task's time.
  • This core use case typically employs the service, business, and data access layers.
  • the steps involved in this use case are outlined in the sequence diagram of FIG. 132 .
  • the Subscription Service After receiving a subscription request, the Subscription Service calls the subscription manager which performs subscription rule mapping, after successful subscription arguments validation the Subscription Manager constructs a subscription object which is passed to the Temporal Monitor data access layer. In case of a validation error, an exception is thrown describing the type of error.
  • This use case is triggered by a timer when the time calculated based on a subscription triggering rule elapses or when a triggered subscription change event is fired by the Subscription Manager. Steps which may be included in this use case are illustrated in the sequence diagrams of FIGS. 133-134 and may include some or all of the following steps:
  • the Runtime Manager gets the prospective task associated with the triggering rule.
  • the system stores the results into the Results database ready to be retrieved by the subscriber, or pushes the results to the subscriber ResultAwaitCallback service.
  • the Calculate Rule workflow calculates the next occurrence and saves it in the Prospective Tasks database.
  • Runtime Manager retrieves the earliest task from a prospective tasks database and sets the next time on the timer.
  • iv. Deliver results per consumer request In this use case the service would retrieve results from its result data base, based on the parameters supplied to it in the request (ARM compliant). The bookmark in this case is a timestamp.
  • v. Notify consumers of new results This use case is based on a callback to the subscriber, to a URI specified at subscription time. Based on subscription time preference, the results may be stored in the DB for the subscriber to pull them (ping mode) or just sent directly (push). The push mode is expected only for scheduling service subscription (in which the subscriber wants a “wake up call” but would not need to pull any information past that).
  • Maintain pattern rules This may be a manual process, performed by a developer who defines new triggering rule parameters, writes a handler that would know how to construct the proper subscription object from the input parameters, and registers the new rule.
  • the Action Manager carries out SmartWatch recommendations to the outside world by notifying human users or other systems about SmartWatch findings.
  • the Action Manager provides flexibility to PS developers in creating mechanisms to fit the specific client's policies and needs, including message structure, format and look & feel, channels, schedule, workflows. This lowers the cost of project implementation by promoting quick development cycle of (sometime complex) actions to meet a specific client's need (project versus product).
  • integration with the customer's current clinical workflow is seamless and the end consumer typically receives the messages within his day-to-day operational systems.
  • Implemented actions follow up on sent notifications to “close the loop” and ensure notifications are being appropriately used, including a notification consumers' feedback mechanism that would allow continuous system improvement and system tune up.
  • messages and notifications are not lost, notifications cannot be sent to wrong recipients, and message replays are allowed in the event of system error.
  • FIG. 135 is a logical overview of the Action Manager according to certain embodiments of the present invention. As shown, the action manager may comprise:
  • a. BusinessLogic Layer exposes services to its consumer—SmartWatch. Typically includes:
  • ActionMetadataService Provides consumer with metadata about the action manager. Used mostly by design time components such as SmartWatch management tool during SmartGuard editing.
  • ActionInvocationService A façade that allows consumers (SmartWatch service) to invoke actions supported by Action Manager, including receiving an invocation request, validating it and submitting the action for execution.
  • ActionDirectory An internal service which holds mapping between action definitions and concrete action implementations (usually a workflow but maybe a simple class). Used by ActionMetadataService in order to list actions and describe them. Used by ActionInvocationService in order to map action request parameters implementing workflow and validation rules.
  • ActionRuntimeManager An internal service which manages the running action workflow's lifetime. Starts off with action being submitted by ActionInvocationService and is operative to monitor, report, manage (e.g. lookup hanged workflows and stop them). Also includes set of tools & services to facilitate rapid development of workflows, to meet developer productivity goals.
  • Workflows & Formatters A package of customization in which concrete workflows and formatters (for content formatting) reside.
  • Communication Layers responsible for handling any communication the workflow employs. It may include some or all of the following types of communications:
  • Input which provide data to be included in notifications and to be used in workflow decision making
  • Output delivering notification to recipients in the outside world (humans or systems)
  • Response receiving messages from recipients (humans or systems) that include either acknowledgments or answers (from recipients) to specific questions included in notification.
  • the communication layer typically includes:
  • dbMotionServices & AdditionalServices are packages which supply workflow developer with a set of input communication to services it consumes.
  • the package contains service client proxies.
  • dbMotionServices are product-based (supplying access to services such as security, KNEO, dbMotion Business layer, PCP and so on), and AdditionalServices supplies customer-specific information sources.
  • NotificationDeliveryService delivers messages through delivery channels. It starts off with a notification request from a workflow, maps it to one of its delivery channels and assures reliable delivery, properly logged and so on.
  • a commercially available product such as a communication enabled business process (CEBP), may be used.
  • CEBP communication enabled business process
  • ActionResponseService allows recipients to influence the workflow by responding to it. Responses may trigger events in the corresponding workflow. Based on pluggable listeners that know to communicate responses back to the workflow. This subsystem typically includes a Response Listeners package in which customized listeners reside.
  • a Data Access Layer manages database access for business and communication layers.
  • This use case employs several services from the business and communication layers and also typically employs the DAL in recording any operation being executed and artifact being produced (notifications, recipients, . . . ).
  • FIG. 137A illustrates how actions are invoked by SmartWatchService, how the action request is validated and how the action request is submitted by the ActionInvocationService to ActionRuntimeManager.
  • ActionRuntimeManager initializes and starts the workflow e.g. as shown in the diagram of FIG. 137B which, for simplicity, does not include details of the workflow being run.
  • a typical action workflow may include decisions about who and what to communicate, including getting data to support decisions and to be included in the message, preparing message content (formatting), deciding on recipients, sending notification(s), waiting for responses and reacting to them.
  • FIG. 137C is a diagram of a notification delivery process.
  • the workflow has collected data, decided on proper notification mechanism and prepared a notification message (content formatted). It calls NotificationDeliveryService to manage the delivery of the notification to its recipient(s).
  • Action Response This use case starts when one of the Action Response Listeners receives an Action Response Message. The message is forwarded to ActionResponseService for processing the response. This in turn would trigger the action workflow (assuming the workflow is waiting for that response) or the ActionResponseService would trigger a new workflow to process the Action Response e.g. as shown in FIG. 137E .
  • FIG. 141 is a table of ontological relationships, defined in conventional, public SNOMED terminology.
  • the set of relationships in FIG. 141 is an example of semantic relationships, some or all of which may be used by the CTS subsystem of FIG. 1A . It is appreciated that this example is provided merely for purposes of clarification by way of example and, like many other examples provided herewithin, is not intended to be limiting.
  • the system shown and described herein typically but not necessarily uses conventional cache implementations such as Cache Application Block from Microsoft Enterprise library to provide client side caching functionalities in the CTS client subunit, which may be used by various of the SMW subsystems described herein.
  • Cache Application Block from Microsoft Enterprise library to provide client side caching functionalities in the CTS client subunit, which may be used by various of the SMW subsystems described herein.
  • HF heart failure
  • Example admitted HF patient sub-classifications are described below with reference to FIGS. 145A-145D , including triggering rules and other characteristics for entry and exit tasks.
  • An example of an LVS function evaluation method, including triggering rules and other characteristics for a monitoring task, is described below with reference to FIGS. 146A-146C .
  • An example ACEI or ARB for LVSD is described below with reference to FIGS. 147-150 .
  • An example sub-classification for temporarily discharged HF patients is described below with reference to FIGS. 151-152B , including triggering rules and other characteristics for entry and exit tasks.
  • Example vocabulary codes are described herein with reference to the table of FIG. 153 .
  • An example HF PATIENTS CLASSIFICATION is now described with reference to FIGS. 144A-144C , including triggering rules and other characteristics for entry and exit tasks.
  • An example Entry Task is now described.
  • Triggering Rules may include one or both of: Identify new HF problems—an example list
  • Triggering Rule may be:
  • KNEO may be:
  • An Exit Task for the HF patients classification may be as follows: Triggering Rules, each of which may be implemented in XML, may include some or all of: Identify cancelled HF Problems for specific patient—list of codes may be as above (CTS list for triggering rule). (No use of Condition.negationInd in UPMC); and Identify expiration of specific patient Is HF Patient KM: may be same as for the entry task.
  • Inputs may include: “Is HF Patient” KM evaluation result (Boolean Conclusion ER) Decision logic, in words and in pseudocode, may be as follows:
  • CTS may be as for the entry task.
  • Inpatient Encounters in specific Facility for specific Patient Is Eligible HF Encounter KM may be as follows: Inputs/Query Parameters are described in the table of FIG. 145A . Decision logic, in words and in pseudocode, may be as follows:
  • Encounter When Encounter is active OR Encounter discharge date is from the past 24 hours AND Encounter from a given facility AND Encounter deals with hospitalized patients (inpatient OR emergency) AND Encounter length of stay is less than 120 days AND Patient age exceeds 18 years (at the admission date)
  • the SW KM (smart watch knowledge module) e.g. as described below may save the encounter id (CPQP) in the classification.
  • the encounter id may be extracted from the IsEligibleHFEncounterER.Reasons. In general, only one encounter may be retrieved, but in exceptional cases more than one may be retrieved. In order to guarantee that the SW KM may only find one encounter id, enforce also a latest operation (on top of all other conditions).
  • the encounter id may be extracted from the IsEligibleHFEncounterER.Reasons. In general, only one encounter may be retrieved, but in exceptional cases more than one may be retrieved. In order to guarantee that the SW KM may only find one encounter id, enforce also a latest operation (in addition to all other conditions).
  • Outputs may include IsEligibleHFEncounter, whose type is Boolean Conclusion ER. Attribute names and values of outputs are described in the table of FIG. 145B . An example SmartWatch KM is now described. Inputs may include: “Is Eligible HF Encounter” KM evaluation result (Boolean Conclusion ER) Decision logic, in words and in pseudocode, may be as follows:
  • Triggering Rules may include: Identify if specific encounter was not active OR encounter type was changed OR discharge date not empty; and Temporal Trigger: Admission Date+120 days Is Eligible HF Encounter KM may be as described above with reference to the corresponding characteristic of the entry task.
  • An example SmartWatch KM is now described.
  • Inputs may include: “Is Eligible HF Encounter” KM evaluation result (Boolean Conclusion ER) Decision logic, in words and in pseudocode, may be as follows:
  • HF - 2 Evaluation of An example, also termed herein HF-2, of an LVS function evaluation method, including triggering rules and other characteristics for a monitoring task, is now described with reference to FIGS. 146A-146B .
  • Triggering Rules may include: Identify changes in the existence of LVS Function Evaluation Document for specific patient—list of codes, e.g. as for the triggering rule for the CTS described below, e.g. using a suitable XML implementation.
  • An example Evaluation of LVS Function KM may be as follows: Inputs/Query Parameters are described in the table of FIG. 146A . Decision logic, in words and in pseudocode, may be as follows:
  • the Quality Conclusion contains a vocabulary code. The code designation may be retrieved from dbMotion vocabulary by the consumer (EDR). The vocabulary may also hold the mapping between the code and the relevant category e.g. as shown in FIG. 153 .
  • Attribute names and values are described in the table of FIG. 146C .
  • An example SmartWatch KM for the LVS function evaluation method's monitoring task may be as follows: Inputs may include: “Evaluation of LVS Function” KM evaluation result Decision logic, in words and in pseudocode, may be as follows: In words: When always
  • KNEO may be:
  • KFW may include:
  • a Monitoring Task for ACEI or ARB for LVSD may for example be as follows: Triggering Rules, each of which may be implemented in XML, may include some or all of: Identify changes in ACEI or ARB Medications for specific Encounter—list of codes e.g. as described below with reference to the triggering rule for these medications. Identify changes in ACEI or ARB Allergies for specific Patient—list of codes e.g. as described below with reference to the triggering rule for these allergies. Identify negated OR cancelled HF Problem events for specific patient—e.g. as per exit task triggering rules for HF patient classification as described above. Identify changes in ACEI or ARB Contraindication Conditions—list of codes e.g. as described below with reference to the triggering rule for these contraindication conditions.
  • Inputs/Query Parameters are described in the table of FIG. 147 .
  • the list of codes for the first and second rows in the table may be as described herein for the CTS of the ACEI or ARB for LVSD monitoring task (KNEO for ACEI and ARB medications).
  • the list of codes for the third row in the table may be as described herein for the CTS of the ACEI or ARB for LVSD monitoring task (KNEO for diastolic dysfunction conditions).
  • the list of codes for the fourth row in the table may be as described herein for the CTS of the ACEI or ARB for LVSD monitoring task (KNEO for contraindications conditions).
  • the list of codes for the fifth and sixth rows in the table may be as described herein for the CTS of the ACEI or ARB for LVSD monitoring task (KNEO for ACEI and ARB allergies).
  • Decision logic in words and in pseudocode, may be as follows: In words: An example of a suitable decision table (in words) is provided in FIG. 148 . Codes translations may be as shown in FIG. 153 . In pseudo code:
  • Diastolic Dysfunction Conditions DRI is not empty Conditions/Condition/value/(code,codeSystem) Member In CTS list- 0 ACEI Medication Prescribed During Encounter? ACEI Medications DRI is not empty SubstancesAdministration/SubstanceAdministration/Medication/code/(code,codeSyst em) Member In CTS list e.g. as described herein with reference to the KFW of the ACEI and ARB medications. ARB Medication Prescribed During Encounter? ARB Medications DRI is not empty SubstancesAdministration/SubstanceAdministration/Medication/code/(code,codeSyst em) Member In CTS list- e.g.
  • ACEI Allergy ACEI Allergies DRI is not empty Allergies/AllergyIntolerance/value/(code,codeSystem) Member In CTS list - e.g. as described herein with reference to the KFW of the ACEI and ARB allergies.
  • ARB Allergy ARB Allergies DRI is not empty Allergies/AllergyIntolerance/value/(code,codeSystem) Member In CTS list e.g. as described herein with reference to the KFW of the ACEI and ARB allergies.
  • the Quality Conclusion contains a vocabulary code.
  • the code designation may be retrieved from dbMotion vocabulary by the consumer (EDR).
  • the vocabulary may also hold the mapping between the code and the relevant category e.g. as shown in FIG. 153 .
  • Attribute names, values and other characteristics are set out in the table of FIG. 150 .
  • An example of a SmartWatch KM for the monitoring task of the ACEI or ARB for LVSD is now described.
  • Inputs may include: “ACEI or ARB for LVSD” KM evaluation result
  • Decision logic in words and in pseudocode, may be as follows:
  • KNEO may be as follows:
  • Triggering Rule may comprise:
  • KNEO may comprise:
  • KFW may comprise:
  • Contraindication conditions list of contraindication conditions (ACEI and ARB) may be retrieved.
  • Triggering Rule may be:
  • KNEO may be:
  • KFW may be:
  • Diastolic dysfunction conditions list of diastolic dysfunction conditions (subset of HF conditions) may be retrieved.
  • KNEO may be:
  • KFW may be:
  • FIGS. 151-152B An example sub-classification for temp discharged HF patients is now described with reference to FIGS. 151-152B , including triggering rules and other characteristics for entry and exit tasks.
  • Motivation to support a business requirement to continue monitoring discharged patients for 24 hours after the discharge.
  • This sub-classification is a workaround for Dynamic Triggering Rule Parameters.
  • Parent Classification Admitted HF Patients.
  • An example Entry Task for the sub-classification for temp discharged HF patients is now described. Triggering Rules: Identify Completed Inpatient Encounters in specific Facility for specific Patient e.g. as per third and fourth triggering rules for entry task of admitted HF patients sub-classification, described above.
  • Inputs/Query Parameters may be as per row 1 in the table of FIG. 145A .
  • Decision logic in words and in pseudocode, may be as follows:
  • the Is Eligible HF Encounter KM may be divided into 2 KMs/rules that one of them is this one.
  • Outputs may include is DischargedHFEncounter, whose type is Boolean Conclusion ER. Attribute names, values, and other characteristics are set out in the table of FIG. 151 .
  • Inputs may include: “Is Discharged HF Patient” KM evaluation result (Boolean Conclusion ER) Decision logic, in words and in pseudocode, may be as follows:
  • Triggering Rules may include at least the following:
  • Is Discharged HF Patient KM as for the entry task.
  • An example SmartWatch KM for the exit task may be as follows:
  • Example vocabulary Codes for the embodiment of FIGS. 144A-152B are set out in the table of FIG. 153 .
  • FIG. 154 a is a simplified functional block diagram of a high level architecture of a smart agent system constructed and operative in accordance with certain embodiments of the present invention.
  • EMR is also termed EHR herein.
  • Data Analyzer Desktop Agent is also termed EHR Agent Host or SmartAgent host herein.
  • Agent Viewer is also termed EHR Agent User Interface or SmartAgent user interface herein.
  • a VPO Virtual Patient Object
  • a VPO is an Object, in the sense of object-oriented programming, that is retrieved by a Patient data services functionality and stores a patient's clinical History.
  • a VPO Analyzer is also termed EHR Agent Orchestration Web Service herein.
  • a VPO Business Domain is also termed Clinical Data Web Service or “Patient Clinical Data Services” or “Patient data services” herein.
  • WPF refers to a conventional computer-software graphical subsystem for rendering user interfaces such as but not limited to, for Windows-based applications, Windows Presentation Foundation.
  • PPOL refers to a Patient-Provider-Organization Link such as but not limited to that provided in DBMotion's commercially available HIE.
  • a medical domain typically comprises interconnected network of entities (e.g. as shown in FIG. 172 ) such as Providers (e.g., medical staff, clinician, nurse) providing care services to Patients, at medical Organizations (e.g., clinic, hospital).
  • Providers e.g., medical staff, clinician, nurse
  • the information about relations (Links) between medical entities is an integral part of healthcare information which facilitates intelligent services.
  • a PPOL may list patients being treated by a specific clinician, describe an organizational hierarchy of a medical unit, and return the PCP of a specific patient.
  • a Providers-Patients-Organizations Link (PPOL) computerized service typically provides and manipulates information about relations (Links) between medical entities.
  • a PPOL typically manages different entities and the relations between the entities in the medical domain, such as—for example—relationships between a patient's GP and the physician's office manager.
  • a PPOL typically does one or more of: connects to a conventional EMPI (Enterprise Master Patient Index) patient registry; provides a unique ID for patient and provider identities (aka cluster); stores provider-provider relations, e.g. office manager; stores provider-patient relations, e.g. PCP based on ADT messages; and acts as a providers' registry or connects to an existing such registry.
  • EMPI Enterprise Master Patient Index
  • the smart agent system of FIG. 154 a typically includes a client and a server, each including some or all of the illustrated blocks, interacting suitably e.g. as shown.
  • the SmartAgent client application typically intercepts EMR activities and recognizes EMR context e.g. user, patient and workflow e.g. as described herein in detail.
  • the PPOL module typically performs identity management including harmonization of different identifiers of entities.
  • the CTS terminologies and vocabularies module typically harmonizes local terminologies used in various data sources to the ontology used by the HIES e.g. the HIES commercially available from DbMotion, Israel.
  • the security authority block typically authenticates and authorizes user access to patients' clinical data.
  • the “get VPO” block typically retrieves patient data (e.g. VPOs—virtual patient objects) from repositories, which may be harmonized and/or federated, in the HIES.
  • smart agent is used herein to include an HIES-EMR bridging system according to any of the embodiments shown and described herein, which facilitates cooperation between HIES and a population of one or more EMRs with which the HIES interacts.
  • the smart agent may perform any or all of the following operations:
  • a. identify an application which has opened on a work station on which the HIES client is installed, as a medical service provider application e.g. EMR. This may occur because the EMR is compatible with a context sharing standard that the smart agent also supports or may be screen captured. Alternatively, APIs in the operating system may be available which define (assign an operating system name to) the relevant screen and/or fields within the screen, enabling the smart agent to identify the application.
  • the smart agent may find the patient identifier, e.g. by screen capture or by context sharing.
  • the smart agent retrieves the patient identifier by first recognizing the EMR page through which the patient user accesses the medical records and then, e.g. using prior knowledge re the location of the patient identifier on that page, capturing the user identifier.
  • filter available HIES information e.g. using suitable “attention rules”, to select suitable information to provide to the user identified in (b), pertaining to the patient identified in (c).
  • attention rules filter out either irrelevant information or superfluous (repetitive) information, or both.
  • the lab page may be identified by the hovering smart agent.
  • the smart agent may then display to the user only lab results which are not present in her EMR, optionally blinking to indicate that such exist and are available for viewing.
  • the hovering smart agent may intercept that the user is prescribing penicillin to a patient called Susan Smith and may then display only relevant information such as all allergies known for Susan Smith, or the subset of Susan Smith allergies pertinent to penicillin.
  • the SmartAgent user interface and behavior is designed to be floated on top of an instance of an EMR and not to interrupt the regular user workflow.
  • a Floating application within User, Patient and System Context e.g. as shown in FIG. 156 a , may be used as follows:
  • the User opens a patient record in the EMR.
  • a HIES client agent SmartAgent installed on the client machine “captures” the patient identifier (MRN), the User Context (Username/Role), and the System Context (SystemID) and calls the HIE's VPO Analyzer web service, which identifies the System, the User and the Patient.
  • MRN patient identifier
  • UserContext UserContext
  • SystemID System Context
  • the client SmartAgent gets the response and presents a Floating Application.
  • the Floating button includes a link to launch the HIE's Viewer with the user and patient context. 5.
  • the VPO (Virtual Patient Object) Analyzer of FIG. 154 a typically performs smart evaluations on the VPO in the context of the User, the Patient and the System, in order to provide more relevant and needed information to the User.
  • One of the VPO Analyzer's methods is “Exclude System Data”. This method excludes data from the VPO that already exists in the User's EMR. This results in “clean” data (excluding what user can already see in the EMR) that is presented within the Results or Viewer Panes.
  • the user looks for data on Diabetes (say) in the HIES. To do so, the User enables the Search option in the floating toolbar and types the phrase “Dia”. 2. Search suggestions are presented and user selects the “Diabetes” Suggestion. 3. As a result, the Results and Navigation pane opens and presents the results for Diabetes from the Patient's VPO, organized according to Clinical Aspects (Medications, Problems, Population Membership, etc). 4. The User clicks the “Diabetes” population. 5. The Diabetes View is opened in the View panel.
  • a process operative to Launch an HIES Viewer and CareBoard is now described. Any information found is presented in the Data and Navigation panel. The information is organized according to the different clinical aspects (Laboratory, Medications, etc.) and evaluation aspects (Population membership, Metrics, Notifications, Alerts etc.). The clinical aspects and actual presented data are links to the relevant page in the HIES's Clinical Viewer or Collaborate.
  • FIG. 154 b is a table summarizing an example set of functional requirements of a content/VPO analyzer included in the apparatus shown and described herein.
  • FIG. 154 c is a table summarizing an example set of functional requirements of a content capturing and sharing functionality included in the apparatus shown and described herein.
  • FIG. 154 d is a table summarizing an example set of functional requirements of a semantic search functionality included in the apparatus shown and described herein.
  • FIG. 154 e is a table summarizing an example set of functional requirements of a floating application included in the apparatus shown and described herein.
  • FIG. 155 a is a table summarizing an example set of non-functional auditing, security and localization requirements of apparatus shown and described herein.
  • FIG. 155 b is a table summarizing an example set of non-functional topological and pre-requisite requirements of apparatus shown and described herein.
  • FIG. 155 c is a table summarizing an example set of non-functional performance requirements of apparatus shown and described herein.
  • FIG. 155 d is a table summarizing an example set of non-functional reusability and integrability requirements of apparatus shown and described herein.
  • FIG. 156 a is an example user interface useful in entering a Patient File and launching the SmartAgent system provided according to certain embodiments of the present invention.
  • FIG. 156 b An example user interface for a FloatingClosed functionality is illustrated in FIG. 156 b .
  • An example object table useful in understanding the functionality of the user interface of FIG. 156 b is illustrated in FIG. 156 c . Footnotes in the first column of the object table of FIG. 156 c refer to suitably marked locations in the user interface of FIG. 156 b , respectively.
  • FIG. 156 d An example user interface for a FloatingSearchOpen functionality is illustrated in FIG. 156 d.
  • FIG. 157 a illustrates the SmartAgent application hovering on top of an example EMR (Allscripts Sunrise—commercially available EMR) in an expanded mode.
  • FIG. 157 b is an enlarged view of the expanded SmartAgent panel.
  • FIG. 157 c An example object table useful in understanding the functionality of the user interface of FIG. 157 b is illustrated in FIG. 157 c . Footnotes in the first column of the object table of FIG. 157 c refer to suitably marked locations in the user interface of FIG. 157 b , respectively.
  • FIG. 157 d is an Object Table.
  • FIG. 158 is a user interface for a laboratory screenshot of a preview panel useful in accordance with certain embodiments of the present invention.
  • the smart agent typically uses attention rules to determine whether or not to provide a user with an indication that aims to direct her or his attention to the fact that information relevant to her or him is available in the HIES.
  • the indication may include a highlight color in the background of the Name e.g. as shown in FIG. 159 a .
  • a rule can be built from a set of predefined filter types, such that a suitable predefined combination of the rules triggers the Attention indication and the relevant data presented by default.
  • FIG. 159 b is a table presenting an example set of basic rules.
  • FIG. 159 c is a table presenting an example set of rule combinations.
  • the indication may consider the filter types of FIG. 159 c which are combinations of the basic rules of FIG. 159 b.
  • Rule 1 Exclude my E.H.R. data: User is alerted if there is information in the HIES which does not exist in the user's EMR. Typically, the HIES stores an indication, for each information item, of the EMR which provided that information item, allowing information items provided by a user's EMR to be filtered out and not displayed to the user.
  • Rule 2 Exclude data irrelevant to workflow.
  • a health care providing user opens his EMR at a page pertaining to laboratory, medicine, Procedures, Allergies, Vital signs, Pathologies, Imaging results, Clinical documents, immunizations, Problems, Diagnosis, or any other EMR functionality.
  • the Agent hovers over the EMR application, intercepts the type of page opened, and selects from among the HIE information items available, only the ones which are relevant, using predetermined criteria, to the current EMR functionality.
  • Smart agent generates an alert if information which is new, relative to the point in time at which a particular health care providing user last looked at the HIES.
  • FIG. 160 a is a table of an example set of presentation use cases.
  • FIG. 160 b is a table of an example set of context interception use cases.
  • FIG. 160 c is a table of an example set of system health use cases.
  • FIG. 160 d is a table of an example set of data preparation, configuration & deployment, and extension development use cases.
  • FIG. 154 a The high level architecture of a smart agent system constructed and operative in accordance with certain embodiments of the present invention is illustrated in the simplified functional block diagram of FIG. 154 a .
  • the apparatus of FIG. 154 a may include some or all of:
  • VPO analyzer an addition to the VPO Web Services. is typically operative to filter and highlight pieces in the VPO which are considered important to be presented. It is typically based on GetVPO functionality and rules on those.
  • SmartAgent application A client-installed application. Typically comprises some or all of: a. SmartAgentHost—a windows try application that connects all the dots on the client machine b. SmartAgentPresentation—SmartAgent presentation Module (WPF) application c.
  • Context interception library Library Screen capturing interfaces. Its job is to capture events from EMR application such as patient context, and pass it on to the SmartAgentHost.
  • FIG. 161 which includes an Interaction example—User context interception sequence.
  • FIG. 161 and other figures herein are generated in Enterprise Architect UML format; it is appreciated that this does not limit the scope of the invention and is merely utilized as one possible format for demonstrating one possible example set of data structures and computerized processing methods useful for implementing the present invention.
  • FIGS. 162 , 163 a - 163 c , 164 - 166 An example use case model is now described with reference to FIGS. 162 , 163 a - 163 c , 164 - 166 .
  • FIG. 162 A Use Case Model Overview (Use Case diagram) is illustrated in FIG. 162 . “Perspective” Overviews are illustrated in FIGS. 163 a and 163 b including an actors overview diagram and a use case context diagram, respectively.
  • Configure & Personalize presentation options may include, inter alia: Presentations Skins Vs EH.R., Presentation rules and Base query, each of which is now described in detail according to respective embodiments of the present invention:
  • Presentation skins refers to an ability to customize the SmartAgent application appearance to have a plurality of different “look and feel”s.
  • end users want the EMR agent to appear on top of a given EMR with a look and feel which is similar to that of the EMR.
  • Presentation Rules refers to how the SmartAgent behaves to a given attention rule result—such as blinking frequency of alerts, or whether to blink and/or to expand the SmartAgent to view Clinical Data.
  • Base Query refers to filtering to obtain a VPO. Filtering can be by Time, or which clinical Aspects to obtain (e.g. filter to obtain only labs, or All Clinical Aspects).
  • the system may update to the smart agent applications scattered all over the network (and out of network for community clinics).
  • the smart agent may be installed on any suitable platform, such as a Citrix box.
  • setting up the agent may be controlled by configuring Citrix sessions, or by network login script.
  • Context Interception (Use Case diagram) is illustrated in FIG. 163 c , which is suitable for implementing the context interception functionality of FIG. 162 .
  • Context interception may include identification, e.g. as described below, of some or all of: (a) application, (b) patient e.g. as per FIG. 164 described herein, (c) user, e.g. as per FIG. 167 described herein, (d) workflow context, (e) patient interaction, (f) user-managed user interactions, e.g. as per FIG. 167 described herein, and (g) user details e.g. as per FIG. 166 described herein.
  • User identification may include interception of the users' details, and interception of user-managed user interactions.
  • Re “Identify Application” use case shown in FIG. 162 the system intercepts the application (EMR) which the user is using.
  • EMR application
  • This context may be captured from the EMR screen or provided by the EMR.
  • This same application can be used for multiple instances.
  • a Cerner app may be used in different “regions” in UPMC—Cerner H1, H2, H3.
  • the instance may be used when applying content rules such as “exclude mine”.
  • Re “Identify Patient” use case shown in FIG. 162 the system intercepts the patient that the user is currently looking at in the EMR. This context may be captured from the EMR screen or provided by the EMR.
  • Re additional “Identify Patient” use case shown in FIG. 162 the system intercepts the patient that the user is currently looking at in the EMR. This context may be captured from the EMR screen or provided by the EMR.
  • FIG. 164 is a Sequence diagram of an “Identify Patient” Interaction.
  • Re the “Identify User” use case shown in FIG. 162 the system intercepts the user that is using the EMR in order for the health information exchange system (HIES) to present data to that user, according security privileges as configured in the EMR.
  • HIES health information exchange system
  • This context may be captured from the EMR screen or provided by the EMR.
  • FIG. 166 is an Activity diagram of an “Intercept User Details” functionality.
  • FIG. 167 is a Use Case diagram of an “Identify User” functionality which is useful e.g. in conjunction with the “Identify User—managed users Interaction” use case shown in FIG. 162 .
  • Re the “Identify Workflow Context” use case shown in FIG. 162 the system intercepts the workflow in which the user is on the EMR side. For example, is the user on “labs” tab or on “medication” tab? This context may be captured from the EMR screen or provided by the EMR.
  • An advanced scenario here is responding to “free” selection on the screen, e.g. —user selects “Hgb” on the screen and history graph needs to be shown.
  • Re the “Apply Rules” use case: Typically, acting on patient data, the system decides which records are to be presented using attention rules e.g. as described herein. The system is typically able to add more rules and adjust existing rules.
  • Example rules include: —“exclude my EMR data” and —“exclude what I saw”, also termed herein the “new since last seen” rule.
  • Re the “Prepare Patient Data for presentation” use case typically, the system prepares data to be presented to the user. This includes fetching the data as well as filtering out irrelevant records, based on rules. This typically works in conjunction with the VPO analyzer of FIG. 1 a.
  • the “Develop & Configure EMR support” UC typically describes a possible need of the system to grow and support new EMRs, new versions of known EMRs as well as customized versions of known EMRs.
  • the support is focused on the interception of elements from the EMR screen.
  • the “Control floating application state” may for example include Minimize, expand, size, position, dock, close etc.
  • HIES health information exchange system
  • the launch may or may not include context (user, patient, app). For example—navigation menu for medications (even though no medication record is currently shown).
  • Perform Search UC the user searches for records within the patient record. The search can either be on the codified data, or free search over text (notes within acts and the content of clinical documents).
  • Present Clinician Data” UC the system presents data from the HIES that is not related to the patient viewed in the EMR. For example—“my recent events” from a Collaborate functionality in the HIES, “my admitted patients” and so on.
  • the system presents patient data to the user.
  • the user selects act to be sent to his EMR and the system delivers them to the EMR to be presented there.
  • the GetVPO service of FIG. 162 is an Actor which represents clinical services or Web Services which provides the ability to query and retrieve Patient clinical Data.
  • FIG. 169 is a logical diagram of the smart agent of FIG. 168 .
  • FIG. 170 is a logical diagram of the context entities of FIG. 169 .
  • the context entities package may serve as the data contract of the event model between all components.
  • EHRContext may comprise an entity (data) object representing the context of a specific EMR application.
  • EHRApplicationDetails may represent the application (EMR) details as intercepted.
  • EHRPatientDetails may represent the patient details as in the EMR intercepted.
  • EHRUserDetails represents the user details in the EMR as intercepted.
  • the screen capturing functionality of FIG. 169 typically comprises a library that implements in an IOC (Inversion Of Control) implementation of the Screen capturing interfaces. Its job includes capture of events from an EMR application such as patient context, and passing the patient content on to the AgentHost of FIG. 169 .
  • FIG. 171 is a logical diagram of the ScreenCapturing functionality of FIG. 169 .
  • the ScreenCapturingEHRContextInterceptor of FIG. 171 may comprise an interceptor based on conventional Screen Capturing technology which may operate the dlls and convert to .Net events as appropriate.
  • the ScreenCapturingEHRContextInterceptor of FIG. 171 may comprise any interceptor based on suitable Screen Capturing technology such as that commercially available from screenscraper studio, having a http presence on the world wide web at at: screen-scraper.deskperience.com// which is a software tool including a development kit that is capable of screen capturing actions.
  • the SmartAgentHost functionality of FIG. 19 typically is installed on the client machine, hosts the presentation layer and orchestrates the interaction between the presentation layer and the screen interception e.g. screen capturing.
  • FIG. 174 A logical diagram of controllers is shown in FIG. 174 .
  • FIG. 174 illustrates the engine and the corresponding configurations that execute and orchestrate the various interceptors shown and described herein.
  • the apparatus of FIG. 174 is useful in conjunction with the screen capturing functionality of FIGS. 169 and 171 .
  • FIG. 174 is particularly useful in understanding an example design of context interception, its classes and methods, and scenarios the context interceptor may support, such as but not limited to one or more of: user log-in, enter patient file, exit patient file, all according to certain embodiments of the invention.
  • the diagram of FIG. 173 describes, for the above scenarios, an initial step of getting the context and passing it to an EMR agent, so as to call VPO services, search patient and security, all in accordance with certain embodiments of the invention.
  • EHRContextManager of FIG. 174 , it is typically the responsibility of this class to orchestrate the context switches, bridging between context interceptors, presentation parts, and windows events, such as but not limited to:
  • the multiplicity of this class may be expected to be one per EMR window instance. (e.g. two Cerner windows would be assigned with two different context managers.
  • the RuntimeManager of FIG. 174 typically hosts the entire system. Its responsibilities include some or all of the following:
  • FIG. 176 A logical diagram of ContextInterception is illustrated in FIG. 176 .
  • the InterceptorConfiguration of FIG. 178 typically comprises an object which may be delivered to each interceptor when it is started. The configuration is stored and controlled.
  • the InterceptorConfiguration may hold a configuration of the Interceptor in the context of the EMR it intercepts.
  • An example configuration is as follows:
  • dbMotion server e.g. dbMotion server
  • the Server address is typically a URL which may for example have an http: prefix followed by, say: //ApplicationServer:9150/dbMotion/SmartAgent b.
  • the IEHRContextInterceptor of FIG. 178 is an interface; the responsibility of implementer of this interface typically includes discovery of context changes to a given EMR window instance.
  • the window's assigned context manager may be subscribed to the interceptor's events.
  • the IEHREventInterceptor of FIG. 178 typically comprises an “abstract” interface which only defines the minimal requirements.
  • the IMpl package of FIG. 178 includes out-of-box interception capabilities focused on interception of some or all of: application launch, application position change, internal proxies to external interceptors, including, e.g. active EMR or screen capturing vendor.
  • the responsibility of the implementer of this interface is to intercept the event of launching a known EMR application. Once launched, a dedicated EHRContextInterceptor may be created to the specific window.
  • the runtime manager may be subscribed to the OnApplicationOpened event.
  • the IEHRWindowStateInterceptor of FIG. 178 typically comprises an interface operative to allow the application to stick into the EMR window and track it as it moves.
  • the VPOAnalyzer is an addition to the VPO “family” e.g. clinical data services as described herein and is operative to filter and highlight important pieces in the VPO to be presented. It is based on GetVPO functionality and rules pertaining to that functionality, typically including some or all attention rules applicable to the patient clinical data retrieved as described herein in detail.
  • Example Framework and Contracts pertaining to the VPOAnalyzer may be appreciated with reference to FIG. 177 .
  • the AnalyzedPatientRecord of FIG. 177 typically provides a Data Contract for the VPO analyzer of FIG. 154 a , containing the VPO as well as the markup—the highlighted elements of the VPO.
  • the AnalyzerRuleHighlights of FIG. 177 typically holds the VPO markup highlights for an analyzer rule.
  • the HighlightedElement of FIG. 177 typically allows the rule to mark ⁇ highlight VPO elements to be presented according to their logic, for example—those that do not come from a given EMR.
  • the SystemIdentity of FIG. 177 typically comprises a data contract package which may optionally be part of PPOL of FIG. 168 .
  • FIG. 178 is an example Logical diagram for the SystemIdentity functionality of FIG. 177 .
  • Service & business layers may include the apparatus shown in the logical diagram of FIG. 179 .
  • the IVpoDataSource of FIG. 179 may comprise an interface which abstracts away the details of how the VPO is retrieved.
  • a BAC-based data source for deployment outside “business” areas is provided and a business-agent version may be used when integrated into business access services hence it can utilize internal features.
  • the SystemLinksManager of FIG. 179 may be part of the PPOL of FIG. 15 and typically comprises a manager responsible of providing configuration of system links and the relation between them.
  • the VPOAnalyzerManager of FIG. 179 may comprise a manager ⁇ controller responsible of orchestrating the VPO analysis process.
  • FIG. 180 is an example logical diagram of the rules functionality of FIG. 179 .
  • the AnalyzerRuleFactory functionality of FIG. 180 typically comprises a singelton class, serving as a factory for analyzer rules, based on configuration. The configuration may be based on CareManagement suite, which in turn may allow configuring different profiles and personalization.
  • the CareEventsGetterRule functionality of FIG. 180 typically comprises an analyzer “rule” which gets CareEvents based on a CareEvents query (which events are of interest? how far back?). It may merge its results to the upper level.
  • the OutsideEHRRecordsRule functionality of FIG. 180 typically comprises an analyzer which highlights those records which are out of reach in a given EMR.
  • the rule may be based on system links configuration, which may be part of the PPOL of FIG. 168 .
  • the UnseenRecordsVPOAnalyzerRule functionality of FIG. 180 typically highlights those records the user have not seen yet, based on information about entry to health information exchange system (HIES) applications, for example PLV records.
  • HIES health information exchange system
  • the VPOGetterRule functionality of FIG. 180 typically comprises an analyzer “rule” which is based on VPO query and a set of child analyzer rules which further analyze the fetched VPO.
  • the VPOGetterRule functionality of FIG. 180 typically merges its results to the upper level.
  • An example Use Case (UC) Realization process is illustrated in the Identify Patient UC realization sequence diagram of FIG. 181 .
  • An example server operative to Identify Patient UC realization is illustrated in the sequence diagram of FIG. 182 .
  • a particular advantage of certain embodiments of the present invention is that the EMR's code need not be changed because the apparatus of the present invention is able to intercept whatever context it employs from the EMR. Any suitable method may be employed for intercepting EMR context, such as but not limited to:
  • the architecture of the system shown and described herein includes one or more adaptors for context interception also termed herein “interceptors”, e.g. as shown in FIG. 176 , and therefore any such special adaptor can easily be incorporated into the architecture of the system shown and described herein, as an additional or substitute adaptor in FIG. 176 .
  • “Manual Intervention” typically includes a set of features in the Smart Agent which enable the system to locate, within a patient record, an item of information that may be relevant for the end user in the context of the workflow.
  • a health provider-user may be prescribing a new medication to the patient.
  • capturing the prescribed medication enables to search for a drug interaction or an allergy within the HIE patient record. It is appreciated that finding the relation between the prescribed medication in a given EMR and the ability to identify kind of relations to other clinical artifacts within the patient record, are not trivial, e.g. because the clinical concepts terminology is unknown to the HIE. Also, since the terminology used for the medication is unknown, there may be no ability to manage the relations to other clinical concepts.
  • the CTS subsystem of dbMotion's commercially available health information exchange system typically provides capabilities that make intervention in the EMR based on local terminology possible, including one or more of the following, all e.g. as described herein with reference to any or all of FIGS. 2-3 and 27 - 39 :
  • the SmartAgent is typically operative to present the user with an alert on an allergy to a prescribed medication by intercepting the medication name, locating its concepts in the CTS terminology as a local concept, locating the baseline ontology concept it relates to, locating the related ontology concepts of allergy and, using a given VPO, resolving if an individual patient meets this intervention rule.
  • This is an example of use of the semantics framework provided in the commercially available dbMotion health information exchange system, in order to perform workflow context interception.
  • Semantic Interoperability refers to the ability to translate data from multiple and varied Healthcare IT systems and then to organize such data in a meaningful way for display and analysis. This facilitates creation of a meaningful “virtual patient record” comprised of data from multiple source systems that can still be coherently organized and understood. Semantic Interoperability facilitates assimilation of data that originated in one system, into a different system.
  • Terminology of Semantic Interoperability used herein includes:
  • An HIE e.g. that commercially available from DBMotion, may be pre-configured with a Baseline Semantic Ontology (also termed herein a Baseline Ontology).
  • the pre-configured or “out of the box” (OOB) Baseline Ontology can be customized and configured by a user.
  • the Baseline Ontology typically represents a common language into which all data aggregated from source systems by dbMotion is translated (“Local to Baseline Translations”) and from which it is again translated (“Baseline to Local Translation”), if required, in the course of semantically meaningful data export (termed herein “semantic export”) to a destination system in a way that is consistent with the terminology used by that destination system.
  • the terminologies used by the source systems and the destination systems are termed herein Local Terminologies.
  • the Baseline Ontology is also used to group data and optionally to enable at least one of decision support, alerting, and population management.
  • the HIE does not import/export information about the relationships between codes:
  • the Local to Baseline Translations and the Baseline to Local Translations are concerned only with mapping terminology (codes).
  • the broader Semantic Ontology is exclusively in the Baseline Ontology—it can be customized if desired, but it is not impacted by the source or destination systems that are interconnected by the HIE system.
  • HIE's Semantic Interoperability may be provided by a Vocabulary Manager (VM) sub-system.
  • Terminology translation support may be limited to one-way translation (Local to Baseline Translation) and Semantic Ontology may be limited to basic grouping capabilities.
  • a Common Terminology Service may alternatively or in addition provide Semantic Interoperability by providing a Semantic Ontology functionality that provides both translation services and semantic relationship knowledge services throughout the HIE.
  • CTS Synchronization Service enables the CTS to co-exist side by side with a Vocabulary Manager system.
  • the CTS Synchronization Service may synchronize a newer CTS Baseline Ontology with the Vocabulary Manager system (CTS to VM) and also synchronize Local Terminology mappings managed within the VM with the CTS (VM to CTS).
  • Baseline codes that are not part of the Baseline Ontology (referred to as Proprietary Baseline Terminologies), these are typically mapped to the CTS Baseline Ontology concepts using a structured Baseline Mapping file provided by the HIE.
  • a CTS may support inter alia any or all of the following use-case scenarios:
  • Semantically harmonize aggregated medical/administrative data from multiple source systems e.g. by translating the source system local terminology to the Baseline Ontology (Local to Baseline Translation), as well as by using the Baseline Ontology to hierarchically organize certain data areas to facilitate grouping, filtering and sorting features.
  • Baseline Ontology Local to Baseline Translation
  • Baseline Ontology Hierarchically organize certain data areas to facilitate grouping, filtering and sorting features.
  • a destination system e.g. a particular EMR
  • the Baseline Ontology Terminology may for example be assembled by combining selected sub-sets of different well-known standard terminology systems (SMONED, RxNorm, LOINC, etc).
  • SMONED, RxNorm, LOINC, etc The specific subset of codes in the Baseline Ontology from within a given standard may be selected based on suitable criteria such as but not limited to some or all of the following:
  • the Table of FIG. 185 a is an example of origins of Baseline Ontology Terminology Components in an example HIE (the DBMotion HIE).
  • the Baseline Ontology Relationships or concept-relationship aspect of the Baseline Ontology may be maintained using a suitable toolset for ontology management such as OWL (Web Ontology Language), endorsed by the Worldwide Web Consortium (W3C).
  • OWL Web Ontology Language
  • W3C Worldwide Web Consortium
  • Relationships supported in the CTS may for example include some or all of the following:
  • Terminology Maps for translating bi-directionally between the Local Terminologies used by various source and destination healthcare IT systems and the Baseline Ontology.
  • the CTS may for example be pre-configured with a set of OOB (out-of-the-box) Terminology Maps that map between Local Terminologies used by Allscripts EMRs and the Baseline Ontology. Examples of such maps, e.g. for the DBMotion HIE, are set out in the table of FIG. 185 b.
  • Terminology Maps Any or all of the following methods may be supported for building Terminology Maps:
  • Semantic Interoperability typically provides a “central hub” type system as opposed to “myriad point-to-point” systems. Rather than creating mappings between every potential pair of relevant terminology code sets, a standards-based baseline may be provided from which and to which everything is translated. This means that far fewer mappings are used to translate “anything to anything”. Analogous is the difference between using a dictionary to translate every language to and from every other language and using just one dictionary (per each of n languages) from each language into a “universal common language” and back, which effectively translates between any 2 languages.
  • Terminology Services typically is limited to translating codes from one set to another, whereas Ontology also refers to relationships between those codes e.g. the hierarchy/grouping relationship that enables grouping together clinically related medications, allergies, etc. “Ontology relationships” may also be defined to enable a CTS to respond to a query such as “give me all the medications, conditions, and lab tests associated with Diabetes”.
  • HIE operates exclusively through a central Baseline Ontology, the HIE can define these relationships only once in the terminology of the Baseline Ontology and can then use the relationships for any Local Terminology used by any other source system.
  • Semantic Interoperability is not “point-to-point”. Thus, instead of mapping from and to every possible combination of source and destination code sets, only one mapping is performed, from any source/destination code set to/from the Baseline Ontology.
  • Semantic Interoperability is not limited to “terminology services” and instead provides an “ontology” of relationships between concepts within a given clinical domain (e.g. a hierarchy of medications), as well as across clinical domains (e.g. all medications, conditions, and labs associated with Diabetes).
  • a given clinical domain e.g. a hierarchy of medications
  • clinical domains e.g. all medications, conditions, and labs associated with Diabetes
  • Semantic Interoperability focuses on most frequently used codes and most important, as pre-defined relationships among codes. This allows efficient investment in maintaining mappings and reducing the almost infinite potential task of “mapping everything” to a manageable mapping agenda.
  • CTS Common Terminology Services
  • dbMotion HIE software module that powers its Semantic Interoperability capabilities
  • FIG. 186 is a simplified functional block diagram illustration of an embodiment of the invention showing a smart agent which may be constructed and operative in accordance with any of the embodiments shown and described herein, operative in conjunction with an HIE which may comprise any conventional HIE such as but not limited to DBMotion's HIE; and one or more conventional EMRs (E.H.R.'s).
  • HIE which may comprise any conventional HIE such as but not limited to DBMotion's HIE; and one or more conventional EMRs (E.H.R.'s).
  • the smart agent of FIG. 186 may include a client and server as shown; however, functionalities of these two may be interchanged as desired. Any suitable functional connection between the SmartAgent and the Entity Identity Management (EMPI) may be provided such as that described above with reference to FIGS. 164 and/or 168 . Any suitable functional connection between the SmartAgent and Security Services may be provided such as that described above with reference to FIGS. 167 and/or 168 . Any suitable functional connection between the SmartAgent and Patient Data Services may be provided such as that described above with reference to FIG. 168 . Any suitable interceptors may be employed such as the Context Interceptor processor described above with reference to FIG. 166 . The Client may be based in part on the apparatus of FIG.
  • EMPI Entity Identity Management
  • the ScreenScraping functionality which may include a context interceptor, SmartAgent Host and SmartAgent presentation client as described herein.
  • the SmartAgent Client may optionally be based on the Context Interceptor described hereinabove with reference to any or all of FIGS. 170 , 174 and 176 .
  • a suitable object model of the context which the context interceptor API of FIG. 186 may employ, is described above with reference to FIG. 170 .
  • the Web service component of the server may for example comprise the SmartAgent Presentation Server of FIG. 169 as described above.
  • the VPO analyzer component of the server may for example be implemented in accordance with the apparatus of FIG. 177 .
  • software components of the present invention including programs and data may, if desired, be implemented in ROM (read only memory) form including CD-ROMs, EPROMs and EEPROMs, or may be stored in any other suitable typically non-transitory computer-readable medium such as but not limited to disks of various kinds, cards of various kinds and RAMs.
  • ROM read only memory
  • EEPROM electrically erasable programmable read-only memory
  • Components described herein as software may, alternatively, be implemented wholly or partly in hardware, if desired, using conventional techniques.
  • components described herein as hardware may, alternatively, be implemented wholly or partly in software, if desired, using conventional techniques.
  • Any computer-readable or machine-readable media described herein is intended to include non-transitory computer- or machine-readable media.
  • Any computations or other forms of analysis described herein may be performed by a suitable computerized method. Any step described herein may be computer-implemented.
  • the invention shown and described herein may include (a) using a computerized method to identify a solution to any of the problems or for any of the objectives described herein, the solution optionally include at least one of a decision, an action, a product, a service or any other information described herein that impacts, in a positive manner, a problem or objectives described herein; and (b) outputting the solution.

Abstract

A method for using a health information exchange system which stores patient record data regarding a multiplicity of patients, to serve a first plurality of EMRs each interacting with an EMR community including a set of at least one EMR, the method comprising: for each individual EMR within the first plurality of EMRs, performing a computerized context interception process using a processor to intercept context from the individual EMR and to identify therewithin an event whereby a health provider using the individual EMR calls up an individual patient's record from said individual EMR; and responsive to identification of the event, using a computerized output device for providing patient record data, pertaining to the individual patient, to the health provider.

Description

    REFERENCE TO CO-PENDING APPLICATIONS
  • Priority is claimed from:
  • U.S. Provisional Patent Application No. 61/438,762 filed on Feb. 2, 2011, entitled: “Smart agent for EMR processing and methods useful in conjunction therewith”.
  • This application is a Continuation in Part of: U.S. patent application Ser. No. 12/840,806, entitled “Health information exchange and integration system and methods useful in conjunction therewith” and filed 21 Jul. 2010.
    • FIELD OF THE INVENTION
  • The present invention relates generally to systems for processing medical information and more particularly to computerized interactions with EMRs.
    • BACKGROUND OF THE INVENTION
  • Conventionally, information is transferred between an HIE and EMR via messages exchanged between the two systems. For example, an EMR may know how to import lab results from an HIES. An EMR may provide a tab in its main application, sometimes known as the “community tab” which enables a user to view, but not manipulate or import, HIE-provided information about a patient. Varying medical technology between the HIE and EMR, combined with a lack of ability to semantically resolve the variation, may impose limitations to these modes of information transfer.
  • According to Wikipedia, an Enterprise Master Patient Index (EMPI) is “a form of customer data integration (CDI) specific to the healthcare industry. Healthcare organizations or groups of them will implement EMPI to identify, match, merge, de-duplicate, and cleanse patient records to create a master index that may be used to obtain a complete and single view of a patient. The EMPI will create a unique identifier for each patient and maintain a mapping to the identifiers used in each record's respective system.” It has been claimed that by using an EMPI for “correctly matching patient records from disparate systems and different organizations”, it is possible to obtain “a complete view of a patient”.
  • Known technologies relevant to the field of the invention include context management, single sign-on, CCOW or Screen capturing method for context interception.
      • Other state of the art health information exchange and integration systems, and conventional technology pertaining to certain embodiments of the present invention, are described in the following publications inter alia:
    • 1. US20070118540
    • 2. US20090125555
    • 3. US20080189496
    • 4. WO2007010485
    • 5. JP6243152
    • 6. DE10163469
    • 7. US20040141661
    • 8. US20090080408
    • 9. US20040122709
    • 10. US20040122719
    • 11. US20040122787
    • 12. US20040122707
    • 13. Published US Application US20080046292;
    • 14. Published US Application US20050144043; and
    • 15. Published PCT Application WO/2007/084502.
  • Non-Patent Literature describing health information exchange through the use of semantic technology includes:
  •
    Comput Methods Programs Biomed., 2009, 93 (3), 297-312 #1
    XML technologies for the Omaha System: a data model, a Java
    tool and several case studies supporting home healthcare
    Vittorini Pierpaolo; Tarquinio Antonietta; di Orio Ferdinando
    Digital Society, 2009. ICDS ′09. Third International Conference, #2
    168-173
    Semantic Exchange of Medicinal Data: A Way Towards Open
    Healthcare Systems
    Puustjarvi, J and Puustjarvi, L
    Engineering in Medicine and Biology Society, 2009. EMBC 2009. #3
    Annual International Conference of the IEEE, 1726-1729
    Interoperability of personal health records
    Lahteenmaki, Jaakko; Leppanen, Juha and Kaijanranta, Hannu
    Information Technology: New Generations, 2009. ITNG ′09. Sixth # 4
    International Conference; 308-313
    Healthcare Applications Interoperability through Implementation of
    HL7 Web Service Basic Profile
    Hussain, M; Afzal, M; Ahmad, H. F; Khalid, N and Ali, A
    Computer-Based Medical Systems, 2009. CBMS 2009. 22nd IEEE #5
    International Symposium; 1-6
    Ontology-based approach to achieve semantic interoperability on
    exchanging and integrating information about the patient clinical
    evolution
    Miyoshi, N, Ferreira, A and Felipe, J. C
    Computer-Based Medical Systems, 2009. CBMS 2009. 22nd IEEE #6
    International Symposium; 1-6
    Semantic biological image management and analysis
    Chubb, C, Inagaki, Y, Cotman, C, Cummings, B and Sheu, P. C
    • Lähteenmäki, Jaakko, Leppänen, Juha, Kaijanranta, Hannu, “Interoperability of Personal Health Records” (2009) 31st Annual Int. Conference of the IEEE Engineering in Medicine and Biology Society, EMBC'09, Minneapolis, Minn., USA, 2-6 Sep., 2009, EMBC'09 DVD, 1726-1729.
    • Miyoshi, N. Ferreira, A. Felipe, J. C., “Ontology-based approach to achieve semantic interoperability on exchanging and integrating information about the patient clinical evolution”, Computer-Based Medical Systems, 2009. CBMS 2009. 22nd IEEE International Symposium on Issue Date: 2-5 Aug. 2009
    • Healthcare Services Specification Project (HSSP) Service Functional Model (SFM) Specification—Decision Support Service (DSS), Version 1.0, Sep. 27, 2006, available on the World Wide Web.
  • The disclosures of all publications and patent documents mentioned in the specification, and of the publications and patent documents cited therein directly or indirectly, are hereby incorporated by reference.
    • SUMMARY OF THE INVENTION
  • Certain embodiments of the present invention seek to provide a technical solution for the problem of allowing medical data to be effectively retrieved, stored, and presented to medical service providing users where the medical data exists in digital form within a plethora of non-compatible, partially overlapping software systems which are constantly being updated.
  • Certain embodiments of the present invention seek to provide an interoperability solution for medical databases, providing a health information exchange system typically storing complete, single and harmonized patient records, and easing access thereto by bringing relevant information to a user at points in time in which that information is useful and as part of her or his workflows.
  • Certain embodiments of the present invention seek to bring relevant context-based information from inside the health information exchange system to a user e.g. physician's working environment and workflows (typically EMR), rather having the physician leave his working environment and search for the information he needs in a Clinical Viewer as an external application.
  • Certain embodiments of the present invention seek to enhance effective software compatibility including reducing dependency on EMR vendors to customize their software products in order to integrate with the health information exchange system platform (Button, Smart Access, and other services).
  • Certain embodiments of the present invention seek to provide easy and efficient access to specific context-based patient information eliminating the need to navigate through many patient's views in an external application.
  • Generally, Health Information Exchange (HIE) is defined as the mobilization of healthcare information electronically across organizations within a region, community or hospital system. HIE provides the capability to electronically move clinical information among disparate health care information systems while maintaining the meaning of the information being exchanged. The goal of HIE is to facilitate access to and retrieval of clinical data to provide safer, more timely, efficient, effective, equitable, patient-centered care. To meet this goal, HIE providers develop computerized infrastructures and applications that enable the information exchange and viewing of exchanged information. As HIE solutions complement the EMR applications, the EMR and HIE vendors are looking for ways to integrate with each other in order to enable:
  • 1. Data exchange from the EMR the HIE and vice versa
    2. Integrate the information hold in hold in the HIE within the EMR application and user workflow
    3. Enrich EMR capabilities with the HIE solutions and services.
  • When an HIE solution is integrated with the EMR, both accessibility and User Context may be taken into account.
  • Certain embodiments of the present invention seek to provide an SOA-based platform that enables healthcare organizations and health information exchanges (HIEs) to integrate their information assets, through the creation of a virtual patient record by logically connecting a group of care providers and organizations without requiring the replacement of existing information systems. By providing ubiquitous access to integrated patient information, the solution virtually bridges gaps that often exist between inpatient/acute care and community care.
  • Typically, a single, virtual patient record contains complete and harmonized patient data by logically connecting a group of care providers and organizations without requiring the replacement of existing information systems. Smooth and easy access to the care-critical information stored in the HIE should be facilitated, by providing a user with relevant patient information at the point in time it is needed, as part of the clinical workflow.
  • The system shown and described herein may perform any or all of the above functionalities:
      • Provide important, relevant, context-based information from the HIE within a physicians' work environment and workflows (typically their EMRs)—as opposed to having the physicians leave their work environments and enter the HIE's Clinical Viewer functionality as an external application to search for the information needed.
      • Reduce the HIE's dependency on EMR vendors to customize their products in order to integrate with the HIE's platform (e.g. launch button, SSO, services).
      • Provide efficient access to specific context-based patient information, thereby eliminating the need to navigate through multiple clinical views in an external application such as a dbMotion Viewer.
  • The SmartAgent is a client application that is designed to meet the EMR users' need to get comprehensive and relevant clinical information on patients from sources of information which are not in their EMR, and in addition to serve as a gateway to HIE applications and solutions.
  • The client application, typically installed on the user's machine, is termed herein a SmartAgent client.
  • Examples of use scenarios include but are not limited to the following:
  • 1. Smart Button within User, Patient and System Context: User opens a patient record in his EMR. SmartAgent, which is installed in his client machine, “captures” the patient identifier (MRN), the User Context (Username/Role) and the System context (SystemID) and calls a VPO Analyzer web service or Virtual Patient Object Clinical Data Web Service) that identifies the System, user and the patient. The user is authorized and the patient is found in the health information exchange system. The Client SmartAgent gets the response and presents a Floating Button. The Floating button includes Link to Launch Viewer with user and patient context. The User presses the button and seamlessly accesses the health information exchange system's Clinical Viewer.
    2. VPO Analyzer attention rules: In order to bring more relevant information to the user, smart evaluations are typically provided on the VPO in the context of the user, patient and system. One of the Analyzer's attention rules may be “Exclude System Data” which excludes from the VPO Data that exists in the physician's own system. The response is “Clean” data excluding what a user can see in his EMR, which may be presented within the Results or Viewer Panes. The rule is typically constructed and operative to analyze the patient's clinical data and to alert the user in the SmartAgent client application that information that meets the rule exists and is available for viewing.
    3. Semantic Search: A user may for example be looking for data on Diabetes in the health information exchange system. To do that he enables a search option in the floating toolbar and type the phrase “Dia”. Search suggestions are presented and user selects the “Diabetes” Suggestion. As a result a “Results and Navigation” pane opens and presents the results for Diabetes from the Patient's VPO organized by Clinical Aspects (Medications, Problems, Population Membership, etc.). User presses “Diabetes” population and the Diabetes View is opened in the View panel.
    4. Data Presentation and Launch Viewer: Any information found may be presented in a Data and Navigation Panel. The information is organized according to the different clinical aspects (Laboratory, Medications, etc.) and evaluation aspects (Population membership, Metrics, Notifications, Alerts etc.). The clinical aspects and actual presented data may constitute a link to a relevant page in the health information exchange system's Clinical Viewer. The user can see under a Laboratory Results menu, a result for hbA1c from, say, a previous week. Aside from the result, 2 buttons may be provided, one to open the Laboratory Clinical View and another to open the Lab Result Page with the hbA1c history.
  • The present invention also typically includes at least the following embodiments:
  • a. A computerized system for supplying a human user with relevant, context-based patient information within the user's work environment and workflows.
    b. A system according to embodiment a wherein the user's work environment includes at least one EMR.
    c. A system according to embodiment b which does not require customization of the EMR.
    d. A system according to embodiment ‘a’ which supplies information without requiring the user to navigate through multiple clinical views in an external application.
    e. A system according to embodiment ‘a’ wherein the system includes a proactive apparatus which operates proactively, responsive to user context operations, to present relevant clinical information.
    f. A system according to embodiment ‘a’ wherein the system includes a processor operative to select relevant information including performing a computerized analysis of a computerized patient record and deriving, from the analysis, relevant clinical information which is presented to the user, whereas other clinical information is not presented to the user.
    g. A system according to embodiment ‘f’ wherein differentiation of relevant clinical information from other clinical information is based on at least one of the following: user context, profile, patient illness, ward context, EMR Workflow Context.
    h. A system according to embodiment ‘a’ and wherein the system is operative to provide information, within the workflow, on overall patient events and evaluations for each individual physician or user.
    i A system according to embodiment ‘a’ and also comprising at least some aspects of a skin application shown and described herein.
    j. A computerized method for supplying a human user with relevant, context-based patient information within the user's work environment and workflows.
    k. A method according to embodiment T wherein the user's work environment includes at least one EMR.
    l. A method according to embodiment ‘k’ which does not require customization of the EMR.
    m. A method according to embodiment T which supplies information without requiring the user to navigate through multiple clinical views in an external application.
    n. A method according to embodiment T wherein the method includes a proactive apparatus which operates proactively, responsive to user context operations, to present relevant clinical information.
    o. A method according to embodiment T wherein the method includes a processor operative to select relevant information including performing a computerized analysis of a computerized patient record and deriving, from the analysis, relevant clinical information which is presented to the user, whereas other clinical information is not presented to the user.
    p. A method according to embodiment ‘o’ wherein differentiation of relevant clinical information from other clinical information is based on at least one of the following: user context, profile, patient illness, ward context, EMR Workflow Context.
    q. A method according to embodiment ‘a’ and wherein the system is operative to provide information, within the workflow, on overall patient events and evaluations for each individual physician or user.
    r. A method according to embodiment T and also comprising at least some aspects of a skin application shown and described herein.
    s. A computer program product, comprising a computer usable medium having a computer readable program code embodied therein, the computer readable program code adapted to be executed to implement any of the methods shown and described herein.
  • Certain embodiments of the present invention seek to provide a decision making system including a system of logic including hierarchical semantic relationships, a plurality of systems of medical information which are provided in a plurality of local terminologies respectively, and a decision making apparatus for transforming the medical information in the local terminologies to transformed information usable by the system of logic and for using the system of logic to make at least one decision based on the transformed information, without translating the system of logic into the plurality of local terminologies. The term “terminology” is intended to include any scheme for representing medical information. The following terms and other terms defined herein may be construed either in accordance with any definition thereof appearing in the prior art literature or in accordance with the specification, or as follows:
  • Classification Type—A base set of classifications which all others derive from. The existing classifications are:
      • Candidate—represents a new population element entering the system.
      • ActiveMember—represents a member of the population currently being monitored
      • DormantMember—represents a member who is “sleeping” or currently active but not being monitored (in a dormant state)
      • Evaluation Task—an evaluation task combines a set of executable rules, an evaluation goal, activation, and a set of triggering rule subscriptions. When a member is associated with a task (by having a specific classification) the triggering rule subscriptions are sent to the Data Event Monitor for that member. When task processing is activated, if that member has had any matching triggering rules fire, the task is sent to be processed (along with the member details).
      • Member—The population element of a specific Guard, each member is tagged with its population source and contains a list of classifications.
      • Member Classification—Guard evaluation tasks are grouped by classifications. If a member belongs to a specific classification, that member has certain tasks associated with him or her.
      • Population Source—the source of members for the Guard, could be an external list, an enrollment service, or a data event monitor.
      • Triggering Rule Subscription—subscription for the Abstract Rule Monitor, contains a Pattern Rule Identifier and a set of subscription arguments.
      • Schedule—an alarm (scheduled or event based) used to activate processing for a particular evaluation task (or set of evaluation tasks).
  • DEM—data event monitor e.g. as described herein
  • EMPI—Conventional Enterprise Master Patient Index service
  • Principal Index—aka (also termed herein) Leading Index
  • VIA—a commercial Virtual Identity Aggregation service provided by DBMotion Inc., Israel
  • ACEI—angiotensin-converting enzyme inhibitors
  • LVS—Left Ventricular Systolic
  • LVSD—Left Ventricular Systolic Dysfunction
  • DBMotion—refers to a functionality which is either commercially available from DBMotion Inc., Israel and/or is shown and described herein. Other definitions, acronyms, and abbreviations useful in understanding certain embodiments of the present invention, are provided in the table of FIG. 2.
  • In accordance with an aspect of the invention, there is provided a health information exchange system comprising an apparatus for archiving health information using a health information encoding procedure only if the health information fulfills a criterion of frequent use; and an apparatus for using a first procedure to respond to queries pertaining to the health information which fulfills the criterion of frequent use and using a second procedure to respond to queries not pertaining to the health information which fulfills the criterion of frequent use.
  • In accordance with an aspect of the invention, there is further provided a health information exchange system comprising an ontological apparatus for defining and storing ontological link elements ontologically linking between individual health care information items within a first population of health care information items; an apparatus for receiving a second population of health care information items and for associating at least some individual items in the second population, with corresponding individual items within the first population of health care information items; and an apparatus for responding to queries regarding particular information items in the second population including translating the particular information items into items in the first population corresponding to the particular information items and using link elements linking the items in the first population corresponding to the particular information items to generate data pertaining to the particular information items in the second population.
  • In accordance with an embodiment of the invention, there is provided a system comprising an apparatus for making at least one health decision based on the queries.
  • In accordance with an embodiment of the invention, there is further provided a system also comprising apparatus for implementing the at least one health decision.
  • In accordance with an embodiment of the invention, there is further provided a system also comprising apparatus for making at least one health decision based on the queries.
  • In accordance with an embodiment of the invention, there is further provided a system also comprising apparatus for implementing the at least one health decision.
  • In accordance with an aspect of the invention, there is provided a health information exchange method comprising archiving health information using a health information encoding procedure only if the health information fulfills a criterion of frequent use; and using a first procedure to respond to queries pertaining to the health information which fulfills the criterion of frequent use and using a second procedure to respond to queries not pertaining to the health information which fulfills the criterion of frequent use. In accordance with an aspect of the invention, there is provided a health information exchange method comprising defining and storing link elements linking between individual health care information items within a first population of health care information items; receiving a second population of health care information items and associating at least some individual items in the second population, with corresponding individual items within the first population of health care information items; and responding to queries regarding particular information items in the second population including translating the particular information items into items in the first population corresponding to the particular information items and using link elements linking the items in the first population corresponding to the particular information items to generate data pertaining to the particular information items in the second population.
  • In accordance with an embodiment of the invention, there is further provided a method also comprising making at least one health decision based on the queries.
  • In accordance with an embodiment of the invention, there is still further provided a method also comprising implementing the at least one health decision.
  • In accordance with an embodiment of the invention, there is yet further provided a method also comprising making at least one health decision based on the queries.
  • In accordance with an embodiment of the invention, there is yet further provided a method also comprising implementing the at least one health decision.
  • In accordance with an aspect of the invention, there is provided a computer program product, comprising a computer usable medium having a computer readable program code embodied therein, the computer readable program code adapted to be executed to implement a health information exchange method comprising archiving health information using a health information encoding procedure only if the health information fulfills a criterion of frequent use; and using a first procedure to respond to queries pertaining to the health information which fulfills the criterion of frequent use and using a second procedure to respond to queries not pertaining to the health information which fulfills the criterion of frequent use.
  • In accordance with an aspect of the invention, there is yet further provided a computer program product, comprising a computer usable medium having a computer readable program code embodied therein, the computer readable program code adapted to be executed to implement a health information exchange method comprising defining and storing link elements linking between individual health care information items within a first population of health care information items; receiving a second population of health care information items and for associating at least some individual items in the second population, with corresponding individual items within the first population of health care information items; and responding to queries regarding particular information items in the second population including translating the particular information items into items in the first population corresponding to the particular information items and using link elements linking the items in the first population corresponding to the particular information items to generate data pertaining to the particular information items in the second population.
  • In accordance with an embodiment of the invention, there is yet further provided a computer program product wherein the method also comprises making at least one health decision based on the queries.
  • In accordance with an embodiment of the invention, there is yet further provided a computer program product wherein the method also comprises implementing the at least one health decision.
  • In accordance with an embodiment of the invention, there is yet further provided a computer program product wherein the method also comprises making at least one health decision based on the queries.
  • In accordance with an embodiment of the invention, there is yet further provided a computer program product wherein the method also comprises implementing the at least one health decision.
  • In accordance with an embodiment of the invention, there is yet further provided a method wherein the second population of health care information items are expressed in a local terminology and are mapped to a baseline terminology in which the first population of health care information items are expressed, to enable terminology interoperability at least when responding to queries.
  • In accordance with an embodiment of the invention, there is yet further provided a method wherein the baseline terminology is semantically enriched by associating semantic information therewith, the method also comprising generating conclusions about health information expressed in at least one local terminology by using the semantic information rather than by defining semantic relations for the local terminology.
  • In accordance with an embodiment of the invention, there is yet further provided a system in which only a subset of a universe of health information is archived.
  • In accordance with an embodiment of the invention, there is yet further provided a system wherein the apparatus for responding to queries uses a first procedure to respond to queries pertaining to the subset and uses a second procedure to respond to queries not pertaining to the universe of health information but not pertaining to the subset.
  • In accordance with an embodiment of the invention, there is yet further provided a system also including an end user interface allowing end users to define rules; and a decision support subsystem (DSS) interacting with the end user interface and using semantic capabilities of a baseline terminology in which the first population of health information items is encoded, to simplify definition of rules by the end users.
  • In accordance with an embodiment of the invention, there is yet further provided a system wherein the decision support subsystem comprises an Enterprise DSS which has a process cycle and which uses DSS rules to define all phases in the process cycle.
  • In accordance with an embodiment of the invention, there is yet further provided a method wherein the translating and the using is applied to a use case involving processing of Smart Guard Adapters, the processing including at least one of developing, defining and configuring.
  • In accordance with an embodiment of the invention, there is yet further provided a method wherein the translating and the using is applied to a use case involving a SmartWatch System, the use case including at least one of processing and monitoring health of the system.
  • In accordance with an embodiment of the invention, there is yet further provided a method wherein the translating and the using are applied to a use case involving Managing Guard runtime.
  • In accordance with an embodiment of the invention, there is yet further provided a method wherein the translating and the using are applied to a use case involving applying Guard changes.
  • In accordance with an embodiment of the invention, there is yet further provided a method wherein the translating and the using are applied to a use case involving task activation based upon a schedule.
  • In accordance with an embodiment of the invention, there is yet further provided a method wherein the translating and the using is applied to a use case involving identifying patients to be added to a defined population of patients.
  • In accordance with an embodiment of the invention, there is yet further provided a method wherein the translating and the using are applied to a use case involving monitoring a population of patients including determining if they need to be evaluated, evaluating them thereby to generate at least one evaluation result, and responding to the evaluation result.
  • In accordance with an embodiment of the invention, there is yet further provided a method wherein the health information encoding procedure includes mapping health information expressed in at least one local terminology to a baseline terminology to enable terminology interoperability and storing ontological information interrelating health information items expressed in the baseline terminology.
  • In accordance with an embodiment of the invention, there is yet further provided a system wherein the ontological apparatus includes interrelationships between clinical-level information items.
  • In accordance with an embodiment of the invention, there is yet further provided a system wherein the clinical-level information item comprises at least one health care information item specifying at least one of a disease, rather than only a class thereof, and a medication, rather than only a class thereof, such as “Left Ventricular Heart Failure”, rather than “Cardio-vascular disorder”, and “Amoxicillin 250 MG Oral Capsule [Amoxymed]”, rather than “Antibiotic”, respectively.
  • In accordance with an embodiment of the invention, there is yet further provided a system wherein the ontological apparatus maps at least one legacy concept expressed in local terminology to at least one ontology concept expressed in a baseline terminology thereby allowing queries on the level of a single legacy concept to be responded to, for example, the following legacy concept: (System: ICD9, Code: 428.9, Designation: HEART FAILURE NOS) may be mapped to the following Ontology concept: (System: SNOMED-CT; Code: 84114007; Designation: Heart failure (disorder). Very generic examples of classifications are “Disorder”, “Medicine”, “Procedure”; more specific classification examples are “Cardio-vascular disorder”, “Antibiotics” etc. Classifications do not identify a patient's clinical status; for example, it is not enough to say in a clinical record that the patient has “Cardio-vascular disorder” as there are many types of such disorders, and it is typically useful to know which disorder the patient suffers from, to decide how to treat it. Examples of clinical-level information items are “Left Ventricular Heart Failure”, “Amoxicillin 250 MG Oral Capsule [Amoxymed]”; these information items are sufficiently detailed to describe aspects of an individual patient's clinical status and/or treatment rather than mere classifications thereof.
  • Also provided is a computer program product, comprising a typically non-transitory computer usable medium or computer readable storage medium, typically tangible, having a computer readable program code embodied therein, said computer readable program code adapted to be executed to implement any or all of the methods shown and described herein. It is appreciated that any or all of the computational steps shown and described herein may be computer-implemented. The operations in accordance with the teachings herein may be performed by a computer specially constructed for the desired purposes or by a general purpose computer specially configured for the desired purpose by a computer program stored in a typically non-transitory computer readable storage medium.
  • Any suitable processor, display and input means may be used to process, display e.g. on a computer screen or other computer output device, store, and accept information such as information used by or generated by any of the methods and apparatus shown and described herein; the above processor, display and input means including computer programs, in accordance with some or all of the embodiments of the present invention. Any or all functionalities of the invention shown and described herein may be performed by a conventional personal computer processor, workstation or other programmable device or computer or electronic computing device, either general-purpose or specifically constructed, used for processing; a computer display screen and/or printer and/or speaker for displaying; machine-readable memory such as optical disks, CDROMs, magnetic-optical discs or other discs; RAMs, ROMs, EPROMs, EEPROMs, magnetic or optical or other cards, for storing, and keyboard or mouse for accepting. The term “process” as used above is intended to include any type of computation or manipulation or transformation of data represented as physical, e.g. electronic, phenomena which may occur or reside e.g. within registers and/or memories of a computer. The term processor includes a single processing unit or a plurality of distributed or remote such units.
  • The above devices may communicate via any conventional wired or wireless digital communication means, e.g. via a wired or cellular telephone network or a computer network such as the Internet.
  • The apparatus of the present invention may include, according to certain embodiments of the invention, machine readable memory containing or otherwise storing a program of instructions which, when executed by the machine, implements some or all of the apparatus, methods, features and functionalities of the invention shown and described herein. Alternatively or in addition, the apparatus of the present invention may include, according to certain embodiments of the invention, a program as above which may be written in any conventional programming language, and optionally a machine for executing the program such as but not limited to a general purpose computer which may optionally be configured or activated in accordance with the teachings of the present invention. Any of the teachings incorporated herein may wherever suitable operate on signals representative of physical objects or substances.
  • The embodiments referred to above, and other embodiments, are described in detail in the next section.
  • Any trademark occurring in the text or drawings is the property of its owner and occurs herein merely to explain or illustrate one example of how an embodiment of the invention may be implemented.
  • Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification discussions, utilizing terms such as, “processing”, “computing”, “estimating”, “selecting”, “ranking”, “grading”, “calculating”, “determining”, “generating”, “reassessing”, “classifying”, “generating”, “producing”, “stereo-matching”, “registering”, “detecting”, “associating”, “superimposing”, “obtaining” or the like, refer to the action and/or processes of a computer or computing system, or processor or similar electronic computing device, that manipulate and/or transform data represented as physical, such as electronic, quantities within the computing system's registers and/or memories, into other data similarly represented as physical quantities within the computing system's memories, registers or other such information storage, transmission or display devices. The term “computer” should be broadly construed to cover any kind of electronic device with data processing capabilities, including, by way of non-limiting example, personal computers, servers, computing system, communication devices, processors (e.g. digital signal processor (DSP), microcontrollers, field programmable gate array (FPGA), application specific integrated circuit (ASIC), etc.) and other electronic computing devices.
  • The present invention may be described, merely for clarity, in terms of terminology specific to particular programming languages, operating systems, browsers, system versions, individual products, and the like. It will be appreciated that this terminology is intended to convey general principles of operation clearly and briefly, by way of example, and is not intended to limit the scope of the invention to any particular programming language, operating system, browser, system version, or individual product.
  • Elements separately listed herein need not be distinct components and alternatively may be the same structure.
  • Any suitable input device, such as but not limited to a sensor, may be used to generate or otherwise provide information received by the apparatus and methods shown and described herein. Any suitable output device or display may be used to display or output information generated by the apparatus and methods shown and described herein. Any suitable processor may be employed to compute or generate information as described herein e.g. by providing one or more modules in the processor to perform functionalities described herein. Any suitable computerized data storage e.g. computer memory may be used to store information received by or generated by the systems shown and described herein. Functionalities shown and described herein may be divided between a server computer and a plurality of client computers. These or any other computerized components shown and described herein may communicate between themselves via a suitable computer network.
    • BRIEF DESCRIPTION OF THE DRAWINGS
  • Certain embodiments of the present invention are illustrated in the following drawings:
  • FIG. 1A is a simplified functional block diagram illustration of a health information exchange and integration system constructed and operative in accordance with certain embodiments of the present invention.
  • FIG. 1B is a table of sequence interaction descriptions useful in understanding the operation of the system of FIG. 1A according to certain embodiments of the present invention.
  • FIGS. 2 and 3 are a table and a diagram useful in understanding an embodiment of the CTS sub-system of FIG. 1A, a knowledge framework sub-system and a smart-watch sub-system, which interact with a core platform for processing medical information, such as the core platform product available from DBMotion Inc., Israel.
  • FIGS. 4A-8C are diagrams and other illustrations useful in understanding an embodiment of the knowledge framework sub-system of FIG. 1A.
  • FIGS. 9-13C are diagrams and other illustrations useful in understanding an example detailed implementation of the knowledge framework sub-unit of FIG. 1A.
  • FIGS. 14-17 are diagrams and other illustrations useful in understanding an embodiment of the Smart-watch sub-system of FIG. 1A.
  • FIGS. 18A-137 are diagrams and other illustrations which, particularly in conjunction with FIGS. 9-13, are useful in understanding an example health information exchange and integration system constructed and operative in accordance with certain embodiments of the present invention. Specifically:
  • FIGS. 18A-105 are diagrams and other illustrations useful in understanding an example implementation of the CTS sub-unit of FIG. 1A.
  • FIGS. 106A-137 are diagrams and other illustrations useful in understanding an example implementation of the smart-watch sub-unit of FIG. 1A. Specifically:
  • FIG. 106A is a simplified functional block diagram illustration of the smart-watch sub-unit constructed and operative to certain embodiments of the present invention.
  • FIG. 106B is a table describing operations, some or all of which may be performed by the system of FIG. 106A.
  • FIGS. 106C-114 are diagrams and other illustrations useful in understanding an example implementation of the smart-watch service unit of FIG. 106A.
  • FIGS. 115-123 are diagrams and other illustrations useful in understanding an example implementation of the data event monitor of FIG. 106A.
  • FIGS. 124-130 are diagrams and other illustrations useful in understanding an example implementation of the person identity service of FIG. 106A.
  • FIGS. 131-134 are diagrams and other illustrations useful in understanding an example implementation of the temporal monitor of FIG. 106A.
  • FIGS. 135-137 are diagrams and other illustrations useful in understanding an example implementation of the action manager of FIG. 106A.
  • FIG. 138 is a SmartWatch-wide high level use case diagram of SmartWatchService use cases and their associated actors provided in accordance with certain embodiments of the present invention.
  • FIG. 139 is a use-case focused diagram of the smart watch service illustrating SmartWatchService use cases provided in accordance with certain embodiments of the present invention.
  • FIG. 140 is a diagram of an example Knowledge-Module Entities Model from which a knowledge base repository for the KFW sub-system of FIG. 1A may be derived.
  • FIG. 141 is a table of typically conventional ontological relationships serving as an example of semantic relationships which may be used by the CTS subsystem of FIG. 1A.
  • FIG. 142 is an example of a pattern rule comprising a subscription snippet, in XML format.
  • FIG. 143 is an example of a pattern rule comprising a definition snippet, in XML format.
  • FIGS. 144A-153 are diagrams and other illustrations useful in understanding an example Enterprise Clinical Decision Support System which may utilize the SmartWatch subunit of FIG. 1A. In particular:
  • FIGS. 144A-144C illustrate an example HF (heart failure) patients classification including triggering rules and other characteristics for entry and exit tasks.
  • FIGS. 145A-145D illustrate example admitted HF patient sub-classifications, including triggering rules and other characteristics for entry and exit tasks.
  • FIGS. 146A-146B illustrate an example of an LVS function evaluation method, including triggering rules and other characteristics for a monitoring task.
  • FIGS. 147-150 illustrate an example ACEI or ARB for LVSD.
  • FIGS. 151-152B illustrate an example sub-classification for temp discharged HF patients including triggering rules and other characteristics for entry and exit tasks.
  • FIG. 153 is a table of Example vocabulary codes useful in the system of FIGS. 144A-152 b.
  • FIG. 154 a is a simplified functional block diagram of a high level architecture of a smart agent system constructed and operative in accordance with certain embodiments of the present invention.
  • FIG. 154 b is a table summarizing an example set of functional requirements of a content/VPO analyzer included in the apparatus shown and described herein.
  • FIG. 154 c is a table summarizing an example set of functional requirements of a content capturing and sharing functionality included in the apparatus shown and described herein.
  • FIG. 154 d is a table summarizing an example set of functional requirements of a semantic search functionality included in the apparatus shown and described herein.
  • FIG. 154 e is a table summarizing an example set of functional requirements of a floating application included in the apparatus shown and described herein.
  • FIG. 155 a is a table summarizing an example set of non-functional auditing, security and localization requirements of apparatus shown and described herein.
  • FIG. 155 b is a table summarizing an example set of non-functional topological and pre-requisite requirements of the apparatus shown and described herein.
  • FIG. 155 c is a table summarizing an example set of non-functional performance requirements of apparatus shown and described herein.
  • FIG. 155 d is a table summarizing an example set of non-functional reusability and integrability requirements of the apparatus shown and described herein.
  • FIG. 156 a is an example user interface useful in entering a patient file and launching the SmartAgent system provided according to certain embodiments of the present invention, including an example of how a smart agent may position itself vis a vis an E.H.R. according to certain embodiments.
  • FIG. 156 b is a simplified pictorial illustration of an example user interface for a FloatingClosed functionality
  • FIG. 156 c is an example object table useful in understanding the functionality of the user interface of FIG. 156 b.
  • FIG. 156 d is a simplified pictorial illustration of an example user interface for a FloatingSearchOpen functionality.
  • FIG. 157 a illustrates the SmartAgent application, according to certain embodiments of the present invention, hovering on top of an example EMR (Allscripts Sunrise—commercially available EMR) in an expanded mode, e.g. by presenting the smart agent's clinical data on top of the EMR e.g. as described herein with reference to FIGS. 156 a-156 c.
  • FIG. 157 b is an enlarged view of the expanded SmartAgent panel, according to certain embodiments of the present invention.
  • FIG. 157 c is an example object table useful in understanding the functionality of the user interface of FIG. 157 b.
  • FIG. 157 d is an example Object Table.
  • FIG. 158 is an example user interface for a laboratory screenshot of a preview panel useful in accordance with certain embodiments of the present invention.
  • FIG. 159 a is a simplified pictorial illustration of an example method for highlighting of the background of a patient's name field.
  • FIG. 159 b is a table presenting an example set of basic rules.
  • FIG. 159 c is a table presenting an example set of rule combinations.
  • FIG. 160 a is a table of an example set of presentation use cases.
  • FIG. 160 b is a table of an example set of context interception use cases.
  • FIG. 160 c is a table of an example set of system health use cases.
  • FIG. 160 d is a table of an example set of data preparation, configuration & deployment, and extension development use cases.
  • FIG. 161 illustrates an Interaction example—User context interception sequence, in Enterprise Architect UML format.
  • FIGS. 162, 163 a-163 c, 164-166 present an example use case model useful in conjunction with the system of FIG. 154 a.
  • FIG. 165 is an example table suitable for storing a timestamp per user and per patient according to certain embodiments.
  • FIG. 168 is a diagram of an example Design Model of a smart agent constructed and operative in accordance with certain embodiments of the present invention.
  • FIG. 169 is a logical diagram of the smart agent of FIG. 168 according to certain embodiments.
  • FIG. 170 is a logical diagram of the context entities of FIG. 169 according to certain embodiments.
  • FIG. 171 is a logical diagram of the ScreenCapturing functionality of FIG. 169 according to certain embodiments.
  • FIG. 172 is a pictorial diagram of a medical domain comprising an interconnected network of entities according to certain embodiments.
  • FIG. 173 is a table of the InterceptionEventDispatcher's operations according to certain embodiments.
  • FIG. 174 is a Logical diagram of controllers according to certain embodiments.
  • FIG. 175 is a table of Operations, some or all of which may be performed by the InterceptorsFactory functionality of FIG. 174.
  • FIG. 176 is a logical diagram of Context Interception functionality provided according to certain embodiments.
  • FIG. 177 is a diagram of example Framework and Contracts pertaining to the VPOAnalyzer of FIG. 154 a.
  • FIG. 178 is an example Logical diagram for the SystemIdentity functionality of FIG. 177.
  • FIG. 179 is a logical diagram of Service & business layers provided according to certain embodiments.
  • FIG. 180 is an example logical diagram of the rules functionality of FIG. 179.
  • FIG. 181 is an Identify Patient UC (use case) realization sequence diagram illustrating an example Use Case (UC) Realization process.
  • FIG. 182 is a sequence diagram of an example server operative to identify patient UC realization.
  • FIG. 183 is a top-level simplified flowchart illustration of a method of operation for the smart agent system of FIG. 154 a, according to an embodiment of the present invention.
  • FIG. 184 is a pictorial diagram showing parameters useful for defining EMR Agent shell window position relative to EMR application window according to certain embodiments.
  • FIG. 185 a is a table of example origins of Baseline Ontology Terminology Components in an example HIE according to certain embodiments.
  • FIG. 185 b is a table of Terminology Maps that map between Local Terminologies according to certain embodiments.
  • FIG. 186 is a simplified functional block diagram illustration of an embodiment of the invention showing a smart agent which may be constructed and operative in accordance with any of the embodiments shown and described herein.
  • FIG. 187 is a diagram illustration of an example CCOW context Interceptor according to certain embodiments.
  • FIG. 188 is a diagram illustrating filtering of clinical information whose source of information is a given EMR according to certain embodiments.
    •
  • Computational components described and illustrated herein can be implemented in various forms, for example, as hardware circuits such as but not limited to custom VLSI circuits or gate arrays or programmable hardware devices such as but not limited to FPGAs, or as software program code stored on at least one intangible computer readable medium and executable by at least one processor, or any suitable combination thereof. A specific functional component may be formed by one particular sequence of software code, or by a plurality of such, which collectively act or behave or act as described herein with reference to the functional component in question. For example, the component may be distributed over several code sequences such as but not limited to objects, procedures, functions, routines and programs and may originate from several computer files which typically operate synergistically.
  • Data can be stored on one or more intangible computer readable media stored at one or more different locations, different network nodes or different storage devices at a single node or location.
  • It is appreciated that any computer data storage technology, including any type of storage or memory and any type of computer components and recording media that retain digital data used for computing for an interval of time, and any time of information retention technology, may be used to store the various data provided and employed herein. Suitable computer data storage or information retention apparatus may include apparatus which is primary, secondary, tertiary or off-line; which is of any type or level or amount or category of volatility, differentiation, mutability, accessibility, addressability, capacity, performance and energy use; and which is based on any suitable technologies such as semiconductor, magnetic, optical, paper and others.
    • DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS
  • The following terms may be construed either in accordance with any definition thereof appearing in the prior art literature or in accordance with the specification, or as follows:
  • E.H.R, EMR: In the present specification and claims, these are used generally interchangeably in that any reference to one might also refer to the other, mutatis mutandis. A repository of computerized health/medical data including a multiplicity of patient records and an interface allowing a user e.g. physician to access such data and, typically, manipulate such data.
  • HIES, HIE: health information exchange (HIE) system such as DBMotion's HIES, typically including computerized apparatus accepting and storing information from, and providing information to, a plurality of EMRs.
  • Context: as in CCOW terminology, this term includes information which may be shared by or derived from a computerized system such as an EMR. This information may include who is operating the (e.g.) EMR (user context), who is the patient whose data is currently being processed/displayed by the EMR (patient context) and what operation (e.g. prescription, referral, other) the user is currently performing. “context interception”—obtaining, for a first computerized system such as a HIES, context from a second computerized system such as an EMR, e.g. by sharing or deriving, typically including a determination of how the information from the second computerized system is to be used or related to by the first computerized system. Example of context interception provided according to certain embodiments of the present invention: When an EMR enters a medical record, the smart agent may retrieve the patient identifier e.g. by first recognizing the EMR page through which the patient user accesses the medical records and then, e.g. using prior knowledge re the location of the patient identifier on that page, capturing the user identifier.
  • Business rule or business layer: As defined in Wikipedia, this term of the art simply refers to a computerized processing rule or layer of computerized processing respectively and does not have any financial connotation whatever.
  • Mrn: patient ID e.g. Medical record number.
  • EMR: electronic medical record.
  • There is thus provided, at least the following embodiments:
    • Embodiment 1
  • A method for using a health information exchange system which stores patient record data regarding a multiplicity of patients, to serve a first plurality of EMRs each interacting with an EMR community including a set of at least one EMR, the method comprising:
  • for each individual EMR within said first plurality of EMRs, performing a computerized context interception process using a processor to intercept context from the individual EMR and to identify therewithin an event whereby a health provider using said individual EMR calls up an individual patient's record from said individual EMR; and
  • responsive to identification of said event, using a computerized output device for providing patient record data, pertaining to said individual patient, to said health provider.
  • Context sharing used by Healthcare systems such as EMR and HIE solution's Context Interception processes are used commonly in the healthcare industry in order to insure synchronization for the clinical data presented for a given provider. In the healthcare industry, the context is commonly referred to a healthcare system (such as HIE or EMR), patient and user identifiers are intercepted by the HIE or EMR and are used to authenticate and authorize to user by given user context, to resolve the patient by the given patient identifiers, and to enable an automation of opening the patient file in the EMR. An example of this embodiment is described below with reference to FIG. 186 which is a diagram of an example component model, as well as in FIGS. 161, 166-167, 170, 174, 176.
    • Embodiment 2
  • A method according to embodiment 1 wherein said patient record data includes at least one information item which is tagged to indicate a source EMR which provided said information item to said health information exchange system and wherein said patient record data provided to said health provider is filtered so as to filter out said at least one information item if said information item's source EMR equals said individual EMR.
  • An HIE system may be built to aggregate a patient's clinical information from various sources (such as EMRs, lab systems, radiology systems, etc.), in order to enable a provider to view a complete set of clinical information on a given patient at the point of care. The clinical data aggregated into the HIE may additionally include Metadata that enables unique identification of the source system of each specific clinical data element (e.g. specific lab test done for a given patient, or prescribed medication).
  • In order to enable filtering of clinical information based on the source of the data, it may be possible to enable the system to request information to define the relevant filter condition. For example, if a provider would like to view given patient clinical information that does not exist in the provider's EMR system, and under the assumption the given EMR Data is aggregated into the HIE as any other clinical data source, the HIE may enable the clinical data web services to get as an input the EMR identifier which can be retrieved by the computerized context interception process described above. The response of the web service then typically excludes the EMR data. Typically, as described above, the HIE has the metadata of the given EMR which includes the source system identifier, in which case the clinical data service is able to exclude this EMR information, e.g. as described below with reference to FIGS. 154 a and 177.
    • Embodiment 3
  • A method according to embodiment 1 wherein said intercepting and identifying includes using a context management protocol.
    • Embodiment 4
  • A method according to embodiment 3 wherein said context management protocol comprises CCOW.
  • The Common Context Management protocol in the healthcare industry refers to HL7 CCOW. A SmartAgent CCOW Context interceptor is typically provided which is operative to register to a given CCOW Context Manager (e.g. Sentillion) and get synchronized with the context the Context Manager receives from other EMR or clinical systems register to the Context Manager. The methods for context interception from a context manager may include some or all of the following HL7 CCOW standard operations: Join context, Leave context, Follow context, Handle context termination and Handle “ping” request.
  • An example architecture of the SmartAgent CCOW context Interceptor is illustrated in FIG. 176. A diagram illustration of an example CCOW context Interceptor is provided in FIG. 187. The Endpoints in the mid area of FIG. 187 are optional SmartAgent Context intercepors, which may be an integral part of the SmartAgent Client of FIGS. 154 a and 176.
    • Embodiment 5
  • A method according to embodiment 1 wherein said health provider is served by a display screen when using said individual EMR and wherein said identifying includes capturing information from said display screen.
    • Embodiment 6
  • A method according to embodiment 1 wherein said identifying includes:
  • pre-storing a patient identifier location for each EMR within said first plurality of EMRs; and
  • capturing said individual patient's patient identifier from said patient identifier location.
  • Suitable methods for capturing information from said display screen are known e.g. in Windows operating systems which provide native API for elements displayed in the screen such as Windows, UI controls, and text within these controls. Additional available computerized solutions such as ScreenScraping Studio, described online at the following http location: screen-scraper.deskperience.com, capture elements from the screen in various different ways. Screen Scrapping tools such as Screen Scrapping studio, enable stating of a location within a screen or in correlation to an application's position on a given screen, and interception of the data within it.
  • The SmartAgent context interceptors infrastructure, e.g. as described in FIGS. 154 a, 169 and 170, may enable a Screen scraping context interceptor designed to intercept relevant context elements such as user and patient context, to apply suitable rules to refine and to validate intercepted information and to pass the intercepted information to the SmartAgent for application, user and patient resolving. The SmartAgent ScreenScrapping context interceptor typically intercepts both user and patient context.
    • Embodiment 7
  • A method according to embodiment 1 wherein said providing patient record data includes subscribing to events exchanged between the individual EMR and an operating system serving the EMR, ascertaining in real time at least one current EMR display operation and mimicking the EMR display operation when providing the patient record data.
  • The SmartAgent windows state interceptor of FIG. 176 typically uses operating system events to identify a relevant EMR now displayed. This identification is used by the SmartAgent to position itself on top of the EMR, e.g. by applying suitable position algorithms such as but not limited to providing a SmartAgent User Interface Shell container for a desktop application which uses some or all of the following parameters which are defined pictorially in FIG. 184:
      • Horizontal offset—horizontal offset of the specified Shell container window angle from the specified EMR window angle
      • Vertical offset—vertical offset of the specified Shell container window angle from the specified EMR window angle
      • EMR angle—one of the 4 angles of EMR window to anchor Shell container to
      • Shell angle—one of the 4 angles of Shell container window to anchor.
  • FIG. 156 a is an example of a smart agent positioning itself vis a vis an E.H.R. In the example of FIG. 156 a, the EMR is Allscripts Sunrise and the SmartAgent position in the top right, tuned by number of pixels from the top right corner of the EMR Application angles.
  • Interception configuration may be loaded at runtime from InterceptionConfig.xml file. The file may contain a list of configurations for known EMR applications. Every configuration may specify some or all of: Launch interceptor class type, Window state interceptor class type, Context interceptor class type and Shell container class type. Custom configuration XML blocks may be specified for each interceptor.
  • When a SmartAgent runtime manager instantiates an interceptor, the manager typically gets the interceptor's configuration class type and then deserializes custom XML block into instance of this configuration class type.
  • The SmartAgent runtime manager may process the configuration by performing some or all of the following steps:
  • a. Read all configurations
  • b. For each configuration gets Launch interceptor block
  • c. Instantiate Launch interceptor and assign unique identifier thereto
  • d. Save mapping between Launch interceptor identifier and whole configuration block
  • e. When a particular Launch interceptor fires an EMR opened event, the event gets a configuration block corresponding to this Launch interceptor
  • f. Context Interceptor, Window state interceptor and Shell blocks specified in the configuration block are read
  • g. 3 classes are instantiated accordingly
  • h. Read and instantiate custom configuration block for each of the 3 items
  • i. Configure each item with an instantiated custom configuration object
    • Embodiment 8
  • A method according to embodiment 7 wherein said EMR display operation comprises at least one of a translation along a display screen, a minimization of size and a maximization of size.
  • The position of the SmartAgent on top of the EMR is typically determined relative to the EMR's position and/or state on the screen e.g. as shown herein in FIGS. 156 a (minimized) and 157 a (maximized). A windows state interceptor functionality “listens” for any change in the state of the EMR window which may have occurred and changes the state of the SmartAgent accordingly. For example:
  • a. If an Operation system event of minimizing the EMR occurred, the SmartAgent may be minimized as well.
    b. If the user moved the window of the EMR 10 pixels to the left, Operation systems events occur and are intercepted, and the SmartAgent may move 10 pixels to the left as well.
    • Embodiment 9
  • A method according to embodiment 1 wherein said intercepting and identifying includes screen-capturing EMR context.
    • Embodiment 10
  • A method according to embodiment 5 wherein said patient record data includes at least one information item which is tagged to indicate a category of information to which said information item pertains,
  • and wherein said capturing includes capturing screen information indicative of a category of information currently being viewed by the health provider,
  • and wherein said patient record data presented to said health provider is filtered so as to filter out said at least one information item pertaining to a category of information other than the category of information currently being viewed by the health provider.
  • Context based viewing is typically based on information collected during the screen capturing. Presentation of information in a system based on context in a different system may be achieved by using screen capturing e.g. according to the following example workflow:
      • a. Health Provider Views Patient chart in his EMR
      • b. Health provider selects to view a tab such as the “Allergies” tab where the patient's allergies are displayed.
      • c. SmartAgent Screen scrapping configured to identify the Allergy (say) tab is selected and intercepts this workflow context. The context is passed to the workflow context interceptor e.g. as described herein in “Identify Workflow Context” FIGS. 160 b, 163 c, 169-170 and 181.
      • d. Workflow context interceptor performs “Allergy Selected” (say) action where the SmartAgent request discpatcher performs an action in the “Expand SmartAgent and open Allergy” category.
    Embodiment 11
  • A method according to embodiment 10 wherein said category of information includes at least one of the following group of categories: laboratory information, medicines, allergies, procedures, vital signs, pathologies, imaging results, clinical documents, immunizations, problems, and diagnosis.
    • Embodiment 12
  • A method for using a health information exchange system, storing patient record data regarding a multiplicity of patients, to serve a first plurality of EMRs each interacting with an EMR community including a set of at least one EMR, the method comprising:
  • For each individual EMR within said first plurality of EMRs, using a processor to automatically identify an event whereby a health provider using said individual EMR calls up an individual patient's record from said individual EMR; and
  • using a processor to apply at least one predetermined rule involving intercepted EMR context and using a computerized output device to provide an alerting indication drawing the health provider's attention to at least some of said patient record data according to said predetermined rule.
  • HIE systems consolidate typically large amounts of information per patient, from a wide variety of information systems such as EMRs, lab systems, imaging systems, etc. SmartAgent rules are typically applied on patient information arriving from the HIE to filter out irrelevant clinical information or information that already exits in the system the health provider is working on, e.g. a given EMR. These rules may apply various combinations of filters on the Patient Clinical data. Filters may for example include:
  • a. Time filters filtering out information that is outdated in the sense of healthcare; for example, 5 year old lab results are almost always irrelevant hence typically have a display priority which is lower than 5 year old allergy records which are often relevant; and/or
  • b. Source filters filter out information whose source system is the EMR itself.
  • Rules may be applied by the VPO Analyzer component e.g. as shown and described herein with reference to FIGS. 154 a-154 b, 159 c, 177, 180 and 188.
    • Embodiment 13
  • A method according to embodiment 12 wherein said generating an alerting indication comprises presenting patient record data, pertaining to said individual patient, to said health provider.
    • Embodiment 14
  • A method according to embodiment 12 wherein said predetermined rule comprises alerting said health provider's attention if said patient record data includes at least one item of information not included in said individual EMR.
  • Attention rules are components which may be provided, typically on the EMR Agent server side which typically runs rules on clinical acts in each VPO and marks clinical acts which meet the rule's conditions. The SmartAgent client application typically checks for pre-selected clinical acts and performs an action such as a basic “blink” action or “Expand the SmartAgent” or “Make Clinical acts Bold” if certain clinical acts meet certain rules. Example: the patient record includes 3 acts. An attention rule (“Rule 1”) states: “Mark (i.e. select) clinical acts NOT from my EMR”. Assume only Act 1 meets this rule. Act 1 is then marked in the VPO a Rule 1 annotation. The SmartAgent may then be configured to perform an action of flashing if it finds at least one clinical act that meet a certain rule e.g. rule 1 in the present example.
    • Embodiment 15
  • A method according to embodiment 12 wherein said rule involves health-provider specific context and wherein said applying includes identifying said health provider's identifier.
  • Such provider identification may be performed by the User Context interceptor of FIG. 181.
    • Embodiment 16
  • A method according to embodiment 14 wherein items of information included in said patient record data are stored in computerized storage, in association with respective information source tags indicating an information source supplying each said item, and wherein a determination is made, based on said information source tags, of whether or not said patient record data includes at least one item of information not included in said individual EMR.
  • As described above, data stored in the HIE can be identified as having arrived from a specific EMR source. The VPO Analyzer which is part of the SmartAgent service may use Clinical Data provided by the Clinical Data Services as described above, and metadata of each clinical data element (e.g. Specific Allergy) in order to filter clinical information whose source of information is a given EMR e.g. as shown in FIG. 188. For example, the VPO Analyzer may apply “Exclude my EMR” data and filter out clinical information whose source system, according to its metadata, is identical to the EMR identifier provided by the EMR Interceptor.
    • Embodiment 17
  • A method according to embodiment 16 wherein a list of information sources supplying an individual EMR is stored in computerized storage and wherein said determination includes determining whether all items in said patient record data are supplied by one of: said individual EMR; and an information source appearing in the list of information sources supplying the individual EMR.
  • In many cases, EMR Systems which serve as data providers or sources for an HIE, also receive clinical data from other systems. A common example is Lab Results clinical data that may be recorded in dedicated (non EMR) lab information systems.
  • The lab results are sent by the lab system and may be received by EMRs and also by the HIE. In this case, it is common to find information that already exists in the EMR, which was not sent by the EMR and also appears in the HIE. For such cases, a configuration may be provided which determines which EMR served as a source, which received information from other sources (e.g. a lab system). In order to apply a rule or filter such as “Exclude my EMR data”, this configuration may be used, so in addition to filtering clinical information from specific source, a filter is applied on sources that act as a source of the given EMR. In the present example, clinical information which arrives from the lab system which is acting as a source of the given EMR, may be filtered.
    • Embodiment 18
  • A method according to embodiment 15 wherein said predetermined rule comprises alerting said health provider's attention if said patient record data includes at least one item of information which was not seen by the health provider identified by said identifier when he was last served by said health information exchange system.
  • Additional Example of a rule is “show me only clinical data I (as provider) haven't seen on this patient”.
  • In order to filter out clinical information that a given provider has not seen for a particular patient, some or all of the following operations may be performed, suitably ordered e.g. as follows:
  • a. SmartAgent's user context interceptor intercepts user identifier e.g. as described herein with reference to FIG. 181.
    b. SmartAgent's patient context interceptor intercepts patient information and identifies the patient.
    c. For the given user and patient, systems get the Timestamp on which the user last accessed this patient
    d. SmartAgent service runs service clinical data service and gets patient's clinical data.
    e. SmartAgent service runs the “new acts since last seen” VPO Analyzer rule. If at least 1 clinical act date is later than the timestamp, the rule is applied, the correlated clinical record is marked with the relevant annotation of the rule, and the SmartAgent identifies those acts which are later than the timestamp and enables the alert.
    f. Provider views the patient's clinical data in SmartAgent. In order for the workflow to be applied the next time the provider enters the patient file, the SmartAgent saves the timestamp of the last time the provider saw the patient's data in the SmartAgent.
    f. Save last viewed timestamp for the given user and given patient. The timestamp per user and per patient can for example be stored in the table of FIG. 165.
    • Embodiment 19
  • A method according to embodiment 15 wherein said identifying said health provider's identifier employs single-sign-on authentication of said health provider.
  • CCOW and screen capturing are suitable methods to intercept user context as described above. User context intercepted thereby may include a user identifier which is used by information systems to automatically authenticate and authorize the user, including passing the user context to the information system security system for user resolution and authentication. User authentication may proceed as described herein with reference to FIGS. 154 a, 163 b, and 166-167. A single sign on process is advantageous because it facilitates a health provider's workflow by not requiring log-in credentials to be provided separately for each health system being used e.g. in the SmartAgent.
    • Embodiment 20
  • A method according to embodiment 15 wherein said identifying said health provider's user name includes capturing said health provider's identifier from a screen display employed by said health provider.
    • Embodiment 21
  • A method according to embodiment 1 wherein said intercepting and identifying includes providing an architecture which interacts with at least one context interception adaptor and, when operating in conjunction with a specific EMR having a specific context sharing capability, using an adaptor adapted to utilize said specific context sharing capability as said context interception adaptor. The Context interceptor architecture typically enables creation of a separate custom interceptor for each EMR, in the event that no out-of-the-box context interceptor meets the interception requirements of a given EMR. FIG. 171 is an example of an architecture of a custom context interceptor, termed a “Corner Context interceptor” that inherits interception capabilities from a parent class of EMR context interceptors. This custom context interceptor may be a plug-in into the SmartAgent Client service.
    • Embodiment 22
  • A method according to embodiment 1 wherein said context intercepted includes an indication of at least one display characteristic characterizing a graphic user interface being generated by the EMR and wherein said providing patient record data includes generating a graphic user interface for displaying said patient record data which shares said display characteristic.
  • The ability, also termed herein “skins”, to modify the look and feel of GUI based applications is often part of Development frameworks such as .Net and Java. The term “skins” refers to different colors, fonts, or other appearance preferences in which the application can be configured to be presented. In order to enable health providers to use their EMR with the SmartAgent, and experience the SmartAgent appearance to be similar to the EMR's, the SmartAgent enables different appearance configurations to be applied for each EMR, e.g. as described in FIG. 160 d (“Configure and personalize presentation options”), since different EMRs more often than not have different appearance characteristics.
    • Embodiment 23
  • A method according to embodiment 22 wherein said at least one display characteristic includes at least one of: a color characteristic, a texture characteristic, a text font, a text size, and a characteristic of an icon such as a button.
    • Embodiment 24
  • A system for using a health information exchange system, storing patient record data regarding a multiplicity of patients, to serve a first plurality of EMRs each interacting with an EMR community including a set of at least one EMR, the system comprising:
  • a record-call up identifying processor operative, for each individual EMR within said first plurality of EMRs, to automatically identify an event whereby a health provider using said individual EMR calls up an individual patient's record from said individual EMR; and
  • an intercepted context rule applying processor applying at least one predetermined rule involving intercepted EMR context and controlling a computerized output device to provide an alerting indication drawing the health provider's attention to at least some of said patient record data according to said predetermined rule.
    • Embodiment 25
  • A system for using a health information exchange system which stores patient record data regarding a multiplicity of patients, to serve a first plurality of EMRs each interacting with an EMR community including a set of at least one EMR, the method comprising:
  • a record-call up identifying processor operative, for each individual EMR within said first plurality of EMRs, for performing a computerized context interception process using a processor to intercept context from the individual EMR and to identify therewithin an event whereby a health provider using said individual EMR calls up an individual patient's record from said individual EMR; and
  • a record call-up identifying processor-driven output device controller operative, responsive to identification of said event, to control a computerized output device for providing patient record data, pertaining to said individual patient, to said health provider.
  • FIG. 1A is a simplified functional block diagram illustration of a health information exchange and integration system constructed and operative in accordance with certain embodiments of the present invention. FIG. 1B is a table of sequence interaction descriptions useful in understanding the operation of the system of FIG. 1A according to certain embodiments of the present invention. As shown, the health information exchange and integration system of FIG. 1A includes 3 typically symbiotic sub-systems namely a CTS sub-system, a knowledge framework sub-system and a smart-watch sub-system, which interact with a core platform for processing medical information, such as the core platform product available from DBMotion Inc., Israel. Embodiments of these subsystems are now described with reference to FIGS. 2-3, FIGS. 4A-8C and FIGS. 14-17 respectively. Detailed descriptions of example implementations of these three subsystems are described further on with reference to FIGS. 18A-105D, 9-13C and 106A-137 respectively.
  • First, an embodiment of the CTS sub-system is now described generally with reference to FIGS. 2-3. The CTS sub-system is also termed herein the SeNS or “Semantic Network Services” and may also be termed “semantic framework” and may include some or all of the following units, each preceded by their reference numeral in FIG. 3: 302 Query Façade; 304 Extendable specific query interface framework; 306 Metadata interface; 308 Generic query interface; 310 Get Concept; 312 Get Baseline; 314 Get SameAs; 316 Get ValueSet; 318 Custom Interfaces; 320 CTS Access Control; 322 Query processor; 324 Reasoner; 326 Local terminology; 328 Persistence layer; 330 Global Ontology; 332 Value Set; 334 Metadata service; 336 Notification engine; 338 Ontology extension; 340 Management Application; 342 Management Façade; 344 Navigation tool; 346 Mapping tool; 348 Approval process; 350 Add local concept interface; 352 CRUD interface for ValueSets; and 354 CTS Kernel. Typically, the chief functional breakdown of the CTS subsystem's function is Ontology (content), Querying and Management.
  • Possible considerations for designing the CTS subsystem of FIG. 1A are now described in detail.
  • The representation of medical information is a key issue in the use of computerized systems in healthcare. In everyday life, medical concepts are represented by words and phrases. This form of information representation allows a high degree of freedom but is difficult to use in computer systems. Phrases might be too long and are often inconsistent: ‘pain in lower abdomen’ could also be described as ‘complains of recurring pain in the lower part of the abdomen’. In order to avoid these problems, medical information saved in computer systems is codified. The process of codifying medical information involves the representation of medical concepts, such as observations or procedures, using a fixed code instead of free text.
  • A platform is described which addresses this by providing some or all of: robust information model, a repository of standard vocabularies, tools for searching for concepts, mapping tools to help map proprietary vocabularies to standard ones, tools for defining semantic neighborhoods and relation patterns between concepts, routine updates to vocabularies when released by the standards-development organization, and a set of semantic services such as some or all of: Managing local and Control Terminologies, Semantic Maps (mapping) between local and baseline (standard) concepts, Semantic Business Services, VPO Enrichment, Semantic Navigation (in Semantic Networks).
  • Semantic Interoperability includes ensuring that information exchanged between systems is understandable in the manner in which it was intended by the original creator of that information. It may enable systems to aggregate information from different sources and process it in a meaningful manner.
  • Semantic Interoperability between heterogeneous healthcare information systems is provided in accordance with certain embodiments. One of the primary obstacles to interoperability is the use of independent sets of terms and codes by the participating systems. When consumers of data (e.g. physicians, EMRs, workflows, Decision Support Systems, BI tools and more) refer to clinical concepts that originated from various sources, they cannot easily interpret, analyze, compare or rationalize this data for visualization. In other words, semantic information is lacking.
  • The problem of unified medical representation and clinical code mapping has become more and more crucial in the medical world. The effort of creating a global vocabulary and mapping local codes to baseline codes requires time, experience, and knowledge of clinical code standards and clinical terms. Therefore, it is desired to provide an ability to create such vocabulary artifacts easily, and to make the project of mapping flexible and controllable.
  • System goals may include some or all of:
  • A. Retrieve patient information: Typically, it is desired to bring together data from disparate clinical information systems in a uniform structure and semantics to support patient care, clinical decision support, and various secondary uses of clinical data such as research.
  • B. Semantic interoperability: Typically by creating solutions and services for a clinical decision support that makes use of the integrated, uniform data. The system described herein may comprise the integration point for data, and is privy to data that the various source systems are not. Thus, the system of the invention typically can provide enhanced decision support on top of the decision support that the source EMRs provide. This is done by creating solutions for the knowledge-representation and inference capabilities of existing commercial CDSSs.
  • An example of what may be achieved is the population of an electronic medical record or EMR A with an allergy—documented in EMR B—that patient Y has to medication X, the result of which is the ability of the decision-support component of EMR A to fire a drug-allergy alert when the physician writes a prescription for patient Y for a medication in the same allergy class as medication X. Unless EMR A understands the code used for medication X and has knowledge about the relationships between drugs and their allergy class, it cannot fire such an alert.
  • In order to accomplish the sharing of patient information and clinical decision support solutions, a semantic interoperability paradigm may be based on some or all of the following harmonized elements:
  • a. Unified Medical Schema—Ontology of medical knowledge that describes the information and semantics of a medical domain and maintains relations between different domains.
  • b. Vocabulary Ontology—A natural continuation of the UMS, which describes the medical terminology ontology. This ontology utilizes and adheres to well-adopted and advanced standards and methodologies (such as SNOMED, LOINC, HL7 v3, UMLS etc.).
  • c. Common Terminology services (CTS)—Services that maintain cross-terminology mappings enabling interpretation and translation of information encoded in different terminology systems (such as but not limited to industry known systems e.g. SNOMED, LOINC, ICD and proprietary coding systems). CTS typically includes and incorporates Semantic Network Services (SeNS): services based on medical terminology ontology, providing semantic navigation capabilities that allow interpretation of medical information. Therefore, CTS and SeNS are used herein generally interchangeably.
  • The platform described herein typically enables clinicians to draw conclusions based on a meaningful and unambiguous presentation of information, and serves as the foundation for clinical rules and alerts based on the aggregated information. The system is typically vocabulary agnostic, working with a broad range of standards, coding methods, and vocabularies.
  • The first step in accomplishing the sharing of patient information and clinical decision support solutions may include Unified Medical Schema such as the UMS of DBMotion as a uniform structure for data. The UMS is, in the terminology of data modeling, a logical data model. The UMS may be created by using the HL7 version 3 Reference Information Model as a starting point.
  • As part of the implementation process of the above solution, human designers together study the structure of the data from the client's EMRs (and other systems to be integrated) and map or translate those structures to the unique structure of the UMS. For example, this process might involve looking at various HL7 v 2.x messages, finding various data elements such as drug code and medical record number and mapping the fields in the messages that contain these data elements to the appropriate data elements in the UMS. In this way, all the information in the network has one unique representation and thus can be shared among different users within different systems and organizations.
  • The Vocabulary Ontology describes the medical terminology network. The vocabulary ontology is based on a data model that represents concepts, concept relations, coding systems and contexts. The content of the ontology typically includes some or all of:
  • a. UMS, such as dbMotion UMS's, domains and related concepts together with coding systems and other attributes associated with them
  • b. relations between concepts to represent all logic employed by a particular medical application
  • c. Grouping of concepts for creating contexts.
  • This ontology may serve as a foundation for the CTS subsystem.
  • Accomplishing a uniform structure and semantics for data also typically relies upon a solution to the “vocabulary” problem, where different systems use different codes (or “words”) to refer to the same entities. For example, when two different EMRs (Cerner and EpicCare) use different codes for the class of medications known as atorvastatin 80 mg oral tablet: Cerner—7247, EpicCare—045772. Typically, the CTS subsystem includes some or all of the following functionalities:
  • a. Managing of local Terminologies for each operational system within all nodes defined.
  • b. Maintaining cross-terminology mappings
  • c. Enabling interpretation and translation of information encoded in different terminology systems (like industry known SNOMED, LOINC, ICD etc and proprietary coding systems)
  • d. Enabling definitions of categories and contexts for groups of concept codes.
  • This enables the system to store mappings of code systems in the CDR. For example, the following mappings may be created to the RxNorm code for atorvastatin 80 mg oral tablet (259255) to translate data between EMRs at UPMC: 7427 to 259255 and 045772 to 259255.
  • The CTS subsystem typically provides some or all of the following functionalities pertaining to relations between concepts and searching capabilities:
  • a. Providing semantic navigation capabilities that allow interpretation of medical information.
  • b. Providing relation patterns between different concepts.
  • c. Enabling search capabilities on the concepts tree.
  • Definitions, acronyms and abbreviations useful in understanding certain embodiments of the present invention e.g. as described in FIG. 3 and henceforth, are provided in the table of FIG. 2. An example business layer suitable for CTS users is now described, including medical information retrieval and filtering functionalities thereof.
  • According to certain embodiments, when retrieving medical information there is a significant role to retrieving and interpreting the vocabulary codes bounded to the retrieved information most times in the context of a UMS domain. The business layer may decide what is the codes' information to be listed in the business output schema e.g. local code, baseline code, both, calculated typically according to different business rules, code's neighborhood, and hierarchy. In order to do so, the business typically online queries the CTS requesting the relevant information.
  • Another CTS use of the business layer may be for advanced filtering—when there is a need to retrieve information according to one concept code (e.g. “give me all WBC lab results”) or according to a context (e.g. “give me all beta blocker medications”). Another possible use is to retrieve all information that is related according to relation patterns (e.g. “give me all relevant information for the contra indication pattern”—which would result in all medications, conditions, procedures, etc. that have contra indication to a certain drug).
  • A Data Integration layer may operate to recognize concept codes during loading and to load new concept code. When a code arrives through a message to the DIL, a query to the CTS typically results in information regarding this code if such exists or indication that this code is new. When a new code arrives through a message to the DIL, the new code is sent to the Vocabulary Ontology for further processing such as but not limited to being mapped to the right concept or adding new contexts.
  • When building a knowledge module, the knowledge expert may query the CTS™ and SeNS™ for various terminology operations (e.g., translation of a code between vocabularies, identification of semantic relationships between codes).
    • Example
  • KM decision logic—If the patient is treated with Coumadin Medication AND has a Diagnosis of Bioprosthetic Mitral valve AND the duration of the treatment is more than 3 months, then send message to stop Coumadin.
  • CTS interaction: Search medication—the knowledge engineer provides CTS with the name “Coumadin” and requests all relevant codes. The CTS may retrieve 34 different codes from which the user chooses the appropriate one, say Coumadin Tab 5 mg—RxNorm code—209081.
  • Relations—the knowledge engineer retrieves from the CTS all relations associated with the selected medication and selects the appropriate one: “May Prevent by” relation.
  • Diagnosis—the knowledge engineer navigates from Coumadin on the “May Prevent by” relation and may retrieve a list of Diagnosis. The user chooses, say, the Bioprosthetic Mitral valve diagnosis.
  • The knowledge engineer enters a suitable duration for the selected diagnosis (Bioprosthetic Mitral valve): 3 months. Then Action—the knowledge engineer writes the “Then” clause: send message to stop Coumadin.
  • Consumers of CTS services in SmartWatch, other than KFW, typically include the Event Monitor described herein. The Event Monitor typically receives triggering rules for which it needs to look for matching records for some reason. These triggering events come from clinical knowledge. Triggering rules are envisioned to be predicated over the data. Every such rule can be thought of as composed of two elements: a pattern rule such as “lab result whose code is x from code system y and whose value is greater than z” and subscription parameters—actual values to be filled into the pattern rule. In the above case the values may include x=SNOMED, y=11111 and z=15. Event Monitor may support a limited number of such pattern rules, and may monitor a large number of specific triggering rules using parameterized subscriptions to these pattern rules. Event Monitor typically does not make final decisions, but rather triggers the evaluation of the patient using KFW. For that reason, when at risk of ambiguity—it is usually better to have false positives (false alarms) over false negatives (missing a relevant record).
  • The action manager component is typically operative to communicate SmartWatch findings to the external world, to care providers and external systems. Thus, the Event Monitor gets the message across to the receiving end in a way that is as easy as possible, the Action Manager typically expects the CTS to convert in runtime from baseline terminology in which information was provided, into the terminology the external system uses, probably a local code system.
  • A third SmartWatch consumer for CTS may be a SmartGuard manager tool described herein, in which SmartGuards are defined. Within this tool rules are defined on which SmartWatch makes decisions and captures relevant pieces of information. Application-specific needs here may be similar to the application-specific KFW needs.
  • Vocabulary administrators may use the vocabulary management tool in order to manage all vocabulary aspects. A user, by using the mapping tool, may perform the actual mapping of the local concept codes to the dbMotion Vocabulary Ontology.
  • Vocabulary human experts typically include a specialist e.g. MD familiar in a clinical area serving as an authority for clinical terms and deciding whether mapping is correct. The Vocabulary experts use the vocabulary management tool to approve the mappers' suggested mapping using the vocabulary management tool and also may provide suggestions for improvement of the dbMotion Vocabulary Ontology.
  • The following processes I-IV, some of which may be provided in dbMotion core, and solutions that employ vocabulary services, are now described.
  • I. Loading Local vocabulary information
  • In order to represent the local data of each system and in order to be able to translate it to a common terminology, the local vocabulary information is typically located into commercially available dbMotion (e.g.) Vocabulary Ontology. The following steps may be followed, completely or in part:
  • a. Initial stage: In the initial stage of pre-deployment, each organization provides dbMotion a list of all local coding systems with all their concept codes (manual process). All the local code systems' concept codes from the predefined file/s are imported to the dbMotion Vocabulary Ontology and each code is assigned to a vocabulary domain.
  • b. Production stage including an offline process and an online process, typically including loading of vocabulary codes on a fluent basis. The vocabulary elements can be loaded to the system both in offline process e.g. using a vocabulary management tool and\or in online process (automatic during messages loading using the Data Integration Layer).
  • Offline process: By using a vocabulary management tool typically with appropriate permissions, updates can be made to the vocabulary content both by using an import service or by manually influencing the vocabulary elements on the management tool.
  • As in the initial stage of pre-deployment, when there is an update in any local coding system, the updates or the whole list of codes can be transformed to a predefined file/s format in a manual process and may be imported to the Vocabulary Ontology using a vocabulary manager tool. Alternatively, when only a few changes occur, changes may be effected manually in the vocabulary management tool.
  • Deleted vocabulary elements: Obsolete local vocabulary elements that are not acting in any record in the CDR can be removed manually from the Vocabulary Ontology using a vocabulary manager tool.
  • Online process: When a new Local code enters a CDR through a message, it is loaded to the CDR and assigned to a pre-defined concept domain according to the message type and related field. The CDR contains only the Local Codes as received from the legacy systems. No mapping process may take place in the Data Integration process. The new local code is marked as new in the Vocabulary Ontology and an event is sent to the Event log for the Vocabulary administrator to monitor it on a regular basis. The administrator can relate the concept to a UMS sub domain and map the code to the Vocabulary Ontology.
  • A code arriving in a message is always associated with a codeSystem and may also be associated with an effectiveDate for the cases when codes in the coding system are editable i.e. can change their meaning over time, such as ICD9 and CPT4 codes. The Vocabulary Ontology takes this into account.
  • II. Mapping local codes to the ontology
  • Mapping allows a user to map between Local Concept codes and the Vocabulary Ontology (e.g. baseline concept code) in the context of UMS Domains. The process of mapping is executed using the vocabulary manager tool. For each UMS concept domain, the local code can be mapped to one entry point in the dbMotion Vocabulary Ontology. The mapper chooses local code or bulk of local codes for mapping. The mapper can apply different filters/parameters for the mapping. A mapping process that occurs in the Mapping Tool provides mapping suggestions to each of the selected codes with scoring. These suggestions can be approved/rejected by the Mapper. The mapping approval includes also the decision of what vocabulary domain to assign. Mapping to a post-coordinated baseline concept typically refers to mapping in which a combination of more than one baseline codes together give the exact mapping—and relation between a collection of baseline codes when mapped to a local code.
  • III. vocabulary management.
  • Suitable vocabulary management functionalities a-h, some or all of which may be provided, are now described.
  • a. Manage versions: When there is new version of a coding system, the version's validation start date is updated for any vocabulary object that was updated according to the new version updates. Until the new version is activated, the Vocabulary Ontology maintains both old and new information. When retrieving changed code information, the system may check if the retrieved code's information is up-to-date. Typically, only if it is, the information is retrieved.
  • b. Maintaining of concept codes: Concept codes are maintained on a regular basis. If changes occur in a coding system, this change may be analyzed and imported to the Vocabulary Ontology in a predefined format. The vocabulary manager tool may manage the different versions. When the change is of a baseline code, it is the responsibility of the commercially available dbMotion product to provide those updates when they occur. If it is a change in a local coding system, then it is the responsibility of each node separately.
  • c. Maintain concept relations to other concepts: The vocabulary manager tool may allow the change of relations between concepts—creating new relations and deleting relations no longer existing. This change is effected in the level of the Vocabulary Ontology and is typically approved before being activated.
  • d. Maintain mapping of a local code to Ontology: The vocabulary manager tool may allow the changing of mapping of local codes to the Vocabulary Ontology. This change typically must be approved before being activated and versioned.
  • e. Maintain contexts/value sets: The vocabulary manager tool may allow the creation and update of contexts and value sets. Each change typically must be approved before being activated and versioned.
  • f. Maintaining UMS domain information: The vocabulary manager tool may allow the change of UMS domain information, when sub-domains are being updated. When updating a sub-domain, its related concept codes may no longer be relevant and other concept codes may now be relevant. When deleting sub-domain, the vocabulary administrator typically first decides what to do with all its related concept codes. All changes typically must be approved and versioned before being activated.
  • g. Publish changes to subscribers: Any change in a subscribed concept may be published to the subscribers in a predefined format.
  • h. Approval process: Each change in the Vocabulary Ontology is typically approved by authorized users. The vocabulary manager tool may allow and implement the approval process for each changed element.
  • IV. Semantic navigation: Querying procedures A-F, some or all of which may be employed by dbMotion core product and/or by the CTS subsystem, are now described:
  • A. Retrieve codes according to a given context: In each node, if the given context exists in its CDR, a process that generates the list of all valid concept codes that are assigned to this domain or to one of its sub-domains, is executed. For each of the generated codes, a process that retrieves the relevant data from a Vocabulary Ontology is executed.
  • B. Retrieve Codes according to a specific code within a specific context: In the initiator node, if the given code exists in the CDR's vocabulary domain, and is also assigned to the given domain or to one of its sub-domains, a process that retrieves the valid code's baselines is executed. This baseline code is then passed to all the network's nodes. In each node, a process that generates the list of the baseline's mapped local codes is executed. The mapped codes are all the local codes that are mapped to the baseline code. For each of the generated codes, typically including the baseline, a process that retrieves the relevant data from the CDR is executed. A relevant data is the information in the CDR that has the generated code in one of its predefined attributes.
  • C. Search for a concept: Locate and retrieve a certain vocabulary concept using a search service. This can be a string. Input Parameters may include some or all of the following:
  • 1. Search string: a string (not case sensitive) that is the motivation of the search. Search typically finds items related to it.
  • 2. Domains/sub domains context: limit the search to pre-defined domains and sub-domains. If null, search the entire database. Use the internal mapping/created list of domains.
  • 3. Context string: limit the search to the provided context string.
  • 4. Related codes relationship types: The output result may include the related codes/concepts as well. In the output, indicate those as “related” and provide the relation type. If null, no related concepts are retrieved, “All” may retrieve all related concepts.
  • 5. Relation pattern: the searching is done according to the given relation pattern which defines the semantic navigation pattern.
  • 6. Input language: the language in which the search string is provided.
  • 7. Output language(s): The code/concept designation language(s).
  • 8. Coding system(s) or abstract concept for result
  • 9. Scoring cut off
  • 10. Max results per search
  • D. Dynamic querying: A user might build a specific query. dbMotion SeNS™ may allow building of such a query, save it and enable to reuse it when appropriate.
  • E. Query control tool: In order to be able to build a query according to changing needs, dbMotion SeNS™ may include a query control tool. This tool may address all application-specific requirements for searching and querying using a dedicated GUI for this purpose. In this tool, the user may be able to effect some or all of the following functionalities: Build a dynamic query, and save it for later use; Use existing queries; Use a template for creating a query; Update existing queries; Navigate graphically in the dbMotion Vocabulary Ontology, in order to find, and select concepts; and Define Value set of concepts from a query result.
  • F. Mapping Tool: The CTS subsystem typically includes a mapping tool which allows a user to match between string, codes and phrases to the right place within the Vocabulary Ontology by using a dedicated GUI. In this tool, the user may be able to perform some or all of the following functionalities: Mapping local codes to standards (dbMotion Vocabulary Ontology) with high performance and quality; match the best suggested mapping according to a map ranking for each suggested mapping; and apply different search methods or algorithms as appropriate.
  • The term “Concept” as used hereinabove refers to or points to a terminology element that describes one item of classification knowledge such as a specific drug or disease, like congestive heart failure. A “classification concept” points to a higher level, typically more general, knowledge element, such as a cardio-vascular disorder.
  • A “Node” as used hereinabove refers to a software deployment component that provides some or all of the system functionality described herein for an individual medical organization. A Node may contain one or more physical servers and is usually but not necessarily installed in each hospital within a medical enterprise. Each Node typically has its own Clinical Data Repository (CDR) that stores information collected from this specific facility.
  • An embodiment of the knowledge framework sub-system is now described generally with reference to FIGS. 4A-8C. Specifically, an embodiment of the Knowledge Framework (KFW) of FIG. 1A is now described which includes capabilities used by stakeholders and target users. The KFW system may enable knowledge-based interpretation of clinical data to facilitate automatic decision support capabilities. The KFW may comprise a tool set, services, and repositories that enable its users and consumers to acquire, maintain, store, and apply knowledge to data in a meaningful way.
  • The system of the present invention, even without the knowledge framework, typically enables healthcare organizations to securely share and exchange medical information, creating a Virtual Patient Object (VPO) by logically connecting a group of care providers and organizations without enforcing data centralization or replacement of existing information systems. By sharing real-time medical information, medical staff can make clear critical decisions, thereby providing safer and more efficient healthcare.
  • The information flowing from the network shown and described herein can leverage development of services that go beyond sharing and exchange of information for purposes such as presentation. Moreover, to avoid overloading care providers with increasing amounts of raw data, it is desired to have services that can interpret raw data, e.g. hemoglobin lab test measurements, into more meaningful concepts at different levels of abstraction, e.g. anemia state, which is derived from consequent hemoglobin lab test results.
  • SmartWatch (SMW) enables continuous monitoring of a population, e.g. patients, within a defined medical information space. The SMW framework is utilized by application-specific and/or customer-specific Enterprise Clinical Decision Support Systems (ECDSS). These SMW-based ECDS systems, also known as SmartGuards, are outside the scope of certain embodiments of the present invention and suitably employ core platformabilities of certain embodiments of the present invention and services as well as consuming new services which may be provided by the KFW. For example, the core platform of certain embodiments of the present invention provides a unified holistic view of the patient clinical state manifested by the Virtual Patient Object (VPO) while the KFW provides the ability to interpret the data contained within the VPO to generate healthcare delivery recommendations.
  • An example of an Enterprise Clinical Decision Support System which may utilize the SmartWatch subunit shown and described herein is described herein in detail with reference to FIGS. 144A-153.
  • Thus, the KFW may utilize the holistic view of a patient as captured in the VPO provided by certain embodiments of the present invention to enable knowledgeable abstraction of data to meaningful concepts. This data abstraction ability serves as a key vehicle to support the creation of clinical decision support services. For example, improve the quality of medical care by creating Enterprise Clinical Decision Support Systems (ECDSS) that consume data interpretation results to generate recommendations to care providers and administrators. Another example might be to generate a VPO schema recommendation that takes into consideration preferences such as clinician specialty, e.g. cardiologist, and patient clinical state, e.g. congestive heart failure (CHF), to address specific requests for information.
  • Another goal of the KFW according to some embodiments is to facilitate the dissemination and utilization of clinical expertise to improve the quality of care. Clinical expertise is accumulated by clinical experts at different medical domains over years of experience. The KFW may enable clinical experts to play an active role during the knowledge acquisition process while collaborating with other actors, e.g. knowledge engineers.
  • The KFW is typically operative to provide computerized support e.g. to one or more medical domain experts, researchers, clinicians, nurses, social workers, administrators, knowledge engineers and other, non-human consumers, such as EMR, workflow, CPOE process, another DSS, to interpret raw data in order to reach meaningful conclusions at different levels of abstractions otherwise hidden in the data. The KFW typically facilitates application of knowledge to data to reach meaningful concepts at different levels of abstractions which are useful in computerized clinical decision support.
  • Applications for this system extend throughout the healthcare community at large. It may be domain experts playing the role of knowledge editors to disseminate their valuable knowledge accumulated over years of practicing medicine, care providers benefiting from knowledge-based interpretation of data to improve the medical care they deliver, or healthcare applications developers using KFW services to create ECDSS applications. The common denominator for these diverse scenarios is an objective of acquisition and application of knowledge to data to reach meaningful concepts at different levels of abstraction, thereby improving the quality and safety of medical care, while potentially reducing overall clinical costs.
  • The ability to achieve this task capitalizes on the unique offering of the platform provided in accordance with certain embodiments of the present invention in the healthcare IT market as described hereinabove.
  • An example list of users is provided in the table of FIG. 4A. An example User environment is described in the table of FIG. 4B. Typical Key Stakeholder/User-defined Needs are set out in the table presented in FIGS. 5A-5H, taken together.
  • A high level description of the Knowledge Framework (KFW) capabilities, interfaces to consumers and the system configuration, now follows. Part of the KFW may rely on 3rd party components. For example, one may incorporate an existing commercial rule engine instead of developing one ‘from scratch’.
  • The KFW typically utilizes services provided by the core platform shown and described herein. The KFW is responsible to provide services to acquire, maintain, store, and apply knowledge to data to reach meaningful conclusions at different levels of abstraction. The KFW may provide its services according to the Service Oriented Architecture (SOA) principles. These services may be available to systems shown and described herein and applications internally, e.g. business domains developed using Business Layer infrastructure shown and described herein, as well as to other healthcare IT applications externally, such as 3rd party Electronic Medical Records (EMR).
  • SMW is a framework that enables continuous monitoring of a population, e.g. patients, within a defined medical information space. The SMW framework allows the development of Enterprise Clinical Decision Support Systems (ECDSS). These SMW-based ECDSS, also known as SmartGuards, capitalize on core platform abilities shown and described herein as well as consuming new services which may be provided by the KFW. For example, the core platform shown and described herein provides a holistic view of the patient clinical state manifested by the Virtual Patient Object (VPO) while the KFW provides the ability to interpret the data contained within the VPO to generate healthcare delivery recommendation.
  • The KFW may serve other components shown and described herein as well. For example, the business layer may consume its services as part of a business process modeled in a business domain and accessible through a business method. The business method outputs including the knowledge evaluation results generated by the KFW can be displayed using a Clinical View created using the Presentation Layer shown and described herein. In addition, a 3rd party EMR or other healthcare application can consume these same services of the KFW similarly.
  • The new system may interface with the existing platform core shown and described herein to utilize several of its existing services. These services may include but are not limited to:
      • The Security Layer—for services such as role\rule access control.
      • The Support and Testability Layer—for services such as auditing and logging.
      • The Common Terminology Service (CTS)—for services such as looking up terms originating from controlled medical vocabularies (e.g., SNOMED-CT).
  • The KFW may provide SOA-based public interfaces to consume the services it provides, such as creating of a new Knowledge Module (KM) or evaluating a Knowledge Module giving specific patient data, to internal and external applications and authorized users of the system shown and described herein as shown in FIG. 6 which is a context diagram for the knowledge framework unit. The KFW System may comprise a Knowledge Acquisition Tool (KAT) and a suit of Management tools client components, a KFW Access Service, Knowledge-Base repository and one or more Inference Engines server components as illustrated in FIG. 7 which is a system overview of the knowledge framework according to certain embodiments. KFW main functional units may include some or all of: a management functional unit also termed herein “KAT” and “PCT management tools”, access service (SOA), knowledge base repository, PCT management tools suit, and inference engines.
  • Typically, a KM or Knowledge Module comprises a knowledge evaluation rule, an input data model, an output data mode and terminology/ontology elements that are used by the KM. The server component resides on a variety of servers including an application server that hosts the KFW Access Service, an application server that hosts one or more Inference Engines, such as but not limited to RatHat's JBoss Drools engine, and a data server that hosts the Knowledge-Base repository. The server component may interface with existing components shown and described herein e.g. as detailed previously. This interface is supported by the existing SDK shown and described herein, although it may be extended or even enriched with new functionality if application-specific requirements arise.
  • The management tools suit is an optional functionality. KFW's knowledge base repository may be derived from a suitable Knowledge-Module Entities Model such as, for example, that of FIG. 140 and a suitable programming technique, such as Hibernate, an open source Java persistence framework project, may be employed to convert business objects into DB structures, such that no DB modeling need be done explicitly. The client components reside on personal computers either as web-based thin clients or as full-blown desktop applications using technologies such as ASP.NET and SmartClient technologies respectively. Once the client component is installed on the PC, the user may access the KFW System from the PC through the network shown and described herein or via a secured Internet access following a successful authentication and authorization process.
  • The table presented in FIGS. 8A-8C, taken together, identifies capabilities, all of which are typically but not necessarily provided, of the KFW System in terms of benefits and features. The features are further described hereinbelow.
  • Some or all of the following assumptions and dependencies typically characterize capabilities of certain embodiments of the KFW System:
      • The KFW consumer is solely responsible to collect the data which may be used to apply a Knowledge Module.
      • The KFW typically stores neither information being used for evaluations nor the results of (e.g. conclusions derived from) the evaluations. Generally, the term “persist” is used herein to refer to storing in service storage such as a database.
      • The KFW information model may be inspired from the UMS shown and described herein, but does not necessarily rely on it.
      • The Common Terminology Service (CTS) shown and described herein provides functionality which may be used to embed terms originating from controlled vocabularies, clinical (e.g., LOINC) or administrative (HL-7 Ethnicity), during the knowledge acquisition process. The functionality may include one or more of:
        • Find concepts using different search criteria (e.g., name, type, and domain).
        • Navigate through concept graph using semantic links, e.g. is_a or part_of associations.
        • Obtain metadata of a particular concept, e.g. value range type (numeric or qualitative), unit of measure family.
      • The UMS information model and its derivations, such as baseline terminologies, are accessible electronically via the Reference Model shown and described herein or similar resource.
      • The knowledge acquisition process is performed by collaboration between domain experts and knowledge engineers.
      • Some of the KFW functionality may involve embedding commercially available software components e.g. commercial business rule engines such as Drools which is part of the commercial product JBoss distributed by RatHat. Some of the KFW functionality relies on existing components of the platform shown and described herein, e.g. STL and Security layers.
  • Features of the KFW System, according to certain embodiments, some or all of which may be provided, are now described:
  • FEAT8 Data interpretation and inference capability: The KFW may receive as input (1) an identifier of a Knowledge Module to evaluate, e.g. definition of chronic hypertension, and relevant patient data, e.g. blood pressure measurements. The KFW may process the data and knowledge using an inference engine of some kind, e.g. a temporal reasoning engine. As output, the KFW may generate a conclusion e.g. patient had chronic hypertension during last year.
  • FEAT8.1 Iterative Knowledge Module Evaluation Interaction: The KFW enables its consumers to provide it with the data it uses to perform a Knowledge Module evaluation in an iterative manner. Thus, a possible intermediate evaluation result is the fact that additional data is to be provided to complete the current evaluation request processing. Then, after the consumer collected the missing data, it sends another evaluation request to the KFW. The intermediate result may be marked as not final.
  • FEAT8.2 Inference Evaluation Explorer: Each conclusion result may optionally contain an explanation of the knowledge and facts that lead to it. This explanation may be in a human-readable and machine-interpretable format. One of the evaluation request arguments may explicitly direct the KFW whether to generate such an explanation or not, as part of its output. For example, the hematocrit and haptoglobin serum levels of a patient, leading to the conclusion of having ongoing hemolysis, may be presented together with the definition of what an ongoing hemolysis is.
    FEAT8.3 Temporal Reasoning Capability: A special type of inference capability that the KFW may support is temporal reasoning. A common feature of many healthcare information types is having a time stamp. The valid time of a WBC lab test result, the request time to perform a MRI imaging study and gestation condition start time are only some examples. The temporal reasoning method enables to interpret large sets of time-stamped raw data into meaningful concepts at different levels of abstraction. This may include abstraction of individual time points to longitudinal time intervals, computation of trends and gradients from series of consequent measurements, and detection of different types of patterns, which may be otherwise hidden in the raw data.
  • FEAT8.4 Probabilistic Reasoning Capability: Another type of inference is undeterministic or probabilistic reasoning. Optionally, insufficient, incomplete, or less reliable data is input to an inference process. Or, non-deterministic data abstraction methods such as fuzzy logic may optionally be applied including reflecting the data quality implications on the final output in terms of confidence level. For these purposes exactly probabilistic algorithms, such as Bayesian Networks or Belief Networks, exist which reflect the data quality implications on the final output in terms of confidence level. This optional capability typically utilizes a specialized knowledge representation model that captures the probabilistic nature of the knowledge and corresponding inference mechanisms.
  • FEAT8.5 Context-Based VPO Schema Generator: A special type of evaluation result is a recommendation to an information schema of a Virtual Patient Object (VPO). A VPO schema can be generated when given as inputs the clinical state of a patient, e.g. current problem list, and possibly the preferences of a care provider, e.g. clinical specialty. This custom-tailored VPO may benefit the care provider by decreasing the amount of information to review during a care delivery session. FEAT8.6 Knowledge Evaluation Simulator: A helpful feature to a knowledge editor is to simulate the evaluation process of a Knowledge Module. The simulator typically supports debug-like mode enabling to find problems in the Knowledge Module definition or inference engine. In addition, the simulator may have a capability to generate a representative data set that covers possible inference execution branches.
    • FEAT9 Robust Knowledge Module Representation Model
  • FEAT9.1 Descriptive Information Traits: A section common to all types of Knowledge Modules is the one that contains descriptive information about the Knowledge Module. The Knowledge Module metadata describes its scope, goal, function, etc. This may include its creation date, modification dates, authors, version details, and classification keywords, whether codified or not. This information serves as the basis to search and retrieve Knowledge Modules by submitting search queries that comprise the descriptive information traits.
    FEAT9.2 Standard Boolean Expressions: Simple rule-based clinical knowledge is often expressed using straightforward Boolean expressions, i.e. and/or clauses. Thus, the KFW may support the representations of such expressions.
  • FEAT9.3 Declarative and Procedural Knowledge: Clinical knowledge can be divided into two main types, declarative and procedural knowledge. The declarative knowledge type defines meaningful clinical concepts related to the patient's clinical state. For example, blood pressure state Knowledge Module definition (i.e., low, medium, or high) comprises declaring possible quantitative ranges of diastolic and systolic blood pressure to each qualitative value. The procedural knowledge type usually defines clinical workflows and procedures. This may be for instance a recommendation of treatment for patients suffering from high blood pressure (e.g., routine blood pressure monitoring). It usually involves the explicit specification of control structure such as do-in-parallel, decision steps, or mandatory actions. The KFW may provide specific knowledge representation (KR) models to capture these two distinct types of knowledge to support a broad range of Clinical Decision Support Systems (CDSS). Moreover, the KR models used to capture these knowledge definitions may be based, or at least adhere, to existing healthcare standards such as HL7 GLIF for declarative and procedural knowledge respectively.
  • FEAT9.4 Terminologies and Vocabularies: A Knowledge Module definition often comprises terms and concepts originating from controlled medical vocabularies. These concepts are typically found both in the metadata section of a Knowledge Module, e.g. an applicable clinical state such as diabetes mellitus using coded keywords from SNOMED, and in its knowledge definition section, e.g. referring to a certain type of blood lab test such as WBC count using LOINC codes. Thus, the KR model of a Knowledge Module provides special placeholders enabling to embed terms and concepts during the knowledge acquisition process. Moreover, embedding terms and concepts originating from well-accepted and commonly-used terminologies facilitates sharing and reuse of Knowledge Modules at different clinical settings.
  • FEAT9.5 Interrelation between Knowledge Modules: A Knowledge Module definition often relates to knowledge definitions of other Knowledge Modules. To ease and simplify the knowledge acquisition process an ability to interrelate Knowledge Modules may be provided. Common Knowledge Module interrelations include inheritance and composition. For example, the Proteinuria state Knowledge Module (i.e., protein levels in urine) can be derived to capture gestational proteinuria without repeating the common knowledge parts. As another example, the HELLP syndrome Knowledge Module comprises hemolysis state, liver enzymes state, and platelet state Knowledge Modules, each being valuable on its own too. Thus, the KR may cater for this by enabling to base the definition of one Knowledge Module on other Knowledge Modules via common interrelations such as specialization (i.e., is-a) and composition (i.e., part-of).
  • FEAT9.6 Automatic Triggering Events Extraction: The evaluation process of a Knowledge Module may impose on the requesting consumer to perform preliminary operations, for example gathering data according to application-specific Knowledge Module data requirements, which are costly in terms of time and computational resources (e.g., network traffic). In addition, in some cases it is critical to evaluate a Knowledge Module as soon as one of its comprising data elements changes in the CDR. Therefore, from a Knowledge Module definition, a consumer may be able to automatically extract events, in terms of data changes in a CDR (e.g., arrival of a new WBC lab test message), which trigger the necessity to evaluate the Knowledge Module.
  • FEAT10 Knowledge Base Repository
  • FEAT10.1 Knowledge Module Search Engine: There may be a mechanism that enables to search and retrieve Knowledge Modules. During runtime, before requesting to evaluate a Knowledge Module, it first may be retrieved and explored to provide application-specific data requirements as input. During design-time, to maintain the Knowledge Module definition, a knowledge editor may be able to locate it before editing. The Knowledge Module search engine allows searching and retrieving of Knowledge Modules by submitting search queries. These search queries capitalize on the descriptive information section of a Knowledge Module. Two possible search queries are free-text search query or a context-based search query. The free text search query contains a single search string to be matched against any text-based section of a Knowledge Module. The context-based search query comprises a structured query, for example XML, which defines for each searchable attribute or trait of a Knowledge Module its expected value. For example, a search for Knowledge Modules of John Foster may use the Author descriptive information trait. Another example is a search for Knowledge Modules that expect to receive a certain LOINC-coded lab test typically using the data requirements' Knowledge Module attribute.
  • FEAT10.2 Knowledge Module Definition Import and Export Mechanism: A mechanism that enables to import and export Knowledge Module definitions in or out of a KB repository. An XML schema defines the Knowledge Module file format and allows a Knowledge Module to be imported from one KB and exported into another KB.
  • FEAT11 Knowledge Acquisition Tool: One of the KFW client components is the Knowledge Acquisition Tool (KAT) that facilitates domain experts and knowledge engineers, acting as knowledge editors, to collaboratively acquire, edit, and maintain the knowledge definitions and descriptive information of Knowledge Modules stored in the KFW knowledge-base repository. Besides knowledge editing capabilities, the KAT may contain several other features, as described hereinbelow. FEAT11.2 UMS Explorer: The underlying clinical information model of the KFW is the UMS shown and described herein. Hence, the definition of any Knowledge Module typically comprises UMS entities such as LabResult, Diagnosis (type of Condition entity), and Medication. The UMS information model is relatively large in scope and contains diverse attributes, complex data types, and various relations between its entities. Thus, the KAT may contain a specialized module, named UMS Explorer, to explore the UMS information model and assist the knowledge editor to navigate and find UMS entities and attributes that comprise a Knowledge Module definition. The functionality expected of the UMS explorer includes: free-text search and context-based search of UMS entity and attribute (e.g., entities that use a certain vocabulary domain), descriptive information, and navigation according to relations (e.g., related-act).
  • FEAT11.3 Knowledge Module Explorer: A Knowledge Module definition may relate to another Knowledge Module. Different types of relations can exist between Knowledge Modules, including specialization (i.e., is-a) and aggregation (i.e., part-of). For example, the Hypertension Knowledge Module, which defines the clinical state of having elevated blood pressure, can be derived by another Knowledge Module to define gestational hypertension. Thus, the KAT may contain a specialized module, named Knowledge Module Explorer, to explore the KB repository and assist the knowledge editor to navigate and find Knowledge Modules during the knowledge acquisition process. The functionality expected of the Knowledge Module explorer includes: free-text search and context-based search of Knowledge Modules (e.g., all Knowledge Modules that use a certain SNOMED code), descriptive information, and navigation according to relations (e.g., is-a).
  • FEAT11.4 Concept Explorer: A Knowledge Module definition may contain terms and concepts originating from controlled medical vocabularies (e.g., LOINC code for WBC count). Different types of terminology relations exist serving different coding habits. For example, the SNOMED terminology is usually used to code diagnosis terms, signs and symptoms. Thus, the KAT may contain a specialized module, named Concept Explorer, to explore the variety of terminologies and assist the knowledge editor to navigate and find concepts to embed in a Knowledge Module definition. The functionality expected of the Concept explorer includes: free-text search and context-based search of concepts (e.g., diabetes code in SNOMED), descriptive information, and navigation according to relations (e.g., is-a), if such exist, between concepts.
  • FEAT12 Role and Rule Access Control: By capitalizing on the Security Layer shown and described herein, the KFW provides a secured and controlled environment at design-time and runtime. Users and consumers may be authenticated and receive authorization before accessing KFW services and knowledge. Special roles and rules may be defined for the KFW to cater for its unique services and protect its special resources. For example, a knowledge editor role may be defined as well as a rule determining who can edit a certain Knowledge Module.
  • FEAT13 Auditing and Logging: By capitalizing on the STL Layer shown and described herein, the KFW provides a robust and flexible audit and log capability. The level of auditing and logging can be changed according to different scenarios, for example testing vs. production. Special auditing and logging policies can be applied to different services and resources of the KFW, for instance applying a meticulous auditing and logging policy to knowledge creation and maintenance operations.
  • Applicable Standards The KFW functionality is largely based on the functionality specified in the HSSP DSS SFM as described hereinabove to facilitate interoperation with KFW services.
  • An embodiment of the smart-watch sub-system is now described generally with reference to FIGS. 14-17.
  • An embodiment of the Smartwatch subunit of FIG. 1A is now described with reference to FIGS. 14-17. By their nature, clinical decision support systems are very complex. The challenge of creating such systems is even greater in a heterogeneous and distributed environment where the data—the cornerstone of any decision support system—exists in different locations (often hard to access) with different structures, standards and terminologies, often lacking any common semantics. Many of the existing EMR systems provide a rich set of decision support functionalities but these rely on each system's limited data. Typically, an enterprise-wide decision support framework co-exists with the EMR CDSS modules.
  • There are substantial market opportunities created as a result of the above challenge in the context of increasing pressures from government, payers, employers and patients to improve and substantiate patient safety and treatment outcome while reducing costs. Focused efforts to improve care of patients with chronic diseases (e.g., CMS targets, pay for performance) seek to provide orchestration of care and related information across venues of care both within IDN's and across facilities not within the same organization. Realization of the promised benefits of electronic medical record (EMR) systems, ensuring completeness of the data used by the EMR's in assisting with clinical decision support and bridging the gap between care locations and facilities across the continuum of care with different EMR's employ interoperability solutions, including enterprise clinical decision support capabilities and services.
  • To enable automated decision support services at the enterprise level the dbMotion Platform product may be employed, thereby achieving interoperability, and presenting medical information from disparate sources as if it originated from one normalized source, using common representation, terminology and semantics. This enables the creation of an advanced infrastructure for an enterprise-wide clinical decision support framework termed herein the SmartWatch Subsystem.
  • The Enterprise Clinical Decision Support System (ECDSS), also termed herein the SmartWatch subsystem, may work in conjunction with the commercially available dbMotion platform. The SmartWatch subsystem addresses the challenge in such a way that no centralized database is mandatory, thus enabling enterprise decision support services both in a fully distributed as well as centralized model (and any hybrid in between). The SmartWatch subsystem is not intended to replace existing clinical decision support systems currently running within any of the existing EMRs, or any other systems in the organization. Instead, it aims to address problems that cannot be tackled by any operational/legacy system (e.g. EMR) that often has access only to a partial subset of the patient's clinical information.
  • The SmartWatch subsystem may facilitate both the design time and runtime activities involved in the creation and use of ECDSS. These activities may include some or all of: knowledge elicitation, eligibility determination, continuous patient monitoring providing timely alerts, notifications and more. Care providers are then able to carry out the appropriate actions, in a timely manner, thereby increasing the quality of healthcare and lowering costs that might arise from possible deterioration in a patient's condition.
  • SmartWatch does not aim to replace the physicians' role in complex decision making Instead it is targeted at giving help and support with decision making—performing time-consuming, data-driven or time-driven tasks, and bringing the human factor into the picture only when human involvement is inevitable.
  • The SmartWatch subsystem may rely on a built-in knowledge base, maintained by medical professionals. This knowledge base allows The SmartWatch subsystem definitions (matching rules, etc) to be set in an abstract, high level language, rather than having to code rules in computer language.
  • Definitions, Acronyms and Abbreviations used herein include:
      • SmartGuard: —A SmartWatch solution that is built to watch over a specific population. A live SmartWatch system may include many SmartGuards. SmartGuards are logically (and probably technically) separated from each other. One may envision the SmartGuard to be a set of configuration settings defining a SmartWatch vertical instance, the population involved, the information to be employed, the rules and actions that may be performed.
      • Population: —A set of patients grouped by some criteria. These criteria could be medical (people diagnosed as . . . ) encounter based (Currently hospitalized in ward . . . ) demography-based (people over 90) or any other UMS-based criteria. A population may also include other elements derived from dbMotion's UMS such as organizational units, physicians and so forth.
      • Information: —the set of data elements to be collected for a population member (a patient). Typically each SmartGuard would define different application-specific information needs.
      • EMPI: —Enterprise Master Person Index: Software that attempts to cluster patient records from separate applications (AKA operational systems) usually using probabilistic methods. An EMPI cluster contains a set of indexes, each representing a demographic record in an operational system.
      • Subscriber: —is an entity that signs up (to some SmartGuard) to be notified when a certain condition matches a population member. The subscriber may be a person, or another system.
      • HIPAA: —Health Insurance Portability and Accountability Act, which is the leading regulation in the United States for the use and disclosure of patient health information.
      • Population criteria: —the criteria that defines population membership. This may include, for example, inclusion/exclusion over UMS entities, or more complex rules which use other considerations such as time, age and so on.
        The SmartWatch subunit may have some or all of the following properties and functionalities:
      • Population—The problems focus on populations of patients (or other entities) that share some characteristics such that monitoring them is beneficial.
      • Information—The relevant population is monitored for some limited set of clinical (or other) data elements—giving SmartWatch an advantage where information is scattered over an enterprise, in different systems and at disparate locations, possibly coded using different terminologies.
      • Rules—The population being watched is expected to be “ok” most of the time for most examined subjects (patients), the objective being to find the abnormal elements—to identify situations where some action is to be taken for a population member (patient). The problems that fall into the SmartWatch profile would usually involve clinical knowledge, introducing two complex issues:
        • The ability to apply clinical knowledge to the raw data and derive decisions from it involves intelligent inference mechanisms & knowledge representation.
        • Clinical knowledge changes constantly and therefore requires constant knowledge maintenance by knowledge experts.
      • Actions—the functionality of communicating monitoring results to the outside world. Many communication mechanisms can be envisioned to serve this, allowing much flexibility in implementation. Also, a possible need for workflow capabilities is recognized in order to allow escalation reminders and so on, in order to close the loop.
      • Three examples of tasks the SmartWatch subsystem may perform are now described:
      • 1. Active monitoring of a patient's clinical condition in a distributed, semantically heterogonous environment. The importance of monitoring a patient's condition can be viewed for example in the context of chronic patients. In a typical chronic patient scenario, the target audience is identifiable, and so are the indicators to monitor. In such a scenario, monitoring is a long term process, and identifying an abnormality that leads to a corrective action can be of great value. However, this monitoring is greatly facilitated by computerized assistance: the number of patients can be very large. Patient data volume can be overwhelming. Events are not detectable locally—patients visit different hospitals, clinics, meet different caregivers. Lack of semantic interoperability, different data structures and languages exist. A typical multi-hospital environment introduces more difficulties such as different systems, usually distributed; different APIs; different semantics are used. No unique patient identifier exists.
      • Example: Monitor all diabetic patients—checking that their clinical diabetes indicators such as Lipid profile (LDL), Glucose, HA1C, Creatinine, urine micro-albumin and so forth are within range, and are performed promptly; making sure Eye exam (DRE) and foot exam are carried out promptly and so forth. When a certain test is not done within the timeframe, or results demand provider attention, SmartWatch may notify the local EMR, with a mail to the primary physician. This affects quality of healthcare. Poor monitoring may lead to complications, deterioration of patient condition, and potentially further treatment costs. Non-automatic monitoring is time-consuming and inefficient. Certain embodiments seek to provide a preemptive action leading to a care provider response to the patient's condition.
      • 2. Gathering medical research data: When Collecting clinical data for research, such data sometimes needs to be de-identified. This affects researchers who may need to gather clinical data records to base their research on. The impact includes high costs of assembling research data from a variety of sources, cherry-picking patients that match the criteria, inconsistency in patient records due to diverse source semantics, patient privacy issues, and wrong patient identification due to de-identification methods. Certain embodiments seek to eliminate or reduce any need to collect such data manually, improve data integrity by supplying an integrated patient record, and enhance patient privacy with automated patient records gathering, so patient identity is not disclosed to researchers in any way.
      • 3. The task of public health surveillance may include looking out for abnormal healthcare patterns on a large scale. This can be done by monitoring information sources such as ER visits, medication consumption, diagnoses and so on.
      • For example, an alert may be issued when, in one week, 5 patients from the same area (zip code) are suspected to be suffering from bacterial meningitis. This task typically affects disease control centers officials, ER managers and public health. Poor epidemic detection does not allow authorities to respond on a timely basis, resulting in the potential infection of more people, with higher treatment costs. The impact of the epidemic outburst may be drastically reduced, following corrective action, such as containment, before the epidemic gets out of hand.
  • The SmartWatch subsystem is a platform for developing services that facilitate an enterprise-wide clinical decision support system (ECDSS) that utilizes the Service Oriented Architecture (SOA) environment provided by the dbMotion platform. The subsystem is geared to identify a target population according to eligibility rules, and monitor the state of the target population members over time, according to another set of monitoring rules, and eventually trigger proper actions such as alerts or reminders when a rule is matched.
  • The subsystem may facilitate both the design time and runtime activities involved in the creation and use of ECDSS. These activities include knowledge elicitation, eligibility determination, monitoring patient state continuously, providing timely alerts, notifications and more. Consequently, care providers can carry out suitable actions when appropriate, thereby increasing the quality of healthcare and lowering costs arising from deterioration in the patients' condition.
  • The SmartWatch subsystem is intended to rely on a built-in knowledge base, maintained by medical professionals. This knowledge base allows the SmartWatch subsystem definitions (matching rules, etc) to be set in an abstract, high level language, rather than having to code rules in computer language.
  • The SmartWatch subsystem can serve as a complementary framework that may benefit other systems. Currently, cutting edge EMR systems provide CDSS capabilities usually during data entry (i.e. in real time) although they are dependent on the data available to the EMR itself. In contrast, SmartWatch's design enables retrospective CDSS capabilities offering a near real-time response. Thus, a preferred model for The SmartWatch subsystem is one of synergy in which the SmartWatch subsystem provides a continual monitoring of clinical information and notification services to other applications.
  • SmartWatch does not aim to replace the physicians' role in complex decision making, but to provide help and support in decision making by performing time-consuming, data-driven or time-driven tasks, and bringing the human factor into the picture only when needed.
  • The SmartWatch model may include 4 logical layers as follows:
      • 1. Population: The Population layer defines and manages the target population to be monitored. This is accomplished either with eligibility criteria that define the population boundaries and detect new population members automatically, or by letting users enroll members directly.
      • 2. Information: The Information layer controls information to be gathered and processed for the population members, once their membership has been established. This information can be used later by other (higher) layers, for example for rule evaluation or within an action's output message. Required information, if any, is not necessarily static, and may change in accordance with the member state, as different stages of analysis may employ different data elements.
      • 3. Rules: The Rules layer defines the conditions for which any action may be taken for population members. It defines the abnormal behavior that the SmartWatch subsystem monitors for its population members.
      • 4. Actions: The Actions layer handles actions that may be taken when a population member (patient) matches a rule, usually when some abnormal condition has been identified. Actions typically comprise a workflow detailing reminders, escalation procedures, and close-the-loop functionalities and may include services to deliver messages using standard channels to humans or other IT systems.
  • A high level conceptual view of SmartWatch, based on the 4 layers mentioned above is illustrated in FIG. 14. As illustrated, there is communication between the 4 logical SmartWatch layers. Each layer depends on preceding layer artifacts. In addition, SmartWatch communicates with dbMotion platform services such as security services, EMPI, and the management layer. Also illustrated is the dependency of SmartWatch on the Knowledge Framework in supporting clinical decision making.
  • SmartWatch may employ several storage elements that include SmartWatch Metadata, in which the SmartGuard (the SmartWatch Solution) properties are retained, population and possibly VPO storage, in which the population and information are stored. The Knowledge Framework may add storage—a knowledge base—of its own. The VPO storage system is used to store ePHI, and for that reason careful thought may be taken on how to store them without compromising patient and business security and privacy. SmartWatch provides services to external parties, allowing complementary applications to fit in and form a solution.
  • The knowledge-framework role is to allow SmartGuards to be defined in terms of clinical concepts and abstractions, rather than referring directly to raw UMS data. The knowledge framework may be able to connect a concept, or a knowledge module, to data and to a suitable computation mechanism.
  • The SmartGuard can be thought of as a single SmartWatch subsystem solution, monitoring a specific population. The SmartWatch subsystem may host several SmartGuards running simultaneously. Each such SmartGuard may contain all the details it uses in order to operate: the population criteria, information to be employed, the rules to be matched, and the actions to take when rules fire.
  • SmartGuards are tools for retrieving information between hospitals. To make sure that no unauthorized query is performed in a hospital repository, SmartGuards may require hospital approval to operate.
  • SmartWatch is a framework, which provides services, and therefore employs additional components to form a comprehensive solution. FIG. 15 presents such a solution that includes a dbMotion platform that provides the application-specific required data for the SmartGuards, SmartWatch itself, and a clinical application that users interact with in their daily routine, such as a CPOE or EMR. This clinical application interacts with SmartWatch, and provides the user with a subscription mechanism, a message viewer (e.g., view SmartWatch patient messages within the patient file; action items for the physician after login to the system and so on), and an ability to close the loop (e.g. by marking a checkbox verifying that the message was addressed, by simply viewing the message, or by initiating a process tracking the patient condition). None of these interfaces is mandatory, but failing to provide one may result in the creation of a partial solution only.
  • A clinical application as shown in FIG. 15 may be referred to here as a complementary application. This document assumes the existence of such an application, provided by dbMotion or by an external provider, to form a complete solution. Also shown in FIG. 15 are messages sent to users directly, via for example SMS or Email protocols. Messages sent to human users in this form, would usually be accompanied by a corresponding message to the complementary application, while providing elementary information and directing the user to view the full message details in the complementary application.
  • FIG. 16 presents a domain model for SmartWatch, implying both its static service-oriented structure, as well as the dynamic processes involved. It shows SmartWatch containing several SmartGuards, maintaining their properties through services, as well as the dynamic messages coming into the SmartGuard process from dbMotion network, and out of the process to users and systems. Also shown is a clinical knowledge base, and its editor, CDSS that may be called by SmartWatch during patient records analysis.
  • Some or all of the following functionalities, and associated supporting features, may be provided:
      • Patient condition monitoring: Physicians gain a monitoring tool for their patients that relieves them of certain tedious tasks, allowing them to concentrate on more complex cases. In a pay-for-performance environment, physicians/clinics gain actual income when SmartWatch helps them to meet suitable quality measures. For this functionality, associated supporting features may include some or all of the following:
        • User direct notifications
        • Alerts to external, complementary applications
        • Reminders & Escalation notifications
        • Mandatory message properties
        • SmartGuard definition tools
        • Additional pluggable workflows
        • Subscription service
        • Population enrollment service
        • Close the loop capabilities
      • Researchers may greatly benefit from a tool that gathers comprehensive, semantically coherent, research-oriented patient records from distributed systems. This eliminates the effort of piling up research data from various inconsistent sources, and the need to reconstruct de-identified patients' records into virtual patients. For this functionality, associated supporting features may include some or all of:
        • Alerts to external, complementary applications
        • SmartGuard definition tools
        • SmartGuards rely on high level medical abstract concepts
        • Subscription service
        • Research purposes output service
      • Public health surveillance
      • A SmartGuard monitors admission records to ER, identifying abnormal patterns in a patient's condition, alerting a possible epidemic. A benefit of this is public health, but hospitals and regional/national disease control centers also benefit from task automation. For this functionality, associated supporting features may include some or all of:
        • User direct notifications
        • Alerts to external, complementary applications
        • Reminders & Escalation notifications
        • Mandatory message properties
        • SmartGuard definition tools
        • Additional pluggable workflows
        • Subscription service
        • Close the loop services
  • According to certain embodiments of the invention SmartWatch relies on the dbMotion infrastructure as its main data source and relies on some or all of the following dbMotion Services: Security, Auditing and Logging (STL, CEB).
  • This may enhance re-use of any needed functionality which already exists in a dbMotion product. SmartWatch relies on its decision logic in the Knowledge Framework component for modeling clinical knowledge, and in applying that knowledge to patient data. SmartWatch is a service-based product, that assumes the existence of complementary applications (not necessarily part of the basic SmartWatch) from which users can actually subscribe to SmartGuards, view the artifacts—resulting messages, and let SmartWatch know when the issue is addressed (close the loop). SmartWatch analysis assumes the existence of an EMPI service, with a one-to-one relationship between the EMPI cluster and the virtual patient SmartWatch refers to. Even if there are more than one (several) clusters returned from the EMPI, SmartWatch may use only one of them. If the EMPI clustering quality is poor, SmartWatch's decision quality may be affected, as it may miss patient records or be confused by records actually related to another patient.
  • According to certain embodiments of the invention, SmartWatch assumes each EMPI vendor supplies the “member-of” functionality, whose input is an index and its output is the cluster the input belongs to, along with all cluster indexes. This converts an operational system patient index into a virtual patient which contains all indexes in the cluster. SmartWatch assumes that EMPI vendors do not supply a change log service, detailing clusters whose state has changed. However, if such a service is available, keeping up with patient EMPI state may be made much easier and may simplify the process.
  • The system need not provide an application (GUI) for managing the actions and states related to population members. Instead it may only provide SOA based infrastructure that may enable developing such capabilities.
  • Possible Consumers for the SmartWatch subunit are described in the table of FIG. 17.
  • User environment: In general, the expert, Super User category is envisioned using networked, personal computers. This is a small, predefined set of users:
      • The SmartGuard editor user role may use a designated application to configure the SmartGuards he/she is authoring. This application may be the SmartWatch management tool or a similar tool.
      • The SmartGuard/SmartWatch administrator role is envisioned using the SmartWatch management tool to perform administrative, maintenance, monitoring and configuration of a SmartWatch product implementation. This includes tasks like review & approval of SmartGuards before they actually run, viewing status & operation statistics (e.g. population size, number of actions taken, exceptional conditions etc). This user type may exist in any dbMotion node.
  • As far as the Consumer category is concerned, the situation is far less clear. This is envisioned as an area that includes many professional services with customization & configuration, aimed at getting to end-users, in the most effective way, to meet their needs with working modes in the specific project rather than the “one suit fits all” product approach. This statement implies that users may be working in any kind of electronic environment, from mobile phones, thru PDAs, networked personal computers, mainframe terminals to fax machines. The following is a classification of delivery methods that may be useful:
      • Direct, standard delivery channels (e-Mails, SMS, fax and so on).
      • Complementary application that may be the users' working environment, to present the SmartGuard's output. Such an application may be a commercial EMR, dbMotion Clinical Views™, or some other proprietary clinical application.
  • In addition, the following factors (among others) may be considered in deciding which channels are best in a given situation:
      • Urgency level—Life-threatening messages may be accompanied by a text message to the relevant physicians' mobile device, while less urgent messages may be pushed to an application queue, to be presented to the next caregiver.
      • Enterprise preferences—Enterprise policy may prefer to send notifications to its physicians' mobile devices, or to a reliable follow up mechanism/EMR system. Each implementation may include a configuration stage during which it may be decided how and where the notifications are addressed.
      • Personal preferences—Consumer-type users in general and PCPs in particular, may have different levels of automation in their offices. Also, the nature of their activities may dictate out-of-office hours during which a physician would prefer to be notified through a mobile device. These typically simplified constraints may require a diversity of abilities to receive and respond to notifications.
      • Time factors—An SMS message at night time may either be rescheduled to a reasonable time, or sent to the on-shift physician who is currently responsible for the patient.
  • Medical records may be gathered for specified groups of patients (population), providing proactive messages based on the records collected. SmartWatch may provide an enterprise-wide view of patients and an ability to analyze the information, apply rules to them, and as a result perform actions in which messages are sent to external actors to respond to SmartWatch findings. The response time (measured starting from an event happening in real life, and ending as user views the resulting message) expectation is at most near real-time.
  • SmartWatch may be supplied with an existing content that covers common medical cases.
  • This content is to be supplied in the form of existing definitions of populations, related knowledge and actions, packaged as a set of SmartGuards. This means that each SmartGuard may be a deployable unit, packed and deployed together.
  • Some or all of the following functionalities I-VI may be provided to facilitate identification and management of populations:
      • I. SmartWatch may support population discovery by several parallel methods, as detailed below. The fact that population members are discovered by different mechanisms may not impact the rest of the layers. i.e. in a given SmartGuard there may be population members (patients or other) that were discovered automatically and others that were enrolled by their physician, but the rest of the SmartGuard flow may work the same for all cases. Therefore, some or all of the following population discovery mechanisms 1-5 may be provided:
        1. Automatic population discovery by eligibility criteria: SmartWatch is typically able to discover patients (or other UMS entities) as matching the SmartGuard criteria by using knowledge from the Knowledge Framework (triggering events).
        2. Population based on external list: In some cases the population could be known to an external system that can provide a prepared list of patients to work with. SmartWatch may provide an interface that enables project specific implementation to push patients into a population. For example, the list of admitted patients may be accessible using a db view generated from an ADT system.
        3. Patient enrolled in population by care provider: optionally, SmartWatch may allow consumers (e.g. care providers) to enroll patients into some SmartGuard population. This requirement arises from two scenarios: scenario 1) —let physicians register their patients to an existing population, for which they are not qualified by the eligibility criteria—imagine a SmartGuard watching over CHF male patients over 65, and a physician who wants to add his patient to this population even though he is just 62-enabling human decision-making to override the computer logic; scenario 2) —a SmartGuard that is voluntary, includes no eligibility criteria, and is based on patients/physicians deliberate enrollment—for example, monitoring the influence of a new drug, a diet and so forth. This requirement, if provided, probably involves much customization to supply users with tools to perform such an enrollment (for example search and choose leading record; enroll button from patient file). SmartWatch may provide an interface for adding patients to a population (high priority), together with tool (GUI). This tool may also be useful for testing.
        4. Patient enrolment in a population by patients themselves—SmartWatch may enable patients to enroll themselves in a SmartGuard solution.
        5. Patients pushed between SmartGuards: it may be useful to move patients between SmartGuards when they fit some pattern. SmartWatch may therefore enable a SmartGuard action to add patients to another SG population. For example, a population that monitors elderly patients (over 65) may push patients to another SmartGuard that are related to age criteria.
      • II. Partially matched population: In defining SmartGuard's population eligibility criteria, it is very likely that even though certain patients do not qualify for the population, they may not be excluded from it and may be added in the future. Some examples: a lab result is missing, but might be provided shortly; age—the patient is too young and may qualify in x days; patient identity may change to add an index that carries with it the data which may be used to qualify for the SmartGuard. The requirement is typically not to lose such patients, and to somehow put the system into a “sleeping mode” (for these patients), waiting for the missing condition to occur.
      • III. Online connection as a SmartWatch population information source: SmartWatch typically utilizes the dbMotion core product, using it as its information source. However, it cannot assume the dbMotion CDR as the sole information source. It also addresses information sources that are available through dbMotion online connections as well. A list of application-specific requirements from an information source may be assembled as well as a list of scenarios that could not be supported in such a case. Examples for online information sources are medications thru RxHub, claims data (P4P BUC), and Pan-Canadian standard.
      • IV. STRQ55 Run as background process and on demand: SmartWatch may be able to run as a background process, expected to perform most of its data fetching activities outside working hours whenever possible, in order to avoid network overload. The schedule in which SmartWatch collects data depends on the SmartGuard it is working for. These schedules are typically adjustable per SmartGuard. However, it may also be possible to make SmartWatch run a specific SmartGuard on demand (immediately) regardless of the defined schedule.
      • V. SmartWatch observations do not have to be patient-centric: dbMotion is also capable of collecting data on medical elements that are not actual patients; SmartWatch may exploit this to monitor entities that are not patients as well. Although most populations described in this document relate to patients, it may be understood in the broader sense of UMS-entity centric. For example SmartWatch may also observe the patient capacity of a ward, where the observation is ward-centric; or the usage of some set of expensive medication, where the population is medication-centric.
      • VI. Find mass Trends: SmartWatch may be able to identify events resulting from an accumulation in some population, rather than focusing on the individual patient. Example: disease control scenario, in which the event is—X people of the same zip code area are hospitalized within N days and diagnosed with diagnosis D.
  • SmartWatch may depend on the knowledge framework in formulating & executing its clinical rules and decisions. Functionalities of the knowledge framework which may interact with SmartWatch or otherwise be used thereby, may include some or all of the following functionalities A-G:
      • A. Separation of the knowledge (Knowledge Framework) from the execution & delivery engines (SmartWatch). Separation may be desirable for some or all of the following reasons 1-3:
      • 1. Allow clinical knowledge & software engines to be separately maintained and released.
      • The clinical knowledge that would be modeled for SmartWatch has a different timeline to the software updates. The knowledge changes are driven by clinical innovations and discoveries whose timeline cannot always be planned (such as taking a drug off the shelves). The engines on the other hand, are managed in software lifecycles, driven by new application-specific requirements, performance issues and so on. For this reason it is highly desirable to have the ability to deliver knowledge updates on a parallel track to software updates.
      • 2. Clinical professionals may actively participate in knowledge modeling & elicitation.
      • One problem with incorporating clinical knowledge into code written by programmers is the poor communication that arises, resulting in modeling errors. Knowledge Framework application-specific requirements in the long run typically incorporate the ability of clinical subject matter experts to model and validate the content. Therefore, Knowledge Framework may provide a tool for knowledge management/acquisition.
      • 3. Managing and changing the knowledge at project level: Knowledge customization at the customer level may facilitate SmartWatch solutions in areas where clinical consensus is lacking. This ability may assist in overcoming out-of-consensus situations where the knowledge involved in the out-of-the-box solution is not accepted by customers' subject matter experts, by allowing local experts to alter the knowledge as they see fit. Therefore, SmartWatch and Knowledge Framework may enable managing and changing the knowledge at project level (rather than by product level). Furthermore, such changes may not affect the original out-of-the-box components, but may be done on the “Save as . . . ” version of the implementation project, in order to minimize compatibility issues in the future.
      • B. Probabilistic decision logic: The clinical decision support may involve, where appropriate, probabilistic capabilities. Such probabilistic capabilities may be used where either the decision model dictates directly, or in cases where there are grey areas, for example, age weighed against other clinical indicators (patient is not 65, she is 64.95 but has strong indicators). In such cases, the decision (e.g. whether to invoke an action, to include or exclude some patient in the population) can be made using a threshold which is a property of the SmartGuard. In a way, the threshold value determines the balance between possible false positives (threshold it set too low, which may result in high rate actions to be taken based on false interpretations) and false negatives (threshold is set too high, missing true actions whose score was not high enough). Setting such a threshold depends on the nature of the SmartGuard—the risks involved in each kind of error, the impact of each and more.
      • C. Knowledge may be stated using normalized concepts represented in controlled medical vocabularies.
      • Have the knowledge presented in baseline codes, based on known standards. Using local vocabularies would make the knowledge non-transferable. In addition, baseline codes may to be used for distributing rules for the event monitor.
      • D. Rules may include full Boolean logic operators & expressions.
      • E. Time-dependent rules: Many situations may include time aspects in which SmartWatch may initiate a revisit to patient information driven by time related conditions, for example, verifying that a certain test is performed every 3 months. Simply waiting for the test to show up may be inappropriate.
      • F. The decision support logic may be backed up with references & explanations based on individual data.
      • In order to persuade consumers of the correctness of SmartWatch recommendations, an explanation documenting the decision support logic may be employed. This may include a reference to information on which the knowledge was modeled, as well as an explanation about how this knowledge was applied to the patient data—resulting in the recommendation. Such information may be sent to consumers in the message or viewed in an audit report. The purpose is to show who the knowledge authority is (society, expert, guideline, CMS, P4P) and to show how the system reached the conclusion.
      • G. User Defined Logic: In contrast to enterprise-defined rules to which an end-user can only subscribe, without the ability to change the rule logic, SmartWatch may also allow a user (physician) the ability to define his own rules, or refine an existing rule.
        • During a SmartGuard operation, actions are invoked, typically including various means to get a message across, making sure SmartWatch's recommendations reach the user in the most suitable way for him/her, within the specific context and, if necessary, making sure it is properly handled. This calls for a very powerful, flexible set of services for taking advanced actions. This may be a combination of out-of-the-box solutions and ‘application blocks’ as well as an environment to code a per-case/need workflow/process. An example set of requirements suitable for implementing this includes some or all of the following requirements 1-20:
          1. SmartWatch message typically contains sufficient information for the recipient to understand it: SmartWatch actions' output could be a readable message, sent to human actors via e-mail, fax, SMS and so on; or a message to other electronic systems, such as EMR, ClinicalViews, Database and so on, perhaps serving as a trigger to some process (integrated into the EMR workflows, integrated into the provider/patient portal/PHE etc). In either case, the message typically includes sufficient semantic information and should conform to the relevant standards to make it understandable for the receiving actor (human or application).
          2. SmartWatch outcomes as part of the VPO: SmartWatch's recommendations may remain, in the long run, as part of the VPO, accessible to dbMotion consumers in the same way as any other patient related information. One possibility for implementation might be for any recommendation generated by SmartWatch to be documented in the UMS. A new UMS domain may be built to accommodate the new information, following the HL7 RIM principles. The information may include some of SmartWatch metadata as well. For example, link the action (alert/notification) class linked (many-to-one) to a SmartGuard class linked with creator class and so on.
          3. Close the loop capabilities: SmartWatch may raise issues so important to the patient's well-being that an Email or SMS to the primary physician are not appropriate. Such a message is typically accompanied by some mechanism that verifies that proper actions have been taken, or at least that the issue was dismissed by a proper authority. SmartWatch keeps track of the events it sends, and provides a service that allows the receiving application to notify SmartWatch that the issue has been addressed (loop is closed). This service may also be able to supply a list of non-closed issues for a consumer. The details of when to remind, how escalation is handled and so on, can be part of the SmartGuard properties, although actual interaction with the user is made by the receiving application.
          “Remind Me” mode: In cases where the action channels include acknowledgment from a human user, a desired ability is for the user to ask to be reminded at a later time. This is helpful when the SmartWatch outcomes encourage a care provider to do something that he/she prefers to postpone. In this case, a ‘remind me’ service can be very helpful. SmartWatch may provide a service that enables the receiving application to utilize such a “remind me” functionality.
          Escalation workflow: An optional escalation process may be provided within the actions workflow to make sure issues raised by SmartWatch are addressed, by directing the message to another recipient after a predefined timeframe in which no response is received. Such a process may verify that the previous message was acknowledged and action has been taken in a timely manner. A system-defined need for such a step is introduced from communication reliability limitation (it is possible to ensure a fax is sent, but how can one verify that it was read?) and from physician availability (sent a message to a physician's EMR but she is on vacation)—for example, if the physician has not taken any action on an urgent case, the case may be escalated to her manager 24 hours later. SmartWatch may provide a service that may enable the receiving application to utilize such functionality.
          4. Narrative (free text) simple messages: In cases where an output message from SmartWatch actions is aimed at a human actor, the message may be expressed as a narrative text that describes the recommendation. For example “Patient belongs to XXXX population. It is highly recommended to perform the following blood tests . . . ”
          5. Narrative (free text) complex messages: When an output message from SmartWatch actions is aimed at a human actor, the message may be expressed as a narrative text that describes the recommendation and the logic behind it, and uses dynamic data to formulate the message. For example “Patient belongs to XXXX population. Based on <yy parameter> and <xx parameter it is highly recommended to perform the following blood tests: <recommendation ZZZ> . . . ”
          6. EMR Empowerment: Most typically, the preferred way for care providers to consume SmartWatch outcome is within the application they use from day-to-day—mostly the EMR they use for standard activities (workflow, CPOE, etc). This is why interaction with the EMR, allowing SmartWatch to use the EMR to get the message across, is useful.
          7. Structured messages: When an output message from SmartWatch actions is intended for another system, the message may be formatted in a structured format, so as to enable other systems to consume it. The message may contain semantics as appropriate, such that the information delivered to the consumer is understandable by the SmartGuard definition.
          8. Use Healthcare IT standards as SmartWatch output format: Wherever possible, in interacting with other systems, adhere to/comply with relevant recognized healthcare IT standards, such as CCD, CDA, HL7 V2/3 etc.
          9. Built in mechanism to standard delivery channels: The out-of-the-box offering may include the ability to send secured messages to standard devices and protocols such as SMS, email, fax. A lower priority channel, which may be useful for communication with patients, can be paper-based mail.
          10. Out-of-the-box actions workflow: SmartWatch may come with a set of out-of-the-box action solutions, and with ‘application blocks’. SmartWatch may allow the configuration/customization of the out-of-box action solutions to meet customer needs.
          11. Provider identity resolving/PCP service: When SmartWatch sends a message to a patient's care provider (in most cases the PCP), it is typically operative to correctly identify the relation between the patient and his provider. This PCP service is envisioned as part of dbMotion Core product, but it is crucial to SmartWatch.
          12. Action workflows and messages which are context-sensitive: Message format (text, color) and delivery method may depend on the context in which the message is sent, including, for example, the recipient role, urgency, time of day, and delivery method. The goal is to get to the consumers, mostly care providers, in a way most convenient to them, non-disruptive to their daily tasks. For example, when sending the output of a SmartGuard (e.g. alert/notification) as SMS and/or email, the choices may be smart and have some logic/workflow/rule based capabilities (e.g. not sending an SMS to physician X on Saturdays and Sundays between 09:00 to 17:00). SmartWatch therefore may have some basic business rule capabilities for this non-clinical logic (clinical knowledge is managed by Knowledge Framework).
          13. Paper/Fax messages: Some recipients of messages and reports may not be connected to the dbMotion network or only be loosely connected. Such a mode may only permit simple, one-way communication by fax or paper-based reports sent by mail. For example, transfer of care use cases introduces nursing homes as an actor that is a) not affiliated with the dbMotion network; b) not computerized in almost any way. A fax may be a good means of communication for such cases. Note may be taken as to how to obtain these contact details (e.g. recipient registry or Subscription) and how to tie them to the patient records. Another example relates to agencies to which reports may be delivered. An alternative simpler scenario could be when the paper report is electronically transmitted to a person, who is then responsible to fax/mail it to the target facility.
          14. SmartReports capabilities: SmartWatch is typically able to generate a report with the SmartGuard result/outcome. This may include all relevant information for the consumer/user. This report may be sent (as an option) automatically to a given printer/fax or be saved (as PDF for example). The report may be either patient specific or contain a batch of patients. Batching patients is useful for all the Use Cases that are classified as Reporting Use Cases in many scenarios. Example 1—preparation of a report for a physician of all his patients whose Coumadin-related evaluation points are due this week (with all information which may be used to make the call) allows him to get the job done much more efficiently than referring to them individually. Example 2—report to the authorities of quality performance/measures.
          SmartWatch is typically operative to: 1. enable report generation, using standard reporting tools (e.g. MS Excel). 2. Provide basic/simple out of the box report generation capabilities.
          15. Patient de-identification and re-identification: When sending messages to some systems or external agents there is a recognized need for patient de-identification, in order to maintain patient privacy and comply with HIPAA regulations. This de-identification may be performed in such a way that allows SmartWatch to reconstruct the patient identity (re-identify). De-identification omits any identifying patient details (names, addresses, phone numbers and so on), or replaces these with gibberish details. The de-identification procedure is consistent in that it yields the same result when applied again on the same input info. The de-identification method (in which fields may be scrambled/omitted from the message) may be customizable per project. Usage example 1: A SmartGuard for research purposes, either to identify eligible people or to gather data; Usage example 2—P4P measures computation may assume aggregation in some BI tool, where patient identity is irrelevant—however the ability to drill down back to the patient is desirable (assuming user's security privileges are adequate) which typically requires de-identification. There is great demand for such a service in many other domains of the dbMotion Core product. It may therefore be designed as a service that can be consumed by other layers/modules.
          16. Action's result urgency level: Actions taken and resulting messages may include an urgency level property indicating the urgency with which the message may be treated. An outgoing message should be marked with a proper urgency level indicating the impact of the delivery of that message. SmartWatch findings may be life-saving, but may also be less urgent, and may be treated accordingly. Urgency level may also be a subscription parameter (wants to be notified for very important items) or influence the delivery method (e.g. sometimes must send an SMS in a life-threatening issue). Such “lookup values” management functionality can be designed to use dbMotion Core Vocabulary Management and/or CTS.
          17. Confidence measure: As a decision support tool in a world of different semantics, units, possible missing information, and patient identification issues—a confidence measure may be assigned for each message. Such measures can also serve (similarly to urgency level) in determining the appropriate message delivery.
          18. Sending Messages to remote node recipients/subscribers: SmartWatch may support subscribers coming from different nodes. Securing subscription of users not from the local SmartWatch Node is usually a provided functionality, if there are anticipated issues with securing subscribers that the node, managing a SmartGuard, cannot authenticate & authorize.
          19. SmartWatch may have a subscription mechanism which allows consumers (e.g. physicians, health plans, external firms & agencies) to subscribe to get notifications from a given SmartGuard. Subscription information may include some filtering logic (a specific patient, all my patients, urgency level conditions, confidence measure threshold) contact information (fax number, email, . . . ) as well as preferences (e.g. preferred method of communication, time-of-day/day of week constraints)
          A possible business model is a customer paying per notification he receives. To accomplish this, SmartWatch keeps track of how many notifications each recipient/system receives, and stops sending notifications when the contract expires in a manner which may depend on urgency level. Another option (less realistic) is to limit a consumer subscription to a population whose size is limited by the consumer contract. A possible solution can control notifications based on dbMotion core Event Log counters.
          An enterprise may define mandatory notifications that a physician must receive, without voluntary registration. At the same time, it may be possible to define notifications that a physician actively subscribes/un-subscribes to. SmartWatch typically supports all 3 of the following options: a. mandatory, b. opt-in and c. opt-out. Note that opt-in/opt-out options rely on having a subscription/un-subscription mechanism.
          20. Activate EMR Workflows: In some cases, it might be beneficial for SmartWatch to initiate the ordering of new tests (e.g. laboratory tests). For example when confidence level is low, some new test may clarify the picture. This can be achieved in many ways, including notifying the PCP or integrating into EMR workflows. Optionally, SmartWatch is able to integrate directly with the EMR or Clinical Systems. Alternatively, SmartWatch is able to trigger EMR/Clinical System Worflows.
          The importance and difficulty of achieving high adoption rates is known. Some or all of the following requirements A-C may be provided in this context, including software requirements from the infrastructure, as well as guidelines or best practice for the solutions to be built on that infrastructure:
          A. Enable feedback from users: In an interaction with users, SmartWatch may allow a user to provide feedback that can be considered for future product refinement. This applies to SmartWatch and Knowledge Framework management tools (SmartGuard editor, Knowledge acquisition tool, control room,) as well as to interaction through messages, and interaction integrated into the care-provider workflow (EMR empowerment). Feedback may include user response (free text) as well as internal information (application info, SmartGuard info . . . ). The feedback may be sent to dbMotion and the relevant IT owner. One simple example for such interaction is to provide the user who receives the message an email address to send his feedback. A more advanced solution is a web form to submit his feedback which may also include the context of that specific message. A possible solution could utilize dbMotion Core ADR.
          B. Fit into clinician workflow: A decision support tool typically has its recommendations integrated into the clinicians' application in a way that is not disruptive and is context-sensitive. This is mostly relevant for SmartWatch solutions built on top of the framework—but the framework may facilitate it, for example, by providing the infrastructure for EMR empowerment as described herein.
          C. Look for knowledge consensus and knowledge authority: When building a SmartGuard (SmartWatch vertical solution) the question of knowledge consensus may arise. Many clinical scenarios are difficult in this regard and it may be hard to achieve users' acceptance of decision support recommendations based on knowledge resources they doubt. An independent knowledge authority such as medical associations and societies that publish their best practice care plan may be helpful. SmartWatch and SmartGuard System Management Requirements may include one or more of the following requirements 1-9:
          1. SmartGuard activation: SmartWatch typically has the ability to start and stop SmartGuards independently of one another. When stopping a SmartGuard and restarting it at a later time special caution should be taken in making sure that no input events are lost in the process (all relevant records that were inserted during the time the SmartGuard was down are revisited when the SmartGuard is activated).
          2. SmartGuard Expiration Date: One of the SmartGuard attributes may be Expired Date. If such a date is defined for the SmartGuard, it may stop automatically when the date is reached.
          3. Monitoring tools—Auditing, Logging: SmartWatch typically employs a set of monitoring tools and a consistent auditing and logging methodology with tools to assist in tracking activities over time—for example, alerts which the system sent over time, to whom, sees that the loops were properly closed, and so on. This would greatly help in evaluating the ROI of a given SmartGuard SmartWatch and leverage the existing tools provided by the dbMotion product.
          4. SmartWatch Control Room: The monitoring and system management tools may be part of the larger concept, the Control Room. Someone sitting in the SW (virtual/physical) control room and in front of one/a few screens is able to manage the whole operation: track log, activate/de-activate SmartGuards, see/correct errors etc. Such an application may track all activities in the different SmartGuards and monitor their operation—track ALL the activities in the SmartWatch network, enable deactivate/activate SmartGuards, audit the various types of errors (and act on them), filter all the active SmartGuards, see the status and all relevant information for each one.
          5. Document and manage all changes made to the system after deployment: SmartWatch may follow common practice in the content management field in order to make sure that the SmartGuard metadata and related knowledge always have the most updated information, versioning, and so on. Several examples: approval date, owner (company, person), update dates etc (Content Management). SmartWatch can utilize the existing dbMotion core product mechanisms for management change (mainly the Reference Model).
          6. Maintain SmartGuard integrity: SmartWatch relies on a suitable source such as the dbMotion core product as an information source, and is typically made aware of changes in dbMotion. Such changes, low down, could be for unrelated reasons, where the people making a change are unaware of the effect it may have on SmartGuards that hover above and consume the data and the chance that a change may affect some SmartGuard function in the wrong way. The outcome can be a false negative, which may be potentially dangerous. Semantic changes—for example changing business rules and/or data modeling decisions without changing the structure—are handled with caution. Examples of dbMotion changes that can affect SmartWatch: changes in the UMS, business methods, mapping in terminologies, archetype, KW, lab values (and many more). These changes can easily give rise to a malfunctioning SmartGuard. A possible solution utilizes the dbMotion Reference Model system to maintain SmartGuard integrity. The reference model manages the overall dbMotion system configuration and the relations between the dbMotion components. The importance of the Reference Model in this case goes way beyond the implementation domain (project Vs product).
          7. Search capabilities in SmartWatch metadata: SmartWatch may provide the ability to query the SmartWatch metadata repository for SmartGuards based on some topic, keyword or clinical term (using some vocabulary). For example, a list of all SmartGuards related to hypertension.
          8. SmartGuard feasibility testing: Once a SmartWatch is defined, estimation may be made of population size, verifying that the SmartGuard is feasible. This information may be considered for SmartGuard approval (in each node). For business security, this information is not exposed across nodes.
          9. SmartGuard full description: A description of the SmartGuard in free text: —e.g. what is the population?, what information is gathered? and why?—the decision logic process, the actions that are taken. This may be a generated report, but may include meta data text pieces that were captured along the way.
          Security & privacy requirements may include some or all of the following requirements 1-12:
    1. General:
  • Users are authenticated prior to accessing the system. Users are authorized for the operation they perform. Access to any storage system is secured. Secured Communication may be established for ePHI. In any case where patient data is used for research purposes, all patient identifying properties may be removed from it (de-identification). Every significant action in the system that relates to a covered entity (patient) may be recorded.
    2. Actions may protect patient privacy. Since SmartWatch has the potential to distribute patients' data outside the dbMotion world and to non-authorized users, it may provide means to protect patient confidentiality with regard to information that is included in notifications and the actors who receive them. SmartWatch should have authorizing tools that verify who receives patient-related notifications, and a security methodology for SmartGuard development, configuration and deployment. A methodology is useful to prevent overlooking patient privacy. The authorizing tools are employed to facilitate verification that outgoing messages are authorized. The SmartGuard may always send the minimal data set that is relevant to the context of the specific SmartGuard.
    3. Subscription security authorization: SmartWatch enforces authorization for subscribing to SmartWatch actions to get messages, to avoid unauthorized access to confidential patient information as a result of notification
    4. SmartWatch management tools security and auditing: SmartWatch controls access to its management tools and audit user activities for several reasons: a) sensitive information may be accessible to users of these tools, for example through auditing messages sent b) changing security-related settings can cause HIPAA violation (for example if patient consent policy setting is altered) and c) changing SmartWatch settings definitions may jeopardize the proper functioning of the system. As to the question of who may stop and start SmartGuards, this is typically done only by an authorized administrator and is audited. Deactivating a SmartGuard can have severe implications if clinicians rely on its actions. SmartWatch may therefore provide and manage secure access (authentication and authorization) to Smart Watch management tools.
    5. Access data across the enterprise (using dbMotion) in a secure manner: SmartWatch is typically operative to access data across the enterprise (using dbMotion) in a secure manner, utilizing a secure channel, authentication and authorization—for example, a need to prevent SmartWatch from accessing unauthorized data domains.
    6. Enterprise business security: SmartWatch introduces an amplification of all the barriers found in the dbMotion core with regard to ownership. While the ‘per-patient and only for-patient-at-the-point-of-care’ argument usually works in the patient centric viewer model of dbMotion core, this will not always be the case with SmartWatch. The customers concerned (hospitals) may have doubt about querying their CDRs/operational systems in a ‘batch-mode’ (in contrast to treatment-based context implied when a clinician views patient ePHI) which may be mitigated by a federated model and a mechanism that guarantees to some degree that the data is used for the purposes agreed upon only. This concern is greater in a RHIO setting where SmartWatch has the potential of revealing too much business-sensitive information between hospitals/organizations that may be business competitors. SmartWatch may therefore enable the customer to manage and control access to his data repositories.
    7. Securing SmartWatch storage: The SmartWatch process may involve short-term or long-term storage of ePHI. The storage devices are secured. Furthermore, customers may require enforcing regulations that prevent duplication or centralized storage of identifiable ePHIs.
    8. STRQ43.9 Auditing: SmartWatch may enable auditing of all operations that relate in any way to accessing patient information (ePHI). An audit entry may include details of the user, the time the operation took place, and the ability to generate audit reports—with the option to audit any changes in SmartGuard settings, any operation in SmartGuard or SW management, and any message that was sent. In addition, audit of SmartWatch Actions may include ALL the information about a recommendation/notification/alert, including its content and narrative explanation (mainly for medico-legal reasons).
    9. STRQ43.10 Notifications over unsecured delivery channels: SmartWatch may be designed to deliver messages to both secured systems and to people over potentially unsecured channels such as Email, Fax or SMS. Provisions are typically made both for protecting patient privacy in the message content and for technologically securing the channel. For example, Email could be signed and encrypted, an SMS message may include partial, non-confidential information, directing the user to view the full notification in a secured system, to which the message was sent in parallel. The recommended practice is using secure channels only.
    10. Patient consent to be incorporated into the SmartWatch process: SmartWatch may find a way to take into account patient consent considerations when deciding on including a patient in a SmartGuard. Policies can be established at enterprise or SmartGuard level that may include (but are not limited to) opt-in, opt-out, no consent required. SmartWatch may utilize the dbMotion core PAS.
    11. SmartGuards from using ePHI retrieved under a different role/contract, or ePHI retrieved under different authorization settings (i.e. role/contract): SmartGuard may use information it was not authorized to view. In other words, data sharing between SmartGuards can put patients' privacy at risk unless they share the same authorization level (for example, the same role/contract which means they have exactly the same permission).
    12. Use existing dbMotion Core Security System and Auditing System: SmartWatch may use dbMotion Product Security and Auditing, as much as possible, for meeting security and privacy needs. This may reduce costs in the SmartWatch Product Development, and simplify the work of the customer security admin—using the same tools and settings both for dbMotion and SmartWatch. This means that SmartWatch may not have its own Security Layer, but rather utilize dbMotion core security. Since there are many cases where there is no cross-enterprise unique patient identifier, patient identity is not deterministic. This may impose some or all of the following constraints 1-3 on SmartWatch:
    1. SmartWatch cannot assume patient clustering is stable.
    When using records collected at different points in time, SmartWatch cannot assume that patient identity has not changed, i.e. that the patient's cluster as determined by the EMPI system is the same as before. Special note is taken for the join/add operation (when a person's identity is added to the EMPI cluster), which is hard to spot. Therefore, SmartWatch typically employs cluster consistency procedures to verify that the patient cluster has not changed along the way.
    2. Patient enrollment scenario.
    When a physician selects a patient cluster/index retrieved from the EMPI system—the selection may be stored in SmartWatch. Proposal: save a leading index whose cluster may be used as the virtual patient.
    3. SmartWatch may be able to work in an environment that has a unique patient identifier for all systems, without EMPI. This applies to some European countries and Israel.
      • Other design considerations may include the following considerations 1-7:
      • 1. Any audit entry may include the relevant unique SmartGuard identifier as well as the date and time. All the SW's auditing and tracking may utilize the dbMotion core STL & ADR (CEB).
      • 2. Population size limits constraint. Since population primary criteria are a matter of configuration, it is potentially possible to define very large populations that include all patients (i.e. age >0). Such a population might have a significant effect on the system performance—both dbMotion and SmartWatch, and practically hang the system while collecting data for it. For this reason, constraints may be set on either population size (data may not be collected for a population with over 10 k members), or on the rate of collecting the data (allow collecting data for 1 k members per day). Similar constraints may be set to interaction with external systems, especially EMPI providers. Another solution could be a testing methodology and tools to identify such large populations.
      • 3. Knowledge-level adjustability: The clinical knowledge SmartWatch uses ought to be adjustable at the customer site by knowledge engineers with a clinical background, using a knowledge acquisition tool/archetype designer, e.g. as described herein with reference to FIGS. 4A-8C.
      • 4. System-integrator-level adjustability: SmartWatch may allow much space for the Project Implementation Team (system integrator level) customization & configuration with regard to the following aspects:
      • 5. It is envisioned that much customization may be carried out in the action layer, since the external systems and preferred communication methods may vary greatly between customers. The Action Manager is therefore typically flexible and adaptive and offers ready-made communication tools, and best practices with regard to actions' workflow SDK's. The Action Manager may be generally prepared for customization by the Project Implementation team.
      • 6. The ability to create and modify SmartGuards may be available at least at the system integrator level. Preferably, most activities should be performed by the customer's administrator level. The functionality includes a set of tools that allows the system integrator to configure the criteria defining the patients to collect data for, the data to collect, calculations on that data, the rules applied on them, actions to be taken when patient data matches the rules' logic, and a ‘close the loop’ workflow. Some guidelines that may help in this regard are the use of templates; allowing their creation based on an existing SmartGuard (save as, e.g.); following the 4 layer path which makes sense to clinicians; SDK and Application Blocks.
      • 7. Taking into account the fact that the infrastructure cannot be developed to support any future need ahead of time, all SmartWatch components may be extensible. Some examples are the ability to communicate to proprietary delivery channels, a need to monitor triggering events that were not supported in the original design and supporting implementation with no CDR. Testability requirements may include some or all of the following requirements 1-5:
      • 1. SmartGuard test mode: SmartWatch may provide a testing mode to facilitate the construction of new SmartGuards or changes to existing ones. This may be beneficial both in the development environment as well as on the customer side. When working in such a mode, the SmartGuard may be limited in some ways, for example in its outside communication capabilities. The test mode may be applied at the SmartGuard level, allowing a tested SmartGuard to run side-by-side with production SmartGuards.
      • 2. Enable Automatic Testing thru SOA: Some GUI capabilities may also be provided through services, in order to allow these server-side functionalities to be tested using automatic testing implemented by program tools.
      • 3. Test-dedicated tracking events (STL) to promote testing processes: SmartWatch may add entries to STL for test purposes, at each major step along the way, to allow testers to track process progress. Preferably, STL may be triggered on entry and exit of each major function, stating status and duration. However, logging level configuration may be enabled (so in production there may be less system events than in debug mode.). A similar methodology to the system events tracking in the dbMotion product may be used.
      • 4. Log messages verbose mode: SmartWatch may supply a verbose mode in which state variables, input parameters, intermediate computation results and so on can be written to log files. This may help in testing and debugging (during the development phase) and may also be helpful in analyzing problems at an operational site.
      • 5. Allow offline testing using test data emulator: Because during SmartGuard development, a dbMotion network and other components (DSS, EMPI) might not be available, and since it may be hard to provide meaningful data for a variety of SmartGuards, it may be possible to replace dbMotion, VIA, and KFW with test data simulators—preferably existing dbMotion Product simulators.
  • An example of health information exchange and integration system constructed and operative in accordance with certain embodiments of the present invention is now described with reference to FIGS. 18A-137 which may operate in conjunction with healthcare information integration software commercially available from dbMotion Inc., US Steel Tower, 600 Grant Street, Suite 22017, Pittsburgh, Pa. 15219, such as dbMotion's service oriented architecture (SOA) based dbMotion™ Solution.
  • Unified Modeling Language (UML) is a standardized general-purpose modeling language in the field of software engineering used in generating the above drawings. The standard is managed, and was created by, the Object Management Group. UML includes a set of graphic notation techniques to create visual models of systems with software components.
  • The CTS sub-unit of the example health information exchange and integration system is first described with reference to FIGS. 18A-105D. Specifically, FIGS. 18A-18B, taken together, illustrate a Use Case Model—(Use Case diagram). FIG. 19 illustrates an Actor View—(Use Case diagram). FIG. 20 illustrates a CTS Runtime Use Case View—(Use Case diagram). FIG. 21 illustrates CTS Metadata Service Use Cases—(Use Case diagram). FIG. 22 illustrates a Get Service Address functionality (Use Case diagram). FIG. 23 illustrates a Manage Extension functionality—(Use Case diagram). FIG. 24 illustrates a Manage Named Query Metadata functionality—(Use Case diagram). FIG. 25 illustrates CTS Extension Use Cases—(Use Case diagram). FIG. 26 illustrates a Fill Concept Information in Vocabulary Business Aspect—(Activity diagram). FIG. 27 illustrates CTS Extended Solution Use Cases—(Use Case diagram). FIG. 28 illustrates CTS First Analysis Use Cases—(Package diagram). FIG. 29 illustrates a CTS Management Use Case View—(Use Case diagram).
  • FIG. 30 illustrates an Add Local Code functionality—(Activity diagram). FIG. 31 illustrates a CTS Metadata Use Case View—(Use Case diagram). FIG. 32 illustrates a Design Model—(Logical diagram). FIG. 33 illustrates a Logical Model—(Logical diagram). FIG. 34 illustrates a System—(Logical diagram). FIG. 35 illustrates Services—(Package diagram). FIG. 36 illustrates a Query Service—(Logical diagram). FIG. 37 illustrates Service Contracts—(Logical diagram). FIG. 38 illustrates an Execute Command functionality—(Sequence diagram). FIG. 39 illustrates a Get Next Response functionality—(Sequence diagram). FIG. 40 illustrates a Query Processor—(Logical diagram). FIG. 41 illustrates a Service Contract—(Logical diagram). FIG. 42 illustrates Metadata Services—(Logical diagram). FIG. 43 illustrates an Information Service—(Logical diagram). FIG. 44 illustrates a Management functionality—(Package diagram). FIG. 45 illustrates an Analysis functionality—(Package diagram). FIG. 46 illustrates Business Entities—(Logical diagram). FIG. 47 illustrates a Client—(Logical diagram). FIG. 48A illustrates a Service—(Logical diagram). FIG. 48B illustrates Tools—(Logical diagram). FIG. 49 illustrates a Framework—(Logical diagram).
  • FIGS. 50A and 50B illustrate a Tool API—(Logical diagram). FIG. 51 illustrates a Shared—(Logical diagram). FIGS. 52-57, taken together, illustrate an Information Model—(Logical diagram). FIGS. 58-63, taken together, illustrate a Management Information Model—(Logical diagram). FIG. 64 illustrates Management Data Contracts—(Logical diagram). FIG. 65 illustrates Management Query Data Contract—(Logical diagram). FIG. 66 illustrates a Management Query Data Contract—Functions Specification—(Logical diagram). FIG. 67 illustrates Metadata—(Logical diagram). FIG. 68 illustrates Metadata Query Objects—(Logical diagram). FIG. 69 illustrates Metadata Schema Objects—(Logical diagram).
  • FIG. 70 illustrates Metadata PlugIn Objects—(Logical diagram). FIG. 71 illustrates a Query—(Logical diagram). FIG. 72 illustrates a Request Data Contract—Query Function Area—(Logical diagram). FIGS. 73-78, taken together, illustrate a Request Data Contract—Query Functions Specification—(Logical diagram). FIG. 79A illustrates a Response Data Contract—(Logical diagram). FIG. 79B illustrates a Client—(Logical diagram). FIGS. 80-83, taken together, illustrate Service Access Total Diagrams—(Logical diagram). FIG. 79C illustrates a Management functionality—(Logical diagram). FIGS. 84-86, taken together, illustrate Service Access functionality—(Logical diagram). FIG. 87 illustrates a Query—(Logical diagram). FIGS. 88-89B, taken together, illustrate a Service Access—(Logical diagram).
  • FIG. 90 illustrates Client Basic Scenarios—(Use Case diagram). FIG. 91 illustrates Execute Query functionality—(Sequence diagram). FIG. 92 illustrates a Fill Query Data Set—(Sequence diagram). FIG. 93A illustrates a Put Cached Items to Result and Correct the Bulk Parameters—(Sequence diagram). FIG. 93B illustrates a Service—(Logical diagram). FIG. 93C a Query Processor—(Logical diagram). FIGS. 94-96, taken together, illustrate a Query Processor—Abstract Model—(Logical diagram). FIG. 97 illustrates a Shared functionality—(Logical diagram). FIG. 98A illustrates a Session Management functionality—(Logical diagram). FIG. 98B illustrates System Services—(Logical diagram). FIG. 98C illustrates a Metadata Service—(Logical diagram). FIG. 98D illustrates a Query Processor—(Logical diagram). FIG. 99 illustrates Frameworks—(Logical diagram).
  • FIG. 100 illustrates a Common functionality—(Logical diagram). FIG. 101 illustrates Service Contracts—(Logical diagram). FIG. 102 illustrates a Data Model—(Logical diagram). FIG. 103 illustrates an Implementation Model—(Component diagram). FIG. 104 illustrates a CTS (Logical diagram). FIG. 105A illustrates a management functionality—(Logical diagram). FIG. 105B illustrates a parameter—(Logical diagram). FIG. 105C illustrates an exception—(Logical diagram). FIG. 105D illustrates a model—(Logical diagram).
  • In FIG. 18A, the CTS query use case Responsibility may include that it provides information about concepts in dbMotion ontology including Concept details and/or Search mechanism. The CTS metadata service use case Responsibility may include that it provides metadata information about CTS service for consumer-services for integration in the design and runtime. An Extension framework may provide the following Use Cases: Creation and developing of CTS extensions; and/or Internal product simple basic query extensions.
  • In FIG. 27, the first determining step may include some or all of the following operations:
      • 1. For local ValueSet determinate baseline concepts
      • 2. For baseline concepts determinate parent baseline concepts in the specific context
      • 3. For parent baseline concepts determinate all local concepts.
        • The second determining step may include some or all of the following operations:
      • 1. For local ValueSet determinate baseline concepts
      • 2. For baseline concepts determinate child baseline concepts in the specific context
      • 3. For previous resulting baseline concepts determinate local concepts.
  • In FIG. 32, the Design Model may include at least the Logical Model and the Data Model. The Logical model included the System and Framework sections. Both may include classes and artifacts which define the structure of the code used in the application under development.
  • In FIG. 33, the Logical Model is a model of the software system under construction. It may include classes which generally have a direct relationship to source code or other software artifacts that can be grouped together into executable components. The system package contains the classes and artifacts which are being built or designed as part of the current model. The Frameworks package generally contains classes and components that have been designed and built earlier and are being reused as part of the current project.
  • In FIG. 92, current cache-optimization may include the following steps:
      • 1. For every bulk parameter, attempt to find cached object
      • 2. In case it exists—put to QueryDataSet and remove bulk from existing ParametersSet.
  • In analysis of results, it may cache objects in the cache by bulk hash-code and endpointname. In FIG. 98D, an Analyser may be operative for parsing and logical analyzing of query text. Factory query object may work through Analyser.
  • In FIG. 102, typically a schema package contains a logical grouping of tablets. This model describes the data which must be stored and retrieved as part of the overall system design. Typically this will mean relational database models which describe the tables and data in detail and allow generation of DDL scripts to create and setup databases.
  • In FIG. 103, typically, the implementation Model defines how classes, artifacts and other low level elements are collected into high level components and the interfaces and connections between them. Components are compiled software artifacts that work together to provide the required behavior within the operating constraints defined in the requirements model. Components may be deployed to varying hardware platforms e.g. as described in the Deployment Model. The Components package contains modeled components and their structural constituents. These include additional exposed interfaces, ports and other gateways or internal structural components. The connectivity and internal structure of these are further modeled in the internal Structures and Connections packages.
  • Internal structures provide a detailed view of possible internal workings and dependencies of a component. Using a Composite Structure diagram, they illustrate how the component fulfils its behavioral contracts and provides interface behavior to other components within the system. The Connections package models the dependencies and connectivity between the various components, and how each is used as part of a co-operative system to accomplish required tasks. Typically, Components expose interfaces and API's which are used by other Components.
  • The knowledge framework sub-unit of the example health information exchange and integration system is now described, referring back to FIGS. 9-13C. The illustrated embodiment is an example implementation of the KFW subunit of FIG. 1A which is not intended to be limiting.
  • Specifically, the implementation's CTS Runtime Interfaces are described with reference to FIG. 9. A Knowledge-Framework and Knowledge-Module Static Model are described, including business identifiers described with reference to FIG. 10A, an artifact described with reference to FIG. 10B, and a knowledge-Module Entities Model described with reference to FIGS. 10C-10F. A KFW Business-Object-Model (BOM) is described with reference to FIGS. 11A and 11B. A KFW Evaluation Interface is described generally with reference to FIG. 12A. An Evaluation Request for the KFW Evaluation Interface of FIG. 12A is described with reference to FIGS. 12B-12C. An Evaluation Response for the KFW Evaluation Interface of FIG. 12A is described with reference to FIGS. 12D-12E. A KFW-Evaluation Process described with reference to FIG. 13A. An Evaluation Plug-in Mechanism is described with reference to FIGS. 13B-13C.
  • Generally, in the example implementation, Knowledge-Framework (KFW) is a decision-support service. KFW manages and evaluates Knowledge-Module (KM) entities. A KM contains a piece of clinical business-logic. A KM has a well defined contract: a set of specified input data and a set of results. KMs are modular and can be re-used, i.e., the output of one KM, can be used as input for another one. The body of a KM is its decision-logic. The decision-logic is based on input data and set the KM evaluation-results. The decision-logic is created and managed by knowledge-experts (e.g., clinicians). The decision-logic may use CTS ontology concepts. These concepts are defined implicitly as queries (commands) over dbMotion's CTS ontology only.
  • At runtime, KFW consumers send requests to evaluate actual patient data. The raw patient data is stored in dbMotion database using its local terminology. Before the data (e.g., a lab result) reach KFW service, the data is pre-processed and enriched with a mapping to dbMotion's CTS ontology. As a computation of the requested KM starts, KFW asks CTS to evaluate the pre-defined CTS queries. CTS returns a list of CTS ontology concepts. During the KM's decision-logic evaluation, KFW may check whether the patient actual data corresponds to one of the concepts in the result of the expected query.
  • Example CTS Runtime Interfaces are now described with reference to FIG. 9. KFW defines the following interfaces and allowed operations on CTS objects:
      • a. CTSRuntime: a marker interface.
      • b. CTSConceptRT: represents a single CTS concept identifier. sameConcept(CTSConceptRT other): returns true if the other concept is equivalent to this concept.
      • c. CTSConceptListRT: represents a list of CTS concepts. Contains(CTSConceptRT item): returns true if this list contains the given item.
  • A Knowledge-Framework and Knowledge-Module Static Model is now described. Business Identifiers: FW identifies its entities using identifiers, e.g. two types of identifiers, (a) and (b), as shown in FIG. 10A:
  • a. EntityIdentitifer: identifies main entities and may include:
      • ScopingEntityId: a scope of ids (similar to namespace)
      • BusinessId: business id of the entity within the scoping entity
      • Version: version of the entity b. ItemIdentifier: for entities that are composed in main entities. May include:
      • ContainingEntityId: the id of the containing entity
      • ItemId: unique id of this item within the containing entity
  • Artifact, e.g. as shown in FIG. 10B, is used to store not-structured data or data that KFW is agnostic to its structure.
  • An example Knowledge-Module Entities Model is illustrated in the class KM diagram formed by FIGS. 10C and 10D, taken together as indicated by the arrows. KFW internally operates on ‘Entities’. KFW-Entities is an object-model mapped to a relational database. The main entity in KFW is the ‘KnowledgeModule’ (KM). A KM extends from ‘ScopedEntity’ and hence is identified by an ‘EntityIdentifier’ (see above). A KM may include some or all of the following members:
      • a. DecisionLogicType—determines the type of the decision-logic used in this KM. These are examples for possible values: ‘decision-table’, ‘rules’, ‘java code’ etc.
      • b. Status—determines the status of the KM. Example values are: ‘draft’, ‘in_production’, ‘obsolete’ etc.
      • c. InitialDataRequirements: a set of DataRequirementItems (DRIs) employed in a particular application, when evaluating a KM. A DRI is a KMItem, and hence is identified by an ‘ItemIdentifier’ (see above). Each DRI specifies one named data-input of the KM, e.g., ‘last year encounters’. The DRI is specified in one or more alternate DataModels. Each model format of the expected DRI data is defined by referencing a particular xml type in an xml schema (e.g., ‘encounters’ xml type). In addition, the DataModel can also constraint the returned data by specifying a query (the internal structure of the query is not in the scope of KFW). Typically, a Data model may be defined in one of dbMotion's schemas, using dbMotion's query language.
      • d. AdditionalDataRequirements: an optional set of DRIs that may be required. For example, if certain patient data is rarely needed by the KM and is expensive to collect, it may be defined as a DRI in AdditionalDataRequirement. Example: an initial call to evaluate a KM may contain only InitialDataRequirements (those that are easy to collect). Only if KFW failed to reach a conclusion using this data, the KFW response may contain a requirement for these AdditionalDataRequirements.
      • e. EvaluationResults: a set of evaluation-results. Each evaluation result declares the format of the returned data. This set is the output signature of a KM. For example, if a KM returns a yes/no answer it may have one evaluation-result of type Boolean. An evaluation-result can be computed in this KM, or propagated from the evaluation of another dependent KM.
      • f. DecisionLogicItems: a set of abstract source artifacts that defines the KM decision-logic. For example, it can be an Excel file that defines a decision-table. Or it can be a Java program that parses the input data and computes an evaluation-result. The actual type of the decision-logic artifacts depends on the value of DecisionLogicType attribute on the KM level.
      • g. CTSItems: a set of abstract items specifying one or more CTS ontology concepts e.g. as shown in FIG. 10E. CTSIntensionalItem uses an Artifact e.g. as described above to specify a CTS command.
  • A CTS command is the main object to query CTS, e.g. as illustrated in FIG. 10F. In FIG. 10F, typically, the command state is created at design-time by browsing CTS metadata service and selecting (or creating) a command. The command is saved in an artifact. When calling contains(CTSConceptRT item) method, the ctsItem calls CTS Query Service passing the command. CTS returns a flat list of CTS ontology concepts that satisfy the command. Finally, the method checks if the given item is included in this result list.
  • CTSExtensionalListItem typically comprises a hard-coded list of CTS ontology concepts and implements the contains( ) operation. CTSIntensionalSingleItem typically comprises a hard-coded single CTS ontology concept and implements the sameConcept( ) operation.
  • A suitable KFW Business-Object-Model (BOM) is now described. As described above, at runtime KFW evaluates patient data. The data reaches KFW service as xml documents (in dbMotion's format) and is transformed internally into (Java) objects. The model of this data is called the ‘Business-Object-Model’, or BOM in short. For example, Condition is a class in the BOM. The BOM may refer to CTS concepts. For example, Condition.Code is coded using CS class. CS class represents a CTS concept. At its root level it contains code and codeSystem attributes to identify a concept in a local terminology. The CDTranslations composition contains translations of this concept to other terminologies. In particular, this collection contains the translation to dbMotion's CTS ontology.
  • CS class also implements the CTSConceptRT interface. Hence, operations sameConcept( ) and contains( ) that were defined on KM CTSItems can be applied on BOM attribute values. The sameConcept(other) method in CS class is implemented by comparing the other.code+codeSystem attributes to CS root level attributes, or by finding an element in CDTranslations that satisfies sameConcept(other). FIG. 11 is a diagram of an example class condition.
  • An example KFW Evaluation Interface is now described. Typically, KFW exposes several interfaces. The evaluation interface of FIG. 12A is an example of a suitable interaction between KFW service and CTS. The interface of FIG. 12A defines four evaluation methods. The flow in all methods may be similar, so for simplicity only the flow of the first method—evaluate( ) is described hereinbelow. The method receives an EvaluationRequest and returns an EvaluationResponse. An example EvaluationRequest is now described with reference to FIG. 12B. In FIG. 12B, KMEvaluationRequests includes a list of KM ids to evaluate in this request. DRIData includes a list of patient data to use in the evaluation. Each DRI in the request object refers to DRI of an existing KM (using DRI ID). The data itself is enveloped in a SemanticPayload which includes a payload of data in xml element format. The informationModelSSId specifies the actual format of the data.
  • FIG. 12C is an example of an EvaluationRequest in xml format. This is a request to evaluate a single KM, with a single DataRequirementItemData (DRIData) of type ‘Conditions’ which contains (in this example) a single ‘Condition’. Condition.value is a CS element that carries a local (i.e., from legacy system) concept code. In addition, CDTranslation element specifies a mapping to a dbMotion's ontology concept. This translated code may correspond to the CTS codes expected by the KM.CTSItems.
  • An example EvaluationResponse is now described with reference to FIG. 12D. In FIG. 12B:
      • FinalKMEvaluationResponses: a collection of responses for KMs that KFW service has successfully reached a final result.
        • KnowledgeModuleId: the id of the KM that this response refers to
        • EvaluationResultsData: a collection of evaluation result data. One item per an EvalutionResultItem in the referenced Km.
          • EvaluationResultId: the id of the referenced EvalutionResultItem
          • SemanticPayload: the data itself, in the format declared by the EvalutionResultItem
      • IntermediateKMEvaluationResponses: a collection of responses for KMs that KFW service could not reach a final result, probably because of missing data.
        • RequiredDRIIds: a collection of KM DataRequirementItem Ids that are missing for reaching a final result of this KM.
  • FIG. 12E illustrates an example of a KM evaluation result.
  • An example of a KFW-Evaluation Process is now described. As described above, one runtime use-case of the KFW service is ‘evaluate’. The evaluate method receives an EvaluationRequest and returns an EvaluationResponse (both were described above). FIG. 13A is a top level simplified flow diagram of an example evaluation process. EvaluationLocalBean is the class that implements the Evaluation interface. Typically:
      • 1. The consumer sends EvaluationRequest messages to the bean.
      • 2. The request contains pointers to the KMs to evaluate. Hence, the first step is to retrieve the KM entities from the database.
      • 3. A DataContext is created. The DataContext initially contains all the DRIData provided by the consumer. During the process, computed evaluation-result data are accumulated on this DataContext.
      • 4. An EvaluationPlan is created. The problem is that an EvaluationRequest may comprise one or more KMs that can have inter-dependencies. KFW has to determine a sequence of KMs to evaluate. A plan serves as a strategy of the KM evaluation sequence.
        • For example, one may assume this knowledge base: [a, b, c->a, b] (i.e., km c depends on the outputs of kms a and b.), then on runtime KFW receives a request to evaluate km c. One option is to evaluate the KMs in this sequence: [a, b, c]. Another strategy might be [a |b, c] (i.e., to compute a and b in parallel and to compute c).
      • 5. The plan is executed with the dataContext. During the plan execution evaluationResult data are accumulated in the dataContext.
      • 6. An EvaluationResponse is assembled by looking at which KMs were originally requested and the actual data is collected from the dataContext.
  • An Evaluation Plug-in Mechanism is now described which is useful in the process of evaluating a single KM. As described herein with reference to the KM static model, KM decision-logic is stored in artifacts. The KFW supports a mechanism to plug-in new decision-logic types. For example, the decision-logic can be declared in rules, or using a decision-table. The plug-in mechanism that evaluates a particular KM is determined by its KM.DecisionLogicType attribute value. Hence, KFW holds a map where the keys are decisionLogicTypes and the values are DecisionLogicPluginProvider objects. For performance reasons, the KM decision-logic artifacts are compiled into a plug-in proprietary form. This compiled form is also stored in the KM static model in a special artifact. FIG. 13B is a diagram of an example class manager. In the embodiment of FIG. 13B:
      • DecisionLogicPluginProvider: a factory object that provides appropriate compilation and evaluation plug-ins.
        • getCompiler( ) returns a DecisionLogicCompiler object
        • newEvaluator( ) receives a KMSignature and a compiled artifact and returns a new Evaluator.
      • DecisionLogicCompiler: an object that knows to compile source artifacts in a specific decision-logic format
        • Compiled( ): returns a new artifact that contains the compiled form of the source artifacts
        • getErrors( ): returns a list of errors in the source artifacts.
      • Evaluator: an object that evaluates requests and returns responses.
  • A typical KFW-plug-in evaluation process is illustrated in FIG. 13C in which an AtomicEvaluationPlan is the implementation class of EvaluationPlan interface for evaluating a single KM. A KM entity is passed in the constructor call. If the KM does not contain a compiled artifact, the sources have to be compiled. In practice, a compiled artifact is usually already set in production systems (it may be null only during the KM authoring stage). EvaluationPluginManagerImpl is a singleton object that contains a map of decisionLogicType strings to DecisionLogicPluginProvider objects. This map is initialized from configuration. The plan asks the provider to get a compiler object. The compiler gets the KM entity and returns a compiled artifact. This compiled artifact is stored.
  • When the plan is executed, the plan asks the provider to provide an Evaluator object. The Evaluator object is constructed from KM entity (expecting a not null compiledArtifact). The Evaluator.evaluate( ) method is called passing the driData (extracted from the request). The evaluator is state-less and the same evaluator can be used several times to evaluate different requests of the same KM.
  • The SmartWatch sub-unit of the example health information exchange and integration system of FIG. 1A is now described with reference to FIGS. 106A-137. FIG. 106A is a simplified functional block diagram illustration of the SmartWatch sub-unit constructed and operative to certain embodiments of the present invention. FIG. 106B is a table describing operations, some or all of which may be performed by the system of FIG. 106A.
  • As shown in FIG. 106A, the SmartWatch sub-unit of FIG. 1A typically includes some or all of a SmartWatchservice unit, a data event monitor, a person identity service, a temporal monitor and an action manager. These functional units are now described in detail herein, with reference to FIGS. 106C-114, 115-123, 124-130, 131-134, 135-137 respectively. Various architectural views are provided, such as one or more, as appropriate, of the following UML-defined view: use-case view, a logical view, a process view, a deployment view, an implementation view and a data view, where:
      • 1. Use-Case Model: Describes the actors and use cases for a system which may be software-implemented
      • 2. Design Model: Describes the design elements of the system, how they cooperate to realize system use-cases; how they trace to requirements if any, user experience and key analysis elements; and how they map into implementation elements
      • 3. Implementation Models: Describe the implementation elements of the system.
      • 4. Deployment Model: Describes the deployment structure of the system.
  • The architecture of the SmartWatch service unit is typically designed to be a focal point of lifetime management/storage of all Guard instances and to concurrently process multiple Guard evaluation tasks for an assortment of member/task combinations, all as described in detail below.
  • Use-Case View: Certain SmartWatchService use cases illustrating functions of the service based upon its population processing activities, some or all of which functions may be provided in any given embodiment, are now described. These use cases, referred to herein as use cases (i)-(x), and their associated actors are shown in the SmartWatch-wide high level use case diagram of FIG. 138 and in the use-case focused diagram of the SmartWatchservice of FIG. 139. The following use-cases employ multiple applications of the SmartWatch system, which may include SmartWatch Management GUI, Person Identity Service, and other components of the total system.
    • I. Develop and Deploy Smartguard (Also Termed Herein SG) Adapters
      • New population discovery mechanisms
      • New identity change behavior
        ii. Define & Configure Guard
      • Register and validate Guard configuration
      • Check-out Guard configuration
      • Supplying metadata for SmartWatch Management GUI
        iii. Configure SmartWatch System
        iv. Manage Guard Runtime
      • A Guard administrator may be able to activate and deactivate a Guard, in addition to viewing the Guards current status (i.e. Active or Inactive). Activities included in this use-case would be: Activating and Deactivating a Guard and Viewing Guard current execution status and log.
        v. Monitor SmartWatch System Health
      • Activities included in this use-case would be maintaining and reporting Guard runtime performance count.
        vi. Apply Guard Changes
      • In this use case SmartWatch reconciles changes to existing population members, such as splits/joins as defined in conventional EMPI systems, which may affect previous decisions (activity executions). Activities included in this use case would be, given a new version of a Guard, reconciling changes to recognized members.
        vii. Discover New Population Element
      • SmartWatch looks for candidates to be added to the population and joins them into the population if they fit. Smart Guard definition determines what may be required for a patient to fit the population; the decision could be based on eligibility criteria from KFW, an external db view or some other source. The following activities are typically included in this use case:
      • a. Retrieving Candidates from the Data Event Monitor (or other population source)
      • b. Retrieving patient indexes using a conventional EMPI system and using identity monitor
      • c. Filtering for duplicate indexes on fired subscriptions
      • d. Verifying candidates are not already a part of the population
      • e. Pushing a member into a default classification
        viii. Process Known Population Element
      • SmartWatchService monitors its current population members by determining if they need to be evaluated, evaluating them, and responding to an evaluation result. Activities included in this use case may be: Retrieving applicable members from monitors (based upon triggering rules which have fired); and Filtering for duplicate members.
        ix. Process General Population Element
      • This represents a primary processing use case for this service. The SmartWatchService evaluates a patient within the context of a specific Guard. The goal includes determining classification eligibility (e.g. entry criteria). Activities included in this use case may include some or all of:
      • a. Retrieving (aggregating) rules to evaluate based upon the patient and classification(s) and evaluating them
      • b. Stepping a member into a classification and accumulating monitoring activities
      • c. Stepping a member out of a classification and removing associated monitoring activities
      • d. Updating triggering rule subscriptions
      • e. Handling monitoring activities (e.g. Action Invocation Request, Triggering Rules Subscriptions)
      • f. Remove a patient from the population
        x. Activate Task
      • This use case encompasses SmartWatchService's activation needs based upon a schedule; however according to an alternative embodiment, triggering is by the event monitor when new results are waiting. Still another alternative embodiment includes activating from an external application (GUI tool or command line). Activities included in this use case would be:
        • a. Wake-up according to flow
        • b. Find the appropriate task
        • c. Begin processing member or population discovery
  • Architectural Design Elements are now described (logical view), e.g. as shown in overview in FIG. 106C. Typically, two layers, a business logic layer and a data access layer, share a common set of entities.
  • The business logic layer (BLL) of the SmartWatchService contains a group of managers that perform at least certain functionalities of SmartWatchService. The MonitorBrokerManager orchestrates requests from the other managers within the business logic layer to the external monitors for triggering rule matching and subscribing services. The ServiceBrokerManager orchestrates requests to other external services. The CallbackManager serves as a point for external services to send information to the SmartWatchService. Services for the business logic layer may include some or all of:
      • a. GuardExecutionManager—The guard execution manager coordinates both discovery of a new member for a guard, and retrieving triggered rules for monitoring a guard's population.b. GuardManager—Manages all of the Guards and their runtime/lifecycle information. This manager can activate or de-activate a guard, or set it to another intermediate runtime status. This manager also performs lifetime management operations on an individual Guard, such as loading, activating, and deleting Guard instances.c. GuardMemberManager—The guard member manager performs operations on individual guard members. It coordinates member classification changes, in addition to registering and activating subscriptions for member monitoring through the MonitorBrokerManager.d.
  • MemberProcessingManager—The processing manager receives items which contain both a member and a list of tasks that are to be processed for them. Each task contains a list of rules which are to be evaluated. The MemberProcessingManager communicates with a Rule Evaluator to complete this, and returns a set of activities to execute for each member. An example of an activity could be to change a member's classification, or the send an action to the ActionManager. The Data Access Layer typically handles storage for various entities. Entities stored here may include some or all of:
      • a. Individual population members and virtual patient objects.
      • b. Bookmarks (operation history)
      • c. Metadata information for SmartWatchService and the Guards
      • d. Guard processing itemsExample use-case implementations or realizations for the above SmartWatch Wide Use-Cases (i)-(x) are now described: i. Develop and Deploy Smart Guard Adapters may include:
      • a. Development of new population providers for a Guard population source
      • b. Development of new Identity Change Strategy for Guard population source
      • c. Development of new types of activities
      • d. Changes in Business Object Model (i.e. modifying an existing action, creating new activities)
        ii. Define & Configure Guard: User registers a new Guard configuration. Guard configuration classes are validated for conformity to basic rules e.g. whether valid activations are present and whether a population source exists. A guard runtime structure is built from the configuration classes. A second implicit validation takes place during this phase, in which the service verifies that the configuration aliases are valid, that no cyclical sources exist and that no member classifications contain invalid tasks. A guard's detail structure is also built from this configuration. The details include the current lifecycle and runtime state, in addition to the default guard properties taken from the configuration.
        Supplying metadata for SmartWatch management GUI is a scenario which may be supported by the SmartWatchMetaData service as this service evolves to a concrete representation. The metadata service may expose metadata from the service or configuration file.iii. Configure SmartWatch System—this use case is self-explanatory.
        iv. Manage Guard runtime: Typically, the User activates a Guard, e.g. as shown herein in FIG. 107. Guard activation may comprise some or all of the following steps, suitably ordered e.g. as follows:
      • a. The Guard's details are pulled from the existing list
      • b. If the Guard has been modified, some reconciliation takes place (including verifying that the existing members, classification, configurations are still valid)
      • c. If the Guard is currently in “inactive”, or “halted” state—any current members have their triggering rules re-activated. This is done through the GuardMemberManager.
      • d. The triggering rules for the population source are re-activated. In case this is the first activation, the provider may register them first and then activate.
      • e. The Guard's runtime status is changed to active: A user de-activates a Guard. Guard de-activation may comprise some or all of the following steps, suitably ordered e.g. as follows:
      • a. The Guard's details are retrieved based upon the provided guard identifier.
      • b. The Guard's activation schedules are removed from the Temporal Monitor through a call to ServiceBrokerManager
      • c. The triggering rules for a Guard's members are deactivated
      • d. The triggering rules for each of the Guard's population providers are deactivated
      • e. The Guard's runtime state is changed to inactive
      • The system may View Guard execution status and log.
        v. Monitor SmartWatch system health e.g. Maintain and report Guard runtime performance count—this use case is self-explanatory.
        vi. Apply Guard Changes—this use case is self-explanatory. Guard (or SmartGuard) is a term used herein to identify the instance. SmartWatch handles many instances of evaluations. Each such instance typically includes various evaluations such as, for example, population definition, monitoring definition, actions definition.
        vii. Discover New Population Element, e.g. as shown herein in FIG. 108. Discovery of a new population element may comprise some or all of the following steps, suitably ordered e.g. as follows:
      • a. Discover new population element is called directly by the user or by a callback from activation.
      • b. For each population source configured under the Guard, the service retrieves the new patients.
      • c. The new patients are added to an exclusion list for each population source
      • d. For each potential new member the cluster is retrieved from the Person Identity Service
      • e. Duplicate patient clusters are joined (filtered)
      • f. Patients existing within the Guard's population source are filtered
      • g. The patient is added to the Guard's collection of members
      • h. The new member is given the initial classification targeted by the population source
      • i. The new member is pushed into the processing queue with the list of applicable tasks from the classification just set.
        viii. Process Known Population Element, e.g. as shown herein in FIGS. 109 and 110.
  • Processing of a known population element may comprise some or all of the following steps, suitably ordered e.g. as follows:
      • a. Process is triggered by user or activation (timer or monitor)
      • b. Check for temporal triggering rules which fired for subscribed events
      • c. Check for data event triggering rules which fired for subscribed events
      • d. Check for identity triggering rules that fired.
      • e. For each result—check for identity changes and handle as appropriate. Unclassify the current member and add to initial classification (re-evaluation of all classifications). If appropriate—add new members for split cluster fragments.
      • f. Check for data changes (updates/deletes) which might change past recommendations
      • g. The member is pushed into the processing queue with the list of applicable tasks
        ix. Process General Population Element, e.g. as shown herein in FIGS. 111-112.
  • Processing of a general population element may comprise some or all of the following steps, suitably ordered e.g. as follows:
      • a. Get applicable tasks based upon Guard and member classification
      • b. Execute Task Rule (Knowledge Module or hard-coded rule) e.g.:
        • b-1. Invoke KNEO to evaluation knowledge module
        • b-2. KNEO invokes the KFW to evaluation the knowledge module
        • b-3. Store the patient VPO returned.
      • KNEO (KNowledge Evaluation Orchestration) is a functionality within SmartWatch which simplifies SMW communication with KFW since in order to execute KM in KFW, SmartWatch typically collects patient data, which may optionally, as a design choice, be effected by a separate service, namely KNEO.c. Receive evaluation result and handle activities, activity could be of any of the following types:
        • c-1: Registering a specialized triggering rule
        • c-2: Invoke an action
        • c-3: Step in or out of a classification (see Re-classification Activity)
      • d. Log all activities
        Re-Classification Activity may include any or all of the following:
      • a. Add or remove a member to the classification based upon the evaluation result.
      • b. Analyze member's current classification status. If the member is not a part of any existing classification, Unsubscribe from Person Identity Service and Unsubscribe from applicable Monitors. If the member is a part of an existing classification, check whether the classifications have changed.
      • c. Collect applicable classification triggering rules including Update triggering rule subscriptions
      • d. Update patient process history and Guard run history
        x. Activate Task: Cause a specific task to be activated by schedule or by callback e.g. as shown herein in FIGS. 113 and 114.
  • The data event monitor is now described with reference to FIGS. 115-123. An architectural overview of certain embodiments of the data event monitor, using different architectural views to depict different aspects of the system, is now provided. The data event monitor (DEM) and Temporal Monitors typically provide a way to trigger patient evaluations in SMW. Any suitable implementation of such triggers may be employed, which may differ from those specifically described herein e.g. due to specifics of the interlaying system such as how the CDR is built and what other capabilities are. For example, triggering may occur when the incoming message is being processed rather than as described herein.
  • The following use cases may be provided:
      • i. Manage triggering rules subscriptions (add/remove subsections to pattern rules): Accept subscription changes from consumers, and reflect them in the subscription database. This may include new subscriptions, along with the patient indices (for either inclusion or exclusion). This also handles updates such as removing triggering rules from patients and changes to the triggering rules for patients. The subscription information typically includes enough information to allow the consumer to pull results later on with a different level of granularity (SmartGuard, classification, Task, member). This information is typically reflected in the results as well.
      • ii. Maintain Subscription's patients and indices: When there are EMPI (Enterprise Master Patient Index) changes of a known member, “fix” all of the subscriptions to ensure that the correct patients continue to be monitored. In terms of population management, when a member is added to or removed from the Smart Guard, this use case changes the patient list while retaining the actual subscription. Use cases iii and iv are both “Collect events” use cases which map CDR data to an event object model e.g. that of FIG. 140 which is a diagram of an example of one suitable event object model. Typically, a suitable event object model is generated for each medical domain. Each domain typically comprises a realm of medicine such as Encounters, Labs, Medications, Documents, Imaging, Immunization, Allergies, and Pathology. Encounters typically include any type of physician visit, either to a PCP (Primary Care Physician) or as admission into hospital.
      • iii. Collect new events: This use case gets “latest” events from a data source such as the CDR for processing, either in push or pull mode. A typical event would arrive from the CDR, but there is the option to receive events from other sources.
      • iv. Collect old events (also termed herein “bootstrap scenario”): Get events from the data provider from any timeframe for processing (“Bootstrap” scenario). These events are to be tagged in order to be matched only against the set of subscriber/pattern rules that “missed” them (either a new Smart Guard or a freshly reactivated one as described herein with reference to the Control rule execution use case. This operation is performed at the subscriber level, for all of the subscriber's subscriptions.
        Use cases v-vii are all “Deliver results” use cases.
        v. Deliver results per consumer request (consumer pulls results): When a consumer requests results from the data event monitor, a use case may provide such results. It is the consumer's responsibility to ask for the start and end points of the results.
        vi. Notify Consumer of new results: “Pings” the consumer when there are results waiting for it. This may be configured to only ping any given consumer at a certain interval (no more than once every 30 minutes, for example).
        vii. Process Events: As shown in FIG. 115, this use case covers the “event processing chain” in the data event monitor. When data events enter this chain, this use case may harmonize the data (terminology & unit of measure), determine what subscriptions are fired by the data, and store the results of the matching operation.
        viii. Maintain pattern rules: General maintenance of the pattern rules that the data event monitor can support. These may include creating new stored procedures for matching, defining pattern rule parameters, and mapping the two together. Three components are ultimately used by the Data Event Manager, also termed herein “data event monitor”, when matching events to subscriptions: Rules Processors, Event Working Tables, and Subscription Tables. The Rules Processors make the various Event Working Tables/Subscription Tables pairings meaningful.
        ix. Control rule execution (stop/start at the subscriber level)
      • In this use case, the Data Event Monitor allows to stop or start the rule execution. When starting over, there is a need to collect all events that were missed during the time in which the rules were deactivated (similar to the bootstrap scenario).
  • Example implementations or realizations of the above data event monitor use-cases (i)-(ix), other than where self-explanatory, are now described.
  • i. Manage triggering rules subscriptions (add/remove subsections to pattern rules)
  • When monitoring data for new subscriptions, historical events may or may not be looked at, going as far back as is predetermined to be appropriate, according to the application. Subscriber accesses the subscription service. Subscriber may provide:
  • a. Pattern rule
  • b. Patient Indices, including the instructions for inclusion (population monitoring) or exclusion (population discovery).
  • c. Subscription Information (parameters for the pattern rules).
  • d. Ping Interval—What is the minimum time allowed between pings from the event monitor when triggering rules fire. This may be the anti-flood mechanism.
  • Processing may include the following operations:
      • a. Look up pattern rule.
        • FIG. 142 is an example of a pattern rule comprising a subscription snippet, in XML format. FIG. 143 is an example of a pattern rule comprising a definition snippet, in XML format. It is appreciated that the above are merely examples of pattern rules which allow other suitable application-specific pattern rules to be developed analogously, and are not intended to be limiting, but are rather merely illustrative.
      • b. Validate subscription against pattern rules.
      • c. Detect triggering rule changes to existing patient—subscriber associations
      • d. Delete irrelevant triggering rules.
      • e. Persist the actual triggering rules: Include information that may allow subscriber to later pull results with desired levels of granularity, such as SmartGuard, classification, task, member. The event monitor may mirror this type of information in the results.
      • f. Attach patient ids to the triggering rules for inclusion or exclusion.
      • g. Begin monitoring data for these rules.
  • Updates may be performed, e.g. as illustrated herein the diagrams of FIGS. 116-117A.
  • Deprecate triggering rules from patients (cease using these, without actually deleting them), e.g.:
  • a. Receive subscriber id, member id, triggering rule, task, classification code, pattern rule parameters.
  • b. Get subscription handler for that rule.
  • c. Deprecate the rules in the database.
  • ii. Maintain Subscription's patients and indices e.g. as illustrated in the diagram of FIG. 117B. Typically, the following occurs:
  • a. Consumer notifies Subscription Service that there are EMPI (Enterprise Master Patient Index) changes for a member. Update the patient indices in the patient subscription tables.
  • b. Consumer notifies Subscription Service that a member may be added-to, or removed-from a subscription. Add/Remove the member association to the subscription.
  • Historical events may or may not be looked at for these scenarios, going as far back as is predetermined depending on the application. Reference is made in this connection to FIGS. 117A-117B which are diagrams illustrating a basic flow of UpdateSubscription and UpdateSubscriptionIdentities functionalities respectively.
  • iii. Collect new events e.g. as per the diagrams of FIGS. 118A-118B. Event collection service manages all of the events that it gets from the providers. Providers work uncoupled from the Event Collection Service by knowing how to collect data from whatever source they are in charge of Modes may include a Push mode which is operative to receive data from source in real-time (ala CEBEventListener); and a Pull mode which is operative to retrieve proactively from source (ala CDR).
  • At a desired frequency such as once per half hour, new events are collected from the source using a suitable conventional event collecting functionality such as the TableLookupEventProvider or OnlineCommandEventLoader Functionalities mentioned in FIG. 118A. Record retrieval may be based on a sort of handle, which can be: timestamps, record number, or other identifier of the information source. Activation is time-based. OnlineCommandEventLoader adheres to the Online Source's policies. For example, proof may be demanded that the patient is actually being treated by a user of SmartWatch. The Event Provider maps the new event data into the object model, and passes the object(s) to the Event Collection Service. Events are stored in an event table, based on a suitable event object model such as the example illustrated in FIG. 140. Events receive a batch number from the batch manager. The Process Events use case is initiated. FIG. 118A is a diagram of a basic flow of a new event collection functionality. FIG. 118B is a diagram of a basic flow of a by-criteria event collection functionality.
  • iv. Collect old events (also termed herein “bootstrap scenario”), e.g. as per the diagram of FIG. 119 which illustrates a basic flow for an old event collection process. Typically, consumer instructs Data Event Monitor to collect and process all data events based on a timeframe (issues a “Bootstrap” command). Note that the subscription may already exist separately before a Bootstrap is requested. All subscriptions for a subscriber are bootstrapped. Query the Data Provider for the events, typically by performing some or all of the following steps, suitably ordered e.g. as shown:
  • a. Use the DataEventCriteria object to define the event set.
  • b. Insert these into a suitably constructed event working table(s) tagged so as to indicate that the operation is for BootstrapSubscription ID X. Subscription ID links back to the Subscriber.
  • c. Get Batch ID from batch manager.
  • d. Harmonization and Matching proceed as normal, and when the “bootstrap” exclusion phase later runs within the matching processor, it may strip out any results for events that were triggered by any other subscription ID.
  • v. Deliver results per consumer request (consumer pulls results), e.g. as shown herein in the diagram of FIG. 120. Results, when delivered, may be sent at the subscriber level, or at a more finer-grained level, such as results for a specific task for a subscriber. Consumer requests Data Event Monitor Service for results; the operation may include the following steps:
  • a. Consumer provides “bookmark.”
  • b. In the SmartWatch system, the bookmark is the batch number of the last batch that was closed during the last results retrieval. When the Data Event Monitor is called for more results with this batch number, it increments the number, and provides results from batch+1 onward, to the new most-recently-closed batch.
  • c. Query Results table for tasks that fit the consumer's timeframe.
  • d. Only results in “Closed” batches are eligible.
  • e. Provide the requested results.
  • vi. Notify Consumer of new results, typically including:
  • a. Continuously monitor the results database for undelivered, closed events.
  • Ping subscriber if the minimum interval has passed since the last ping.
  • b. When the batch manager closes a batch, raise event that Batch X is closed.
  • c. Event Handler looks at every result, and identifies the subscription id's for subscriptions and the ping time, if any. Attempt to add subscriber to “ping list” along with when the ping may happen. Set a timer at the subscriber level so that the ping will sound when it is supposed to. If the subscriber is already on the “ping list”, then if the pinging interval for this subscription is supposed to happen sooner than the “time left” on the ping list for that subscriber, overwrite the entry on the ping list. Otherwise, do nothing.
  • d. When a timer pops up from the pinging list, ping the subscriber.
  • vii. Process Events e.g. as shown herein in FIG. 121.
  • This Use Case is realized by the processor chain. As new data events enter the queue, a Harmonizer picks them up and harmonizes events, including some or all of:
  • a. Terminology Mapping
  • b. Unit of Measure (convert to baseline)
  • c. Split pertinent events into multiple events as appropriate.
  • d. Notify batch manager
  • e. Drop events from processing chain as appropriate.
  • f. Notify batch manager
  • g. Mark event as “harmonized” in the working event table(s).
  • A Matcher then performs some or all of the following operations:
  • a. Monitors its “working tables”, namely various tables where events are stored to be later “matched” against subscriptions in subscription tables.
  • b. Waits until any table fills up with X records (configurable), or until Y seconds (configurable) pass, whichever comes first.
  • c. Runs all pattern rule processors against the events in a table, and the subscriptions that work with those events. An example of a pattern rule processor might be a stored procedure in the working table.
  • d. Rule Processors are “keyed” in such a way as to say what working tables they support, and what subscription tables they support.
  • e. For discovery triggering rules, the matcher may compare the results against the members that the subscribers already have in the populations, and may remove these results from the final result set.
  • f. Another removal step is the “bootstrap removal phase,” where the matching processor removes results that were generated by subscriptions other than the subscription for which the event is keyed.
  • g. Another removal step is performed for deactivated subscriptions. This is typically performed as a separate step because patient monitoring rules abstract the individual patient when doing the matching, and only join them after the rule fires.
  • h. Results are delivered to the results table.
  • FIG. 121 is a diagram showing a basic flow for an event provision process operative in accordance with one embodiment of the present invention.
  • viii. Maintain pattern rules e.g. as shown herein in the diagram of FIG. 122.
  • a. A New Pattern Rule is designed, typically by a human operator and translated into a Rules Processor (for example, a stored procedure).
  • b. Determine what Event Working tables and Subscription tables the new pattern rule “works” with.
  • c. Create new Event Working tables and Subscription tables if appropriate.
  • d. Define the compatible data types for the operands in the triggering rules within any Rules Processor.
  • e. Map the results of this process to some tables used to expose the pattern rules and parameters they accept. Also map a handler for the subscription service to push subscriptions into the working tables, all e.g. as shown in the diagram of FIG. 122.
  • ix. Control rule execution (stop/start at the subscriber level)
  • a. Subscriber orders a “stop” for its subscriptions. This may affect all subscriptions that the subscriber has. Persist the “IsActive” field for each subscription object to false.
  • b. Consumer orders a “start” for a subscription. Persist the “IsActive” field for each subscription object to true. Operation may be similar to the bootstrap scenario described above.
  • FIGS. 123A and 123B are subscription activation and de-activation basic flows, useful for implementing control rule execution use case (ix) according to certain embodiments of the present invention.
  • The SmartWatch Person Identity Service of FIG. 1A is now described, according to certain embodiments of the present invention, with reference to FIGS. 14-17. As described herein, SmartWatch is operative to achieve automated decision support focused around population with common characteristics. SmartWatch relies on the functionality of gathering clinical data from diverse systems. SmartWatch is designed to operate under a significant design constraint—the reality in which a patient does not have a unique identifier across the enterprise. To meet this constraint SmartWatch communicates with conventional EMPI (Enterprise Master Patient Index) systems that know how to cluster patient identifiers (indexes) based mostly on probabilistic algorithms. The SmartWatch Person Identity Service serves as an arbitrator between SmartWatch and conventional EMPI systems.
  • The Person Identity Service is typically different to VIA, which is a commercial Virtual Identity Aggregation service provided by DBMotion, Israel. While VIA is an abstraction layer from concrete EMPI vendor implementation allowing dbMotion components to make an EMPI call using a unified API, Person Identity Service (PERIS), on the other hand, implements at least one additional functionality that is not part of the services proposed by EMPI vendors, namely a subscription capability to effect changes in person identity.
  • The Person Identity Service is typically operative to:
  • a. receive EMPI (Enterprise Master Patient Index) clustering information about specific sets of people (patients) e.g. up to date cluster state information (on demand) and clustering changes information (publish subscriber pattern).
  • b. Mediate the above capabilities of an EMPI provider such as Initiate.
  • c. Minimize calls to EMPI provider. Since a central consumer of the service is SmartWatch—an automated system—the load may be significantly more difficult than human users making requests.
  • EMPI (Enterprise Master Patient Index) clustering changes over time is a constraint stemming from the nature of the distributed healthcare environment without a unique patient identifier. Since EMPI cluster changes, the service is operative to help its consumer(s) such as SmartWatch manage the information it keeps for the long run on patients, in various points in time, as such changes may change decisions being made. A Use-Case View of the Person Identity Service is shown in FIG. 124. Some or all of the following use cases may be provided:
  • i. Retrieve Person Identity (Cluster): When the system is requested by its consumer to retrieve a person current cluster—the set of indexes that are currently clustered together according to the EMPI (Enterprise Master Patient Index) provider. The entry point is an index, related to as the principal index, and the outcome is the set of indexes currently associated with it by the EMPI provider. Unlike search operations in VIA (a commercial Virtual Identity Aggregation service provided by DBMotion, Israel)—there is no human user making decisions—the EMPI provider is the sole authority according to which later decisions are made.
  • ii. Manage identity change rules subscriptions (ARM): Accept subscription changes from consumers, and reflect them in the subscription database. This may include new subscriptions and modifications to existing subscriptions. The subscriptions are meant to allow service consumers to be aware of changes to identity changes of persons (patients) that the consumer is interested in. For example, the consumer (SmartWatch Service) would like to be notified whenever EMPI (Enterprise Master Patient Index) system has made any change to a given patient of his (a member) such as join or split. The subscription includes a person index that identifies the person for the consumer and is also termed herein the “principal index”.
  • Use cases iii and iv are Deliver results use cases (ARM).
  • iii. Deliver results per consumer request (consumer pulls results): When a consumer requests for results from the service, this use case may provide those results. It is typically the consumer's responsibility to ask for the start and end points of the results.
  • iv. Notify Consumer of new results: “Pings” the consumer when there are results waiting. This may be configured to only ping any given consumer at a certain interval (no more than once every 30 minutes, for example).
  • v. Maintain Patient Identities: synchronizes system's knowledge of person cluster state with the EMPI (Enterprise Master Patient Index) provider. Several workflows may be employed here, depending on the capabilities of the EMPI provider, on performance requirements and allowed latency. Workflows may include: receiving regular updates on all person identity changes from EMPI provider (push updates); receive a snapshot of the cluster database from EMPI provider (push snapshot); proactively request cluster state for selected person(s)—whose state was not checked for a relatively long period of time (pull proactively); or some hybrid of the above.
  • The diagram of FIG. 125 illustrates the significant design packages and subsystems of the service. The design packages of FIG. 125 typically include:
  • a. Business Logic Layer: implements the business logic and provides the services described above.
    b. ClusterResolvingService: allows consumers to retrieve a person cluster which comprises a set of indexes that currently represent the same person according to an EMPI (Enterprise Master Patient Index) provider. This call may yield a call to EMPI provider (EMPI-Get), but may also be resolved within the service itself, in case the cluster is already known and reasonably up-to-date. Consumers may specify a time interval, which defines what ‘reasonably up-to-date’ means from their perspective.
    c. ClusterResolvingService: a service which allows EMPI (Enterprise Master Patient Index) providers, or some mediator process on their behalf, to communicate clustering changes to the system.
    d. SubscriptionService: implements publish subscriber pattern, allowing consumers to subscribe to identity change rules for selected people that they are interested in. The subscription includes a principal person index as the identifier of the person of interest.
    e. Data Layer: A layer which handles the storage of the various entities in order for the system to function. Entities to be stored may include Subscriptions & subscribers (people of interest to subscribers); Indexes and their current clusters; and Results (i.e. indexes which changed and the subscriber relations.)
    f. EMPI (Enterprise Master Patient Index) Adaptors: A package (typically a shared dll), overviewed in FIG. 126, which contains interface as well as an out-of-the-box adapter operative to retrieve a cluster from the EMPI provider. The EMPI adaptors package abstracts away from the system the exact details of how a “get” operation that retrieves a cluster, given that an index is performed in the specific project. The implementing classes may be customized at the project level to accommodate the different EMPI configurations at different customer sites.
  • Example implementations or realizations of the above use-cases are now described, except where self-explanatory.
  • i. Retrieve Person Identity (Cluster): a call is made to ClusterResolvingService. Within such a call the service may first check whether the cluster can be found at the DAL, and whether it is “fresh” enough for consumer requirements if any. If not, the cluster is retrieved from EMPI (Enterprise Master Patient Index) provider, stored and returned to consumer. In parallel, this starts an analysis process of cluster changes by the changes manager, one embodiment of which is illustrated in FIGS. 127A-127B.
  • An alternative flow, as shown in FIGS. 128A-128B, is returning the cluster together with changes being made that the consumer (also a subscriber) may be aware of. In this case the consumer supplies also subscriber id and a handle (timestamp or record number) to retrieve results by, the handle typically representing the latest knowledge of consumer for the given person.
  • ii. Manage identity change rules subscriptions (ARM): An UpdateSubscriptions call is made to Person Identity Service's Subscription service. The service “persists” the subscriber, with its person interest in its subscription storage; typically this involves the service saving the subscription, comprising a subscriber or patient to be monitored, in storage.
  • v. Maintain Patient Identities: An example proactive flow is illustrated in FIG. 29. The proactive flow of FIG. 29 is significant when the EMPI (Enterprise Master Patient Index) vendor is unable to push updates to the system. It is realized by a call from a scheduling system to the ClusterUpdatesService typically under a suitable specialized interface termed herein ProactiveClusterUpdatesService.
  • The passive flows (pushes from EMPI (Enterprise Master Patient Index) provider or a mediator on their behalf) are realized by calls to the ClusterUpdatesService, as illustrated in FIGS. 130A-130B. The proactive flow (main flow) is realized by an internal process which looks for persons whose identity is outdated and queries them with EMPI vendor to update the system knowledge of the cluster state.
  • According to one centralized embodiment of the present invention, PersonIdentityService is deployed in one node and SmartWatchService(s) calls it remotely. According to another distributed embodiment of the present invention, wherever an individual SmartWatchService is deployed, PatientIdentityService is deployed as well, serving only that individual “local” SmartWatch system. The two embodiments may be suitably combined. The SmartWatch Temporal Monitor is now described, with reference to FIGS. 131-134. Typically, the monitor creates a component to facilitate SmartWatch execution of event driven tasks. The monitor typically provides mechanisms for subscribing, publishing, and delivering the results using a pull and push model, all without losing results and without pushing results to wrong consumers.
  • A Use-Case View of the SmartWatch temporal monitor is provided in FIG. 131A. An overview thereof is provided in FIG. 131B. Use cases of the temporal monitor may include some or all of the following:
  • i. Manage triggering rules subscriptions: The use case starts as a result of the “Process Population Element” use case, usually when the monitoring criteria is fired for a population member. According to SmartGuard definitions and business logic, SmartGuard Service requests the Temporal Monitor system to subscribe for one or more triggering rules.
  • ii. Schedule Tasks: The use case starts with the “Manage Guard runtime” use case, when a guard is activated. At that time, typically, the system ensures guard tasks are being run according to schedule defined within the guard. The system would subscribe these requests similar to i. Manage triggering rules subscriptions use case.
  • iii. Calculate Rules: This use case is triggered by a timer when the time calculated based on a subscription triggering rule elapses. The elapse time event triggers a workflow typically including some or all of the following steps:
      • a. Populates the results repository with new data
      • b. Using the subscription's triggering rule calculates the event's next occurrence
      • c. Updates the prospective tasks repository with the new calculated event occurrence
      • d. If the subscription delivery preference is to use a push method the results are pushed to the URI specified by the consumer
      • e. If the rule's calculated number of occurrences or the subscription's end date are reached, the subscription is removed
  • iv. Deliver results per consumer request: This use case starts as a result of receiving a consumer request for getting results delivered after the execution of prospective tasks scheduled based on the submitted by the consumer triggering rules. The system searches the results repository using the criteria specified by the consumer. The use case ends as the system delivers the results.
  • v. Notify consumers of new results: The use case starts when the calculated subscription triggering rule fires and the subscription delivery preference is to use a push method. The results are pushed to the URI specified by the consumer. The use case ends as the system delivers the results.
  • FIG. 131B is a logical view of the temporal monitor according to certain embodiments of the present invention. As shown, the temporal monitor typically comprises a service layer which exposes services and/or packages to its consumer e.g. SmartWatch, such as one or more of the following services and packages:
  • a. SubscriptionService: service which provides functionality for managing the subscriptions and delivering the results to SmartWatch as a consumer.
    b. SchedulingService: façade that allows consumers (SmartWatch service) to store and remove subscriptions. Receives a scheduling request, validates it, and stores it into the subscription repository.
    c. PatternRuleManagementService: A service providing functionality for managing the Temporal Monitor triggering rules used by the system to create the subscription's prospective tasks executed by business layer at runtime.
    A Business Layer encapsulates the Temporal Monitor business logic exposed as subsystems. The subsystems include internal service providing functionality for managing subscriptions, monitoring execution of prospective tasks based on the subscription's triggering rules, and delivering the results to the consumer. Functionalities which may be provided may include one, some or all of the following:
    a. SubscriptionManager: responsible for managing the subscription's lifecycle. Also the subsystem notifies the Runtime Manager subsystem of new subscriptions that need an initial prospective task to be stored in the prospective tasks repository and are ready for execution.
    b. ResultManager (not shown): delivers results per user request or pushes the results to a consumer defined location (URI).
    c. RuntimeManager: Subscribes for notification events coming from the Subscription Manager subsystem or a prospective task elapsed time event. A business logic is applied to each event and a set of actions is executed. The next RR occurrence is computed and results are pushed to consumers.
  • A Data Access Layer (DAL) manages database access for the business layer.
  • Example Implementations or realizations for the temporal monitor's use cases are now described, except where self-explanatory:
  • i. Develop SmartWatch Triggering Rules Subscription Workflow: This may be a non-automated process effort e.g. as shown.
    ii. FIG. 132 is a diagram showing the basic flow of the Update Subscription functionality also termed herein the “schedule tasks” functionality. The workflow is operative to manage triggering rules subscriptions. The system receives a set of triggering rules subscriptions including the results delivery preferences (pull or push method). The subscriptions are validated based on predefined business logic and stored in the subscriptions database. The use case ends after the subscriptions are saved and a new Subscription Event is fired for all new subscriptions entering the system. The event triggers the execution of a workflow that calculates the triggering rules e.g. as described herein with reference to the iii. Calculate Rules use case iii of the temporal monitor. This results in creation of a new record in the prospective tasks repository and if the time of the new prospective task is closer than the “closest event” time held so far, the time is reset to the new prospective task's time.
  • This core use case typically employs the service, business, and data access layers. The steps involved in this use case are outlined in the sequence diagram of FIG. 132. After receiving a subscription request, the Subscription Service calls the subscription manager which performs subscription rule mapping, after successful subscription arguments validation the Subscription Manager constructs a subscription object which is passed to the Temporal Monitor data access layer. In case of a validation error, an exception is thrown describing the type of error.
  • iii. Calculate Rules: This use case is triggered by a timer when the time calculated based on a subscription triggering rule elapses or when a triggered subscription change event is fired by the Subscription Manager. Steps which may be included in this use case are illustrated in the sequence diagrams of FIGS. 133-134 and may include some or all of the following steps:
  • a. The Runtime Manager gets the prospective task associated with the triggering rule.
  • b. Based on the subscriber's delivery preferences, the system stores the results into the Results database ready to be retrieved by the subscriber, or pushes the results to the subscriber ResultAwaitCallback service.
  • c. The Calculate Rule workflow calculates the next occurrence and saves it in the Prospective Tasks database.
  • d. After rule computation, in case of no future occurrence, the task is removed.
  • e. Runtime Manager retrieves the earliest task from a prospective tasks database and sets the next time on the timer.
  • iv. Deliver results per consumer request: In this use case the service would retrieve results from its result data base, based on the parameters supplied to it in the request (ARM compliant). The bookmark in this case is a timestamp.
    v. Notify consumers of new results: This use case is based on a callback to the subscriber, to a URI specified at subscription time. Based on subscription time preference, the results may be stored in the DB for the subscriber to pull them (ping mode) or just sent directly (push). The push mode is expected only for scheduling service subscription (in which the subscriber wants a “wake up call” but would not need to pull any information past that).
    vi. Maintain pattern rules: This may be a manual process, performed by a developer who defines new triggering rule parameters, writes a handler that would know how to construct the proper subscription object from the input parameters, and registers the new rule.
  • Referring now to FIGS. 135-137 inter alia, the Action Manager carries out SmartWatch recommendations to the outside world by notifying human users or other systems about SmartWatch findings. The Action Manager provides flexibility to PS developers in creating mechanisms to fit the specific client's policies and needs, including message structure, format and look & feel, channels, schedule, workflows. This lowers the cost of project implementation by promoting quick development cycle of (sometime complex) actions to meet a specific client's need (project versus product). Typically, integration with the customer's current clinical workflow is seamless and the end consumer typically receives the messages within his day-to-day operational systems. Implemented actions follow up on sent notifications to “close the loop” and ensure notifications are being appropriately used, including a notification consumers' feedback mechanism that would allow continuous system improvement and system tune up. Typically, messages and notifications are not lost, notifications cannot be sent to wrong recipients, and message replays are allowed in the event of system error.
      • Action manager use cases may include some or all of the following:
      • i. Develop SmartWatch Action Workflow: developer develops a new action workflow to support client needs. ii. Execute action: starts as a result of the “Process Population Element” use case described herein, usually when the monitoring criteria is fired for a population member. According to SmartGuard definitions and business logic, SmartGuard Service requests the Action Manager system to execute one or more Action Workflows. The Action Workflow collects appropriate information, creates a notification message, decides on the Delivery Channel, formats the message to fit the Delivery Channel, and sends the message through the channel. The end result includes sending a notification message to an Action Recipient, which can be either a Care Provider or an Action Receiving/Responding System. This Use Case describes the available activities that can be used to create an Action Workflow. For example, Action Workflows can be developed in order to send e-mail or SMS, to add a record to a database/CDR, to invoke a workflow in an EMR/CPOE system, to send a report through fax and to activate another Action Workflow. The Action Workflow includes the logic to determine what data to be included in the notification, appropriate formatting, delivery channel, metadata properties. The Action Workflow can also include custom logic to interact with other systems and resources, e.g. dbMotion Security, Subscription System, and any other system that Action Manager supports. The use case ends when the requested Action Workflow is executed.
      • iii. Get Action Workflow Metadata. This use case typically defines data elements used for Action Workflow, defines Security settings, and/or uses delivery channels.
      • iv. Recall action: deals with situations in which actions SmartWatch invoked in the past are overridden and the new decision may be communicated to consumers who already received messages during original action invocation, for example, data changes in the CDR such as final lab results, or deleted records as a result of a DIL receiving update message.
      • v. Report Action statistics
      • vi. Replay notifications
      • vii. Send notification (breakdown from an executed action).
  • FIG. 135 is a logical overview of the Action Manager according to certain embodiments of the present invention. As shown, the action manager may comprise:
  • a. BusinessLogic Layer: exposes services to its consumer—SmartWatch. Typically includes:
  • a-1: ActionMetadataService: Provides consumer with metadata about the action manager. Used mostly by design time components such as SmartWatch management tool during SmartGuard editing.
  • a-2: ActionInvocationService: A façade that allows consumers (SmartWatch service) to invoke actions supported by Action Manager, including receiving an invocation request, validating it and submitting the action for execution.
  • a-3: ActionDirectory: An internal service which holds mapping between action definitions and concrete action implementations (usually a workflow but maybe a simple class). Used by ActionMetadataService in order to list actions and describe them. Used by ActionInvocationService in order to map action request parameters implementing workflow and validation rules.
  • a-4: ActionRuntimeManager: An internal service which manages the running action workflow's lifetime. Starts off with action being submitted by ActionInvocationService and is operative to monitor, report, manage (e.g. lookup hanged workflows and stop them). Also includes set of tools & services to facilitate rapid development of workflows, to meet developer productivity goals.
  • a-5: Workflows & Formatters: A package of customization in which concrete workflows and formatters (for content formatting) reside.
  • b. Communication Layers: responsible for handling any communication the workflow employs. It may include some or all of the following types of communications:
  • Input—which provide data to be included in notifications and to be used in workflow decision making; Output—delivering notification to recipients in the outside world (humans or systems); and Response—receiving messages from recipients (humans or systems) that include either acknowledgments or answers (from recipients) to specific questions included in notification.
  • The communication layer typically includes:
  • b-1: dbMotionServices & AdditionalServices are packages which supply workflow developer with a set of input communication to services it consumes. The package contains service client proxies. dbMotionServices are product-based (supplying access to services such as security, KNEO, dbMotion Business layer, PCP and so on), and AdditionalServices supplies customer-specific information sources.
  • b-2: NotificationDeliveryService: delivers messages through delivery channels. It starts off with a notification request from a workflow, maps it to one of its delivery channels and assures reliable delivery, properly logged and so on. A commercially available product, such as a communication enabled business process (CEBP), may be used.
  • b-3: ActionResponseService: allows recipients to influence the workflow by responding to it. Responses may trigger events in the corresponding workflow. Based on pluggable listeners that know to communicate responses back to the workflow. This subsystem typically includes a Response Listeners package in which customized listeners reside.
  • A Data Access Layer (DAL) manages database access for business and communication layers.
  • Example implementations or realizations of the above-described use cases for the action manager are now described:
  • i. Develop SmartWatch Action Workflow: Typically non-automated. The workflow may be in accordance with the diagram of FIG. 136.
  • ii. Execute action: This use case employs several services from the business and communication layers and also typically employs the DAL in recording any operation being executed and artifact being produced (notifications, recipients, . . . ).
  • The following functionalities, action validation and notification delivery, typically form part of the execute action process above and typically comprise implementations of the execute action use case:
  • Validate Action: The diagram of FIG. 137A illustrates how actions are invoked by SmartWatchService, how the action request is validated and how the action request is submitted by the ActionInvocationService to ActionRuntimeManager. Next, ActionRuntimeManager initializes and starts the workflow e.g. as shown in the diagram of FIG. 137B which, for simplicity, does not include details of the workflow being run. A typical action workflow may include decisions about who and what to communicate, including getting data to support decisions and to be included in the message, preparing message content (formatting), deciding on recipients, sending notification(s), waiting for responses and reacting to them.
  • Deliver Notification: FIG. 137C is a diagram of a notification delivery process. The workflow has collected data, decided on proper notification mechanism and prepared a notification message (content formatted). It calls NotificationDeliveryService to manage the delivery of the notification to its recipient(s).
  • iii. Get Action Workflow Metadata: This use case is realized by a call from SmartWatch Management tool to ActionMetadataService. Management tool which is a GUI component in which SmartGuard is edited. The metadata service would call ActionDirectory to locate the metadata such as list of actions, parameters, workflow associated with an action and so on.
  • iv. Get Action Response: This use case starts when one of the Action Response Listeners receives an Action Response Message. The message is forwarded to ActionResponseService for processing the response. This in turn would trigger the action workflow (assuming the workflow is waiting for that response) or the ActionResponseService would trigger a new workflow to process the Action Response e.g. as shown in FIG. 137E.
  • FIG. 141 is a table of ontological relationships, defined in conventional, public SNOMED terminology. The set of relationships in FIG. 141 is an example of semantic relationships, some or all of which may be used by the CTS subsystem of FIG. 1A. It is appreciated that this example is provided merely for purposes of clarification by way of example and, like many other examples provided herewithin, is not intended to be limiting.
  • The system shown and described herein typically but not necessarily uses conventional cache implementations such as Cache Application Block from Microsoft Enterprise library to provide client side caching functionalities in the CTS client subunit, which may be used by various of the SMW subsystems described herein.
  • An example HF (heart failure) patients classification is described below with reference to FIGS. 144A-144C, including triggering rules and other characteristics for entry and exit tasks.
  • Example admitted HF patient sub-classifications are described below with reference to FIGS. 145A-145D, including triggering rules and other characteristics for entry and exit tasks. An example of an LVS function evaluation method, including triggering rules and other characteristics for a monitoring task, is described below with reference to FIGS. 146A-146C. An example ACEI or ARB for LVSD is described below with reference to FIGS. 147-150. An example sub-classification for temporarily discharged HF patients is described below with reference to FIGS. 151-152B, including triggering rules and other characteristics for entry and exit tasks. Example vocabulary codes are described herein with reference to the table of FIG. 153.
    An example HF PATIENTS CLASSIFICATION is now described with reference to FIGS. 144A-144C, including triggering rules and other characteristics for entry and exit tasks.
    An example Entry Task is now described.
    Triggering Rules may include one or both of:
    Identify new HF problems—an example list of codes is provided below under CTS triggering rules; and
    • Is HF Patient KM
  • Inputs/Query Parameters are described in the table of FIG. 144A.
    Example Decision logic is now described in words and in pseudo-code.
  • In words
    When
    Patient is alive
    AND
    Patient has a HF Condition
    AND
    The latest HF Condition is not negated
    Then Return isHFPatient = True
    Else Return isHFPatient = False

    In pseudo code
  • When
    PatientAdministration/DeceasedInd <> 1 //defined as bit data type in
    the CDR
    AND
    HF Conditions DRI is not empty
    Conditions/Condition/value/(code,codeSystem) Member In CTS list
    e.g. as described below (CTS list for KFW).
    AND
    Latest (effectiveTime_Start) HF Conditions negationInd <> 1 //no use
    of Condition.negationInd in UPMC.
    OR
    Latest (effectiveTime_Start) HF Conditions statusCode notMemberIn
    ([2.16.840.1.113883.5.14, aborted], [2.16.840.1.113883.5.14, cancelled],
    [2.16.840.1.113883.5.14, suspended])
    Condition status concept may be retrieved from the CTS (design-time)
    Then Set Evaluation Result to True
    Outputs may include IsHFPatient, whose type is Boolean Conclusion ER.

    Attribute names, values and other characteristics of outputs are set out in the table of FIG. 144B.
    SmartWatch KM is now described.
    Inputs may include:
    “Is HF Patient” KM evaluation result (Boolean Conclusion ER)
    Decision logic, in words and in pseudo-code, may be as follows:
  • In words:
    When “Is HF Patient” KM evaluation result is True
    Then
    Add member to population ″HF Patients″, Step in classification
    Remove member from population “Candidates”, Step out classification
    Else
  • Remove member from population “Candidates”, Step out classification
  • In pseudo code:
  •
    When “Is HF Patient” KM evaluation result = True
    Then
    Create Evaluation Result - Classification Decision Activity:
    ClassificationDecisionActivity/ClassificationDecision/classificationId =
    “HFPatients”
    /move = “In”
    AND
    Create Evaluation Result - Classification Decision Activity:
    ClassificationDecisionActivity/ClassificationDecision/classificationId =
    “Candidates”
    /move = “Out”

    Outputs may include EntryHFPatientsClassification, whose type is Classification Decision Activity.
    CTS: Retrieve HF Condition codes
    • Triggering Rule may be:
  • CTS list=
    named query=” GetLocalCodesForConceptHierarchy”
    Parameters=
    @code=″84114007″
    @codeSystemId=″2.16.840.1.113883.6.96″
    ]
    • KNEO may be:
  • CTS list=
    named query=” GetLocalCodesForConceptHierarchy”
    Parameters=
    @code=″84114007″
    @codeSystemId=″2.16.840.1.113883.6.96″
    ]
    • KFW
  • CTS list=
    named query=” GetConceptHierarchy”
    Parameters=
    @code=″84114007″
    @codeSystemId=″2.16.840.1.113883.6.96″
    ]

    An Exit Task for the HF patients classification may be as follows:
    Triggering Rules, each of which may be implemented in XML, may include some or all of:
    Identify cancelled HF Problems for specific patient—list of codes may be as above (CTS list for triggering rule). (No use of Condition.negationInd in UPMC); and
    Identify expiration of specific patient
    Is HF Patient KM: may be same as for the entry task.
    • SmartWatch KM:
  • Inputs may include:
    “Is HF Patient” KM evaluation result (Boolean Conclusion ER)
    Decision logic, in words and in pseudocode, may be as follows:
  • In words:
    When “Is HF Patient” KM evaluation result is False
    Then
    Remove member from population ″HF Patients″, Step out classification
    Exit criteria type: “not relevant” — patient was removed from the
    population (patient is deceased) i.e. there is no need to monitor the
    completion of his recommendations
    Action: Store Result to EDR

    The result stored in the EDR is the “Is HF Patient” (clinical) KM evaluation result as-is.
    In pseudo code:
  • When “Is HF Patient” KM evaluation result = False
    Then
    Create Evaluation Result - Classification Decision Activity:
    ClassificationDecisionActivity/ClassificationDecision/classificationId =
    “HFPatients”
    /move = “Out”
    AND
    Create Evaluation Result - Action Invocation Activity:
    ActionInvocationActivity/ActionInvocation/actionId = “StoreToEDR”
    /ActionInvocationParameter/alias = “Is HF Patient”
    /rootId = null
    /extension = null
    /InformationModelSSId= $IsHFPatientER.SSid
    /value = $IsHFPatientER

    Outputs are described in the table of FIG. 144C. CTS may be as for the entry task.
    • Admitted
  • An example sub-classification for admitted HF patients is now described with reference to FIGS. 145A-145D, including triggering rules and other characteristics for entry and exit tasks.
    Entry Task may be as follows:
    Triggering Rules may be implemented in XML and may include some or all of the following:
    a. Identify Active (status=active AND discharge date=null) Inpatient Encounters in specific Facility for specific Patient
    b. Identify (status=null AND discharge date=null) Inpatient Encounters in specific Facility for specific Patient
    c. Identify Completed (status=completed AND discharge date < > null) Inpatient Encounters in specific Facility for specific Patient
    d. Identify Completed (status=null AND discharge date < > null) Inpatient Encounters in specific Facility for specific Patient
    Is Eligible HF Encounter KM may be as follows:
    Inputs/Query Parameters are described in the table of FIG. 145A.
    Decision logic, in words and in pseudocode, may be as follows:
  • In words:
    When
    Encounter is active OR Encounter discharge date is from the past 24 hours
    AND
    Encounter from a given facility
    AND
    Encounter deals with hospitalized patients (inpatient OR emergency)
    AND
    Encounter length of stay is less than 120 days
    AND
    Patient age exceeds 18 years (at the admission date)

    The SW KM (smart watch knowledge module) e.g. as described below may save the encounter id (CPQP) in the classification. The encounter id may be extracted from the IsEligibleHFEncounterER.Reasons. In general, only one encounter may be retrieved, but in exceptional cases more than one may be retrieved. In order to guarantee that the SW KM may only find one encounter id, enforce also a latest operation (on top of all other conditions).
    • Then Return is EligableHFEncounter=True Else Return is EligableHFEncounter=False
  • In pseudo code:
  •
    When
    {((Encounters/Encounter/statusCode/code = “active” AND
    Encounters/Encounter/statusCode/codeSystem =
    “2.16.840.1.113883.5.14”) OR
    Encounters/Encounter/statusCode/code = null)
    AND
    Encounters/Encounter/effectiveTime_end = null}
    OR
    {((Encounters/Encounter/statusCode/code = “completed” AND
    Encounters/Encounter/statusCode/codeSystem =
    “2.16.840.1.113883.5.14”) OR
    Encounters/Encounter/statusCode/code = null)
    AND
    Encounters/Encounter/effectiveTime_end + 24 hours > Now}
    Encounter status concept may be retrieved from the CTS (design-time)
    AND
    (Encounters/Encounter/assignedOrganization/id/root =
    “2.16.840.1.113883.3.57.1.3.11.11.1.6.5” AND
    Encounters/Encounter/assignedOrganization/id/extension = “RE”) OR
    (Encounters/Encounter/assignedOrganization/id/root =
    “2.16.840.1.113883.3.57.1.3.11.11.1.6.5” AND
    Encounters/Encounter/assignedOrganization/id/extension = “RI”)
    AND
    (Encounters/Encounter/code/code = “EMER” AND
    Encounters/Encounter/code/codeSystem = “2.16.840.1.113883.5.4”) OR
    (Encounters/Encounter/Code/Code = “IMP” AND
    Encounters/Encounter/code/codeSystem = “2.16.840.1.113883.5.4”) OR
    (Encounters/Encounter/code/code = “ACUTE” AND
    Encounters/Encounter/code/codeSystem = “2.16.840.1.113883.5.4”) OR
    (Encounters/Encounter/Code/Code = “NONAC” AND
    Encounters/Encounter/code/codeSystem = “2.16.840.1.113883.5.4”)
    Encounter type concept may be retrieved from the CTS (design-time)
    AND
    When Encounters/Encounter/effectiveTime end = null Then Now( ) −
    Encounters/Encounter/effectiveTime_start <= 120 days Else
    Encounters/Encounter/effectiveTime_end −
    Encounters/Encounter/effectiveTime_start <= 120 days
    AND
    Encounters/Encounter/effectiveTime_start −
    PatientAdministration/BirthTime >= 18 years

    The SW KM e.g. as described below may save the encounter id (CPQP) in the classification. The encounter id may be extracted from the IsEligibleHFEncounterER.Reasons. In general, only one encounter may be retrieved, but in exceptional cases more than one may be retrieved. In order to guarantee that the SW KM may only find one encounter id, enforce also a latest operation (in addition to all other conditions).
    • Then Set Evaluation Result to True
  • Outputs may include IsEligibleHFEncounter, whose type is Boolean Conclusion ER.
    Attribute names and values of outputs are described in the table of FIG. 145B.
    An example SmartWatch KM is now described.
    Inputs may include:
    “Is Eligible HF Encounter” KM evaluation result (Boolean Conclusion ER)
    Decision logic, in words and in pseudocode, may be as follows:
  • In words:
    When “Is Eligible HF Encounter” KM evaluation result is True
    Then
    Add member to population ″Admitted HF Patients″, Step in
    classification and save encounter id (CPQP) in classification
    • Action: Store Result to EDR
  • The result stored in the EDR is the “Is Eligible HF Encounter” (clinical) KM evaluation result as-is.
    In pseudo code:
  • When “Is Eligible HF Encounter” KM evaluation result = True
    Then
    Create Evaluation Result - Classification Decision Activity:
    ClassificationDecisionActivity/ClassificationDecision/classificationId =
    “AdmittedHFPatients”
    /move = “In”
    /ClassificationDecisionParameter/key =
    “SW_ADMITTED_HF_ENC_ROOT”
    /value = $IsEligibleHFEncounterER.Reasons...Act_ref/root
    /ClassificationDecisionParameter/key =
    “SW_ADMITTED_HF_ENC_EXT”
    /value = $IsEligibleHFEncounterER.Reasons...Act_ref/extension
    AND
    Create Evaluation Result - Action Invocation Activity:
    ActionInvocationActivity/ActionInvocation/actionId = “StoreToEDR”
    /ActionInvocationParameter/alias = “Is Eligible HF Encounter”
    /rootId = null
    /extension = null
    /InformationModelSSId= $IsEligibleHFEncounterER.SSid
    /value = $IsEligibleHFEncounterER

    Outputs are described in the table of FIG. 145C.
    An example Exit Task for the sub-classification of the admitted HF patients is now described.
    Triggering Rules may include:
    Identify if specific encounter was not active OR encounter type was changed OR discharge date not empty; and
    Temporal Trigger: Admission Date+120 days
    Is Eligible HF Encounter KM may be as described above with reference to the corresponding characteristic of the entry task.
    An example SmartWatch KM is now described.
    Inputs may include:
    “Is Eligible HF Encounter” KM evaluation result (Boolean Conclusion ER)
    Decision logic, in words and in pseudocode, may be as follows:
  • In words:
    When “Is Eligible HF Encounter” KM evaluation result is False
    Then
    Remove member from population ″Admitted HF Patients″, Step out
    classification
    Exit criteria type: “to be completed” — patient was removed from the
    population due to some other event (not death) hence completion of all his
    recommendations is still to be monitored.
    Action: Store Result to EDR

    The result stored in the EDR is the “Is Eligible HF Encounter” (clinical) KM evaluation result as-is.
    In pseudo code:
  • When “Is Eligible HF Encounter” KM evaluation result = False
    Then
    Create Evaluation Result - Classification Decision Activity:
    ClassificationDecisionActivity/ClassificationDecision/classificationId =
    “AdmittedHFPatients”
    /move = “Out”
    AND
    Create Evaluation Result - Action Invocation Activity:
    ActionInvocationActivity/ActionInvocation/actionId = “StoreToEDR”
    /ActionInvocationParameter/alias = “Is Eligible HF Encounter”
    /rootId = null
    /extension = null
    /InformationModelSSId= $IsEligibleHFEncounterER.SSid
    /value = $IsEligibleHFEncounterER
    Outputs are described in the table of Fig. 145D.
    HF - 2: Evaluation of

    An example, also termed herein HF-2, of an LVS function evaluation method, including triggering rules and other characteristics for a monitoring task, is now described with reference to FIGS. 146A-146B.
    An example Monitoring Task for the above LVS function evaluation method is now described.
    Triggering Rules may include:
    Identify changes in the existence of LVS Function Evaluation Document for specific patient—list of codes, e.g. as for the triggering rule for the CTS described below, e.g. using a suitable XML implementation.
    An example Evaluation of LVS Function KM may be as follows:
    Inputs/Query Parameters are described in the table of FIG. 146A.
    Decision logic, in words and in pseudocode, may be as follows:
  • In words:
    When
    At least one LVS Function Evaluation Document Exist in Patient Record
    Then
    Return Code HF2-T1
    AND
    Return isPerformed = True
    AND
    Return isRequired = False
    Else
    Return Code HF2-T2
    AND
    Return isPerformed = False
    AND
    Return isRequired = True

    Code translations may be e.g. as shown in FIG. 153.
    In pseudo code:
  • Rule #1
    When
    LVS Documents DRI is not empty
    Documents/ClinicalDocument/code/(code,codeSystem) Member In CTS
    list described below.
    Then
    Create Evaluation Result - Quality Conclusion:
    QualityConclusion/QualityAnswer/SystemName = null
    /code = “HF2-T1”
    /codeSystem = “2.16.840.1.113883.3.57.1.4.6.1”
    /displayName = null
    /effectiveTime = null
    /domainCode = null
    Set Evaluation Result (IsPerformed) to True
    Set Evaluation Result (IsRequired) to False
    Rule #2 (else)
    When
    LVS Documents DRI is empty
    IsEmpty (Documents/ClinicalDocument/code/(code,codeSystem) Member
    In CTS list described below.
    Then
    Create Evaluation Result - Quality Conclusion:
    QualityConclusion/QualityAnswer/SystemName = null
    /code = “HF2-T2”
    /codeSystem = “2.16.840.1.113883.3.57.1.4.6.1”
    /displayName = null
    /effectiveTime = null
    /domainCode = null
    Set Evaluation Result (IsPerformed) to False
    Set Evaluation Result (IsRequired) to True

    Outputs are described in the table of FIG. 146B. The Quality Conclusion contains a vocabulary code. The code designation may be retrieved from dbMotion vocabulary by the consumer (EDR). The vocabulary may also hold the mapping between the code and the relevant category e.g. as shown in FIG. 153.
    Attribute names and values are described in the table of FIG. 146C.
    An example SmartWatch KM for the LVS function evaluation method's monitoring task may be as follows:
    Inputs may include:
    “Evaluation of LVS Function” KM evaluation result
    Decision logic, in words and in pseudocode, may be as follows:
    In words:
    When always
    • Then Action: Store Result to EDR
  • The result stored in the EDR is the “Evaluation of LVS Function” (clinical) KM evaluation result as-is.
    In pseudo code:
  • When 1=1
    Then
    Create Evaluation Result - Action Invocation Activity:
    ActionInvocationActivity/ActionInvocation/actionId = “StoreToEDR”
    /ActionInvocationParameter/alias = “Evaluation of LVS Function”
    /rootId = null
    /extension = null
    /InformationModelSSId= $EvaluationOfLVSFunctionER.SSid
    /value = $EvaluationOfLVSFunctionER
    /ActionInvocationParameter/alias = “HF-2:IsPerformed”
    /rootId = null
    /extension = null
    /InformationModelSSId= $HF-2:IsPerformedER.SSid
    /value = $HF-2:IsPerformedER
    /ActionInvocationParameter/alias = “HF-2:IsRequired”
    /rootId = null
    /extension = null
    /InformationModelSSId= $HF-2:IsRequiredER.SSid
    /value = $HF-2:IsRequiredER

    Outputs may include EvaluationOfLVSFunctionAction, which may be of the Action Invocation Activity type.
    CTS: Retrieve list of document types (“LVS Function Evaluation”)
    Triggering Rule may include:
  • CTS list=
    @code=“11522-0”; @codeSystemId=“ 2.16.840.1.113883.6.1”
    @code=“18745-0”; @codeSystemId=“ 2.16.840.1.113883.6.1”
    ]
    • KNEO may be:
  • CTS list=
    @code=“11522-0”; @codeSystemId=“ 2.16.840.1.113883.6.1”
    @code=“18745-0”; @codeSystemId=“ 2.16.840.1.113883.6.1”

    KFW may include:
  • CTS list=
    @code=“11522-0”; @codeSystemId=“ 2.16.840.1.113883.6.1”
    @code=“18745-0”; @codeSystemId=“ 2.16.840.1.113883.6.1”
    • HF-3
  • An example, also termed herein HF-3, of ACEI or ARB for LVSD is now described with reference to FIGS. 147-150.
    A Monitoring Task for ACEI or ARB for LVSD, may for example be as follows:
    Triggering Rules, each of which may be implemented in XML, may include some or all of:
    Identify changes in ACEI or ARB Medications for specific Encounter—list of codes e.g. as described below with reference to the triggering rule for these medications.
    Identify changes in ACEI or ARB Allergies for specific Patient—list of codes e.g. as described below with reference to the triggering rule for these allergies.
    Identify negated OR cancelled HF Problem events for specific patient—e.g. as per exit task triggering rules for HF patient classification as described above.
    Identify changes in ACEI or ARB Contraindication Conditions—list of codes e.g. as described below with reference to the triggering rule for these contraindication conditions.
    • ACEI or ARB for LVSD KM:
  • Inputs/Query Parameters are described in the table of FIG. 147. The list of codes for the first and second rows in the table may be as described herein for the CTS of the ACEI or ARB for LVSD monitoring task (KNEO for ACEI and ARB medications). The list of codes for the third row in the table may be as described herein for the CTS of the ACEI or ARB for LVSD monitoring task (KNEO for diastolic dysfunction conditions). The list of codes for the fourth row in the table may be as described herein for the CTS of the ACEI or ARB for LVSD monitoring task (KNEO for contraindications conditions). The list of codes for the fifth and sixth rows in the table may be as described herein for the CTS of the ACEI or ARB for LVSD monitoring task (KNEO for ACEI and ARB allergies).
    Decision logic, in words and in pseudocode, may be as follows:
    In words:
    An example of a suitable decision table (in words) is provided in FIG. 148.
    Codes translations may be as shown in FIG. 153.
    In pseudo code:
  • When
    Patient has Diastolic Dysfunction?
    Diastolic Dysfunction Conditions DRI is not empty
    Conditions/Condition/value/(code,codeSystem) Member In CTS list- 0
    ACEI Medication Prescribed During Encounter?
    ACEI Medications DRI is not empty
    SubstancesAdministration/SubstanceAdministration/Medication/code/(code,codeSyst
    em) Member In CTS list e.g. as described herein with reference to the KFW of the
    ACEI and ARB medications.
    ARB Medication Prescribed During Encounter?
    ARB Medications DRI is not empty
    SubstancesAdministration/SubstanceAdministration/Medication/code/(code,codeSyst
    em) Member In CTS list- e.g. as described herein with reference to the KFW of the
    ACEI and ARB medications.
    ACEI Allergy?
    ACEI Allergies DRI is not empty
    Allergies/AllergyIntolerance/value/(code,codeSystem) Member In CTS list - e.g. as
    described herein with reference to the KFW of the ACEI and ARB allergies.
    ARB Allergy?
    ARB Allergies DRI is not empty
    Allergies/AllergyIntolerance/value/(code,codeSystem) Member In CTS list e.g. as
    described herein with reference to the KFW of the ACEI and ARB allergies.
    ACEI or ARB Contraindications Conditions?
    ACEI and ARB Contraindication Conditions DRI is not empty
    Conditions/Condition/value/(code,codeSystem) Member In CTS list - e.g. as
    described herein with reference to the KFW of the contraindication conditions for the
    ACEI and ARB.
    Then
    Create Evaluation Result - Quality Conclusion:
    QualityConclusion/QualityAnswer/SystemName = null
    /code = according to the table of Fig. 148
    /codeSystem = “2.16.840.1.113883.3.57.1.4.6.1”
    /displayName = null
    /effectiveTime = null
    /domainCode = null

    Set Evaluation Result (IsPerformed) to True/False according to the table of FIG. 148
    Set Evaluation Result (IsRequired) to True/False according to the table of FIG. 148
    Outputs are described in the table of FIG. 149.
    The Quality Conclusion contains a vocabulary code. The code designation may be retrieved from dbMotion vocabulary by the consumer (EDR). The vocabulary may also hold the mapping between the code and the relevant category e.g. as shown in FIG. 153.
    Attribute names, values and other characteristics are set out in the table of FIG. 150. An example of a SmartWatch KM for the monitoring task of the ACEI or ARB for LVSD is now described.
    Inputs may include:
    “ACEI or ARB for LVSD” KM evaluation result
    Decision logic, in words and in pseudocode, may be as follows:
  • In words:
    When always
    Then
    Action: Store Result to EDR

    The result stored in the EDR is the “ACEI or ARB for LVSD” (clinical) KM evaluation result as-is.
    In pseudo code:
  • When 1=1
    Then
    Create Evaluation Result - Action Invocation Activity:
    ActionInvocationActivity/ActionInvocation/actionId = “StoreToEDR”
    /ActionInvocationParameter/alias = “ACEI or ARB for LVSD”
    /rootId = null
    /extension = null
    /InformationModelSSId= $ACEIorARBforLVSDER.SSid
    /value = $ACEIorARBforLVSDER
    /ActionInvocationParameter/alias = “HF-3:IsPerformed”
    /rootId = null
    /extension = null
    /InformationModelSSId= $HF-3:IsPerformedER.SSid
    /value = $HF-3:IsPerformedER
    /ActionInvocationParameter/alias = “HF-3:IsRequired”
    /rootId = null
    /extension = null
    /InformationModelSSId= $HF-3:IsRequiredER.SSid
    /value = $HF-3:IsRequiredER

    Outputs may include ACEIorARBforLVSDAction, of the Action Invocation Activity type.
    An example CTS for the monitoring task of the ACEI or ARB for LVSD is now described.
    ACEI and ARB medications:
    Retrieve list of ARB medications (ACEI and ARB)—2 separate lists
    Triggering Rule may be as follows:
  • ACEI CTS list=
    named query=” product/GetLocalCodesForConceptHierarchy″
    Parameters=
    @code=″ 372733002″
    @codeSystemId=″2.16.840.1.113883.6.96″
    ARB CTS list=
    named query=” product/GetLocalCodesForConceptHierarchy”
    Parameters=
    @code=″ 372913009″
    @codeSystemId=″2.16.840.1.113883.6.96″

    KNEO may be as follows:
  • ACEI CTS list=
    named query=” product/GetLocalCodesForConceptHierarchy”
    Parameters=
    @code=″ 372733002″
    @codeSystemId=″2.16.840.1.113883.6.96″
    ARB CTS list=
    named query=” product/GetLocalCodesForConceptHierarchy”
    Parameters=
    @code=″ 372913009″
    @codeSystemId=″2.16.840.1.113883.6.96″

    KFW may be as follows:
  • ACEI CTS list=
    named query=” product/GetConceptHierarchy”
    Parameters=
    @code=″ 372733002″
    @codeSystemId=″2.16.840.1.113883.6.96″
    ARB CTS list =
    named query=” product/GetConceptHierarchy”
    Parameters=
    @code=″ 372913009″
    @codeSystemId=″2.16.840.1.113883.6.96″
  • ACEI and ARB Allergies for the CTS of the monitoring task of the ACEI or ARB for LVSD is now described.
  • Retrieve list of allergies (ACEI and ARB)—2 separate lists.
    Triggering Rule may comprise:
  • ACEI Allergy CTS list =
    named query=”product/GetLocalCodesForConceptHierarchy”
    Parameters=
    @code=″372733002″
    @codeSystemId=″2.16.840.1.113883.6.96″
    ARB CTS list=
    named query=”product/GetLocalCodesForConceptHierarchy”
    Parameters=
    @code=″372913009″
    @codeSystemId=″2.16.840.1.113883.6.96″

    KNEO may comprise:
  • ACEI CTS list=
    named query=”product/GetLocalCodesForConceptHierarchy”
    Parameters=
    @code=″372733002″
    @codeSystemId=″2.16.840.1.113883.6.96″
    ARB CTS list=
    named query=”product/GetLocalCodesForConceptHierarchy”
    Parameters=
    @code=″372913009″
    @codeSystemId=″2.16.840.1.113883.6.96″

    KFW may comprise:
  • ACEI CTS list=
    named query=”product/GetConceptHierarchy”
    Parameters=
    @code=″372733002″
    @codeSystemId=″2.16.840.1.113883.6.96″
    ARB CTS list =
    named query=”product/GetConceptHierarchy”
    Parameters=
    @code=″372913009″
    @codeSystemId=″2.16.840.1.113883.6.96″

    Contraindication conditions: list of contraindication conditions (ACEI and ARB) may be retrieved.
    • Triggering Rule may be:
  • CTS list=
    @code=“41291007”
    @codeSystemId=“2.16.840.1.113883.6.96”
    @code=“45281005”
    @codeSystemId=“2.16.840.1.113883.6.96”
    • KNEO may be:
  • CTS list=
    @code=“41291007”
    @codeSystemId=“2.16.840.1.113883.6.96”
    @code=“45281005”
    @codeSystemId=“2.16.840.1.113883.6.96”
    • KFW may be:
  • @code=“41291007”
    @codeSystemId=“2.16.840.1.113883.6.96”
    @code=“45281005”
    @codeSystemId=“2.16.840.1.113883.6.96”

    Diastolic dysfunction conditions: list of diastolic dysfunction conditions (subset of HF conditions) may be retrieved.
    • KNEO may be:
  • CTS list=
    @code=“418304008”
    @codeSystemId=“2.16.840.1.113883.6.96”
    • KFW may be:
  • @code=“418304008”
    @codeSystemId=“2.16.840.1.113883.6.96”
    • Temp
  • An example sub-classification for temp discharged HF patients is now described with reference to FIGS. 151-152B, including triggering rules and other characteristics for entry and exit tasks. Motivation—to support a business requirement to continue monitoring discharged patients for 24 hours after the discharge. This sub-classification is a workaround for Dynamic Triggering Rule Parameters. Parent Classification—Admitted HF Patients.
    An example Entry Task for the sub-classification for temp discharged HF patients is now described.
    Triggering Rules: Identify Completed Inpatient Encounters in specific Facility for specific Patient e.g. as per third and fourth triggering rules for entry task of admitted HF patients sub-classification, described above.
    • Is Discharged HF Patient KM:
  • Inputs/Query Parameters may be as per row 1 in the table of FIG. 145A.
    Decision logic, in words and in pseudocode, may be as follows:
  • In words:
    When
    Encounter discharge date is from the last 24 hours
    Then Return isDischargedHFEncounter = True
    Else Return isDischargedHFEncounter = False

    In pseudo code:
  • When
    ((Encounters/Encounter/statusCode/code = “completed” AND
    Encounters/Encounter/statusCode/codeSystem =
    “2.16.840.1.113883.5.14”) OR
    Encounters/Encounter/statusCode/code = null)
    AND
    Encounters/Encounter/effectiveTime_end + 24 hours > Now
    Encounter status concept may be retrieved from the CTS (design-time)
    Then Set Evaluation Result to True

    This rule may be exactly as the first part of the Is Eligible HF Encounter KM e.g. as described above with reference to “is eligible HF encounter KM” pertaining to the entry task of the sub-classification for admitted heart failure patients. Therefore it may be useful to reuse this logic i.e. the Is Eligible HF Encounter KM may be divided into 2 KMs/rules that one of them is this one.
    Outputs may include is DischargedHFEncounter, whose type is Boolean Conclusion ER.
    Attribute names, values, and other characteristics are set out in the table of FIG. 151.
    • SmartWatch KM
  • Inputs may include:
    “Is Discharged HF Patient” KM evaluation result (Boolean Conclusion ER)
    Decision logic, in words and in pseudocode, may be as follows:
  • In words:
    When “Is Discharged HF Patient” KM evaluation result is True
    Then
    Add member to population ″Temp Discharged HF Patients″, Step
    in classification

    In pseudo code:
  • When “Is Discharged HF Patient” KM evaluation result = True
    Then
    Create Evaluation Result - Classification Decision Activity:
    ClassificationDecisionActivity/ClassificationDecision/classificationId =
    “TempDischargedHFPatients”
    /move = “In”

    Outputs are set out in the table of FIG. 152.
    An example Exit Task for the sub-classification for temp discharged HF patients is now described.
    Triggering Rules may include at least the following:
    • Temporal Trigger Discharge Date+24 Hours
  • Is Discharged HF Patient KM: as for the entry task.
    An example SmartWatch KM for the exit task may be as follows:
    • Inputs:
  • “Is Discharged HF Patient” KM evaluation result (Boolean Conclusion ER)
    Decision logic, in words and in pseudocode, may be as follows:
  • In words
    When “Is Discharged HF Patient” KM evaluation result is False
    Then
    Remove member from population ″Temp Discharged HF Patients″, Step
    out classification

    In pseudo code
  • When “Is Discharged HF Patient” KM evaluation result = False
    Then
    Create Evaluation Result - Classification Decision Activity:
    ClassificationDecisionActivity/ClassificationDecision/classificationId =
    “TempDischargedHFPatients”
    /move = “Out”

    Outputs are set out in the table of FIG. 152.
    Example vocabulary Codes for the embodiment of FIGS. 144A-152B are set out in the table of FIG. 153.
  • FIG. 154 a is a simplified functional block diagram of a high level architecture of a smart agent system constructed and operative in accordance with certain embodiments of the present invention. In FIG. 154 a, it is appreciated that EMR is also termed EHR herein. Data Analyzer Desktop Agent is also termed EHR Agent Host or SmartAgent host herein. Agent Viewer is also termed EHR Agent User Interface or SmartAgent user interface herein. A VPO (Virtual Patient Object) is an Object, in the sense of object-oriented programming, that is retrieved by a Patient data services functionality and stores a patient's clinical History. A VPO Analyzer is also termed EHR Agent Orchestration Web Service herein. A VPO Business Domain is also termed Clinical Data Web Service or “Patient Clinical Data Services” or “Patient data services” herein. The term “WPF” refers to a conventional computer-software graphical subsystem for rendering user interfaces such as but not limited to, for Windows-based applications, Windows Presentation Foundation.
  • The term “PPOL” refers to a Patient-Provider-Organization Link such as but not limited to that provided in DBMotion's commercially available HIE. Generally, a medical domain typically comprises interconnected network of entities (e.g. as shown in FIG. 172) such as Providers (e.g., medical staff, clinician, nurse) providing care services to Patients, at medical Organizations (e.g., clinic, hospital). The information about relations (Links) between medical entities is an integral part of healthcare information which facilitates intelligent services. For example, a PPOL may list patients being treated by a specific clinician, describe an organizational hierarchy of a medical unit, and return the PCP of a specific patient. A Providers-Patients-Organizations Link (PPOL) computerized service typically provides and manipulates information about relations (Links) between medical entities. A PPOL typically manages different entities and the relations between the entities in the medical domain, such as—for example—relationships between a patient's GP and the physician's office manager. A PPOL typically does one or more of: connects to a conventional EMPI (Enterprise Master Patient Index) patient registry; provides a unique ID for patient and provider identities (aka cluster); stores provider-provider relations, e.g. office manager; stores provider-patient relations, e.g. PCP based on ADT messages; and acts as a providers' registry or connects to an existing such registry.
  • The smart agent system of FIG. 154 a typically includes a client and a server, each including some or all of the illustrated blocks, interacting suitably e.g. as shown. The SmartAgent client application typically intercepts EMR activities and recognizes EMR context e.g. user, patient and workflow e.g. as described herein in detail. The PPOL module typically performs identity management including harmonization of different identifiers of entities. The CTS terminologies and vocabularies module typically harmonizes local terminologies used in various data sources to the ontology used by the HIES e.g. the HIES commercially available from DbMotion, Israel. The security authority block typically authenticates and authorizes user access to patients' clinical data. The “get VPO” block typically retrieves patient data (e.g. VPOs—virtual patient objects) from repositories, which may be harmonized and/or federated, in the HIES.
  • The term “smart agent” is used herein to include an HIES-EMR bridging system according to any of the embodiments shown and described herein, which facilitates cooperation between HIES and a population of one or more EMRs with which the HIES interacts. For example, the smart agent may perform any or all of the following operations:
  • a. identify an application which has opened on a work station on which the HIES client is installed, as a medical service provider application e.g. EMR. This may occur because the EMR is compatible with a context sharing standard that the smart agent also supports or may be screen captured. Alternatively, APIs in the operating system may be available which define (assign an operating system name to) the relevant screen and/or fields within the screen, enabling the smart agent to identify the application.
    b. identify health care providing user e.g. because user logins in with password, or by capturing user's name from the screen, or e.g. authenticating the user using single-sign on functionality.
    c. assuming that the EMR is currently working on the medical record of a particular patient, the smart agent may find the patient identifier, e.g. by screen capture or by context sharing. Typically, when an EMR enters a medical record, the smart agent retrieves the patient identifier by first recognizing the EMR page through which the patient user accesses the medical records and then, e.g. using prior knowledge re the location of the patient identifier on that page, capturing the user identifier.
    d. optionally, filter available HIES information, e.g. using suitable “attention rules”, to select suitable information to provide to the user identified in (b), pertaining to the patient identified in (c). Typically, attention rules filter out either irrelevant information or superfluous (repetitive) information, or both.
    e. display all, or some (as filtered in (d)) information pertaining to the patient identified in (c.). Typically, all information available from all EMRs with which the HIES interacts, is available to be displayed, unless filtered. Typically, this information is displayed to the health care providing user via an HIE data importer such as a tab or button that takes the user to an HIE portal.
    Examples of the operation of steps (d) and (e):
  • (i) if the user presses on the lab page in her or his EMR, the lab page may be identified by the hovering smart agent. The smart agent may then display to the user only lab results which are not present in her EMR, optionally blinking to indicate that such exist and are available for viewing.
  • (ii) if the user presses on a medicine page in her or his EMR, the hovering smart agent may intercept that the user is prescribing penicillin to a patient called Susan Smith and may then display only relevant information such as all allergies known for Susan Smith, or the subset of Susan Smith allergies pertinent to penicillin.
  • (iii) The user presses on a lab result page and sends Susan Smith to do a lab test. The smart agent may intercept this and blink or otherwise indicate that Susan has already done this lab test.
  • The SmartAgent user interface and behavior is designed to be floated on top of an instance of an EMR and not to interrupt the regular user workflow.
  • A Floating application within User, Patient and System Context, e.g. as shown in FIG. 156 a, may be used as follows:
  • 1. The User opens a patient record in the EMR.
    2. A HIES client agent (SmartAgent) installed on the client machine “captures” the patient identifier (MRN), the User Context (Username/Role), and the System Context (SystemID) and calls the HIE's VPO Analyzer web service, which identifies the System, the User and the Patient.
    3. The User is authorized and the Patient is found in the HIE.
    4. The client SmartAgent gets the response and presents a Floating Application. The Floating button includes a link to launch the HIE's Viewer with the user and patient context.
    5. The User clicks the button and seamlessly accesses the HIE's Clinical Viewer.
  • The VPO (Virtual Patient Object) Analyzer of FIG. 154 a typically performs smart evaluations on the VPO in the context of the User, the Patient and the System, in order to provide more relevant and needed information to the User. One of the VPO Analyzer's methods is “Exclude System Data”. This method excludes data from the VPO that already exists in the User's EMR. This results in “clean” data (excluding what user can already see in the EMR) that is presented within the Results or Viewer Panes.
  • A Semantic Search method is now described:
  • 1. The user looks for data on Diabetes (say) in the HIES. To do so, the User enables the Search option in the floating toolbar and types the phrase “Dia”.
    2. Search suggestions are presented and user selects the “Diabetes” Suggestion.
    3. As a result, the Results and Navigation pane opens and presents the results for Diabetes from the Patient's VPO, organized according to Clinical Aspects (Medications, Problems, Population Membership, etc).
    4. The User clicks the “Diabetes” population.
    5. The Diabetes View is opened in the View panel.
  • A process operative to Launch an HIES Viewer and CareBoard is now described. Any information found is presented in the Data and Navigation panel. The information is organized according to the different clinical aspects (Laboratory, Medications, etc.) and evaluation aspects (Population membership, Metrics, Notifications, Alerts etc.). The clinical aspects and actual presented data are links to the relevant page in the HIES's Clinical Viewer or Collaborate. Example: Under the Lab Results menu, the user sees a result for hbA1c from last week. Beside the result there are two buttons: one opens the Labs Clinical View and the other opens the Lab Results Page with the hbA1c history.
  • FIG. 154 b is a table summarizing an example set of functional requirements of a content/VPO analyzer included in the apparatus shown and described herein.
  • FIG. 154 c is a table summarizing an example set of functional requirements of a content capturing and sharing functionality included in the apparatus shown and described herein.
  • FIG. 154 d is a table summarizing an example set of functional requirements of a semantic search functionality included in the apparatus shown and described herein.
  • FIG. 154 e is a table summarizing an example set of functional requirements of a floating application included in the apparatus shown and described herein.
  • FIG. 155 a is a table summarizing an example set of non-functional auditing, security and localization requirements of apparatus shown and described herein.
  • FIG. 155 b is a table summarizing an example set of non-functional topological and pre-requisite requirements of apparatus shown and described herein.
  • FIG. 155 c is a table summarizing an example set of non-functional performance requirements of apparatus shown and described herein.
  • FIG. 155 d is a table summarizing an example set of non-functional reusability and integrability requirements of apparatus shown and described herein.
  • In an OnPageLoad mode of operation, FIG. 156 a is an example user interface useful in entering a Patient File and launching the SmartAgent system provided according to certain embodiments of the present invention.
  • Floating Application Small Panel: An example user interface for a FloatingClosed functionality is illustrated in FIG. 156 b. An example object table useful in understanding the functionality of the user interface of FIG. 156 b is illustrated in FIG. 156 c. Footnotes in the first column of the object table of FIG. 156 c refer to suitably marked locations in the user interface of FIG. 156 b, respectively.
  • An example user interface for a FloatingSearchOpen functionality is illustrated in FIG. 156 d.
  • FIG. 157 a illustrates the SmartAgent application hovering on top of an example EMR (Allscripts Sunrise—commercially available EMR) in an expanded mode.
  • FIG. 157 b is an enlarged view of the expanded SmartAgent panel.
  • An example object table useful in understanding the functionality of the user interface of FIG. 157 b is illustrated in FIG. 157 c. Footnotes in the first column of the object table of FIG. 157 c refer to suitably marked locations in the user interface of FIG. 157 b, respectively.
  • FIG. 157 d is an Object Table.
  • FIG. 158 is a user interface for a laboratory screenshot of a preview panel useful in accordance with certain embodiments of the present invention.
  • Example Attention Rule Definitions for a Clinical Content Specification are now described. The smart agent typically uses attention rules to determine whether or not to provide a user with an indication that aims to direct her or his attention to the fact that information relevant to her or him is available in the HIES. The indication may include a highlight color in the background of the Name e.g. as shown in FIG. 159 a. A rule can be built from a set of predefined filter types, such that a suitable predefined combination of the rules triggers the Attention indication and the relevant data presented by default. FIG. 159 b is a table presenting an example set of basic rules. FIG. 159 c is a table presenting an example set of rule combinations. The indication may consider the filter types of FIG. 159 c which are combinations of the basic rules of FIG. 159 b.
  • Example rules are as follows:
  • Rule 1: Exclude my E.H.R. data:
    User is alerted if there is information in the HIES which does not exist in the user's EMR. Typically, the HIES stores an indication, for each information item, of the EMR which provided that information item, allowing information items provided by a user's EMR to be filtered out and not displayed to the user.
    Rule 2: Exclude data irrelevant to workflow.
  • A health care providing user opens his EMR at a page pertaining to laboratory, medicine, Procedures, Allergies, Vital signs, Pathologies, Imaging results, Clinical documents, immunizations, Problems, Diagnosis, or any other EMR functionality. The Agent hovers over the EMR application, intercepts the type of page opened, and selects from among the HIE information items available, only the ones which are relevant, using predetermined criteria, to the current EMR functionality.
  • Rule 3: new since last seen.
  • Smart agent generates an alert if information which is new, relative to the point in time at which a particular health care providing user last looked at the HIES.
  • FIG. 160 a is a table of an example set of presentation use cases.
  • FIG. 160 b is a table of an example set of context interception use cases.
  • FIG. 160 c is a table of an example set of system health use cases.
  • FIG. 160 d is a table of an example set of data preparation, configuration & deployment, and extension development use cases.
  • The high level architecture of a smart agent system constructed and operative in accordance with certain embodiments of the present invention is illustrated in the simplified functional block diagram of FIG. 154 a. The apparatus of FIG. 154 a may include some or all of:
  • 1. VPO analyzer—an addition to the VPO Web Services. is typically operative to filter and highlight pieces in the VPO which are considered important to be presented. It is typically based on GetVPO functionality and rules on those.
    2. SmartAgent application. A client-installed application. Typically comprises some or all of:
    a. SmartAgentHost—a windows try application that connects all the dots on the client machine
    b. SmartAgentPresentation—SmartAgent presentation Module (WPF) application
    c. Context interception library—Library Screen capturing interfaces. Its job is to capture events from EMR application such as patient context, and pass it on to the SmartAgentHost.
  • Certain user context interception sequences, some or all of which may be included in the model, are illustrated in the diagram of FIG. 161, which includes an Interaction example—User context interception sequence. FIG. 161 and other figures herein are generated in Enterprise Architect UML format; it is appreciated that this does not limit the scope of the invention and is merely utilized as one possible format for demonstrating one possible example set of data structures and computerized processing methods useful for implementing the present invention.
  • An example use case model is now described with reference to FIGS. 162, 163 a-163 c, 164-166.
  • A Use Case Model Overview (Use Case diagram) is illustrated in FIG. 162. “Perspective” Overviews are illustrated in FIGS. 163 a and 163 b including an actors overview diagram and a use case context diagram, respectively.
  • Regarding the configuration and deployment functionality of FIG. 162:
  • Configure & Personalize presentation options may include, inter alia: Presentations Skins Vs EH.R., Presentation rules and Base query, each of which is now described in detail according to respective embodiments of the present invention:
  • Presentation skins refers to an ability to customize the SmartAgent application appearance to have a plurality of different “look and feel”s. Typically, end users want the EMR agent to appear on top of a given EMR with a look and feel which is similar to that of the EMR.
  • Presentation Rules—refers to how the SmartAgent behaves to a given attention rule result—such as blinking frequency of alerts, or whether to blink and/or to expand the SmartAgent to view Clinical Data.
  • Base Query refers to filtering to obtain a VPO. Filtering can be by Time, or which clinical Aspects to obtain (e.g. filter to obtain only labs, or All Clinical Aspects).
  • For the “deploy updates to agent” use case, the system may update to the smart agent applications scattered all over the network (and out of network for community clinics). The smart agent may be installed on any suitable platform, such as a Citrix box. For the “install agent on Citrix box” use case, setting up the agent may be controlled by configuring Citrix sessions, or by network login script.
  • A Context Interception (Use Case diagram) is illustrated in FIG. 163 c, which is suitable for implementing the context interception functionality of FIG. 162. Context interception may include identification, e.g. as described below, of some or all of: (a) application, (b) patient e.g. as per FIG. 164 described herein, (c) user, e.g. as per FIG. 167 described herein, (d) workflow context, (e) patient interaction, (f) user-managed user interactions, e.g. as per FIG. 167 described herein, and (g) user details e.g. as per FIG. 166 described herein. User identification may include interception of the users' details, and interception of user-managed user interactions.
  • Re “Identify Application” use case shown in FIG. 162: In this UC the system intercepts the application (EMR) which the user is using. For example, is the user working with Allscripts MyWay, Cerner etc. This context may be captured from the EMR screen or provided by the EMR. This same application can be used for multiple instances. For example a Cerner app may be used in different “regions” in UPMC—Cerner H1, H2, H3. The instance may be used when applying content rules such as “exclude mine”.
  • Re “Identify Patient” use case shown in FIG. 162: In this UC the system intercepts the patient that the user is currently looking at in the EMR. This context may be captured from the EMR screen or provided by the EMR.
  • Re additional “Identify Patient” use case shown in FIG. 162: In this UC the system intercepts the patient that the user is currently looking at in the EMR. This context may be captured from the EMR screen or provided by the EMR.
  • FIG. 164 is a Sequence diagram of an “Identify Patient” Interaction.
  • Re the “Identify User” use case shown in FIG. 162: In this UC the system intercepts the user that is using the EMR in order for the health information exchange system (HIES) to present data to that user, according security privileges as configured in the EMR. This context may be captured from the EMR screen or provided by the EMR.
  • FIG. 166 is an Activity diagram of an “Intercept User Details” functionality.
  • FIG. 167 is a Use Case diagram of an “Identify User” functionality which is useful e.g. in conjunction with the “Identify User—managed users Interaction” use case shown in FIG. 162.
  • Re the “Identify Workflow Context” use case shown in FIG. 162: In this UC the system intercepts the workflow in which the user is on the EMR side. For example, is the user on “labs” tab or on “medication” tab? This context may be captured from the EMR screen or provided by the EMR. An advanced scenario here is responding to “free” selection on the screen, e.g. —user selects “Hgb” on the screen and history graph needs to be shown.
  • Turning now to the Data Preparation functionality in FIG. 162:
  • Re the “Apply Rules” use case: Typically, acting on patient data, the system decides which records are to be presented using attention rules e.g. as described herein. The system is typically able to add more rules and adjust existing rules. Example rules include: —“exclude my EMR data” and —“exclude what I saw”, also termed herein the “new since last seen” rule.
  • Re the “Prepare Patient Data for presentation” use case: typically, the system prepares data to be presented to the user. This includes fetching the data as well as filtering out irrelevant records, based on rules. This typically works in conjunction with the VPO analyzer of FIG. 1 a.
  • Re the Extension Developments functionality in FIG. 162:
  • The “Develop & Configure EMR support” UC typically describes a possible need of the system to grow and support new EMRs, new versions of known EMRs as well as customized versions of known EMRs. The support is focused on the interception of elements from the EMR screen.
  • Re the Presentation functionality in FIG. 162:
  • The “Control floating application state” may for example include Minimize, expand, size, position, dock, close etc. In the launch health information exchange system (HIES) Viewer UC the system acts merely as an entry point to the existing viewer (Clinical Viewer, Collaborate). The launch may or may not include context (user, patient, app). For example—navigation menu for medications (even though no medication record is currently shown). In the “Perform Search” UC the user searches for records within the patient record. The search can either be on the codified data, or free search over text (notes within acts and the content of clinical documents). In the “Present Clinician Data” UC the system presents data from the HIES that is not related to the patient viewed in the EMR. For example—“my recent events” from a Collaborate functionality in the HIES, “my admitted patients” and so on.
  • In the Present Patient Data UC the system presents patient data to the user. In the “Send To My EMR” UC the user selects act to be sent to his EMR and the system delivers them to the EMR to be presented there.
  • The GetVPO service of FIG. 162 is an Actor which represents clinical services or Web Services which provides the ability to query and retrieve Patient clinical Data.
  • An example Design Model is shown in FIG. 168. FIG. 169 is a logical diagram of the smart agent of FIG. 168.
  • FIG. 170 is a logical diagram of the context entities of FIG. 169. The context entities package may serve as the data contract of the event model between all components. EHRContext may comprise an entity (data) object representing the context of a specific EMR application. EHRApplicationDetails may represent the application (EMR) details as intercepted. EHRPatientDetails may represent the patient details as in the EMR intercepted. EHRUserDetails represents the user details in the EMR as intercepted.
  • The screen capturing functionality of FIG. 169 typically comprises a library that implements in an IOC (Inversion Of Control) implementation of the Screen capturing interfaces. Its job includes capture of events from an EMR application such as patient context, and passing the patient content on to the AgentHost of FIG. 169. FIG. 171 is a logical diagram of the ScreenCapturing functionality of FIG. 169.
  • The ScreenCapturingEHRContextInterceptor of FIG. 171 may comprise an interceptor based on conventional Screen Capturing technology which may operate the dlls and convert to .Net events as appropriate.
  • The ScreenCapturingEHRContextInterceptor of FIG. 171 may comprise any interceptor based on suitable Screen Capturing technology such as that commercially available from screenscraper studio, having a http presence on the world wide web at at: screen-scraper.deskperience.com// which is a software tool including a development kit that is capable of screen capturing actions.
  • The SmartAgentHost functionality of FIG. 19 typically is installed on the client machine, hosts the presentation layer and orchestrates the interaction between the presentation layer and the screen interception e.g. screen capturing.
  • A logical diagram of controllers is shown in FIG. 174. FIG. 174 illustrates the engine and the corresponding configurations that execute and orchestrate the various interceptors shown and described herein. Typically, the apparatus of FIG. 174 is useful in conjunction with the screen capturing functionality of FIGS. 169 and 171. FIG. 174 is particularly useful in understanding an example design of context interception, its classes and methods, and scenarios the context interceptor may support, such as but not limited to one or more of: user log-in, enter patient file, exit patient file, all according to certain embodiments of the invention. The diagram of FIG. 173 describes, for the above scenarios, an initial step of getting the context and passing it to an EMR agent, so as to call VPO services, search patient and security, all in accordance with certain embodiments of the invention.
  • Regarding the EHRContextManager of FIG. 174, it is typically the responsibility of this class to orchestrate the context switches, bridging between context interceptors, presentation parts, and windows events, such as but not limited to:
  • a. Pass on events to the presentation about patient, user, application and workflow context switches
  • b. Receive events from presentation such as user requests to hide\close\float the window and make sure to respond correctly to those events, for example by stopping the interceptors.
  • c. Make sure the window moves together with the EMR window.
  • The multiplicity of this class may be expected to be one per EMR window instance. (e.g. two Cerner windows would be assigned with two different context managers.
  • Operations, some or all of which may be performed by the InterceptorsFactory functionality of FIG. 174, are set out in the table of FIG. 175.
  • The RuntimeManager of FIG. 174 typically hosts the entire system. Its responsibilities include some or all of the following:
  • 1. Manage (start\stop\monitor) the different managers.
  • 2. Orchestrate the process of discovering new EMR window, creating a ContextManager and context interceptor for it.
  • A logical diagram of ContextInterception is illustrated in FIG. 176. The InterceptorConfiguration of FIG. 178 typically comprises an object which may be delivered to each interceptor when it is started. The configuration is stored and controlled. The InterceptorConfiguration may hold a configuration of the Interceptor in the context of the EMR it intercepts. An example configuration is as follows:
  • a. Connection to server
    To allow an EMR Agent work with a database such as a dbMotion database an address of the server, e.g. dbMotion server, is typically set up. The Server address is typically a URL which may for example have an http: prefix followed by, say: //ApplicationServer:9150/dbMotion/SmartAgent
    b. View shell window position:
      • EMR Agent shell window position may be defined relatively to EMR application window. The View can be anchored to one of the sides of EMR window. Suitable parameters may specify relative position such as some or all of the following parameters as defined in FIG. 184:
      • EMR angle—angle of EMR window to be used as a start point for computing View position
      • View angle (Shell angle)—angle of View to be positioned relatively to EMR angle
      • Horizontal offset—horizontal offset of View angle from EMR angle (can be negative to position View angle to the left from EMR angle)
      • Vertical offset—vertical offset of View angle from EMR angle (can be negative to position View angle above EMR angle)
      • Each time EMR window position or size is changed, EMR Agent typically updates corresponding shell window position e.g. according to the parameters above.
      • View position parameters may be specified in a InterceptionConfig.xml file under a ShellConfig tag. Here is an example of suitable ShellConfig values:
  •
    <ShellConfig
    EhrAngle=“RightTop” ShellAngle=“RightTop”
    HorizontalOffset=“10” VerticalOffset=“10” />
      • These parameters may be specified per EMR.
        c. SmartAgent Floating Application Attention rules may be as follows:
      • The EMR Agent view title area may be used to notify the user when context dependent data is delivered to the Agent from a suitable database e.g. dbMotion database. The notification may have some or all of the following 3 parameters:
      • Blinking number—how many time title area blinks after some data is delivered
      • Blinking rise time—duration of each blink
      • Blinking pause time—delay between blinks
      • These parameters can be changed in a suitable file e.g. “dbMotion.SmartAgent.Client.Viewer.dll.config”. There follows an example fragment of the configuration file with default values:
  •
    <setting name=“BlinkingNumber” serializeAs=“String”>
    <value>5x</value>
    </setting>
    <setting name=“BlinkingRiseTime” serializeAs=“String”>
    <value>00:00:00.2000000</value>
    </setting>
    <setting name=“BlinkingPauseTime” serializeAs=“String”>
    <value>00:00:00</value>
    </setting>
  • These parameters may be specified globally.
  • The IEHRContextInterceptor of FIG. 178 is an interface; the responsibility of implementer of this interface typically includes discovery of context changes to a given EMR window instance. The window's assigned context manager may be subscribed to the interceptor's events.
  • The IEHREventInterceptor of FIG. 178 typically comprises an “abstract” interface which only defines the minimal requirements.
  • The IMpl package of FIG. 178 includes out-of-box interception capabilities focused on interception of some or all of: application launch, application position change, internal proxies to external interceptors, including, e.g. active EMR or screen capturing vendor.
  • Regarding the IEHRLaunchIncerceptor functionality of FIG. 178, the responsibility of the implementer of this interface is to intercept the event of launching a known EMR application. Once launched, a dedicated EHRContextInterceptor may be created to the specific window.
  • The runtime manager may be subscribed to the OnApplicationOpened event.
  • The IEHRWindowStateInterceptor of FIG. 178 typically comprises an interface operative to allow the application to stick into the EMR window and track it as it moves.
  • Referring again to FIG. 168, the VPOAnalyzer is an addition to the VPO “family” e.g. clinical data services as described herein and is operative to filter and highlight important pieces in the VPO to be presented. It is based on GetVPO functionality and rules pertaining to that functionality, typically including some or all attention rules applicable to the patient clinical data retrieved as described herein in detail.
  • Example Framework and Contracts pertaining to the VPOAnalyzer may be appreciated with reference to FIG. 177. The AnalyzedPatientRecord of FIG. 177 typically provides a Data Contract for the VPO analyzer of FIG. 154 a, containing the VPO as well as the markup—the highlighted elements of the VPO. The AnalyzerRuleHighlights of FIG. 177 typically holds the VPO markup highlights for an analyzer rule. The HighlightedElement of FIG. 177 typically allows the rule to mark \ highlight VPO elements to be presented according to their logic, for example—those that do not come from a given EMR. The SystemIdentity of FIG. 177 typically comprises a data contract package which may optionally be part of PPOL of FIG. 168.
  • FIG. 178 is an example Logical diagram for the SystemIdentity functionality of FIG. 177.
  • Service & business layers may include the apparatus shown in the logical diagram of FIG. 179. The IVpoDataSource of FIG. 179 may comprise an interface which abstracts away the details of how the VPO is retrieved. A BAC-based data source for deployment outside “business” areas is provided and a business-agent version may be used when integrated into business access services hence it can utilize internal features. The SystemLinksManager of FIG. 179 may be part of the PPOL of FIG. 15 and typically comprises a manager responsible of providing configuration of system links and the relation between them. The VPOAnalyzerManager of FIG. 179 may comprise a manager\controller responsible of orchestrating the VPO analysis process.
  • FIG. 180 is an example logical diagram of the rules functionality of FIG. 179. The AnalyzerRuleFactory functionality of FIG. 180 typically comprises a singelton class, serving as a factory for analyzer rules, based on configuration. The configuration may be based on CareManagement suite, which in turn may allow configuring different profiles and personalization. The CareEventsGetterRule functionality of FIG. 180 typically comprises an analyzer “rule” which gets CareEvents based on a CareEvents query (which events are of interest? how far back?). It may merge its results to the upper level. The OutsideEHRRecordsRule functionality of FIG. 180 typically comprises an analyzer which highlights those records which are out of reach in a given EMR. The rule may be based on system links configuration, which may be part of the PPOL of FIG. 168. The UnseenRecordsVPOAnalyzerRule functionality of FIG. 180 typically highlights those records the user have not seen yet, based on information about entry to health information exchange system (HIES) applications, for example PLV records. The VPOGetterRule functionality of FIG. 180 typically comprises an analyzer “rule” which is based on VPO query and a set of child analyzer rules which further analyze the fetched VPO. The VPOGetterRule functionality of FIG. 180 typically merges its results to the upper level.
  • An example Use Case (UC) Realization process is illustrated in the Identify Patient UC realization sequence diagram of FIG. 181. An example server operative to Identify Patient UC realization is illustrated in the sequence diagram of FIG. 182.
  • A particular advantage of certain embodiments of the present invention is that the EMR's code need not be changed because the apparatus of the present invention is able to intercept whatever context it employs from the EMR. Any suitable method may be employed for intercepting EMR context, such as but not limited to:
  • a. use of a context management protocol such as CCOW.
    b. screen capturing (also termed herein “screen scrapping”)
    c. providing a specialized context interception adaptor, also termed herein “interceptor” for a particular EMR taking advantage of a specific context sharing capability which that particular EMR has. Typically, the architecture of the system shown and described herein includes one or more adaptors for context interception also termed herein “interceptors”, e.g. as shown in FIG. 176, and therefore any such special adaptor can easily be incorporated into the architecture of the system shown and described herein, as an additional or substitute adaptor in FIG. 176.
  • “Manual Intervention” typically includes a set of features in the Smart Agent which enable the system to locate, within a patient record, an item of information that may be relevant for the end user in the context of the workflow. As an example, a health provider-user may be prescribing a new medication to the patient. According to certain embodiments, capturing the prescribed medication enables to search for a drug interaction or an allergy within the HIE patient record. It is appreciated that finding the relation between the prescribed medication in a given EMR and the ability to identify kind of relations to other clinical artifacts within the patient record, are not trivial, e.g. because the clinical concepts terminology is unknown to the HIE. Also, since the terminology used for the medication is unknown, there may be no ability to manage the relations to other clinical concepts.
  • The CTS subsystem of dbMotion's commercially available health information exchange system typically provides capabilities that make intervention in the EMR based on local terminology possible, including one or more of the following, all e.g. as described herein with reference to any or all of FIGS. 2-3 and 27-39:
      • 1. The dbMotion CTS maintains semantic and/or ontological relationships between Local EMR terminologies to a basic ontology e.g. as employed by dbMotion.
      • 2. The dbMotion Ontology contains relationships, e.g. of medication concepts and their related contra medications. Also, allergy clinical ontology concepts are related to relevant medication clinical concepts.
      • 3. The CTS facilitates handling of ontology relations (e.g. relations between clinical concepts), typically by using only a single, given, pre-defined medical terminology, while “translating” all terms or codes in all other medical terminologies into and out of the given terminology. All ontological relationships are represented in terms of, and typically only in terms of, the given medical terminology. For example, the code that corresponds to Medication of Penicillin typically has a relation in the ontology to many other clinical concepts which also pertain to Penicillins, such as side effects thereof. In this context, the CTS facilitates querying for all the Penicillins ontology clinical concepts, using a given terminology's clinical concept. In summary, while many medical terminologies each include a multiplicity of medical codes, and terms may be supported by the systems shown and described herein, typically, ontological/semantic relationships between concepts are represented (e.g. only as) relationships between terms in the pre-defined medical terminology; whereas ontological/semantic relationships between terms, say, A and B, within a medical terminology X other than the pre-defined medical terminology (also termed herein “the ontology”) are derived by translating both A and B from terminology X into the pre-defined medical terminology, and identifying any semantic relationships between the translations of these. Typically, even if new relationships which are imported into the system are expressed in terms of a medical terminology X other than the pre-defined medical terminology, nonetheless, the relevant terms in X are first translated into the pre-defined medical terminology, so as to express the new relationships solely in terms of the pre-defined medical terminology, and only then, the new relationships, so expressed, are saved for future use.
      • An example CTS functionality is described above with reference to FIGS. 18A-105. A commercially available CTS functionality is provided in DBmotion's E.H.R. product. Embodiments of CTS functionality are also described below.
  • If some or all of features 1-3 above are provided, the SmartAgent is typically operative to present the user with an alert on an allergy to a prescribed medication by intercepting the medication name, locating its concepts in the CTS terminology as a local concept, locating the baseline ontology concept it relates to, locating the related ontology concepts of allergy and, using a given VPO, resolving if an individual patient meets this intervention rule. This is an example of use of the semantics framework provided in the commercially available dbMotion health information exchange system, in order to perform workflow context interception.
  • Embodiments of CTS functionality are now described:
  • While there is value in bringing together data from multiple source systems into a unified virtual patient record with each source-system providing data using its own “local terminology” codes, there are many limitations in viewing the resulting hodge-podge of terminologies. By converting all the data into a common set of standards-based codes, using CTS functionality, the results are much more meaningful.
  • The term Semantic Interoperability refers to the ability to translate data from multiple and varied Healthcare IT systems and then to organize such data in a meaningful way for display and analysis. This facilitates creation of a meaningful “virtual patient record” comprised of data from multiple source systems that can still be coherently organized and understood. Semantic Interoperability facilitates assimilation of data that originated in one system, into a different system.
      • The Semantic Interoperability capabilities may have some or all of the following target audiences:
      • End users who benefit from the meaningful translation of data to a common terminology set and the organization of the data in a meaningful way.
      • Vocabulary administrators tasked with maintaining the code sets used by an organization's healthcare IT systems and the mapping/translation between them.
      • Data experts responsible for understanding and leveraging data stored in a HIE system.
      • SDK developers who need to create applications that access semantically harmonized data.
  • Terminology of Semantic Interoperability used herein includes:
      • Code Set Mapping: Translation among code sets associated with various Healthcare IT data encoding standards. There are a variety of code sets commonly used by various vendor systems. For example, one EMR might encode medications using the Medispan code set, while another will use the NDC code set, another the Multum code set, and still another the RxNorm code set. Similar differences (with different sets of alternate standards) are found in the code sets used for Conditions, Labs, Immunizations, Allergies, Diagnoses, etc. Even when a common code set is used by two systems, there are often differences in the versions of the code set, and in the subset of codes actually used from within the standard code set. Moreover, even when sharing a code-set and version, there can be specific customizations and variations used by different organizations or departments.
      • Semantic Ontology: A set of code sets (typically including versions and subsets) used to store clinical/administrative data, together with defined relationships among the various codes that are represented and managed. An ontology includes relationships between data elements, as opposed to mere translating of varying code sets used to represent data in clinical or administrative domains. Relationships may include “grouping” (e.g. the fact that a large set of RxNorm codes for various forms of Penicillin can all be grouped together in certain contexts e.g. from a point of view of side-effects or indications), and/or inter-relationships (contradictions, interchangeability, etc.). Relationships can be within one administrative/clinical domain (e.g. the therapeutic classes of medications) or across domains (e.g. a relationship between a condition and the medication used to treat it).
  • Baseline Ontology and Local Terminologies: An HIE e.g. that commercially available from DBMotion, may be pre-configured with a Baseline Semantic Ontology (also termed herein a Baseline Ontology). The pre-configured or “out of the box” (OOB) Baseline Ontology can be customized and configured by a user. The Baseline Ontology typically represents a common language into which all data aggregated from source systems by dbMotion is translated (“Local to Baseline Translations”) and from which it is again translated (“Baseline to Local Translation”), if required, in the course of semantically meaningful data export (termed herein “semantic export”) to a destination system in a way that is consistent with the terminology used by that destination system. The terminologies used by the source systems and the destination systems are termed herein Local Terminologies.
  • Typically, the Baseline Ontology is also used to group data and optionally to enable at least one of decision support, alerting, and population management.
  • When doing Local to Baseline Translation, a record of the original Local Terminology encoding is typically maintained for reference. It may then be a configurable option whether data is displayed in Local Terminology, Baseline Ontology, or both.
    According to some embodiments, the HIE does not import/export information about the relationships between codes: The Local to Baseline Translations and the Baseline to Local Translations are concerned only with mapping terminology (codes). The broader Semantic Ontology is exclusively in the Baseline Ontology—it can be customized if desired, but it is not impacted by the source or destination systems that are interconnected by the HIE system.
    • Vocabulary Manager to Common Terminology Service
  • HIE's Semantic Interoperability may be provided by a Vocabulary Manager (VM) sub-system. Terminology translation support may be limited to one-way translation (Local to Baseline Translation) and Semantic Ontology may be limited to basic grouping capabilities.
  • A Common Terminology Service (CTS) may alternatively or in addition provide Semantic Interoperability by providing a Semantic Ontology functionality that provides both translation services and semantic relationship knowledge services throughout the HIE.
  • In commercially available dbMotion HIE's Release 4.2, CTS services are used by components associated with the dbMotion Collaborate application, as well as by Semantic Export capabilities introduced in the context of the Allscripts Community Record features powered by dbMotion Release 4.x. Some modules may utilize an earlier dbMotion Vocabulary sub-system. A CTS Synchronization Service enables the CTS to co-exist side by side with a Vocabulary Manager system. The CTS Synchronization Service may synchronize a newer CTS Baseline Ontology with the Vocabulary Manager system (CTS to VM) and also synchronize Local Terminology mappings managed within the VM with the CTS (VM to CTS).
  • If there are Baseline codes that are not part of the Baseline Ontology (referred to as Proprietary Baseline Terminologies), these are typically mapped to the CTS Baseline Ontology concepts using a structured Baseline Mapping file provided by the HIE.
  • A CTS may support inter alia any or all of the following use-case scenarios:
  • Semantically harmonize aggregated medical/administrative data from multiple source systems e.g. by translating the source system local terminology to the Baseline Ontology (Local to Baseline Translation), as well as by using the Baseline Ontology to hierarchically organize certain data areas to facilitate grouping, filtering and sorting features.
  • Semantically export data from the virtual patient record and its Baseline Ontology to the Local Terminology used by a destination system (e.g. a particular EMR) (Baseline to Local Translation).
      • Maintain bi-directional mapping between different Local Terminologies and the terminology used by the (dbMotion e.g.) Baseline Ontology.
      • Provide services and infrastructure for semantic navigation capabilities e.g. by using associations between various concepts belonging to different clinical domains (e.g. a Lab test related to an Allergy, related to a contra Medication).
        CTS may use either or both of the following Semantic Content Types:
        Baseline Ontology, which includes:
      • The baseline terminology—selection of code sets (typically including the version and sub-set of codes used) for all relevant clinical/administrative domains; and
      • relationships (primarily hierarchy/grouping relationships) among those codes within and across domains.
        Terminology Maps: bi-directional code mappings from Local Terminology sets to the terminology of the Baseline Ontology.
        Some mappings are provided pre-configured and are referred to as “out of the box” (OOB) mappings. Additional customer-specific mappings and/or modifications to the OOB terminology maps may be provided to match the specific usage of a given Local Terminology by a given customer source system. The HIE may automatically identifies unmapped codes that it encounters.
  • The Baseline Ontology Terminology may for example be assembled by combining selected sub-sets of different well-known standard terminology systems (SMONED, RxNorm, LOINC, etc). The specific subset of codes in the Baseline Ontology from within a given standard may be selected based on suitable criteria such as but not limited to some or all of the following:
      • Based on concepts most frequently used concepts by EMRs
      • Based on anticipated Ontology use cases (such as concepts related to Diabetes)
      • Compliancy with pre-defined requirements
  • The Table of FIG. 185 a is an example of origins of Baseline Ontology Terminology Components in an example HIE (the DBMotion HIE).
  • The Baseline Ontology Relationships or concept-relationship aspect of the Baseline Ontology may be maintained using a suitable toolset for ontology management such as OWL (Web Ontology Language), endorsed by the Worldwide Web Consortium (W3C).
  • Relationships supported in the CTS may for example include some or all of the following:
  • Classification (Hierarchy):
      • PARENT_CLASS_OF: A concept that is the Parent of a related classification concept.
      • SUB_CLASS_OF: A concept that is the Child of a related classification concept.
  • Mapping:
      • EQUALS_TO: Equivalent meaning of two concepts.
  • Cross domain relations:
      • VACCINE_AGAINST: Cross domain relation. An Immunization concept that should prevent/immunize against the related condition concept.
  • Inner domain relations:
      • RxNorm
        • INGREDIENT_OF: An ingredient concept is the content of the related medication concept.
        • HAS_INGREDIENT: A medication concept has the related ingredient concept.
      • SNOMED
        • HAS_FINDING_SITE: A site concept for where the related condition occurs.
        • HAS_CAUSATIVE_AGENT: A disease concept is caused by the child causes.
  • In order for the CTS to provide its translation services, it may be supplied with Terminology Maps for translating bi-directionally between the Local Terminologies used by various source and destination healthcare IT systems and the Baseline Ontology. The CTS may for example be pre-configured with a set of OOB (out-of-the-box) Terminology Maps that map between Local Terminologies used by Allscripts EMRs and the Baseline Ontology. Examples of such maps, e.g. for the DBMotion HIE, are set out in the table of FIG. 185 b.
  • Any or all of the following methods may be supported for building Terminology Maps:
      • OOB Terminology Maps: Terminology maps can be purchased or developed, using conventional Terminologies consultancy techniques, and provided as OOB (out-of-the-box) Terminology Maps.
      • Customer Provided Terminology Maps: A Vocabulary Manager sub-system of the HIE may include an “Import Tool” that can import Excel-based Terminology Maps provided by customers. These may then be automatically synchronized to the new CTS sub-system.
      • Surfacing of Unmapped Codes: During the data aggregation process, a Vocabulary Manager sub-system may automatically surface unmapped codes that it encounters and provide a facility for mapping them to the Baseline Ontology.
      • Semantic Interoperability may facilitate Semantic Export. Semantic Interoperability may make it easier to view aggregated data within a Clinical Viewer even if it only worked “one way” (from the terminology of a source system to our common baseline terminology). A CTS typically however provides full round-trip translation services, allowing the HIE to move data from one system to another in a meaningful way e.g. by providing Semantic Export capabilities into Allscripts EMRs. Data that flows into an Allscripts EMR via a Allscripts Community Record solution can be displayed in the “language” of that EMR, regardless of the source system from which it came.
  • Semantic Interoperability typically provides a “central hub” type system as opposed to “myriad point-to-point” systems. Rather than creating mappings between every potential pair of relevant terminology code sets, a standards-based baseline may be provided from which and to which everything is translated. This means that far fewer mappings are used to translate “anything to anything”. Analogous is the difference between using a dictionary to translate every language to and from every other language and using just one dictionary (per each of n languages) from each language into a “universal common language” and back, which effectively translates between any 2 languages.
  • A difference between Terminology Services and Ontology Services is that Terminology typically is limited to translating codes from one set to another, whereas Ontology also refers to relationships between those codes e.g. the hierarchy/grouping relationship that enables grouping together clinically related medications, allergies, etc. “Ontology relationships” may also be defined to enable a CTS to respond to a query such as “give me all the medications, conditions, and lab tests associated with Diabetes”. When an HIE operates exclusively through a central Baseline Ontology, the HIE can define these relationships only once in the terminology of the Baseline Ontology and can then use the relationships for any Local Terminology used by any other source system.
  • According to some embodiments, Semantic Interoperability is not “point-to-point”. Thus, instead of mapping from and to every possible combination of source and destination code sets, only one mapping is performed, from any source/destination code set to/from the Baseline Ontology.
  • According to some embodiments, Semantic Interoperability is not limited to “terminology services” and instead provides an “ontology” of relationships between concepts within a given clinical domain (e.g. a hierarchy of medications), as well as across clinical domains (e.g. all medications, conditions, and labs associated with Diabetes).
  • According to some embodiments, Semantic Interoperability focuses on most frequently used codes and most important, as pre-defined relationships among codes. This allows efficient investment in maintaining mappings and reducing the almost infinite potential task of “mapping everything” to a manageable mapping agenda.
  • One implementation of the CTS (Common Terminology Services) functionality described herein is the dbMotion HIE's software module that powers its Semantic Interoperability capabilities.
  • FIG. 186 is a simplified functional block diagram illustration of an embodiment of the invention showing a smart agent which may be constructed and operative in accordance with any of the embodiments shown and described herein, operative in conjunction with an HIE which may comprise any conventional HIE such as but not limited to DBMotion's HIE; and one or more conventional EMRs (E.H.R.'s).
  • The smart agent of FIG. 186 may include a client and server as shown; however, functionalities of these two may be interchanged as desired. Any suitable functional connection between the SmartAgent and the Entity Identity Management (EMPI) may be provided such as that described above with reference to FIGS. 164 and/or 168. Any suitable functional connection between the SmartAgent and Security Services may be provided such as that described above with reference to FIGS. 167 and/or 168. Any suitable functional connection between the SmartAgent and Patient Data Services may be provided such as that described above with reference to FIG. 168. Any suitable interceptors may be employed such as the Context Interceptor processor described above with reference to FIG. 166. The Client may be based in part on the apparatus of FIG. 169 including the ScreenScraping functionality which may include a context interceptor, SmartAgent Host and SmartAgent presentation client as described herein. The SmartAgent Client may optionally be based on the Context Interceptor described hereinabove with reference to any or all of FIGS. 170, 174 and 176. A suitable object model of the context which the context interceptor API of FIG. 186 may employ, is described above with reference to FIG. 170. The Web service component of the server may for example comprise the SmartAgent Presentation Server of FIG. 169 as described above. The VPO analyzer component of the server may for example be implemented in accordance with the apparatus of FIG. 177.
  • It is appreciated that terminology such as “mandatory”, “required”, “need” and “must” refer to implementation choices made within the context of a particular implementation or application described herewithin for clarity and are not intended to be limiting since in an alternative implantation, the same elements might be defined as not mandatory and not required or might even be eliminated altogether.
  • It is appreciated that software components of the present invention including programs and data may, if desired, be implemented in ROM (read only memory) form including CD-ROMs, EPROMs and EEPROMs, or may be stored in any other suitable typically non-transitory computer-readable medium such as but not limited to disks of various kinds, cards of various kinds and RAMs. Components described herein as software may, alternatively, be implemented wholly or partly in hardware, if desired, using conventional techniques. Conversely, components described herein as hardware may, alternatively, be implemented wholly or partly in software, if desired, using conventional techniques.
  • Included in the scope of the present invention, inter alia, are electromagnetic signals carrying computer-readable instructions for performing any or all of the steps of any of the methods shown and described herein, in any suitable order; machine-readable instructions for performing any or all of the steps of any of the methods shown and described herein, in any suitable order; program storage devices readable by machine, tangibly embodying a program of instructions executable by the machine to perform any or all of the steps of any of the methods shown and described herein, in any suitable order; a computer program product comprising a computer useable medium having computer readable program code, such as executable code, having embodied therein, and/or including computer readable program code for performing, any or all of the steps of any of the methods shown and described herein, in any suitable order; any technical effects brought about by any or all of the steps of any of the methods shown and described herein, when performed in any suitable order; any suitable apparatus or device or combination of such, programmed to perform, alone or in combination, any or all of the steps of any of the methods shown and described herein, in any suitable order; electronic devices each including a processor and a cooperating input device and/or output device and operative to perform in software any steps shown and described herein; information storage devices or physical records, such as disks or hard drives, causing a computer or other device to be configured so as to carry out any or all of the steps of any of the methods shown and described herein, in any suitable order; a program pre-stored e.g. in memory or on an information network such as the Internet, before or after being downloaded, which embodies any or all of the steps of any of the methods shown and described herein, in any suitable order, and the method of uploading or downloading such, and a system including server/s and/or client/s for using such; and hardware which performs any or all of the steps of any of the methods shown and described herein, in any suitable order, either alone or in conjunction with software. Any computer-readable or machine-readable media described herein is intended to include non-transitory computer- or machine-readable media.
  • Any computations or other forms of analysis described herein may be performed by a suitable computerized method. Any step described herein may be computer-implemented. The invention shown and described herein may include (a) using a computerized method to identify a solution to any of the problems or for any of the objectives described herein, the solution optionally include at least one of a decision, an action, a product, a service or any other information described herein that impacts, in a positive manner, a problem or objectives described herein; and (b) outputting the solution.
  • Features of the present invention which are described in the context of separate embodiments may also be provided in combination in a single embodiment. Conversely, features of the invention, including method steps, which are described for brevity in the context of a single embodiment or in a certain order may be provided separately or in any suitable subcombination or in a different order. “e.g.” is used herein in the sense of a specific example which is not intended to be limiting. Devices, apparatus or systems shown coupled in any of the drawings may in fact be integrated into a single platform in certain embodiments or may be coupled via any appropriate wired or wireless coupling such as but not limited to optical fiber, Ethernet, Wireless LAN, HomePNA, power line communication, cell phone, PDA, Blackberry GPRS, Satellite including GPS, or other mobile delivery. It is appreciated that in the description and drawings shown and described herein, functionalities described or illustrated as systems and sub-units thereof can also be provided as methods and steps therewithin, and functionalities described or illustrated as methods and steps therewithin can also be provided as systems and sub-units thereof. The scale used to illustrate various elements in the drawings is merely exemplary and/or appropriate for clarity of presentation and is not intended to be limiting.

Claims (25)

1. A method for using a health information exchange system which stores patient record data regarding a multiplicity of patients, to serve a first plurality of EMRs each interacting with an EMR community including a set of at least one EMR, the method comprising:
for each individual EMR within said first plurality of EMRs, performing a computerized context interception process using a processor to intercept context from the individual EMR and to identify therewithin an event whereby a health provider using said individual EMR calls up an individual patient's record from said individual EMR; and
responsive to identification of said event, using a computerized output device for providing patient record data, pertaining to said individual patient, to said health provider.
2. A method according to claim 1 wherein said patient record data includes at least one information item which is tagged to indicate a source EMR which provided said information item to said health information exchange system and wherein said patient record data provided to said health provider is filtered so as to filter out said at least one information item if said information item's source EMR equals said individual EMR.
3. A method according to claim 1 wherein said intercepting and identifying includes using a context management protocol.
4. A method according to claim 3 wherein said context management protocol comprises CCOW.
5. A method according to claim 1 wherein said health provider is served by a display screen when using said individual EMR and wherein said identifying includes capturing information from said display screen.
6. A method according to claim 1 wherein said identifying includes:
pre-storing a patient identifier location for each EMR within said first plurality of EMRs; and
capturing said individual patient's patient identifier from said patient identifier location.
7. A method according to claim 1 wherein said providing patient record data includes subscribing to events exchanged between the individual EMR and an operating system serving the EMR, ascertaining in real time at least one current EMR display operation and mimicking the EMR display operation when providing the patient record data.
8. A method according to claim 7 wherein said EMR display operation comprises at least one of a translation along a display screen, a minimization of size and a maximization of size.
9. A method according to claim 1 wherein said intercepting and identifying includes screen-capturing EMR context.
10. A method according to claim 5 wherein said patient record data includes at least one information item which is tagged to indicate a category of information to which said information item pertains,
and wherein said capturing includes capturing screen information indicative of a category of information currently being viewed by the health provider,
and wherein said patient record data presented to said health provider is filtered so as to filter out said at least one information item pertaining to a category of information other than the category of information currently being viewed by the health provider.
11. A method according to claim 10 wherein said category of information includes at least one of the following group of categories: laboratory information, medicines, allergies, procedures, vital signs, pathologies, imaging results, clinical documents, immunizations, problems, and diagnosis.
12. A method for using a health information exchange system, storing patient record data regarding a multiplicity of patients, to serve a first plurality of EMRs each interacting with an EMR community including a set of at least one EMR, the method comprising:
for each individual EMR within said first plurality of EMRs, using a processor to automatically identify an event whereby a health provider using said individual EMR calls up an individual patient's record from said individual EMR; and
using a processor to apply at least one predetermined rule involving intercepted EMR context and using a computerized output device to provide an alerting indication drawing the health provider's attention to at least some of said patient record data according to said predetermined rule.
13. A method according to claim 12 wherein said generating an alerting indication comprises presenting patient record data, pertaining to said individual patient, to said health provider.
14. A method according to claim 12 wherein said predetermined rule comprises alerting said health provider's attention if said patient record data includes at least one item of information not included in said individual EMR.
15. A method according to claim 12 wherein said rule involves health-provider specific context and wherein said applying includes identifying said health provider's identifier.
16. A method according to claim 14 wherein items of information included in said patient record data are stored in computerized storage, in association with respective information source tags indicating an information source supplying each said item, and wherein a determination is made, based on said information source tags, of whether or not said patient record data includes at least one item of information not included in said individual EMR.
17. A method according to claim 16 wherein a list of information sources supplying an individual EMR is stored in computerized storage and wherein said determination includes determining whether all items in said patient record data are supplied by one of said individual EMR, and an information source appearing in the list of information sources supplying the individual EMR.
18. A method according to claim 15 wherein said predetermined rule comprises alerting said health provider's attention if said patient record data includes at least one item of information which was not seen by the health provider identified by said identifier when he was last served by said health information exchange system.
19. A method according to claim 15 wherein said identifying said health provider's identifier employs single-sign-on authentication of said health provider.
20. A method according to claim 15 wherein said identifying said health provider's user name includes capturing said health provider's identifier from a screen display employed by said health provider.
21. A method according to claim 1 wherein said intercepting and identifying includes providing an architecture which interacts with at least one context interception adaptor and, when operating in conjunction with a specific EMR having a specific context sharing capability, using an adaptor adapted to utilize said specific context sharing capability as said context interception adaptor.
22. A method according to claim 1 wherein said context intercepted includes an indication of at least one display characteristic characterizing a graphic user interface being generated by the EMR and wherein said providing patient record data includes generating a graphic user interface for displaying said patient record data which shares said display characteristic.
23. A method according to claim 22 wherein said at least one display characteristic includes at least one of: a color characteristic, a texture characteristic, a text font, a text size, and a characteristic of an icon such as a button.
24. A system for using a health information exchange system, storing patient record data regarding a multiplicity of patients, to serve a first plurality of EMRs each interacting with an EMR community including a set of at least one EMR, the system comprising:
a record-call up identifying processor operative, for each individual EMR within said first plurality of EMRs, to automatically identify an event whereby a health provider using said individual EMR calls up an individual patient's record from said individual EMR; and
an intercepted context rule applying processor applying at least one predetermined rule involving intercepted EMR context and controlling a computerized output device to provide an alerting indication drawing the health provider's attention to at least some of said patient record data according to said predetermined rule.
25. A system for using a health information exchange system which stores patient record data regarding a multiplicity of patients, to serve a first plurality of EMRs each interacting with an EMR community including a set of at least one EMR, the method comprising:
a record-call up identifying processor operative, for each individual EMR within said first plurality of EMRs, for performing a computerized context interception process using a processor to intercept context from the individual EMR and to identify therewithin an event whereby a health provider using said individual EMR calls up an individual patient's record from said individual EMR; and
a record-call up identifying processor-driven output device controller operative, responsive to identification of said event, to control a computerized output device for providing patient record data, pertaining to said individual patient, to said health provider.
US13/208,417 2010-07-21 2011-08-12 System and methods for facilitating computerized interactions with emrs Abandoned US20120215560A1 (en)

Priority Applications (9)

Application Number Priority Date Filing Date Title
US13/208,417 US20120215560A1 (en) 2010-07-21 2011-08-12 System and methods for facilitating computerized interactions with emrs
US14/145,903 US10325335B1 (en) 2010-07-21 2013-12-31 Facilitating computerized interactions with EMRs
US14/145,906 US10733684B1 (en) 2010-07-21 2013-12-31 Facilitating computerized interactions with EMRs
US14/145,908 US10789662B1 (en) 2010-07-21 2013-12-31 Facilitating computerized interactions with EMRS
US14/145,904 US10297343B1 (en) 2010-07-21 2013-12-31 Facilitating computerized interactions with EMRS
US14/145,905 US10755802B1 (en) 2010-07-21 2013-12-31 Facilitating computerized interactions with EMRs
US15/648,096 US10726088B1 (en) 2011-08-12 2017-07-12 Computing system for presenting supplemental content in context
US16/391,371 US11636928B1 (en) 2011-02-02 2019-04-23 Facilitating computerized interactions with EMRS
US16/443,843 US11380426B1 (en) 2010-07-21 2019-06-17 Facilitating computerized interactions with EMRs

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US12/840,806 US20110288877A1 (en) 2009-11-09 2010-07-21 Health Information Exchange and Integration System and Methods Useful in Conjunction Therewith
US201161438762P 2011-02-02 2011-02-02
US13/208,417 US20120215560A1 (en) 2010-07-21 2011-08-12 System and methods for facilitating computerized interactions with emrs

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US12/840,806 Continuation-In-Part US20110288877A1 (en) 2009-11-09 2010-07-21 Health Information Exchange and Integration System and Methods Useful in Conjunction Therewith

Related Child Applications (6)

Application Number Title Priority Date Filing Date
US14/145,904 Continuation US10297343B1 (en) 2010-07-21 2013-12-31 Facilitating computerized interactions with EMRS
US14/145,906 Continuation US10733684B1 (en) 2010-07-21 2013-12-31 Facilitating computerized interactions with EMRs
US14/145,905 Continuation US10755802B1 (en) 2010-07-21 2013-12-31 Facilitating computerized interactions with EMRs
US14/145,903 Continuation US10325335B1 (en) 2010-07-21 2013-12-31 Facilitating computerized interactions with EMRs
US14/145,908 Continuation US10789662B1 (en) 2010-07-21 2013-12-31 Facilitating computerized interactions with EMRS
US15/361,788 Continuation-In-Part US10678876B1 (en) 2011-08-12 2016-11-28 Computing system for presenting supplemental content in context

Publications (1)

Publication Number Publication Date
US20120215560A1 true US20120215560A1 (en) 2012-08-23

Family

ID=46653509

Family Applications (8)

Application Number Title Priority Date Filing Date
US13/208,417 Abandoned US20120215560A1 (en) 2010-07-21 2011-08-12 System and methods for facilitating computerized interactions with emrs
US14/145,905 Active 2030-08-29 US10755802B1 (en) 2010-07-21 2013-12-31 Facilitating computerized interactions with EMRs
US14/145,903 Active 2032-01-25 US10325335B1 (en) 2010-07-21 2013-12-31 Facilitating computerized interactions with EMRs
US14/145,908 Active 2031-11-29 US10789662B1 (en) 2010-07-21 2013-12-31 Facilitating computerized interactions with EMRS
US14/145,904 Active 2030-07-22 US10297343B1 (en) 2010-07-21 2013-12-31 Facilitating computerized interactions with EMRS
US14/145,906 Active 2032-05-16 US10733684B1 (en) 2010-07-21 2013-12-31 Facilitating computerized interactions with EMRs
US16/391,371 Active 2036-05-10 US11636928B1 (en) 2011-02-02 2019-04-23 Facilitating computerized interactions with EMRS
US16/443,843 Active US11380426B1 (en) 2010-07-21 2019-06-17 Facilitating computerized interactions with EMRs

Family Applications After (7)

Application Number Title Priority Date Filing Date
US14/145,905 Active 2030-08-29 US10755802B1 (en) 2010-07-21 2013-12-31 Facilitating computerized interactions with EMRs
US14/145,903 Active 2032-01-25 US10325335B1 (en) 2010-07-21 2013-12-31 Facilitating computerized interactions with EMRs
US14/145,908 Active 2031-11-29 US10789662B1 (en) 2010-07-21 2013-12-31 Facilitating computerized interactions with EMRS
US14/145,904 Active 2030-07-22 US10297343B1 (en) 2010-07-21 2013-12-31 Facilitating computerized interactions with EMRS
US14/145,906 Active 2032-05-16 US10733684B1 (en) 2010-07-21 2013-12-31 Facilitating computerized interactions with EMRs
US16/391,371 Active 2036-05-10 US11636928B1 (en) 2011-02-02 2019-04-23 Facilitating computerized interactions with EMRS
US16/443,843 Active US11380426B1 (en) 2010-07-21 2019-06-17 Facilitating computerized interactions with EMRs

Country Status (1)

Country Link
US (8) US20120215560A1 (en)

Cited By (111)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110184954A1 (en) * 2005-05-06 2011-07-28 Nelson John M Database and index organization for enhanced document retrieval
US20110238437A1 (en) * 2010-03-25 2011-09-29 Jian Zhou Systems and Methods for Creating a Form for Receiving Data Relating to a Health Care Incident
US20120173585A1 (en) * 2010-12-30 2012-07-05 Yue Pan Obtaining hierarchical information of planar data
US20120179642A1 (en) * 2008-05-01 2012-07-12 Peter Sweeney System and method for using a knowledge representation to provide information based on environmental inputs
US20130191494A1 (en) * 2012-01-23 2013-07-25 Kiranjit Singh Sidhu Secure Proxied Data Retrieval from Third-Party Services
US20130268467A1 (en) * 2012-04-09 2013-10-10 Electronics And Telecommunications Research Institute Training function generating device, training function generating method, and feature vector classifying method using the same
US20130268258A1 (en) * 2012-04-04 2013-10-10 Pilla Gurumurty Patrudu Mechanism and system for representing and processing activity models
US20130325959A1 (en) * 2012-06-01 2013-12-05 Sony Corporation Information processing apparatus, information processing method and program
US20130326579A1 (en) * 2012-05-30 2013-12-05 Rafae Bhatti Healthcare privacy breach prevention through integrated audit and access control
US20140180708A1 (en) * 2012-12-24 2014-06-26 The Corporation Of Mercer University Systems and methods for responding to requests for health related information
US20140215490A1 (en) * 2010-10-22 2014-07-31 Medicity, Inc. Managing Healthcare Information in a Distributed System
US20140278771A1 (en) * 2013-03-13 2014-09-18 Salesforce.Com, Inc. Systems, methods, and apparatuses for rendering scored opportunities using a predictive query interface
US20140278519A1 (en) * 2013-03-14 2014-09-18 Cerner Innovation, Inc. Expression of Clinical Logic with Positive and Negative Explainability
WO2014190092A1 (en) * 2013-05-22 2014-11-27 Quantros, Inc. Probabilistic event classification systems and methods
US8914595B1 (en) * 2011-09-29 2014-12-16 Emc Corporation Snapshots in deduplication
US20150019248A1 (en) * 2013-07-15 2015-01-15 Siemens Medical Solutions Usa, Inc. Gap in Care Determination Using a Generic Repository for Healthcare
US8949940B1 (en) * 2011-10-12 2015-02-03 Mahasys LLC Aggregating data from multiple issuers and automatically organizing the data
US20150039343A1 (en) * 2013-07-31 2015-02-05 Lightbeam Health Solutions, LLC System for identifying and linking care opportunities and care plans directly to health records
WO2015038432A1 (en) * 2013-09-12 2015-03-19 Geisinger Clinic Method and system for distributing patient data and patient status notifications
US20150081332A1 (en) * 2013-08-30 2015-03-19 Joe Casper Method for Indexing, Searching and Retrieving Health Information
US20150112710A1 (en) * 2012-06-21 2015-04-23 Battelle Memorial Institute Clinical predictive analytics system
US20150161335A1 (en) * 2013-12-11 2015-06-11 Christopher R. Galassi Providing Secure and Seamless Authentication and Workflow for Medical Records and Affiliated Systems
US20150172651A1 (en) * 2013-12-16 2015-06-18 Barco N.V. Efficient error recovery
USD735225S1 (en) 2013-01-03 2015-07-28 Par8O, Inc. Display screen of a computing device with graphical user interface
US20150244687A1 (en) * 2014-02-24 2015-08-27 HCA Holdings, Inc. Providing notifications to authorized users
US20150269217A1 (en) * 2008-07-22 2015-09-24 International Business Machines Corporation Embedded change logging for data synchronization
US9251335B2 (en) 2014-04-25 2016-02-02 Bank Of America Corporation Evaluating customer security preferences
CN105323186A (en) * 2014-06-20 2016-02-10 中兴通讯股份有限公司 Load control method and apparatus for notification messages
US9286467B2 (en) 2014-04-25 2016-03-15 Bank Of America Corporation Evaluating customer security preferences
US20160283666A1 (en) * 2015-03-24 2016-09-29 CareDox Inc. Coordinating record sharing
US20160283673A1 (en) * 2015-03-24 2016-09-29 Intelligent Medical Objects, Inc. System and method for medical classification code modeling
US20160292363A1 (en) * 2013-11-29 2016-10-06 Koninklijke Philips N.V. Document management system for a medical task
US9525692B2 (en) 2012-10-25 2016-12-20 Imprivata, Inc. Secure content sharing
US20170083669A1 (en) * 2012-01-20 2017-03-23 International Business Machines Corporation Method and apparatus providing an online diagnostic assistant tool
US20170161435A1 (en) * 2015-12-08 2017-06-08 Sansoro Health, LLC Electronic medical record integration system and methods
US9697337B2 (en) 2011-04-12 2017-07-04 Applied Science, Inc. Systems and methods for managing blood donations
US20180096058A1 (en) * 2016-10-05 2018-04-05 International Business Machines Corporation Using multiple natural language classifiers to associate a generic query with a structured question type
US20180097871A1 (en) * 2012-04-30 2018-04-05 Google Llc Systems and methods for facilitating deduplication of operations to be performed
US9996216B2 (en) * 2015-06-25 2018-06-12 medCPU, Ltd. Smart display data capturing platform for record systems
US20180165780A1 (en) * 2013-03-15 2018-06-14 Breg, Inc. Business intelligence portal
US20180181716A1 (en) * 2016-12-27 2018-06-28 General Electric Company Role-based navigation interface systems and methods
US10013529B1 (en) * 2012-08-14 2018-07-03 Allscripts Software, Llc Workbench for integrating applications
US10084805B2 (en) * 2017-02-20 2018-09-25 Sas Institute Inc. Computer system to identify anomalies based on computer-generated results
CN108604239A (en) * 2015-12-30 2018-09-28 华睿泰科技有限责任公司 System and method for effective grouped data object
US10090069B2 (en) 2015-12-17 2018-10-02 Kairoi Healthcare Strategies, Inc. Systems and methods for data cleansing such as for optimizing clinical scheduling
US10120707B2 (en) * 2015-12-08 2018-11-06 Paypal, Inc. Deployment of development environments
US10127620B2 (en) * 2006-09-26 2018-11-13 Centrifyhealth, Llc Individual health record system and apparatus
US10128000B1 (en) 2012-04-19 2018-11-13 Kaiser Foundation Hospitals Computer system and method for delivering operational intelligence for ambulatory team based care and virtual medicine
US10140422B2 (en) 2013-03-15 2018-11-27 Battelle Memorial Institute Progression analytics system
US20180358115A1 (en) * 2017-06-07 2018-12-13 Koninklijke Philips N.V. Device, system, and method for operative personal health records
US20190080054A1 (en) * 2017-09-08 2019-03-14 Konica Minolta Healthcare Americas, Inc. Cloud-to-local, local-to-cloud switching and synchronization of medical images and data
US20190147993A1 (en) * 2016-05-16 2019-05-16 Koninklijke Philips N.V. Clinical report retrieval and/or comparison
US10311364B2 (en) 2013-11-19 2019-06-04 Salesforce.Com, Inc. Predictive intelligence for service and support
WO2019110428A1 (en) * 2017-12-04 2019-06-13 Koninklijke Philips N.V. Imputing an outcome attribute to a pers record missing an outcome attribute using a structured situation string or unstructured case note text associated with the record
US20190266235A1 (en) * 2018-02-28 2019-08-29 Charles Northrup System and Method for a Thing Machine to Perform Models
RU2699683C1 (en) * 2018-11-01 2019-09-09 Акционерное общество Инжиниринговая компания "АСЭ" (АО ИК "АСЭ") Method of constructing a distributed information system
US10417322B2 (en) * 2016-05-06 2019-09-17 Cerner Innovation, Inc. Real-time collaborative clinical document analysis and editing
US10425355B1 (en) * 2013-02-04 2019-09-24 HCA Holdings, Inc. Data stream processing for dynamic resource scheduling
US10426424B2 (en) 2017-11-21 2019-10-01 General Electric Company System and method for generating and performing imaging protocol simulations
US10460841B2 (en) 2006-09-26 2019-10-29 Centrifyhealth, Llc Individual health record system and apparatus
US20190340246A1 (en) * 2018-05-02 2019-11-07 Language Scientific, Inc. Systems and methods for producing reliable translation in near real-time
US20190348161A1 (en) * 2017-01-04 2019-11-14 Yueqiang Liang Personal health record system with process decision support function
US10515336B2 (en) * 2013-03-15 2019-12-24 United Airlines, Inc. Material harmonization disposition system for electronic inventories
US10542004B1 (en) 2014-02-24 2020-01-21 C/Hca, Inc. Providing notifications to authorized users
US10678876B1 (en) 2016-02-26 2020-06-09 Allscripts Software, Llc Computing system for presenting supplemental content in context
US20200210612A1 (en) * 2019-01-02 2020-07-02 International Business Machines Corporation Policy based lifecycle management of personal information
US10726088B1 (en) 2011-08-12 2020-07-28 Allscripts Software, Llc Computing system for presenting supplemental content in context
US10789662B1 (en) 2010-07-21 2020-09-29 Allscripts Software, Llc Facilitating computerized interactions with EMRS
US10812417B2 (en) * 2018-01-09 2020-10-20 International Business Machines Corporation Auto-incorrect in chatbot human-machine interfaces
US10868719B2 (en) 2017-04-28 2020-12-15 Oracle International Corporation System and method for federated configuration in an application server environment
US10896381B2 (en) * 2016-03-18 2021-01-19 Fair Isaac Corporation Behavioral misalignment detection within entity hard segmentation utilizing archetype-clustering
US10909176B1 (en) * 2014-10-28 2021-02-02 Intelligent Medical Objects, Inc. System and method for facilitating migration between electronic terminologies
US20210049220A1 (en) * 2019-08-13 2021-02-18 Roumelia "Lynn" Margaret Buhay Pingol Procurement data management system and method
US10956224B1 (en) * 2017-08-29 2021-03-23 Wells Fargo Bank, N.A. Creating augmented hybrid infrastructure as a service
US10978197B2 (en) * 2015-12-18 2021-04-13 Cerner Innovation, Inc. Healthcare workflows that bridge healthcare venues
US10984897B2 (en) 2016-10-27 2021-04-20 Snaps Solutions, Llc Systems and methods for surfacing contextually relevant content into the workflow of a third party system via a distributed architecture
US11031109B2 (en) 2017-12-28 2021-06-08 International Business Machines Corporation Contextual EMR based dashboard graphical user interface elements
US20210209130A1 (en) * 2020-01-03 2021-07-08 HealthSnap, Inc. System and method for syncing asynchronously received sequential data from disparate sources
US11061876B2 (en) * 2016-11-15 2021-07-13 Sap Se Fast aggregation on compressed data
US11107560B1 (en) * 2016-12-02 2021-08-31 Allscripts Software, Llc Methods, systems and apparatus for processing and displaying community patient data alongside native patient data
US11114194B2 (en) 2015-10-01 2021-09-07 Audacious Inquiry Network-based systems and methods for providing readmission notifications
US11152091B1 (en) 2020-01-31 2021-10-19 Allscripts Software, Llc Systems and methods for clinical task separation in electronic health record applications
US11170879B1 (en) 2006-09-26 2021-11-09 Centrifyhealth, Llc Individual health record system and apparatus
US11177041B1 (en) 2018-07-20 2021-11-16 MedAmerica Data Services, LLC Method and system for cardiac risk assessment of a patient using historical and real-time data
US11200968B2 (en) 2017-12-20 2021-12-14 International Business Machines Corporation Verifying medical conditions of patients in electronic medical records
US20210390262A1 (en) * 2020-06-10 2021-12-16 Mette Dyhrberg Standardized data input from language using universal significance codes
US20210406098A1 (en) * 2020-06-30 2021-12-30 Cerner Innovation, Inc. System and method for new issue management for conversion achievement
US11226959B2 (en) 2019-04-03 2022-01-18 Unitedhealth Group Incorporated Managing data objects for graph-based data structures
US11226976B2 (en) * 2016-05-20 2022-01-18 Magnet Forensics Investco Inc. Systems and methods for graphical exploration of forensic data
US11238988B2 (en) 2013-03-14 2022-02-01 Cerner Innovation, Inc. Large scale identification and analysis of population health risks
US20220031254A1 (en) * 2012-01-04 2022-02-03 Masimo Corporation Automated condition screening and detection
US11263273B2 (en) 2016-05-20 2022-03-01 Magnet Forensics Investco Inc. Systems and methods for graphical exploration of forensic data
US20220084641A1 (en) * 2014-03-21 2022-03-17 Ehr Command Center, Llc Medical services tracking system and method
US11302441B2 (en) * 2018-10-29 2022-04-12 3M Innovative Properties Company Patient treatment resource utilization predictor
US11322236B1 (en) 2019-04-03 2022-05-03 Precis, Llc Data abstraction system architecture not requiring interoperability between data providers
US11372949B1 (en) * 2016-11-04 2022-06-28 Cerner Innovation, Inc. Dynamic narrative view generation
US11426498B2 (en) 2014-05-30 2022-08-30 Applied Science, Inc. Systems and methods for managing blood donations
US11482322B1 (en) 2018-07-20 2022-10-25 MedAmerica Data Services, LLC Patient trackerboard tool and interface
US11495332B2 (en) 2017-12-28 2022-11-08 International Business Machines Corporation Automated prediction and answering of medical professional questions directed to patient based on EMR
US11501859B1 (en) 2018-07-20 2022-11-15 MedAmerica Data Services, LLC Patient callback tool and interface
US11539817B1 (en) 2018-09-27 2022-12-27 C/Hca, Inc. Adaptive authentication and notification system
US20220415500A1 (en) * 2021-06-25 2022-12-29 Mental Health & Wellness Now Partners, LLC Computing Device Configured with User Check-In for Mental Health and Wellness
US11574711B1 (en) * 2016-12-31 2023-02-07 Altera Digital Health Inc. Graphical user interface methodologies for providing specialty views of healthcare data
US11594311B1 (en) 2016-03-31 2023-02-28 OM1, Inc. Health care information system providing standardized outcome scores across patients
US11626192B1 (en) * 2018-07-20 2023-04-11 MedAmerica Data Services, LLC Real time parser for use with electronic medical records
US11688496B2 (en) * 2020-04-03 2023-06-27 Anju Software, Inc. Health information exchange system
US11823798B2 (en) * 2016-09-28 2023-11-21 Merative Us L.P. Container-based knowledge graphs for determining entity relations in non-narrative text
US11837343B2 (en) 2018-04-30 2023-12-05 Merative Us L.P. Identifying repetitive portions of clinical notes and generating summaries pertinent to treatment of a patient based on the identified repetitive portions
US11837334B2 (en) 2019-08-29 2023-12-05 Shrpro, Llc Whole-life, medication management, and ordering display system
US11862346B1 (en) * 2018-12-22 2024-01-02 OM1, Inc. Identification of patient sub-cohorts and corresponding quantitative definitions of subtypes as a classification system for medical conditions
US11943420B2 (en) * 2021-06-30 2024-03-26 Tobii Ab Method and system for alignment of data

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11908569B2 (en) * 2015-12-02 2024-02-20 Iryou Jyouhou Gijyutu Kenkyusyo Corporation Electronic sticky note system
US11797706B2 (en) 2016-02-09 2023-10-24 Health2047, Inc. Mobile device network traffic modification and user based restrictions on data access
US11759110B2 (en) * 2019-11-18 2023-09-19 Koninklijke Philips N.V. Camera view and screen scraping for information extraction from imaging scanner consoles
CN113035302A (en) * 2019-12-24 2021-06-25 佳能医疗系统株式会社 Medical information processing system, medical information processing apparatus, and medical information processing method
US11393566B1 (en) 2021-07-13 2022-07-19 Beigene, Ltd. Interoperable platform for reducing redundancy in medical database management

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020083075A1 (en) * 2000-12-22 2002-06-27 Tony Brummel System and method for a seamless user interface for an integrated electronic health care information system
US20060074633A1 (en) * 2004-10-01 2006-04-06 Prakash Mahesh System and method for rules-based context management in a medical environment
US20080046292A1 (en) * 2006-01-17 2008-02-21 Accenture Global Services Gmbh Platform for interoperable healthcare data exchange
US20090177492A1 (en) * 2000-10-11 2009-07-09 Malik M. Hasan Method and System for Generating Personal/Individual Health Records

Family Cites Families (56)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS5942489A (en) 1982-09-03 1984-03-09 株式会社日立製作所 Poroidal magnetic coil supporting device
JPH05243152A (en) 1992-02-26 1993-09-21 Oki Electric Ind Co Ltd Molecular beam epitaxial growth device and method thereof
US7256770B2 (en) 1998-09-14 2007-08-14 Microsoft Corporation Method for displaying information responsive to sensing a physical presence proximate to a computer input device
US6909443B1 (en) * 1999-04-06 2005-06-21 Microsoft Corporation Method and apparatus for providing a three-dimensional task gallery computer interface
US7490048B2 (en) * 1999-12-18 2009-02-10 Raymond Anthony Joao Apparatus and method for processing and/or for providing healthcare information and/or healthcare-related information
US20030023717A1 (en) 2001-07-26 2003-01-30 Lister Michael L. Method and apparatus to reveal the usability of an internet web site
US7756728B2 (en) * 2001-10-31 2010-07-13 Siemens Medical Solutions Usa, Inc. Healthcare system and user interface for consolidating patient related information from different sources
DE10163469A1 (en) 2001-12-21 2003-03-20 Siemens Ag Storage of medical images in an archive with an associated keyword, so that a doctor or specialist subsequently treating a patient can access relevant images
EP1324254A1 (en) * 2001-12-21 2003-07-02 Siemens Aktiengesellschaft System for searching patient history or medical archives by keyword
JP2004030128A (en) * 2002-06-25 2004-01-29 Nec Software Kyushu Ltd Health care information sharing system, health care information sharing method, and health care information sharing program
US7583861B2 (en) 2002-11-27 2009-09-01 Teramedica, Inc. Intelligent medical image management system
US20040122707A1 (en) 2002-12-18 2004-06-24 Sabol John M. Patient-driven medical data processing system and method
US20040122787A1 (en) 2002-12-18 2004-06-24 Avinash Gopal B. Enhanced computer-assisted medical data processing system and method
US20040122719A1 (en) 2002-12-18 2004-06-24 Sabol John M. Medical resource processing system and method utilizing multiple resource type data
US20040122709A1 (en) 2002-12-18 2004-06-24 Avinash Gopal B. Medical procedure prioritization system and method utilizing integrated knowledge base
US7895053B2 (en) 2003-10-07 2011-02-22 Hospira, Inc. Medication management system
WO2005106474A2 (en) * 2004-04-14 2005-11-10 Edda Technology, Inc. Liver disease diagnosis system, method and graphical user interface
US7801743B2 (en) 2005-02-11 2010-09-21 Avaya Inc. Use of location awareness of establish communications with a target clinician in a healthcare environment
US20060287890A1 (en) 2005-06-15 2006-12-21 Vanderbilt University Method and apparatus for organizing and integrating structured and non-structured data across heterogeneous systems
US20070021977A1 (en) 2005-07-19 2007-01-25 Witt Biomedical Corporation Automated system for capturing and archiving information to verify medical necessity of performing medical procedure
US7853621B2 (en) 2005-11-23 2010-12-14 Oracle International Corp. Integrating medical data and images in a database management system
CA2632593A1 (en) 2005-12-01 2007-06-07 Future Health, Inc. Method of efficiently and effectively providing unique and/or multiple office management services in one system and a method and system for automatically selecting educational, marketing and other business-related items to be provided to a client
WO2007120904A2 (en) 2006-04-14 2007-10-25 Fuzzmed, Inc. System, method, and device for personal medical care, intelligent analysis, and diagnosis
US20080097952A1 (en) * 2006-10-05 2008-04-24 Integrated Informatics Inc. Extending emr - making patient data emrcentric
US8037052B2 (en) 2006-11-22 2011-10-11 General Electric Company Systems and methods for free text searching of electronic medical record data
US8468244B2 (en) 2007-01-05 2013-06-18 Digital Doors, Inc. Digital information infrastructure and method for security designated data and with granular data stores
US8655939B2 (en) 2007-01-05 2014-02-18 Digital Doors, Inc. Electromagnetic pulse (EMP) hardened information infrastructure with extractor, cloud dispersal, secure storage, content analysis and classification and method therefor
US7953944B2 (en) 2007-02-02 2011-05-31 Siemens Aktiengesellschaft Dynamic data archiving with dynamically defined rules and dynamically defined parameter
US20080208624A1 (en) * 2007-02-22 2008-08-28 General Electric Company Methods and systems for providing clinical display and search of electronic medical record data from a variety of information systems
US8515926B2 (en) * 2007-03-22 2013-08-20 International Business Machines Corporation Processing related data from information sources
US7689916B1 (en) 2007-03-27 2010-03-30 Avaya, Inc. Automatically generating, and providing multiple levels of, tooltip information over time
US8850057B2 (en) 2007-09-20 2014-09-30 Intel Corporation Healthcare semantic interoperability platform
US20090125555A1 (en) 2007-11-14 2009-05-14 General Electric Company Method and apparatus for flexible archiving
US10096075B2 (en) 2008-09-12 2018-10-09 Epic Systems Corporation Patient community system with anonymized electronic medical data
EP2350882A4 (en) 2008-10-03 2013-01-23 Invensys Sys Inc Retrieving and navigating through manufacturing data from relational and time-series systems by abstracting the source systems into a set of named entities
US20100131498A1 (en) * 2008-11-26 2010-05-27 General Electric Company Automated healthcare information composition and query enhancement
US8239216B2 (en) 2009-01-09 2012-08-07 Cerner Innovation, Inc. Searching an electronic medical record
US10055105B2 (en) 2009-02-03 2018-08-21 Calgary Scientific Inc. Method and system for enabling interaction with a plurality of applications using a single user interface
US20110071852A1 (en) * 2009-09-18 2011-03-24 E-Health Portfolio, Incorporated Health Information Management Systems and Methods
US20110288877A1 (en) 2009-11-09 2011-11-24 dbMotion Ltd. Health Information Exchange and Integration System and Methods Useful in Conjunction Therewith
TWI438675B (en) 2010-04-30 2014-05-21 Ibm Method, device and computer program product for providing a context-aware help content
US20120215560A1 (en) 2010-07-21 2012-08-23 dbMotion Ltd. System and methods for facilitating computerized interactions with emrs
US20120101843A1 (en) 2010-10-22 2012-04-26 Medicity, Inc. System and method for anonymizing patient data
US8949427B2 (en) 2011-02-25 2015-02-03 International Business Machines Corporation Administering medical digital images with intelligent analytic execution of workflows
US9836485B2 (en) 2011-02-25 2017-12-05 International Business Machines Corporation Auditing database access in a distributed medical computing environment
US20140303670A1 (en) 2011-11-16 2014-10-09 Neuromechanical Innovations, Llc Method and Device for Spinal Analysis
US20130218596A1 (en) 2012-02-16 2013-08-22 dbMotion Ltd. Method And System For Facilitating User Navigation Through A Computerized Medical Information System
WO2014039709A2 (en) 2012-09-05 2014-03-13 Dorsata, Inc. Methods and systems for the implementation of web based collaborative clinical pathways
CA2896086C (en) 2012-12-21 2023-01-17 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
JP2016519806A (en) 2013-03-14 2016-07-07 オントミクス， インコーポレイテッド System and method for a personalized clinical decision support tool
US20150025911A1 (en) 2013-07-17 2015-01-22 Webmd, Llc Methods and systems for distributing sensitive or confidential information
US9626262B1 (en) 2013-12-09 2017-04-18 Amazon Technologies, Inc. Primary role reporting service for resource groups
US20150363554A1 (en) 2014-06-13 2015-12-17 International Business Machines Corporation Configuring accessibility settings following a medical change
US9208284B1 (en) 2014-06-27 2015-12-08 Practice Fusion, Inc. Medical professional application integration into electronic health record system
US20160132645A1 (en) 2014-11-07 2016-05-12 Qsi Management, Llc System and architecture for providing shared patient data notifications
US20170091388A1 (en) 2015-09-30 2017-03-30 Stratus Interoperable, Inc. Systems and methods supporting interoperability among health record applications and data sources

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090177492A1 (en) * 2000-10-11 2009-07-09 Malik M. Hasan Method and System for Generating Personal/Individual Health Records
US20020083075A1 (en) * 2000-12-22 2002-06-27 Tony Brummel System and method for a seamless user interface for an integrated electronic health care information system
US20060074633A1 (en) * 2004-10-01 2006-04-06 Prakash Mahesh System and method for rules-based context management in a medical environment
US20080046292A1 (en) * 2006-01-17 2008-02-21 Accenture Global Services Gmbh Platform for interoperable healthcare data exchange

Cited By (214)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8782050B2 (en) * 2005-05-06 2014-07-15 Nelson Information Systems, Inc. Database and index organization for enhanced document retrieval
US20110184954A1 (en) * 2005-05-06 2011-07-28 Nelson John M Database and index organization for enhanced document retrieval
US10878955B2 (en) 2006-09-26 2020-12-29 Centrifyhealth, Llc Individual health record system and apparatus
US11170879B1 (en) 2006-09-26 2021-11-09 Centrifyhealth, Llc Individual health record system and apparatus
US10127620B2 (en) * 2006-09-26 2018-11-13 Centrifyhealth, Llc Individual health record system and apparatus
US10460841B2 (en) 2006-09-26 2019-10-29 Centrifyhealth, Llc Individual health record system and apparatus
US10867133B2 (en) * 2008-05-01 2020-12-15 Primal Fusion Inc. System and method for using a knowledge representation to provide information based on environmental inputs
US20120179642A1 (en) * 2008-05-01 2012-07-12 Peter Sweeney System and method for using a knowledge representation to provide information based on environmental inputs
US9495407B2 (en) * 2008-07-22 2016-11-15 International Business Machines Corporation Embedded change logging for data synchronization
US20150269217A1 (en) * 2008-07-22 2015-09-24 International Business Machines Corporation Embedded change logging for data synchronization
US10474646B2 (en) 2010-03-25 2019-11-12 Rldatix North America Inc. Systems and methods for creating a form for receiving data relating to a health care incident
US8781852B2 (en) * 2010-03-25 2014-07-15 Rl Solutions Systems and methods for creating a form for receiving data relating to a health care incident
US20110238437A1 (en) * 2010-03-25 2011-09-29 Jian Zhou Systems and Methods for Creating a Form for Receiving Data Relating to a Health Care Incident
US9798747B2 (en) * 2010-03-25 2017-10-24 Rl Solutions Systems and methods for creating a form for receiving data relating to a health care incident
US20140288955A1 (en) * 2010-03-25 2014-09-25 Rl Solutions Systems and methods for creating a form for receiving data relating to a health care incident
US11380426B1 (en) 2010-07-21 2022-07-05 Allscripts Software, Llc Facilitating computerized interactions with EMRs
US10789662B1 (en) 2010-07-21 2020-09-29 Allscripts Software, Llc Facilitating computerized interactions with EMRS
US8990834B2 (en) * 2010-10-22 2015-03-24 Medicity, Inc. Managing healthcare information in a distributed system
US20140215490A1 (en) * 2010-10-22 2014-07-31 Medicity, Inc. Managing Healthcare Information in a Distributed System
US8996581B2 (en) * 2010-12-30 2015-03-31 International Business Machines Corporation Obtaining hierarchical information of planar data
US20120173585A1 (en) * 2010-12-30 2012-07-05 Yue Pan Obtaining hierarchical information of planar data
US9697337B2 (en) 2011-04-12 2017-07-04 Applied Science, Inc. Systems and methods for managing blood donations
US10726088B1 (en) 2011-08-12 2020-07-28 Allscripts Software, Llc Computing system for presenting supplemental content in context
US8914595B1 (en) * 2011-09-29 2014-12-16 Emc Corporation Snapshots in deduplication
US8949940B1 (en) * 2011-10-12 2015-02-03 Mahasys LLC Aggregating data from multiple issuers and automatically organizing the data
US20220031254A1 (en) * 2012-01-04 2022-02-03 Masimo Corporation Automated condition screening and detection
US20170083669A1 (en) * 2012-01-20 2017-03-23 International Business Machines Corporation Method and apparatus providing an online diagnostic assistant tool
US10257315B2 (en) * 2012-01-23 2019-04-09 Facebook, Inc. Secure proxied data retrieval from third-party services
US20130191494A1 (en) * 2012-01-23 2013-07-25 Kiranjit Singh Sidhu Secure Proxied Data Retrieval from Third-Party Services
US20130268258A1 (en) * 2012-04-04 2013-10-10 Pilla Gurumurty Patrudu Mechanism and system for representing and processing activity models
US9176951B2 (en) * 2012-04-04 2015-11-03 Pilla Gurumurty Patrudu Mechanism and system for representing and processing activity models
US20130268467A1 (en) * 2012-04-09 2013-10-10 Electronics And Telecommunications Research Institute Training function generating device, training function generating method, and feature vector classifying method using the same
US10128000B1 (en) 2012-04-19 2018-11-13 Kaiser Foundation Hospitals Computer system and method for delivering operational intelligence for ambulatory team based care and virtual medicine
US10938903B2 (en) * 2012-04-30 2021-03-02 Google Llc Systems and methods for facilitating deduplication of operations to be performed
US11394780B2 (en) * 2012-04-30 2022-07-19 Google Llc System and method for facilitating deduplication of operations to be performed
US20180097871A1 (en) * 2012-04-30 2018-04-05 Google Llc Systems and methods for facilitating deduplication of operations to be performed
US20130326579A1 (en) * 2012-05-30 2013-12-05 Rafae Bhatti Healthcare privacy breach prevention through integrated audit and access control
US9438632B2 (en) 2012-05-30 2016-09-06 Accenture Global Services Limited Healthcare privacy breach prevention through integrated audit and access control
US8984583B2 (en) * 2012-05-30 2015-03-17 Accenture Global Services Limited Healthcare privacy breach prevention through integrated audit and access control
US9369535B2 (en) * 2012-06-01 2016-06-14 Sony Corporation Information processing apparatus, information processing method and program
US20130325959A1 (en) * 2012-06-01 2013-12-05 Sony Corporation Information processing apparatus, information processing method and program
US20150112710A1 (en) * 2012-06-21 2015-04-23 Battelle Memorial Institute Clinical predictive analytics system
US10013529B1 (en) * 2012-08-14 2018-07-03 Allscripts Software, Llc Workbench for integrating applications
US11520911B2 (en) 2012-10-25 2022-12-06 Imprivata, Inc. Secure content sharing
US11030330B2 (en) 2012-10-25 2021-06-08 Imprivata, Inc. Secure content sharing
US11822677B2 (en) 2012-10-25 2023-11-21 Imprivata, Inc. Secure content sharing
US9525692B2 (en) 2012-10-25 2016-12-20 Imprivata, Inc. Secure content sharing
US10061929B2 (en) 2012-10-25 2018-08-28 Imprivata, Inc. Secure content sharing
US20140180708A1 (en) * 2012-12-24 2014-06-26 The Corporation Of Mercer University Systems and methods for responding to requests for health related information
USD735225S1 (en) 2013-01-03 2015-07-28 Par8O, Inc. Display screen of a computing device with graphical user interface
US10425355B1 (en) * 2013-02-04 2019-09-24 HCA Holdings, Inc. Data stream processing for dynamic resource scheduling
US9367853B2 (en) 2013-03-13 2016-06-14 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing data upload, processing, and predictive query API exposure
US9235846B2 (en) 2013-03-13 2016-01-12 Salesforce.Com, Inc. Systems, methods, and apparatuses for populating a table having null values using a predictive query interface
US9240016B2 (en) 2013-03-13 2016-01-19 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing predictive query interface as a cloud service
US9454767B2 (en) 2013-03-13 2016-09-27 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing a related command with a predictive query interface
US9390428B2 (en) * 2013-03-13 2016-07-12 Salesforce.Com, Inc. Systems, methods, and apparatuses for rendering scored opportunities using a predictive query interface
US9349132B2 (en) 2013-03-13 2016-05-24 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing a group command with a predictive query interface
US9342836B2 (en) 2013-03-13 2016-05-17 salesforces.com, Inc. Systems, methods, and apparatuses for implementing a predict command with a predictive query interface
US9690815B2 (en) 2013-03-13 2017-06-27 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing data upload, processing, and predictive query API exposure
US9336533B2 (en) * 2013-03-13 2016-05-10 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing a similar command with a predictive query interface
US9753962B2 (en) 2013-03-13 2017-09-05 Salesforce.Com, Inc. Systems, methods, and apparatuses for populating a table having null values using a predictive query interface
US20140280193A1 (en) * 2013-03-13 2014-09-18 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing a similar command with a predictive query interface
US10963541B2 (en) 2013-03-13 2021-03-30 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing a related command with a predictive query interface
US10860557B2 (en) 2013-03-13 2020-12-08 Salesforce.Com, Inc. Systems, methods, and apparatuses for implementing change value indication and historical value comparison
US20140278771A1 (en) * 2013-03-13 2014-09-18 Salesforce.Com, Inc. Systems, methods, and apparatuses for rendering scored opportunities using a predictive query interface
US11875884B2 (en) * 2013-03-14 2024-01-16 Cerner Innovation, Inc. Expression of clinical logic with positive and negative explainability
US20140278519A1 (en) * 2013-03-14 2014-09-18 Cerner Innovation, Inc. Expression of Clinical Logic with Positive and Negative Explainability
US20230024631A1 (en) * 2013-03-14 2023-01-26 Cerner Innovation, Inc. Expression of clinical logic with positive and negative explainability
US11238988B2 (en) 2013-03-14 2022-02-01 Cerner Innovation, Inc. Large scale identification and analysis of population health risks
US11488695B2 (en) * 2013-03-14 2022-11-01 Cerner Innovation, Inc. Expression of clinical logic with positive and negative explainability
US10566080B2 (en) * 2013-03-14 2020-02-18 Cerner Innovation, Inc. Expression of clinical logic with positive and negative explainability
US10140422B2 (en) 2013-03-15 2018-11-27 Battelle Memorial Institute Progression analytics system
US10872131B2 (en) 2013-03-15 2020-12-22 Battelle Memorial Institute Progression analytics system
US10929939B2 (en) * 2013-03-15 2021-02-23 Breg, Inc. Business intelligence portal
US20180165780A1 (en) * 2013-03-15 2018-06-14 Breg, Inc. Business intelligence portal
US10515336B2 (en) * 2013-03-15 2019-12-24 United Airlines, Inc. Material harmonization disposition system for electronic inventories
WO2014190092A1 (en) * 2013-05-22 2014-11-27 Quantros, Inc. Probabilistic event classification systems and methods
US10269450B2 (en) 2013-05-22 2019-04-23 Quantros, Inc. Probabilistic event classification systems and methods
US11256876B2 (en) 2013-07-15 2022-02-22 Cerner Innovation, Inc. Gap in care determination using a generic repository for healthcare
US11783134B2 (en) 2013-07-15 2023-10-10 Cerner Innovation, Inc. Gap in care determination using a generic repository for healthcare
US20150019248A1 (en) * 2013-07-15 2015-01-15 Siemens Medical Solutions Usa, Inc. Gap in Care Determination Using a Generic Repository for Healthcare
US10540448B2 (en) * 2013-07-15 2020-01-21 Cerner Innovation, Inc. Gap in care determination using a generic repository for healthcare
US20150039343A1 (en) * 2013-07-31 2015-02-05 Lightbeam Health Solutions, LLC System for identifying and linking care opportunities and care plans directly to health records
US20150081332A1 (en) * 2013-08-30 2015-03-19 Joe Casper Method for Indexing, Searching and Retrieving Health Information
WO2015038432A1 (en) * 2013-09-12 2015-03-19 Geisinger Clinic Method and system for distributing patient data and patient status notifications
US10311364B2 (en) 2013-11-19 2019-06-04 Salesforce.Com, Inc. Predictive intelligence for service and support
US10956411B2 (en) * 2013-11-29 2021-03-23 Koninklijke Philips N.V. Document management system for a medical task
US20160292363A1 (en) * 2013-11-29 2016-10-06 Koninklijke Philips N.V. Document management system for a medical task
US10614911B2 (en) * 2013-12-11 2020-04-07 Chirstopher R. Galassi Providing secure and seamless authentication and workflow for medical records and affiliated systems
US20150161335A1 (en) * 2013-12-11 2015-06-11 Christopher R. Galassi Providing Secure and Seamless Authentication and Workflow for Medical Records and Affiliated Systems
US20210158910A1 (en) * 2013-12-11 2021-05-27 Christopher R. Galassi Providing Secure and Seamless Authentication and Workflow for Medical Records and Affiliated Systems
US10063853B2 (en) * 2013-12-16 2018-08-28 Barco N.V. Efficient error recovery
US20150172651A1 (en) * 2013-12-16 2015-06-18 Barco N.V. Efficient error recovery
US10542004B1 (en) 2014-02-24 2020-01-21 C/Hca, Inc. Providing notifications to authorized users
US20150244687A1 (en) * 2014-02-24 2015-08-27 HCA Holdings, Inc. Providing notifications to authorized users
US9203814B2 (en) * 2014-02-24 2015-12-01 HCA Holdings, Inc. Providing notifications to authorized users
US11552952B1 (en) * 2014-02-24 2023-01-10 C/Hca, Inc. Providing notifications to authorized users
US9906532B2 (en) 2014-02-24 2018-02-27 HCA Holdings, Inc. Providing notifications to authorized users
US10505935B1 (en) 2014-02-24 2019-12-10 HCA Holdings, Inc. Providing notifications to authorized users
US11756659B2 (en) * 2014-03-21 2023-09-12 Dhrpro, Llc Medical services tracking system and method
US20220084641A1 (en) * 2014-03-21 2022-03-17 Ehr Command Center, Llc Medical services tracking system and method
US9251335B2 (en) 2014-04-25 2016-02-02 Bank Of America Corporation Evaluating customer security preferences
US9286467B2 (en) 2014-04-25 2016-03-15 Bank Of America Corporation Evaluating customer security preferences
US9519783B2 (en) 2014-04-25 2016-12-13 Bank Of America Corporation Evaluating customer security preferences
US9519790B2 (en) 2014-04-25 2016-12-13 Bank Of America Corporation Evaluating customer security preferences
US11426498B2 (en) 2014-05-30 2022-08-30 Applied Science, Inc. Systems and methods for managing blood donations
CN105323186A (en) * 2014-06-20 2016-02-10 中兴通讯股份有限公司 Load control method and apparatus for notification messages
US20170142614A1 (en) * 2014-06-20 2017-05-18 Zte Corporation Load Control Method and Apparatus for Notification Messages
US10085175B2 (en) * 2014-06-20 2018-09-25 Zte Corporation Load control method and apparatus for notification messages
US10909176B1 (en) * 2014-10-28 2021-02-02 Intelligent Medical Objects, Inc. System and method for facilitating migration between electronic terminologies
US20160283666A1 (en) * 2015-03-24 2016-09-29 CareDox Inc. Coordinating record sharing
US20160283673A1 (en) * 2015-03-24 2016-09-29 Intelligent Medical Objects, Inc. System and method for medical classification code modeling
US10885148B2 (en) * 2015-03-24 2021-01-05 Intelligent Medical Objects, Inc. System and method for medical classification code modeling
US9996216B2 (en) * 2015-06-25 2018-06-12 medCPU, Ltd. Smart display data capturing platform for record systems
US20180260099A1 (en) * 2015-06-25 2018-09-13 Medcpu, Inc. Smart Display Data Capturing Platform For Record Systems
US11114194B2 (en) 2015-10-01 2021-09-07 Audacious Inquiry Network-based systems and methods for providing readmission notifications
US11094404B2 (en) 2015-12-08 2021-08-17 Interoperability Bidco, Inc Electronic medical record integration
US20170161435A1 (en) * 2015-12-08 2017-06-08 Sansoro Health, LLC Electronic medical record integration system and methods
US10818381B2 (en) * 2015-12-08 2020-10-27 Datica, Inc. Electronic medical record integration system and methods
US10120707B2 (en) * 2015-12-08 2018-11-06 Paypal, Inc. Deployment of development environments
US10204705B2 (en) 2015-12-17 2019-02-12 Kairoi Healthcare Strategies, Inc. Systems and methods for data cleansing such as for optimizing clinical scheduling
US10090069B2 (en) 2015-12-17 2018-10-02 Kairoi Healthcare Strategies, Inc. Systems and methods for data cleansing such as for optimizing clinical scheduling
US11688510B2 (en) * 2015-12-18 2023-06-27 Cerner Innovation, Inc. Healthcare workflows that bridge healthcare venues
US20210225498A1 (en) * 2015-12-18 2021-07-22 Cerner Innovation, Inc. Healthcare workflows that bridge healthcare venues
US10978197B2 (en) * 2015-12-18 2021-04-13 Cerner Innovation, Inc. Healthcare workflows that bridge healthcare venues
CN108604239A (en) * 2015-12-30 2018-09-28 华睿泰科技有限责任公司 System and method for effective grouped data object
US10747399B1 (en) 2016-02-26 2020-08-18 Allscripts Software, Llc Application that acts as a platform for supplement applications
US10678876B1 (en) 2016-02-26 2020-06-09 Allscripts Software, Llc Computing system for presenting supplemental content in context
US10692593B1 (en) 2016-02-26 2020-06-23 Allscripts Software, Llc Identifying events in a badge of a graphical user interface
US10896381B2 (en) * 2016-03-18 2021-01-19 Fair Isaac Corporation Behavioral misalignment detection within entity hard segmentation utilizing archetype-clustering
US11594310B1 (en) 2016-03-31 2023-02-28 OM1, Inc. Health care information system providing additional data fields in patient data
US11594311B1 (en) 2016-03-31 2023-02-28 OM1, Inc. Health care information system providing standardized outcome scores across patients
US10755038B2 (en) * 2016-05-06 2020-08-25 Cerner Innovation, Inc. Real-time collaborative clinical document analysis and editing
US10417322B2 (en) * 2016-05-06 2019-09-17 Cerner Innovation, Inc. Real-time collaborative clinical document analysis and editing
US11144714B2 (en) * 2016-05-06 2021-10-12 Cerner Innovation, Inc. Real-time collaborative clinical document analysis and editing
US20190147993A1 (en) * 2016-05-16 2019-05-16 Koninklijke Philips N.V. Clinical report retrieval and/or comparison
US11527312B2 (en) * 2016-05-16 2022-12-13 Koninklijke Philips N.V. Clinical report retrieval and/or comparison
US11263273B2 (en) 2016-05-20 2022-03-01 Magnet Forensics Investco Inc. Systems and methods for graphical exploration of forensic data
US11226976B2 (en) * 2016-05-20 2022-01-18 Magnet Forensics Investco Inc. Systems and methods for graphical exploration of forensic data
US11823798B2 (en) * 2016-09-28 2023-11-21 Merative Us L.P. Container-based knowledge graphs for determining entity relations in non-narrative text
US10754886B2 (en) * 2016-10-05 2020-08-25 International Business Machines Corporation Using multiple natural language classifier to associate a generic query with a structured question type
US20180096058A1 (en) * 2016-10-05 2018-04-05 International Business Machines Corporation Using multiple natural language classifiers to associate a generic query with a structured question type
US20220180985A1 (en) * 2016-10-27 2022-06-09 SNAPS Solutions LLC Systems and methods for surfacing contextually relevant content into the workflow of a third party system via a distributed architecture
US11942197B2 (en) * 2016-10-27 2024-03-26 Snaps Solutions, Llc Systems and methods for surfacing contextually relevant content into the workflow of a third party system via a distributed architecture
US11942196B2 (en) * 2016-10-27 2024-03-26 Snaps Solutions, Llc Systems and methods for surfacing contextually relevant content into the workflow of a third party system via a distributed architecture
US11170880B2 (en) * 2016-10-27 2021-11-09 SNAPS Solutions LLC Systems and methods for automatically executing workflows of third-party systems
US20220180984A1 (en) * 2016-10-27 2022-06-09 SNAPS Solutions LLC Systems and methods for surfacing contextually relevant content into the workflow of a third party system via a distributed architecture
USD967123S1 (en) 2016-10-27 2022-10-18 SNAPS Solutions LLC Display screen with a slide-out graphical user interface
US11568971B2 (en) 2016-10-27 2023-01-31 Snaps Solutions, Llc Systems and methods for surfacing contextually relevant content into the workflow of a third party system via a distributed architecture
US10984897B2 (en) 2016-10-27 2021-04-20 Snaps Solutions, Llc Systems and methods for surfacing contextually relevant content into the workflow of a third party system via a distributed architecture
US11372949B1 (en) * 2016-11-04 2022-06-28 Cerner Innovation, Inc. Dynamic narrative view generation
US11061876B2 (en) * 2016-11-15 2021-07-13 Sap Se Fast aggregation on compressed data
US11107560B1 (en) * 2016-12-02 2021-08-31 Allscripts Software, Llc Methods, systems and apparatus for processing and displaying community patient data alongside native patient data
US20180181716A1 (en) * 2016-12-27 2018-06-28 General Electric Company Role-based navigation interface systems and methods
US11574711B1 (en) * 2016-12-31 2023-02-07 Altera Digital Health Inc. Graphical user interface methodologies for providing specialty views of healthcare data
US20190348161A1 (en) * 2017-01-04 2019-11-14 Yueqiang Liang Personal health record system with process decision support function
US11640853B2 (en) * 2017-01-04 2023-05-02 Yueqiang Liang Personal health record system with process decision support function
US10084805B2 (en) * 2017-02-20 2018-09-25 Sas Institute Inc. Computer system to identify anomalies based on computer-generated results
US10868719B2 (en) 2017-04-28 2020-12-15 Oracle International Corporation System and method for federated configuration in an application server environment
US11393562B2 (en) * 2017-06-07 2022-07-19 Koninklijke Philips N.V. Device, system, and method for operative personal health records
US20180358115A1 (en) * 2017-06-07 2018-12-13 Koninklijke Philips N.V. Device, system, and method for operative personal health records
US10956224B1 (en) * 2017-08-29 2021-03-23 Wells Fargo Bank, N.A. Creating augmented hybrid infrastructure as a service
US10503869B2 (en) * 2017-09-08 2019-12-10 Konica Minolta Healthcare Americas, Inc. Cloud-to-local, local-to-cloud switching and synchronization of medical images and data
US20190080054A1 (en) * 2017-09-08 2019-03-14 Konica Minolta Healthcare Americas, Inc. Cloud-to-local, local-to-cloud switching and synchronization of medical images and data
US10426424B2 (en) 2017-11-21 2019-10-01 General Electric Company System and method for generating and performing imaging protocol simulations
WO2019110428A1 (en) * 2017-12-04 2019-06-13 Koninklijke Philips N.V. Imputing an outcome attribute to a pers record missing an outcome attribute using a structured situation string or unstructured case note text associated with the record
US11200968B2 (en) 2017-12-20 2021-12-14 International Business Machines Corporation Verifying medical conditions of patients in electronic medical records
US11495332B2 (en) 2017-12-28 2022-11-08 International Business Machines Corporation Automated prediction and answering of medical professional questions directed to patient based on EMR
US11031109B2 (en) 2017-12-28 2021-06-08 International Business Machines Corporation Contextual EMR based dashboard graphical user interface elements
US10812417B2 (en) * 2018-01-09 2020-10-20 International Business Machines Corporation Auto-incorrect in chatbot human-machine interfaces
US20190266235A1 (en) * 2018-02-28 2019-08-29 Charles Northrup System and Method for a Thing Machine to Perform Models
US11625533B2 (en) * 2018-02-28 2023-04-11 Charles Northrup System and method for a thing machine to perform models
US11837343B2 (en) 2018-04-30 2023-12-05 Merative Us L.P. Identifying repetitive portions of clinical notes and generating summaries pertinent to treatment of a patient based on the identified repetitive portions
US11836454B2 (en) * 2018-05-02 2023-12-05 Language Scientific, Inc. Systems and methods for producing reliable translation in near real-time
US20190340246A1 (en) * 2018-05-02 2019-11-07 Language Scientific, Inc. Systems and methods for producing reliable translation in near real-time
US11482322B1 (en) 2018-07-20 2022-10-25 MedAmerica Data Services, LLC Patient trackerboard tool and interface
US11501859B1 (en) 2018-07-20 2022-11-15 MedAmerica Data Services, LLC Patient callback tool and interface
US11935645B1 (en) 2018-07-20 2024-03-19 MedAmerica Data Services, LLC Patient trackerboard tool and interface
US11177041B1 (en) 2018-07-20 2021-11-16 MedAmerica Data Services, LLC Method and system for cardiac risk assessment of a patient using historical and real-time data
US11626192B1 (en) * 2018-07-20 2023-04-11 MedAmerica Data Services, LLC Real time parser for use with electronic medical records
US11539817B1 (en) 2018-09-27 2022-12-27 C/Hca, Inc. Adaptive authentication and notification system
US20220189619A1 (en) * 2018-10-29 2022-06-16 3M Innovative Properties Company Patient Treatment Resource Utilization Predictor
US11302441B2 (en) * 2018-10-29 2022-04-12 3M Innovative Properties Company Patient treatment resource utilization predictor
RU2699683C1 (en) * 2018-11-01 2019-09-09 Акционерное общество Инжиниринговая компания "АСЭ" (АО ИК "АСЭ") Method of constructing a distributed information system
US11862346B1 (en) * 2018-12-22 2024-01-02 OM1, Inc. Identification of patient sub-cohorts and corresponding quantitative definitions of subtypes as a classification system for medical conditions
US20200210612A1 (en) * 2019-01-02 2020-07-02 International Business Machines Corporation Policy based lifecycle management of personal information
US20200210615A1 (en) * 2019-01-02 2020-07-02 International Business Machines Corporation Policy based lifecycle management of personal information
US11775505B2 (en) 2019-04-03 2023-10-03 Unitedhealth Group Incorporated Managing data objects for graph-based data structures
US11301461B2 (en) 2019-04-03 2022-04-12 Unitedhealth Group Incorporated Managing data objects for graph-based data structures
US11593353B2 (en) 2019-04-03 2023-02-28 Unitedhealth Group Incorporated Managing data objects for graph-based data structures
US11755566B2 (en) 2019-04-03 2023-09-12 Unitedhealth Group Incorporated Managing data objects for graph-based data structures
US11669514B2 (en) 2019-04-03 2023-06-06 Unitedhealth Group Incorporated Managing data objects for graph-based data structures
US11636097B2 (en) 2019-04-03 2023-04-25 Unitedhealth Group Incorporated Managing data objects for graph-based data structures
US11322236B1 (en) 2019-04-03 2022-05-03 Precis, Llc Data abstraction system architecture not requiring interoperability between data providers
US11586613B2 (en) 2019-04-03 2023-02-21 Unitedhealth Group Incorporated Managing data objects for graph-based data structures
US11281662B2 (en) 2019-04-03 2022-03-22 Unitedhealth Group Incorporated Managing data objects for graph-based data structures
US11226959B2 (en) 2019-04-03 2022-01-18 Unitedhealth Group Incorporated Managing data objects for graph-based data structures
US11741085B2 (en) 2019-04-03 2023-08-29 Unitedhealth Group Incorporated Managing data objects for graph-based data structures
US11620278B2 (en) 2019-04-03 2023-04-04 Unitedhealth Group Incorporated Managing data objects for graph-based data structures
US20210049220A1 (en) * 2019-08-13 2021-02-18 Roumelia "Lynn" Margaret Buhay Pingol Procurement data management system and method
US11645342B2 (en) * 2019-08-13 2023-05-09 Roumelia “Lynn” Margaret Buhay Pingol Procurement data management system and method
US11837334B2 (en) 2019-08-29 2023-12-05 Shrpro, Llc Whole-life, medication management, and ordering display system
US20210209130A1 (en) * 2020-01-03 2021-07-08 HealthSnap, Inc. System and method for syncing asynchronously received sequential data from disparate sources
US11941026B2 (en) * 2020-01-03 2024-03-26 HealthSnap, Inc. System and method for syncing asynchronously received sequential data from disparate sources
US11152091B1 (en) 2020-01-31 2021-10-19 Allscripts Software, Llc Systems and methods for clinical task separation in electronic health record applications
US11688496B2 (en) * 2020-04-03 2023-06-27 Anju Software, Inc. Health information exchange system
US20210390262A1 (en) * 2020-06-10 2021-12-16 Mette Dyhrberg Standardized data input from language using universal significance codes
US11699204B2 (en) * 2020-06-30 2023-07-11 Cerner Innovation, Inc. System and method for new issue management for conversion achievement
US20210406098A1 (en) * 2020-06-30 2021-12-30 Cerner Innovation, Inc. System and method for new issue management for conversion achievement
US11694289B2 (en) 2020-06-30 2023-07-04 Cerner Innovation, Inc. System and method for conversion achievement
US11694290B2 (en) 2020-06-30 2023-07-04 Cerner Innovation, Inc. System and method for adoption tracking and intervention for conversion achievement
US20220415500A1 (en) * 2021-06-25 2022-12-29 Mental Health & Wellness Now Partners, LLC Computing Device Configured with User Check-In for Mental Health and Wellness
US11657917B2 (en) * 2021-06-25 2023-05-23 Mental Health & Wellness Now Partners, LLC Computing device configured with user check-in for mental health and wellness
US11943420B2 (en) * 2021-06-30 2024-03-26 Tobii Ab Method and system for alignment of data

Also Published As

Publication number Publication date
US11380426B1 (en) 2022-07-05
US10755802B1 (en) 2020-08-25
US10789662B1 (en) 2020-09-29
US10325335B1 (en) 2019-06-18
US11636928B1 (en) 2023-04-25
US10733684B1 (en) 2020-08-04
US10297343B1 (en) 2019-05-21

Similar Documents

Publication Publication Date Title
US20120215560A1 (en) System and methods for facilitating computerized interactions with emrs
US20110288877A1 (en) Health Information Exchange and Integration System and Methods Useful in Conjunction Therewith
US11087878B2 (en) Methods and systems for improving connections within a healthcare ecosystem
Steele et al. Personal health record architectures: technology infrastructure implications and dependencies
AU2004211771B2 (en) System, method, and computer program for interfacing an expert system to a clinical information system
Marcos et al. Solving the interoperability challenge of a distributed complex patient guidance system: a data integrator based on HL7’s Virtual Medical Record standard
US20140195258A1 (en) Method and system for managing enterprise workflow and information
US20150039343A1 (en) System for identifying and linking care opportunities and care plans directly to health records
US20070244904A1 (en) Method and Architecture for Goal Oriented Applications, Configurations and Workflow Solutions on-the-Fly
Muñoz et al. Proof-of-concept design and development of an EN13606-based electronic health care record service
Anderson et al. Implementation of a deidentified federated data network for population-based cohort discovery
US10747399B1 (en) Application that acts as a platform for supplement applications
US10847256B2 (en) System and computer program for healthcare information management in a multi-party healthcare network
Donahue et al. Veterans health information exchange: successes and challenges of nationwide interoperability
Hosseini et al. A service oriented architecture approach to achieve interoperability between immunization information systems in Iran
Kunnappilly et al. A model-checking-based framework for analyzing ambient assisted living solutions
Katehakis et al. Personal Health ICT Systems to Support Integrated Care Solutions
VASILĂŢEANU et al. Towards an agent-oriented architecture of the digital healthcare ecosystem
US20210110918A1 (en) Medical event contextualization and error detection system
US20240105322A1 (en) Software application to standardize access to surgical procedure inventory benchmarks and data collection and implementation of surgical procedure benchmarks for tray rationalization and supply optimization
US20210193308A1 (en) Continuous Improvement Tool
Sousa Big Data and real-time knowledge discovery in healthcare institutions
Martínez Millana ASSESSMENT OF RISK SCORES FOR THE PREDICTION AND DETECTION OF TYPE 2 DIABETES MELLITUS IN CLINICAL SETTINGS
Gonçalves Desenvolvimento de uma Infraestrutura baseada em HL7® FHIR® para Interoperabilidade Clínica
Siqveland et al. Integrating Telemedicine Solutions with Electronic Health Records; Evaluation of Alternatives based on the Proposed Reference Architecture for Norway

Legal Events

Date Code Title Description
AS Assignment

Owner name: DBMOTION LTD., ISRAEL

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:OFEK, ZIV;BEN-TAL, SHIRI;ACKERMAN, YURI;AND OTHERS;SIGNING DATES FROM 20111009 TO 20111016;REEL/FRAME:027117/0674

AS Assignment

Owner name: DBMOTION LTD., ISRAEL

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:OFEK, ZIV;BEN-TAL, SHIRI;GOME, ZIV;AND OTHERS;SIGNING DATES FROM 20130902 TO 20131006;REEL/FRAME:032228/0171

AS Assignment

Owner name: ALLSCRIPTS SOFTWARE, LLC, ILLINOIS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:GREENBERG, EYAL;REEL/FRAME:041320/0329

Effective date: 20161206

STCB Information on status: application discontinuation

Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION