Visualizing the Criteria in an HQMF Document

One of my take-aways at the recent Query Health Face to Face was to show how well or poorly the transformations I had developed would work against HQMF documents generated by the Model Authoring Tool (MAT).  I started my analysis and got stuck because I couldn't really see the logic flow of the criteria generated by MAT. I decided I would build a little visualization tool.  Previously, I had generated a visualization of IHE Profile and Actor relationships using GrafViz and and XSLT.  I figured that I could use the same techniques here.

This is an interesting side project because it could also be used to visualize relationship in other HL7 Version 3 and CDA Release 2.0 or Release 3.0 instances.

The first template matches the root of the HQMF document and creates a directed graph named "G".  Then it delves into the Population Criteria Section (section[code/@code='57026-7'] and describes the content of it.  I could use the same thing over other sections to delve into those by simply removing the predicate or changing it's contents to focus on a different section.


  <xsl:output method="text" indent="no"/>
  <xsl:template match="/">
    <xsl:text>digraph G {&#xA;</xsl:text>
    <xsl:apply-templates select="//hqmf:section[hqmf:code/@code='57026-7']"/>
    <xsl:text>}&#xA;</xsl:text>
  </xsl:template>

Since I'm just generating a grafviz input file, I set the output method to text at the top of the stylesheet.  The next template generates the root node representing the section:


  <xsl:template match="hqmf:section">
    <xsl:call-template name="getNodeName"/>
    <xsl:text> [ label="</xsl:text>
    <xsl:value-of select="hqmf:code/@displayName"/>
    <xsl:text>\n</xsl:text>
    <xsl:value-of select="hqmf:title"/>
    <xsl:text>" ];&#xA;</xsl:text>
    <xsl:apply-templates select="hqmf:entry"/>
  </xsl:template>

It calls upon a template to get the name of the section from it's content.  Then it assigns a label to the node based on the displayName in the code, and the title of the section.

The getNodeName template is reused in several places to generate an internal name for a node.  This was done because HQMF uses references to acts based on the <id> element, and I wanted only one node in the graph for each of the items referencing the same node.

  <xsl:template name="getNodeName">

    <xsl:choose>

      <xsl:when test="hqmf:id">

        <xsl:text>"</xsl:text>

        <xsl:value-of select="translate(hqmf:id/@root,'-','_')"/>

        <xsl:if test="hqmf:id/@extension">

          <xsl:text>:</xsl:text>

          <xsl:value-of select="hqmf:id/@extension"/>

        </xsl:if>

        <xsl:text>"</xsl:text>

      </xsl:when>

      <xsl:otherwise><xsl:value-of select="generate-id()"/></xsl:otherwise>

    </xsl:choose>

  </xsl:template>

So, if there is an <id> in a class, it is used as the internal name for it, otherwise, I just generate an identifier from it using the generate-id() XPath function.

Entries and their relationships to other acts are handled using the same template, since an entry is just another  act relationship from a section to some other act.


  <xsl:template match="hqmf:entry|hqmf:sourceOf">
    <xsl:variable name="act" 
      select="hqmf:act|hqmf:observation|hqmf:procedure|hqmf:encounter|
              hqmf:substanceAdministration|hqmf:supply"/>
    <xsl:variable name="target">
      <xsl:for-each select="$act">
        <xsl:call-template name="getNodeName"/>
      </xsl:for-each>
    </xsl:variable>
    <xsl:variable name="source">
      <xsl:for-each select="..">
        <xsl:call-template name="getNodeName"/>
      </xsl:for-each>
    </xsl:variable>
    <xsl:apply-templates select="$act"/>
    <xsl:text>  </xsl:text>
    <xsl:choose>
      <xsl:when test="@inversionInd='true'">
        <xsl:value-of select="$target"/>
        <xsl:text> -&gt; </xsl:text>
        <xsl:value-of select="$source"/>
      </xsl:when>
      <xsl:otherwise>
        <xsl:value-of select="$source"/>
        <xsl:text> -&gt; </xsl:text>
        <xsl:value-of select="$target"/>
      </xsl:otherwise>
    </xsl:choose>
    <xsl:text> [ label=</xsl:text>
      <xsl:text>"</xsl:text>
      <xsl:if test='hqmf:conjunctionCode'>
        <xsl:value-of select="hqmf:conjunctionCode/@code"/>
        <xsl:text> </xsl:text>

      </xsl:if>

      <xsl:value-of select="@typeCode"/> 
      <xsl:if test="hqmf:subsetCode">
        <xsl:text> (</xsl:text>
        <xsl:value-of select="hqmf:subsetCode/@code"/>
        <xsl:text>)</xsl:text>
      </xsl:if>
      <xsl:text>"</xsl:text>
    <xsl:text> ]&#xA;</xsl:text>
  </xsl:template>

This template finds the act that is the target of the relationship.  Then it gets the name of the target and source acts (the source is the parent of the relationship element).  Then it outputs the necessary definition for the child node by applying the template for acts (see the line in bold above).  Finally it generates either:

 source-act-name -> target-act-name
OR
 target-act-name -> source-act-name

depending on whether the @inversionInd attribute is true or not.  Then it generates a label describing the relationship.  A more evolved version of the stylesheet would generate more human readable labels, but this was sufficient for starters.

The next-to-last step was to process each act, and recurse over the act relationships.


  <xsl:template match="hqmf:act|hqmf:observation|hqmf:procedure|hqmf:encounter|
    hqmf:substanceAdministration|hqmf:supply">
    <xsl:text>  </xsl:text>
    <xsl:call-template name="getNodeName"/>
    <xsl:text> [ label="</xsl:text>
    <xsl:value-of select="local-name()"/>
    <xsl:if test="hqmf:code">
      <xsl:text>\n</xsl:text><xsl:value-of select="hqmf:code/@displayName"/>
    </xsl:if>
    <xsl:if test="hqmf:title">
      <xsl:text>\n</xsl:text>
      <xsl:value-of select="hqmf:title"/>
    </xsl:if>
    <xsl:text>", tooltip="</xsl:text>
    <xsl:apply-templates 
      select="hqmf:*[not(self::hqmf:sourceOf)]" mode='tooltip'/>
    <xsl:text>"]; &#xA;</xsl:text>  
    <xsl:apply-templates select="hqmf:sourceOf"/>  
  </xsl:template>

This step generates a node for the act, naming it from the element name and code and title (when present).  Then it applies the previously described template to any child relationships in the last line.

Finally, I needed to generate a description of the criteria.  For now, I just copied the XML inside the act into a tooltip using the line in bold above and a pair of other templates.  These templates are run in a different mode so they don't overlap with other processing.  All they do for now is copy the XML into a tooltip.  The first one processes elements and generates an appropriate opening tag.  It calls the second (see the line in bold) to generate the attributes.


<xsl:template match="*" mode="tooltip">
    <xsl:param name="indent" select="0"/>
    <xsl:variable name="newline">&amp;#xA;</xsl:variable>
    <xsl:value-of select="substring('          ',1,$indent)"/>
    <xsl:text>&lt;</xsl:text>
    <xsl:value-of select="local-name()"/>
    <xsl:apply-templates select="@*" mode="tooltip"/>
    <xsl:if test="count(*)=0 or normalize-space(text()) = ''">/</xsl:if>
    <xsl:text>&gt;</xsl:text>
    <xsl:value-of select="$newline"/>
    <xsl:if test="normalize-space(text())!=''">
      <xsl:value-of select="normalize-space(text())"/>
    </xsl:if>
    <xsl:if test="count(*)!=0">
      <xsl:apply-templates select="*" mode="tooltip">
        <xsl:with-param name="indent" select="$indent+1"/>
      </xsl:apply-templates>
      <xsl:value-of select="substring('          ',1,$indent)"/>
    </xsl:if>
    <xsl:if test="count(*)&gt;0 or normalize-space(text()) != ''">
      <xsl:text>&lt;/</xsl:text>
      <xsl:value-of select="local-name()"/>
      <xsl:text>&gt;</xsl:text>
      <xsl:value-of select="$newline"/>
    </xsl:if>
  </xsl:template>
  
  <xsl:template match="@*" mode="tooltip">
    <xsl:text> </xsl:text>
    <xsl:value-of select="local-name()"/>
    <xsl:text>='</xsl:text>
    <xsl:value-of select="."/>
    <xsl:text>'</xsl:text>
  </xsl:template>

Then I can run grafviz over the output to generate an SVG which I can display in my browser.  Unfortunately, I cannot upload the SVG to Blogger and I have to fix a few other things before I can upload it elsewhere, so here is a rather large scrollable PNG version.  So, now I can visualize the criteria, the next question I have is what to do about it.

For comparison, here is the same measure in the way that I implemented it (also as a PNG, but much smaller and about one quarter as complicated).

What I need to do now is figure out how much of the complexity in the first image is unnecessary.

NeHC Industry Leader Briefing Tomorrow at 12 PM EST

This just crossed my desk …

---

Industry Leader Briefing The Office of the National Coordinator for Health Information Technology (ONC) is a cooperative agreement partner of National eHealth Collaborative (NeHC). On Friday, December 2, 2011 at 12 p.m. EST, NeHC University will host Dr. David Baker, Professor and Chief of Internal Medicine at the Feinberg School of Medicine at Northwestern University for an Industry Leader Briefing on health information technology (HIT) and quality improvement. Dr. Baker will join NeHC to talk about how HIT and health information exchange can assist providers in improving quality and coordination of care. This program will discuss the use of HIT to improve quality and safety, using examples from Northwestern Memorial Hospital and the Northwestern Medical Faculty Foundation's General Internal Medicine Clinic.  We invite you to join this NeHC University Industry Leader Briefing. Register today! Check out the full Fall 2011 NeHC University semester schedule! Questions? Email NeHC University at university@nationalehealth.org.

Into the CDA Acronym Soup

Acronyms are a way of life for a Standards Geek.  These "short-form" names are an insider's code, almost as incomprehensible as 1337.  CDA, CCR, CCD, XDS-MS, C32, C48, C80, C83, XPHR, GreenCDA, CCDA (an Acronym first coined here by Wes Rishel), et cetera. For the average implementer, lack of knowledge about acronyms leads to miscommunication of requirements, subsequently resulting in incorrect implementation and later rework.  It gets even more challenging because many of these have several meanings.  The CCR is a data set and an XML Schema.  A CCR is an XML document that conforms to the XML Schema, but it can also be an implementation that conforms to the data set (e.g., The CCD is a CCR).


I spend a good deal of time with implementers who ask questions about CCD trying to be sure what they really mean, because I'm aware that most people in the US who are asking questions about "CCD" are really asking questions about the Meaningful Use requirements laid on top of the HITSP C32.  Sometimes the question really does get back to the HL7 CCD specification, but more often than not, it doesn't.


This post from mid-2010 shows 50 different specifications.  Each one has it's own acronym and has several different kinds of relationships with at least two or more others with only ONE exception (CDA).  I won't go into why we (geeks) use acronyms.  Tone Southerland (a standards geek colleague in IHE PCC) already explains that in this blog post.  What I'm going to try to address in this post is how an implementer is to cope.

So, here are the cliff notes.  If you are an implementer, you should study this, as there will be a test.

CDA - Clinical Document Architecture.  An HL7 standard describing the XML format of clinical documents.  It has also been approved by ANSI and ISO.  Currently in release 2.0, with work on release 3.0.

CCDA - CDA Consolidation Guide.  An HL7 Draft Standard for Trial Use consolidating the past work of HL7, Health Story, IHE, and HITSP into one consolidated guide.  The acronym was first coined by Wes Rishel.  Most participants call it the "Consolidation Guide".

CCR - Continuity of Care Record.  An ASTM standard data-set for information to exchange between systems supporting to support continuity of care.  It is published with an accompanying adjunct that is the XML Schema created by ASTM that conforms to that standard.  The format specified in the adjunct competes with the HL7 CDA.

CCD - Continuity of Care Document (Release 1.0).  An HL7 Informative document harmonizing the ASTM CCR and the HL7 CDA. A CCD is a CCR, but uses the HL7 CDA standard to represent the data.  It has now been superseded by the CCD 1.1 found in CCDA.

XDS-MS - Cross Enterprise Sharing of Medical Summaries.  An IHE profile (implementation guide) from the IHE Patient Care Coordination domain and is part of the PCC Technical Framework. It was originally based on the CRS 1.0, but was later changed to use the CCD.

CRS - Care Record Summary (Release 1.0).  An informative document from HL7 based on the CDA, and one of the intellectual ancestors of the CCD.  In competition with the CCR at the time of publication, but now superseded by release 2.0, and the CCDA.

XPHR - Exchange of Personal Health Records.  An IHE profile (implementation guide) from the IHE Patient Care Coordination Technical Framework.  It describes and further specifies how to use the CCD to exchnage information between PHR systems and EHR systems.

C32 - Summary Documents Using HL7 Continuity of Care Document.  A specification published by ANSI/HITSP that further codifies how to use the CCD for the US. Originally based directly on the HL7 CCD, it was later adapted to use the IHE XPHR profile.  However, confusion in interpretation of this specification by industry certifiers has led to conformance to the IHE PCC Technical Framework, but not necessarily XPHR directly.  The C32 makes use of the HITSP C80 and C83 specifications.

MU Stage 1 - Meaningful Use Stage 1.  A set of regulatory requirements for certification of EHR Systems that enable providers to obtain incentive payments from the federal government.  In addition to requiring support for both the CCR and CCD, it provides additional requirements over and above the HITSP C32 which result in yet further confusion about what a C32 is.

C48 - Encounter Document Using IHE Medical Summary.  A HITSP specification for encounter summaries based on the IHE XDS-MS.

C83 - CDA Content Modules Component.  A HITSP specification containing almost all CDA Section and Entry templates used in HITSP CDA based implementation guides.  The only real exception is the HITSP C37 Lab Report document based on the IHE XD-LAB profile.

C80 - Clinical Document and Message Terminology.  A HITSP specification containing vocabulary requirements for almost all HITSP specifications.  These are referenced by C83.

C37 - Lab Report Document.  A HITSP specification for lab reports using CDA, based on the IHE XD-LAB profile.

XD-LAB - Sharing Laboratory Reports. An IHE Profile from the IHE Laboratory Technical Framework for laboratory reports represented using CDA.

Loading I2B2 from CDA Documents

As part of my evaluation of models for I2B2, hQuery and CIM, I decided to map from CDA Release 2.0 using  the business rules applied in C83 and the CDA Consolidation guide to the I2B2 Star Schema.  The point of this exercise is to show how an I2B2 data repository would be populated from a collection of CDA documents, and as a result, build the mapping between the I2B2 model and C32 (which also leads to hQuery, since it's model is based on the C32).  While I've based this work on C32 and the CDA Consolidation project, the rules are general enough that they can be applied to a variety of different CDA documents, and they need not conform to the templates for those guides.  The I2B2 Data Repository design documentation (pdf) was essential to this work, and I wish I'd had it when I started on my SQL Proof of concept.  Oh well, I'll have to go back and rework that one later, and it's my fault for not catching up on the summer concert listening.

Here's a table showing my initial mappings.  The first column indicates the I2B2 fact or dimension table.  The second column indicates the field.  The third is an XPath expression giving either the context for the table (for table heading rows), or the data element (relative to the table context element) that appears within the table field.  XPath expressions using the cda: namespace identifier can be found in the CDA schema.  Those with the rim: namespace identifier represent extensions defined by HL7 SDWG on behalf of HITSP to represent the field.  The last column describes either the table or the field within the table based on the I2B2 documentation

To load a CDA document, one would iterate over each document, stopping at the table context points, and create a row of data using the field specifications.  Then each fact or dimension table would be loaded from the unique rows produced.  This an overly simplified description of the algorithm (table load order is important for referential integrity), and that are lot of other details I'll get into later.  First, let's look at the (somewhat simplified) mapping:

Table	Field	CDA	I2B2 Definition
Observation		cda:act| cda:observation| cda:substanceAdministration| cda:supply| cda:encounter| cda:procedure	In healthcare, a logical fact is an observation on a patient. It is important to note that an observation may not represent the onset or date of the condition or event being described, but instead is simply a recording or a notation of something. For example, the observation of ‘diabetes’ recorded in the database as a ‘fact’ at a particular time does not mean that the condition of diabetes began exactly at that time, only that a diagnosis was recorded at that time (there may be many diagnoses of diabetes for this patient over time)
	Encounter ID	ancestor-or-self::cda:*[@classCode='ENC'] [1]/cda:id	patient visit number
	Patient ID	//cda:patientRole/cda:id	patient number
	Concept Code	@classCode or cda:code	Code for observation of interest (i.e. diagnoses, procedures, medications, lab test)
	Provider ID	ancestor-or-self::cda:*[@typeCode='AUT' or @typeCode='PRF'][1]/cda:*/cda:id	Practitioner id or provider id
	Start/End Date Range	cda:effectiveTime	Starting and ending date-time of observation
	Modifier	(computed)	Code for modifier of interest (i.e. “ROUTE”, ”DOSE”), note that value columns are often used to hold the amounts such as “100” (mg) or “PO"
	Instance ID	cda:id	Encoded instance number that allows more that one modifier to be provided for each concept_cd. Each row will have a different modifier_cd but a similar instance_num.
	Value Type	cda:value/@xsi:type	Format of the concept N = Numeric T = Text (enums/short messages) B = Raw Text (notes/reports) NLP = NLP result text
	Value	cda:value
	Location Code	ancestor-or-self::cda:*[@typeCode='LOC']/cda:*[@classCode='SDLOC']/cda:id	A location code, such as for a clinic
Patient		//cda:patientRole	Each record in the patient_dimension table represents a patient in the database. The table includes demographics fields such as gender, age, race, etc. Most attributes of the patient dimension table are discrete (i.e. Male/Female, Zip code, etc.).
	Patient ID	cda:id
	Vital Status	(computed)	Contains a code that represents the vital status (alive or dead) of the patient and the precision of the vital status data.
	Birth Date	cda:patient/cda:birthTime
	Death Date	cda:patient/rim:deceasedTime
	Gender	cda:patient/   cda:administrativeGenderCode
	Age	(computed)
	Language	cda:patient/   cda:languageCommunication/    cda:languageCode
	Race	cda:patient/cda:raceCode
	Marital Status	cda:patient/   cda:maritalStatusCode
	Religion	cda:patient/   cda:religiousAffiliationCode
	Zip Code	cda:addr/cda:zip
	StateCityZipCode	cda:addr/(cda:state|cda:city|cda:zip)
Provider		//(cda:author|cda:performer)	Each record in the provider_dimension table represents a physician or provider at an institution. The provider_path is the path that describes how the provider fits into the institutional hierarchy. Institution, department, provider name and a code may be included in the path
	Provider ID	cda:id
	Provider Name	cda:name
Encounter		//cda:*[classCode='ENC']	The visit_dimension table represents sessions where observations were made. Each row represents one session (also called a visit, event or encounter.) This session can involve a patient directly, such as a visit to a doctor’s office, or it can involve the patient indirectly, as in when several tests are run on a tube of the patient’s blood. More than one observation can be made during a visit. All visits must have a start date/time associated with them, but they may or may not have an end date. The visit record also contains specifics about the location of the session, such as the hospital or clinic the session occurred, and whether the patient was an inpatient or outpatient at the time of the visit.
	Encounter ID	cda:id
	Patient ID	ancestor-or-self::cda:*[   typeCode='SBJ' or   typeCode='RCT' ]/cda:*/(cda:id|rim:id)[1]
	Active Status	cda:statusCode
	Start/End Date	cda:effectiveTime
	Encounter Type Code	cda:code
	Location Code	ancestor-or-self::cda:*[typeCode='LOC']/cda:*[classCode='SDLOC']/cda:id

Now for some comments on it...

Concept Codes
You'll need to look at both the "act" classCode attribute, and maybe the code element within the act, and map that to the I2B2 ontology to figure out how to populate the concept code.

Modifier Codes
In I2B2, a single fact can have multiple parts.  Each part of the fact is identified by the Instance identifier, and the part being represented (e.g., medication, Dose, route or frequency for a medication) can be separately represented.  In CDA, the "fact" is represented by one of the basic "act" classes, and the properties of that class represent each of the fields.  So, some acts will need to be represented as several facts (e.g., medications), while others (e.g., a lab result), will just be represented as a single fact.  This shouldn't be too hard to understand.

Value and Value Type
I2B2 has four different basic value types.  CDA has a few more that need to be mapped into the SQL tables.  Also, I2B2 has different columns in which each value type is placed.

Location Codes [sic]
In the I2B2 schema, location codes really identify specific locations, and so are identifiers, not codes.  Thus my mapping to cda:id for a specific location.  Locations are set in the document context for each observation, and apply unless overridden later in the document (a rare occurence).

Encounters
A CDA document is "documenation of" an "encompassing encounter".  Usually, what is recorded in the  document with respect to the encounter and its location applies to everything in the document (it's part of the context of the document).  That could be overridden subsequently in the document, indicating that the fact was a component of a different encounter that had a different location participant, but again, that is usually not the case.

Provider

Usually, the "author" of the document is also the performing provider, but again, that can be overridden with a performer participant in the encounter (there are several types of performers as well).

So, if you wanted to load a CCD document into an I2B2 data repository, this is enough to get you started.

My next task is to look at the NQF HQMF documents created by the Measure Authoring Tool, and see what I interpreted incorrectly, and see how well my transforms work against it, and comment on its structure.  While HQMF may be the right standard to represent queries, we will need implementation guidance given on how to represent queries in the Query Health environment.  The IHE Quality Measure Definition (ftp to Word document) profile might be one source for that guidance, and I've been drafted to help on that profile.  I'll  certainly be taking what I learn from this project into that one.

Query Health Face to Face

I'm spending today at the Query Health Technical Committee face to face meeting.  We spent the morning deciding on how to "build" the code that will be used to pilot the technologies.  I saw this slide for the first time this morning:

It means that the work I've been doing demonstrating implementation of HQMF for the last few weeks has been largely successful.  There are now four  major coding tasks.  One involves the PopMedNet policy framework, another involves the hQuery back-end, and the other the I2B2 back-end.  The fourth piece, which Sean Nolan labeled the "Keith Stream" of work (and which I heard as "Keith's Dream", which is a pretty good interpretation), is transformation of HQMF queries into hQuery or I2B2 implementations which can then be run against either back end.

The intention is that HQMF be the standardized, model based query specification, with an option for use of  I2B2 or hQuery when something really convoluted might be needed.   Both hQuery and I2B2 have query builder interfaces (whose output might be transformable to HQMF), and  NQF is working on some sort of HQMF Editor (called the Measure Authoring Tool) the  as well.  I may build some front-end transformations so that users familiar with the existing tools could generate an HQMF in those interfaces that could run against either back-end.

I also have some hope of designing (and maybe even building) an XQuery based implementation, but that would require more resources that I currently have at this point in time.

After lunch, we started talking about the plugin model.  It was then that I became very thankful that I no longer code up web user interfaces.

This afternoon, we will be discussing some details about information models and standards mapping to code components.  One of the most fun conversations we had on models this morning was how we needed to look at an I2B2 *-schema, the hQuery GreenC32 Javascript object model, and the S&I Framework CIM through hazy glass to see what silhouette emerges.  That's exactly what I was talking about in Models for Query Health.  Given the way that CDA, CCD, and C32 have permeated throughout healthcare IT in the US, I'm pretty sure what I'll see  (it's gotten to the point that I can map to C32 in my sleep or sniff out a C32-based data model blind-folded).

---

Updated to reflect correction on the Measure Authoring Tool.

Some notes on HL7 GreenCDA

If you read John Halamka's blog discussing the November HIT Standards Committee meeting, he spent a good deal of time talking about Green CDA.  Much of the discussion I'm seeing now has to do with the use of "Green CDA" on the wire.  The HL7 Structured Documents workgroup created a position statement back in February on that topic that encouraged experimentation.

The debate of Green CDA on the wire (both within HL7 and without) is something I've discussed previously.  


If you read the HL7 project description for Green CDA, you'll see where it talks about how it is two things:

1. A description of a process to produce an XML-based API for creating CDA documents
2. The output of executing that process (largely through manual efforts).

The process to date is a manual one, with the intention that there could be tools that support automation of it.  This is one of the goals of the ONC sponsorship of the MDHT project, or was at least when they started.  But right now, the only published "Green CDA" implementation is the one developed to demonstrate the process in the HL7 Implemenation Guide.  I don't know where MDHT is at with respect to creating a "Green CDA" specification, but I suspect it is still a release or two away.  

As a process, Green CDA is not well defined enough to enable automation.  There will be a lot of discovery about what needs to be done to automate.  As an implementation, the sample Green CDA implementation is OK for representing many HITSP C83 constructs, but isn't up to date with the CDA Consolidation guide.  I'd hate to see us put more manual effort into creating another manual implementation, because it would really not move the industry forward.

Green CDA takes what HL7 learned from the CCR wars to heart, making the implementation of CDA easier for developers.  But these days, I don't think it goes far enough.  I have my own idea about what will make it easier for developers.  I think we could even combine the "greening" of the models with the development of an HTML5-based CDA implementation that would be even easier for developers to understand and create.

I think the HIT SC either went too far, or not far enough.  If we really are going to spend the next 9-12 months designing a format for the next generation of Health IT solutions that could be deployed under Meaningful Use Stage 3, why not take a significant leap forward, instead of remaining with what we have learned thus far.  After all, if you are going to introduce "breaking incompatibilities" with current Health IT solutions, why not get something really worthwhile out of it.

I can think of nothing more interesting to work on (even Query Health is a distant second).

     Keith

P.S.  My own guess about the ONC response to the HIT SC Green CDA recommendation, which you can take with a grain of salt, is that the MU Stage 2 rule will NOT recommend Green CDA, but that it WILL reference the CDA Consolidation work.   Let's come back to this in 3 months and see if I was right.

P.P.S.  Now that CDA Consolidation guide is out in draft form, my next big project is a gap analysis between it, and the HITSP C32/C83/C80 set of documents.

Will Healthcare ever grow up?

My daughters are both growing up.  Yesterday morning, my eldest attended a high school football game as a guest member of the marching band.  They asked the Middle school flag teams to march with the band for Thanksgiving day. As she grows up, she is learning more and more about how to care for herself (and others).  Afterwards, she was cooking a dish for the thanksgiving meal we are about to share with friends.

She knows that she needs to see a doctor regularly, she knows how to ask for her records, and how to read them to some degree.  Here time horizon is also expanding.  We played Monopoly last night, and as she kept running short on funds, she kept thinking about the kinds of financial decisions she'd be making on her own in college ... hmm, pizza now, or groceries for the week?  In short, she's beginning to learn what she needs to support herself as an adult.

Over the last hundred years, healthcare has advanced from something that only the rich could really afford, to something that was considered to be an essential component of every person's basic needs.  Over that same time, the costs of healthcare have grown, seemingly without bound, and it is now regressing back to something that only the rich and/or well-employed (and healthy) can really afford.

I find myself wondering what kind of healthcare system my daughters will have to teach their children about.  Will it be something that they, as digital natives, find familiar and reassuring and part of their usual lives, or will it be even more frustrating, expensive and cumbersome than it is today?  I'm hoping for the former, but it is so hard to predict where we will be in twenty years.

Our political leaders often cannot seem to think beyond the next election, our financial sector cannot even seem to think beyond the next quarter or maybe as far as the next year, and our healthcare system within the 18-month average horizon that an insurer needs to care about a patient, or the deadline for the next regulatory hurdle affecting payment?

These are the time frames in which children think, next month, next Christmas, next birthday, next school year, when I get to the next school, et cetera.  As a parent, I had to start thinking about college for my kids when they were born.  That is the kind of time frame that adults have to think in.  What will healthcare leaders be thinking like when my daughter is an adult?  Like her, or like her children?

I'll keep pushing because our healthcare system needs adults right now to keep pushing.  And if we keep it up, eventually it might just grow up, just like children do.  I'm optimistic, but still not certain.