Skip to end of metadata
Go to start of metadata

Event Location

San Antonio, Texas, January 12-13, 2019


  • Lisa Nelson (MaxMD)
  • Jean Duteau (Duteau Design)
  • Joginder Madra (Madra Consulting)


  • Improve consistency and quality of information representation in C-CDA exchange documents


Saturday, January 12, 2019


Encounter Summary Documents vs Patient Summary Documents

Utilize guidance developed in the Commonwell/Carequality IG.

Participants will bring prepared C-CDA sample documents and their questions.

Documents will be exchanged and reviewed for consistency and consumption capability.



Utilize guidance available from ONC, maturity ranking for each data class developed at the ONC Interoperability Forum.

Participants will bring C-CDA documents that demonstrate representation of selected USCDI data classes.

Participants will discuss areas where guidance is not clear enough to guide consistent representation, identify opportunities for greater consistency, and generate examples to be considered by the CDA Examples Task Force to improve the pool of verified examples available to implementers. 


Clinical Notes
Demonstrate how to use new C-CDA supplemental templates for Notes Section and Note Activity. 

Participants will bring C-CDA documents that demonstrate representation of clinical note information.

Participants will discuss areas where guidance is not clear enough to enable consistent representation, identify opportunities for greater consistency, and generate examples to be considered by the CDA Examples Task Force to improve the pool of verified examples available to implementers.


Handle C-CDA documents within FHIR APIs

Participants will explore options for exchanging C-CDA documents via FHIR APIs.

Participants will use conversion mechanisms to experiment with converting C-CDA documents into FHIR C-CDA documents, and converting FHIR documents to C-CDA documents.

Sunday, January 13, 2019


Care Plan Documents

Participants will bring C-CDA Care Plan documents that demonstrate representation of care plan information.

Care Plan documents may include a Document Summary Section as specified in the IHE DSS profile.

Participants will discuss areas where guidance is not clear enough to guide consistent representation, identify opportunities for greater consistency, and generate examples to be considered by the CDA Examples Task Force to improve the pool of verified examples available to implementers.


Participants will discuss issues related to defining and representing data provenance in C-CDA documents.


Participants will learn and provide feedback on the rules developed for the Scorecard tool and for plans developed around the CDA roadmap.
Participants will discuss and provide input on approaches to change management and release scheduling that support implementer preferences and recognize implementer challenges.
Participants will provide feedback on uptake for new versions of C-CDA Templates:  Considerations for errata releases, Value Set updates and possible C-CDA R2.2


Emergent Topics

Participants will conduct additional discussions for parking lot items.

Optionally, participants may discuss emerging topics such as the representing Social Determinants of Health.

Participants interested in exploring other FHIR tracks may join with other track programs.


See Attendance sheet

Event Notes - see IAT slide deck



Sat - Q1

Encounter Summary Documents vs. Patient Summary Documents

Encounter Summary and Patient Summary Sample Files

  • Encounter summary vs. patient summary
    • encounter summaries summarize and individual patient visit
    • patient summaries summarize care over a period of time and may encompass multiple encounters. Challenge is in present patient information over time - e.g. problem list changes vs. problem list at point in time
  • Encompassing Encounter can be used to include multiple service events as part of an encounter summary
    • Nobody appears to do this. More have the ability to include a single service event as part of an encounter summary.
    • Service Event vs. Encompassing Counter
      • there appears to be some duplication in information that could be included at each level
      • providers involved in an encounter → encompassing encounter
      • care team members (but not involved in an encounter) → service event
      • "Care Team" needs refinement to more clearly define content and usage. Add to Sunday Q4 discussion.
Sat - Q2

USCDI (US Core Data for Interoperability)

  • What goes into the results section? This section has been a bit of dumping ground.
    • Clear consensus for putting lab results in the results section
    • Resulted procedures (e.g. EKG) may be both in procedures and results.
    • No clear consensus around "other" results - e.g. non-mental/functional assessment scales
    • Desire for definite list of what is allowed in the results section, what is allowed in the assessments section, etc. Additions to the list could be requested. Need process around this.
      • Take to CDA Management group to provide guidance on how results should be shared:
        • results section
        • assessments section
        • grab bag section
    • Consistent use of the result organizer - even for single results
      • Use of the result organizer allows for machines to process all "results" consistently regardless of which section the results are placed. Organizing "results" into different sections offers more value to human readers.
  • Use of assessment section, plan section, and assessment and plan section
    • The existence of these three sections is problematic as it allows for variation in the community. Recommendation is that implementers are encouraged to use the assessment section along with the plan section and avoid using the assessment and plan section.
  • Medication statement vs. medication administration vs. medication order
    • medication statement vs. medication administration
      • only way to differentiate between a medication statement and a medication administration is to indicate who reported this information
    • medication administration vs. medication order
      • use mood code 'EVN' for administrations and 'INT' for orders
    • medication dispense → does not appear that anymore is including information about dispenses
  • Compounding
    • can be communicated via text or broken out by ingredient
  • Recommend that NCQA specifies HEDIS quality measure values sets that include support for RxNorm and NDC.
    • Q3 update...this would be supported by HEDIS by 2020
