Ontology Review 1. The NHS Common Basic Specification. Why top level Ontologies don’t work.

This is the first of an occasional series of reviews I intend to write to illustrate some important general traits of ontologies. In each review I will dissect an ontology and examine why it succeeded or failed. In this essay I mention concepts that are defined in my previous essay. Judging the likely success of an ontology. This first review covers an ontology called the Common Basic Specification (CBS) that was designed in the late 1980s to bring much needed standardization and rationalization to the fragmented information management processes of the British National Health Service (NHS). It persisted in various forms until the late 1990′s when it was finally abandoned. This is my explanation of why it failed.

I have been living in the US now for 6 years and have come to recognize a common reaction among Americans whenever the NHS is mentioned. They all try to hide it, but a patronizing look comes over them. It doesn’t matter how much you tell them that doctors in the NHS wash before they go into surgery, and even use anesthetics these days, Americans just can’t help feeling sorry for anyone who has to suffer under a 3 rd world healthcare system. So before I explain the CBS it is probably worth describing the NHS.

Background

The NHS is the largest employer in Europe it is the main provider of healthcare for the entire United Kingdom (pop 60 million). It’s annual budget is about 5 to 6 percent of the GDP of the United Kingdom. In 2002 that amounted to about 64 billion GBP which at current exchange rates is approximately 115 billion USD. By contrast the US spends about 15 percent of its GDP on healthcare and Americans live on average one year longer than the British. A more detailed breakdown of staffing and budget allocation for the NHS is available here. Primary healthcare in the UK is delivered through about 10,000 General Practices and about 2000 Hospitals, most with less than 100 beds. There are a few large Hospitals with up to 1000 beds, these larger hospitals are usually teaching Hospitals. All these numbers are approximate but they give a general idea of the scale of the NHS.

In the late 1980s it became apparent that the same information management problems were being encountered over and over again in hospital after hospital throughout the UK. Not only that, but they were being solved poorly time and time again. This was obviously wasteful. Hospitals had no reason to compete in the area of information management and every reason to cooperate. If these common problems could be solved correctly and then reused significant savings might be realized. At the same time the digital patient record became the holy grail of healthcare computing. In this vision of the future any patients complete medical history would be available anywhere it was needed and could be passed from GP practice to Hospital and back. It could even follow a patient as s/he moved around the country. The Common Basic Specification was suggested as the best way to ensure consistency across multiple solutions and thus enable standardization and portability of the digital patient record.

The Common Basic Specification

The Common Basic Specification ( CBS ) is a conceptual generic model of the activity of health care delivery.

[IT Standards Handbook - NHS Data Standards]

Definition of the NHS Data Model was started in 1986 and continued for several years. It was eventually renamed the Common Basic Specification (CBS). By 1992 a CBS Generic Model had been published. This was in effect a top level ontology (similar to the SUMO currently under development). It was developed for healthcare service delivery but it as can be seen from the diagram below it was universally applicable to any kind of service delivery.

Class descriptions for the figure

  • Act for subject: An “Activity” that is directed towards a “Subject”.
  • Activity: Purposeful and intentional “Event”
  • Activity class: A kind of “Activity”.
  • Agent: Role assumed by a “Subject” enabling it to act purposefully
  • Authorised to perform: The recording of the fact that an “Agent” may perform certain classes of “Activity”.
  • Category: Abstraction on the basis of common properties.
  • Concept: “Object” which is a unit of thought.
  • Event: Something which happens.
  • Incident: “Event” occurring without known volition.
  • Knowledge concept: A collection of “Concepts”, the relationships between them and the reasons for them.
  • Located at: A “Location” for a “Subject”.
  • Location: Point or piece of space.
  • Object: Part of the conceivable or perceivable universe
  • Percept: Perceived or inferred to exist
  • Reason for activity: The identification of a “Subject property” as the reason for performing or planning an “Activity for subject”.
  • Reference point: Point or piece of time or space.
  • Responsible for: The responsibility that an “Agent” has for a “Subject”.
  • Results in: A means of establishing that an “Activity for subject” has resulted in a “Subject property”.
  • Subject: “Percept” which is one or more physical objects.
  • Subject property: Anything that describes a subject: location, identity, characteristic etc..
  • Timepoint: Point or span of time.

The initial publication of the CBS was found to be too high level. The model was hurriedly reworked and republished in 1993 as a series of CBS Application views one of which was later renamed the CBS Clinical View. This view was a slightly lower level ontology. After nearly 5 years and 5 million GBP had been invested in the model it was decided to use it as the foundation for a series of “demonstrator projects”. This work began in 1992/3. I was involved in the largest of these projects where the CBS was to be used as the foundation for an entire Hospital Information Support System. This system was to cover every aspect of hospital information management: patient master index, inpatient and outpatient management, orders and results reporting, , maternity, pharmacy, and many other ancillary activities including; clinical laboratories, laundry, and facilities management. By using the CBS as a conceptual model the final system was intended to be reusable across the NHS and be fully “future-proofed”. The system took almost 3 years to build and while it was successful in the first hospital it was only reused once.

In 1998, 3 years after the Hospital Information Support System was completed the model was redefined yet again and renamed the NHS Healthcare Model (HcM). But by this point it was too late. No one believed in the blue fairy of future proofing anymore and the model was abandoned. It is no longer even available online from any official NHS website. However, last year I downloaded a copy in anticipation of writing this article. So here is The Common Basic Specification (CBS) a.k.a. The NHS Healthcare Model (HcM). Take a look around and try drilling down on some of the diagrams to get a real flavor of the model. (If you want a complete copy just send me an email and I will send a zipped file. Please don’t over stress my poor machine by downloading the whole thing.)

