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.

Monday, June 30, 2008

Public Comment Period Begins for HITSP Documents



The Healthcare Information Technology Standards Panel (HITSP) announces the opening of a public comment period for the following HITSP documents:



  • HITSP/RDSS56 – HITSP Remote Monitoring Use Case Requirements, Design and Standards Selection

  • HITSP/RDSS57 – HITSP Patient-Provider Secure Messaging Use Case Requirements, Design and Standards Selection

  • HITSP/RDSS58 – HITSP Personalized Health Care Use Case Requirements, Design and Standards Selection

  • HITSP/RDSS59 – HITSP Consultation and Transfers of Care Use Case Requirements, Design and Standards Selection

  • HITSP/RDSS60 – HITSP Immunizations and Response Management Use Case Requirements, Design and Standards Selection

  • HITSP/RDSS61 – HITSP Public Health Case Reporting Use Case Requirements, Design and Standards Selection

The public comment period will be open from Friday June 27th until Close of Business, Friday, July 25th. HITSP members and public stakeholders are encouraged to review these documents and provide comments through the HITSP comment tracking system. The documents and the HITSP comment tracking system are accessible through http://www.hitsp.org/ by clicking on the “Public Review and Comment” link on the right side of the screen.


All Panel and public comments received on these documents will be reviewed and dispositioned by the HITSP Technical Committees. Comments will be considered in the preparation of the Interoperability Specifications and associated constructs.


Friday, June 27, 2008

Clinical Decision Support

Some problems are so complex that you have to be highly intelligent and well informed just to be undecided about them. – Laurence J. Peter

Clinical decision support is of great interest right now in the United States. In September of 2007, the American Health Information Community released prototypes of six use cases, almost all of which call for clinical decision support in some way. Earlier this week, I spent about 45 minutes on the phone explaining the current state of clinical decision support standardization to a contractor working for ONC. It was an important call, even though unscheduled, and so I gave up about half the unscheduled time I had left in the day to the topic.

One reason for the interest in clinical decision support is that a number of activities can be streamlined through the use of these tools, improving care and reducing healthcare spending. These tools enable clinicians to access relevant information to provide safe and effective care. Having access to relevant information is critical. The volume of knowledge necessary to provide safe and effective care to patients is such that no human can know all that is necessary. This knowledge is growing at an extremely rapid pace. MEDLINE, a database of clinical research citations provided by the US National Library of Medicine adds hundreds of thousands of citations to its database annually.

Another reason for interest in clinical decision support is that these tools might enable automation of mandated reporting under various State and Federal regulations. A great deal of paper flows inside healthcare facilities in order to keep up with these reporting requirements. It takes a great deal of manual effort to keep this information flowing. Even when the reporting is done electronically, the information does not often originate from electronic sources, and must be manually gathered.

As the starting quote alludes to, clinical decision support is an incredibly complex problem. Before I dive into the details, I'd first like to describe what clinical decision support is. A common interpretation of clinical decision support is that it involves invoking an application (or interface or service), providing it with data, and having it invoke some action like alerting a provider or returning a treatment plan or suggestion for care (as in the case for drug interaction tools). This is just one of many different ways that clinical decision support is implemented.

Clinical decision support encompasses a variety of tools that assist healthcare providers in providing safe and effective care to patients. These tools take a variety of forms, including flowsheets, assessment instruments, drug interaction knowledge bases, vaccine forecasting tools, genetic risk assessment tools, chronic disease management solutions, population stratification tools, and quality measures.

  • Flowsheets are designed to make the most relevant information available to healthcare providers quickly and easily to enable clinical decision-making.
  • Assessment instruments support clinical decision-making by gathering certain information supplied by a provider or the patient, and using that information to compute results that can help providers implement appropriate care plans based on overall assessment scores.
  • Drug interaction databases are probably the most common example of clinical decision support tools. These databases keep track of interactions between a drug and other drugs, allergies or conditions, and report potential difficulties when providers are ordering medications.
  • Vaccine forecasting tools take information about a patients current allergies, conditions, medications, and vaccination history, and propose plans for immunizations that should be received and when.
  • Chronic disease management solutions collect data on patients enrolled in a chronic disease management program, either through remote monitoring; telephone interviews, or electronic submissions from portals or provider EHR systems. These solutions review the gathered information and suggest various actions to take to facilitate management of the disease, including the scheduling appointments, patient contacts, et cetera.
  • Genetic risk assessment tools gather information about a patient; including their medical history, family history, and genetic test results, and assess the patient's risk for genetically related diseases.
  • Other tools allow populations to be ranked for disease risk to identify groups that may need alternate levels of care.
  • Quality measures are clinical decision support tools that can be used to identify areas that need attention in a clinical practice.

