This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

CDA Example Task Force

From HL7Wiki
Jump to navigation Jump to search

SDWG formed the CDA template example task force to collect and share member submitted samples. The task force developed a process with SDWG to receive approval for samples.

The approved samples are posted below.

Contents

Current Task Force Work

Our calls planned for Thursdays 12 PM ET will focus on ... examples. Please join us! 

 Upcoming Weeks
  2/4 – 
      1. Narrative-only Goals Section
      2. Narrative-only Health Concerns Section

       Future: Draft IP Sample - (Normal BMP Results (with Troponin), Functional and Cognitive Impairment, Subcutaneous medication administered with event time)

170.314(b)(2) Transitions of care – create and transmit summary care record sample creation is the current focus of the example task force.

CDA Example Task Force Quality Criteria

Discuss updating samples for C-CDA R2.0/R2.1 to support gold standard

Please contact the SDWG co-chairs (primary Brett Marquard) if you any questions.

Historical reference only: CDA Example Task Force - Previous Review Cycles, CDA Example Task Force Examples - Approved and On Deck

APPROVED EXAMPLES OVERVIEW TABLE

(Click on Table Headers to sort)

http://wiki.hl7.org/index.php?title=CDA_Example_Task_Force
Section Example name Approved C-CDA Examples (github) Comments
ALLERGIES, ADVERSE REACTIONS OR ALERTS No Known Allergies with Author Timestamp This is an example of how an author can record a patient has no known allergies.
ALLERGIES, ADVERSE REACTIONS OR ALERTS No Known Medication Allergies with Author Timestamp This is an example of how an author can record a patient has no known medication allergies.
ALLERGIES, ADVERSE REACTIONS OR ALERTS Allergy to Specific Drug This is an example of an allergy to a specific drug (penicillin) using RxNorm as terminology with information on both allergic reaction and reaction severity. For drug allergies, this example illustrates a good practice of encoding the allergen at the ingredient level (penicillin) not administration level (10 mg tablet). See DSTU 219 for update regarding act/code.
ALLERGIES, ADVERSE REACTIONS OR ALERTS Allergy to Drug Class This is an example of an allergy to a drug class (penicillins) using NDF-RT as terminology with information on both allergic reaction and reaction severity. See DSTU 219 for update regarding act/code.
ALLERGIES, ADVERSE REACTIONS OR ALERTS Propensity to adverse reaction to substance (Latex) This is an example of a propensity to substance allergy with information on both allergic reaction and reaction severity. It was based upon discussion with Russ Leftwich and Lisa Nelson in coordination with Patient Care Committee. See DSTU 219 for update regarding act/code.
ALLERGIES, ADVERSE REACTIONS OR ALERTS Food allergy (Egg) This is an example of a food allergy with information on both allergic reaction and reaction severity. It was based upon discussion with Russ Leftwich and Lisa Nelson in coordination with Patient Care Committee. See DSTU 219 for update regarding act/code
ALLERGIES, ADVERSE REACTIONS OR ALERTS Drug intolerance with multiple reactions (epinephrine) This is an example of a propensity to drug adverse event with information on multiple allergic reactions each with reaction severity. It was based upon discussion with Russ Leftwich and Lisa Nelson in coordination with Patient Care Committee. See DSTU 219 for update regarding act/code.
ALLERGIES, ADVERSE REACTIONS OR ALERTS Drug intolerance with multiple reactions (codeine) This is an example of a propensity to drug adverse event with information on multiple allergic reactions each with reaction severity. It was based upon discussion with Rob Hausam and John D'Amore and Russ Leftwich in coordination with Patient Care Committee. This sample replaces the Epinephrine sample which had less clinical accuracy/relevance. See DSTU 219 for update regarding act/code
ENCOUNTERS Hospital Discharge Encounter with Billable Diagnoses This is an example of an allergy to a specific drug (penicillin) using RxNorm as terminology with information on both allergic reaction and reaction severity. For drug allergies, this example illustrates a good practice of encoding the allergen at the ingredient level (penicillin) not administration level (10 mg tablet). See DSTU 219 for update regarding act/code
Family History Normal Family History; Father deceased with conditions; Mother alive with no conditions Example shows multiple observations for one family member, identifying the cause of death, and a family member with no known problems.
GENERAL PATTERNS No Information Problems Section This is an example of how an author can record a section contains No Information. This is an exceptional case and does not cover 'No Known' scenarios. See No Known Allergies with Author Timestamp (GitHub) for an example of 'No Known'. See DSTU Comment 384
GENERAL PATTERNS No Information Specific Entry within a Section that requires entries This is an example of how an author can record no information about an entry in a section that requires an entry. This pattern is a temporary solution until generic codes are available to identify each entry.
IMMUNIZATIONS Unknown Patient Immunization Status This is an example of how an author can record they do now know whether the patient has received any vaccinations.
MEDICATIONS Patient prescribed oral medication QID PRN without precondition specified This is an example of a medication which is QID and PRN (as needed) but with no precondition specified. It was generated based on SDWG list-serv discussion in December 2013. It also demonstrated a pre-coordinated generic medication coded at the SDC level (generic 600mg Oral Tablet) in RxNorm hierarchy.
  • Additional content - the following file illustrates 3 different medication entries. These examples are meant to illustrate the coding of a medication precondition or indication.
    • Patient prescribed oral medication for pain
      • Summary of examples:
        • PRN with a coded precondition - Ibuprofen 600mg Oral Tablet, 1 tablet Every 6 Hours PRN for joint pain
        • Instructions; similar to above but NOT a PRN - Ibuprofen 600mg Oral Tablet, 1 tablet Every 6 Hours as Directed
        • Indication; again, NOT a PRN - Ibuprofen 600mg Oral Tablet, 1 tablet Every 6 Hours for joint pain.