As ontologies go the Common Basic Specification is large and complex, which is not surprising given its scope and the length of time it took to develop. The CBS was reworked and refined until it became a clean conceptual model for generic service delivery. It is; coherent – logical in the relationship of its parts, generic enough to handle any healthcare delivery use case, and it is mature – the corners have been knocked off. So why did it fail?

Reasons for Failure of the Common Basic Specification

Of the Millions of pounds spent on developing the CBS very little was spent on articulating the benefits of implementing a common standard or training people to use the model. Many potential beneficiaries of the model did not see the value of training staff to understand it. Implementing an ontology is a political activity. It requires persuasion, coercion and sometimes direct threats. Small specialized groups can be persuaded to agree on large complex ontologies but large groups find such agreement difficult and often impossible. It is almost as if there was a law governing the adoption of ontologies.

The size and complexity of an ontology is inversely proportional to the size and complexity of the community of agents that can be persuaded to adopt it.

But there is a more fundamental problem with top level ontologies that is not political. At higher levels of abstraction every conceptual model is subjective; there is always another way to model reality. It can be advantageous to deliberately take a contrary view precisely because it will lead to different conclusions that may offer competitive advantage over others. The field of Healthcare delivery is large enough to accommodate many different world views. The CBS failed because it was the fossilization of a single world view.

Finally the Common Basic Specification took a top down reductionist approach to a fundamentally bottom up emergent problem. This same fundamental error is made by all top level ontologies. It is being made today by the developers of SUMO, an ontology doomed to the same fate as the CBS. As a professional body the IEEE ought to know better. A top down reductionist approach is useful for constrained problem domains but it is the wrong strategy for broad areas of knowledge. Robert Graves understood the tradeoff between a top down and a bottom up and explained it better than I ever could in his poem In Broken Images.

In Broken Images

He is quick, thinking in clear images;
I am slow, thinking in broken images.

He becomes dull, trusting to his clear images;
I become sharp, mistrusting my broken images,

Trusting his images, he assumes their relevance;
Mistrusting my images, I question their relevance.

Assuming their relevance, he assumes the fact,
Questioning their relevance, I question the fact.

When the fact fails him, he questions his senses;
When the fact fails me, I approve my senses.

He continues quick and dull in his clear images;
I continue slow and sharp in my broken images.

He in a new confusion of his understanding;
I in a new understanding of my confusion.

Robert Graves

This entry was posted in System Design and tagged , , , , , . Bookmark the permalink.
  • http://www.hakank.org/webblogg/archives/000488.html hakank.blogg

    Ontology Review

    Virtual Travelog kommer att skriva en serie om olika ontologier och dess

  • Ken Evans

    Very interesting article! I would add that “Top down modeling approaches don’t work because you have to make too many assumptions when you initially decide where the top is.” Like the routes of many UK roads, many “business process models” are a legacy of the first sheep that trod the path. Do you know where I can find an electronic copy of the CBS logical model (ER format). Ken

  • John R. Harris

    Ken

    Thanks for the comment. I think you make two points which are both valid but separate. “Deciding where the top is” is of course an impossible tasks since it is subjective. Paving the cow (or sheep) path is another problem. I think the CBS suffered from the first problem but not the later. Many Ontologies do pave the cow path but the CBS did not.

    As for an ER model of the CBS. The last time I saw such a thing was in 1993. I have a “UML” model which I could send you (let me know by email). If you just want to look around I have made the UML model available here

  • http://docrpm.com/ Ryan

    make excellent points about the human-oriented roadblocks to the successful implementation of an ontology…the failure of the CBS reiterates a basic fact about the need to balance usability, value propositions, and complexity. this pattern plays itself out repeatedly in (web) software implementations as well, where the famous [Quality x Acceptance = Effectiveness] rule applies.

    i might suggest one modification to your rule about ontologies. unless i misread, it seems that you meant to say that a *successful” ontology’s size and complexity is inversely proportional to the size and complexity of the group of agents expected to adopt it.

    i wonder how this rule applies to groups of machine agents (either hardware or software). machines don’t suffer from ego, laziness, or requirements for clear value propositions; they gain nothing from politics. they need not be presuaded to use an ontology. are there other implications when trying to implement a complex ontology with a set of automated user agents?

  • Jim Stuttard

    Enjoyed v much. U might like Critical Care Pathways by Julian Todd – consultants design ccps in uml using system architect. I’d v much like a copy of your cbs uml model.

  • Pat Lillies

    Possibly a dead thread given the length of time since the last posting, but thought I would add this. The Boston story basically matches the actual source. The phrase originates with a poem written by Sam Walter Foss (1858-1911) originally of New Hampshire, but he did live in Boston for a period of time, so the reference to Boston streets may be legit. The poem was called “The Calf-Path” and can be found if searched on the Net. Somehow Calf has turned into cow, so perhaps Foss was also aware of the inherent travel efficiencies of cows, and used the meandering of calves to make his point.

  • Peach Teacher

    What does the expresion, “Paving the cow paths” mean?

    Interesting discussion of ontology, by the way!

    Thanks, Peach.

  • John R. Harris

    Peach

    Paving the cow path is an expression I heard first in the east coast of the US. The story as it was told to me is as follows:

    When the city of Boston was new and unpaved the city fathers decided against laying out a regular street plan and instead merely paved the paths that had been worn by cattle. The implication is that this has resulted in a chaotic inefficient street plan that lacks logic. The admonition not to “pave the cow path” is supposed to remind us not to enshrine a makeshift solution.

    Of course there are problems with this phrase. Cattle are actually a pretty good at finding the path of least resistance, which is often the best route for a road.