If you are working on CDA or beginning to work on CDA, you might want to consider coming to the HL7 March Educational Summit in Atlanta GA. The dates are March 6-8, 2012 and they will be filled with CDA tutorials.

The first is the Introduction to Clinical Document Architecture (CDA), offered the morning of Tuesday March 6th, in the afternoon we will be presenting Clinical Document Architecture (CDA) Advanced, the morning of the 7th we will be presenting the Continuity of Care Document (CCD) and in the afternoon, we will be presenting the CDA Specialist Certification Exam Review.

After two days of study and I would strongly encourage you to read the CDA Standards itself, you could take on the HL7 CDA Certification Exam on Wednesday morning. What better way to spend 1/2 a week in Atlanta. Seriously, if you want to understand the CDA standard, why was it built, how it works, what are doing with it, the Ed Summit provides a wonderful opportunity. Hope to see you there.

The HL7 Structured Documents Work Group has made some progress with the new CDA R3 standard.  Key enhancements include :

1. Full RIM semantics in the clinical statement
2. Significant extensions to the CDA header
3. RIM Data Types 2.0 / ISO Data Types
4. Numerious technical corrections and enhancements

Full RIM Semantics in Clinical Statements

The new standard will support full HL7 Version 3 - RIM semantics in the clinical statement pattern, using a more or less fully uncontrained RIM model. This new enhancement, which at first seems somewhat complex, will be visualized in the HL7 CDA R3 educational tutorials as a simpiler DMIM diagram. This new model is essential to resolve some long running issues with the CDA R2 modeling capabilities, as we seek to improve the CDA's fidelity to other HL7 Domain Committee models.

Significat Extensions to the CDA Header

CDA R3 will support a secondary generic Partisipant for non-patient care documents. This extension will enable support for non-human species and other public health entity partisipation relationships to the header. The modeling for the partisipations is very expressive and draws upon the RIM in a fashion simular to the new clinical statement model. As such, it will require custom templates to invoke, and is not antisipated to be used in normal patient care documents.

ISO / RIM Data 2.0

As part of our refresh to the CDA, we will be migrating from RIM Data Type 1.0 to the new ISO / RIM Data Types 2.0.  A number of enhancements have been incorporated into the new data types specification, including support for post-coordination syntax in the code value field, when the underlying vocabulary system supports it, E.g. SNOMED. Another enhancement comes in enabling Instance Identifiers to clearly indicate the type of Identifier that is bring expressed, E.g. ...

Numerious Technical Enhancement & Improvements

Our last set of enhancements focus on improving the modeling in CDA in a number of ways. Examples include: clearly indicating the source of an Identifer, explicectly identifing the Subject in the CDA header, to supporting the new modeling for context flow representation from the header to the body, section and clinical statements.

Overall, CDA R3 looks to be a major step forward for the CDA standard, the goal of the Structured Documents Work Group is to bring the new release to ballot during the Sept. time frame. Please take time to download it and offer feedback as we move this important standard forward.

Calvin Beebe

The CDA standard is over 11 years old. It started with CDA R1 in 2000, followed by CDA R2 in 2005. Why is CDA R3 taking so long to develop?

The reasons are varied, but for those of us who have worked on the CDA standard over the years, it's the challenge of making it better and not worst. The CDA standard is in some ways simple, it's got a document header, where we keep track of the patient, author, authenticators who have signed off on the document, and we keep track of the document creation date, id and type of document. There is more of course, but the fields provided in the header more than satisfy the basic needs for indexing and retrieving the document from an underlying EMR or document repository. In addition to the header, the document body contains any number of sections needed to display the human readable text, composed of any mix of paragraphs, lists and tables. In all, it's a nice package, which also includes a series of optional machine processable clinical statements, which can be used to perform decision support of any other form of processing required against the clinical content.

This general architecture supports many kinds of clinical documents, likely any you might want to share, and this is where the challenge comes in, CDA has been too successful. Because its such an effective package of human readable and machine processable content, many groups come to us, wanting to put their content into a CDA Document. So much so, that almost any content can now be placed into a document including some which represent data sets more than documents. How does this relate to CDA R3?

Well if we attempt to make CDA R3 do it all, we risk loosing our sense of an authenticated unit of information, a signed clinical document.

We really need two types of containers:

• One a document, which carries a legal authentication along with the human readable markup representing the legal authenticators view of the content and optionally supporting clinical entries.

• The other a collection of data, call it a report or record set, provided by applications, using the clinical statement model to convey processable data that is interpreted and analyzed using software by the receiver.

Both forms of data are common in clinical applications. So much so, that we likely need a third specification, an e-folder object, used to hold any number of these documents and record sets so they can be packaged up and shared between users of clinical systems. Just think an e-folder containing any number of clinical documents, records sets needing to be shared between clinical systems.

We could place the protected health information in the folder secure it up, sharing any patient consent or authorizations needing to be conveyed and ship it between clinical practice sites. The record sets, could identify their contents, laboratory results, vital signs, flow sheets and the documents could be processed for their header references. Audit and controls (authorizations) could be included in the package, in imbedded in the documents and record sets, but provided in association.

Maybe we need less in CDA R3, and more in our standards? - Posted by C. Beebe via iPad

One of the interesting proposals coming out of the HL7 meeting in Orlando this week, was one to create a project to support defining Public Health Reporting requirements via the Structured Documents HQMF standard. This seldom discussed standard, is a sibling standard to the CDA and supports the definition of measure requirements via structured data in a document format. Not intended to support patient data content directly, it rather specifies what information to extract from an EHR or other systems in order to create useful measures for quality assessment. This might be an interesting project to follow as it rolls forward. - Posted by C. Beebe via iPad

Location:Hotel Plaza Blvd,Orlando,United States