Sat - Q3

Clinical Notes

  • Question was posed around the white paper published by the CommonWell Health Alliance. Most are aware of the white paper and there is general intent to develop in accordance with it.
  • Three approaches to representing clinical notes:
    • include note(s) directly attached to the associated act
    • include note(s) in an appropriate standard section
    • include note(s) in a standalone notes section
  • Implementers in the room have the ability to support one or more of the above approaches
  • What is the differentiation between a comment and a clinical note? Historically (i.e. in CCD), comments were defined as "free text data that cannot otherwise be recorded using data elements already defined int he specification". Additionally, a comment requires context to be meaningful and is unable to stand on its own whereas a note can stand alone
    • Hierarchy of usage: clinical notes → comments
  • Action: Examples Task Force to create examples to illustrate

Section Time Range

  • Intended to communicate to the consumer that information contained in a section is limited to the specified time period. There is additional information that is not included because it is outside of the time range. Information that is to be included may require evaluation of the information's status - e.g. a medication was started 5 years ago but is still active. A section time range of the past 6 months should probably include information about this medication as it is still relevant.
  • Original intent of the section time range is to indicate the information provided is somehow filtered or limited.
  • Some providers have requested a filtering of observations to only include the last x number of opposed to limiting by time
  • Action: request that guidance be updated to illustrate scenarios where information is limited (timing-limited usage scenarios, well as quantity-limited scenarios, context-limited scenarios, etc.) well as reviewing existing guidance that section time range only applies to encounter summary documents.

Encounter Diagnosis

  • The CommonWell guide in section 2.2 indicates that an encounter is required to have a diagnosis. Note all encounters will have an encounter diagnosis. This requirement originally stemmed from billing requirements. Brett to update wording to allow for this.
Sat - Q4

Handle C-CDA documents within FHIR APIs

  • FHIR Document Representation
  • CDA → FHIR mappings
    • CDA→ FHIR and FHIR→CDA allows for implementers who only do CDA or who only do FHIR to communicate with each other
    • Initial set of business-level mappings (along with transforms using FHIR mapping language) are available on Github
    • Output of this project was to create draft business mappings and to demonstrate simple round-tripping as a proof of concept. However normative and/or definitive mappings do not yet exist.
  • C-CDA → FHIR transformation demo
    • Lisa demonstrated a live C-CDA to FHIR bundle mapping using the FHIR API.
  • There is an active project with Service Oriented Architecture(SOA). People interested in participating should review the mappings here: SOA C-CDA to FHIR mapping
Sun - Q1

Care Plan Documents

Care Plan Sample Files

  • Care Plan exchange exercise
    • section.title is user-facing and can be rendered using a local display name instead of the LOINC long common name. Further discussion on this will be in Q4.
    • interventions should be linked to goals
    • Chapter 6 of the IHE profile provides recommendations around the creation of summary sections
    • wrapping in the HL7 stylesheet not always working appropriately for some of the samples - e.g. use of styleCode xContentWrapping in line 326 in Allscripts CCDA_MU2015AmbCarePlan with Summary Section.xml
    • The caption element handling doesn’t work properly for elements that aren’t <table>. The apply-template for the non-table case is missing its select statement which is causing the value of the caption to be duplicated. This can be found on line 1695 of the stylesheet (assuming I have the most updated version). The template affected is specifically the template that matches <hl7:caption>.
    • Payers section still needs work.
      • use of root and extension in payer IDs is problematic as there is not common understanding or agreement of which payers are associated with which root and/or extension
  • Allscripts, Meditech, Epic, Cerner and Dynamic Health IT have implemented Care Plan in a production environment
Sun - Q2


  • Operational definition for the session - data and metadata for who and when information was/is created and/or authored, for the purposes for trust, traceability and identification
    • Information contained within a document may have its own "provenance" however, when this information is packaged into a document the document has a separate set of provenance metadata
      • Notion of "who" goes into a role issue, which bleeds into the question of who in what role (author, performer, informant)
      • The "what" may need to be taken into consideration to determine the correct set of "who's", i.e. lab data may need a who around the lab as well as the author in the medical record.
  • Provenance in C-CDA:
    • document-level
    • entry-level
    • authorship of information (who and when) conducts down if it is not otherwise specified (i.e. the document author is assumed to be the entry author if not otherwise specified).
    • suggested guidance - entries should include performer information (who and when) even if not explicitly defined as part of a template

