Sometimes Doing Nothing is the Hardest Thing to Do for Patient Too

This was a great post by Dr. Westby Fisher.  Read it first.

When I catch a cold, I routinely treat the symptoms, rest, and as to doctors, do nothing.  For my kids, I do the same, with watchful waiting to see if it gets worse.  If it does, then I make the call.  I don't need to see a doctor to have them tell me, yep, it's a cold.

As a patient, I'm happy to hear that time will likely cure my problem.  Not to long ago I was diagnosed with Cervicular Radiculopathy.  I used the diagnosis as an experiment in being an engaged patient.  At that time, my symptoms were consistent with C5 compression.  The treatment was a course of oral steroids and a month of PT, with a few backup plans.  After the PT it went away.

It's back, and now I have symptoms of both C4 and C5 compression (more fingers are tingly).  I learned quite a bit from PT and am following the course of exercises that my therapist suggested, as well as going back to sleeping on my back.  There is no pain this time, just a bit of tingling at the beginning and/or end of the day.  What should I do?  Do I call my doctor and make another appointment, or do I deal with this the way I think he would tell me to anyway?  Do I need the steroids again, or are OTC anti-inflammatory drugs sufficient.  I'll learn the answers to these questions when I seem in a few weeks for a follow-up from something else.  But it is hard not to be worried.  If I call, they'll probably want to make another appointment for me sooner, and that just isn't convenient, nor do I think that there is much other than watchful waiting that will happen as a result.  So, I'll wait and watch.  If things get worse, I'll make a call.

My wife has a bum knee (Arthritis).  We paid over $3000 dollars for that diagnosis via MRI, which was what the doctor already told her it likely was to begin with.  Next time I know the right questions to ask about diagnostic testing.  What could this test tell you that you don't already know, and how could it change the treatment, and how likely is it that it is worth the expense?  She's also in PT.  After a month of PT we got our bill.  She discovered we were paying $45 dollars a visit (X four weeks) for Ice pack treatment in addition to the other therapy.  She stopped those and now puts an ice pack on at home after the PT visit.

My doctor told me that my EKG in the office showed a possibly enlarged left ventricle.  I'm already under observation because I'm mildly hypertensive.  He wants an ultrasound.  I'll ask him the same questions I should have asked about the MRI when I see him again.  My wife had a similar experience and even though the ultrasound results came back, no change in treatment occurred.  Is it worth the money?

I too am learning to do nothing.  I wish it were easier, and that I understood what the ramifications were.  I really cannot wait until my doctor gets his patient portal.  Then I'll be able to send him some of these easy to answer questions, and not have to worry so much while I do nothing.

   -- Keith

P.S.  As I think about the business case for doing nothing, it should be easier for doctors to do nothing.  By making more patients happier in less time, they should be able to treat more patients.  I guess it goes back to the adage that an empty bed gets filled as does a void in ones schedule.  Ideally, that would also mean that the patient one is treating are those that are more serious and need more treatment, and therefore generate more revenue.

IHE Call for Nominations in PCC, PCD, ITI & QRPH Domains Open

Greetings IHE members,

IHE International is pleased to announce a Call for Co-Chair Nominations for the IHE ITI, PCC, PCD and QRPH Domains. There are also three IHE Domain Representatives to the IHE International Board are open for nomination including the PCD, PCC and ITI Domains.

The Call for Nominations opens today, Wednesday, August 3. Co-Chairs serve in two year terms and can serve a maximum of two consecutive terms. Elected individuals will serve in their role from September 1, 2011 through August 31, 2013. Please review the open positions and submit your nominations by sending an email to both ihe@himss.org and croth@himss.org. Nominations will be accepted until 11:59 p.m. CST on Wednesday, August 17, 2011.

Interested in Running for Co-Chair or Representative on the International Board?

Nominees must be current voting members at the time of the announcement. Self-nominations are accepted and welcome. Please check your Domain Roster status to ensure your eligibility for election by using the links at the bottom of this email. Interested candidates can read the list of qualifications and responsibilities attached to this email.

Note: The qualifications, responsibilities, and election process for Domain Co-Chairs and the IHE Domain Representative are unique, please read the attached documents carefully. Contact secretary@ihe.net if you have any additional questions.

