How does one refer to an organism in a microbiology report?

Is an organism an entity? Or an observation of an entity (thus, presumably, an observation of an organism)? Can it really be true that, after ten years of HL7 RIM development, the answer to this question is still not clear?

As the useful Resources page of HL7 Australia makes clear:

At first site the RIM is quite simple. The RIM backbone has just five core classes and a number of permitted relationships between them.In HL7 V3, every happening is an Act, which is analogous to a verb in English. Each Act may have any number of Participations, in Roles, played by Entities. These are analogous to nouns. Each Act may also be related to other Acts, via Act-Relationships.Act, Role and Entity classes also have a number of specialisations. For example, Entity has a specialisation called Living Subject, which itself has a specialisation called Person. Person inherits the attributes of both Entity and Living Subject.

Organism, too, is a specialization of Entity, we might reasonably suppose. Thus an organism is not a Role, not a Participation, not a Relationship, and also, we presume, not an Act. That an organism is an Entity is indeed the view embraced by advocates of HL7 in their oral discussions with me over the question whether the RIM can be taken seriously as a representation of the healthcare domain.

Not so for everyone in the world of HL7, however – at least not according to what we can infer from this:

Hi,
I have been working with people at CDC on using V3 messaging to convey microbiology reports among other things. In discussions today, the question came up of where in the Microbiology specification was the observation that identified the organism for which susceptibility results were being passed. I said, well no, the organism was indicated as an entity playing the role of isolate and participating in the "specimen observation cluster". But, I was told, the CDA hospital acquired infection report carried this as an observation, and indeed it does. Is this a problem to be addressed? Or a characteristic of V3 to be managed? It does seem clear that the two specifications have been underway in parallel [*], so it is, if not pointless at least difficult, to say which should be allotted precedence. What ideas do people have?
Mead

*This is exactly the thesis defended here.

News from Stockholm

More from Stockholm County Council, and its ambitious healthcare IT system, the GVD, sometimes advanced as a success story of HL7 V3:

We chose Oracle Healthcare Transaction Base because it complies with the worldwide HL7 standard for clinical data, and because it comes from a major international company, committed to supporting, developing, and refining the product over time. When we conducted a market evaluation, Oracle also came in at the right price. – Jack Robinson, IT Manager, Stockholm County Council

In an article entitled "Missarna som knäckte GVD" (roughly: Flaws in the Cracked GVD"), Madeleine Bäck reports on the recent history of the GVD project, which continues to move from crisis to crisis:

Heavy criticism is directed towards the choice of storage system for GVD, the so-called HTB database, which was acquired from WM-Data and its partner Oracle in 2004. 'Our pilot tests point to catastrophic performance when loading data to the system. We also observed that it would be incredibly complicated and expensive to adapt HTB to the GVD', explains one involved person (who however chose to remain anonymous). The suppliers who built the GVD are aware of the criticism, but they do not agree with all aspects: Pia Kullstrom, head of Public Sector and Healthcare at WM-Data, pushes back specifically as regards criticism of the HTB system. This is not based on facts she claims, but rather on people having a different product-religion.

I am told that features of the GVD marked out as problematic include:

1. The poorly functioning BAT&Portal (for authentication and authorisation services), which uses HL7's CCOW (Clinical Context Object Workgroup) standard protocol, and is supposed to be a web-based, single point of entry and single sign-on access route to the different parts of the system.

2. For writing data to HTB the performance is 'still horrendous', even though Oracle re-wrote the whole implementation for reading data through their API after Stockholm had already accepted the HTB product.

3. GVD has a strongly centralized architecture, but its protagonists did not address the question of how to handle the legacy systems during the transition period. Many of the latter are fully functional, mission critical, clinical systems. Centralized architectures, in which the attempt is made to consolidate semantically non-interoperable data from hundreds of databases into one, are show-stoppers.

As a whole, GVD is a classical "big bang" project, where the thinking has been quantitative, not qualitative, and the Stockholm political leadership has admitted that GVD is an "IT-fiasco".

But the responsible civil servants remain in denial, and there have not as yet been any signals to the effect that they are going to back down from HTB. This raises one further problem: GVD has Oracle HTB, and thus HL7 V3, as central component. One can state with high confidence that HL7 V3 is not going to be the standard at national level for interchange of clinical data in Sweden. So what is Stockholm going to do?