Detailed Clinical Models (DCM)

Introduction to the problem

2012-01-26T09:57:00.000-08:00

Are we there yet?
In spite of decades of experience with electronic health records and clinical decision support, the lack of semantic interoperability has prevented the predicted sea-change in healthcare. Health data is not comparable, it cannot be aggregated and it cannot be used to automate or augment clinical decision making. The solution requires a robust information model and rigorous attention to detail in use of clinical terminology which is well suited for clinical documentation, decision support, public health reporting, quality improvement and clinical trials.

A Detailed Clinical Model (DCM), within the scope of HL7, is a set of specifications for clinical content represented in HL7 v3 formalism. It provides the canonical static semantics for clinical information exchange independent of the particular information exchange paradigm.

The specific implementation presented is implemented as HL7 version 3 specifications which extend by constraint HL7 Clinical statement model using HL7 Templates and following the HL7 TermInfo (Use of SNOMED-CT) specifications. Furthermore, the model adopts a subset of the SNOMED-CT concept model attributes for Findings with Explicit Circumstances as mandatory, relying on the mechanism within the CD data types for post-coordination. This allows for a compact message which is reliably interpreted even by systems which are not designed around this model.

It may be possible to create DCMs with the same semantic content using terminologies other than SNOMED-CT. However, it is the consensus of the HL7 terminology community that SNOMED-CT offers the greatest opportunity to success. There is also a growing recognition (q.v. the TermInfo guide) that creation of implementable specifications which are not specific to a given terminology does not result in semantic interoperability. Thus, while the efforts at HL7 will initially focus on SNOMED-CT based DCM efforts, it should be kept in mind that subsequent efforts will be needed to evaluate other terminology approaches at some later time.
One other use of SNOMED-CT is as a reference terminology. DCMs defined using SNOMED-CT concept models could be re-implemented using other terminologies. The role of SNOMED-CT here isn't as an exchange terminology, but rather to define the semantics of the model, regardless of what controlled vocabulary is used at the interface/message level.

Detailed clinical models address issues of clinical content of health record systems and do not mandate a specific implementation, as transformations between this model and other alternative representations is possible. Furthermore, they are explicitly designed for use in multiple applications including messaging, structured documents, web services, or as the specification of a virtual medical record API for decision support or other components.

Clinical records serve multiple primary uses and roles. They primarily serve as a set of notes so a provider may refresh their recollection of a patient at a subsequent encounter, or as a means of communicating with other providers who may subsequently see the patient. Clinical records further provide a legal document to provide evidence of compliance with regulatory requirements as well as the account which documents the quality and conformance of care which is used to substantiate claims for reimbursement and defend against claims of malpractice. The record may also be primarily concerned with documenting observations gathered as part of a research endeavor, much as a laboratory notebook documents more basic experiments. Clinical decision support systems represent a more modern primary use of captured clinical findings. While the distinction is not terribly informing, secondary uses typically fall outside the direct care or purpose of the encounter, and more often (like the collection of information for research or use in a decision support application) have an analytic or computational focus. Some additional examples include collection of case histories required for board certification in some clinical specialties, reporting of cases of interest for public health authorities, quality assurance reviews, and research involving clinical encounter information (as contrasted with use of information collected primarily for research use). While the primary use requirements are well established, often by statute, and are often met with pre-Gutenberg technology, secondary use is highly dependent upon computational methods.

To meet the requirements of clinical research, clinical decision support, and the analytic requirements, clinical findings must be represented with considerations beyond the simple record keeping mandates and beyond the capability of narrative text. For information to be useful to anyone but another comparably educated professional, an author must express their findings as discrete observations in an information model that reflects the context in a structured manner using an appropriate controlled terminology (or proper structure for numeric data types). The representation of a shared pattern of expression, with the necessary structure to represent simple cases simply while allowing for semantic richness and complexity is the core requirement of the detailed clinical models (DCM) process. The use of shared detailed clinical models is essential to functional semantic interoperability. In addition, clinical system design is complicated by the need to create, often de novo, data structures and application logic. This is often left to the discretion of a non-clinician (and all too often, informatics naive) programmers resulting in the proliferation of lackluster electronic health records which fall short of the decades old promises of automation and improved patient outcomes due to decisions support technologies. One of the objectives of the detailed clinical models effort is the creation of a library of reference information components created by the leading clinical informatics experts in a peer-reviewed and maintainable manner for use by anyone wishing to create an application or system using clinical information.