Sun - Q3


    • Additional rubrics can be proposed by adding to the wiki page (near the bottom)
  • Updated Rubrics
    • intent is to have these incorporated into the Scorecard by the May Working Group Meeting
    • important to remember that decisions around rubrics are made by the Structured Documents Work Group
    • The Scorecard is being used more in more for validation of production documents. Need to emphasize that the letter grade goes beyond what is required for MU validation. There can be a negative perception of an example that is fully compliant with MU, but it does not incorporate all of the suggested best practices. The letter grade suggests something that goes beyond the original intent (e.g. a grade of D suggests that quality may be low...even though a D grade passes certification requirements).
    • Suggestions:
      • indicate the number of tests graded and number of tests passed
      • indicate the number of unique issues
      • other suggestions should be sent to Matt
  • Rollout Process
    • There should be a grace period before the new rubrics will start counting towards the scorecard score. A notice period of six months was suggested before new rubrics are fully used - i.e. incorporated for scoring in the scorecard with errors counting against a score.
      • Important to have high visibility (perhaps by balloting new rubrics) whenever new rubrics are being considered
      • suggest having a regular update cycle - e.g. rubrics will be updated every May

Sun - Q4

Display Name and Validation

  • If validators are going to validate against the display name, the validation should not just be an exact match.

Unsuccessful Attempts for Procedures

  • A procedure was ordered and performed/completed....but the results are not usable - e.g. MRI procedure but the patient moved around too much and as such was not successful.
  • Driven by health maintenance objectives where one would want to indicate that something happened, but it is not valid as part of health maintenance.
  • Suggest handling via procedureActvityObservation.
  • Action: Michal to develop new examples of aborted procedures...leading to a ballot to validate.

Custodian Information

  • Should be the business entity that has responsibility as the steward of the patient's medical information. This is represented as an organization.  
  • Outlier is for patient-generated this case, the patient is the custodian.

Care Team

  • Need to address:
    • possibility of noting this at multiple levels (e.g. header vs down in the body)
    • potentially developing a care team template
  • This is a larger discussion than can be reasonably discussed in this quarter. Should be part of any future work to develop guidance or evolve the C-CDA specification.

PQ without Units

  • How to deal with results that do not have a unit of measure?
    • Suggestion is to change the data type to something other than PQ...failing that, the approach in UCUM would be to use "1" for the unit.

List of C-CDA Examples

  • If anyone from the IAT implement-a-thon is interested in 400+ examples of fictional data from real EHRs (and other HIT vendors), here's a link that was used in 2018 research (presented at AMIA 2018) -

Action/Followup Items



Responsible for Follow-up
Results, Assessments, etc.
  • Provide guidance on how results should be shared - i.e. which section in which they should be placed - using results section, assessments section, functional status, grab bag section, etc.

CDA Management group

1/28/2019 - Added to Examples Task Force Trello List

  • Clarify use of INT and EVN mood codes for medication statements with the Pharmacy work group
Jean Duteau
  • Create examples to illustrate medication usage scenarios (e.g. patient reported, clinician observed, etc.)
Examples Task Force
Notes vs. Comment
  • Create examples to differentiate between clinical notes and comments
Examples Task Force
Section Time Range and Limiting Information
  • Request that guidance be updated to illustrate scenarios where information is limited (timing-limited usage scenarios, quantity-limited scenarios, context-limited scenarios, etc.)
CommonWell Health Alliance CareEquality Team (for near-term effort)
  • Follow up regarding the validation of display names
Matt Rahn
Unsuccessful Attempts for Procedures
  • Develop new examples of aborted procedures
Michael Clifton

Header Roles

  • Develop guidance around header roles and act relationship

CDA Management Group

1/28/2019 - Added to Examples Task Force Trello List

Care Team Representation
  • Develop guidance around the representation of a care team...including consideration of whether a Care Team template should be developed

CDA Management Group

1/28/2019 - Added to Examples Task Force Trello List

  • No labels

1 Comment

  1. Jan 28, 2019 - CMG reviewed the Follow-up items assigned to CDA Management Group and agreed to propose these topics for example creation in the CDA Examples Task Force.  Items will be added to the Examples Task Force Trello Board so that participating implementers interested in developing samples can address these needs.