Ok, so a play on words. CDISC may rule in the field of Clinical Data standards, but, it does not rule in the standardisation of rules associated with data.
Let me expand here for those not familiar with the issue.
CDISC ODM provides a syntax for the definition of metadata (and data) used in the interchange of information between (and sometimes within) systems. CDISC ODM does not scope the definition of edit check rules that are applied to the data when it is captured. I feel that is a significant omission as the rules element of the data a) take a considerable time to develop and b). provide a context to the data.
Question - So, why do we not already have rules built into the standards?
Answer - rules are often technology or vendor specific. There are almost as many methods of implementing rules, as there are EDC products.
Question - Why not define a standard mechanism for creating rules that vendors could either comply with, or, support as part of interfacing?
Answer - Well, it all depends on what you want the rules to do. In their simplest form, rules are boolean expressions that result in the production of a Query or Discrepancy. However, many systems go well beyond simply raising queries. The boolean element of the rule may be consistent, but the activity performed in the situation that the boolean returns true, is often very vendor specific.
Lowest Common Denominator
So - lets assume that we are looking at implementing a lowest common denominator of rules and actions that the majority of systems support, and require
What can we do to standardize a syntax. Three options I think;
1) Choose a syntax from one of the leading vendors,
2). Develop a new syntax building on existing ODM conventions
3). Bring in another standard syntax, potentially already in the Health or LifeScience field
Lets look at them in order.
No. 1 - Choosing a Leading Vendor Syntax is probably great for the chosen leading vendor, but, bad for most other vendors. A benefit though would be that it would already be proven as a means to represent rules and actions in a clinical study. Some syntaxes are based around standard tools such as Visual Basic for Applications, JavaScript or even SQL. This approach may create almost insurmountable boundaries for other vendor systems that do not, or cannot implement the technology - for example, it is not easy to interpret VBA on a non Microsoft platform. So - option 1 has some potential, but, depending on the chosen vendor, may result in closing the door to the standard for others.
No. 2 - Creating a new Syntax would result in something most vendors would be happy with, but, would require considerable effort from the contributors in order to develop a complete specification for the standard, as well as a reference implementation. The advantage of such approach would of course be that it would be seen as a common standard open to all, and not specifically biased to any one vendor company. In practice, the technology approach chosen would favor some more than others.
No. 3 - Leverage an existing Syntax may well bring the benefits of No. 2 without all the costs of designing something from scratch.
Ok, so lets say we go ahead with option 3 - what are the candidate standards for rules in the Health and/or LifeSciences are?
As far as I can tell, not many. In fact, I was only able to find one candidate that had any level of success - a syntax called ARDEN.
ARDEN has existed since 1989 as a syntax for describing Medical Logic. Similar to typical Rules in EDC, they are defined in Modules - Medical Logic Modules - and called based on the triggering of an event.
[For an accurate definition of ARDEN and its roots, check Google Books - search for ARDEN Syntax and examine Clinical knowledge management: opportunities and challenges By Rajeev K. Bali, Pages 209 --> 211]
As a syntax, it is mostly general purpose. Here is a snip from an Arden Syntax module,
logic:
if
then
last_creat is null and last_BUN is null
elseif
alert_text := "No recent serum creatinine available. Consider patient's kidney function before ordering contrast studies.";
conclude true;
then
last_creat > 1.5 or last_BUN > 30
else
alert_text := "Consider impaired kidney function when ordering contrast studies for this patient.";
conclude true;
endif;
conclude false;
;;
In the example, you can see that the syntax uses standard if/then/elseif/endif constructs. Assignments use the := combination etc.
HL7 have a section dedicated to ARDEN here. The activity appears to be limited with no Postings or Documentation since 2004. On walking through some of the presentations, some of the consumer companies such as Eclipsys were proposing extensions to the syntax - for example to add object definition support. It would appear that the take-up of the standard has been limited to those organizations that had a problem to solve in the EHR area, and wanted to re-use a syntax, instead of inventing their own.
The fact that HL7 has lended support for ARDEN may be sufficient in itself. However, we would need to dig considerably deeper to understand how ARDEN syntax would fit with a syntax such as ODM. The first challenge is the conversion to an XML form. There are plenty of articles on ARDEN XML for further reading.
RuleML is another standard that may address the need to create Rules, as well as meeting the perceived need of being XML based.
More about ARDEN and RuleML in a later posting I think. This one is quite long enough for today.
