Does the RIM Really Protect HL7 from the Proliferation of ‘Local Segments’?

From the HL7 Terminfo forum we read the following (posted by Rik Smithies) about the extension to the RIM created by the Connecting for Health initiative in the UK:

Statement Relationships are a UK/CFH invention I believe, that hasn’t gained wide acceptance elsewhere, perhaps because there hasn’ been a strong push, perhaps because our requirements are different, and perhaps because there are other ways to achieve the same thing.

Background :
A Statement Relationship is an Act that works as an Act Relationship. It’s an Act plus a pair of Act Relationships to Act References, that all stands in for a single Act Relationship.

Since it is an Act in its own right and uses ActRefs, it’s doesn’t have to be ‘in-line’ in the XML, and so can be sent separately ie. in a different message. They can have authors that are different from the Acts they relate together and can be updated or removed like any Act.

They have been used for :

1. ‘after the fact’ assertions of links/relationships
a) to allow not having to resend the acts that are being linked
b) to allow breaking the link between two acts (remove the linking act, remove the relationship)
c) to allow a different author from either act to assert the link

2. Allowing coded vocabs of relationship types, rather than using the small group of ActRelationshipTypes

I don’t fully understand how other solutions to 1a) and 1b) work, but I have heard that it is covered by controlActs, possibly in conjunction with updateMode.

A driver for 1a) was to avoid sending the Acts that are being referenced, firstly for message size reasons (though in fact Statement Relationships are physically large). Secondly and more importantly to avoid sending other people’s Acts, so as not to appear to be authoring them, and to avoid re-stating them out of context, without their associated statements, participations etc. I’m prepared to believe there are more elegant solutions to those problems.

1a and 1b are particularly helpful for larger structures that are prone to needing re-organisation, eg problem lists. You may want to move Acts from one list to another, without changing (or ideally restating) any of the Acts themselves. This is common in UK General Practice.

I have heard it stated that 1c) isn’t a requirement that many people need, so perhaps the use case just hasn’t been recognised yet.

2) is the case the Ed mentions. If there is no act relationship type of ‘probable cause’ then you can make a SNOMED code of that and use a statement relationship. My worry is that this is a very CFH specific mechanism. But maybe this is a case that an only be covered with such a construct, and if so it needs exploring further.

I am not troubled by the extension of the RIM. Indeed, as will be already clear, I believe that the RIM is urgently in need of a number of major extensions (for example in order to eliminate its current identification of a disease with its own observation). But I am still puzzled by the idea of a ‘Statement Relationship’ as ‘an Act that works as an Act Relationship’.

Is HL7 v3 Teachable After All?

I am pleased to have the opportunity to include in this blog a report of positive experiences with the HL7 v3, received from Marek Vaclavik, who writes:

… most of my colleagues disagreed on your learnability assessment of the HL7 v3 technology. Using HL7 v3 as a messaging standard does not require a profound knowledge of the HL7 Development Framework or the RIM itself. Our team are of the opinion that HL7 v3 can be learned with a reasonable amount time and effort invested. We consider a training program of one week, such as one we received from an external consultancy company, sufficient for the first contact with the whole topic. Focusing on the messages, the HL7 v3 technology is not more complex than any other XML based document format defined per XML-Schema. Errors in the documentation are, of course, annoying. But as far as we can tell, they are not more frequent or more severe than in other specification we get to see, such as vendor documentations. We would like to thank you for sharing the results of your work with us and hope to see you continuing it. Constructive criticism and open discussion are necessary prerequisities to make HL7 v3 a fully mature and broadly accepted piece of standard.

With kind regards

Marek Václavík,
InterComponentWare AG, Walldorf, Germany.

Comments on this and other postings are more than welcome. One immediate thought is that, to create HL7 V3 implementations, and indeed to teach HL7 V3, it is still necessary to understand (for example) the documentation of the RIM itself. And this, as HL7 leaders have agreed, leaves much to be desired in the way of understandability.

Diseases as Dependent Continuants

In a comment submitted to this blog, Dr William Goossen, researcher and consultant at Acquest Research, Development and Consulting in the Netherlands quotes from my remark in a ">previous posting to the effect that the RIM could effect considerable improvements by adding a new backbone class, called ‘Dependent Continuant’ since this would allow a coherent treatment of diseases, which could be classified under this heading, leaving observations of disease to be classified, properly, as Acts. The new class of Dependent Continuant could then include not only diseases but also qualities such as temperature, blood pressure, etc.

