A computer-implemented system, methods and computer storage media are provided for creating extensible data structures for rule based systems to improve complex event processing. An underlying individual data model is accessed and the content is translated to create singleton values to be utilized in complex event processing to improve the execution fo the complex event processing.
|
10. One or more non-transitory computer storage media having computer-usable instructions that, when used by one or more computing devices, cause the one or more computing devices to perform a method creating extensible data structures for rule based systems to improve complex event processing, the method comprising:
accessing, at a core product, an underlying individual data model containing medical content;
automatically translating, at a content translator, the content from the underlying individual data model into pluggable content that is functionally related to a disease or medically interesting concept, the pluggable content released independently of the core product and not requiring updates to the core product or the content translator, the pluggable content comprising singleton values, wherein a singleton value of the singleton values comprises a static field when the singleton value is a hot spot or a dynamic field when the singleton value is not a hot spot, the hot spot indicating the singleton value triggers a threshold amount of processing or an evaluation in rule conditions;
utilizing the singleton values for rules in a rete model; and
utilizing the results of execution of the rules of the rete model in a complex event processing system to improve the execution of the complex event processing system.
1. A computer-implemented system for creating extensible data structures for rule based systems to improve complex event processing, the computer-implemented system comprising:
a processor; and
a non-transitory computer storage medium storing computer-usable instructions that, when used by the processor, cause the processor to:
access, at a core product, an underlying individual data model containing medical content;
automatically translate, at a content translator, the content from the underlying individual data into pluggable content that is functionally related to a disease or medically interesting concept, the pluggable content released independently of the core product and not requiring updates to the core product or the content translator, the pluggable content comprising singleton values, wherein a singleton value of the singleton values comprises a static field when the singleton value is a hot spot or a dynamic field when the singleton value is not a hot spot, the hot spot indicating the singleton value triggers a threshold amount of processing or an evaluation in rule conditions;
utilize the singleton values for rules in a rete model; and
utilize the results of execution of the rules of the rete model in a complex event processing system to improve the execution of the complex event processing system.
5. The system of
6. The system of
determining if the singleton value newly meets or does not newly meet criteria for being processed by the rete model.
7. The system of
8. The system of
9. The system of
14. The media of
15. The media of
determining if the singleton value newly meets or does not newly meet the criteria for being processed by the rete model.
16. The media of
17. The media of
18. The media of
|
|||||||||||||||||||||||||
This application is a non-provisional of U.S. Provisional Application Ser. No. 62/181,600 filed on Jun. 18, 2015, the entirety of which is hereby incorporated by reference herein.
An approach for translating clinical content to rules evaluated with a RETE algorithm is provided. The analysis is directed to the specific context of generating complex event processing (CEP) rules, for instance for TIBCO BE, but most if not all of the fundamental complexity issues in CEP would be exist in any RETE implementation even if it was batch based and not (real time) event based. Embodiments of the present invention apply to both batch rule based solutions and event rule based solutions.
Embodiments of the present invention will apply to other content if some or all of the key assumptions are met. This analysis is about the cost of evaluating rules and not about the actions/interventions taken when conditions are true. In examples, actions/interventions are simply messages to the console. This is done to keep the examples simple.
The subject matter of the present invention is described with specificity herein to meet statutory requirements. However, the description itself is not intended to limit the scope of this patent. Rather, the inventors have contemplated that the claimed subject matter might also be embodied in other ways, to include different steps or combinations of steps similar to the ones described in this document, in conjunction with other present or future technologies. Moreover, although the terms “step” and/or “block” may be used herein to connote different elements of methods employed, the terms should not be interpreted as implying any particular order among or between various steps herein disclosed unless and except when the order of individual steps is explicitly described.
An exemplary computing environment suitable for use in implementing embodiments of the present invention is described below. An exemplary computing environment (e.g., medical-information computing-system environment) with which embodiments of the present invention may be implemented is provided. The computing environment is merely an example of one suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the computing environment be interpreted as having any dependency or requirement relating to any single component or combination of components illustrated therein.
The present invention might be operational with numerous other purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that might be suitable for use with the present invention include personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above-mentioned systems or devices, and the like.
The present invention might be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Exemplary program modules comprise routines, programs, objects, components, and data structures that perform particular tasks or implement particular abstract data types. The present invention might be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules might be located in association with local and/or remote computer storage media (e.g., memory storage devices).
The computing environment comprises a computing device in the form of a control server. Exemplary components of the control server comprise a processing unit, internal system memory, and a suitable system bus for coupling various system components, including data stores, with the control server. The system bus might be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus, using any of a variety of bus architectures. Exemplary architectures comprise Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronic Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus, also known as Mezzanine bus.
The control server typically includes therein, or has access to, a variety of non-transitory computer-readable media. Computer-readable media can be any available media that might be accessed by control server, and includes volatile and nonvolatile media, as well as, removable and nonremovable media. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by control server. Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer-readable media.
The control server might operate in a computer network using logical connections to one or more remote computers. Remote computers might be located at a variety of locations in a medical or research environment, including clinical laboratories (e.g., molecular diagnostic laboratories), hospitals and other in individual settings, veterinary environments, ambulatory settings, medical billing and financial offices, hospital administration settings, home healthcare environments, and clinicians' offices. Clinicians may comprise a treating physician or physicians; specialists such as surgeons, radiologists, cardiologists, and oncologists; emergency medical technicians; physicians' assistants; nurse practitioners; nurses; nurses' aides; pharmacists; dieticians; microbiologists; laboratory experts; laboratory technologists; genetic counselors; researchers; veterinarians; students; and the like. The remote computers might also be physically located in nontraditional medical care environments so that the entire healthcare community might be capable of integration on the network. The remote computers might be personal computers, servers, routers, network PCs, peer devices, other common network nodes, or the like and might comprise some or all of the elements described above in relation to the control server. The devices can be personal digital assistants or other like devices.
Computer networks comprise local area networks (LANs) and/or wide area networks (WANs). Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet. When utilized in a WAN networking environment, the control server 102 might comprise a modem or other means for establishing communications over the WAN, such as the Internet. In a networking environment, program modules or portions thereof might be stored in association with the control server, the data store, or any of the remote computers. For example, various application programs may reside on the memory associated with any one or more of the remote computers. It will be appreciated by those of ordinary skill in the art that the network connections shown are exemplary and other means of establishing a communications link between the computers (e.g., control server and remote computers) might be utilized.
In operation, an organization might enter commands and information into the control server or convey the commands and information to the control server via one or more of the remote computers through input devices, such as a keyboard, a microphone (e.g., voice inputs), a touch screen, a pointing device (commonly referred to as a mouse), a trackball, or a touch pad. Other input devices comprise satellite dishes, scanners, or the like. Commands and information might also be sent directly from a remote healthcare device to the control server. In addition to a monitor, the control server and/or remote computers might comprise other peripheral output devices, such as speakers and a printer.
Although many other internal components of the control server and the remote computers are not shown, such components and their interconnection are well known. Accordingly, additional details concerning the internal construction of the control server and the remote computers are not further disclosed herein.
The methods, systems and computer readable media, described herein, are directed to improving a technological process. As described in more detail herein, embodiments of the present invention improve the functioning of a computer itself. In particular, the extensible data structures for rule based systems described herein improve the processing time and throughput of a rules based system.
For the purpose of this analysis, three main parts are distinguished from the content perspective.
Distinguishing between two data models:
These are key terms used repeatedly within this document.
Key Assumptions
Assumption 1. Rules are based on variables which have zero or one values.
Assumption 2. There is an underlying Individual Data Model that is assumed by the content but not defined by it.
Assumption 3. If the language (grammar and/or semantics) of how content is received and the individual data model do not change, then Pluggable Content can be generated with the Content Translator with no change to the Core Product.
Assumption 4. If the language (grammar and/or semantics) of how content is received and the individual data model do not change, then the Rete Data Model should not have to be updated.
For example, where each individual has a most recent height and weight and we have a rule that if their BMI is 30 or higher than a care manager contacts them about weight management.
Referring to
In such a simple example the “Multiple Concepts” approach is unusual but this approach does have attraction in many real scenarios. With reference to
For those who are unfamiliar with TIBCO's CEP rules but understand rules in general, the example in
You could write it that way but if you do it reduces the CEP engines ability to optimize the evaluation (it forces the left of the “and” to be evaluated before the right). Priority is just used to determine the order to evaluate rules when multiple are true.
Given that in practice we expect Np to be 100,000 plus (and potentially millions) and that we expect than 3 variables (SingletonValue), the conclusion to a design of the Rete Data Model which involves results in more than one individual concept (linked by a individual ID) in rules is untenable.1 1 Theoretically, if there is a second patient concept which is very sparse (substantial majority of patients have no values), then this conclusion can be challenged, but practically the conclusion is sound.
Design Constraint 1 All individual data used within the conditions of a rule must come from one concept.2 2 This implies that if you need patient data from another concept, the suggested approach is to do a query from the when clause. However, a goal of the design of the Rete Data Model should be to minimize if not eliminate cases where this is needed.
Impacts of “SingletonValue” in Content
Any realistic rules based on a realistic underlying Patent Data Model are unlikely to meet Design Constraint 1. Certainly many desirable rules (including the example below) based on HL7 vMR or FHIR would violate this constraint. However it is possible to define a concept of SingletonValue and write rules that meet this constraint. SingletonValueSingletonValue are calculations against the Individual Data Model. A key attribute of SingletonValue with the attribute that for a given individual it corresponds to either zero or one value. An Example of an SingletonValue is “Most Recent Weight”. If there is no weight there is no value (zero) but otherwise there is exactly one value.
A more detailed continuation of the obesity content example is provided. This version will be based on the vMR model.
Consider a design for the Rete Data Model which has a individual concept with a field for each “SingletonValue” in the content. Given the property of SingletonValue having zero or one value and the expression of a rule is based upon SingletonValue, Assumption 1 is easy to meet. The astute reader will note that this approach is clearly violating Assumption 4. We will address Assumption 4 later but ignoring it for now allows for a cleaner presentation of the concepts involved. The key concepts can still be met when we add Assumption 4 in later.
Using this approach the concepts used for this example are shown in
This Concept design has a subset of the vMR model with simplified inheritance (ClincalStatement and ObservationResult) with a non-vMR individual Concept to bind things together. Note Individual uses these concepts as “ContainedConcepts”. If you use “ConceptReference” then accessing the sub-fields of those fields in the “when” clause of rules is not allowed by TIBCO BE. Using this model, the obesity rule can be written as shown in
This clearly meets Design Constraint 1 and results in the desired constant, O(1), amount of work when processing a individuals height or weight. However, it still needs to be explored how to get from vMR to the SingletonValue value in a constant amount of work for a given ClinicalStatement. In this example there are two Singleton Value.
1. Weight_kg
2. Height_m
The approach taken here is to assume there is an event that corresponds to a complete ClinicalObject in vMR. The events may be created using any variety of techniques. They can be events and not concepts as they are only used to populate values in the individual concept for Singleton Value “variables” and hence can be ephemeral. In the sample code there is an html page that creates these events for testing purposes.
The event structure used is shown in
There is one rule for all events and a rule for each Singleton Value. The rule for all events simply creates an empty Individual Concept if none currently exists as shown in
Notice that these have the nice property that there is only one Event/Concept in the when clause, so processing these is constant time, O(1). There is still a need to address the issue of whether similar properties can be obtained for every SingletonValue (this will be addressed in a subsequent section), this example is a very common type of SingletonValue and this will work well in this case. There is still the problem that what is outlined here violates assumption 4. This is addressed in the next Section.
“SingletonValue” and Assumption 4
If the Concept Model is updated every time a new SingletonValue is encountered, the approach in the previous section can be applied. Multiple concepts and linked by IndividualID is not a viable approach. The alternative is change the height and weight fields in Individual from being static “compile time” fields to be dynamic “run time” fields. In one example, an expression in is replaced in the rule condition (when clause) like:
individual.height_m
with one like:
getObsRes(individual, “height_m”)
An exemplary reasonable solution for this is described in more below. However, it will be appreciated that other solutions may depend on what Rete system is being used.
The approach is to assign a unique integer at run time to each field (specified by a field name string). These numbers start at 0 and go up to Nf−1, the number unique dynamic fields that have been seen so far. A simple data structure and rule functions are provided which efficiently find the position for a given field name. Values are stored in an array at the position for its field name. The goal is to come up with two functions (Rule Functions in BE):
A hashtable would be an example. In another embodiment, using a concept for each field name and using Instance.getByExtId(id) and using appropriate @extId (external ids of concepts) to allow O(1) lookup is provided. However, Instance.getByExtId cannot be used in a Rule Function which is used within a rule condition (“when” clause). So this approach is viable for the “set” function, it does not work for the “get” function. It is also possible other Rete systems might support this approach. Below it was not used in the “set” but it can be used to make that function more efficient. However, there will be many “gets” for every “set”, so at some level, a different (faster) lookup for “set” might not be worth the programming/maintenance effort. A sorted dynamic (extendable) list of field names is used and a binary search is inherently O(log(Nf)) in worse case.
The concepts used for maintaining the dynamics fields are shown in
There are two main choices of where to store FieldMetaData. The first choice is in a singleton concept which effectively makes it a global for all individuals. The second choice is to have a local FieldMetaData for each and every individual. In this section the examples are using the first approach. The following chart documents the made tradeoffs of these alternatives. In some instances, the Singleton approach may be more practical (for TIBCO BE, other Rete engines may be different).
For each vMR object supported an array of the corresponding Concept is added for that object. So in this example when using ObservationResults would give the following design of
Given all these concepts, the Rule Functions needed to implement the “get” and “set” method is outlined. A number of functions are used to make this happen. First are the ones which are needed once (the names of these are prefixed with “_”) and last are the ones needed once per vMR object type supported.
_lookupFieldPos takes a field name and a sorted list and it finds the element in the list doing a binary search. Its validity is CONDITION as it will be used (indirectly) in the “when” clause of rules. Negative return values are slightly tricky. An example of a negative value is provided in the explanation of _lookupFieldPosDecode shown in
lookupFieldPosDecode takes a result returned by _lookupFieldPos and if it was negative converts it to the positive value where it should be located. If I want to add “c”, “a,b,d” it should be added at third position which is 2 since the first position is 0. Given that _lookupFieldPos(“c”, “a,b,d”) will return-3 and lookupFieldPosDecode(_lookupFieldPos(“c”, “a,b,d”)) will return 2 as shown in
_lookupField takes a field name and a sorted list of fields and returns the field with that field name or null if it is not in the list. Its validity is CONDITION as it will be used (indirectly) in the “when” clause of rules as shown in
_getFieldExtIdPre takes a field name and returns a unique external id for it. The implementation of this is uninteresting and left out. However it is O(1) assuming the max number of characters in a field name is a constant (which I am assuming).
_lookupAndInsertField takes a fieldname, sorted list of fields, and the type of the field in case it needs to create the field. It is the same as _lookupField except it never returns null and will create the field and add it to list of fields if it does not find it. If added to the list, the list will still be sorted after. Modifying concepts in a condition/when clause is not allowed which is why there is both a lookup (for when clauses) and a lookupAndInsert (for actions clauses) as shown in
In TIBCO CEP rules, arrays are extendable. If I have an array arr of size Z (arr @length), it has values arr [0] to arr [Z−1]. However if I assign to arr [Z], the array becomes size Z+1. This is utilized in the above code which for people who do not know about this property could be confusing. For the moment, ignore the “for” loop. There is a constant amount of work plus calls (one each) to _lookupFieldPos [O(log(Nf))], _getFieldExtIdPre [O(1)], _lookupFieldPosDecode [O(1)], the “arr[arr@length]= . . . ” to extend the array [O(1)]4, and the Field constructor which should also be O(1). This nets out to O(log(Nf)).
The body of the loop is O(1) obviously, so the number of times the loop iterates is key. This is worst case O(Nf) even amortized. However, let Ns be the number of times a “set” function is called with dynamic fields. The “for” loop in a non-amortized sense clearly is executed in the worst case O(Nf). However, in the Singleton FieldMetaData across all “sets” there can be at most O(Nf2) iterations of the body of the loop. This is because there can only be Nf times a new field can be seen (by definition of Nf) and Nf is the worst case for each one of them. So the total cost of is O(Ns+Nf2) for Ns “sets”. If Ns=Ω(Nf2) then5 this is O(Ns) for Ns “sets” and amortized O(1). Empirically in my sample implementation, the overhead of this is acceptable. Currently it is estimated that 796 fields can be supported (of all vMR types, 206 max for any one type) and even at 2 orders of magnitude bigger it still reasonable performance. Total is the total time to add all the fields as shown in
In the one FieldMetaData for each individual case a field can be new for each individual so you get O(Np*Nf2) over all “sets” but Nf is a local (per individual) number of fields not global. It is possible but far from clear that the same O(1) amortized for the “for” loop exists in this case (if Ns=Ω(Np*Nf2) which is feasible in practice but less clear).
The remaining two functions we need once per vMR object type supported and will be used in rules.
getObsResDG takes a individual, a field name, and the singleton FieldMetaData and returns the value of that field for the individual (null if no value stored). The singleton is passed because Instance.getByExtId cannot be called in a rule function useable in “when” conditions of a rule and we need to use this function in the “when” condition as shown in
As to complexity this is clearly dominated by the call to _lookupField which O(log(Nf)).
setObsResDG takes a individual, a field name, the [new] value and the singleton FieldMetaData. It sets the value of the field. createObsRes is basically a constructor for an ObservationResult from an Event and copyObsRes copies all the fields in the Event version of the vMR object to the Concept version of the vMR object. The implementations are straight forward and omitted here but are O(1) as shown in
The cost of this is dominated by the cost of the call to _lookupAndlnsertField call and is O(Nf) but expected O(log(Nf)).
The rule is a straightforward modification of the rules with static fields. For example, one point to call out is the Concepts.DynFields.FieldMetaDatafmd_singleton;
in the “declare”. However, even though there are 2 things in the “declare” resulting in a cross product. However, since there is only one FieldMetaData there is no combinatorics concern. As written here, there is a problem with every rule having to be reconsidered if the fmd_singleton element changes (which it will when a new field is assigned) as shown in
Using Function Calls in Conditions
BE tries to be efficient in determining which rules need to be considered for addition to the agenda. It operates by a rule that if “nothing has changed” in the data used in the rule condition (when clause of the rule), then the rule doesn't even need to be considered. So for the following simple (and not realistic example because no null check is used) of
declare {
Concepts.Individual p;
}
when {
p.weight_kg.observationValue >= 100;
}
then {...}
In
declare {
Concepts.Individual p;
Concepts.DynFields.FieldMetaData fmd_singleton;
}
when {
getObsResDG(p, ″weight_kg″,fmd_singleton) >= 100;
}
then {...}
In this case since the function is treated as opaque it is assumed if any part of p changes this rule will be considered for agenda creation. This can be mitigated some by instead of passing p into getObsResDG, we pass p.dynObsRes instead6. This will restrict consideration for agenda creation to when any dynamic field stored in dynObsRes changes but if other parts of p changes, it won't be considered. However, the bigger concern is when fmd_singleton changes. When it does than every rule for every individual needs to be reconsidered. This would be prohibitively expensive. However it is also completely unnecessary since changes to fmd_singleton cannot change the evaluated result of any rule condition (when) unless a dynamic field in a individual was also changed (a change to fmd_singleton means a new field never seen before was just seen, but since it was never seen, no value for it can be stored in any individual yet). So with clever use of “forwardChain=false”, this cost can be avoided. 6 Passing p. dynObsRes directly will give a compile time error but it is possible to pass it by creatively wrapping it in a concept.
This is done by replacing not directly using the “set” function for dynamic fields (e.g., setObsResDG) but instead assert a new event to do the set. The Event model needs to be extended to have SetObservationResult inherit from ObservationResultEvent as shown in
In
In
setObsResDG(individual,fieldName,orEvent,fmd_singleton);
With of
Events.SetObservationResult setEvent =Event.createEvent
(″[magic string]″);
Event.assertEvent(setEvent);
The magic string is not useful. In BE if you mouse over the real string, hold the <CTRL> button and click the left mouse button you open the editor which shows how to create the new event. The mapping of values captured in [magic string] is8 shown in
Now to get the right behavior, two rules are created (priority is very relevant). Referring to
The second method has forward chaining on and it just sets the value for the individual (but since it has a lower priority FieldMetaData will not be updated by this method). Forward chaining on is desirable because we do want to reconsider rules that rely on this dynamic fields value as shown in
Note: Consuming the event is critical. Otherwise the rule that created this event will fire off the SetObservationResult event and loop forever. This is dangerous. Using a more complex event model (change the inheritance) can eliminate this potential infinite chain of events (if someone removed the consumeEvent or changes the priorities incorrectly). NOTE: This version of setting calls _lookupFieldPos up to 3 times from:
It is possible to rewrite the code to save the position from the first call in the Events.SetObservationResult event so that the other two calls can be eliminated. The code in the example does this.
Empirically, by averaging runs of repeatedly setting the same fields over and over again 100,000 times on the same individual, static fields sets take.053 ms, dynamic fields with direct function calls to set take 0.067 ms (28% longer), and using the set event method takes 0.106 ms (twice as long as static fields and 58% longer than direct calls). Having 2 dynamic fields verse having 2,000 makes very little difference (2 k look 4.6% longer)
In another embodiment, the cost of adding a never before seen dynamic field when there are already existing individuals is examined. Runs of this are more difficult so I did not do repeated runs to average times (hence nothing is less than 1 MS) plus there are constant overheads in the timing (same if do one or a million) that get spread out over with multiple runs. So don't react no 1 ms verse 0.053 ms above for static fields as shown in
Dynamic Field Approach
Static fields have less overhead and capture “what changed” more accurately for determining which expressions in when clauses to re-evaluate. However, adding new static fields requires bringing down the system and updating the data structures. In one embodiment, a hybrid approach should be used. For Singleton Value that are “hot spots” we should use a static field but for non “hot spot” Singleton Value or new ones we did not anticipate, we use dynamic fields. I am leaving “hot spot” vague but in spirit it is any Singleton Value which triggers a significant amount of processing (including evaluation in rule conditions (when clauses)). However, we could do the same for any Singleton Value that we anticipate if appropriate (even if it is not a hot spot).
Additionally, in an example using one dynamic structure per type, there is M per type with hash a name string into which of the M to use for that name (e.g., for a naïve model, if the ASCII code of the last character is even then use structure 1, if odd then use structure 2). This will allow BE to more exclude more rules from consideration without re-evaluating their when clauses.
Covering Full Range of Possible SingletonValue
SingletonValue could effectively be expressed a query against vMR that returns a sequence a particular vMR object type (e.g., ObservationResult) based on a condition (limited semantics, for example “or” is not possible). A function is applied to that sequence to ensure that the end result is either a single number or 1 object from that sequence. The question is how to handle any possible SingletonValue with rules. Starting conceptually, embodiments of the present invention handle when a vMR object would “newly meet” the criteria of an Singleton Value. “Newly meet” means either the vMR object didn't exist before or it did but previously the condition for the SingletonValue evaluated to false but now it evaluates to true. Embodiments of the present invention also handle the case when a vMR object would “newly not meet” the criteria of an Singleton Value. “Newly not meet”, means the vMR object existed before and the condition for the SingletonValue evaluated to true on it, however now it evaluates to false.
Embodiments of the present invention handle any Singleton Value is to a) recognize when an object “newly meets” or “newly does not meet” the criteria for an SingletonValue and b) for each function how to update the value of the SingletonValue given the “new” information.
There are three reasons an existing vMR object could “newly meet” or “newly not meet” the condition for an Singleton Value.
As for how to compute the functions, one way is to do a query to get the entire sequence and apply the function to that sequence. This is a viable approach in some cases. However, other approaches may be available that do not require a full query. In all of the following let the objects in the sequence be of type vMRType, “p” be the Concept for the relevant individual and “vo” be the Event or Concept for the vMR object being processed as shown in
“newly meets”
if (p.edVal == null || (p.edVal.dt < vo.dt) {
p.edVal = vo;
}
If one processing is more recent then use the one processing.
“newly not meets”: 1. Passage of Time
if (p.edVal == vo) {
p.edVal = null;
}
This works under the assumption that there is one time
window with no gaps when objects qualify
for inclusion in the sequence. In that case, if this was the
most recent but it no longer qualifies because it no longer
falls into the time window, we can't know of a more
recent one that does (as that contradicts that this is the
most recent).
“newly not meets”: 2. Data Change
Query to get full sequence and compute.
The only other approach is to maintain the while sequence
in “p”, but I would rather just query in that case.
“newly meets”
if (p.edVal == null || ( (p.edVal.v > vo.v) {
p.edVal --= vo;
}
If one processing is smaller, store it
“newly not meets”: 1. Passage of Time
Query to get full sequence and compute.
The only other approach is to maintain the while sequence
in “p”, but I would rather just query in that case.
“newly not meets”: 2. Data Change
Query to get full sequence and compute.
The only other approach is to maintain the while sequence
in “p”, but I would rather just query in that case.
“newly meets”
if (p.edVal == null || (p.edVal.v < vo.v) {
p.edVal = vo;
}
If one processing is smaller, store it
“newly not meets”: 1. Passage of Time
Query to get full sequence and compute.
The only other approach is to maintain the while sequence
in “p”, but I would rather just query in that case.
“newly not meets”: 2. Data Change
Query to get full sequence and compute.
The only other approach is to maintain the while sequence
in “p”, but I would rather just query in that case.
“newly meets”
p.edVal++;
One more than before.
“newly not meets”: 1. Passage of Time
p.edVal--;
One less than before.
“newly not meets”: 2. Data Change
p.edVal--;
One less than before.
“newly meets”
p.edVal.count++; p.edVal.total+=vo.v;
The average is obviously p.edVal.total/p.edVal.count
“newly not meets”: 1. Passage of Time
p.edVal.count--; p.edVal.total-= vo.v;
The average is obviously p.edVal.total/p.edVal.count
“newly not meets”: 2. Data Change
p.edVal.count--; p.edVal.total-= prev(vo.v);
The average is obviously p.edVal.total/p.edVal.count
prev(vo.v) is the before change value of vo.v. If that is
not known then will need to query to get full sequence
and compute.
“newly meets”
if (p.edVal.mostRecent == null) {
p.edVal.mostRecent = vo;
} else {
if (p.edVal.mostRecent.dt < vo.dt) {
p.edVal.previous = p.edVal.mostRecent;
p.edVal.mostRecent = vo;
} else {
if (p.edVal.previous == null || p.edVal.previous.dt < vo.dt) {
p.edVal.previous = vo;
}
}
}
If one processing is more recent then use the one processing.
“newly not meets”: 1. Passage of Time
if (p.edVal.mostRecent == vo) {
p.edVal.mostRecent = null;
p.edVal.previous =null; // C1
} else if (p.edVal.previous == vo) {
p.edVal.previous = null;
}
This works under the assumption that there is one time window with no gaps when objects
qualify for inclusion in the sequence. In that case, if this was the most recent but it no longer
qualifies because it no longer falls into the time window, we can't know of a more recent one
that does (as that contradicts that this is the most recent).
The assignment with the comment “C1” makes sense because if the most recent is too old the
second most recent is also too old and in the rare situation they have the same (or almost same)
timestamp, we cannot be sure which one will be processed first, so there is some chance it is not
null already.
“newly not meets”: 2. Data Change
Query to get full sequence and compute.
The only other approach is to maintain the while sequence in “p”, but I would rather just query
in that case.
“newly meets”
if (p.edVal == null) {
|| (p.edVal.dt > vo.dt) {
(p.edVal = vo;
}
If one processing is more recent then use the one processing.
“newly not meets”: 1. Passage of Time
Query to get full sequence and compute.
The only other approach is to maintain the while sequence
in “p”, but I would rather just query in that case.
“newly not meets”: 2. Data Change
Query to get full sequence and compute.
The only other approach is to maintain the while sequence
in “p”, but I would rather just query in that case.
As shown in
Content Translator
Content Translator: In this model content in one form (currently as XML
files) is automatically converted into Pluggable Content as defined above.
This can also be generalized into a content IDE (Integrated Development
Environment). Generalized Analogy: XCode IDE, Android Eclipse
IDE/SDK.
Core Product
Core Product: may include CareXcell or Healthe Care but does not
include the content itself. Analogy: Smart Phone.
Nc
Number of Concepts used in the rule (in the declare)
Nf
The number of unique dynamic fields that exist.
Ng
Number of times a “get” function is called with dynamic fields.
Np
Number of Individuals
Ns
Number of times a “set” function is called with dynamic fields.
Individual Data
Individual Data Model: The data model for individual medical data
Model
assumed by the content.
Pluggable Content
Pluggable Content: This is the functionality related to a disease or other
clinically interesting concept. It is released independently of the Core
Product but can also require particular versions (possibly one version) of
the Core Product to work. Analogy: Smartphone App
Rete Data Model
Rete Data Model: The data model for individual data used in the
rules/Rete network. In general this may or may not be the same as the
Individual Medical Data Model. In CEP, such as TIBCO BE, this
manifests as “Concepts” or “Events”.
The present invention has been described in relation to particular embodiments, which are intended in all respects to be illustrative rather than restrictive. Further, the present invention is not limited to these embodiments, but variations and modifications may be made without departing from the scope of the present invention.
| Patent | Priority | Assignee | Title |
| Patent | Priority | Assignee | Title |
| 10019462, | Dec 30 2011 | EMC Corporation | System and method of hierarchical archive management |
| 20110055137, | |||
| 20110225176, | |||
| 20120095300, | |||
| 20130066643, | |||
| 20140195473, | |||
| 20150019248, | |||
| 20150347914, | |||
| 20160267230, |
| Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
| Jun 20 2016 | Cerner Innovation, Inc. | (assignment on the face of the patent) | / | |||
| Apr 02 2019 | LANDI, WILLIAM | CERNER INNOVATION, INC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 048952 | /0969 | |
| Apr 17 2019 | ANAND, VIKRAM | CERNER INNOVATION, INC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 048940 | /0506 |
| Date | Maintenance Fee Events |
| Date | Maintenance Schedule |
| Jul 13 2024 | 4 years fee payment window open |
| Jan 13 2025 | 6 months grace period start (w surcharge) |
| Jul 13 2025 | patent expiry (for year 4) |
| Jul 13 2027 | 2 years to revive unintentionally abandoned end. (for year 4) |
| Jul 13 2028 | 8 years fee payment window open |
| Jan 13 2029 | 6 months grace period start (w surcharge) |
| Jul 13 2029 | patent expiry (for year 8) |
| Jul 13 2031 | 2 years to revive unintentionally abandoned end. (for year 8) |
| Jul 13 2032 | 12 years fee payment window open |
| Jan 13 2033 | 6 months grace period start (w surcharge) |
| Jul 13 2033 | patent expiry (for year 12) |
| Jul 13 2035 | 2 years to revive unintentionally abandoned end. (for year 12) |