The following Co-Chair Positions & Domain Representatives are now Open for Nominations:

IT Infrastructure (ITI) Domain:

·        Planning Committee – User Co-Chair Open: Mike Nusbaum (MH Nusbaum & Associates Ltd.) is completing his second term and is ineligible for re-election. This position is open for nominations.

·        Technical Committee – Vendor Co-Chair Open: Rob Horn (Agfa) is completing his first term and is eligible for a second term. He has indicated his intention to run for a second term. Nominations will also be accepted.

·        ITI Domain Representative to IHE International Board: Charles Parisot is completing his first term and is eligible for a second term. Nominations will also be accepted.

Patient Care Coordination (PCC) Domain:

·        Planning Committee – Vendor Co-Chair Open: Keith Boone (GE) is completing his first term. He is eligible for a second term and has indicated his intention to run for a second term. Nominations will also be accepted.

·        Technical Committee – User Co-Chair Open: Laura Heermann Langford (Intermountain Health) is completing her first term and is eligible for a second term. She has indicated her interest to run for a second term.. Nominations will also be accepted.

·        Nursing Sub-Committee User and Vendor Co-Chairs Open: The PCC Nursing Subcommittee has one Technical and one User Co-Chair. Marcia Veenstra is completing her second term. Audrey Dickerson has moved to another organization, leaving openings for two new Nursing Subcommittee Co-Chairs. These two positions are open for nominations.

·        PCC Domain Representative to IHE International Board: John Donnelly is completing his first term, is eligible for a second term. Nominations will also be accepted.

Patient Care Devices (PCD) Domain: Joint Planning & Technical Committee:

·        Technical Committee – Vendor Co-Chair Open: John Roads (Phillips) is completing his first term. He is eligible for a second term and has indicated his intention to run for a second term. Nominations will also be accepted.

·        Planning Committee – User Co-Chair Open: Steve Merritt (Baystate Health) is completing his first term. He is eligible for a second term and has indicated his intention to run for a second term. Nominations will also be accepted.

·        PCD Domain Representative to IHE International Board: Todd Cooper is completing his first term and is eligible for a 2^nd term. Nominations will also be accepted.

Quality Research & Public Health (QRPH) Domain – Joint Planning & Technical Committee:

·        Planning Committee – Technical Co-Chair: Didi Davis (Serendipity Health) is completing her first term. She has indicated her intention to run for a second term. Additionally, we will be adding one Planning Co-Chair position. Nominations will be accepted for both positions.

·        Technical Committee – User Co-Chair: Amit Popit (Epic) is completing his first term. He has indicated his intention to run for a second term. Additionally, we will be adding one Technical Co-Chair position. Nominations will be accepted for both positions.

We sincerely thank all of our Co-Chairs & Domain Representatives for their excellent leadership, service and commitment to IHE. They play an instrumental role to the success and advancement of IHE’s work.

2011 - 2013 Nomination and Election Schedule Overview:

1.      Call for Nominations: Wednesday, August 3 – Wednesday, August 17, 2011 at 11:59 p.m. CST

2.      Elections: Election ballots will be provided via online survey and will be accepted Friday, August 19 – Friday, September 2, 2011 at 11:59 p.m. CST. (Actual timeframe my vary slightly)

3.      Election Results: Election results will be announced the week of Monday, September 5, 2011. 

Co-Chair Nomination Guidelines: 

Nominees must be current voting members of the committee for which they are nominated at the time of the announcement. Self-nominations are accepted and are welcome.

·        If you have any questions about the status of an individual you wish to nominate, please check the current domain rosters by viewing the IHE Rosters on the FTP site or from the IHE Wiki. Access the Rosters here: ITI Rosters | PCC Rosters | PCD Rosters | QRPH Rosters

·        If you have questions about the IHE Rosters or need to report any errors, please send an email to secretary@himss.org. Be sure to include the date of the event or vote in question and documentation of your attendance and/or vote.

IHE International Co-Chair & Domain Representative Requirements and Responsibilities- Please see attached document.

How to Submit your Co-Chair Nomination: 

Please send an email to secretary@himss.org. Nominations will be accepted through 11:59 p.m. CST on Wednesday, August 17, 2011. Self-nominations are welcome.