MEDICATIONS Patient Prescribed Medication Every 4-6 Hours This is an example of a medication (Sudafed) which to be administered every 4-6 hours, a common dosing pattern. Representing the range of potential of hours is done through a low and high child element of the period within effectiveTime of PIVL_TS.
MEDICATIONS Debate continues - see document and comments below - Patient Prescribed Oral Antibiotic with Dosing Regimen that Varies Over Prescription Course (Loading or Tapered) This is an example of a common pattern for antibiotic administration which is complex (double dose on day 1, commonly known as Z-PAK). SDWG reviewed this example with the Pharmacy working group in February 2014. This dosing regimen may be characterized as a loading dose, but a similar approach could be used for a tapered dose as well. At the May 2014 Working Group the committee discussed whether this example would be better with just a free text sig. The committee could not agree on the most appropriate location for the free text so this issue remains open. Use this example with caution until a free text sig is available and included.
MEDICATIONS Single Administration of Medication (at Single Point in Time) This is an example of two baby aspirin being administered at a single point in time. At the January 2014 San Antonio meeting of HL7, this approach was decided as appropriate for medication timing of a point in time. Subsequent to that meeting, the TTT validator was adjusted to accept this format for medication times.
MEDICATIONS No Medications Alternate Opinion: 1 Task Force member voted against approving this samples. In her opinion, the narrative text did not convey the same semantic meaning as the information represented in the structured data. For additional information on this point of view, see the sample titled, "XXXXX" in the "Unapproved Samples" area below.
MEDICATIONS Patient Reported Medication without Reported Brand/Dose Patients often report medications that they are taking, either self-prescribed or by another provider, and know the drug name but do not know any specific brand or dose. This is an example of how to record an herbal supplement (echinicea) that a patient has reported taking using the informant to denote that this is patient reported.
MEDICATIONS Antibiotic Administered with Normal Saline (i.e. in hospital) Many medications administered in hospital are done through IV infusion with another agent. In this example, a loading dose of penicillin is administered via IV infusion with normal saline.
PLAN Of TREATMENT Care Plan Goals Instructions Section 170.314(b)(2) Transitions of care: K) Care Plan (Goals and Instructions)
PROBLEMS Patient with No Known Problems
PROBLEMS Problem which has been resolved/completed This example illustrates how to structure a resolved problem, both by having a biological resolution date and a completed status of the concern.
PROBLEMS Active Problem This example illustrates how to structure an active problem.
PROCEDURES Procedure Activity Procedure Example in Procedures Section This example illustrates how a procedure which "alters the physical state" of the patient and should be classified as a procedure.
PROCEDURES Procedures Activity Observation Example in Procedures Section This example illustrates how an observation within a procedure section.
PROCEDURES Procedure Activity Act Example in Procedures Section This example illustrates an act within a procedure section.
RESULTS Result with less than a specified value This is an example of how to encode "less than" a specific range when returned from lab equipment. The example is for BNP, an immunoassay where the lower threshold for detection is often 5 pg/mL. The lower bound of the interval is zero in this example, even though this is none may be specified, since zero is the lower bound for measures of physical quantity. This example also includes a structured reference range.
RESULTS Result with greater than a specified value This is an example of how to encode "greater than" a specific range when returned from lab equipment. The example is for a point-of-care glucometer, which measures blood sugar for diabetics. Often these devices may have an upper bound, 500 mg/dL is shown in this example. The upper bound of the interval is positive infinity in this example. This example also includes two structured reference ranges for normal and high.
RESULTS Result panel with the display of two ordinal values of negative/positive This is an example of how to encode positive and negative, which are common data types returned form lab equipment. While some technologies may represent this as a type of ST (string), it is logical and easily possible to encode this information using SNOMED-CT. This would allow structured examination of this information downstream as well as comparison to a structured reference range, as shown in the example.
RESULTS Result with an unstructured string as the value (e.g. urine color) This is an example of a value from a lab result that may not be structured.
RESULTS Result Which Requires Translation for its Unit Represented in UCUM This is an example of a value from a lab result that may not be structured.
RESULTS Result with discrete units and non-numeric value This is an example of a value from a lab with a discrete unit, but whose value is not a number, so the PQ datatype, the only type with a unit attribute, cannot be used.
RESULTS Result with a pending component Result with a pending component.
SOCIAL HISTORY - SMOKING Unknown Smoking Status This is an example of unknown smoking status. There is a major variation in how no information is managed for smoking status. C-CDA 1.1 explicitly guides to not utilize a nullFlavor for this information. Instead a SNOMED code should be used as demonstrated in the example. A best practice to avoid confusion is for each social history section to only include a single smoking status.
SOCIAL HISTORY - SMOKING Former Smoker in Smoking Status This is an example of a former smoker in smoking status. There is a variation in how effectiveTime/high is used since this represents when the patient stopped smoking, not when they stopped being a former smoker. C-CDA 1.1 explicitly guides to this usage of effectiveTime. A best practice to avoid confusion is for each social history section to only include a single smoking status.
SOCIAL HISTORY - SMOKING Never Smoker in Smoking Status This is an example of a never smoker in smoking status. A best practice to avoid confusion is for each social history section to only include a single smoking status.
SOCIAL HISTORY - SMOKING Current Smoker in Smoking Status This is an example of current smoking status. This example also includes a coordinating social history observation to convey the amount of smoking using a SNOMED code. This SNOMED code in the accompanying observation is not acceptable since smoking status, which is constrained by HL7 and Meaningful Use value set requirements. A best practice to avoid confusion is for each social history section to only include a single smoking status.
VITAL SIGNS Panel of Vital Signs in Metric Units This is panel of the nine common vital signs collected on an adult in metric units. Note that body surface area (BSA), head circumference and height (lying) are not included.
VITAL SIGNS Panel of Vital Signs in Mixed Metric/Imperial Units This is panel of the nine common vital signs collected on an adult in mixed metric/imperial units. Note that body surface area (BSA), head circumference and height (lying) are not included.
FAMILY HISTORY Normal Family History; Father deceased with conditions; Mother alive with no conditions Example shows multiple observations for one family member, identifying the cause of death, and a family member with no known problems.
FAMILY HISTORY Family History; two individuals with the same relationship to the patient Example shows two brothers with multiple conditions. Though they have the same relationship to the patient, they can be identified by their separation into two family history organizers as well as by their subject ID's.
FAMILY HISTORY Family History; generic history (not scoped to individuals) Example shows generic "family history of x" and "no family history of x" with commentary suggesting better options.
Section Example name Approved C-CDA Examples (github) Comments

Examples - Organized by Section

ALLERGIES, ADVERSE REACTIONS OR ALERTS

No Known Allergies with Author Timestamp

(back to overview table)


No Known Medication Allergies with Author Timestamp

(back to overview table)


Allergy to specific substance (cat hair)

(back to overview table)

  • Approved by: Task force approved 4/10/2014. Withdrawn from consideration since not clinically relevant.
  • C-CDA 1.1 Implementation Guide Example
    • TemplateId(s) illustrated: Allergy Concern Act (2.16.840.1.113883.10.20.22.4.30) and Allergy Intolerance Observation (2.16.840.1.113883.10.20.22.4.7) Reaction Observation (2.16.840.1.113883.10.20.22.4.9) Severity Observation (2.16.840.1.113883.10.20.22.4.8)
    • Allergy to specific substance (cat hair)
  • C-CDA 2.0 Example: none yet posted
  • Known bad example?: Valid example with one error for act/code (based on DSTU 219 and C-CDA IG 2.0 clarification) and warning since severity only nested within reaction
  • Reference to full CDA sample: Allergies in empty CCD
  • Custodian: John D'Amore jdamore@diameterhealth.com (GitHub: jddamore)
  • Validation location: TTT Validator
  • Comments: This is an example of an allergy to a specific substance (cat hair) using UNII as terminology with information on both allergic reaction and reaction severity. See DSTU 219 for update regarding act/code


Allergy to Specific Drug

