Sunday, February 13, 2011

PCAST - Documents vs Atoms

In December, the President's Council of Advisors on Science and Technology (PCAST) released a report on HIT. We've been referring to this as "the PCAST Report"

Wes Rishel recently blogged on one of the more contentious issues contained in the report.

Basically, the report calls for a move away from the "record-centric notion that data elements should 'live' inside documents."

Now, I am all for "re-using" information. I expect that we will extract information from these documents and will repurpose that data in ways that none of us can fully understand, today. Indeed, we will extract a Patient's Medication History, Problem List and Allergies from a clinical document and import that into a recieving EHR system to feed into its Clinical Decision Support logic. However, I do see the danger of "taking things out of context" (pun intended).

If we extract "atomic" data from clinical documents and feed this data into other systems and processes, we may end up with GIGO (Garbage In, Garbage Out). The likelihood that the downstream systems may not fully understand the meaning of the "atomic" data and will mis-use it is great.

I cannot explain this any better than Wes does. Please read his analysis.

Saturday, February 12, 2011

ONC CDA IG Consolidation Project Publishing

I volunteered to work on what is now called the Documentation workgroup of this project. Keith Boone of GE Healthcare and I are leading the workgroup.

Basically, what we are doing is deciding what content should go into the Implementation Guides (IGs), and the contractors that the ONC has working on the project will make it happen. I may end up writing some content.

The content needs to be finalized and sent to HL7 for the ballot by March 30.

The issues so far include:

Format for the Conformance Statements. Today, they read like one of those 1970s user manuals that has been translated from Japanese to English by either a machine, or by someone that does not really understand English or the application. Here is an example.

[IHE] SHALL contain [1..1] statusCode, which SHALL be selected from ValueSet ConcernEntryStatus STATIC

OK. This says that this conformance requirement comes from IHE. The section is required to contain a single statusCode which must be from the ConcernEntryStatus value set, which is a static value set.

We'll have a computable version of the conformance statements, so there is little reason for the statement in the IG to read so formally. We'd like the statements to still be precise, but not as clunky. We're going to come up with some examples of what we think the verbage should look like and then present the top 3 or 4 to the larger group. If we get fifty or more people arguing over where a comma should be, it will not be productive.

Format for the graphical representation of the model fragments. We think that each section and entry should have a graphical representation (some people understand pictures better than words). If we use standard UML, our wider audience will understand it, but the HL7 folks will expect the HL7 version of the UML diagram to be present in an HL7 publication. If we use UML only, we will get negative votes from HL7 members who expect the HL7 style graphics to be used in an HL7 publication. If we include both, the document will be much bigger, but that may be our best option. I think that we will make a decision and report that back to the full work group.

A format for the "table view" of the Header, Section and Entries need to be decided on. The HL7 Heirarchical Message Description (HMD) or the HITSP style tables are under consideration. We could possibly come up with a hybrid of the two. I think that we will make a decision on this and then report back to the full work group in the next couple of weeks.

This IG will be viewed and voted on by many people who are not normally voting on HL7 standards. We will need to explain a lot of this to them. Some years ago, when the EHR Functional Model was ballotted, the EHR Work Group faced a similar issue. They put together a separate document that explained the process to newbies. I will find a copy of that and use it as the basis for a document that we will include in the ballot package.

The Header and each section and entry will have a fully populated XML example. The trick will be to have a meaningful example that doesn't obscure the important stuff. We should probably use the HL7 Cast of Characters from the Publishing Facilitator's Guide for our examples.

There will also be a complete example of each document type containing annotations indicating the conformance statement that the data satisfies.

The Documentation Workgroup meets on Wednesdays at noon eastern!

Every Wednesday from 12-1pm EST | Dial-in: 1-888-998-2663 | Pass-code: 9065865
Sign-up for this workgroup by e-mailing