HL7's new AMS is live!   We are working with Fonteva to resolve log in issues. My Account

The HL7 C-CDA Rendering Tool Challenge

C-CDA® Rendering Tool Challenge

HL7 and the Office of the National Coordinator for Health Information Technology (ONC) are holding a challenge to encourage the development of HL7 tools. Will your team be the one to develop the solution and take home the prize?

Want to learn more? View our recorded webinar and the accompanying slide presentation.

Challenge Participants can view the recorded Question and Answer session held on May 4, 2016.


1st place $15,000
2nd place $5,000

Submission Dates

January  12, 2016 – May 31, 2016

Winner Announced

September, 2016 - During HL7's 30th Annual Plenary Meeting in Baltimore, MD


Challenge update:

Winners will be recognized at HL7's 30th Annual Plenary & Working Group Meeting in Baltimore, MD this September

First place winner:
The Backbeach Software C-CDA Viewer, developed by: Bryn Lewis, PhD, Principal Software Development Consultant, Backbeach Software

Try out the tool yourself!  Click on any of the Sample CDA documents appended below the tool at:

Watch a two-minute demo 

Demo of Clinician Notes

Second place winner:  
Patient Insight, developed by: Will Tesch, CEO, HealthLX inc.


HL7's Consolidated Clinical Document Architecture (C-CDA®) standard is an XML-based document markup standard that specifies the structure and semantics of clinical documents such as Discharge Summaries and Imaging Reports that are exchanged between healthcare providers and patients. One of the six characteristics of a C-CDA document is human readability. The process by which these documents are made human readable is called rendering. One of the requirements of C-CDA is that all relevant clinical content of a C-CDA document shall be present (and thus renderable) in human readable form. 

Currently, many clinicians are frustrated with the usability of C-CDA documents because an overabundance of data is rendered by the EHR system based pm C-CDA documents that are being sent/received.  The providers then have to page and sort through all of the data to find the essential and relevant clinical information that triggered the clinical event for which the C-CDA document was created. EHR vendors, for numerous and admirable reasons, typically render more information than clinicians want, sometimes including the patient's entire medical history. A viewer that makes relevant information easier to view would save clinicians' time and insure they do not miss the information they need to make decisions.
C-CDA Rendering Tool Challenge participants will develop a viewer that enables clinicians to efficiently review the patient data from C-CDA documents that is most clinically relevant to them.  The viewer must be capable of rendering the data as specified by the user and allow them to quickly review the current health and needs of a patient.  The viewer should provide functionality to allow a clinician to view the data so they can quickly assess the status and state of the patient efficiently. The viewer needs to be easy to use and present requested data quickly and clearly, whether through section-based view preferences (ordering), filter functions, intelligent sorting, or some other functionality. 
Participants may wish to consider allowing providers to not only select the data they wish to view, but also provide aids which enable effective review of repeating or reoccurring results within sections. 


Entries must adhere to the current principles and requirements for rendering a CDA document (as found in the Clinical Document Architecture standard):

  • There must be a deterministic way for a recipient of an arbitrary C-CDA document to render the attested content.
  • If the C-CDA document has a title it must be rendered.
  • If the C-CDA Body is structured, the label of a section, as conveyed in the Section.title component, must be rendered. The absence of the Section.title component signifies an unlabeled section.
  • When structured content is derived from narrative, there must be a mechanism to describe the process (e.g. by author, by human coder, by natural language processing algorithm, by specific software) by which machine-processable portions were derived from a block of narrative.
  • When narrative is derived from structured content, there must be a mechanism to identify the process by which narrative was generated from structured data.

NOTE: These principles and requirements have led to the current approach, where the material to be rendered is placed into the Section.content and it frequently is not clear where to consistently find narrative.


  • Submission must be open source
  • Submission must meet the minimum certification requirements for viewing C-CDA documents out of a health IT application module as stated in the 2015 Certification Criteria (see page 34 at
    • Directly display only the data within a particular section
    • Set a preference for the display order of specific sections
    • Set the initial quantity of sections to be displayed
  • The winning entries will reside on Github and made freely available on the HL7 website for use
  • The overall winner will receive a complimentary registration and be encouraged to attend the HL7 30th Annual Plenary meeting (September 18-23, 2016 in Baltimore, Maryland) where they can demonstrate their tool for attendees.

Helpful resources:

Questions and inquiries can be directed to David Hamill, Director, HL7 Project Management Office at pmo@HL7.org.