(back to overview table)

  • Approved by: Task force approved 4/10/2014. Approved by SDWG on 4/24/2014
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 1.1
    • TemplateId(s) illustrated: Allergy Concern Act (2.16.840.1.113883.10.20.22.4.30) and Allergy Intolerance Observation (2.16.840.1.113883.10.20.22.4.7) Reaction Observation (2.16.840.1.113883.10.20.22.4.9) Severity Observation (2.16.840.1.113883.10.20.22.4.8)
    • Allergy to specific drug (penicillin) C-CDA 1.1
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 2.0]
    • TemplateId(s) illustrated: Allergy Concern Act (2.16.840.1.113883.10.20.22.4.30.2) and Allergy Intolerance Observation (2.16.840.1.113883.10.20.22.4.7.2) Reaction Observation (2.16.840.1.113883.10.20.22.4.9.2) Severity Observation (2.16.840.1.113883.10.20.22.4.8.2)
    • Allergy to specific drug (penicillin) C-CDA 1.1
  • Known bad example?: Valid example with one error for act/code (based on DSTU 219 and C-CDA IG 2.0 clarification) and warning since severity only nested within reaction
  • Reference to full CDA sample: Allergies in empty CCD
  • Custodian: John D'Amore jdamore@diameterhealth.com (GitHub: jddamore)
  • Validation location: TTT Validator
  • Comments: This is an example of an allergy to a specific drug (penicillin) using RxNorm as terminology with information on both allergic reaction and reaction severity. For drug allergies, this example illustrates a good practice of encoding the allergen at the ingredient level (penicillin) not administration level (10 mg tablet). See DSTU 219 for update regarding act/code


Allergy to Drug Class

(back to overview table)

  • Approved by: Task force approved 4/10/2014. Approved by SDWG on 4/24/2014.
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 1.1
    • TemplateId(s) illustrated: Allergy Concern Act (2.16.840.1.113883.10.20.22.4.30) and Allergy Intolerance Observation (2.16.840.1.113883.10.20.22.4.7) Reaction Observation (2.16.840.1.113883.10.20.22.4.9) Severity Observation (2.16.840.1.113883.10.20.22.4.8)
    • Allergy to drug class (penicillins)
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 2.0]
    • TemplateId(s) illustrated: Allergy Concern Act (2.16.840.1.113883.10.20.22.4.30.2) and Allergy Intolerance Observation (2.16.840.1.113883.10.20.22.4.7.2) Reaction Observation (2.16.840.1.113883.10.20.22.4.9.2) Severity Observation (2.16.840.1.113883.10.20.22.4.8.2)
    • Allergy to drug class (penicillins)
  • Known bad example?: Valid example with one error for act/code (based on DSTU 219 and C-CDA IG 2.0 clarification) and warning since severity only nested within reaction
  • Reference to full CDA sample: Allergies in empty CCD
  • Custodian: John D'Amore jdamore@diameterhealth.com (GitHub: jddamore)
  • Validation location: TTT Validator
  • Comments: This is an example of an allergy to a drug class (penicillins) using NDF-RT as terminology with information on both allergic reaction and reaction severity. See DSTU 219 for update regarding act/code


Propensity to adverse reaction to substance (Latex)

(back to overview table)

  • Approved by: Task Force approved 4/17/2014, reviewed again on 3/12/2015 TF call. SDWG Approved 3/19/2015.
  • C-CDA 1.1 Implementation Guide Example
    • TemplateId(s) illustrated: Allergy Concern Act (2.16.840.1.113883.10.20.22.4.30) and Allergy Intolerance Observation (2.16.840.1.113883.10.20.22.4.7) Reaction Observation (2.16.840.1.113883.10.20.22.4.9) Severity Observation (2.16.840.1.113883.10.20.22.4.8)
    • Propensity to adverse reaction to substance (Latex)
  • C-CDA 2.0 Example: none yet posted
  • Known bad example?: Valid example with one error for act/code (based on DSTU 219 and C-CDA IG 2.0 clarification) and warning since severity only nested within reaction
  • Reference to full CDA sample: Allergies in empty CCD
  • Custodian: John D'Amore jdamore@diameterhealth.com (GitHub: jddamore)
  • Validation location: TTT Validator
  • Comments: This is an example of a propensity to substance allergy with information on both allergic reaction and reaction severity. It was based upon discussion with Russ Leftwich and Lisa Nelson in coordination with Patient Care Committee. See DSTU 219 for update regarding act/code
Food allergy (Egg)

(back to overview table)

  • Approved by: Task Force approved 4/17/2014, reviewed again on 3/12/2015 TF call. SDWG Approved 3/19/2015.
  • C-CDA 1.1 Implementation Guide Example
    • TemplateId(s) illustrated: Allergy Concern Act (2.16.840.1.113883.10.20.22.4.30) and Allergy Intolerance Observation (2.16.840.1.113883.10.20.22.4.7) Reaction Observation (2.16.840.1.113883.10.20.22.4.9) Severity Observation (2.16.840.1.113883.10.20.22.4.8)
    • Food allergy (Egg)
  • C-CDA 2.0 Example: none yet posted
  • Known bad example?: Valid example with one error for act/code (based on DSTU 219 and C-CDA IG 2.0 clarification) and warning since severity only nested within reaction
  • Reference to full CDA sample: Allergies in empty CCD
  • Custodian: John D'Amore jdamore@diameterhealth.com (GitHub: jddamore)
  • Validation location: TTT Validator
  • Comments: This is an example of a food allergy with information on both allergic reaction and reaction severity. It was based upon discussion with Russ Leftwich and Lisa Nelson in coordination with Patient Care Committee. See DSTU 219 for update regarding act/code
Drug intolerance with multiple reactions (epinephrine)

(back to overview table)

  • Approved by: Task Force approved 4/17/2014; Pulled on block with SDWG since any patient given enough epinephrine will have an intolerance.
  • C-CDA 1.1 Implementation Guide Example
    • TemplateId(s) illustrated: Allergy Concern Act (2.16.840.1.113883.10.20.22.4.30) and Allergy Intolerance Observation (2.16.840.1.113883.10.20.22.4.7) Reaction Observation (2.16.840.1.113883.10.20.22.4.9) Severity Observation (2.16.840.1.113883.10.20.22.4.8)
    • Drug intolerance with multiple reactions (epinephrine)
  • C-CDA 2.0 Example: none yet posted
  • Known bad example?: Valid example with one error for act/code (based on DSTU 219 and C-CDA IG 2.0 clarification) and warning since severity only nested within reaction
  • Reference to full CDA sample: Allergies in empty CCD
  • Custodian: John D'Amore jdamore@diameterhealth.com (GitHub: jddamore)
  • Validation location: TTT Validator
  • Comments: This is an example of a propensity to drug adverse event with information on multiple allergic reactions each with reaction severity. It was based upon discussion with Russ Leftwich and Lisa Nelson in coordination with Patient Care Committee. See DSTU 219 for update regarding act/code
Drug intolerance with multiple reactions (codeine)