NOTE: We request that all potential candidates send a current biography to be distributed with the official election ballot.

Questions? Please contact secretary@himss.org.

Thank you on behalf of IHE International. 

C32 questions now being routed through Australia

Grahame Grieve has an "Ask me a question button" on his blog. He routed this one my way:

1.What is difference between various documents published by IHE and
HITSP. they looks similar
For example HITSP C28 vs IHE(Emergency Department Encounter Summary)
2. IHE profiles provide the sections of a clinical documents, but how
do i know what are the data elements a section may have and the XML
representation of the data elements.
EG.for Review of Systems what are the data elements we may have inside
the ENTRY tag.
3. if i create a database using all data elements from HITSP C-83,
would that be good enough to store all data elements i may receive in
all kind of CDA(C28,C48, XDS-MS, healtstory etc) documents.

The HITSP specifications are based up, and refer to the content of the IHE specifications.  For example, HITSP C28 makes use of the IHE EDES profile and requires a conforming instance to also comply with the IHE requirements.

With regard to the data elements that a section may have, HITSP and IHE both have required entries which are described within their respective sections.  Any entry required by IHE is also required by HITSP, and HITSP has additional vocabulary requirements, so you can locate the necessary entries within the HITSP C83 document.  Other entries are permitted by both IHE and HITSP.  They simply aren't specified.  This stems from the idea that these are open templates that others could further constrain by adding new requirements for a more specific use case.

With regard to using the data elements from the HITSP C83, that would be good enough to understand all HITSP specified data elements that you might receive, but it is NOT an exhaustive list due to the openness described above.  That being said, if it can be done using a HITSP template, C83 does say you have to use the HITSP specification for it.

Now, to add that "Ask me a question button" to this blog.

On Comments disparaging of ISO 21090 Healthcare Datatypes

Recently, someone shared with me some rather disparaging comments made about ISO 21090 Healthcare Data Types, otherwise known as HL7 Data Types Release 2.0.  In those comments several assertions were made:

1. TC-215 is trying to create something completely new (or acquiring something completely new created by HL7), rather than standardizing something that has had substantial implementation and development.
2. Competencies in modeling and software development are under-represented in ISO TC-215.
3. People have voted in blocs without reading the materials, without showing that they have the competency to understand them.
4. The existing work violates principals of Object-Oriented Design.
5. The notion of profiles of standards does not exist anywhere else in informatics.  
6. The process did not show that the standard was implementable, implemented, or fit for the purpose by which it was created.
7. Claims that certain organizations (that the commenter is not affiliated with) do not support the standard because they are using something else.

These assertions are largely unsupported by facts, evidence or any other references to support the claims.  I would like to present my counter-claims:

#1: IS0 21090 is a submission of HL7 Data Types Release 2.0.  That work is based upon HL7 Data Types Release 1.0, which is one of the foundation components of HL7 Version 3, and thus CDA, Care Record, and Patient Administration standards or DSTUs.  Substantial implementation and development has been done using these standards worldwide.  As evidence¹, I demonstrate the XDS map, which also shows where CDA is in use, and where PIX/PDQ V3 (based on the HL7 Version 3 Patient Administration standards) are used, and the IHE product registry, which shows more than two dozen products implementing V3, and a greater number implementing CDA.

#2: While I cannot speak for the whole of ISO TC-215, I am quite familiar with many of the members of ISO TC-215 from Germany, Canada, the US, Japan, Australia and a few other countries. I don't find modeling and development experience under-represented in TC-215.  But don't trust my opinion, try this Linked-in search and see what you think (your results may vary depending upon your use of Linked-in).

#3: With regard to blocs, having read the material, and competency: I have seen quite a bit of discussion on HL7 lists showing evidence that ISO TC-215 representatives from several countries have both read the material, understand it, and have offered significant suggestions for improvement.  These are competent individuals that have demonstrated their abilities numerous times.  That traffic also represents a pool of quite experienced modelers and developers, further addressing point #2.  The Ad Hominem attack on the competency of these individuals is unwarranted.

#4: This is the one claim that I cannot refute. Disproving a general negative is nearly impossible.  I'd like to see what principles of OO design were violated, but no such information has been provided in the comments.  Until such information is provided, this is merely an unsupported opinion.

