[rules-users] Facts - One to Many

Wolfgang Laun wolfgang.laun at gmail.com
Thu Jan 2 12:36:06 EST 2014


As you describe it, here's the way to refer to a particular medication:

   Patient( $meds: medications )
   Medication( drugCode == "55749-003-01" ) from $meds

This rule determines whether the patient has this particular
medication. There are other operators that might be useful:

  Medication( drugCode str[startsWith] "55749-003" ) from $meds

Inserting the Medication objects with a backlink to the Patient can
simplify rule evaluation, which may depend on the number and
complexity of the rules. Compare:

   Patient( $meds: medications )
   Medication( drugCode == "55749-003-01" ) from $meds
   Medication( drugCode == "55799-565-01" ) from $meds

with

   $p: Patient()
   Medication( drugCode == "55749-003-01", patient == $p )
   Medication( drugCode == "55799-565-01", patient == $p )

Much depends on the number of facts you'll need to process.

To answer your question, "Takes" was a class name I invented to refer
to the relation as an object, and "this" is Java's "this", referring
to the matching object.

-W


On 02/01/2014, Ray Hooker <ray.hooker at me.com> wrote:
> Wolfgang,   So in your case you were envisioning the possibility of a Takes
> object that matched between a particular medication and the patient.
> Actually we are fairly close in the case of medications.
>
> As you probably know MongoDB allows for documents.   In this case, the
> patient’s document contains subdocuments.  In the case of medications, this
> semantically means “as of the date of this patient document, the patient is
> taking the following medicine listed by the applicable code and text
> description”.
>
> When read from the DB, you actually have a Java object Patient (or “Record”)
> that has a method “medications” that returns a set of “Medication” objects.
> The parent knows about the medication through the set “medications”.  I
> certainly could assert each patient/ record and for each of those assert
> each subdocument, inserting a key back to the parent.
>
> So the rule would need to identify, for example, any case where a particular
> had a medication object where the drug code matched a particular code or set
> of codes.
>
> Any suggestions are appreciated.  Also in the example below, is “Takes” a
> function  and what does “this” refer to?
>
> Thanks,
>
> Ray
> On Jan 2, 2014, at 2:01 AM, Wolfgang Laun <wolfgang.laun at gmail.com> wrote:
>
>> Ideally, a relation is represented by separate objects. Then you might
>> have
>> a rule
>>
>>   $p: Patient()
>>   $p: Takes( patient == $p, $m: medication )
>>   Medication( this == $m )
>>
>> and this rule will fire for each medication of the patient.
>>
>> Answering such questions without details about the actual data model
>> is impossible.
>>
>> -W
>>
>> On 02/01/2014, Ray Hooker <ray.hooker at me.com> wrote:
>>> I am trying to figure out how to work with an existing model. The data
>>> is
>>> in
>>> MongoDB with embedded documents.  It is about patients would have
>>> sub-documents.  For example.  An individual patient may have multiple
>>> allergies. Also a patient has multiple medications.  So it is as
>>> follows:
>>>
>>> - Patient.medications ---> multiple Medication objects
>>>
>>> So I see where you have a simple one to one.  Typically perhaps you
>>> might
>>> have the medication record know that it is associated with the patient,
>>> but
>>> that is not how it is currently organized.  So the question is can I
>>> write
>>> rules when patients.medications returns a set/ collection of medications
>>> associated with the patient. I want to write a rule such as "if a
>>> patient
>>> is
>>> taking medication=xxx...."
>>>
>>> Thanks for your help.
>>>
>>> Ray Hooker
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>



More information about the rules-users mailing list