(back to overview table)

  • Approved by: Task Force approved 4/17/2014; SDWG Approved 4/16/2015
    • C-CDA 1.1 Implementation Guide Example
    • TemplateId(s) illustrated: Allergy Concern Act (2.16.840.1.113883.10.20.22.4.30) and Allergy Intolerance Observation (2.16.840.1.113883.10.20.22.4.7) Reaction Observation (2.16.840.1.113883.10.20.22.4.9) Severity Observation (2.16.840.1.113883.10.20.22.4.8)
    • Drug intolerance with multiple reactions (codeine)
  • C-CDA 2.0 Example: none yet posted
  • Known bad example?: Valid example with one error for act/code (based on DSTU 219 and C-CDA IG 2.0 clarification) and warning since severity only nested within reaction
  • Reference to full CDA sample: https://github.com/LisaRNelson/LRN_HL7_CDA_Examples/blob/master/Allergy_Intolerance_Observation_Codeine.xml Allergies in empty CCD]
  • Custodian: Lisa R. Nelson LisaRNelson@cox.net (GitHub: lisarnelson)
  • Validation location: TTT Validator
  • Comments: This is an example of a propensity to drug adverse event with information on multiple allergic reactions each with reaction severity. It was based upon discussion with Rob Hausam and John D'Amore and Russ Leftwich in coordination with Patient Care Committee. This sample replaces the Epinephrine sample which had less clinical accuracy/relevance. See DSTU 219 for update regarding act/code

CDA HEADER

Patient demographic information
  • Approved by: Task force approved 9/24/2015. SDWG approved 10/15/2015.
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 1.1
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 2.0
    • Not yet created
  • Known bad example?: Valid example
  • Reference in full CDA Sample: recordTarget Packaged in C-CDA Skeleton
  • Custodian: John D'Amore, jdamore@diameterhealth.com (GitHub: jddamore)
  • Validation location: NIST TTT Message Validator for VDT Ambulatory validated April 23, 2015
  • Keywords: Demographics, Name, Address, Telecom, Phone, Email, Race, Ethnicity, Religious Affiliation, Marital Status, Language
  • Comments: This example illustrates how to structure Patient Demographics for the 170.314(b)(2) Transitions of care – A) Patient Demographics.
Care Team
  • Approved by: Task force approved 6/11/2015. SDWG approved 7/9/2015.
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 1.1
    • TemplateId(s) illustrated: 2.16.840.1.113883.10.20.22.1.1 (serviceEvent and Performer)
    • Care Team
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 2.0
    • Not yet created
  • Known bad example?: Valid example
  • Reference in full CDA Sample:
  • Custodian: George Cole
  • Validation location:
  • Comments: This example illustrates how to structure Care Team for the 170.314(b)(2) Transitions of care – B) Care Team.

ENCOUNTERS

Hospital Discharge Encounter with Billable Diagnoses

(back to overview table)

  • Approved by: Task force approved 12/18/2014; SDWG approved 2/12/2015
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 1.1
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 2.0
    • Not yet created
  • Known bad example?: Valid example (NIST Validator shows error on dischargeDiposition, but look right to me)
  • Reference in full CDA Sample: Results Packaged in C-CDA Skeleton
  • Custodian: John D'Amore, jdamore@diameterhealth.com (GitHub: jddamore)
  • Validation location: NIST TTT Message Validator for VDT Ambulatory validated October 22, 2014
  • Keywords: Hospital Encounter, Discharge Diagnoses, participant, performer
  • Comments: This is an example of a hospitalization with discharge diagnoses. Meaningful Use requires a place to document encounter diagnoses, and this example attempts to satisfy. This example aligns with QRDA suggestion for encounter diagnosis.
Outpatient Encounter with Diagnoses

(back to overview table)

  • Approved by: Task force approved 5/7/2015; SDWG approved
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 1.1
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 2.0
    • Not yet created
  • Known bad example?: Valid example
  • Reference in full CDA Sample: Results Packaged in C-CDA Skeleton with header to match ToC scenario
  • Custodian: Lisa R Nelson, LisaRNelson@cox.net (GitHub: LisaRNelson)
  • Validation location: NIST TTT Message Validator for VDT Ambulatory validated May 13, 2015
  • Keywords: Outpatient Visit, Encounter Diagnoses, performer, visit location
  • Comments: This example illustrates how to structure Encounter Diagnosis for the 170.314(b)(2) Transitions of care - L) Encounter Diagnosis

FUNCTIONAL AND COGNITIVE STATUS

No Impairment

(back to overview table)

  • Status: Approved by task force on 6/18/2015. SDWG approved 7/9/2015
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 1.1
    • TemplateId(s) illustrated: Functional Status Section (2.16.840.1.113883.10.20.22.2.14), Functional Status Problem Observation (2.16.840.1.113883.10.20.22.4.68), Cognitive Status Problem Observation (2.16.840.1.113883.10.20.22.4.73)
    • No Impairment Functional Status Section R1.1 (via GitHub)
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 2.0
    • Not yet completed
  • Known bad example?: Valid example
  • Reference to full CDA sample: No Impairment Functional Status section in empty C-CDA
  • Custodian: John D'Amore jdamore@diameterhealth.com (GitHub: jddamore)
  • Validation location: NIST TTT Validator Ambulatory
  • Comments: This is an example of no functional or cognitive impairment. It only illustrates two of multiple potential templated within the functional status section and was prepared for the 170.314(b)(2) Transitions of care - M) Functional and Cognitive Status. Note that there are significant changes to functional and cognitive status in C-CDA 2.0 and 2.1 (including section breakout and deprecation of certain tempaltes). We may re-visit this sample after reconciliation of such changes.
Functional and Cognitive Status with Impairment

(back to overview table)

  • Status: Not yet approved
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 1.1
    • TemplateId(s) illustrated: Functional Status Section (2.16.840.1.113883.10.20.22.2.14), Functional Status Problem Observation (2.16.840.1.113883.10.20.22.4.68), Cognitive Status Problem Observation (2.16.840.1.113883.10.20.22.4.73)
    • Functional and Cognitive Status with Impairment
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 2.0
    • Not yet completed
  • Known bad example?: Valid example
  • Reference to full CDA sample: Functional and Cognitive Status in full C-CDA Sample
  • Custodian: John D'Amore jdamore@diameterhealth.com (GitHub: jddamore)
  • Validation location: NIST TTT Validator Ambulatory
  • Comments: This is an example of functional and cognitive impairment as outlined in MU2 inpatient test data.

GENERAL PATTERNS

Allergy and Problem Status observation Review - This is a summary of the work done by the example task force to review the extra 'status observations' in C-CDA R1.1 and whether the deprecation in C-CDA R2.0 adequately covers key clinical statuses.

No Information Problems Section

(back to overview table)

No Information Specific Entry within a Section that requires entries