#5: The principle of profiling is the foundation of two organizations quite well involved in Healthcare informatics:  IHE and Continua (click the links to see the connection of the organization to the concept "profile").  There are also General IT standards organizations that Profile standards (e.g., see OASIS profiles of web services).

#6: See #1.  The data types are in large part identical to HL7 Data Types release 1, which have been implemented worldwide, and were deemed suitable for purpose by nations, regions, and healthcare provider organizations of all sizes.

#7: With regard to claims that organizations are using something other than ISO 21090 for other purposes, the commenter is correct.  But, they also happen to be using the forerunner of the 21090 data types in existing work, and will be using the 21090 data types when they become available in the HL7 V3 Normative editions of certain standards and drafts already in use (e.g., in IHE Profiles).  If you care to see the opinions of those organizations on ISO Datatypes, you can view the publicly available HL7/ISO Joint ballot results in September and in May of 2008.  I voted affirmatively, as did almost all others.  Cross check the voters in this pool with the comments posted on HL7 lists (see #3 above) and you will find that they voted on this material after both reading and understanding it.

   -- Keith

¹ I find it interesting that I have to use IHE resources to show HL7 implementation. I wish the HL7 product registry project would get off the ground.

Ruminations on the Source of Inspiration

Every now and then I write an introspective post.  There's nothing new I have to report today.  I still have some investigations to continue on the HTML5 front, and some IHE work to complete on the Reconciliation profile before the end of the week.  And ....  You get the idea.

I've be wondering where ideas come from, especially big ones.  After all, if the big ones are the really important ones, I'd like to be able to repeat the process a bit more consciously.  After all, repeat-ability and process are important sources of improvement, right?

I've determined over the years that there is no single trigger for a brainstorm.  It may often is a single thing that unleashes it, much like a dust particle starts a rainstorm.  And it may be something else small that starts it, like the fluttering wings of a butterfly that causes a divergence from one path to another through a chaotic swirl of possibilities.  But through that path, there are a whole lot of other associated connections to the inspiration.

I try to understand my sources of inspiration.  A casual evaluation of the various sources of my posts on HTML 5 led me down some interesting paths.  Some of them were pretty well-worn, such as a mapping from CDA to HTML, which has a long history of being essential to the existing CDA standard.  Other parts of it come from getting to work with really intelligent and diverse people, such as at the recent Health Foo event.  My introduction to the term micro-format as a term comes from discussions around healthcare provider directories held by the FACAs over the past few months, a rather tangentially related idea.  I've used micro-formats plenty of times in my own development of web applications.  It is also a common approach in the development of well structured technical documentation, a field I spent many years working in (even before there was XML).  There's even some notion of microdata (although neither that term, or the term microformat is even used) in the PCAST report.

My wife has a favorite phrase:  "You had to be where you were to get where you are." (Or as Buckaroo Banzai put it:  "No matter where you go, there you are.")  In my case, this is so true.  I have often wished to have been involved in this, my career and passion from the start without all of the side-steps and diversions.  But if that were possible, I wouldn't have the diverse skills, knowledge or insight to pull some of these pieces together.

So, what have I learned about big ideas?  Explore.  Do unconnected things and try to link them together.  Do it a lot. Not everything will work out, but sometimes, accidents do happen.  And the important thing about them is to be where they are, when they happen, so that you can use your experience to see the value of them.  There is no magic formula for inspiration, just a pretty simple one.  The cool thing about it, is that if I follow it, it is also pretty fun.

I want my Summer Back

In Healthcare Standards development, there is a natural ebb and flow between development and implementation.  IHE has this embedded in their annual 18 month cycle.  HITSP did to in its annual cycle.  HL7 doesn't have it embedded quite so much, but since they ballot three times annually, there's still a cycle of intense development followed by a cycle of intense review, and then it repeats.

Sean Nolan comments now on an issue I raised 9 months ago.  It's really about sustainability of initiatives, and the bandwidth of the HIT community.  Summer was one of the periods I had to think about new initiatives.  Not any more with the ONC Summer Camps and Concerts and new initiatives.  Sean's post was topic 1 of last nights #HITsm chat (see the transcript).