Detailed clinical models have specific requirements. First, they reflect the clinical and biomedical reality with accuracy and precision. It is not sufficient to create data models which cannot capture the relevant details in complex cases, nor is it acceptable to have data models which impose rigid and complicated requirements for cases where the observation is simple (such as the case with most normal findings documented). Furthermore, there is nearly always some degree of imprecision in describing a finding, and often a degree of uncertainty as to the very existence or truth of the finding. For example, a physician may appreciate the soft, rounded edges of what appears to be an enlarged spleen on physical exam. They may be able to quantify it as mild, moderate, etc. or describe the lower edge in centimeters below the costal margin. In many patients, appreciation of abdominal masses is limited by their body habitus, and general physical examination estimation of size of visceral contents is notoriously inaccurate. The physician may not even be certain that they are palpating the spleen, and may wish to qualify it as “probably present” or “possibly present”. In contrast, diagnostic imaging (such as an abdominal CT or ultrasound) can provide accurate measurements with known precision/error.

Summary of DCMs

2012-01-22T17:53:00.000-08:00

There is a critical dependence on representing clinical content in a fashion which is both human readable (usually easy), useful for secondary analysis (hard), and which is machine-interpretable (very hard). Casual approaches nearly always fail, as they effectively tie their logic in knots, and use-specific, highly focused approaches lead to volumes of hard (if not impossible) to use piles of important information. There is a recognized need to have a systematic, precise, yet expressive and flexible approach to representation of structured clinical content specification at the level of clinical, research, and legal detail required.

Detailed Clinical Models (DCM) are a precisely defined set of data element specifications which capture the meaning and context of clinical information is a format which is amenable to analysis and use in clinical decision support systems. They provide a common information model for clinical data (including procedures, history and physical exam findings, diagnosis, problems, medication use) which is independent of the use of the information, the source of the information, and which can be shared between applications/services to facilitate semantic interoperability.
Benefits of DCMs include reducing the long-term cost of system development and maintenance by centralizing the management of complexity, and providing data element specifications which can be safely reused for multiple purposes. They also can help simplify migration of data from legacy systems, can be used to define persistence mechanisms which “future proofs” the clinical data, and makes it available for use outside the application which created it.

Specific examples where DCMs are the key enabling technology include interfacing “best of breed” systems, robust clinical decision support, rich data warehouses with precisely defined data, cross organizational quality measures, early recognition of infectious disease outbreaks, and computable electronic health record information exchange.

Design of DCMs is as complex as the clinical information they represent. They need to be able to capture data at the most specific and detailed level which is clinically relevant and which meets the basic requirements of clinical documentation. They also need to be able to represent simple findings simply, while allowing for arbitrary complexity. One of the most important advantages, and requirements, for DCMs is the need to have explicit representation of relationships between data elements, such as those linking a test result to a diagnosis to a therapy.

Detailed Clinical Models include both compositional rules to combine simple models into more complex models, and using multiple hierarchical design patterns (i.e. a broader pattern is constrained into a more specific child pattern) to create models which can be easily parsed and which have deterministic meaning. Similarly, terminology is bound and further constrained as part of the model definitions. All DCMs are a constraint on a common reference model (in the HL7 context, this would be the Clinical Statement Pattern), and will follow a common approach to definition to provide consistent data structures.

Why HL7 needs a DCM standard to collaborate as part of CIMI

2012-01-21T11:06:00.000-08:00

First, I want to be sure that there is a good understanding why HL7 needs a DCM DSTU when most of us working in the HL7 DCM space are also working on the CIMI () efforts.

I think the most important thing to remember is why some of us took up the banner after the "Bocca DCM Summit". There are clearly different aspects of the problem, and different motivations for trying to advance the agenda, so it isn't surprising that different aspects of this complex area require some experimentation and development.

Second, my focus has not been on UML modeling conventions for clinical content. The HL7 DCM DSTU draft/strawman I am working on is all about the methodology, intermediate level models, terminology-RIM interactions, and modularity.