(back to overview table)

  • Status: Task force on 11/20/2014; SDWG Approved on 4/16/2015
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 1.1
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 2.0
    • TemplateId(s) illustrated: Not done yet
    • TBD
  • Known bad example?: Valid example
  • Reference to full CDA sample: TBD
  • Custodian: John D'Amore and Brett Marquard, brett@riverrockassociates.com (GitHub: brettmarquard)
  • Validation location: SITE Validator TOC Ambulatory
  • Comments: This is an example of how an author can record no information about an entry in a section that requires an entry. This pattern is a temporary solution until generic codes are available to identify each entry.

Goals

Goals Section Narrative-only

(back to overview table)

  • Approved by:
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 2.1
  • Known bad example?: Valid example
  • Reference to full CDA sample:
  • Custodian: Brett Marquard, brett@riverrockassociates.com (GitHub: brettmarquard)
  • Validation location: SITE Validator TOC Ambulatory
  • Comments: This is an example of how to send a goals section with only narrative.

Health Concerns

Health Concerns Section Narrative-only

(back to overview table)

  • Approved by:
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 2.1
  • Known bad example?: Valid example
  • Reference to full CDA sample:
  • Custodian: Brett Marquard, brett@riverrockassociates.com (GitHub: brettmarquard)
  • Validation location: SITE Validator TOC Ambulatory
  • Comments: This is an example of how to send a health concern section with only narrative.
Health Concern Linking Example

(back to overview table)

No Known Health Concerns

(back to overview table)

  • Approved by: Task force on 11/5/2015. Approved by SDWG 11/12/2015.
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 2.1
    • TemplateId(s) illustrated: Health Concern Section (2.16.840.1.113883.10.20.22.2.58:2015-08-01) Health Concern Act (2.16.840.1.113883.10.20.22.4.132:2015-08-01)
    • No Known Health Concerns (via GitHub)
  • Known bad example?: Valid example
  • Reference to full CDA sample:
  • Custodian: Brett Marquard, brett@riverrockassociates.com (GitHub: brettmarquard)
  • Validation location: SITE Validator TOC Ambulatory
  • Comments: This is an example of how an author can record they have no health concerns for a patient.

IMMUNIZATIONS

Unknown Patient Immunization Status

(back to overview table)

Influenza Vaccination

(back to overview table)

  • Approved by: Task force on 4/16/2015. SDWG Approved 4/23/2015
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 1.1
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 2.0
    • TemplateId(s) illustrated: Immunization Activity (2.16.840.1.113883.10.20.22.4.52.2)
    • Not Completed
  • Known bad example?: Valid example
  • Reference to full CDA sample: Immunization section in compliant MU2 C-CDA sample
  • Custodian: Brett Marquard, brett@riverrockassociates.com (GitHub: brettmarquard)
  • Validation location: SITE Validator TOC Ambulatory
  • Comments: This example illustrates how to structure Immunizations for the 170.314(b)(2) Transitions of care - J) Immunizations.
Immunization Not Given - Patient Refused

(back to overview table)

  • Approved by: Task force on 10/29/2015. Approved by SDWG 11/12/2015.
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 1.1
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 2.0
    • TemplateId(s) illustrated: Immunization Activity (2.16.840.1.113883.10.20.22.4.52.2)
  • Known bad example?: Valid example
  • Reference to full CDA sample:
  • Custodian: Brett Marquard, brett@riverrockassociates.com (GitHub: brettmarquard)
  • Validation location: SITE Validator TOC Ambulatory
  • Comments: This is an example of how an author can record a patient refused an immunization.

MEDICAL EQUIPMENT

No Implanted Devices

(back to overview table)

  • Approved by: Task Force Approved 12/15/15.
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 2.1
    • TemplateId(s) illustrated: Medical Equipment Section (V2) (2.16.840.1.113883.10.20.22.2.23:2014-06-09) and Procedure Activity Procedure (V2) (2.16.840.1.113883.10.20.22.4.14:2014-06-09 )
    • No Implanted Devices - No UDI (via GitHub)
  • Known bad example?: Valid example
  • Reference to full CDA sample:
  • Custodian: Brett Marquard, brett@riverrockassociates.com (GitHub: brettmarquard)
  • Validation location: SITE Validator TOC Ambulatory
  • Comments: This is an example of how an author can record a patient has no implanted devices

MEDICATIONS

For all Medication examples the example task force agreed (8/28/2014) to only include institutionSpecified on the effectiveTime when the value is true. InstitutionSpecified indicates whether the exact timing is up to the party executing the schedule (e.g., to distinguish "every 8 hours" (false) from "3 times a day" (true)).

Medication Frequencies Approved 9/17/2014 at Chicago WG

(keywords: bid, two times daily; q12h, every 12 hours; tid, three times daily; q8h, every 8 hours; qid, four times daily; q6h, every 6 hours; qd, daily; q24h, every 24 hours; qod, every other day; qm, Once a month; Every other week; 1 hour after meal; before dinner; before lunch (from lat. ante cibus diurnus))

Medication statusCodes Approved on 2/19/2015 SDWG call.

Patient prescribed oral medication QID PRN without precondition specified

(back to overview table)

  • Approved by: Task force on 1/9/2014. Task force approved 1/16/2014
  • C-CDA 1.1 Implementation Guide Example
  • C-CDA 2.0 Example: none yet posted
  • Known bad example?: Valid example when PRN but no precondition specified
  • Reference in full CDA Sample: Results Packaged in C-CDA Skeleton
  • Custodian: John D'Amore, jdamore@diameterhealth.com (GitHub: jddamore)
  • Validation location: NIST TTT Message Validator for VDT Ambulatory validated December 18, 2013
  • Keywords: Precondition, Pre-coordinated medication code, dose frequency
  • Comments: This is an example of a medication which is QID and PRN (as needed) but with no precondition specified. It was generated based on SDWG list-serv discussion in December 2013. It also demonstrated a pre-coordinated generic medication coded at the SDC level (generic 600mg Oral Tablet) in RxNorm hierarchy.
    • Additional content - the following file illustrates 5 different medication entries. These examples are meant to illustrate the coding of a medication precondition or indication.
      • Patient prescribed oral medication for pain
        • Summary of examples:
        • PRN with a coded precondition - Ibuprofen 600mg Oral Tablet, 1 tablet Every 6 Hours PRN for joint pain
        • Instructions; similar to above but NOT a PRN - Ibuprofen 600mg Oral Tablet, 1 tablet Every 6 Hours as Directed
        • Indication; again, NOT a PRN - Ibuprofen 600mg Oral Tablet, 1 tablet Every 6 Hours for joint pain
Patient Prescribed Medication Every 4-6 Hours

(back to overview table)

  • Approved by: Task force 1/30/2014. Approved by SDWG on 2/6/2014.
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 1.1
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 2.0
  • Known bad example?: Valid example
  • Reference in full CDA Sample: Results Packaged in C-CDA Skeleton
  • Custodian: John D'Amore, jdamore@diameterhealth.com (GitHub: jddamore)
  • Validation location: NIST TTT Message Validator for VDT Ambulatory validated February 12, 2014
  • Keywords: Dose frequency, pre-coordinated medication
  • Comments: This is an example of a medication (Sudafed) which to be administered every 4-6 hours, a common dosing pattern. Representing the range of potential of hours is done through a low and high child element of the period within effectiveTime of PIVL_TS.