I've gotten used to the constant pressure on SDOs.  What I haven't yet gotten used to is having the standards efforts of our industry being so forcibly driven by one agency in US Federal government (ONC).  The challenge for me is one of governance.  In each of the SDOs that I participate, we make plans, address dependencies, and identify gaps that need to be filled before some projects will come to the fore.  Those plans, dependencies and gaps used to be identified by the stakeholders involved in the work of those SDOs, but are now externally forced, and the plans mostly inaccessible to those performing the work.  This has the same chilling effect on innovation in Health IT from within those organizations as the pre-HITECH mechanisms for certification of EHRs had on product innovation.  The challenge that the external pressure brings is how to fit it into existing stakeholder demands on the SDOs.  One could argue that ONC is presenting the right demands, and I won't argue that.  My point is that they aren't presenting those demands to the SDOs, but are rather setting up a competing mechanism to do what the SDOs already exist to support.

In the case of the S and I Framework, and in the preceding activities of HITSP, instead of the planning being done by the volunteers doing the work, the planning and requirements for use cases was largely directed by Federal agencies and their advisory committees.  Yet, most of them aren't subsequently present and available to discuss their requirements when the work commences.  This has gotten a little bit better in the S and I Framework programs, in that there are representatives (even if not the instigators) available to discuss requirements (something learned well from the Direct Project). But even today, the SDOs are not yet engaged as participants in the planning process.  In fact, the plans and schedules for future S and I projects are not known outside a very small circle of people.

What I'd really like to see is ONC open up the discussions of what they feel they need, and engage with the various SDOs to encourage innovative thinking, development and planning for the future.  Rather than driving from without, they could have a much better effect driving from within.  By acting with, and as part of the SDO, they participate in the planning, encourage innovative thinking, but can also develop a better understanding of the current environment, and what might be possible today that they aren't even aware of.

IHE recently opened up its annual request for proposals for three domains:  IT Infrastructure, Patient Care Coordination, and Quality, Research and Public Health.  I would encourage ONC to take advantage of this process and submit a proposal or three.  Then come to a meetings and webinars and listen to the discussions around the proposals that we receive, and see how we can help, and visa versa.  I would also suggest that they look into what is happening at HL7 and present a project or two for consideration.

Rethinking HL7 CDA Release 3.0

This blog post is for discussion at a future Structured Documents call on CDA Release 3.  It represents a departure from current thinking about CDA Release 3.0.  It's a continuation of my previous buzzword compliant post on the topic.

The point of departure starts from the idea of using a profile of XHTML as the content for the CDA Narrative block, and instead, replaces that with the idea of using HTML5 as the CDA Narrative representation, using the microdata draft standard (already supported to some degree in several current web browsers) to represent the machine readable data.

I will make an assertion, the proof of which appears below, which is that RIM models can be fully expressed in HTML5 Microdata.  HTML5 Microdata is just an implementation of property bags in HTML5, and property bags can be mapped onto any data model.  Trust me on this, at least for the rest of this article.  The proof, as a former colleague used to tell me, is just a matter of writing the code.

I would like to explore the benefits, and the restructuring of the CDA framework that I’m proposing in this post.

A Framework for Structured Healthcare Documentation
CDA is about Clinical Document Architecture.  This proposal uses HTML5 as a foundation for a Structured Document Architecture, and develops from that a foundation for a Clinical Document Architecture using an information model.  This foundation is based on a mapping of the CDA narrative content model to the HTML5 content model.

