Adverse Events are Not Observations

A further HL7-relevant issue discussed at the recent Clinical Trial Ontology workshop concerned the peculiar HL7 practice of identifying events (for example events of drug interaction) with their observations. This practice is, gratifyingly, less pervasive in the BRIDG model of protocol-driven clinical research than in HL7, but it raises its head even there, for example in the identification of adverse events as adverse event assessments at:

CTOM (imported package)::AdverseEvent
Type: Class Extends: Assessment.
Status: Proposed. Version 1.0. Phase 1.0.
Package: CTOM (imported package)
Details: Created on 1/5/2005 11:17:58 PM. Modified on 9/26/2005 2:22:53 PM.

in BRIDG Model Version 1.41.

The issue raised at the Bethesda workshop was: why does HL7 persist in instituting what, on the face of it, is an obviously false assertion, as a central pillar of its information model?

This question becomes all the more important given that, increasingly, the task of adverse event assessment will occur at geographical sites remote from the adverse events themselves -- something which is logically impossible where adverse events are identified with their own assessments. How, on the basis of such an identification could we track shortfalls (for example in hospital practices or equipment) leading to adverse events in the hospitals themselves in such a way as to distinguish them from shortfalls in practices or equipment leading to poor assessments at remote assessor sites?

Perhaps the ever resourceful ingenuity of HL7's coders can find some complex coding procedure to keep these things apart even after having already identified them; but why not keep them apart from the very start, as simplicity and realism (and learnability and economy and patient safety) would suggest?

Two answers present themselves:

1. that we have here yet one more example of the influence on early HL7 of the focus on healthcare billing -- adverse events themselves, unlike observations and assessments, cannot be billed.

2. that HL7 RIM (and to this degree also HL7 tout court) is an information model -- so that 'adverse event' means: 'information about an adverse event', 'adverse event assessment' means 'information about an adverse event assessment', and so on.

But answer 1. seems not to be in keeping with HL7's current, and much more ambitious, goals. And answer 2. does not, in fact, support the given identification, since even on this meta-level, information about an adverse event and information about adverse event assessments remain distinct, and the former is not a subtype of the latter.

HL7 and BRIDG

The NCBO organized a Clinical Trial Ontology Workshop at the NIH in Bethesda, MD on 16-17 May. Two talks, especially, were of relevance to HL7, given HL7's influential role in the BRIDG project. The first, by Werner Ceusters, pointed to certain problems with BRIDG, which might be resolved by means of a principled ontology of the clinical trial domain.
The second, by Barry Smith, raised certain issues as to the apparent conflict between what seem to be two goals underlying BRIDG, to serve both as a descriptive representation of protocol-driven clinical research and to serve as a prescriptive standardization of such research.
BRIDG representatives at the meeting pointed to the new release of BRIDG, which is due in June 2007, and in which, we are told, some of these problems will be addressed.

HL7: A Package of Decorators

"Implementation of org.hl7.rim.Role as an abstract decorator, i.e., a class that returns NULL/NA or nothing for all property accessprs (sic) amd (sic [indeed many times sic]) that raises UnsupportedOperationExceptions for all mutators. This is used to adapt custom application classes to the RIM class interfaces and only bother about mapping those properties that actually apply to the application class. This can be done in one of two ways: (1) the client class can extend the decorator directly, and implement the applicable properties, or (2) the abstract decorator can be extend (sic) to a concrete decorator, which would hold a reference to the client object and method bodies to delegate and adapt the applicable properties."

Update: July 9, 2009
The quoted package, now here, was originally posted here, where it remained for almost two years before being taken down in 2009. The misprints which it contains (including misspellings of 'and') are of interest only because they are repeated over 6o times in a single document, suggesting that the document itself was never (proof)read by any human being.