Debate continues - see document and comments below - Patient Prescribed Oral Antibiotic with Dosing Regimen that Varies Over Prescription Course (Loading or Tapered)

(back to overview table)

  • Previously, approved by: Task force on 3/6. Approved by SDWG on 4/10/2014.
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 1.1
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 2.0
  • Known bad example?: Valid example
  • Reference in full CDA Sample: Results Packaged in C-CDA Skeleton
  • Custodian: John D'Amore, jdamore@diameterhealth.com (GitHub: jddamore)
  • Validation location: NIST TTT Message Validator for VDT Ambulatory validated February 12, 2014
  • Keywords: Pre-coordinated medication code, dose frequency, tapered dose, loading dose
  • Comments: This is an example of a common pattern for antibiotic administration which is complex (double dose on day 1, commonly known as Z-PAK). SDWG reviewed this example with the Pharmacy working group in February 2014. This dosing regimen may be characterized as a loading dose, but a similar approach could be used for a tapered dose as well. At the May 2014 Working Group the committee discussed whether this example would be better with just a free text sig. The committee could not agree on the most appropriate location for the free text so this issue remains open. Use this example with caution until a free text sig is available and included.


Patient prescribed basal insulin administered at bedtime

(back to overview table)


Single Administration of Medication (at Single Point in Time)

(back to overview table)

    • Approved by: Task force on 3/13. Approved by SDWG on 4/10/2014.
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 1.1
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 2.0
  • Known bad example?: Valid example
  • Reference in full CDA Sample: Results Packaged in C-CDA Skeleton
  • Custodian: John D'Amore, jdamore@diameterhealth.com (GitHub: jddamore)
  • Validation location: NIST TTT Message Validator for VDT Ambulatory validated October 16, 2014
  • Keywords: Pre-coordinated medication code, single administration, point in time
  • Comments: This is an example of two baby aspirin being administered at a single point in time. At the January 2014 San Antonio meeting of HL7, this approach was decided as appropriate for medication timing of a point in time. Subsequent to that meeting, the TTT validator was adjusted to accept this format for medication times.


No Medications

(back to overview table)

  • Approved by: Task force on 3/13. Approved by SDWG on 4/10/2014.
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 1.1
    • TemplateId(s) illustrated: Medication Activity (2.16.840.1.113883.10.20.22.4.16)
    • No Medications R1.1
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 2.0
    • TemplateId(s) illustrated: Medication Activity (2.16.840.1.113883.10.20.22.4.16.2)
    • No Medications R2
  • Known bad example?: Valid example
  • Reference to full CDA sample: No Medications in compliant MU2 C-CDA R1.1 sample
  • Custodian: Brett Marquard, brett@riverrockassociates.com (GitHub: brettmarquard)
  • Validation location: SITE Validator TOC Ambulatory
  • Comments: .
  • Alternate Opinion: 1 Task Force member voted against approving this samples. In her opinion, the narrative text did not convey the same semantic meaning as the information represented in the structured data. For additional information on this point of view, see the sample titled, "XXXXX" in the "Unapproved Samples" area below.


Patient Reported Medication without Reported Brand/Dose

(back to overview table)

  • Approved by: Not yet approved
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 1.1
  • C-CDA 2.0 Example: none yet created
  • Known bad example?: Valid example
  • Reference to full CDA sample: Medications in skeleton CCD
  • Custodian: John D'Amore jdamore@diameterhealth.com GitHub: jddamore)
  • Validation location: NIST TTT VDT Ambulatory validated June 4, 2014
  • Comments: Patients often report medications that they are taking, either self-prescribed or by another provider, and know the drug name but do not know any specific brand or dose. This is an example of how to record an herbal supplement (echinicea) that a patient has reported taking using the informant to denote that this is patient reported.


Antibiotic Administered with Normal Saline (i.e. in hospital)

(back to overview table)

  • Approved by: Not yet approved
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 1.1
  • C-CDA 2.0 Example: none yet created
  • Known bad example?: Valid example. Returns one warning since no PIVL_TS or EIVL_TS included
  • Reference to full CDA sample: Medications in skeleton CCD
  • Custodian: John D'Amore jdamore@diameterhealth.com GitHub: jddamore)
  • Validation location: NIST TTT VDT Ambulatory validated June 4, 2014
  • Comments: Many medications administered in hospital are done through IV infusion with another agent. In this example, a loading dose of penicillin is administered via IV infusion with normal saline.

PLAN OF TREATMENT

This section was previously named Plan of Care.

Care Plan Goals Instructions Section

(back to overview table)

  • Approved by: Task force approved August 20, 2015. SDWG Approved 9/10/2015.
  • C-CDA 1.1 Implementation Guide Example
  • C-CDA 2.0 Example: None yet posted
  • Reference to full CDA sample:
  • Custodian: Lisa Nelson
  • Validation location:
  • Comments: This example illustrates how to structure a Goals and Instructions for the 170.314(b)(2) Transitions of care - K) Care Plan (Goals and Instructions).
Planned EKG

(back to overview table)

  • Approved by: Task Force Approved 11/25/15
  • C-CDA 1.1 Implementation Guide Example
    • TemplateId(s) illustrated: Plan of Care Activity Observation
    • Planned EKG
  • C-CDA 2.0 Example: None yet posted
  • Reference to full CDA sample:
  • Custodian: Brett Marquard
  • Validation location:
  • Comments: This example illustrates how to structure a planned observation.
Planned Encounter (Referral)

(back to overview table)

  • Approved by: Task force 9/24/2015, SDWG 10/15/2015
  • C-CDA 1.1 Implementation Guide Example
    • TemplateId(s) illustrated: Plan of Care Activity Encounter
    • Referral
  • C-CDA 2.0 Example: None yet posted
  • Reference to full CDA sample:
  • Custodian: George Cole
  • Validation location:
  • Comments: This example illustrates how to structure a Referral for the 170.314(b)(2) Transitions of care - N) Referral

PROBLEMS

Patient with No Known Problems

(back to overview table)

Patient with No Known Diabetes

(back to overview table)

  • Approved by: Task force on 11/5/2015. Approved by SDWG 11/12/2015.
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 1.1
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 2.0
    • TemplateId(s) illustrated: Problem Section, Problem Concern Act, Problem Observation
  • Known bad example?: Valid example
  • Reference to full CDA sample: Full Sample No Known Problems
  • Custodian: Brett Marquard
  • Validation location: TTT VDT Ambulatory
  • Comments:
Problem which has been resolved/completed

(back to overview table)

Active Problem

(back to overview table)

PROCEDURES

Procedure Activity Procedure Example in Procedures Section

(back to overview table)


Procedures Activity Observation Example in Procedures Section

(back to overview table)


Procedure Activity Act Example in Procedures Section

(back to overview table)

RESULTS