As Dr Goossen would have it:

Currently the comments refer to the RIM. However, the actual standards are based on the RIM and formed in the Domain Message Information Models (D-MIM). For example the Care Provision D-MIM. The structure suggested above is already in there. It is called clinical or care statements and it allows to express any observation and each observation can be linked to another, e.g. a disease (value pneumonia) can be visible through observations of temperature (e.g. value 39 degrees Celcius), breathing pattern (e.g. shorness of breath), x-ray (showing the pneumonia in the lungs) etc. The suggestion to have this additional class is therefore not necessary at all. This disease and its underlying observations on which the clinician has based his conclusion of "pneumonia" can further be linked to the treatment given and can be tracked in the care statement collector. In other words: what you ask for is already in the HL7 v3 standard, but the RIM is not the whole standard. You look at the wrong sections .

As Werner Ceusters points out, however, if Dr Goossen is right about the Care Provision D-MIM, then this is one more reason why the Dependent Continuant class should indeed by added to the RIM forthwith. This is because HL7 itself asserts that:

The Domain Message Information Model (D-MIM) is a subset of the RIM that includes a fully expanded set of class clones, attributes and relationships that are used to create messages for any particular domain.

If the D-MIM is a subset, then surely it cannot add anything.

It is however gratifying to see that, by the evidence of this D-MIM, HL7-ers working in the area of patient care have recognized that entities such as diseases, temperature qualities and the like, which exist longer than any observation, cannot themselves be identified as observations. They have thus created the notion of Condition, which they define as:

An observable finding or state that persists over time and tends to require intervention or management and is, therefore, distinguished from an observation made at a point in time.

This definition is in line with our proposal according to which a Condition (Dependent Continuant) is something out there on the side of the patient.

But there are problems with the definition nonetheless. First, there are presumably (for example in the very early stages of most every disease) Conditions at the molecular level which are not observable. Second there are Conditions – for instance a normal temperature, a normal blood pressure – which do not ‘tend to require intervention or management’.

Moreover, there are problems with the D-MIM documentation, for example when it asserts that ‘if a state or observation is used as a “reason” for intervention or management, it qualifies as a “Condition.”’ First, what if a state (e.g. of chronic depression) is not ‘used as a “reason” for intervention or management’ – is it then not a Condition? Second, must it not quite generally be the case that Conditions exist prior to any Acts in which they are used as reasons for intervention? Thirdly, we are told in the just-quoted passage that observations themselves can be instances of Condition (which means, given what we assume to be the rules governing the RIM’s backbone classes) that Conditions themselves would have to be accepted, after all, as a subtype of Act, which brings us back to the very same confusions with which we started.

Question, therefore, for Dr Goossens and the authors of this D-MIM: Is what has been added here truly a special kind of Act, called ‘Condition’? And if so, is it reasonable to identify, e.g. a chest pain in a patient as an Act? And if so, who is the agent of this Act?

HL7 RIM: Still an Incoherent Standard ?

The paper

• Barry Smith and Werner Ceusters “HL7 RIM: An Incoherent Standard” (MIE 2006), Studies in Health Technology and Informatics, vol. 124, 133–138

was presented at the Medical Informatics Europe conference in Maastricht on August 28. The powerpoint slides from the presentation are available here.

Gratifyingly, Gunther Schadow's talk at the conference embraced the view that the RIM should henceforth be a standard based on realist ontology. Thus biomolecules, he argued, should be treated not as Acts of observation (as is done currently by HL7's Clinical Genomics WG), but rather as Entities. We are hoping that the two conflicting views of biomolecules and similar items in RIM-based artifacts will now be reconciled in these terms, so that biomolecules (etc.) will henceforth always be classified under Entity, while acts of observation of biomolecules will be classified, straightforwardly, as Acts of observation.

We are hoping, in the same spirit, that the RIM will now add a new superclass of the Act class, which I propose should be called 'Event'. 'Act' could then henceforth be applied only to those Events which are intentional actions. This new superclass could be applied for example to snakebites, floods, fires, processes of infection, and other items hitherto problematic for the RIM. HL7 could then use Event, for the snakebite event, and Act of observation for: Act of observation of the snakebite event.

