Canonical Pedigree Project

Call For Participation

As of January, 2011, the project has the blessing of the HL7 Technical Steering Committee. It's time to kick it into high gear.

If you would like to participate, on either the technical end -- the aspects dealing with XML, HL7 messages, XML tools -- or the clinical end -- creating relevant family health histories, and dealing with the inevitable ambiguity -- there are two things you need to do. Sign up for the Clinical Genomics mailing list and send a mail message to Scott Bolte, the project leader.

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 Healthcare.

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.

All three of the following scenarios fit the original statement. Pedigrees and risk scores courtesy of Hughes Risk Apps.

Scenario 1

Patient:	Janet White
Case Summary:	baseline risk for cancer
Detailed History	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.
Mutation Risk:	BRCAPRO 0.4%, Myriad 1.5%
Lifetime Risk:	BRCAPRO 11.8%, Claus 11.4%

Scenario 2

Patient:	Jane Green
Case Summary:	likely BRCA1 variation that predisposes carriers to breast, ovarian, and prostate cancer
Detailed History	mother: breast cancer at 38, died at 43. maternal aunt 1 of 2: breast cancer at 37, 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.
Mutation Risk:	BRCAPRO 35%, Myriad 5.6%
Lifetime Risk:	BRCAPRO 29%, Claus 40.1%

Scenario 3

Patient:	Jane Black
Case Summary:	more complex picture that includes 3rd degree relatives
Detailed History	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. 1st daughter: age 32, no known cancer. 2nd daughter: breast cancer at age 30, died at 32. maternal uncle 1 of 1: prostate cancer at age 39, died at 45.
Mutation Risk:	BRCAPRO 46%, Myriad 5.6%
Lifetime Risk:	BRCAPRO 34%, Claus 40.1%

If you compare scenarios 1 and 2, it is quite clear that the age of onset of the disease shifted from the 60's to around 40. Similarly, scenario 1 had the incidences of cancer split across family lines, and amongst a large group of siblings. In contrast, scenario 2 was all on one side, and 100% disease penetration included both the three sisters and their brother. A knowledgeable clinician will recognize the first scenario is likely just sporadic cancers that are not terribly surprising given the patients' ages while the second shouts out there is a genetic component.

Now the first two scenarios were crafted to highlight the hazard of drawing conclusions from a simplified family history. However, it is the third situation that is more likely, and more difficult to assess without decision support. By the time 3rd degree relatives are included it becomes quite difficult to assess risk by hand. However, the high clinical value to patients makes it clear that collecting, analyzing, and acting upon a detailed structured family history is worth improving.