Result with less than or equal to a specified value

(back to overview table)

Result with greater than a specified value

(back to overview table)

  • Approved by: Based on SDWG request from Kumara February 2014. Approved on SDWG 3/19/2015. Minor edits (inclusive attribute) and scheduled for re-vote 10/29/2015. Approved by SDWG 11/12/2015.
  • C-CDA 1.1 Implementation Guide Example
  • C-CDA Example: none yet posted
  • Known bad example?: Valid example
  • Reference to full CDA sample: Not yet completed
  • Custodian: John D'Amore, jdamore@diameterhealth.com (GitHub: jddamore)
  • Validation location: Not yet validated
  • Comments: This is an example of how to encode "greater than" (but not equal to) a specific range when returned from lab equipment. The example is for a point-of-care glucometer, which measures blood sugar for diabetics. Often these devices may have an upper bound, 500 mg/dL is shown in this example. An inclusive tag of false is shown to demonstrate a non-inclusive range. The upper bound of the interval is positive infinity in this example. This example also includes two structured reference ranges for normal and high.
Result panel with the display of two ordinal values of negative/positive

(back to overview table)


Result with an unstructured string as the value (e.g. urine color)

(back to overview table)

Result Which Requires Translation for its Unit Represented in UCUM

(back to overview table)


Result with discrete units and non-numeric value

(back to overview table)


Result with a pending component

(back to overview table)

Result of CO2 Test

(back to overview table)

Results of Basic Metabolic Panel and Troponin (MU2 Example)

(back to overview table)

PAYER

Coverage Activity referencing the holder's employer

(back to overview table)


SOCIAL HISTORY (SMOKING)

Unknown Smoking Status

(back to overview table)

  • Approved by: Task Force Approved 6/26; Approved by SDWG 7/03/14
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 1.1
    • TemplateId(s) illustrated: Social History Section (2.16.840.1.113883.10.20.22.2.17) Smoking Status (2.16.840.1.113883.10.20.22.4.78)
    • Unknown Smoking Status
  • C-CDA 2.0 Example: none yet created
  • Known bad example?: Valid example.
  • Reference to full CDA sample: Social History (Smoking Status)in skeleton CCD
  • Custodian: John D'Amore jdamore@diameterhealth.com (GitHub: jddamore)
  • Validation location: NIST TTT VDT Ambulatory validated June 11, 2014
  • Comments: This is an example of unknown smoking status. There is a major variation in how no information is managed for smoking status. C-CDA 1.1 explicitly guides to not utilize a nullFlavor for this information. Instead a SNOMED code should be used as demonstrated in the example. A best practice to avoid confusion is for each social history section to only include a single smoking status.


Former Smoker in Smoking Status

(back to overview table)

  • Approved by: Task Force Approved 6/26; Approved by SDWG 7/03/14
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 1.1
    • TemplateId(s) illustrated: Social History Section (2.16.840.1.113883.10.20.22.2.17) Smoking Status (2.16.840.1.113883.10.20.22.4.78)
    • Former Smoking Status
  • C-CDA 2.0 Example: none yet created
  • Known bad example?: Valid example.
  • Reference to full CDA sample: Social History (Smoking Status)in skeleton CCD
  • Custodian: John D'Amore jdamore@diameterhealth.com (GitHub: jddamore)
  • Validation location: NIST TTT VDT Ambulatory validated June 11, 2014
  • Comments: This is an example of a former smoker in smoking status. There is a variation in how effectiveTime/high is used since this represents when the patient stopped smoking, not when they stopped being a former smoker. C-CDA 1.1 explicitly guides to this usage of effectiveTime. A best practice to avoid confusion is for each social history section to only include a single smoking status.


Never Smoker in Smoking Status

(back to overview table)

  • Approved by: Task Force Approved 6/26; Approved by SDWG 7/03/14
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 1.1
    • TemplateId(s) illustrated: Social History Section (2.16.840.1.113883.10.20.22.2.17) Smoking Status (2.16.840.1.113883.10.20.22.4.78)
    • Never Smoker Status
  • C-CDA 2.0 Example: none yet created
  • Known bad example?: Valid example.
  • Reference to full CDA sample: Social History (Smoking Status)in skeleton CCD
  • Custodian: John D'Amore jdamore@diameterhealth.com (GitHub: jddamore)
  • Validation location: NIST TTT VDT Ambulatory not yet validated
  • Comments: This is an example of a never smoker in smoking status. A best practice to avoid confusion is for each social history section to only include a single smoking status.


Current Smoker in Smoking Status

(back to overview table)

  • Approved by: Task Force Approved 6/26; Approved by SDWG 7/03/14
  • CDA Implementation Guide where template(s) is(are) defined: C-CDA 1.1
    • TemplateId(s) illustrated: Social History Section (2.16.840.1.113883.10.20.22.2.17) Smoking Status (2.16.840.1.113883.10.20.22.4.78)
    • Current Smoking Status
  • C-CDA 2.0 Example: none yet created
  • Known bad example?: Valid example.
  • Reference to full CDA sample: Social History (Smoking Status)in skeleton CCD
  • Custodian: John D'Amore jdamore@diameterhealth.com (GitHub: jddamore)
  • Validation location: NIST TTT VDT Ambulatory validated June 11, 2014
  • Comments: This is an example of current smoking status. This example also includes a coordinating social history observation to convey the amount of smoking using a SNOMED code. This SNOMED code in the accompanying observation is not acceptable since smoking status, which is constrained by HL7 and Meaningful Use value set requirements. A best practice to avoid confusion is for each social history section to only include a single smoking status.

VITAL SIGNS

Panel of Vital Signs in Metric Units

(back to overview table)

  • Approved by: Task force approved May 30, 2014. SDWG approved June 5, 2014
  • C-CDA 1.1 Implementation Guide Example
    • TemplateId(s) illustrated: Vital Sign Organizer 2.16.840.1.113883.10.20.22.4.26, Vital Sign Observation 2.16.840.1.113883.10.20.22.4.27
    • Vital sign panel in metric units
  • C-CDA 2.0 Implementation Guide Example: none yet posted
  • Custodian: John D'Amore, jdamore@diameterhealth.com (GitHub: jddamore)
  • Validation location: NIST TTT Message Validator for VDT Ambulatory validated May 29, 2014
  • Reference to full CDA sample: Vital Signs in C-CDA Skeleton
  • Comments: This is panel of the nine common vital signs collected on an adult in metric units. Note that body surface area (BSA), head circumference and height (lying) are not included.


Panel of Vital Signs in Mixed Metric/Imperial Units