0. The basic Level 0 structured document is simply a profile of HTML5.  It specifies a minimum set of tags that must be supported by an implementation, and the behavior of that implementation in the presence of tags that are not understood (just as HTML5 does).  Level 0 is a new level in the set of levels understood for CDA users.  It means that you just have the narrative content, and do NOT have any metadata.
1. Level 1 structured documents introduce a set of metadata established first in the HL7 Structured Document Architecture (SDA) specification, with some appropriate modifications.  Level 1 structured documents describe the metadata functional requirements needed to support document metadata.  A conforming “level 1” instance of a structured document functionally supports the required metadata of the SDA, but DOES not include any specific representation of that metadata.
1. All documents have an overall subject, identity, and publication time, and may have one or more authors or authoring organizations.  The subject of the document may be a person, place, thing, time, location, theme or author.  The subject is what the document is about.  The typical clinical document is about a patient.  The typical package insert is about a drug.  The typical guideline is about how to treat a particular disease.   From the HL7 Structured Documents workgroup perspective, this shouldn’t matter.  It is a document; domain committees can address functionally what the requirements of the subject are.
2. Documents themselves are either singular or composite.  A singular document has no articles, uses the zero or more HTML5 section structures, and may contain a header, footer or navigation components (e.g., a Table of Contents).  A composite document contains one or more articles.  Each article follows the rules for singular documents, including its functional requirements (e.g., with respect to subject, identity, etcetera).  This allows for collections of documents (e.g. a package of medical records) to be organized into one HTML5 document, and to be extracted and repackaged into another for a different purpose.  An HTML5 transform from article to document and from document to article is straight-forward, since they would be defined as having identical requirements.
2. An SDA Level 2 document would require metadata on not just documents, but also on sections.  That metadata would include for example, a code describing the content of the section.  
3. An SDA Level 3 document would require additional metadata that provided clinical statements associated with the narrative in the document.  It would require conformance to SDA Level 2.  

Now for the traditional CDA Levels:

1. A CDA level 1 document would require the presence of certain metadata (patient, author, document topic, et cetera) in addition to the metadata required of all documents.  But that presence would be defined functionally.
2. A CDA Level 2 document would apply the requirements of SDA Level 2 to CDA Level 1.  It would add requirements for coding sections and providing metadata related to sections.  Again, that would be defined functionally.
3. A CDA Level 3 document would apply the requirements of SDA Level 3 to CDA Level 2.  It would again add functional requirements.  This time, they would be that the document provide machine readable clinical statements from the appropriate domain model to represent the content of the narrative.

Information Models
Now to integrate information models.  Thus far, requirements on the presence of author metadata, patient metadata, et cetera, have all been defined functionally.  I can imagine four different information models that could support these functional requirements.  They are:

• HL7 RIM based models; 
• Green models (ala Green CDA), which are essentially domain specific models derived from a template metamodel, 
• detailed clinical models, which are simply another domain specific model, and 
• OpenEHR based models.  

Each of these models has different structures and rules.  Each of those different models can be used to meet the functional requirements for CDA Level 1-3 (or SDA 1-3).  What the heck, I could even use the CCR data model to meet those requirements.

As yet, we have not discussed wire format representations, just requirements and information models.  To get to representations, we need a microdata framework.  Most of that is already specified in the W3C microdata draft specification, but some profiling may be needed here.  There would need to be a mapping from RIM, Green, DCM, and OpenEHR models to an appropriate microdata representation.  I know how to handle RIM, and have some thoughts on how to handle data types R2, which I view as a two part specification:  Functional requirements on data types, and wire format representations in XML.  For microdata, I want to consider how to meet the functional requirements of the data types, and not necessarily to incorporate the XML representation.

Rules for defining microdata from XML Schemas
Some HTML5 elements are mapped directly to components of the information model.  In HL7, documents, sections, and text (and the subcomponents of text) would map quite well into HTML5.  For elements that don't map to HTML5 elements would be mapped to microdata.  Here are the basic of rules for mapping from schemas (a model) into microdata.

1. An element in the schema becomes a microdata item.  In XML Schema, element names and type names associated with them are described using the XML QNAME.  In microdata, a name or a type can be represented by a URL.  
2. To transform a QNAME into a URL, one simply concatenates the namespace URI, a #, and the element or type name to create a URL that can be used in the microdata propname or proptype attributes.
3. An attribute becomes an item property.  The QNAME associated with the attribute is used as the property name and is transformed to a URL according to the rule above.
4. Elements which don't have associated text in the narrative are represented using span tags containing no text with appropriate microdata elements at the end of the appropriate section.

Thus, a  <cda:substanceAdministration> tag would appear in an HTML5 document as an item where propname='urn:hl7-org:v3#substanceAdministration' and proptype='urn:hl7-org:v3#SBADM'.  Each attribute of the element becomes a new property using the element QNAME as the property name, and the value being the attribute value.  If the CDA element is an entry pointing to narrative text, then the text it points in the document becomes the element where the metadata appears.  CDA entries that don’t have an association with narrative text are transformed to empty <span> or <meta> elements at the end of the section, in the order in which they appear.