All of these tools provide clinical decision support. Some are applied in the context of a single patient, while others apply to populations.


No sensible decision can be made any longer without taking into account not only the world as it is, but the world as it will be. – Isaac Asimov

As the body that is responsible for selecting standards for the AHIC use cases, HITSP needs to take into account:

  • existing standards,
  • current works in progress,
  • the impact of selected standards within and across use cases.

In March of this year, the HITSP Population Perspective TC and Care Management and Health Records TC hosted a Clinical Decision Support day at our face-to-face meeting. During that day, we heard from several experts in the area of clinical decision support, including developers of some of the clinical decision support standards described below. As a result of these discussions we learned a great deal about clinical decision support, including some of the information already provided in this blog.

At the end of the day, we synthesized a model describing clinical decision support that received a good deal of validation from the participants. An image of that model appears here.

In our model, we viewed Clinical Decision Support as a black box, through which we have three different kinds of inputs, and several different types of outputs. The inputs and outputs are of interest to HITSP because they represent areas where standards are needed to support interoperability. The three different inputs include:

  1. Algorithms, or knowledge about how to make inferences or assertions based on existing instance or world knowledge.
  2. Instance data describing the specific case that is being address by the clinical decision support application.
  3. Ontological or "world knowledge", representing facts about the world, such as what drugs interact badly, or how body parts are related, or the relationships between genes and diseases.

Standards exist for each of these three areas, but also a need for more work to make these standards implementable in the healthcare environment. The puzzle is still missing a few pieces.


Algorithms
Several standards exist to support clinical decision support algorithms that need to make yes/no answers. More work is needed in this area to integrate those standards into a set of coherent tools that can be used together.

Arden Syntax
Arden Syntax is perhaps the oldest and most well known standard used for clinical decision support. Arden Syntax originated in 1989 at the Arden Homestead. In 1992, version 1.0 became an ASTM standard. It transitioned to HL7 and version 2.0 became an ANSI and HL7 standard in 1999. The HL7 Clinical Decision Support workgroup is responsible for maintaining the standard. The current version of Arden Syntax is 2.7, which passed HL7 Ballot in May of this year.

Arden Syntax is designed for use by clinicians with little or no formal training in programming. The benefit of this design is that it makes it easy for clinicians to verify the clinical accuracy of a particular medical logic module that is written in that language. Hundreds of medical logic modules have been created for Arden Syntax and are available from the CPMC Medical Logic Module Library.

A key problem in Arden Syntax is known in clinical decision support standards circles as the "curly brace" problem. In short, Arden does not define how an implementation of the language integrates with the healthcare application using it. Arden Syntax leaves that integration to statements that appear within pairs of curly braces { and } inside a medical logic module.

GELLO

GELLO has its ancestry in other expression languages and tools for clinical decision support, including GLIF and GLEE. GELLO is an object-oriented language designed to:

  • Extract information from electronic health records,
  • Compute decision critieria,
  • and abstract or derive summary information.

