Canonical Pedigree Project
Contents
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:
- 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.
- 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.
- 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. As of early 2010, 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 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 Yellowstone National Park, WY, 82190
John Ranger 80 Old Faithful 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.
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
Meeting Minutes
2010-03-23 - Kick off call, Pedigree plan
Summary:
- Canonical Pedigree Project overview
- Review of short term release schedules for interested parties
- Outline of reference pedigrees to be completed by end of month.
- Ad hoc mailing list to be used until formal list created.
