Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Wednesday, August 4, 2010

Standards Activity around Clinical Decision Support

The next week for me is about, in large part, clinical decision support, and I hope to figure out just a bit more about where it is going.  I've had to spend a couple of hours each of the last couple of days thinking about it.  There is quite a bit and yet not quite enough is going on with CDS these days.  The holy grail of CDS is to build a repository of CDS algorithms that can be identified and applied to the appropriate patients, but we still aren't there yet.  Except for Meaningful Use, Clinical Decision Support is the most often searched for topic hitting this space.

Here's just a brief summary of some things that are going on:

AHRQ is working with Thomson Reuters to develop a way to describe a CDS algorithm.  This particular project is a bit cart before the horse because the real problem is NOT how to describe logic (for that we have programming languages), but how to describe the data needed to solve the problem. 

HL7 start work on a respecification of GELLO, as a "profile" of the OMG Object Constrain Language (OCL), instead of a derivation from it a bit more than a year ago.  GELLO is a side-effect free declarative language for Clinical Decision Support that has quite a number of very useful properties for clinical decision support applications.  This work may help.  There are only a few commercialized implementations of GELLO that extend from the original OCL base.  But there could be a lot more implementations of OCL that could be used without extension once the new specification is completed.  The increased availability of GELLO (using the 2.0 specification) should make implementation of clinical decision support logic more widely available.  Even so, we don't have any lack of programming languages to express logic in, declarative or procedural.

Another project going on is the development a repository of CDS algorithms (at the behest of ONC and through RAND), and demonstration of their use.  Once again, a repository is good, but until we know how to index the data that we need, we probably don't know what metadata is needed in the repository.  It should be interesting to see where this work is headed though.

HL7 is working on a Domain Analysis Model for the Virtual Medical Record.  This is critical work but is still very much in development. The VMR is to the electronic health records as the W3C DOM is to XML.  These models will be critical in any eventual expression of clinical decision support logic.

IHE has developed at least three different profiles (QED, CM, and RFD), all of which should help us to integrate clinical decision support services into healthcare applications.  These IHE profiles provide implementations of a functional CDS service, and are also congruent with recent HL7/OMG work on Clinical Decision Support Services. 

And at the same time, NQF is developing data models for quality measures.  These same data models need to be coordinated with other work in CDS to be baked in clinical processes described in guidelines at the very beginning.

Another area of interest is the finalization of the order sets standard in HL7.  Order sets are prepackaged collections of activites to perform for patients meeting a particular criteria.

There's a lot going on, and everyone seems to be headed in a slightly different direction.  But what we are seeing is a natural divergence in an important new phase in healthcare.  If the same development cycles follow here as everywhere else in IT, there will be an eventual convergence, but it is clearly a little way away.

The divergence is just a little bit frustrating for anyone trying to follow everything that is going in.  In fact, if you think you are succeeding in this area, drop me a line and I'll give you a few more threads to follow.  There are a few gaps left, but introducing more work before some of it is completed just isn't an effective way to keep everything moving forwards.
And of course, in all of this, we are still really talking about just the tip of the iceberg.  Clinical decision support is more than just the black box that answers questions.  See my first post on the topic for a summary of what is included in CDS.

4 comments:

  1. Development/ref. Implementations of GELLO have not kept up with the specs making it tough for anyone to consider GELLO. Do you see any changes there going forward?

    -arun

    ReplyDelete
  2. There is also the work of Anvita Health. I have seen a demo of their analytics engine and its actually quite good. I know John Halamka has spoken of them previously.

    ReplyDelete
  3. The major change I see in the development of GELLO is an OCL-based implementation of it. Current "OCL-like" implementations are derived from but have more features than OCL. The OCL-based implementation will be strictly derived from OCL. That means that you can build a GELLO implementation on top of an existing OCL implementation without changing the underlying language. See V3 GELLO R1: OCL-Based

    ReplyDelete
  4. The OCL-based GELLO spec has not been under active development for a while. The recently standardised GELLO specification is based on many years of research and it has the features that OCL lacks to make it usable in decision support. I see the move to "Pure OCL" as doomed to failure because of this and surely a language optimised to decision support is what we need.

    The GELLO spec released this year has fixed the BNF errors in the first release and is now implementable.

    The devil is in the details and after implementing GELLO and using it for real world decision support its clear why the deviation from OCL exists. OCL is optimised for UML and GELLO for decision support.

    I am one of the Authors of the revised GELLO specification, and my name appears on the V2.0 for comment document, but after doing real world implementation I think the current specification is the one that works.

    ReplyDelete