GELLO is based on the Object Constraint Language developed originally by IBM and now part of the UML Standard. GELLO is not a proper subset of OCL, nor is it a pure extension as it explicitly leaves out some capabilities of OCL. However, developers familiar with OCL should find GELLO syntax readily accessible.
GELLO, like OCL is a declarative, rather than procedural language. The simplest way to explain a declarative language is by example. PROLOG and SQL are declarative languages. You describe the result you want to the SQL or PROLOG interpreter, and it decides the best way to obtain the result. The same is true in OCL and GELLO. Declarative programming requires a different way of thinking when expressing a decision problem. When you describe how to make a decision, most people express the decision making process procedurally.
The GELLO language is sufficiently different from OCL that it does require a grammar to be specified. HL7 had previously published a grammar for the GELLO language. However, that grammar has several defects that needed to be corrected. Some ambiguities in either the published grammar or the GELLO language specification have resulted in differing implementations of the language.
The HL7 Clinical Decision Support workgroup is presently working on a new release of the grammar intended to correct these deficiencies. In this context there are several discussions within that work group on whether GELLO should be defined as a subset of OCL, or should be defined in a way that would allow it to be mapped to OCL. One benefit of this approach might be an increase the availability of GELLO language implementation. There are several existing implementations of OCL in existence, including several supported by open source.
There is also an open source project that is developing GELLO tools (see http://www.gello.org/), however no applications or software are available for download as of today.
Like Arden Syntax, GELLO does not explicitly define how GELLO is integrated with an electronic health record. However, GELLO can easily be integrated with any HL7 RIM-based data model due to the object-oriented nature of the language. A simple data model is given as an example in Annex D of the HL7 GELLO language specification. GELLO is intended to be used with something called the vMR or Virtual Medical Record, which is described in more detail in the next section.
Instance Data
With regard to instance data, one of the problems that needs to be resolved is how to represent the information needed to support clinical decisions support applications, and how to exchange that information between applications needing to provide clinical decision support services.
Virtual Medical Record
In 2001, Johnson, Tu, Musen and Purves published a paper titled "A virtual medical record for guideline-based decision support" which can be found in the Proceedings of the AMIA Library . This often-referenced paper describes the concept of the Virtual Medical Record, or vMR that can be used to support guideline-based decision support. The concept of the virtual medical record is so often referenced in clinical decision support circles that I found it surprising that this wasn't defined by HL7 as a standard already. However, in January of this year, the HL7 Clinical Decision Support work group submitted a project to create an implementation guide for the virtual medical record, and expects to complete this work in the months ahead. This project will recommend a data model to use with the vMR, based on existing HL7 standards. One proposal for this model has already been made and recommended by several members of HL7 and co-chairs of various HL7 working groups. That recommendation is to use the HL7 Care Record and Care Record Query draft standards for trial use (A DSTU is essential a "prototype" standard, released for implementation testing).
The Patient Care Coordination Domain of Integrating the Healthcare Enterprise recently released an update to the Query for Existing Data (QED) profile, which makes use of the aforementioned standards, and a new profile know as the Care Management (CM) profile, using those same standards.
HL7 Continuity of Care Document
On of the recent things we've learned about the HL7 Continuity of Care Document or CCD is that templates can be extremely powerful. Having defined a few dozen templates in the CCD, we now find those same templates appearing in numerous other standards and implementation guides from HL7, IHE, Continua and CDA for Common Document Types projects. The benefit for clinical decision support to this proliferation of the CCD templates is that we are finding the same templates being reused over and over again to record the same kinds of information. That degree of consistency is absolutely necessary when you want to apply decision support to information that may be coming from different healthcare IT applications deployed all over the country.
The IHE Patient Care Coordination Technical framework uses the CCD templates as the basis for much of its material. Where the CCD has defined a particular template for use, IHE has either used it directly, or used and further constrained it in its technical framework. One profile that makes surprising use of CCD templates is the Query for Existing Data profile described next. The Care Management and Health Records TC in ANSI/HITSP is looking at a similar approach in the HITSP component specifications, as that committee is already responsible for four specifications that make use of the IHE PCC profiles to exchange content.
Query for Existing Data
The IHE Query for Existing Data integration profile explains how to use the HL7 Version 3.0 Care Record and Care Record Query DSTUs to query an EMR for clinical information. This profile also makes use of the Continuity of Care Document templates, but enforcing the rules of those templates on the clinical statements returned by the query transaction. The QED profile supports the ability for a clinical decision support system inside an enterprise to query for specific clinical data from that enterprises EHR system.
Care Management
The IHE Care Management (CM) integration profile uses the same standards as QED, but for a different purpose. In this integration profile, the HL7 Version 3.0 Care Record messages play an extremely important role. They allow systems that IHE describes as "Guideline Managers" to publish parts of a guideline. The part of the guideline that is published is the list of specific clinical data they downstream systems are interested in receiving. These descriptions are given in enough detail so that EHR applications can automatically determine what information updates need to be sent and when. These information updates can also be provided using existing HL7 Version 2 messages to support legacy applications.

HL7 Decision Support Service

The HL7 Service Oriented Architectures workgroup is presently working on implementations of the Decision Support Service Functional Model DSTU. One possible implementation for this service would utilize the HL7 Care Record DSTU previously mentioned several times to generate a vaccine forecast for a patient. The way this service would work would be to publish a Care Record Event which contained the necessary information to generate a vaccine forcast using the Care Record message. The response message from the DSS would be another Care Record Event that contained two pieces of information:

  1. A validated list of immunizations
  2. A care plan containing a proposed vaccination schedule for the patient.

This follows the general structure needed for many clinical decision support problems (e.g., drug interaction checking). The care plans produced by the service can describe different treatment alternatives, provide the reasons for the suggested treatments and the goals and risks asociated with each.
World Knowledge
Ontological or world knowledge often appears in terminology systems, such as SNOMED CT and RxNORM, which require frequent updates as new world knowledge is provided. Standards are needed to support the exchange and update this information on a routine rather than exceptional basis.
IHE ITI Sharing Value Sets
Enter the Sharing Values Sets (SVS) profile supplement published recently by IHE for public comment. This profile is intended to provide a mechanism to for applications needing value sets to obtain them repositories that maintain them. This will allow common value sets to be maintained in central locations. One use for value sets in clinical decision support is to identify specific sets of values that describe an aggregate concept that a clinical decision support system needs to act upon. An example would be the set of values that are used to identify reportable or notifiable conditions from a reference vocabulary such as SNOMED CT. In this example, a limited subset of SNOMED CT codes could be maintained as a value set to identify a set of conditions that require reports to be made to state or Federal public health officials. The benefit of this to interoperability is that these value sets can then be accessed by a large number of applications systems as needed.

Summary
There is a great deal of activity going on through various standards organizations in the area of clinical decision support. Not all of the pieces are ready today, but it is no accident than many of the pieces of the puzzle are starting to fit into place. Those of us who spend a great deal of time in healthcare standards are paying attention, and making sure that the relevant standards bodies do as well.
There is still a great deal of work that needs to be done in the area of Clinical Decision Support. Future discussions on this topic within AHIC and ONC should continue to include those of us who have been working on these standards.

Let's get coordinated!

-- Keith

P.S. In the interest of full disclosure, I've been intimately involved with many of the aforementioned standards activities in IHE and ANSI/HITSP to some degree also in HL7. I am the principle editor of the IHE Query for Existing Data and Care Management profiles, and have been involved in many of the dicussions on GELLO and the Virtual Medical Record within HL7, and co-chair the CMHR TC in ANSI/HITSP.


Friday, June 20, 2008

HIPAA Claims Attachments and other Ramblings

If you have interest in HIPAA Claims Attachments and CDA Release 2.0, I will be presenting on this topic on a live WEDI Audiocast next week. Clink the link if you want more information on this presentation. It's not free, but is reaonably priced, and I receive no renumeration for this presentation, the fees go towards funding WEDI activities, including educational activities like this one.

In other ramblings, I have been thinking about various topics that I want to discuss on this blog, and am looking for feedback. While I have a few blog posts in mind, I'd like to hear from you on what topics are of interest.

-- Keith

Thursday, June 19, 2008

The New Profiles are Here!

I'm posting the following announcement here for those of you who are interested. I'm pretty fond of this group, and I think they do good work. You can make it even better by reading and commenting on what they do.






New Technical Framework supplement documents and whitepapers have been published for public comment for the:

Patient Care Coordination (PCC) Domain
  • Antepartum Record (APR)
  • Care Management (CM)
  • Cancer Registry Pathology Report (CPR)
  • Immunization Content (IC)
  • Medical Home White Paper
  • Query for Existing Data (QED)
These supplements are available for download at http://static.ihe.net/Technical_Framework/index.cfm#pcc.
To be considered for incorporation in the Trial Implementation versions of these
supplements, comments must be submitted by July 18, 2008. Early submission will
be greatly appreciated.

Quality, Research and Public Health (QRPH) Domain:

  • Clinical Research Data Capture (CRD)
  • Performance Measure Data Element Structured for EHR Extraction Whitepaper
These supplements are available for download at http://static.ihe.net/Technical_Framework/index.cfm#quality.
To be considered for incorporation in the Trial Implementation versions of these
supplements, comments must be submitted by July 18, 2008. Early submission will
be greatly appreciated.

IT Infrastructure (ITI) Domain:

  • Asynchronous Web Services Exchange
  • Emergency Contact Information (ECON) White Paper
  • Pediatric Demographics Option
  • Referral Requests:
    • Media Referral Request (MRR),
    • Shared Documents Referral Request (SRR),
    • Referral Request Content (RRC)
  • Sharing Value Sets (SVS))
  • Cross Enterprise Sharing of Scanned Documents (XDS-SD)
  • Publish/Subscribe Infrastructure for XDS.b White Paper
