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

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.

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:

• Discharge and Transfer Summaries
• Consult Notes
• History and Physical Notes
• Operative Reports
• Antepartum Summaries
• Remote Monitoring
• Personal Health Exchange
• Emergency Department Encounters

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.

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)