Placeholder Fact

From DOC

Rules can now be written more compactly and with less technical fluff. Placeholder (only at this point) can be referenced directly rather than via "MenuData". For example,

rule "Place observation on observation summary list"
  when
     $msObservation: MenuStructure( role == "placeholder", path == "echr:patient:observation" )
     $mdObservation: MenuData( menuStructure == $msObservation, actStatus!="nullified")
  then
     MenuData mdObsList = app.createReferenceMD( $mdObservation, "echr:patient:summary:obssum" );
end

can now be written as

rule "Place observation on observation summary list"
  when
    $obs: observation( actStatus!="nullified")
  then
    app.createReferenceMD( $obs, "echr:patient:summary:obssum" );
end

By removing literal strings, more checking is done at rule compile time (configPhase3). Also, the observation is returned as a (new) PlaceholderFact rather than the more generic MenuData class. The name of the fact, such as "observation" is the name of the placeholder which must be unique within an account type. For this reason, each rule module using PlaceholderFacts should be limited to rules about one AccountType.

To activate PlaceholderFact behavior in a particular rule file, add a Doclet-style annotation to the rule file like this:

package echr
//@use echr placeholders

This directs the rule compiler to include all placeholders from the "echr" metadata (in this case).

Note: This inserts additional facts (PlaceholderFacts) in addition to the usual MenuData facts. Therefore, when adding a rule such as described above, you mush also remove the "MenuData" rule, otherwise, both will be fired. This allows both styles of rules to coexists. For example, some capabilities are not yet supported in PlaceholderFacts. Indeed, the new PlaceholderFacts are designed to be more restrictive.

Fields can also be referenced in rule conditions by name rather than the arcane "string01" style. The following shows the test field and the effectiveTime fields being referenced from an observation, as defined in the echr-patient.application.xml file.

rule "Test PlaceholderFact"
  when
    observation( $test: test, $effectiveTime: effectiveTime )
  then
    app.info( "Observation " + $test + " " + $effectiveTime); 
end

Dots can be used to chain references to other placeholder when defined in metadata. For example, an observation is usually a component of the patient object. Therefore, you can directly access fields of the patient placeholder from the observation placeholder.

rule "Test PlaceholderFact with dots"
  when
    observation( $patientName: patient.lastName )
  then
    app.info( "Observation for LastName: " + $lastName ); 
end

Access to the underlying MenuData from the PlaceholderFact is also provided. For example:

    observation( $md: menuData )

However, direct access to MenuData is now discouraged.

The PlaceholderFact approach performs datatype checking. There are two methods used to determine the datatype (Java Class). If neither of these methods yields a more specific result, then the datatype will be a generic Object. In any case, the rule consequence can cast variables when needed. The implicit method is based on the known datatype of pre-defined "internal" fields. For example, when accessing the lastName of a patient, which by default is stored in the internal column called "string01", can be inferred to be a string.

The explicit method applies to fields that do not use internal fields, so called extended fields. A placeholder field definition can contain one of the following types:

• string
• date
• long
• double
• placeholder - Reference to another placeholder
• AD - HL7 Address datatype
• CD - HL7 Concept descriptor datatype
• ED - HL7 Encapsulated Data datatype
• INT - HL7 Integer datatype
• PQ - HL7 Physicial Quantity datatype
• REAL - HL7 Real datatype
• TEL - HL7 Telecom address datatype
• TS - HL7 Point in Time datatype

For example, a normal string field definition might look like this:

   <field name="homeAddr1" internal="_extended" type="string">
       ...
   </field>

Making it an HL7 AD datatype would look like this:

   <field name="homeAddr" internal="_extended" type="AD">
       ...
   </field>