There is a project called Config which processes all cases before they are processed by the online projects. The Config project can be used to add information to the case that is common to all of the online projects. This means you can save a lot of effort by not having to repeat the same sorts of rules in every project.
Whenever a case is received from the Online Information System, it will be processed firstly by the Config project. Any derived attribute, feature, derived feature, or report section given in the Config project for the case, will be added to the case as a primary attribute called a Config attribute.
A Config attribute can be identified by a blue arrow icon in the case view of the online project:
The value of this attribute will be the corresponding value in the Config project, that is:
Item in Config project | Value of the Config attribute in online projects |
Derived attribute | The same as the value of the derived attribute in the Config project. |
Feature or Derived feature | The same as the value of the feature in the Config project, i.e. true or false. The value will appear in the current episode only. |
Report Section | The text of the comment in that report section. If there is more than one comment, the value will be the concatenation of the comments. The value will appear in the current episode only. |
A Config attribute can be used in an online project in exactly the same way as any other primary attribute is used.
An example of when to use the Config project
Suppose that your RippleDown installation has two clinical projects: Lipids and Thyroids. Suppose both projects need to have defined a feature named Diabetic in order to identify patients with this disease.
Instead of building rules to define this feature in both clinical projects, hence repeating your work, you only have to define it once in the Config project. The Config project will automatically add this information into all your clinical projects. The way this would work is as follows:
- Open the Config project with the Knowledge Builder and define a feature named Diabetic, which is given whenever the clinical notes of a case contains the word “diabetic”. Other rules you could add to define this feature include:
- at least one fasting glucose >= 7.0 (units are mmol/L)
- at least one GTT >= 11.1
- and so on…
Note: The system will check that the name “Diabetic” does not already exist in either of the two clinical projects. If it does, you will have to choose another name.
- Suppose the Online Information System now sends a case to the Lipids project where the clinical notes for the case indicates the patient is diabetic.
- The Config project interprets the case. Because the feature Diabetic is given, the Config project adds a new Config attribute to the case named Diabetic with value “true”.
- The case appears in the Lipids project, but now with the Diabetic attribute. This can be seen in the case viewer as an attribute with a blue arrow icon.
- Similarly, if the Online Information System sends a case to the Thyroids project with attributes that trigger this feature on the Config project, the attribute Diabetic will also appear in the Thyroids case with value “true”.
Not only have you saved the effort of building this feature in all your clinical projects, but if the guidelines for the definition of diabetes change, you only have to make the changes in the one place, that is, in the Config project.
See also: How config attributes are named