These supplements are available for download at http://www.ihe.net/Technical_Framework/index.cfm#IT.
To be considered for incorporation in the Trial Implementation versions of these
supplements, comments must be submitted by July 9, 2008. Early submission will
be greatly appreciated.

Patient Care Devices (PCD) Domain:

  • Alarm Communication Management (ACM)
  • Rosetta Terminology Mapping (RTM)
  • Point-of-Care Infusion Verification (PIV)
These supplements are available for download at http://www.ihe.net/Technical_Framework/index.cfm#pcd.
To be considered for incorporation in the Trial Implementation versions of these
supplements, comments must be submitted by July 7, 2008. Early submission will
be greatly appreciated.



Wednesday, June 18, 2008

If I had a Hammer

“If the only tool you have is a hammer, you tend to see every problem as a nail.” — Abraham Maslow (1908-70), American psychologist

Recently, I ran across a question on the ANSI/HITSP C32 specification from an implementer. The C32 specification describes how the US Federal Government expects to use the HL7 Continuity of Care Document in our National Health Information Network.

The basic question we started with is how does one represent an operative report, a discharge summary, or a progress note in a C32 document.

I am still a bit confused with the 2 sections and what goes into each one, and the fact that we can't capture the document type (i.e., operative report vs. discharge summary vs. progress note).

