By far the most common question was whether attendees could get the slides. The slides are being made available to all attendees in PDF form, and I believe have already been mailed out to anyone who registered.
These are the questions we got and my answers:
- What is the best resource to get started? By far the best resource to get started with are the specifications themselves, which are available through HL7. For the HITSP C32, the best document to look at is C83 CDA Content Modules which contains numerous examples. There are also many examples in the IHE PCC Technical Framework.
Another good resource are the CDA and CCD Quick Start guides which were developed by Alschuler and Associates.
- Is the HL73/CDA 2 XML spec publicly available?
How can the current CCD Implementation Guide be obtained? Are there legitimate sources outside of HL7? The CDA Standards are available through HL7, ANSI and ISO (yes, CDA is also an ISO Standard). I believe the CCD specification is only available through HL7.
- What tools are available to create and read CDA documents?
There are a number of tools at various levels of complexity. I recommend having a look at the Model Driven Health Tools which includes tools designed to author, publish, validate, and implement CDA documents. There's also the NIST Validators, which will be crucial for US implementations. Misys Open Source Solutions (MOSS) includes a CCD Generator. IBM produced a CDA Builder that is apparently in use at NCI. The Open eHealth Integration Platform contains a CDA Parser. There is an Eclipse Instance Editor that can be used to validate and edit CDA Instances.
- Which is the best version of the implementation guide for CDA that one should use?
What are you trying to do? There are more than two dozen implementation guides on CDA, some of which stand alone, and others which build on top of other guides. Most of the guides build from the CCD guide but go further, filling in the gaps that CCD wasn't designed to address. If you are looking for CDA Implementation guides for use in the US, the best source is still ANSI/HITSP. For Europe, I would suggest looking at the work coming out of epSOS. One of the very first guides came out of Canada. This post contains a diagram showing the intellectual history of many of the guides, and includes links to many of them.
- What is the difference between CDA Release 1, 2 and 3? That's kind of like asking what the difference between HTML 1, 2, 3, 4 and 5 are. However, to make it short and sweet. CDA Release 1 was the very first HL7 Version 3 standard to be produced (1999). It uses a form of XML and a model of the RIM that actually predates the HL7 Reference Information Model and XML Implementation Technology standards that we know today. CDA Release 2.0 is the current version and is what CCD and other implementation guides are based upon. See the next question for CDA Release 3.
- What are your plans with CDA R3 release?
There a numerous changes planned for CDA Release 3. The HL7 Structured Documents Working group is currently building a plan having evaluated nearly 50 Suggested Enhancements and 65 Formal Proposals. While there are many expected changes, the biggest will be support for reuse of Domain models, support for public health, and some thoughts on chaning the narrative to support a subset of XHTML.
- What is relationship between CDA and Green CDA? Green CDA is a simplified version (more efficient, easy to write, edit, read, etc?) of CDA? Green CDA will replace CDA? When green CDA should be used? Green CDA is essentially an experiment to see how to make it easier to produce CDA documents. Will Green CDA replace CDA? I don't think so, since it is more limited than CDA. However, it does effectively provide a simpler API to produce CDA documents.
- Is there a file size limitation for CDA to support? CDA documents are not themselves limited to any particular size by the standard. Size limits may be imposed by external systems. For example, many interfaces can support messages that are 32 or 64K in length (a goodly number of pages of CDA document, probably more than most structured documents would ever need).
- Are there any standards around compression or encryption of CDA documents? The HL7 standards fort the ED Data type support compression of image content inside a CDA document. Web related standards support compression in transmission (e.g., GZIP).
- Can you also use CDA to show document images? or is it data only? Images are supported by the standard, but it is not intended to replace DICOM for imaging (e.g., an X-RAY, CT Scan or MRI Study). The example document in the CDA standard shows how an image can be included in a document.
- Can you describe a use case for CDA and how (or perhaps if) that is different than a use case for CCD?
- Can you please briefly describe now a CDA might be used differently than a CCD
- Why can't a discharge summary be expressed as a narrative in the Encounters section?
For these three, let me refer you to my second post "If I had a hammer" and the reason for starting this blog.
- Is there a such thing as a "generic" CDA XML document, or is it always also a defined structure such as CCD?
The CDA standard itself is intended to support a wide variety of use cases and to enable the display of clinical content using a single stylesheet. It need not always be a defined structure such as the CCD.
- Can you please elaborate on how how business rules are translated into the templateid root.This post on Template Identifiers, Business Rules and Degrees of Interoperability probably covers the most important details. Essentially the template identifier is assigned to a set of business rules associated with an information item. Those business rules can be encoded into conformance requirements that can be in many cases automatically evaluated with model driven tools or using ISO Schematron as in the NIST validators.
- Is it also relevant for interoperability inside hospitals (between applications inside hospitals, Cardiology CVIS and HISs), replacing hl7 ORU/MDM messagesYes, CDA is very relevant for interoperability inside hospitals, but it need not replace the MDM message. The MDM message is a way to transport a document between systems. CDA is the Content to be transported. Many systems in use at hospitals support use of MDM to do this today.
- MDM vs CCD?
- What type of HL7 V2 message can be used when CDA or any other file is to be exchanged using HL7 V2 Message?You can use the HL7 Version 2 MDM message to transport a CDA document, and the CDA standard itself covers this in section 3: CDA Document Exchange in HL7 Messages.
- Has any consideration been made for person-readable data in a multi-language environment? CDA supports reporting of the principal language of the document in the languageCode attribute found in both the ClinicalDocument element and the section element. The ISO 639 code "mul" can be used to specifically identify content that is multi-lingual. This is something needing review in Release 3.
- If machine readable entries are included, does the clinical content need to match what it in the human readable section? The HL7 Structured Documents Workgroup has long asserted that what is seen in the human readable narrative, which includes document titles, section titles, and section text is what is signed. The machine readable entries SHOULD match, but you can expect that there may be more clinical detail in some of this content that may not be part of the signed narrative. For example, codes may be applied to clinical content after documents are signed.
- Is there a list of EHR vendors that are currently able to recieve CDA documents, e.g., Hosptial discharge summaries directly into an ambulatory EHR like say [product name]. HL7 maintains a Product and Service guide which contains some information, but hasn't been fully populated by all vendors supporting CDA. IHE Connectathons also report on which vendors have successfully implemented IHE profiles, and Vendor Conformance Statements for those vendors are available (click the folder link on the report).
- Is there a reccomendation on the CCD of how to indicate that a piece of information is considered sensitive. ie a diagnosis of HIV. This would be to enable the receiving application to either mask or require an attestation as to the need to see this information.
CDA includes an attribute called confidentialityCode on the document or any of its sections which can be used to mark the sensitivity of the document. See this excellent post by John Moehrke on appropriate use of that attribute. The main problem with "MASKING" as it were are that in implementing such an infrastructure you are interfering with the wholeness and legal authenticity of the content being viewed.
- A CCD section (encounter) can have many different types of entries by using CDA linkage. Example: Encounter Section can have Results Observation entries, Procedure Entries ...etc is there any standard which restricts this?
Other than explicit restrictions in CCD (or guides which build upon it), not that I am aware of. Most implementation guide developers for CDA take the approach that you must send what the guide requires, but are permitted to send more. This allows for incremental interoperability (see this post). If we had restricted the CCD entries to be only what we had modeled, CCD sections could not be reused and extended to support new use cases, and similarly for other guides.