The Power of the Framework

Now, here is where I think the beauty of this lies:  A CDA document is defined based on certain functionality, and a singular standard (HTML5).  When we get into representation of content in the information model, every information model is connected to the clinical content in the same way.  The receiving system does not need to even understand the contained information model in order to compute with it, so long as the pieces doing the computing are aware.

There are still too many options for information models for the comfort of many people.  A number of folks are still very leery about the3 existence of both GreenCDA and CDA wire formats.  I’ve just added three other information models to those two (DCM, OpenEHR and CCR) and it could be worse.  It could support the CIMs created by the transfers of care work via the S and I Framework. How about Google Microdata definitions for People, Organizations, Products and Events?

We could even use what I call the blue model.  In the blue model, you have levels as well.  The very basic level is CDA level 0.  It contains just text in a <pre> tag.  This is basically worthless for anything other than displaying, or perhaps using a customized parse into a spreadsheet.  The next level puts some metadata on it using spans to wrap the different parts.  We keep adding levels until the necessary structure appears for full computability.  At some point, the pre tag can disappear and you have a CDA Level 3 with machine readable metadata and models.  Dump your blue-button text into the first, and what have you?  Something that everyone can read, but no computer can do anything with.  Keep moving the bar, and it becomes fully machine readable with well-defined semantics.

The power of this framework  is that it could support ANY model.  The problem with it is that it can support ANY model.  Why is this a good thing?  If you take it far enough, models can easily coexist.  I could have CDA and GreenCDA at the same time, or CCR and CDA.  I could even use the Google Microdata right alongside HL7 patient, organization, product and encounter models.  People are going to complain that this is ugly and not at all what standards are about.  We want a single international standard which makes everyone happy.  This suffers from so much optionality that nobody would be able to interoperate.  

Building the Standard from the Framework
But we haven’t built the standard yet, only a framework upon which we could build it.  My preferred approach would be to use RIM or a Green model for CDA.  But if the framework is right, we can share this infrastructure with others who want to use a different information model, and we would still be able to support some level of interoperability across all clinical documents.  At the very least, all these clinical documents would be human readable across the different models.  You might not understand the metadata present in the document, but you could at least read it.  For most browsers, this is exactly the behavior that we get today when we display an HTML5 document.

We still have too many options, so it is time to eliminate some of them.  As far as HL7 is concerned, for an HL7 CDA instance, the microdata must based either on the RIM, or on a Green representation of a RIM model.  I can build a RIM microdata ITS in my sleep, the rules are so simple.  I cannot do this for Green models today, although I’m told it will get easier soon with tools from both HL7 and MDHT.  So that’s another research project.  I'd stick with RIM for now pending the outcome of the other project.  And I can use them both!

Data Types
I haven't yet addressed data types.  These would be specified as a separate microdata ITS.  The reason for doing that is that I want to experiment with two different data type representations.

The first representation uses the data types and their components as full-blown microdata objects.  The second uses simple strings as much as possible.  Many (not all) HL7 Data types have a literal form.  A PQ is represented as a real number followed by optional whitespace, followed by an optional UCUM unit expression, e.g., 350mg.  A time interval can be represented as [198705122000;198705122130]. 

• Literal forms are human readable and can be readily parsed and understood by humans and computers.  
• They are shorter than forms which require each component to be separately identified.
• They may actually be easier for implementers to use and parse.  

Unfortunately, code values (concept descriptors in HL7 parlance) do not have literal forms, but I have a cheat for that based on how I teach that data types (and would welcome other approaches).  Most uses of CD are actually CE.  The basic representation of a code requires a codeSystem and code.  This is really just an identifier for a concept in a particular namespace (a vocabulary).  The HL7 II data type represents identifiers using the literal form root:extension.  I’d just adopt that for CD, and maybe add some syntactic sugar to support codeSystemName and displayName.  Qualifiers are microdata properties where the name is the qualifier name, and the value is the qualifier value.

Having a data types R2 component Data Type ITS, and a literal Data Type ITS allows some experimentation to show which is easier to use, code for, et cetera.

