Canonical Pedigree Project

Canonical Pedigree Project Overview

The Canonical Pedigree Project (CPP) was proposed and approved at the HL7 Phoenix meeting of the Clinical Genomics work group in January, 2010. It is intended to improve adoption of the standard V3 pedigree message. It has three aspects:

1. Reference Pedigrees: Provide reference pedigree messages with corresponding text descriptions of the family history. Intended to be a resource for family history collection software verification.
2. Interoperability Testing: The internal storage of a pedigree is up to the host system. Furthermore, some interoperability standards want to represent a pedigree using alternate formats (e.g. CCD, vMR, clinical statements, etc.). The canonical pedigree project shall provide test guidance to verify that host systems and alternate formats are able to accurately maintain the relationships in the reference pedigrees. If full fidelity cannot be maintained, the guidance will help quantify the lost of fidelity.
3. Clinical Power: Many systems provide support only for simplified family histories. For example, they will capture that there were two instances of aunts with breast cancer. That simplified perspective is in contrast with one that maintains maternal vs. paternal line, the number of available aunts and clinical details such as age of onset. The intent behind this facet of CPP is to quantify the clinical benefits of improving the granularity of family and clinical histories.

To learn more about the goals or status of CPP contact the project leader, currently Scott Bolte of GE Heatlhcare.

Interoperability Problems

Technical Equivalence

The adoption of the HL7 Pedigree standard message is inhibited by a lack of interoperability testing. That has lead to multiple systems that are generating incompatible messages. While wider use of the HL7 provided message schema would partially address that problem, there is still a problem verifying when messages are equivalent. Without requiring detailed knowledge of XML, the markup language used to capture a pedigree message, the following examples illustrate the problem.

• Well-Formed: An XML message is said to be well-formed if it conforms to the high-level XML syntax rules. For people unfamiliar with XML, here is a more familiar example of a street address for a letter that would be considered well-formed:

  80 Old Faithful
  John Ranger

• Valid: An XML message is valid if it conforms to a schema definition that dictates the allowed content and ordering of elements. In the previous example, though a person may be able to guess how to send the letter to Mr. Ranger with its well-formed address, the address is actually invalid. The street element improperly comes before the person name element and the state & zip code elements are missing. An address that is both well-formed and valid according to generally accepted schema rules in the United States is:

  John Ranger
  80 Old Faithful Trail
  Yellowstone National Park, WY, 82190

• Equivalent: For interoperability, it is not sufficient that pedigree messages are valid. It is critical to be able to test if two pedigree messages are equivalent. Here are two valid addresses that are subtly different:

  John Ranger
  Old Faithful Visitor Center
  80 Old Faithful Trail
  Yellowstone National Park, WY, 82190

  John Ranger
  80 Old Faithful Trail
  Yellowstone National Park, WY, 82190

It is central to the canonical pedigree project to be able verify generated pedigree messages are equivalent to the reference messages.

Degrees of Equivalence

There are three levels of equivalence testing that needs to be done.

1. First, there is the comparison of two messages where spaces, carriage returns, encoding (e.g. '<' vs. &lt;) is standardized. This should be fairly straightforward.
2. Second, there is comparison where attributes or elements are sorted differently. For example, one system might list the people from oldest to youngest while another does the reverse. Both lists are equivalent, but it is harder to confirm the XML structures are equal.
3. Finally, there are semantic equivalents to test. Niece is equivalent to sister's daughter, but coming up with a system that can correctly discern that will be a challenge.

Reference Pedigrees

The following sample is an elaborated pedigree that supplements the standard specification: Patient has two sisters, a husband a daughter, and a mother and a father (each has two parents): Media:PedigreeSampleElaborated.doc

Clinical Power

The need for detailed family health history can easily be demonstrated. For example, the chart for a 30 year old woman may have the statement "family history of breast cancer -- mother and two aunts". Unfortunately that simple statement is insufficient to distinguish between normal and increased risk.

Here are three scenarios that all fit the original statement:

• Scenario 1 baseline risk for cancer:
  • mother: breast cancer at age 59, died at 62.
  • paternal aunt 1 of 5: breast cancer at 63, died at 69.
  • paternal aunt 2 of 5: breast cancer at 67, died at 75.
  • three maternal aunts (ages 61, 63, 65) with no history of breast or ovarian cancer.
• Scenario 2 likely BRCA1 variation that predisposes carriers to breast, ovarian, and prostate cancer:
  • mother: breast cancer at 38, died at 43.
  • maternal aunt 1 of 2: breast cancer at 37, ovarian cancer at 43, died at 45.
  • maternal aunt 2 of 2: breast cancer at age 42, died at 48.
  • maternal uncle 1 of 1: prostate cancer at age 39, died at 45.
• Scenario 3 more complex picture that includes 3rd degree relatives
  • mother: breast cancer at age 38, died at 43.
  • maternal aunt 1 of 2: breast cancer at 37, ovarian cancer at 43, died at 45.
  • maternal aunt 2 of 2: breast cancer at 42, died of 48.
  • maternal uncle 1 of 1: prostate cancer at age 39, died at 45.