Semantic Interoperability, EHR, etc. are of little use to someone whose claim is denied by his or her insurance company

Founded in 1945, Kaiser Permanente is this nation’s largest not-for-profit health plan, serving more than 8.6 million members, with headquarters in Oakland, California.

This blog has carried a prominently-placed electronic health records (EHR) video outlining some of the excellent information technology work that's being introduced by Kaiser Permanente.

So, given the placement of this video, I feel a responsibility to add here the reality that Kaiser Permanente's technology is only one facet of a system that daily makes decisions about who can and who cannot get health care.

The California Nurses Association/National Nurses Organizing Committee has just released new data that reveals more than one of every five requests for medical claims for insured patients, even when recommended by a patient’s physician, are rejected by California’s largest private insurers. (The Kaiser Permanente Health Plan membership in California is greater than 6 million.)

This is data that the health insurance companies have wanted to hide, and it’s just now becoming available. It documents that these insurance companies have denied, in California alone, 45 million claims since 2002. Some of these rates ranged as high as 40 percent (for UnitedHealthcare’s PacifiCare). And other large, giant insurers like Blue Cross, Health Net, CIGNA, and Kaiser were all in the range of 30 percent (Kaiser Permanente's denial rates is 28 percent). This report shows a clear pattern of very high denials by the very insurance companies that people depend upon to assure that they get the care they need when they need it.

There are a variety of reasons insurance companies claim why they make these denials: in the end though, it’s a war that goes on between the insurance companies and the doctors and the hospitals. (Note: Attorney General of California Jerry Brown has announced he’s going to conduct an investigation into the business practices of these companies and why these denial rates are so high.)

A recent piece in the Los Angeles Times quotes a spokeswoman for the California Association of Health Plans, responding to the data that the California Nurses Association/National Nurses Organizing Committee has just released, saying, “It appears [that] a good deal of the so-called denials are merely paperwork issues.”

It seems to me that even if you put the best face on the California Association of Health Plans' response, what it demonstrates is how much waste (aka administrative overhead) there is in the health insurance industry. It's been suspected for some time now that one-third of every healthcare dollar goes to waste and to enforcing claims denials in the United States..

Reasoning for Ontology Engineering and Usage and The Challenges of Modern Medical Ontologies

In my August 6 post, I briefly introduced ontology editor Protégé 4.0 with the reasoners FaCT++ (implemented using C++) and Pellet (Java based). Today's post picks up this story and adds the RacerPro (commercial) reasoner to the mix. You can -- and I recommend that you do -- download your own copies of the latest versions of these tools. Links that enable you to do so are located at the end of this post.



Protégé 4.0 with three reasoner added-ins

A reasoner is a piece of software able to infer logical consequences from a set of asserted facts or axioms. In the present context, a reasoner makes inferences about classes and individuals in an ontology, tasks that are beyond the Web Ontology Language (OWL) model alone.

Ontologies, as described in prior posts, are formal vocabularies of terms, often shared by a community of users, and, as such, ontologies play an important role in semantic interoperability and Web 3.0. One of the most prominent application areas of ontologies is medicine and the life sciences. For example, the Systematised Nomenclature of Medicine Clinical Terms (SNOMED CT) is a clinical ontology. Another example is the OBO Foundry -- a repository containing about 80 biomedical ontologies.

These ontologies are gradually superseding existing medical classifications and will provide the future platforms for gathering and sharing medical knowledge. Capturing medical records using ontologies will reduce the possibility for data misinterpretation, and will enable information exchange between different applications and institutions.

Medical ontologies are strongly related to description logics (DLs), which provide the formal basis for many ontology languages, most notably the W3C standardised OWL. All the above mentioned ontologies are nowadays available in OWL and, therefore, in a description logic. The developers of medical ontologies have recognised the numerous benefits of using DLs, such as the clear and unambiguous semantics for different modelling constructs, the well-understood tradeoffs between expressivity and computational complexity, and the availability of provably correct reasoners and tools (discussion to follow).

The development and application of ontologies crucially depend on reasoning. Ontology classification, i.e., organising classes into a specialisation/generalisation hierarchy, is a reasoning task that plays a major role during ontology development: it provides for the detection of potential modelling errors such as inconsistent class descriptions and missing sub-class relationships. For example, about 180 missing sub-class relationships were detected when the version of SNOMED CT used by the NHS was classified using the DL reasoner FaCT++. Query answering is another reasoning task that is mainly used during ontology-based information retrieval; e.g., in clinical applications query answering might be used to retrieve "all patients that suffer from nut allergies".

Despite the impressive state-of-the-art, modern medical ontologies pose significant challenges to both the theory and practice of DL-based languages. Existing reasoners can efficiently deal with some large ontologies, but many important ontologies are still beyond the reach of available tools (i.e., they are unable to classify some widely used ontologies).

Applications currently need to work around these limitations, e.g., by using subsets of ontologies that can be successfully processed. For example, the version of GALEN typically used in practice contains only about 20% of the axioms of the full version; this reduces the interaction between concepts and thus makes the ontology "processable". This is, however, highly undesirable in practice, because it reduces coverage, weakens the conceptualisation of the domain and may prevent the detection of modelling errors.

Furthermore, the amount of data used with ontologies can be orders of magnitude larger than the ontology itself. For example, the annotation of patients' medical records in a single hospital can easily produce data consisting of hundreds of millions of facts, and aggregation at a national level might produce billions of facts. Existing reasoners cannot cope with such data volumes, especially not if ontologies such as GALEN and FMA are used as schemata.

Having forewarned you about these limitations, I'd like to recommend the following video on reasoners -- free and commercial.

http://videolectures.net/iswc08_moller_itsr/

Some readers of this blog might not be familiar with terms that appear in the video, starting with ABox and TBox.



For those readers especially, the following links for accessing the Protégé, Pellet and Racer sites could be used to install and examine this software (and accompaning documentation) before watching the videos.

Protégé http://protege.stanford.edu/

Pellet http://clarkparsia.com/pellet/

RacerPro http://www.racer-systems.com/

Then, as you watch the video, you could follow along using your own running code. For some, this will require more than a single session.

Recommended reading - basics of description logics:
www.inf.unibz.it/~franconi/dl/course/dlhb/dlhb-01.pdf
www.inf.unibz.it/~franconi/dl/course/dlhb/dlhb-02.pdf
http://www.cs.man.ac.uk/~horrocks/Slides/IJCAR-tutorial/Print/p1-introduction.pdf

Semantic Interoperability -- Part III Ontologies -- Prelude to Electronic Health Records (EHR)

This post is a continuation of the introduction to ontologies that I posted on August 4 and July 20.

Readers new to this subject might also find the 2 ½ minute video What Is Web 3.0, Anyway? worthwhile.

An ontology is an explicit specification of a conceptualization (defined earlier), that is to say, a formal representation of a knowledge domain. Usually an ontology consists of: (i) classes, which represent the concepts of the domain (for example, in an ontology about the domain of Telecommunications, as in the listing below, a possible concept could be "Phone"); (ii) properties, to establish relationships between the concepts (for example, a "Phone" concept could have as property the "Company"; (iii) instances, with concrete examples associated with every concept (for example, "Siemens" could be an instance of the "Company” concept); and (iv) axioms, which are restrictions applicable to certain elements of the ontology, necessary to specify completely the knowledge domain (for example, in the ontology about telecommunications, it could define a restriction to indicate that in this domain a "Phone" must have always, at least, a "Company").

Ontologies can be stored using XML-based markup languages such as OWL (Ontology Web Language), which facilitates their reuse in different semantic platforms to annotate and search resources. These languages allow us to define tags in order to represent the different ontology elements. The listing below shows an extract of a OWL file containing the Telecommunications example ontology that has been created using the Protegé tool. As you can observe, in this language, the concepts are delimited by the Class tag, the properties by the ObjectProperty tag, the instances by the tag corresponding to the associate class (in the example, the class Company has as instance "Siemens"), and the axioms with tags like Restriction or subClassOf (this one is used in the example for representing that "Cellphone" is a type of "Phone").



Content of a OWL file - a fragment of an
Ontology about Telecommunications
{click to enlarge}

Today one of the main uses of ontologies is to support the Semantic Web (aka Web 3.0), especially for annotating Web resources and facilitating the localization of these annotated resources when users formulate queries to semantic search engines. For this purpose, in the previous example of Telecommunications, an ontology has included two annotations as instances of the “Phone” and “Cellphone” classes which correspond to two documents (“Gigaset3015Classic.pdf” and “MobileC55.pdf”, respectively) located in a hypothetical Web server (“http://www.telecosiemens.com”).

The Reality

Researchers have written much about the potential benefits of using ontologies, and most of us regard them as central building blocks of the Semantic Web and other semantic systems. Unfortunately, the number and quality of actual, “non-toy” ontologies available on the Web today is remarkably low. This implies that the Semantic Web community has yet to build practically useful ontologies for a lot of relevant domains in order to make the Semantic Web a reality.

In striking contrast to the data within a stand-alone document, publications have yet to benefit from the opportunities offered by cyber infrastructure. While the means of distributing publications has vastly improved, publishers have done little else to capitalize on the electronic medium. In particular, semantic information describing the content of these publications is generally sorely lacking, as is the integration of this information with data in public repositories.

The Reasoner

One of the key features of ontologies is that they can be processed by a reasoner. One of the main services offered by a reasoner is to test whether or not one class is a subclass of another class. By performing such tests on all of the classes in an ontology it is possible for a reasoner to compute the inferred ontology class hierarchy. Another standard service that is offered by reasoners is consistency checking. Based on the description (conditions) of a class, the reasoner can check whether or not it is possible for the class to have any instances. A class is deemed to be inconsistent if it cannot possibly have any instances.

Reasoning with Protégé 4.0

Reasoning with your ontology is one of the most commonly performed activities and the ontology editor Protege 4.0 comes with 2 built-in reasoners, FaCT++ and Pellet. To classify your ontology, open the Reasoner menu and select one of the available reasoners. FaCT++ will automatically classify your ontology. Pellet requires that you select classify. Once you have done this, the class hierarchy on the Entites tab changes to show the inferred class hierarchy. Unsatisfiable classes appear in red under Nothing, and everything else appears in the hierarchy under their inferred superclasses. The asserted class hierarchy is still available, stacked under the asserted one, as shown in the next screenshot.



Screenshot of an inferred class hierarchy
{click to enlarge}

Instructions for getting started with the OWL editor in Protege 4:
http://protegewiki.stanford.edu/index.php/Protege4GettingStarted

A Practical Guide To Building OWL Ontologies:
http://www.co-ode.org/resources/tutorials/ProtegeOWLTutorial-p4.0.pdf

The Microsoft Word Add-in For Ontology Recognition – An Introduction

There are other tools (e.g., The Microsoft Word Add-in For Ontology Recognition to name one) that might be suitable for your needs. It’s a MS Word 2007 add-in that enables the annotation of Word documents based on terms that appear in ontologies.

This Word Add-in For Ontology Recognition is a free Microsoft download. With it, as shown in the figures below, you select and then download one or more ontologies which are thereafter available automatically from within your Word document.

The Microsoft Word Add-in For Ontology Recognition – An Overview

This add-in enables authors who use Microsoft Word for content creation to incorporate semantic knowledge into the content. This add-in should simplify the development and validation of ontologies, by making ontologies more accessible to a wide audience of authors and by enabling semantic content to be integrated in the authoring experience, capturing the author’s intent and knowledge at the source, and facilitating downstream discoverability.

The goal of the add-in is to assist authors in writing a manuscript that is easily integrated with existing and pending electronic resources. The major aims of this project are to add semantic information as XML mark-up to the manuscript using ontologies and controlled vocabularies (from the National Center for Biomedical Ontology) and identifiers from major biological databases, and to integrate manuscript content with existing public data repositories.

As part of the publishing workflow and archiving process, the terms added by the add-in, providing the semantic information, can be extracted from Word files, as they are stored as custom XML tags as part of the content. The semantic knowledge can then be preserved as the documented is converted to other formats, such as HTML or the XML format from the National Library of Medicine, which is commonly used for archiving.

The full benefit of semantic-rich content will result from an end-to-end approach to the preservation of semantics and metadata through the publishing pipeline, starting with capturing knowledge from the subject experts, the authors, and enabling this knowledge to be preserved when published, as well as made available to search engines and presented to people consuming the content.

The Microsoft Word Add-in For Ontology Recognition – Screen Shots

{click to enlarge}

The Word Add-in For Ontology Recognition User’s Guide for the Semantic Mark-up and XML Formatting of Scholarly Articles is a good place to start for further information on this tool.

Semantic Tagging

When a word or set of words is tagged by the add-in, the word is wrapped with some tags that associate it with the ontology term. The example below shows the word "disease" being tagged with Human Disease ontology.

{click to enlarge}

If the Word file (docx) is to be transformed to other formats, this set of tags would need to be processed using xslt or other technologies. Note that there are other CodePlex projects available which implement transformations of docx files to other formats, which one can start from.

Ontology Add-in for Microsoft Office Word 2007 Video

Metcalfe's law vis-à-vis the value of semantic interoperability

A new economic model

Metcalfe's law states that the value of a network is proportional to the square of the number of connected users of the system (n**2).

Metcalfe's law characterizes many of the network effects of communication technologies and networks such as the Internet, social networking, and the World Wide Web. It is related to the fact that the number of unique connections in a network of a number of nodes (n) can be expressed mathematically as the number n(n − 1)/2, which is proportional to n**2 asymptotically.



The law has often been illustrated using the example of fax machines: a single fax machine is useless, but the value of every fax machine increases with the total number of fax machines in the network, because the total number of people with whom each user may send and receive documents increases.

Metcalfe's law is more of a heuristic or metaphor than an iron-clad empirical rule. In addition to the difficulty of quantifying the "value" of a network, the mathematical justification measures only the potential number of contacts, i.e., the technological side of a network. However the social utility of a network depends upon the number of nodes in contact. For instance, if Chinese and non-Chinese users don't understand each other, the utility of a network of users that speak the other language is near zero, and the law has to be calculated for the two sub-networks separately.

When considering electronic health record (EHR) interoperability, two nodes are in contact in a meaningful way if the nodes themselves, not just human beings sitting at those nodes, can understand the content of a message from the other node in an unambiguous way. In other words, semantic interoperability is what counts.

Apropos of EHR, Rod Beckstrom, the recently appointed president of the Internet Corporation for Assigned Names and Numbers (Icann), has used his address to the Black Hat USA 2009 conference to propose a new economic model for valuing computer networks and the internet.

"Who cares how many nodes there are?" Beckstrom said. "If you look at a value of the network, focus on the transactions. The value of the network equals the net value added to each user's transactions, summed for all users."

For example, some networks grow the number of users but become less valuable since the value of their transactions is so small.

Microsoft chairman Bill Gates dropping his Facebook account in July was a case in point, Beckstrom said. The number of 'friends' became so great that the network lost its value.

Electronic Health Records (EHR) - Semantic Interoperability - Part 1

To press a suit means one thing to a tailor and another thing to a lawyer.

A free radical means one thing to a chemist but meant another thing to members of the House Un-American Activities Committee (HUAC) during the 1950’s.

And, medication for pain and pain medication don’t always mean the same thing. The controversy surrounding the recent death of Michael Jackson illustrates this last point.

In the examples above, as in clinical terminology, words can take on different meanings depending on factors like time or place (i.e., context).

Furthermore, clinicians and organizations use different clinical terms that mean the same thing. For example, the terms heart attack, myocardial infarction, and MI may mean the same thing to a cardiologist, but, to a computer, they are all different. There is a need to exchange clinical information consistently between different health care providers, care settings, researchers and others (semantic interoperability), and because medical information is recorded differently from place to place (on paper or electronically), a comprehensive, unified medical terminology system is needed as part of the information infrastructure.

Interoperability

Interoperability is the ability of two parties, either human or machine, to exchange data or information.

First, syntactic interoperability guarantees the exchange of the structure of the data, but carries no assurance that the meaning will be interpreted identically by all parties. Web pages built with HTML or XML are good examples of machine-to-machine syntactic interoperability because a properly structured page can be read by any machine with a Web browser. The meaning of the page to a particular machine may vary substantially; however, this is not usually considered a problem because the semantics of a page are meant to be interpreted by human viewers.

Next, human or semantic interoperability guarantees that the meaning of a structure is unambiguously exchanged between humans. Documents such as progress notes, referrals, consults, and others achieve semantic interoperability at a clinician-to-clinician level by relying on common medical vocabularies.

Finally, computable semantic interoperability requires that the meaning of data be unambiguously exchanged from machine to machine (as shown in the figure below). This does not necessarily mean that all machines need to process the received data the same way, but rather that each machine will make its processing decisions based on the same meaning.



Words and Meanings

The meanings of words change, sometimes rapidly. But a formal language such as used in an ontology -- a rigorous and exhaustive organization of some knowledge domain that is usually hierarchical and contains all the relevant entities and their relations -- can encode the meanings (semantics) of concepts in a form that does not change. In order to determine what is the meaning of a particular word (or term in a database, for example), it is necessary to label each fixed concept representation in an ontology with the word(s) or term(s) that may refer to that concept.

When multiple words refer to the same (fixed) concept, in language this is called synonymy; when one word is used to refer to more than one concept, that is called ambiguity. Ambiguity and synonymy are among the factors that make computer understanding of language very difficult. The use of words to refer to concepts (the meanings of the words used) is very sensitive to the context and the purpose of any use for many human-readable terms.

The use of ontologies in supporting semantic interoperability is to provide a fixed set of concepts whose meanings and relations are stable and can be agreed to by users. When a word used in some interoperability context changes its meaning, then to preserve interoperability it is necessary to change the pointer to the ontology element(s) that specifies the meaning of that word.

There are a number of tools for the programmatic handling (i.e., creating, querying, etc.) of ontologies. The visual representation of ontologies is an important contribution of these tools.



IBM Integrated ontology Development Toolkit (formerly named IBM Semantics Toolkit) is one of many toolkits designed for storage, manipulation, query, and inference of ontologies and corresponding instances.

An upcoming post will discuss the role and value of semantic technology in service-oriented architectures (SOA).

Electronic Health Record Interoperability: Specifications, Standards, and Working Groups

{Prelude to upcoming post - semantic interoperability}

The American Recovery and Reinvestment Act of 2009 (ARRA) states that the HIT Policy Committee shall make recommendations on standards and implementation specifications, among other tasks.

The Healthcare Information Technology Standards Panel (HITSP) EHR-Centric Interoperability Specification consolidates all information exchanges that involve an Electronic Health Record (EHR) System within any of the thirteen HITSP Interoperability Specifications existing as of February 13, 2009, the enactment date of the American Recovery and Reinvestment Act (ARRA).

Reading these two statements and others like them requires an understanding of terms such as

* recommendation
* specification
* standard, and
* working group

Each of these bullets is linked to its Wikipedia entry.



Given that many of the readers of this blog (from 42 countries so far) are interested in the information technology aspects of The American Recovery and Reinvestment Act , electronic health record interoperability and the like, it may be easier for them if I elaborate on the four terms listed above by using the example of cascading style sheets (CSS), a simple language that allows you to declare how documents are displayed by Web browsers. By so doing, I’ll be introducing additional expressions with which these members of the IT community are already familiar.

The Cascading Style Sheets language was created through a collaborative effort between Web developers and browser programmers under the auspices of the World Wide Web Consortium (W3C for short).

The W3C is an international industry group that comprises over 500 companies, research institutions, and Web development organizations that issues technical specifications for Web languages and protocols.

W3C specifications are called "recommendations" because the W3C is technically not a standards-issuing organization, but in practice this is usually an issue of semantics.

Recommendations are taken as defining a standard form of a Web language, and they are used by Web developers, software tools creators, browser programmers, and others as a blueprint for computer communication over the Web. Examples of W3C Recommendations include Hypertext Markup Language (HTML) and Extensible Markup Language (XML).

The CSS Specifications

The W3C Recommendations issued by the Cascading Style Sheet working group compose the official specification for the CSS language. The CSS working group consists of a number of experts in Web development, graphic design, and software programming, representing a number of companies, who all work together to establish a common styling language for the Web.

CSS Level 1

The Cascading Style Sheets Level 1 (sometimes called CSS1 for short) was officially issued as a W3C Recommendation in December 1996. The URL for this specification is http://www.w3.org/TR/REC-CSS1.

If you try to read the W3C Recommendation for CSS1, you may end up confused. That's because W3C documents aren't written as a general introduction to a subject but rather as precise language definitions for software developers. Most W3C Recommendations are quite opaque to most normal people, although the CSS1 specification isn't too bad compared with some. Being able to refer to the official specification is quite useful, though.

Optional note for programmers - Classes and IDs

In addition to setting styles based on HTML elements, CSS allows for rules based on two optional attributes in HTML: class and id. Each of these can serve as the selector part of a CSS rule and can be set on any visible HTML tag.

The div and span elements really come into their own with class and id selectors. Through the use of class and id attributes, div or span tags can be made to have nearly any effect and presentation, which is often good but sometimes bad. Care must be taken to avoid using class or id selectors that you're not ignoring more appropriate markup, which has understood semantics. In other words, a div with a class of bldtxt has no specific meaning in the context of HTML, but a strong tag definitely does. Before using div or span, consider if another tag would make more sense.

The mention above of the word "semantics" is meant to be a segue to the subject of a later post, semantic interoperability.

Interoperability of Disparate Systems ...

A system that includes new and old technologies -- partially represented by the use case diagram shown below -- will be the subject of upcoming posts. Interoperability -- technical and semantic -- using open, standard protocols will be my focus.



{double click for larger view}

For anyone not familiar with use case diagrams, here's a link to an easy-to-follow introduction to using them and another link to the Wikipedia entry for use case diagrams.

The discussion of technical interoperability will include, but not be limited to, whether to employ Web services with BPEL or ESB (or both) and business activity monitoring (BAM) tools.

The discussion of semantic interoperability will include, but not be limited to, whether to employ HL7 version 3 messages or CDA documents (or both).

Other topics such as service level agreements (SLA), key performance indicators (KPI), telemetry, and telemedicine will be included.