The question expresses two parts of the problem:
  1. How do we make use of the CCD to create a uniform way to exchange information, and having done so,
  2. How do we classify documents as to the type of service they describe.
Fortunately, during the development of the CCD, the HL7 Structured Documents work group realized that the CCD templates for problems, medications, allergies, et cetera, could be reused in any other document built on the HL7 CDA standard. Realizing that, they created template identifiers that would allow these templates to be used in any kind of document.

Much work has been done on creating CDA documents using these CCD templates, in HL7, IHE and elsewhere. To date, there are implementations guides that have been developed by IHE and HL7 for:

Each of these implementation guides is using templates from the HL7 Continuity of Care Document, so that as we look inside each document, problems, medications, allergies and other clinical information have a uniform representation based on the CCD.

So the real question is not, "how to I put an operative note into a CCD", but rather,

How do we use the CCD specifications to record this information inside a _____(fill in the blank)?

The answer is to use the same templates created for the CCD, and in the ANSI/HITSP C32 specification in those other clinical documents.

The reason for doing this can be explained very simply. Imagine that you are a physician caring for a patient, and you want to find a particular document. It may be an operative note, a discharge summary, a consultation, et cetera. If all documents are CCD's, then you no longer have the capability to distinguish between them by the kind of service represented in the document. Can you imaging wading through all of these CCD's to find the right document? What you really want is for those documents to be classified by the kind of service performed by the provider. If it's a discharge summary, then it should say so.

