Wednesday, December 30, 2009
Monday, November 09, 2009
- Independent Continuants (roughly corresponding to HL7 Entity)
- Dependent Continuant (missing from HL7)
- Occurrents (of which HL7 Act would form a subclass, alongside those occurrents which are not Acts, such as parasomnias, involuntary muscle contractions, erosion of teeth due to persistent vomiting, and so forth)
BFO has shortcomings for representing medical information at the granular level. Like many philosophy based upper ontologies, it suffers from defining accidental properties when they are not. This leads to issues in maturation of organisms through development cycles such as parasites go through and leads to erroneous classifications.Cecil agreed to formulate his concerns in relation to a concrete case, in which John, a person on rotation living in the Congo, has a blood test drawn that shows sporozoites on the smear. The challenge for BFO is then to answer the following questions:
1. How does BFO deal with the question whether John has malaria when there are sporozoites detected on his blood smear?
2. How can BFO be used to classify an immature life form as a cause of a disease when the causative agent develops internally to the organism and changes its stage of life?
Werner Ceusters and I have sought to address these challenges here (a new version, here, addresses comments made by Christos Louis and posted below). Responses from the HL7 community are welcome. At the same time we have issued to Cecil, and through him to all afficionados of the RIM, an analogous challenge:
1. How does HL7 RIM deal with the question whether John has malaria when there are sporozoites detected on his blood smear?
2. How can HL7 RIM be used to classify an immature life form as a cause of a disease when the causative agent develops internally to the organism and changes its stage of life?
Responses to this challenge can be submitted as comments to this posting, or by email to email@example.com. All responses will be published here.
Update November 3, 2009
Update November 16, 2009:
Response from Prof. Christos (Kitsos) Louis (IMBB-FORTH / Department of Biology, University of Crete)
Overall, I think that this is a very nice idea in order to prove that BFO is indeed a powerful tool. I really liked it. But...
1) Diagnosis of malaria is extremely easy, so why make a doctor “think” first, when the only thing he has to do is a blood smear? The only possibility of mis-diagnosis is for MDs in the North who may simply not think of the disease. Also, in the opposite case cited in the abstract, if malaria is asymptomatic for whatever reason, this usually happens only in hyperendemic areas (almost exclusively the tropics) and it is of no clinical or epidemiological importance other than on a purely academic level. If, on the other hand, the audience is specialists of medical informatics (the emphasis is on informatics, i.e. people who for whatever reason don’t “like” BFO), my guess is that after taking care of the stuff below, this could certainly have positive consequences in terms of a potential global acceptance of BFO.
2) The biology of the disease and medical/diagnostic consequences: Sporozoites, as you mention in the intro, are very “short lived” in the blood. Also, due to their very low number (malaria can be caused even by one sporozoite!), they are almost impossible to detect in the blood (see wrong sentence in second paragraph of Methods)! Thus, they play zero role in the diagnostic process (and diagnosis) of malaria, which is initiated only after the first or second bout of fever. This happens days after the infectious mosquito bite and certainly not within 30 minutes. As a matter of fact, even if one rich tourist were bitten close to a hospital/clinic one would not find a single doctor willing to do a “smear” because it would be completely useless. Thus, although indeed true, anything that lies between ID#3 and right after ID#10 is absolutely irrelevant in terms of diagnosis. Furthermore, Table 3 is not only simplified but oversimplified. Malaria (disease, disposition, whatever), unless we talk about a relapse or a medically-induced one, has to start with an infectious mosquito bite, thus somehow I feel that this should be somehow be mentioned between IDs #2 and #3. Moreover, one of the crucial aspects of malaria is the recurrence of fever attacks the first of which is the one that starts the disease from the point of view of pathology. These recurring fevers make up the crucial feature that routinely leads doctors to either diagnose it as malaria or initiate the relevant diagnostic procedures. Therefore, I think that the recurring fevers should somehow find their way to Table 3. Concluding this part, I would rewrite the whole thing “starting” from the diagnostically and clinically relevant point, which is the presence of blood-stages (several kinds, and in no way called “mature”) in the peripheral blood.
3) Other comments:
i) The existence of “surviving liver stages”, i.e. hypnozoites, can only be inferred a posteriori. This may be crucial in the definition of disease (see penultimate sentence of the Discussion). Would one talk about disease solely because there may or may not be a few hypnozoites present in a few liver cells, that may or may not ever wake up?
ii) I have a big problem with Stedman’s definitions, as these first, exclude autoimmune diseases or second, are cyclical: D3 defines, among others, a disease as being a disorder while D5 says that a disorder may result from a disease! I would therefore prefer to concentrate entirely on either CDC definitions or WHO.
iii) The title’s second part is completely misleading. There is nothing about the Plasmodium life cycle here, as only part (and only part) of the vertebrate component of the life cycle is “discussed”
iv) You state “...or have no physiological counterpart at all (e.g. inflammation).” Given that inflammation is a normal response of the human body, I have certain doubts whether this should not also be “physiological” similar to the hyperventilation stated immediately before that.
Friday, October 02, 2009
But there is a worry which arises in connection with this general strategy, which is that software engineers -- even when given all the resources they need, and even when walled off from committee interference and popularity contests -- often seem to produce work that is affected by the very same confusions about which Wolandscat himself is complaining. Consider, for instance, the Microsoft Healthvault list of Health Item Types, which informs us that:
Allergic Episode is an occurrence of an allergy which is defined by the Allergy type.symptoms
At the same time we are told that Allergic Episode inherits Health Record Item, where the latter is defined as:
A single piece of data in a health record that is accessible through the HealthVault service.
Is 'Allergic Episode' so defined really a good name for something that is (a) a single piece of data, that is (b) in a health record that is (c) accessible through Microsoft Healthvault?
Further examples of Health Record Items provided by Microsoft include: a blood pressure measurement, an exercise session, or an insurance claim. But is a blood pressure measurement or an insurance claim or an exercise session truly a good example of a 'single piece of data'? Are any of these things data at all?
A potentially even more serious problem for Microsoft turns on the fact that the definitions offered on this page by its engineers are static programming class definitions -- suggesting that their authors think that they can create a representation of the medical domain by means of a monotonically growing set of classes deployed in software. But medicine is constantly changing in polydirectional ways, and software conceived along the given lines will be so sensitive to such changes that it will require constant maintenance, re-testing and re-deployment.
If, therefore, much HL7 standards-building offers evidence of a lack of overarching software infrastructure that could make the standard work in any kind of serious deployment, so the Microsoft material on the Healthvault pages is evidence of an equal and opposite lack of understanding of the domains within which such deployment would need to take place (vast and changing content; complex semantics).
As I am sure Wolandscat would agree, the real need, if we are to get all the separate pieces of this gigantic puzzle to work together, has to be an organisation that is something like a mini-university, or a cross between a university and a company (to avoid becoming detached from reality) involving at least: ontologists, software engineers, medical domain experts, and persons with experience of and a track-record of success in implementing and brutally testing healthcare IT systems in real-world environments. The organisation should have cross-disciplinary mechanisms that force each kind of person involved to understand the outputs and meaning of the others' work. And this work should be implemented in tools -- not just in its vision -- and subject to rigorous real-world testing in advance of any eventual release in the form of 'standards'.
Sunday, September 20, 2009
The author begins by pointing to the long-standing assumption
that we should rely on official standards bodies to standardise things, and indeed, our entire modern civilisation does rely on this. From the thickness of car-window glass (look carefully for the standards mark etched into the window next to you get in your car) to power voltage and frequency, to mobile phone and internet communication standards, the sanity of our world today relies on successful standardisation of every conceivable physical and electromagnetic phenomenon which comes into play when one object or person interacts with another.He then goes on to point out that there is an abnormal situation in the eHealth domain, which consists in the fact that standards are being developed by official agencies, including HL7 (an "ansi-accredited standards developing organizations"). This is in contrast to what has been the normal situation elsewhere, where standards were initially developed by engineering organisations, such as telecommunications companies, IT companies, or universities and research networks, and became standards only after they had been not only specified, but also implemented and thoroughly tested. The author provides a variety of reasons why a committee process of the type employed by HL7 and similar standards organizations is an unsuitable approach for addressing the problems of semantic interoperability. The reasons include:
a consistent ecosystem of standards is not likely to emerge from multiple standards organisations, with significantly different rules, and cultures, and which are quite competitive;I am pleased to see that the OBO (Open Biomedical Ontologies) Foundry, an initiative in which I am involved, has embraced an approach which avoids the majority of these problems in its attempt to create a standard set of semantically interoperable ontology resources to support biomedical research. Two principal marks of the OBO effort are 1. its striving for logical consistency and for non-redundancy even as the suite of involved ontologies grows, and 2. its commitment to thorough testing of all OBO artifacts and to careful peer review before ontologies are accredited for use by the OBO Foundry community.
the international standards organisations in the e-health area are large enough that even internally they generate inconsistent standards;
development of technical artefacts by committee is almost destined to fail;
good technical artefacts can only be developed by an engineering process (that is to say: requirements, analysis, design, implementation and validation – as old-style or agile as you like);
most standards in e-health are being developed without a sound model of the ecosystem, in other words, they are developed as ‘point-to-point’ specifications, or responses to specific problems, with no reference to an underlying design framework;
there is in general very little culture of implementation or testing – many e-health standards are issued untested;
there is little or no organisational commitment to maintenance, in the sense that software developers understand – i.e. if a bug is found, there should be a way to report it, and track its progress, and on the development side, the organisation should be capable of issuing new releases in a timely fashion (organisations that do do this always have two things you can find – an online version control repository and an online issue tracker);
timelines for delivery are notoriously unreliable;
the groups created for delivering a given work item typically do not contain people with the required engineering competence, but rather enthusiasts ...
Tuesday, September 08, 2009
Definition: This field indicates any permanent or transient handicapped conditions.
A0 No functional limitations
A1 Ambulates with assistive device
A2 Wheelchair/stretcher bound
A3 Comatose; non-responsive
A5 Vision impaired
A6 Hearing impaired
A7 Speech impaired
A8 Non-English speaking
A9 Functional level unknown
B1 Oxygen therapy
B2 Special equipment (tubes, IVs, catheters)
Saturday, August 01, 2009
Benson's book is well-written and well-structured, and will provide a good starting point to those who are interested in the role of HL7 and SNOMED CT in current endeavors to realize interoperability in the realm of health information. Unfortunately in his treatment of HL7 RIM Benson still stays too close to the in many places confusing wording of the HL7 organization's own documents, and thus he does not provide the necessary level of clarity which would be needed for a more generally useful introduction to HL7 v3. In some cases there are outright contradictions, so that the reader is left with no reliable way of determining what is meant.
The problems at issue will by now be all too clear to the readers of this blog, but I will reiterate them nonetheless:
a. Confusing use of 'Act' to mean in some cases intentional action and in other cases anything that happens.b. Confusing use of 'Act' (the same word) to mean in some cases a record and in other cases that which is recorded.
I provide passages to illustrate these problems below, confining myself to Benson's Chapter 7 – The HL7 V3 RIM, with one example taken from his Glossary. Emphases have been added by me. While the passages from ch. 7 are provided in their order of appearance, they are, inevitably, taken out of context. If someone can provide me with a key to the relevant context or contexts which will enable me to understand them consistently I would be more than grateful.
1. In his Glossary, Benson defines 'Act' as:
Any action of interest. Something that has happened or may happen.
(Interestingly, HL7 itself does not include the term 'Act' in its own Glossary, though it does include several of Act's children, and it presupposes an understanding of what 'Act' might mean in its definitions of the corresponding terms.)
The passages from Benson's chapter 7 are as follows:
2. "In HL7 V3, every happening is an Act, which is analogous to a verb in English. Each Act may have any number of Participations, which are Roles, played by Entities. These are analogous to nouns." [Act = any action of interest?, or any happening whatsoever (for example, a drug interaction, or an event in which someone dies as a result of a shooting accident)?]
3. "Act is a record of something that has happened or may happen. Full representation of an Act identifies the kind of act (what happens), the actor who performs the deed, and the objects or subjects (e.g. patients) that the act affects." [An Act is a record; an act affects patients; so 'Act' and 'act' are not synonymous; yet elsewhere in this chapter (for instance under 'Status Code') Benson uses 'Act' and 'act' interchangeably.]
4. "Information in a document is treated as an Act – the act being the creation of the document content." [Does this mean that information is the act of creating information? What, more generally, is HL7's view of the relationship between an Act, and what is treated as an Act? And is the act the record, or the creation of the record?]
5. "Each transaction is a kind of act." [I presume that this means that each transaction is an act (or Act?) of a certain kind.] "An account is a record of a set of transactions." [Does this, by 3., mean that an account is a record of a set of records?]
6. "Observation is defined as an Act of recognizing and noting information about the subject, and whose immediate and primary outcome (post‐condition) is new data about a subject. Observations often involve measurement or other elaborate methods of investigation, but may also be simply assertive statements, such as a diagnosis." [Are observations events of recognizing and noting? Or are they the results of events in the form of records or statements, as would be implied by 3. above and by the fact that Observation is a kind of Act? Or are they sometimes one and sometimes the other? Are some Observations records of Observations?]
7. "A Procedure is defined as an Act whose immediate and primary outcome (post‐condition) is the alteration of the physical condition of the subject." [Again, how can this be consistent with 3. above? How can a record alter the physical condition of its subject?]
8. "A particular Entity in a particular Role can participate in an Act in many ways. Thus, a person in the role of surgeon may participate in an act as primary surgeon or as assistant surgeon." [Is the surgeon participating then exclusively as record keeper, as is implied by 3. above, or also as surgeon?]
Does this matter? Well, perhaps. There is currently much activity on the HL7 front in light of urgent efforts to bring about the needed interoperability between HL7 and the SNOMED CT vocabulary. How, under the conditions described above, will the Acts at the heart of HL7 v3 be callibrated in relation to what SNOMED calls 'procedures'?
Tuesday, July 28, 2009
One of the joys of HL7 Version 3 are the many different ways that you can say the same thing depending upon the context of your message. Let's look at a laboratory test result for example. Using the HL7 RIM, this will be encoded as an observation. Using the 2008 Normative Edition there are at least 7 ways within the published standards to say the same thing. These seven different ways appear in the following HL7 Version 3 standards:
- Care Record
The picture [here] shows how these HL7 standards support this concept slightly differently in each case.
- Clinical Genomics Pedigree
- Clinical Document Architecture
- Clinical Statement
- Common Message Element Types
- Public Health Reporting: Individual Case Safety Report
- Periodic Reporting of Clinical Trials
- Laboratory Results
I've shown how the names of the XML Element, and the constraints on the content of the Observation class vary using a bold red font, or where the RIM attribute is missing, a red background
Wednesday, July 15, 2009
In a recent post I pointed to errors created by the flexibility of HL7, for example because it allows the NK code for 'next of kin' to be used in a message also, for example, when referring to a nurse. Graham Grieve has entered a Comment to this post, defending a view of the NK code as 'a field that users can put what they need into'.
As he points out:
The question is, for any particular use, is that use consistent with the definition of the field? I don't think it is in the hoot example. But consulting the standard, the definition is loose - like the definition of next of kin in the real world. Of course, in a competition to find the worst case of egragarious mis-use of a standard, HL7 regulars would line up to bring forward their favorite cases. But HL7 is not alone here. HTTP is the same too. As for web services ... . What this does betray is a flaw in the whole picture: the standards body defines a logical structure, but business use cases require things to be done, and how are they going to be done? So some partially educated analyst makes a (variably) bad decision under considerable pressure, usually with some input from actual implementers. The outcomes are unpredictable. Actually tightening the definitions (like in a proper ontology) can make things worse, and so can loosening them. Though either can make things better for at least some users in some circumstances. It's just something we have to live with.I fear that Graham's relaxed attitude to the dilemmas of bad coding ignores an overwhelming problem in the current (v3) architecture of HL7, a problem which does much to explain the peculiar features of some of the discussions on HL7's email lists, and which explains also why HL7 needs to devote so much effort to the consideration of questions like 'Is Diet a subclass of SupplyAct?' or 'Is a car accident an intentional action?'
The problem is that the RIM rests on a counter-intuitive upper level ontology, one in which anything that is not an Entity has to be classified as an Act. This counter-intuitive ontology -- in which a disease, for want of any more appropriate category, is identified with an act of observation of a disease -- not only makes it hard for HL7 analysts to avoid making bad decisions; it is also likely to be responsible for medical (coding) errors downstream, and it also places obstacles in the way of simple remedies for such errors.
Consider, for example, the case described in part 4 of the interesting series "Are Health IT Designers, Testers and Purchasers Trying to Kill People?" by Scot M. Silverstein. The chart below represents a problem list presentation page generated in an Electronic Medical Record system via auto-population based on what its makers refer to as an 'artificial intelligence' function.
As Silverstein points out, a number of issues are illustrated here. For present purposes we focus only on those pertaining to the diagnosis 'atrial fibrillation.' This is, as Silverstein notes, an important piece of information for the clinician to know.
Except, however, when the patient does not have atrial fibrillation. This entry was auto-populated when a nurse ordered a blood clotting test and erroneously entered the reason for the test as "atrial fibrillation" (a common reason, just not the case here) to expedite the order's completion. Voila! Now Mrs. Jones carries this diagnosis, and the next clinician to come along might order her anticoagulated with heparin or coumadin for a history of A. fib, introducing yet more chance of an iatrogenic injury.HL7 was not, for all I know, involved in any way in the creation either of this system or of the specific problem list here illustrated. But consider the difficulties created by the RIM for any rectification. Suppose, for instance, one wished to have a facility to allow users of the EMR to generate different sorts of problem lists for different purposes. These might include, for example, problem lists that would include only those entries in which a disease is ascribed to a patient on the basis of some act of observation by a clinician. To achieve this end, we would need to keep records of observations by clinicians clearly separate from records of diseases on the side of the patient, along the lines illustrated for example here. We have attempted to identify a way in which the RIM could allow a programme do this coherently. But thus far we have not been successful.
And I am told it takes going back to the vendor to have this erroneous entry permanently removed. Sheer idiocy! For instance, if the patient moves to a different unit, is discharged and returns to this hospital, or to an outpatient clinic or another hospital branch with this on the record, the chances of a screwup are not insignificant
Tuesday, July 14, 2009
The ontology is associated with a blog, which draws attention to some of the unfortunate consequences which flow from the fact that HL7 is flexible in the familiar ways (thus it allows the NK code for next of kin to be used also, for example, for nurses).
The OWL framework provides a clear perspective on HL7 v. 2.3, and avoids the usual problems (with act, observation, etc.) which plague v.3.
Thursday, July 09, 2009
Comment 1 (to HL7 RIM: still no coherent way to track concerns):
KC: I too wish to echo's Grahame concern that you seem quite liberal in quoting comments out of context and seem all to eager to find the most minute publication error as further evidence to support your "interesting" theory about how HL7 works or what you can do with the organizations work products.
BS: I am afraid I do not yet have a theory about how HL7 works, because, like many others, I do not understand the HL7 documentation. This is in part because it is unclear -- a problem which HL7 has already acknowledged and is itself attempting to ameliorate -- but in part, and more seriously, because it is inconsistent. Gunther Schadow, Charlie Mead and Mead Walker defend this state of affairs by arguing that:
As different people edit parts of the specification, inconsistencies in form and quality may emerge; as some ambiguities are clarified, other previous systematic ideas may be corrupted; and well meant glossary entries may cause confusion. Sometimes irreconcilably opposed conceptualizations may coexist and one resorts to vague or ambiguous language in the interest of moving forward in areas where parties can not agree.Some would argue, however, that this is a state of affairs that raises questions for an organization that is proposing standards for information exchange, especially in a critical domain such as health care, and especially in a context in which large government investments depend on making the right sorts of standards decisions.
KC: While you at times do happen upon a legitimate concern about HL7, you do a great disservice to those who read your blog by misconstruing ongoing self critique by HL7, and discussion of very difficult technical issues as flaws.
BS: Such self-critique is of course an entirely positive thing. It would be a flaw in a system only if actual errors or inconsistencies or unclarities or ambiguities identified through such critique would be ignored at the stage where the artifacts in question become normative.
KC: Should more people read (or care) what you publish, it could have a detrimental effect by stiffing the public discourse which marks a healthy SDO.
BS: Good point. I hereby commit to closing down this blog just as soon as there is evidence that it is succeeding in becoming influential.
KC: Since you are such an ardent lurker of the lists, perhaps you might wish to attend some of the frequent tutorials to give you a better working knowledge of HL7 methods and models, and then consider directly contributing to the ongoing efforts to find workable solutions.
BS: I devote a lot of time to the OBO Foundry standards efforts (we also organize many interesting tutorials). The developers of all the ontologies within the Foundry recognize the value of criticism from outsiders, since outsiders are able to provide a fresh perspective -- for example by exposing ways in which our documentation falls short. Science, I believe, makes progress only to the degree that it maintains a healthy culture of criticism from outsiders.
Comment 2 (to Big HIT) (responding to the identification of major problems with HL7 XML):
KC: HL7 XML is standard. It follows published W3C standards, which as far as most are concerned are the standards about XML which matter.
BS: Correct. But not all standards are equally good, I'm afraid. See, as concerns HL7 XML, the arguments here (summarized already here).
KC: HL7 itself is a ANSI SDO, and anything that HL7 publishes as normative BY DEFINITION is a standard.
BS: An ANSI standard, yes; all the more reason, therefore, to ensure that everything is checked very carefully before publication as normative, for example to ensure consistency.
KC: Finally, HL7 contributes, collaborates and uses the same ISO standard (21090) for data types, which is by-and-large the XML which makes up "HL7 XML."
BS: Unfortunately most HL7v2 and HL7v3 message standards do not follow this ISO standard. Moreover 21090 is not a full ISO standard. It is in the DIS-stage and therefore under development: http://www.iso.org/iso/catalogue_detail.htm?csnumber=35646 [See update below]
KC: Please, when you make statements such as that, you should constrain yourself to the facts, and not make such invalid and irresponsible statements.
BS: I hope, with respect, that we are both doing our best to confine ourselves to the facts.
Update August 2011: http://www.iso.org/iso/catalogue_detail.htm?csnumber=35646 now published as an ISO standard.
Thursday, June 25, 2009
I am happy to provide a link to the requested larger set of responses here (no letter from Graham among them, however, for the reason given below). I am also happy to withraw my portrayal of what Graham certifies is a technical mistake as if it were a policy issue. My reason for jumping to conclusions in this way turned on the repeated reports which I receive from persons with a much better knowledge of HL7 than I, to the effect that, when proposals to simplify HL7 are put to ballot, there is a tendency for such proposals to be voted down.
I think your quoting Dan's email in this way is highly inappropriate. You have also cherry picked the various responses to Dan. For instance, you didn't include mine. Your comment is: "Why was the change of adding CONC and COND not made to the official RIM standard" is highly disingenuous - trying to portray a technical mistake as a policy issue.
I think you may have a point about condition vs act, but the continued errors of reporting and perspective this blog entry shows make it really hard to bother listening to your point.
Postscript July 7, 2009:
In a further comment, Graham now writes:
I look forward to seeing evidence of the rectification. And I hope that it is done right -- i.e. that 'condition' gets to mean 'condition' and not, for example, 'observation of condition', 'worry about condition' -- so that the existing problems with 'disease' are not simply recreated under a new heading. A condition is not an act.
It's certainly true that repeated proposals to simply HL7 are voted down. There's several reasons for this which could be variously categorised as the good, the bad and the ugly. But by and large it appears to be an inevitable part of the standards process: you only ever add scope and requirements. And refactoring is always hard to pull off, let alone when other people get to vote on the outcome in a consensus based process ...
Somewhat embarrassingly, it turns out that my email to Dan was private, not cc:ed to the list (I think by accident). Whoops, so my apologies on this count Anyway, this one was a technical mistake, and it appears that it will be rectified as a technical error.
Sunday, May 24, 2009
To normal persons both of these options seem equally unacceptable. To the RIM, however, a stunningly creative work-around is at hand: diseases are identified as Acts of Observation. Roughly: a disease is an observation of a disease.
One of the many problems with this work-around is that there are often many observations of one and the same disease (for instance of my diabetes or Jim's arthritis), and the RIM provides us with no satisfactory answer to the question of how we can identify what each given series of such observations have in common. The obvious answer -- that they are all observation of the same disease / problem / condition -- is ruled out.
When Werner Ceusters and I made this surely obvious point at the Medical Informatics Europe meeting in August 2006 (see here), Günther Schadow responded on behalf of HL7 to the effect that steps would be taken to add new classes to the RIM in order to address the obvious need to refer to items such as diseases, medical problems, clinical conditions which are not Entities, and thus not made of molecules, but yet such as to endure self-identically through time.
Two new classes -- of Concern and Condition (with abbreviations 'CONC' and 'COND') -- were selected, and a number of important HL7v3 players have been using these classes -- in reflection of the fact that they address an urgently felt need. Unfortunately, the ISO RIM standard and the ANSI HL7v3 standard did not see fit to support such usage.
We therefore have a new bifurcation of different RIMs (where the RIM itself was introduced 13 years ago precisely in order to solve the problem of multiple different dialects plaguing HL7v2).
Why was the change of adding CONC and COND not made to the official RIM standard, given the obvious benefits of simplicity and greater ontological coherence such a change would bring? This question is being raised also inside the HL7 community, as for example in the following email exchange, which hints at serious problems regarding the quality of HL7's decision-making process:
From: Dan Russler firstname.lastname@example.org
Date: 23 May
2009 4:52:26 GMT+02:00
To: Jean-Henri Duteau email@example.com
, MNM List , HL7terminfo ,
"firstname.lastname@example.org " email@example.com
Problem list in the CCD standard: was Patient care harmonization Was:Re: NIB
forms for next ballot
I am semi-retired now fom HL7, but I am still heavily involved in HL7-based implementations and feel a need to help avert a "crisis of confidence" in HL7. There have been important events since the Nov. 2006 harmonization votes on Concern (CONC), Condition Node (CNOD), and Condition (COND) despite the missing voting records regarding CONC in the RIM. One of the most important is that the CCD, with the Patient Care Concern Tracking Structure embedded in the Problem List and Allergy List (Alert) sections is now named in US HITSP-based regulations and is live in State government-based patient care activities such as in Alabama Medicaid HIE and the State of Tennessee Shared Health HIE. It would be horrible for a relatively minor missing voting record incident to cause a crisis of confidence in HL7 in the middle of the US Federal Recovery Act initiatives. CCD training, Schematron testing, registered templateID OIDs all support the Concern Tracking Structure in the CCD.
History: As referenced in this Cover document for the HL7 RIM proposal introducing the new Act.classCode "CONC (Concern)," a great amount of consensus building preceded the introduction to harmonization. The use of the term "Concern" rather than Condition Node in the patient care models for problem and allergy lists was suggested by OO (by then representative Gunther Schadow). Patient Care accepted the recommendation and brought the proposal to harmonization. At the same time, Structured Documents implemented a highly constrained version of the newly renamed "Concern Tracking Structure" in the CCD. Due to the limited ability of CDAR2 to support new classCodes, the instance of the "Concern Class" in the CCD had to be implemented as an "Act Class." However, the CCD Act.classCode used in the problem list and alert sections of the CCD is structurally the same as the CONC class in the Patient Care Concern Tracking Structure. The intent at that time was to implement the CONC class in the CCD with CDA R3 when new classCodes were supported. I was the harmonization steward for Patient Care and submitted the harmonization proposal. During discussion, I accepted a friendly ammendment from Woody Beeler to hold off on formally deprecating CNOD until we could make sure that no other committee wanted to use the class. In addition, it was thought wise by others to maintain the COND class as was. My recollection of the vote was that all clinical committees including PC, OO, Structured Docs voted to accept the CONC class as defined in the RIM and leave CNOD and COND in place. It might be helpful to poll the other stewards and find any who recollected voting against the proposal. In January, 2007, the Patient Care minutes show that Woody agreed to submit a definition modification proposal to harmonization to change the definition of CONC by substituting "issue" for "worry." This vote indicates that Woody at that time understood CONC to be "in the RIM."
Comment: Since Nov, 2006, no other TC has decided to utilize CNOD. After being present in the RIM, but unused for almost 10 years now, it seems reasonable to consider removing CNOD from the RIM. A number of implementations that I am aware of have found COND to be valuable in subtyping OBS (thereby differentiating a diagnosis from other kinds of observations). It seems reasonable at this time to continue RIM support of COND. However, in my humble opinion, it seems risky to HL7's reputation for M&M/Vocab to demand revoting on an established standard simply because someone misplaced some voting documents. It seems better to ask
the stewards who were present if anyone remembers voting against adding CONC to the RIM. If a majority do not remember voting against CONC, the reasonable solution is to add CONC to the HL7 RIM as a technical correction rather than requiring the whole process to be repeated. Again, this is no minor decision on
the part of an HL7 committee. This decision has ramifications throughout the US Federal Government, the vendor community, and the user communities using CCD in patient care. It is fair to consider a backwards-compatible revisions to the Concern Tracking Structure in the future based on the evidence from real users of the CCD. However, these revisions should occur through careful HL7 revision processes and with the representation of real CCD users, and not through clumsy process repair efforts in a single HL7 committee, most of whom are not direct users of the standard today.
Dan Russler, MDVP Clinical
InformaticsOracle Global Health Sciences Strategy
Jean-Henri Duteau wrote:
Although I agree with Keith that we should try to locate the final consensus, I do want to point out that the intent of a new submission was less due to the fact that it was missed so many years ago and more to do with the fact that the world has probably changed since the proposal was raised. Woody's point at the MnM Facilitator's Roundtable was that rather than PC stating that the old proposal should be resurrected and simply actioned, that PC should instead work to find the proposal and then resubmit it after ensuring that it is still valid with today's RIM and vocabulary and model requirements. It could very well be that the previous agreed direction is entirely valid and PC just needs the original proposal actioned. But it behooves us to ensure that is true.
Keith W (GE Healthcare) wrote: I would push back on this. This was a rather long discussion over several months that was resolved and closed. We should make appropriateefforts to locate the final consensus. Re-opening this as a new Harmonization proposal because someone failed to keep up with the discussion seems to be an abuse of the process that we went through to come to that consensus. I'd be concerned that the direction it takes would be different from what was agreed upon previously.
Werner Ceusters and Barry Smith, “What do Identifiers in HL7 Identify? An Essay in the Ontology of Identity”, Proceedings of InterOntology 2009 (Tokyo, Japan, February 27-March 1, 2009), 77-86.
Richard H. Scheuermann, Werner Ceusters, and Barry Smith, “Toward an Ontological Treatment of Disease and Diagnosis”, Proceedings of the 2009 AMIA Summit on Translational Bioinformatics, 2009, 116-120.
Tuesday, April 28, 2009
The Data Model That Nearly Killed Me
in which Joe Bugajski describes how far we are from an electronic health record environment that would serve the patient. The situation described is one in which the patient, as he moves through the healthcare system, is called upon to answer questions, over and over again, in ways that give rise to multiple opportunities for inconsistency. Authoritative data about the patient's condition from the patient's own doctor is treated, at best, as just one minor ingredient in the mix.
One heroic medical professional, the first nurse I met in ICU, worked to create a consistent record of my condition, allergies, and medications in the hospital’s electronic health information system. She spent over one hour searching for previously entered data, correcting errors, and moving or reentering data. She argued with one doctor whose concurrent access to the hospital’s system blocked my nurse’s access to my information. She called the hospital’s pharmacy repeatedly to get my medications delivered. She met and called doctors several times. She even convinced one doctor and a pharmacist to come to my room to resolve data errors in person. Despite these heroic efforts, I never received correct medications during my stay. Indeed, my wife snuck one of my inhalers into my room. After I used it, I finally began to recover.
The inconsistencies arise, in part at least, from the absence of any consistent common framework for data entry on the side of the electronic health record. The HL7 RIM might conceivably contribute to filling this gap; but the RIM, as we know, is focused not on the patient's condition, or on the events transpiring on the side of the patient, but rather on the transactions of healthcare professionals. It rests, in other words, on a view of the electronic health record as a collection of statements “not about what was true of the patient but [about] what was observed and believed by clinicians” .
The exact causes of the problems documented by Bugajski are still to be determined. One way of summarizing the argument of this blog is that it seeks to make the case for a more incremental, evidence-based, and patient-centered approach to the EHR, and for a regime in which standards are imposed only when they have been proven in use.
 Rector AL, Nolan WA, and Kay S. Foundations for an Electronic Medical Record. Methods of Information in Medicine 30: 179-86, 1991.
Postlude (1) May 1, 2009
Another version of Bugajski's narrative can be found here, which points to do major problems which must be addressed if the vision of seemless interoperability of healthcare records is to be realized: the problem of building a consistent ontology of the enormous and rapidly evolving medical domain; and the shortage of people with the skills and training needed to realize this goal:
The first problem with modeling healthcare data is that models must represent certain concepts (and not others) that will remain stable and true long enough to be built into computer software then used by healthcare providers and patients. Mr. Obama, have you noticed just how much knowledge has, is, and will be accumulating in the medical sciences? Knowledge is codified using words - medical knowledge uses copious quantities of difficult words taken from several languages. Words that recur frequently in a particular context become imbued with a meaning that includes the context (e.g., the White House). Such words then come to symbolize a bigger idea than originally intended (i.e., a "house" that happens to be "white", versus your administration and not the house). In medicine, how many stable words exist? These words - nay, well-formed concepts, repeatable, agreed by the medical community - can be modeled and added to computers to store records. Go one step further. Specialization in ER, ICU, cardiac care, pulmonology, oncology, radiology, and other medical subjects exists because the cumulative knowledge defines a large ontology. The ontology, taxonomy, skills, and knowledge of an medical subject area then can be referenced with one word - the name of the specialty. Unfortunately, words that refer to a concept in one specialty often mean something different in another specialty.
The second problem is the lack of good modelers. These people, specialists in data engineering, a subfield of software engineering, transform concepts into graphical and lexical patterns that are used to create computer records. The concepts they model are words (nouns and verbs) plus concepts used by practitioners to describe a patient's medical condition, or a critical care pathway, medications, instructions to patients and nursing staff, tests, and diagnoses. Who among us has the modeling skills to encode this data? As information varies across specialties, how should it be encoded? Empirical evidence suggests that engineers who built the electronic health records network at the two facilities that "cared for me" tried to do this, but they failed. Their data model had irreconcilable silos of information spread across specialties and expressed as incomplete taxonomies (entities), inadequate ontologies (attributes), and poor associativity (relationships). Hence, when programmers added those bad data models to the health information systems, those systems later lost critical information about patients' condition, listed wrong medications,isolated prior diagnoses from current observations, in short, made very bad medicine.
Postlude (2): July 4, 2009
Joe Bugajski's Reply to "Proper Perspective Needed..." (April 21, 2009):
I admire, voted for, and strongly support President Obama. I support his vision of a National Health Network (NHN). I strongly disagree with his administration’s $20 billion conclusion that technology and technologists stand ready to build the NHN today. While I know little about practicing medicine, I am an authority (30 experience and many publications) in data interoperability and system integration. Hence, I cannot comment about treatment effectiveness - you and others generously provided these insights. I can write about data in the context of a system design.
The crux of the data model issue is this. If data cannot be made reliably available across silos in a single EHR, then this data cannot be made reliably available to a huge, heterogeneous collection of networked systems. Furthermore, poor quality data models and low quality user interface design convolve into serious data access and use problems for practitioners and their patients. Data models are my immediate concern relative to the NHN, but interface design also needs attention (also a fit subject for study in the NHN context). Further to data models, integration of information across an exceedingly complex, networked, data storage and retrieval topology remains an area of active research. (Indeed, my clients in every industry worldwide struggle with the issues daily - just for in-house systems.) Contrast data integration for NHN with the technology and expertise used to build the interstate highway system – 30 years of networked data knowledge versus 3000 years of road building knowledge. Consider too that technologically advanced, caring, and world-class medical institutions own and operate the troubled systems in question. These experts have immediate access to the best minds in computer, data, and network technologies. If they cannot reliably move data from one department to another, or across the street to from one to the other, how then do the rest of us cope?
Monday, April 13, 2009
has been removed.
there is no distinction between an activity and its documentation,
This is an important step, given the fundamental unclarity which has pervaded the RIM hitherto as concerns whether the items which the RIM calls 'Acts' are real processes (intentional actions) or records of such processes. HL7's official answer to this question thus far has been, absurdly, that the issue is moot, because there is no distinction between real processes and the records of such processes.
We hope now that the opportunity will be taken for further steps towards much needed clarity as concerns the interpretation of 'Act'. In the mentioned Ballot documentation we read:
Contrast earlier versions, where we were told that: "An Act-instance is a record of such an intentional action" (italics added). Are there now also some non-intentional actions the records of which we are allowed to count as Act-instances? If so, which ones? And what is a 'non-intentional action'? And what of of non-intentional events of other sorts, for instance snake bites, accidental poisonings, processes of infection, drug interactions, symptoms of disease?
Acts are the pivot of the RIM: domain information and process records are represented primarily in Acts. Any profession or business, including healthcare, is primarily constituted of intentional and occasionally non-intentional actions, performed and recorded by responsible actors. An Act-instance is a record of such an action.
Following on in the text, we read:
An Act-instance represents a "statement," according to Rector and Nowlan (1991) [Foundations for an electronic medical record. Methods Inf Med. 30.]What is the meaning of 'represents' in such assertions? And what (if any) is the distinction between an Act and an Act-instance? Are we to accept three distinct entities: the action performed in the real world, the record of this action (which record?), the statement in the electronic medical record? Or is the record identical with the statement in the electronic medical record.
Do the authors of this documentation really mean 'The truth about the real world'? Or do they rather mean something like: the picture of or beliefs about the real world implied by a given body of documentation? What if the patient is dead, but the records do not show it?
Acts as statements are the only representations of real world facts or processes in the HL7 RIM. The truth about the real world is constructed through the combination (and arbitration) of such attributed statements only ...
A factual statement may be made about recent (but past) activities, authored (and signed) by the performer of such activities, e.g. a surgical procedure report, clinic note, etc. Similarly, a status update may be made about an activity that is presently in progress, authored by the performer (or a close observer), and later superseded by a full procedure report. Both status update and procedure report are acts, distinguished by mood and state (see Act.statusCode) and completeness of information: neither has any epistemological priority over the other except as judged by the recipient of the information.Is a surgical procedure report truly an activity? Are a status update and a procedure report truly 'acts, distinguished by mood and state'? If so, are they also Acts? Lingering unclarities such as these are not resolved by the list of 'examples' presented by HL7 in the same document to help us understand correct usage:
If editing and maintaining documents are acts, then are the records (and if so which records?) of these processes of editing and maintaining documents Acts? What is the relation between 'acts' and 'Acts', and between both of these and activities (and actions)? And how can a goal be a kind of act? (or Act?)
The kinds of acts that are common in health care include (1) clinical observations, (2) assessments of health condition (such as problems and diagnoses), (3) healthcare goals, (4) treatment services (such as medication, surgery, physical and psychological therapy), (5) acts of assisting, monitoring or attending, (6) training and education services to patients and their next of kin, (7) notary services (such as advanced directives or living will), (8) editing and maintaining documents, and many others.
Saturday, March 28, 2009
Mandl and Kohane propose instead that the government should be a rule-setting referee whose role would be to encourage the development of an open software platform on which innovators could write electronic health record applications in a way which would open the door to competition, flexibility and lower costs. They point to an analogy with Apple's IPhone platform, that anyone can use or write applications for.
This is, of course, a good idea, since it would bring in its wake the opportunity for thorough testing of particular applications before they are extended to larger communities of users. The potential flaw, of course, is that it leaves open the question of what the government-imposed framework of rules should be. The HL7 organization (founded in 1987) continues to be mightily influential in government circles. Consider, to take one simple example, the case of XML. Will it be XML itself that is government imposed? Or will it be HL7-XML, a peculiarly complicated non-standard version of XML resting on an idiosyncratic approach to development that is at odds with the approaches taken by developers with XML expertise?
 Kenneth D. Mandl, M.D., M.P.H., and Isaac S. Kohane, M.D., Ph.D. "No Small Change for the Health Information Economy", New England Journal of Medicine, Volume 360:1278-1281, March 26, 2009. See also New York Times, "Doctors Raise Doubts on Digital Health Data", March 25, 2009.