Relationship to SAIF
This is either the sickest implementation of an HL7 SAIF architecture that I’ve ever seen, or the most beautiful.  I’m not sure yet.  We’ve defined SDA at four levels of conformance.  CDA adds functionally defined clinical document requirements to SDA at each of three levels (CDA Level 0 makes no sense).  The simple set of model mapping rules to microdata describes how to represent models in microdata in a general way.  Mapping from CDA Narrative content can be based on existing mappings with some additions to support new HTML5 features like section and hgroup elements.  The models could be just about anything, but we’ve noted two different possibilities as far as HL7 goes:  RIM and Green.  The data types could either be structured R2 data types, or literal form data types (I’m leaning this way).  The clinical content could come from any HL7 domain model, mapped to RIM and using the Microdata RIM ITS wither either data type mapping.

This represents clean separations for each part of the specification, governed along appropriate lines: SDWG for document structure, domain workgroups for clinical content, MnM and ITS for modeling and data type representation.  The pieces are readily separated into pieces of the larger CDA Release 3.0 project around responsibilities.  The general framework for creating CDA also provides a supporting pattern and infrastructure for subsequent modeling excercises.  We could easily develop SPL, Order Sets, and computable clinical guidelines with appropriate constraints on A) metadata associated with the document, and B) models to represent the machine readable content.  All of these could reuse the Microdata RIM ITS and data types ITS.

Platform Support

The cool thing about microdata and HTML5 is that is scriptable in a browser on multiple platforms.  A good set of scripts will allow someone to use Java or .Net based browser that support it to use the Microdata DOM API to access the microdata content.  These can be readily manipulated in a conforming browser to create a rich, CDA (or SDA) editing platform, using soon-to-be off-the-shelf technologies.  Forget VMR.  If I can give you a CDA in HTML5 with microdata, you will already have a programmable platform from which you can obtain clinical data, and upon which you can create and implement clinical decision support rules.

Several other projects come to mind, many pretty easy to implement: 

• A Microdata to JSON/JavaScript transformation tool is like falling off a log.  A competent engineer with the right tools could build this in a day.  
• A microdata to XML representation tool is also pretty easy, but might take two or three days.  If we define Microdata property models using QNAME to URL transformations, then the only real challenge is figuring out which properties are represented as attributes rather than elements.  
• Microdata Type definitions could include metadata (as microdata even) that assisted the transformation in determining whether to represent microdata properties as attributes or elements.  It would certainly be easier to convert component based data types to XML, rather than the literals, but either still wouldn't be that hard.  We'd probably have to define that in some way.
• You could also add a transformation from HTML5 to the appropriate RIM XML representations for CDA, or any other SDA-based document.

Challenges

OK.  Now I’ve explored benefits.  What can shoot this down? 

Backwards compatibility
This representation is a dramatic departure from the current CDA representation.  Moving from CDA R2 to a microdata based R3 could be a challenge.  But just as there are many common XSLT transformations from CDA R2 to HTML, there are equally feasible transformations from CDA R2 to HTML5.  CDA R2 metadata is readily transformable to its microdata representation following rules similar to what I already described above.
 
A course alteration will delay CDA R3  
While this is almost certainly true, I believe the separation of labor possible with this architecture could actually make it easier to manage, and could even be done sooner.

A movement into untested waters 
Yes, HTML5 is not fully baked.  But many of the features of it are already supported in today’s browsers.  We have an opportunity now, while HTML5 is still being baked to experiment with it, and provide feedback to the W3C to make sure that it does get baked with any features we discover we need.

Dependency on someone else’s standards 
HTML5 and Microdata are being developed by the W3C and the WHATWG.  I don’t see this as an issue, rather it is a huge benefit.  The principals of HTML5 will be understood by the next generation of IT professionals by the time it is ready.  You can buy books from O’Reilly today on HTML5.  When you use general IT standards to solve healthcare IT problems, you can take advantage of the much broader market for those standards to get implementations.  XDS has 10 open source implementations because the underlying infrastructure is already widely available in open source.  As far as I can tell, it is the single most widely adopted HIE technology, and I expect it is because of that link to general IT.  Building CDA Release 3.0 on top of HTML5 could have an even greater benefit.