Recently, the ANSI/HITSP Care Management and Health Records Technical Committee met in Washington DC, and discussed this topic. The solution proposed was to recognize that the C32 specifications applied not to just CCD documents, but to all HITSP created CDA based specifications. That committee will be reworking the HITSP specifications this year to better enable reuse of the C32 specifications across all clinical documents.

The HL7 Structured Documents work group will also be reviewing plans for development of the next release of the HL7 Continuity of Care Document later this year. The expectation is that we would propose changes based on feedback from implementers such as the NHIN implementation projects. When that work begins, I will be proposing a change to the very first conformance statement in the Continuity of Care Document. That statement is reproduced here:

CONF-1: The value for “ClinicalDocument / code” SHALL be “34133-9” “Summarization of episode note” 2.16.840.1.113883.6.1 LOINC STATIC.

My proposal will change this conformance statement to allow for the use of other LOINC codes when the purpose of the document is to contain a medical summary and documentation of other care. I've shown the proposed text below. Please note, this is only my proposal, there is no guarantee that this will become part of the next version of CCD, but it could help to address the confusion raised by the current specification.

CONF-1: A document conforming the these specifications may use any LOINC code in “ClinicalDocument / code” to describe its content. When the purpose of the document is solely to summarize the patient's current health status, the value for “ClinicalDocument / code” SHALL be “34133-9” “Summarization of episode note” 2.16.840.1.113883.6.1 LOINC STATIC.

We need use the right tool for the job, and while the CCD Document is a hammer, the CCD specification itself provides us with a whole box of tools -- CDA sections and entries. We can use these tools to build any number of clinical documents. Furthermore, having done so, we can expect that healthcare applications will be able to understand the content.


Tuesday, June 17, 2008

Motorcycle Guy

Usually at various events, I introduce myself as a Standards Geek for GE Healthcare. It gets a lot of laughs, puts the audience at ease, and it also describes very well what I do. However, I felt I couldn't use "StandardsGeek.blogspot.com" for this blog, becauge John Halamaka already has the Geek-o-sphere covered with GeekDoctor -- Life as a Healthcare CIO. Since I don't aspire to be a CIO, and I'm not a Doctor, I don't want to compete with John. So, I needed a different name for this blog.
About two years ago I attended a meeting sponsored by eHealthConnecticut and the Connecticut Health Information Security and Privacy Initiative (CT-HISPI) to explain several implementation guides developed by Integrating the Healthcare Enterprise that would be applicable to a health information exchange such as they were architecting. A friend of mine from Canada attended to explain some of the security profiles IHE had built -- on her 30th birthday. I rode my motorcycle down to Hartford to attend this meeting, and brought an extra helmet so I could give her a ride from the hotel to the meeting as a birthday present.
The presentation went very well, and I heard feedback from some folks who attended the architectural meetings the next day (that I couldn't attend due to scheduling). At that meeting, the leader of eHealth Connecticut described me to the group that hadn't been at the previous meeting.
You should have seen this guy. He showed up to the meeting in a motorcycle helmet and leathers. He gets up on stage and talks about how IHE is going to solve all of our problems. When he get's done, he throws a helmet to this chick, and rides off with her.
Later that year, I was talking to others (including the gentleman describing me) on a teleconference. The introduction that he gave me was simply this:

You remember Keith, he's that "Motorcycle Guy".
I've never had a better introduction than that, and so that's the introduction I'm giving all of you. The purpose of this blog is for me to expound upon standards, including many of those that I work on in HL7, ISO, ASTM, IHE or ANSI/HITSP.

Those of you who know me, know that I have a lot of opinions on these topics, and here is where I will express them. Please remember that all opinions that I express in this blog are my own, and not those of my employer, or any of the various standards organizations that I am involved with.

For those of you who are interested, here is a picture of my bike (and my friend from Canada)