(back to overview table)

  • Approved by: Task force approved May 30, 2014. SDWG approved June 5, 2014
  • C-CDA 1.1 Implementation Guide Example
    • TemplateId(s) illustrated: Vital Sign Organizer 2.16.840.1.113883.10.20.22.4.26, Vital Sign Observation 2.16.840.1.113883.10.20.22.4.27
    • Vital Sign panel with mixed units
  • C-CDA 2.0 Implementation Guide Example: none yet posted
  • Reference to full CDA sample: Vital Signs in C-CDA Skeleton
  • Custodian: John D'Amore, jdamore@diameterhealth.com (GitHub: jddamore)
  • Validation location: NIST TTT Message Validator for VDT Ambulatory validated May 29, 2014
  • Comments: This is panel of the nine common vital signs collected on an adult in mixed metric/imperial units. Note that body surface area (BSA), head circumference and height (lying) are not included.

FAMILY HISTORY

Normal Family History; Father deceased with conditions; Mother alive with no conditions

(back to overview table)

  • Approved by: Task force approved 1/15/2015; SDWG approved 2/19/2015
  • C-CDA 2.0 (link to CDA Implementation Guide, when available) Implementation Guide Example
    • TemplateId(s) illustrated: Family History Organizer (2.16.840.1.113883.10.20.22.4.45 2015-06-09), Family History Observation (2.16.840.1.113883.10.20.22.4.46 2015-06-09), Age Observation (2.16.840.1.113883.10.20.22.4.31), Family History Death Observation (2.16.840.1.113883.10.20.22.4.47)
    • Family History Section
  • Known bad example?: No
  • Reference to full CDA sample:
  • Custodian: Benjamin Flessner, benjamin@epic.com (GitHub: benjaminflessner)
  • Validation location: C-CDAR2 schema and schematron
  • Comments: Example shows multiple observations for one family member, identifying the cause of death, and a family member with no known problems.
Family History; two individuals with the same relationship to the patient

(back to overview table)

  • Approved by: Task force approved 2/12/2015, SDWG approved 2/12/2015
  • C-CDA 2.0 (link to CDA Implementation Guide, when available) Implementation Guide Example
    • TemplateId(s) illustrated: Family History Organizer (2.16.840.1.113883.10.20.22.4.45 2015-06-09), Family History Observation (2.16.840.1.113883.10.20.22.4.46 2015-06-09)
    • Family History Section (Two Brothers)
  • Known bad example?: No
  • Reference to full CDA sample:
  • Custodian: Benjamin Flessner, benjamin@epic.com (GitHub: benjaminflessner)
  • Validation location: C-CDAR2 schema and schematron
  • Comments: Example shows two brothers with multiple conditions. Though they have the same relationship to the patient, they can be identified by their separation into two family history organizers as well as by their subject ID's.
Family History; generic history (not scoped to individuals)

(back to overview table)

  • Approved by: Task force approved 2/12/2015, SDWG approved 2/19/2015
  • C-CDA 2.0 (link to CDA Implementation Guide, when available) Implementation Guide Example
    • TemplateId(s) illustrated: Family History Organizer (2.16.840.1.113883.10.20.22.4.45 2015-06-09), Family History Observation (2.16.840.1.113883.10.20.22.4.46 2015-06-09)
    • Family History Section (Generic History)
  • Known bad example?: Not "bad" but sub-optimal.
  • Reference to full CDA sample:
  • Custodian: Benjamin Flessner, benjamin@epic.com (GitHub: benjaminflessner)
  • Validation location: C-CDAR2 schema and schematron
  • Comments: Example shows generic "family history of x" and "no family history of x" with commentary suggesting better options.

Formatting of CDA Template Samples

PROTOTYPIC TEMPLATE

Meaningful template example name

Resources and Draft materials

Link to C-CDA 1.1 testing script


C-CDA Empty shell that will validate without errors using NIST TTT.


KNOWN BAD EXAMPLES

  • Future bad examples will go here.

FEEDBACK AND AWAITING RESPONSE

  • Result with less than a specified value (via GitHub)- Awaiting review from Patrick Lloyd with OO

COMMUNITY REQUESTS FOR EXAMPLES (include name, email)

  • I would like an example of a preliminary lab result (John Doe, JohnDoe@email.com)
  • The SMART C-CDA Collaborative generated a list of approximately 50 requested samples here. See the section noted as "Annotated Examples." For more information on the SMART C-CDA Collaborative please visit here. (Ashley Swain, ashley.swain@lantanagroup.com, John D'Amore, jdamore@diameterhealth.com, Josh Mandel, jmandel@gmail.com)


DRAFT MATERIAL - PLEASE DON'T DELETE

How to Setup an XML example from GitHub

  • Sign up for GitHub account. It's free and quick
  • Once you've got an account, you will be able to fork repositories and comment on examples through the website
  • To post and manage examples, you will likely want to install a graphical user interface for GitHub. Here's where you can download: For Windows or For Mac
  • Once you've got the application installed, there are a few steps:
    • Click the "create" button to make a repository where you would like to upload/update to GitHub
    • Once you've created, the repository will exist online and on your local machine
    • On your local machine, place in new or revised files in the local folder (this will generally be under Documents/GitHub). It's good practice to include a text file named README.md, which appears online when people browse your repository. This is a good place to explain what you're working on.
    • Once you've made the edits (or new files) you want to post to GitHub, "commit" the sample entering a description and then hit the "sync" button to upload
    • At this point the changes and new files are posted online publicly
  • For an example GitHub repository with C-CDA samples, check out this one from Children's Hospital Boston


  • Add instructions for how to upload examples (to github, to other sites)
    • Add examples (to site of your choosing)
    • Add link and metadata too
  • enumerated lists
    • validators
    • approving bodies
      • SDWG
      • Infoway
      • NHS


HOW TO PREPARE A SAMPLE FOR APPROVAL BY SDWG

Observing these guidelines will streamline the process for all involved.

  • Include XML comments that will:
    • Make assumptions explicit
    • Annotate each lines
    • Highlight choices and key decisions that were made
  • Confirm statusCode/moodCode/effectiveTime are in agreement
  • Snippet should be in the context of a section
  • Confirm narrative to match entries - and content is linked
  • Does final sample name accurately reflect the final sample
  • Add disclaimer at the top of every sample: SAMPLE DEVELOPED BY HL7 SDWG SAMPLES TASK FORCE - PLEASE SEE http://wiki.hl7.org/index.php?title=CDA_Example_Task_Force FOR ADDITIONAL DETAILS
  • Copy and paste the template below, and complete for your sample
  • Allergy to Substance X
    • Approved by: SDWG (Oct 31, 2013); NHS (Oct 31, 2013)
    • TemplateId(s) illustrated: 2.16.840.1.113883.10.20.22.4.30; 2.16.840.1.113883.10.20.22.4.7
    • CDA Implementation Guide where template(s) is(are) defined: C-CDA R2
    • Reference to full CDA sample: N/A
    • Custodian: John Doe (John.Doe@email.com)
    • Validation location: validator.com
    • Comments: This is the best example EVER!


Under Development -

Complaint of no foot pain - Problem Section

(back to overview table)


Under Development -

No Complaint of foot pain - Problem Section

(back to overview table)

Retrieved from "https://wiki.hl7.org/w/index.php?title=CDA_Example_Task_Force&oldid=114589"