We are hoping, finally, that the new more realistic RIM will add a new, class called Dependent Continuant (for those continuant items which are not Entities because they are not made of physical parts). This would allow a coherent treatment of diseases, which could be classified by the RIM as Dependent Continuants, leaving observations of disease to be classified, again, under: Act of observation. The new class of Dependent Continuant could then include not only diseases but also qualities such as temperature, blood pressure, etc.

Adding the two new classes of Event and Dependent Continuant would thereby bring the RIM still closer to a realist ontology, and thereby yield a great boost in coherence. For reasons stated briefly in part 2 of this, and at greater length here, it would also add to the RIM's ability to support logical reasoning -- since items in reality would no longer be confused with observations.

Postscript (July 16, 2008)

I still see no evidence that the small proposed changes described in the above have even been considered by the wider HL7 community, in spite of the recognition by Gunther Schadow of the benefits that they would bring. On the other hand, further evidence of the problems created by the existing dual framework continues to accumulate. Is the RIM a representation of healthcare information or a representation of the healthcare entities about which such information is collected? From one side HL7' s answer to this question seems to be (in my view, absurdly): there is no difference. From another side, there is confusion and consternation, as illustrated by the following exchange:

From: Koisch, John [USA]
Sent: Wednesday, July 09, 2008 1:17 PM
To: arb
Subject: FW: Entity states and Roles

ArB,

An issue has emerged in the context of the NCI specification of a Person Service (a specification that the ArB is planning on using as an example of the type of specifications that would be produced as ballotable specifications). In the current RIM world view, the creation of Entity instances is fundamentally linked to instances of Registration Acts and refers only to the actual thing rather than an electronic representation of that thing. From a RIM perspective, this means that Entities essentially only exist in the context of Roles and ultimately in Acts The issue emerges when one considers the Entity state diagram and what it means in the context of a Registration Act, i.e. how the semantics of the Entity instances life cycle and the Registration Acts process semantics are partitioned across RIM structures vs the partitioning of the same semantics in a services world.

Please feel free to simply comment on the above statement. However, for context and in the desire to express things completely, there are some attachments. I have included two alternate state diagrams that Charlie and I proposed in the longish email thread between Charlie, Lloyd, Grahame, and myself. And apologies in advance for the lack of presentation of those threads ... there were too many to include and it is difficult to really pull them apart. However, a rough representation of the issues are below
....

Issue #1

Proposition a - There is _at least_ support for having an electronic record that is created but not in the active state

Proposition b - It is likely that there is actually a "pending" state in addition to the inactive and active states that are defined.

Reply - There is a big difference between a person's record (business conception) and the RIM.Person. RIM Persons (and other RIM.entities) essentially only ever exist in the "Active" state or the "Nullified" state.

Conclusion - there seems to be a fundamental disconnect between RIM.Entity, its states, and the way most IT people see entity. The disjoin is exacerbated by the RIM.Entity state machine that does not seem to refer to real entities (it does refer to their representations), even though the RIM uses RIM.Entity only as it pertains to real people. Lloyd maintains that the RIM.Entity cannot, in fact, contain any metadata about the person.

Issue #2

Proposition a - Entities need to be able to express their own state.

Proposition b - Entities need to be able to have states separate from the modeled RIM.Acts in which they are contained.

Reply - Lloyd maintains that RIM.Entity State is trivial (either null or active) and that at any rate, it is only valid to speak of entities in the context of an Act, say, a registration Act.

Rejoinder - But this is a fundamentally different notion than that maintained by most, if not all, of the IT community. And this does not translate to an architecture where systems are distributed.

Reply to the Rejoinder - Grahame holds that it may be that in a services world, a lot of the context that is held in the Act may exist in the service contract.

Conclusion - If Grahame is correct, then this still begs the question of what it means to be compliant to the RIM. Additionally, since services support unity of purpose and non-arbitrary virtualization boundaries, it also is worth asking why we need to create an entity using an "Act"? These are really two ways of asking the same question, though.

Comments welcome and encouraged.

John Koisch

From
http://lists.hl7.org/read/messages?id=93429
http://lists.hl7.org/read/messages?id=93162