In addition to the bottom-up clinical detail, we need a top-down specification so we can build complex things from simple parts, and so that we can write software which can process information, not just parse data into some local system. Thus, we need design patterns defined as HL7 Templates (whatever those turn out to be. Eg. the time series, which becomes a parent/contributor to the "pharmacological challenge and response model" (which the GTT is a specialization of).

The notion I have been selling (which is useful to consider for CIMI, explains why I think HL7 needs a DCM standard to provide a deterministic target to map CIMI models into).

#1 HL7 DCMs are critically needed as a quality improvement initiative in HL7 specifications (and fit nicely into one of the empty boxes of the SAIF matrix). There is too much variability in how various groups model the same content, and far too many complex issues of RIM semantics which are often not appreciated, ignored, not supported (e.g. CDA r2), or just done wrong.

#2 HL7 DCMs are needed because the existing 'reusable' representations are not terribly reusable and don't support generic programming methods. They are either specific to a standard desperately in need up updating (CDA r2, and I am not just picking on them, I am trying to find a few free minutes to help with a r2.1/2.5/3) or which lack the detail needed to implement in a fashion which supports interoperability.

#3 HL7 DCMs need to support non-messaging uses, particularly decision support and long term data persistence. I can throw together an XSD which conveys the data of a glucose tolerance test (and will post a UML of a 'sketch' for something more useful on the blog) in about a half hour. Of course, a year from now, you need to know exactly what I was thinking at the time to write any sort of algorithm to use the information. Using information is the goal, not just exchange or capture.

#4 HL7 DCMs need to provide explicit semantics which are based on both RIM semantics and terminology semantics as a cohesive whole. This turns out to be harder than a lot of people think, and requires expertise in terminology, modeling, RIM semantics, clinical statement pattern, and particularly (in most cases) SNOMED-CT concept model/TermInfo guidelines. So having a centralized and pre-built library of properly modeled content can serve to accelerate the development of a domain's clinical content specifications.

Return after hiatus

2011-01-31T08:54:00.000-08:00

It has been far too long since I was last on-line, and it is high time to resume some discussions about the importance of proper modeling of clinical content.

There are a lot of balls in the air in the healthcare IT world today. With so many different, often disconnected, efforts, we risk the creation of specifications which impair large scale interoperability, secondary use of information, and the benefits of clinical decision support as part of the order entry functions of an electronic health record system.

Several efforts are underway which will help pave the way. The Health Story project, which I am providing technical assistance, will seek to consolidate the existing discrepencies between HL7 v3 CDA r2 implementation guides. This helps to both correct some of the issues many have had, but also is a great illustration of the divergence in approaches which occurs without an overarching information model for the content.

The clinical statement pattern is the current foundation for modeling HL7 clinical content, be it for a message, a clinical document or as part of a web service. The clinical statement pattern provides a mechanism to create interoperable detailed clinical models, but does in an of itself will not provide this. Experience has shown that there are 'many ways to skin a cat'; the DCM effort simply exists to provide one best practice for doing so which can be shared between applications.

Off topic: future of Windows

2009-08-03T21:06:00.000-07:00

A little off topic, but since I have put the effort into evaluating Windows 7 v. Windows XP as well as OpenSolaris w/ GNOME 2.24 and openSUSE with KDE 4.3, I thought I would share (for the record, I am still using openSUSE 11.1/KDE 3.5.10 for actually doing work! Once they fix the bugs/glitches in the Kontact PIM--an Outlook killer--I will switch over full time).

I have been using Windows 7 for testing for the last few weeks and it seems so far to be as stable as Windows XP (only one BSOD so far) and unscrewed up a lot of Vista's folly.

The biggest implication is that for most business users is that they can probably expect to make the transition on their next laptops (which always come with some OS pre-installed) rather than having to request that Vista be downgraded to Windows XP.

That said, it looks like Windows is nearing the end of its usefulness, and even Windows 7 lags behind Linux which has a range of graphic user interfaces (KDE 4.3 in particular is visually stunning, fast and very easy to use) can run most Windows software (via WINE or in some virtual machine), and is much more stable (three weeks w/ one BSOD is pretty good for Windows, most Linux desktop users only reboot for kernel updates and unexpected/unrecoverable crashes are less than once a year in my experience. Laptop support is still a bit of an issue, since support for hot switching display settings and problems w/ WiFi after suspend-resume isn't quite there, but for the most part, things work well, easily and predictably).

As far as the future of Windows: I predict they will take (another) a page from Apple and pitch the whole OS and start over (well, Apple started with a venerable open source Unix) with a microkernal design (maybe even doing to Minix* what Apple did to BSD), security by design, with legacy support via WINE. The big part of the OS will be CLR (the .NET runtime standard) with a return to having POSIX as a Windows service (it was dropped from NT 4.0 along w/ OS/2 support when M$ released Win2K). This will be a change for Microsoft, since it will give them a modern OS, but at the cost of making it easier for application developers (including games) to use the same code base to generate software for Linux, Mac OS/X and Windows. This will run contrary to the long standing practice of making it as hard as possible for Windows developers to port their software to non-Windows platforms.

Beyond the fortune telling (which only time will bear out): KDE 4 is available for pretty much any OS which supports C++ and for which there are QT4 libraries. This includes Windows! You can replace the entire Windows desktop with KDE 4 and enjoy all the eye candy and fancy visual effects that Microsoft had to drop from Vista and Windows 7. I don't know if you can drop it in as easily on Mac OS/X, but it runs fine on just about any other UNIX-like OSs with a few odd balls that I don't know for sure (like QNX).

So, if you use XP and are happy, you are not missing any major functionality that I could fine. If youa re using Vista you should probably upgrade unless you got lucky and everything works. Once KDE 4.3 (currently in release candidate status) is stable, you will have a richer UI and more stable OS with Linux. If you are buying a new laptop, it is worth waiting until the vendor offers Windows 7 and go with that, rather than downgrade to XP or get stuck with Vista.

*Minix is a "UNIX-like" operating system that has some similarities to Linux, but uses a very different kernel design. Linux has the option to add modules to the kernel, and you can end up with a very functional, but large, runtime. For desktop and modern laptop PCs this isn't a big deal. For running Linux on your toaster, cell phone, wrist watch or other minimal platforms it usually takes some work to get a conventional distribution to fit on a non-traditional platform. Minix treats most of those things people usually think of as core kernal functions as services and this gives you some very interesting options for slimming things down to the bare minimum, and, if done right, is theoretically easier to design an ultra-stable platform. There are other microkernal OS's out there (QNX being one--it is stable enough that it is used for nuclear power plant control, the controls on a submarine, and the guideance and launch systems used on ICBMs).

Next top:

One small (overdue) example.

2009-07-26T16:49:00.000-07:00

You can see some early prototypes of detailed clinical models with the Clinical Data Definition work I did with Tolven a few years ago. A reasonable example would be the chest exam which isn't a complete, flushed out, all bells and whistles example, but it gives a basic idea of where we were two years ago.

One of the components, shown here, are the attributes of a heart ascultation finding. It has a main finding, or entry point, (just called Murmur) which has a fairly value set for the Observation.value drawn from a handful of SNOMED-CT concepts which describe the bulk of the murmurs we routinely encounter in practice.

Always behind our times: Isn't time we started planning on moving to the 21st century?

2009-06-23T20:45:00.000-07:00

Several discussions lately have focused on the "low hanging fruit" (which I still maintain is an anti-pattern of healthcare IT). Twice this has centered on the use of billing data, in the form of ICD9 codes, for either use in problem lists or for doing clinical research.

We still have a dramatic gap in the US between what we could do (given some time and space to collaborate, financial support, and endorsement by HITSP) and what we are doing. This is an example where we are so far behind we do need to recalculate our trajectory and start warning people that we will be living in the past for a while longer.

One of the "big" changes, currently scheduled for October, 2013 (originally was slated for 2011) is CMS moving away from the use of ICD9 (International Classification of Disease, 9^th edition) for claims submission to ICD10.

For those who are not tracking the fast-paced world of coded classification systems, ICD9 was put into use in 1975 and is the system used to provide information to payers (CMS being the agency behind Medicare) which is used to justify a claim for healthcare services. It provides groups of codes (21669 as of my last count in the US ICD9-Clinical Modification, ICD9CM) to classify diseases into discrete, mutually exclusive pigeon holes. It was replaced by ICD10 some time ago to report the cause of death to public health agencies, but it is otherwise the most common code system found in outpatient clinics which convey information about a diagnosis.

It has some well known shortcomings which make its use in electronic health records, particularly problem lists (or health concern tracking as we are now calling it), unwise. For example, there is no way to say that someone has a headache in ICD9. There are codes for various types of headache, but they all exclude each other in their definitions. In particular the non-specific “visit code” for a head ache specifically excludes migraine head aches and tension head aches. Which is why using ICD9 to convey health information for patient care reasons (as opposed to billing/administrative/public health reporting use) gives me a head ache.

That aside, it is what everyone seems to be using since we have a ton of data from our billing systems which bears some semblance to what we actually diagnose people as having and, voilà, we have ourselves coded data! The problems are it has been shown to have a only a casual correlation with what people are really diagnosed (e.g. by their physician), and that the codes are chosen to help optimize reimbursement, and most systems have a fixed number of codes that can be captured at any given encounter so that the choice of what codes get put into the slots is more often than not motivated by optimizing billing return rather than reflecting what is important to know about a patient.

Back to my original musing about this super huge big deal of switching to ICD10 in four years. ICD10 is marginally better than ICD9. It allows some diagnosis to be in more than one category (well, not really, but it tries, and by “more than one” I mean two, but only if the second category is an infectious disease or cancer) so that a diagnosis of bacterial pneumonia can now be considered both a bacterial disease -and- (drum roll please) a disease of the lung. It also now uses a letter in the code, rather than all numbers. It does have more diagnosis codes, but is otherwise pretty much the same old.

ICD10 has been around since 1994, or four more years since Jim Cimino's seminal Desiderata for Controlled Medical Vocabularies in the Twenty-First Century (Methods of Information in Medicine 1998;37(4-5):394-403), which called for moving away from ICD-like vocabulary systems in favor of more expressive, more flexible and more logical terminologies (such as SNOMED-CT which was released in 2002 by merging SNOMED-RT with the UK NHS Clinical Terms aka the Read Codes. SNOMED traces its roots back to the Systematic Nomenclature of Pathology circa 1965, or back when we were using ICD8!). You can find much more information on SNOMED at the National of Library website (http://www.nlm.nih.gov/research/umls/Snomed/snomed_faq.html) and from the IHTSDO website at (http://www.ihtsdo.org/snomed-ct/).

So the effective result is that in 4 years we are moving from a 1970's era code system, to a 1990's era code system, which we have known for at least the last ten years to be inadequate for use in health record systems.

At some point we need to start making provisions to actually use technology that is more contemporary, such as ICD11, which is slated for release the year before the US makes the leap to ICD10. A more realistic option is to educate clinicians (they are not so stupid as some IT types make them out to be) about the options and the consequences of doing thing right, particularly when we want to start using data to support "pay for performance" where ICD9/10's shortcomings will be very evident or for personalized medicine where using blunt instruments like ICD9/10 will just work when we start talking about trying to customize medication (and other therapy) based upon knowledge about individual's molecular structure.

More later on the rationale, problems, and proposed use of SNOMED-CT for health care information in the United States, circa early 21^st century.

Welcome

2009-04-18T08:46:00.000-07:00

Welcome to the Detailed Clinical Models blog!

Detailed Clinical Models is a growing effort to bring together the collective wisdom and requirements of the health care informatics community for the ability to create clinical content which reflects the clinical (biomedical) reality in a fashion which is semantically inter-operable between domains, users, applications and applications.

Detailed Clinical Models (DCM) are explicitly intended to support multiple uses of the model and of the information.

Clinical documentation. This is at the level and expressiveness needed for continuity of care, communication between (human) health care providers, consultation reports, billing, medical record keeping regulations (including those required by the US Drug Enforcement Agency DEA for prescribing controlled substances), medico-legal requirements, and, in general, those requirements which currently are met by narrative (written, dictated) paper health record systems.
Decision support systems.
Public health reporting.
Quality of care metrics. This also includes meeting the needs automating an accurate data set needed to meet pay-for-performance incentives and for providing sufficient detail that allow meaningful comparisons based on patient complexity and acuity.
Clinical research. This includes requirements for regulated clinical trials and disease registries.
Personalized medicine.
Translational bioinformatics.
Other secondary uses of information.