HL7 Family History IG US Realm



[pic]

HL7 Clinical Genomics Work Group

The Family History Standard –

Implementation Guide

(US Realm)

November 2627, 2012

Pedigree R1 Co-Editors:

Dr. Amnon Shabo (Shvo)[1]

Dr. Kevin S. Hughes[2]

US Realm IG Co-Editors:

Dr. Amnon Shabo (Shvo)

Mollie H. Ullman-Cullere

Yan Heras

Nnamdi Ihuegbu

Grant M. Wood

© 2011 Health Level Seven, Inc.

Ann Arbor, MI

All rights reserved.

Table of Contents

HL7 Clinical Genomics Work Group 1

The Family History Standard – Implementation Guide 1

DRAFT – November 26, 2012 1

Table of Contents 2

Table of Figures 4

Table of Tables 5

1 Introduction 6

2 storyboards 7

2.1 Cancer - BRCA 7

2.1.1 Storyboard Presentation 7

3 Sample Pedigrees 11

3.1 Breast / Ovarian Cancer – BRCA1/2 11

3.1.1 Annie Proband: 11

3.2 (PKU) - 12

3.2.1 Indiviual with PKU: 12

3.3 < Dominantly Inherited Hypertrophic Cardiomyopathy (HCM) - 12

3.3.1 Indiviual with Dominantly Inherited Hypertrophic Cardiomyopathy: 12

3.4 < X-linked Dialated Cardiomyopathy (DCM) - 13

3.4.1 Indiviual with an X-linked Dilated Cardiomyopathy: 13

4 The Family history model 15

4.1 Model Walkthrough 15

4.1.1 Entry Point - FamilyHistory 15

4.1.2 Patient & Person 16

4.1.3 Clinical Data 16

4.1.4 Genetic Data 16

4.1.5 Informant 17

4.1.6 Relative 17

4.1.7 subjectOf2 Shadow 18

4.1.8 Person and Relative 18

4.1.9 Relative’s Mother and Father Identifiers 19

5 vocabularies 21

5.1 Family Relationships 21

5.2 Age Attributes 21

5.2.1 Age at Death 21

5.2.2 Age of Onset of Disease 21

5.2.3 Age of Living Subject 21

5.3 Race 22

5.4 Ethnicity 22

6 Exchange of family health history 23

appendix a: The family history (Pedigree) model 26

appendix B: hierarchical vs. flat representation 28

appendix C: xml schema and samples 30

appendix D: HITSP specifications on personalized healthcare 31

Appendix E: Genetic Data Represenation 34

Table of Figures

Figure 1: Common Visualization of a Family Health History: Breast Ovarian Cancer Syndrome 11

Figure 2: Common Visualization of a Family Health History: PKU 12

Figure 3: Common Visualization of a Family Health HIstory: Dominantly Inherited Hypertrophic Cardiomyopathy 13

Figure 4: Common Visualization of a Family Health History: X-linked Dilated Cardiomyopathy 14

Figure 5: The Recursive Association of Person and Relative Which Enables a Hierarchical Representation of a Pedigree to Any Depth Needed 19

Figure 6: The Family History (Pedigree) Model 26

Figure 8: Construct Personal and Family Health History & Pedigree 31

Figure 9: Scenario 1: Clinical Assessment Component Data Flow Diagram 32

Table of Tables

Table 1: Outline for Family History of a Cancer Patient 7

Table 2: Age at Death 23

Table 3: Age of Onset of Disease 23

Table 4: Age of Living Object 23

Table 5: Race Value Set (excerpt) 24

Table 6: Ethnicity Value Set 24

Table 7: Personal Relationship Role Type Value Set (excerpt) 24

Introduction

A number of family history applications are in use by health care professionals (e.g., HughesRiskApps, CAGENE, Progeny) as well as by patients (e.g., the US Surgeon General’s My Family Health Portrait. Several of these have application-specific proprietary data formats for pedigree drawing and for the maintenance of family history health information; howeverwhile others are compliant with an international family history standard, for example, HughesRiskApps (available at: ) and the US Surgeon General’s My Family Health Protrait (available at: ) use an ANSI approved HL7 data standard. The benefits for using a proven data standard are many, including interoperability and an information model proven effective in clinical setting for patient care and clinical decision making.

Interoperability between applications had been essentially non-existent. In 2007, the HL7 Pedigree/Family History standard (codename “Pedigree R1”) was approved by ANSI as a normative specification, and thus disparate family history applications can now easily exchange patient information. The receiving application can understand the semantics of the incoming family history and enable the user to view and/or to edit that data using the receiving application’s interface.

In the United States, the Office of the National Coordination (ONC) of Health Information and Technology published Family History data requirements, developed by a multi-stakeholder workgroup which further defines the HL7 Pedigree/Family History standard. Additionally, the ONC Personalized Healthcare Use Case implementation includes recommendations illustrating the use of Family family History health history in the clinical workflow. These documents can be found at:

This standard has been developed in parallel with clinical pilots and the ONC multi-stakeholder initiatives, providing a robust model for adoption. The HL7 Pedigree/Family History standard model proved effective in the identification of patients with increased familial risk of disease within multiple diverse settings (e.g. public use at home, genetic testing laboratory, clinican’s office, mammography center) and disease areas (e.g. cardiology, cancer and prenatal/ObGyn).

This US-Realm specific Family History Implementation Guide (IG) of is based on the Pedigree/Family History R1 standard and provides guidance on the use of the standard in the US by illustrating the preferred representation formats of key data elements such as genetic findings and clinical data. This guide also provides guidance on the exchange mechanism of family health data. Note that the HL7 Clinical Genomics Work Group works with the HHS in order for this guidance included in this IGto accommodates the US Meaningful Use requirements regarding family health history. In this first release of the US Guide, the guidance relates supportsto demographcdemographic and clinical data, as well as certain types of genetic data and risk assessment.

storyboards

This section describes scenarios where family health history is used and enables implementers to better understand the clinical workflow in which family history is integrated for patient care.

1 Cancer - BRCA

The objective of this storyboard is to illustrate the way a patient's pedigree/family health history is used for risk analysis of breast and ovarian cancers and other diseases. It extends the broader breast cancer story board and includes a sample outline for the patient's pedigree/family history.

1. Storyboard Presentation

1. Ms. Eve Everywoman has a family history of breast and ovarian cancer, and she is not of Ashkenazi Jewish descent.

2. She believes she is at high risk of developing breast cancer.

3. She goes to see her clinician (Medical oncologist, surgical oncologist, radiation oncologist, primary care provider) who takes a thorough family history. This history is recorded in the chart and the electronic medical record.

4. The clinician reviews the family history, decides what genetic syndrome her family might have, and categorizes the patient as to degree of risk (Perhaps high, medium, or low risk). The clinician thinks the patient is at high risk of having a BRCA1/2 mutation (i.e. sequence variant).

5. The clinician compares her Family History to tables of risk (Claus, Myriad) and runs computer models (algorithms such as BRCAPRO, see ). This gives a percentage risk of carrying a mutation (i.e. sequence variant) and/or a risk of developing breast and/or ovarian cancer. Her risk of a mutation is 25%, because her father's 4 sisters had ovarian caner.

6. The patient is considered to be at high risk of having a mutation (i.e. sequence variant), and this information is given to her.

7. She is referred to a High Risk Genetic Clinic.

8. She agrees to go to the High Risk Genetic Clinic.

9. Ms Eve Everywoman 's Family History details are sent to this clinic (the HL7 Interaction POCG_IN000001 is used), including her Family History, the syndrome suspected and her level of risk.

10. The counselor at the risk clinic (Nurse geneticist, genetic counselor, MD, etc.) reviews the family history information collected by the clinician (Medical oncologist, surgical oncologist, radiation oncologist, primary care provider), edits it and adds additional details.

11. The Counselor reviews the family history, decides what genetic syndrome the patient’s family might have, and categorizes her degree of risk (perhaps high, medium, or low risk). The Counselor thinks the patient is at high risk of having a BRCA1/2 mutation (i.e. sequence variant).

12. The clinician compares the family history to tables of risk (Claus, Myriad) and runs computer models (algorithms such as BRCAPRO). This gives a percentage risk of carrying a mutation and/or a risk of developing breast and/or ovarian cancer. Her risk of a mutation is 25%, because her father's 4 sisters had ovarian caner.

13. The patient is considered to be at high risk, and she is told she is a candidate for genetic testing. This includes a thorough discussion of the pros and cons of testing. This discussion is recorded in the electronic medical record.

14. Ms. Eve Everywoman wants to have testing, but as she is not affected, it is the standard of care to test a living affected relative first (i.e. a living relative who has/or has had the disease for which the patient is at risk for).

15. The Counselor suggests that her Aunt, Ms. Jeanne Aunt, is the most appropriate candidate for testing. Ms. Jeanne Aunt had ovarian cancer, and is still living.

16. Ms. Eve Everywoman agrees to contact Ms. Jeanne Aunt.

17. Ms Eve Everywoman signs consent to release her own Family History details to Ms Jeanne Aunt and her Provider.

18. Ms. Jeanne Aunt is a 39-year-old woman who had been diagnosed with ovarian cancer at age 35.

19. Ms Jeanne Aunt agrees to discuss testing, and provides the name and address of the risk clinic she will attend.

20. Ms Eve Everywoman's family history details are sent to this clinic.

21. The counselor at the risk clinic (Nurse geneticist, genetic counselor, MD, etc.) reviews the family history information collected by the primary clinician through a pedigree drawing program, and changes the Proband[3] to Ms Jeanne Aunt, edits it and adds additional details (The family history message had Ms Eve Everywomanas the Proband (Self), and Ms Jeanne Aunt as the aunt. The pedigree from the point of view of Ms Jeanne Aunt must have Jeanne Aunt as the Proband (Self) and must show Ms Eve Everywoman as the niece).

22. The Counselor reviews the family history, decides what genetic syndrome her family might have, and categorizes the patient as to degree of risk (Perhaps high, medium, or low risk). The Counselor thinks the patient is at high risk of having a BRCA1/2 mutation, because the patient and one or more of her relatives have had breast/ovarian cancer.

23. The clinician compares the family history to tables of risk (Claus, Myriad) and runs computer models (algorithms such as BRCAPRO). This gives a percentage risk of carrying a mutation and/or a risk of developing breast and/or ovarian cancer. Ms. Jeanne Aunt is virtually at 100% risk of having a BRCA1/2 mutation (i.e. sequence variant).

24. The patient is considered to be at high risk, and she is told she is a candidate for genetic testing. This includes a thorough discussion of the pros and cons of testing. This discussion is reviewed in the electronic medical record.

25. Ms. Jeanne Aunt wants to have testing. She signs an informed consent document.

26. The order for testing is issued, and the informed consent, and the family history are included with the lab requisition. All are MESSEGED to the blood drawing facility.

27. The blood is drawn, and sent to the central testing facility along with the informed consent, the family history and the lab requisition.

28. At the central testing facility, the specimen is checked in (i.e. accessioned), and the DNA is extracted and prepared for DNA sequencing.

29. Full gene sequencing of BRCA1 and BRCA 2 are undertaken.

30. The sequence is assessed for mutations.

31. Identified mutations are assessed for clinical significance: associated with increased risk of developing breast and/or ovarian cancer(pathogenic/deleterious), do not increase the patient’s risk of disease (benign), or if the clinical implications of the mutation is unknown (unknown significance). The actual mutation, and the assessment of clinical significance are sent to the counselor.

32. In this case, a mutation is identified in BRCA1 and the mutation is Pathogenic/Deleterious.

33. The counselor discusses the result with the patient.

34. Patient care decisions (Screening, chemoprevention, prophylactic surgery) are beyond the scope of this storyboard.

35. Ms Jeanne Aunt agrees to share this information with Ms Eve Everywoman's Clinician.

36. This information is sent to Ms Eve Everywoman's Clinician.

37. Ms. Eve Everywoman wants to have testing. She signs an informed consent document.

38. The order for testing is issued, and the informed consent, and the family history are included with the requisition, as well as the results of Ms Jeanne Aunt’s test. All are messaged to the blood drawing facility.

39. The blood is drawn, and sent to the central testing facility along with the informed consent, the family history, the results of Ms Jeanne Aunt’s test, and the lab requisition.

40. At the central testing facility, the specimen is checked in, and the DNA is extracted and prepared for DNA sequencing.

41. Full gene sequencing is not needed. Testing only for the identified mutation is undertaken.

42. The DNA is assessed for that specific mutation (i.e. sequence variant).

43. The mutation is not found.

44. The normal result is sent to the counselor.

45. The counselor discusses the result with the patient.

46. Patient management/care decisions (Screening, chemoprevention, prophylactic surgery) are beyond the scope of this storyboard.

2 PKU – Phenylketonuria

This storyboard illustrates the use of family history as part of the follow-up for a newborn diagnosed with Neonatal Phenylketonuria (PKU), during newborn screening. Phenylketonuria is inherited in an autosomal recessive manner. More details can be found at: .

2. Storyboard Presentation

1. Infant Ned Everynewborn is born.

2. His heel is lightly pricked and a blood sample is blotted onto a card for newborn screening test.

3. The ‘blood spot’ (card with sample from the newborn) is sent to the state’s newborn screening testing lab.

4. Tests are performed and positive (or ambiguous) results are communicated to the hospital and infant’s clinician.

5. The clinicain discusses these positve (or ambiguous) results with the newborn’s parents and refers them to a specialist.

6. The clinical specialist collects the family history of the patient, to help guide patient care and follow-up. In addtion, the clinician educates the parents on risks for future children, as PKU is a inherited recessive condition and 25% of their offspring are at risk of inheriting the condition.

1. Familial Hypertrophic Cardiomyopathy(HCM)

This storyboard illustrates the use of family history as part of confirmatory diagnosis of Familial Hypertrophic Cardiomyopathy. Basic information can be found at: More clinical details can be found at:

1. Storyboard Presentation

1. Ted Everyteen experiences shortness of breath while playing a very intense basketball game and follows up with his clinician.

2. His clinician captures a detailed family history from Ted Everyteen, even asking for him to follow-up with family members to gather more complete information.

3. Ted Everyteen’s clinician identifies that Ted is at high risk for Familial Hypertrophic Cardiomyothy (HCM), because his mother’s family has a history of sudden death at an early age (a ‘red flag’ for HCM) and HCM. In addition, Ted’s mother was diagnosed with HCM; therefore, Ted has a 50% chance of inheriting a mutation associated with the disease.

4. Genetic testing and patient management/care decisions (Screening, chemoprevention, prophylactic surgery) are beyond the scope of this storyboard.

2. X-linked Dialated Cardiomyopathy (XLDCM)

This storyboard illustrates the use of family history as part of confirmatory diagnosis of X-linked Dialated Cardiomyopathy (DCM) or DMD Associated Dilated Cardiomyopathy, which is caused by a mutation in the DMD gene that codes for the dystrophin protein. The DMD gene is located on the X chromosome. Males have one X chromosome and females have two. Typically males with a single mutation in the DMD gene are more severly affected with an early onset of the disease, because females will have a normal DMD gene on their second X chromosome, to compensate. Basic information can be found at: More clinical details can be found at:

1. Storyboard Presentation

1. Tod Everytoddler is three and visiting his pediatrician, Dr. Patricia Primary, for his annual physical. Dr. Primary meets with Tod’s parents, to update records including his family history.

2. Since their last visit, a nephew (Tim) on Tod’s mothers side (i.e. maternal nephew) was diagnosed with Dialated Cardiomyopathy (DCM). Knowing that DCM can be genetic and follow several inheritance patterns (e.g. recessive, dominant, or X-Linked), Dr. Primary is concerned.

3. During Tod’s exam Dr. Patricia Primary identifies an irregular heartbeat and refers Tod to a pediatric cardiologist specializing in genetic medicine. Dr. Primary also recommends that Tod’s mother speak to her sister to get permission for Tod’s and Tim’s clinicains to exchange information relevant for diagnosis.

Table 1: Outline for Family History of a Cancer Patient

|Data Element Name |Value |

|Relative Type (Self) | |

|Cancer | |

| Year Diagnosed | |

| Age Diagnosed | |

|Familial Syndrome Suspected | |

|Mother ID | |

|Father ID | |

|Relative ID | |

| Relative Type (Brother, Sister …) | |

| Cancer | |

| Year Diagnosed | |

| Age Diagnosed | |

| Syndrome Suspected | |

| Mother ID | |

| Father ID | |

|Relative ID | |

| Relative Type (Brother, Sister …) | |

| Cancer | |

| Year Diagnosed | |

| Age Diagnosed | |

| Syndrome Suspected | |

| Mother ID | |

| Father ID | |

|… | |

Sample Pedigrees

3. Breast / Ovarian Cancer – related to mutations in BRCA1/2

1. Annie Proband:

Annie Proband is a 42 year old woman with a family history strongly indicating a hereditary (i.e. familial) breast ovarian cancer syndrome. The pedigree below shows a maternal grandparent and cousin with breast cancer. Early age of onset (30) for her cousin’s breast cancer is another indicator of familial risk. In addition, her mother’s Ovarian cancer is an additional risk factor.

Figure 1: Common Visualization of a Family Health History: Breast Ovarian Cancer Syndrome

[pic]

The XML representations of the above pedigrees can be found in the package containing this guide.

4. Phenylketonuria (PKU) – caused by mutations in the PAH gene

1. Indiviual with PKU:

This is the pedigree of an individual with Phenylketonuria(PKU) a recessive disease. Nancy Everynewborn is diagnosed at birth, as were her bother and cousin, through the national newborn screening program. Nancy’s maternal uncle was diagnosed at age two, before newborn screening was performed, because of his late diagnosis, Nancy’s uncle suffered permanant mental disability.

Test_AR DOB:01/01/1991 MRN: 999_AR

Figure 2: Common Visualization of a Family Health History: PKU

[pic]

5. Dominantly Inherited Hypertrophic Cardiomyopathy (HCM) - MYH7, MYBPC3, TNNT2, TNNI3, TPM1, MYL2, MYL3, ACTC1, CSRP3, TTN, ACTN2, MYH6, TCAP, and potentially other genes.

1. Indiviual with Dominantly Inherited Hypertrophic Cardiomyopathy:

This is the pedigree of an individual with dominantly inherited hypertrophic cardiomyopathy. Her mother and maternal aunt have HCM; a maternal uncle died of sudden cardiac dealth (likely as a result of HCM); and maternal grandparents both died of non-specific heart related problems at 72 and 64. Her other syblings have not yet exhibited symptoms of HCM; their doctors are monitoring them closely and considering genetic testing.

Test Dominant DOB:09/09/1909 MRN: 999

Figure 3: Common Visualization of a Family Health HIstory: Dominantly Inherited Hypertrophic Cardiomyopathy

[pic]

6. X-linked Dialated Cardiomyopathy (DCM) - DMD

1. Indiviual with an X-linked Dilated Cardiomyopathy:

This pedigree shows the family history of an X-linked dilated cardiomyopathy. X-linked dilated cardiomyopathy (XLDC, sometimes abbreviated as XLDCM) is a clinical phenotype of dystrophinopathy which is characterized by preferential myocardial involvement without any overt signs of skeletal myopathy. It is a familial myocardial disease that presents with lethal congestive heart failure in young males in their teens or early twenties. A significant portion of XLDC-patients carry mutations in the dystrophin gene (DMD).

Test X linked DOB:09/09/2009 MRN: 999_XLinked

Figure 4: Common Visualization of a Family Health History: X-linked Dilated Cardiomyopathy

[pic]

The Family history model

The HL7 Family History/Pedigree model enables:

- the representation of family health historiesy in the form of pedigrees (as shown in the previous examples) with proper identification of relationships among family members,

- the capcity to attach data to each family member and the ability to represent any unlimited depth number of generations needed.

- In particularThe root of this model is a Family History class that leads to the Patient class, which in turn is associated with a Relative class. The latter is associated to itself and thus can represent the family relationships

- , eIn this implementation guide, the generic model should be used in a way that each family member / relative class (including the probandpatient) has shall have associations with mother and father classes that have unique identifications;. Tthis structure satisfies the requirements of risk assessment algorithms in order to run properly and produce input for clinical decisions support services.

- In addition, each family member objectRelative can class is optionally be associated with clinical data and optionally with genetic data, so that a specific family member can be associated with the data available for him/her.

Importantly, this modelimplementation guide

- Follows ONC/HHS family history data requirements as developed by the multi-stakeholder workgroup (available at: )

- Supports interoperability

- Aligned with meaningful use standards

- Proven within clinical settings to support both simple and advanced clinical workflows

7. Model Walkthrough[4]

1. Entry Point - FamilyHistory

The starting point of the model is the FamilyHistory Observation class. This class has several associations, one of which is subject participation of the Patient role played by a Person entity. The latter scopes the Relative class which can hold information about the patient's relatives. This constitutes the backbone of the model. In addition, the entry point is associated with risk analysis results and with problems health issues known in the family that cannot could not be attributed to specific family members.

1 id

The id attribute holds a unique identifier of this family history instance.

3 code

The code attribute shall hold a code representing Family History data in general, for example: the LOINC code 10157-6, HISTORY OF FAMILY MEMBER DISEASES or any other code that carries similar semantics..

4 statusCode

The statusCode attribute indicates whether the act of family history observation as a whole has completed, still active, etc. (based on the HL7 RIM Act State Machine).

6 methodCode

The methodCode attribute holds the identification of the program creating the family history data.

2. Patient & Person

The Patient role class is the root of the pedigree but in terms of data, it only captures an id assigned by the family history application on behalf of the provider hosting the family history application. Note that the id is optional and so is the class Provider (the scoping entity of the Patient role). Person is the player entity of Patient and holds general information about the person like gender, birth time, deceased indication, etc.

Note that the gender attribute of the Person class is an "administrative gender".

3. Clinical Data

At the right side of the Patient role there is a 'subjectOf2' participation that associates the patient (as a 'subject of') to a choice box of clinical and genetic data . This choice consists of zero to many ClinicalObservation classes. Note that this association is shadowed at the bottom of the model, and associated with the Relative class, which represents a role of a patient's relative. The ClinicalObservation class (recursively associated to itself) represents any clinical data that is part of the Person clinical history. Currently, the class has the classCode of 'OBS' which means that it is capable of representing only observations. In later releases of this the Pedigree standard, this class will should be replaced with the HL7 Clinical Statement component model.

4. Genetic Data

At the right side of the Patient role there is a 'subjectOf2' participation that associates the patient (as a 'subject of') to a choice box of clinical and genetic data. The representation of genetic data is restricted in version of thethis implementation guide to known mutations and their coded interpretations, as shown in the Vocabularies section and illustrated by examples in appendix E.

10 DataEstimatedAge

The DataEstimatedAge class is used to hold the estimated age of the subject at the effective time of the observation (e.g, the diagnosis time) made on that subject. The diagnosis observation is represented by the associated source observation[5], i.e., the ClinicalObservation class (this is used due to the absence of an age attribute in all HL7 classes). The data type is an interval to allow a range of ages such as in cases when the patient only remembers that the diagnosis was made when the family member was in her forties for example.

code:

The code attribute shall hold a code representing age of subject at the effective time when the source observation was made for that subject.

informant

5. Informant

This class optionally represents the source of information from which this family history was collected.

6. Relative

This refinement of the HL7 Role Class represents a patient's relative and is scoped by the Person entity which plays the Patient role in the first traversal of the model (see further explanation in the "Person and Relative" bullet below). The cardinality of this association is 0..*, which allows for the representation of any number of relatives who all relate to the Person who scopes the role.

The Relative class has a classCode = "PRS", defined as "links two people in a personal relationship… the character of the relationship must be defined by a PersonalRelationshipRoleType code…" The latter code is defined by the Relative.code[6] attribute whose value set is drawn from the domain "PersonalRelationshipRoleType".

Appendix EThe Vocabularies section 5.1 includes a table that shows discusses the codes of this domain. By Uusing values from this domain it is possible to designate the relation to the patient or to the patient's family member. Thus, in this model it is possible to use, for example, the code GRMTH (grandmother) for Relative associated directly to the patient, or use the code NMTH (mother) for Relative associated to the mother of the patient. This makes the model more flexible.

The basis of this part of the model is in the HL7 Reference Information Model (RIM) definition of family member relationships which are based on the relationship between a scoping entity and a role. For example, the code CHILD is defined as follows: "The player of the role is a child of the scoping entity", and the same goes for any type of family relationship. Note that this is valid not only to the relationship between the patient and a relative directly associated with the patient, rather this is true for any relationship between family members on this pedigree, for example, between the patient's mother (the scoper) and her father (the role).

11 SubjectEstimatedAge

This choice box is associated with the Relative class and holds two classes concerned with estimated ages of the subject as follows:

1. The DeceasedEstimatedAge class is used to hold the estimated age when the subject died. It is used due to a lack of age attribute in all HL7 classes. We have proposed to perform RIM harmonization with the addition of age attribute to hold the deceased age as well as the subject age at the time a diagnosis was made (see above in the DataEstimatedAge class description), but were asked to try and model this piece of information using associated observations like this class.

2. The LivingEstimatedAge class is used to hold the estimated age of a living relative whose birth date is unknown.

3. The code shall represent semantics similar to the LOINC code "21611-9" that represents the concept of an estimated age (as opposed to precise age).For deceased subject, the code shall represent semantics similar to the LOINC code 39016-1 (AGE AT DEATH).

7. subjectOf2 Shadow

This class is a shadow of the subjectOf2[7] class associated with Patient and thus also includes all its associated classes. This means that the same clinical and genomic data structures attached to the patient could be optionally attached to any of his/her relatives represented by the Relative class. It could be that the clinical data of any of the persons involved in this pedigree model exist elsewhere (in the same message or document, or in the person medical records). In this case it is possible to point to that data by including reference classes which only hold ids of the actual data, thus enabling applications to get the information if needed.

8. Person and Relative

The Person class allows the representation of personal information like gender and birth time of each of the patient's relatives. It is also linked back to the Relative class, an association which enables a recursive traversal a pedigree at any level of depth in a pure XML hierarchical fashion (i.e., only by nesting elements). Note that in each new traversal of this recursive association, the scoping Person represents another family member, and consequently the Relative class relates to this family member and not directly to the patient. The recursive association is shown in figure 6.

In general, the issue of recursion and XML hierarchy relate to the representation of pedigree data which is hierarchical by nature but could be represented in various ways using XML nesting elements on the one hand or mother and father ids for each relative thus constituting the hierarchy via links and pointers and not via nesting elements. The latter format also allows the flat outline of the pedigree. These issues are discussed in more detail in appendix B.

9. Relative’s Mother and Father Identifiers

In a flat XML representation of a pedigree it is often required to maintain mother and father ids for each relative, in order to allow the family history application to reconstruct the pedigree. These ids should be placed in the id attribute of the Person class. That class should be populated for each parent if available. The first XML sample in appendix D shows a flat representation of a pedigree with the ids populated in the Person class (XML element is relationshipHolder.id).

It is required to use globally unique ids as mandated by the use of the II data type for the id attribute. Regarding the generation of theses ids, there can be two situations:

(1) The application generating the pedigree has a 'root' OID dedicated to this purpose and it extends it for each pedigree it creates. Then, it generates arbitrary unique ids for each relative who doesn't have a globally unique id and places it in the extension component. The concatenation of the pedigree root and relative extension creates a globally unique id for the person;

(2) The application knows a globally unique id of a relative and uses it. Note that in a certain pedigree there can be a mixture of the two situations.

Figure 5: The Recursive Association of Person and Relative Which Enables a Hierarchical Representation of a Pedigree to Any Depth Needed

[pic]

vocabularies

8. Family Relationships

Coding relationship with the proband and relatives or among two relatives shall be done through the HL7 vocabulary RoleCode - PersonalRelationshipRoleType.

Table 2: Personal Relationship Role Type Value Set (excerpt)

|Value Set: Personal Relationship Role Type 2.16.840.1.113883.1.11.19563 DYNAMIC |

|Code System(s): |RoleCode 2.16.840.1.113883.5.111 |

|Description: |A Personal Relationship records the role of a person in relation to another person. This value set is to|

| |be used when recording the relationships between different people who are not necessarily related by |

| |family ties, but also includes family relationships. |

| | |

|Code |Code System |Print Name |

|HUSB |RoleCode |husband |

|WIFE |RoleCode |wife |

|FRND |RoleCode |friend |

|SISINLAW |RoleCode |sister-in-law |

|… | | |

9. Age Attributes

There are three types of age attributes (all types should be considered estimated ages):

1. Age at Death

Table 4: Age at Death

|Code |Code System |Print Name |

|39016-1 |LOINC |Age at death |

2. Age of Onset of Disease

Table 5: Age of Onset of Disease

|Code |Code System |Print Name |

|54130-0 |LOINC |Age range at onset of disease (patient) |

|54115-1 |LOINC |Age range at onset of disease (family member) |

3. Age of Living Subject

Estimated age of a living relative whose birth date is unknown.

|Code |Code System |Print Name |

|21611-9 |LOINC |Age estimated |

Table 6: Age of Living Subject

10. Race

Table 7: Race Value Set (excerpt)

|Value Set: Race 2.16.840.1.113883.1.11.14914 DYNAMIC |

|Code System(s): |Race and Ethnicity - CDC 2.16.840.1.113883.6.238 |

|Description: |A Value Set of codes for classifying data based upon race. |

| |Race is always reported at the discretion of the person for whom this attribute is reported, and |

| |reporting must be completed according to Federal guidelines for race reporting. Any code descending from|

| |the Race concept (1000-9) in that terminology may be used in the exchange |

| | |

|Code |Code System |Print Name |

|2058-6 |Race and Ethnicity- CDC |African American |

|1004-1 |Race and Ethnicity- CDC |American Indian |

|2101-4 |Race and Ethnicity- CDC |Fijian |

|2106-3 |Race and Ethnicity- CDC |White |

|… | | |

11. Ethnicity

Table 8: Ethnicity Value Set

|Value Set: HITSP Ethnicity Value Set 2.16.840.1.113883.1.11.15836 DYNAMIC |

|Code System(s): |Race and Ethnicity - CDC 2.16.840.1.113883.6.238 |

|Code |Code System |Print Name |

|2135-2 |Race and Ethnicity Code Sets |Hispanic or Latino |

|2186-5 |Race and Ethnicity Code Sets |Not Hispanic or Latino |

1 Genetic Mutation Attributes

1. Sequence Variant/Genetic Mutation

For detailed specifications on coding genetic mutations / sequence variants, within a family history/pedigree, see HL7 VERSION 2 IMPLEMENTATION GUIDE: CLINICAL GENOMICS; FULLY LOINC-QUALIFIED GENETIC VARIATION MODEL, RELEASE 2.

Table 9: Sequence Variant / Genetic Mutation Minimal Core Dataset

|LOINC Code |Value Set |LOINC element name |Description/Comments | |

|48018-6 |HGNC |Gene Identifier |HGNC gene Identifier set by the Human Genome |Required |

| | | |Organization Nomenclature Committee. | |

|51958-7 |NCBI |Transcript Reference Sequence |This field carries the ID for the transcribed |Optional for |

| | |Identifier |reference sequence that part of the genetic |manually |

| | | |reference sequence that is converted to Messenger |entered data –|

| | | |RNA. For this ID use either the NCBI nucleotide |may not be |

| | | |RefSeq IDs for transcribed DNA, plus the version |available |

| | | |number (NCBI.NLM.RefSeq), or use the LRG | |

| | | |identifiers with transcript (t or p) extensions | |

| | | |when they become available. (Report sponsored by | |

| | | |GEN2PHEN at the European Bioinformatics Institute | |

| | | |at Hinxton UK April 24-25, 2008). The NCI RefSeq | |

| | | |transcripts IDs have a prefix of “NM” for genes | |

| | | |from the nuclear chromosomes. NCBI does not | |

| | | |currently provide a transcript RefSeq for | |

| | | |mitochondrial genes. The LRG transcripts | |

| | | |Identifiers have a prefix of “LRG_” plus a t | |

| | | |extension. Mitochondrial genes are out of scope of | |

| | | |LRG. C3 = third set of conditionals. Either | |

| | | |‘Genomic Reference Sequence Identifier’ or | |

| | | |‘Transcript Reference Sequence Identifier’ is | |

| | | |required. Both can be used. | |

|48003-8 |NCBI |DNA Sequence Variation Identifier|A DNA Sequence Variation identifier conveys a |Optional |

| | | |universal or standard repository identifier for | |

| | | |definitive characteristics of a DNA Sequence | |

| | | |Variation. (If available, recommend using NCBI | |

| | | |dbSNP ids - RS#) | |

|48004-6 |HGVS |DNA Sequence Variation |Human Genome Variation Society (HGVS) nomenclature |Required |

| | | |for a single or set of DNA Sequence Variation(s) | |

| | | |identified in testing. The use of the nomenclature| |

| | | |is also used to describe non-variations (aka. wild | |

| | | |types). Either the DNA Sequence Variation is | |

| | | |required or the Amino Acid Change. NOTE: If NCBI’s| |

| | | |dbSNP IDs (RS#) is used, then the DNA Sequence | |

| | | |Variation is required to uniquely define the | |

| | | |Variant, as the number is unique to the nucleotide | |

| | | |location and requires the details of nucleotide | |

| | | |change. C4 = fourth set of conditionals. Either | |

| | | |‘DNA Sequence Variation’ or ‘Amino Acid Change’ is | |

| | | |required. Both can be used. | |

|53034-5 |LOINC Answer |Allelic State |The level of occurrence of a single DNA Sequence |Required |

| |List | |Variation within a set of chromosomes. | |

| | | |Heterozygous indicates the DNA Sequence Variation | |

| | | |is only present in one of the two genes contained | |

| | | |in homologous chromosomes. Homozygous indicates | |

| | | |the DNA Sequence Variation is present in both genes| |

| | | |contained in homologous chromosomes. Hemizygous | |

| | | |indicates the DNA Sequence Variation exists in the | |

| | | |only single copy of a gene in a non-homologous | |

| | | |chromosome (the male X and Y chromosome are | |

| | | |non-homologous). Hemiplasmic indicates that the | |

| | | |DNA Sequence Variation is present in some but not | |

| | | |all of the copies of mitochondrial DNA. | |

| | | |Homoplasmic indicates that the DNA Sequence | |

| | | |Variation is present in all of the copies of | |

| | | |mitochondrial DNA. LOINC Answer List values can be | |

| | | |seen in Table 7.6. | |

|48002-0 |LOINC Answer |Genomic Source Class |The genomic class of the specimen being analyzed: |Required |

| |List | |germline for inherited genome, somatic for cancer | |

| | | |genome, and prenatal for fetal genome. LOINC Answer| |

| | | |List values can be seen in Table 7.6. | |

|53037-8 |LOINC Answer |Genetic Disease Sequence |Interpretation of the pathogenicity of the DNA |Optional |

| |List |Variation Interpretation |Sequence Variation in the context of the assessed | |

| | | |genetic disease. LOINC Answer List values can be | |

| | | |seen in Table 7.6. | |

Table 10: LOINC Answer List Values, referenced in Table 9.

|LOINC code |LOINC component |Sequence |Answer text |LOINC |

| | | | |answer code |

|53034-5 |Allelic state |1 |Heteroplasmic |LA6703-8 |

| | |2 |Homoplasmic |LA6704-6 |

| | |3 |Homozygous |LA6705-3 |

| | |4 |Heterozygous |LA6706-1 |

| | |5 |Hemizygous |LA6707-9 |

|53037-8 |Genetic disease sequence variation |1 |Pathogenic |LA6668-3 |

| |interpretation | | | |

| | |2 |Presumed pathogenic |LA6669-1 |

| | |3 |Unknown significance |LA6682-4 |

| | |4 |Benign |LA6675-8 |

| | |5 |Presumed benign |LA6674-1 |

|48002-0 |Genomic source class |1 |Germline |LA6683-2 |

| | |2 |Somatic |LA6684-0 |

| | |3 |Prenatal |LA6685-7 |

| | |4 |Likely Germline |LA18194-3 |

| | |5 | Likely Somatic |LA18195-0 |

| | |6 | Likely Prenatal |LA18196-8 |

| | |7 |Unknown Genomic Origin |LA18197-6 |

Exchange of family health history

While the exchange of family health histories could be done in a number of ways, this US Implementation Guide recommends using standards selected by Meaningful Use, in particular – the Clinical Document Architecture (CDA) standard.

An unconstrained CDA document can have a pointer to a Pedigree instance by using the CDA classes pointing to external information objects. Each of these reference classes has an id and code. The id attribute should hold the id of a Pedigree instance. The code attribute could indicate that the referenced object is a Pedigree.

In line with HITSP recommendations for the realization of the Personalized Healthcare Use Case, the exchange mechanism could be accomplished through a specific type of CDA, which is the Continuity of Care Document (CCD), depicted in the following figure:

[pic]

The full technical details of the HITSP recommendations are described in appendix D, but in a nutshell, the basic idea is that a CCD document could point to a Pedigree instance as aforementioned from the CCD family history section. That section has a relatively rudimentary structure for the family health data and is built on family history ‘organizers’, each can consist of several family history observations concerning the same patient’s relative. The CCD spec states that "The target of a family history organizer... SHOULD be family history observation, but MAY be some other clinical statement." Thus, it is possible to place a pointer to a Pedigree instance in that 'other clinical statement' using the CDA external reference machinery.

Note: An alternative exchange mechanism for systems conformant with HL7 v3 messaging is to use the Pedigree Exchange Interaction specified in the Normative Pedigree available as part of the HL7 Normative Edition (see the following page for more details: ).

appendix a: The family history (Pedigree) model

The following figure shows the HL7 v3 parent model (Pedigree R1) underlying this US ImplemenationImplementation Guide. The intention of this appendix is to provide a broader context of the guidance provided in this ImplemenationImplementation Guide, but for practical reasons, an implementer can skip this appendix and mainly look at the model walk-through and respective XML samples.

Notes:

1. This Family History model is a static model that can be used as a payload in

messaging or workflows. The latter are outside of the scope of this model: v3 messaging is descibed specified in the section on exchangePedigree R1 and workflows are not standardized by HL7.

2. The model utilizes the GeneticLocus and GeneticLoci models which were part of the Genotype Specification (Draft Standard for Trial Use) that has been expired after the finalziationfinalization of the Pedigree ResleaseR1 One. For backward compatabilitycompatibility purposes, the base model in this imppementationImplementation guide Guide still calls these genomic models, but is restricted to specific use cases, for which the genetic data representation is specified in section 4.1.4, along with explicit binding to vocabularies. -

3. The model was designed to use the Clinical Statement shared model (which was still under development when Pedigree R1 was finalized) to represent the clinical data but the latter was still under development when Pedigree R1 was finalized. Therefore, it has a generic ClinicalObservation class with an act relationship to hold common clinical data (e.g., problems, diagnoses, reactions to drugs, allergies, etc.). This structure is compatible with the current Clinical Statement model of HL7. It could be that Pedigree R2 will utlizeutilize the full blown Clinical Statement model, but for the purposes of this US implemenationimplementation guide, the ClinicalObservation class seems to be sufficient.

4. The model has been transformed to an XML schema set using HL7 Tooling. This schema set is included in the the Pedigree R1 specification. It is important to note that the W3C XML Schema language cannot represent all constraints expressed in the base spec as well as in this US guide.

Figure 6: The Family History (Pedigree) Model

[pic]

appendix B: hierarchical vs. flat representation

1. While a pedigree is hierarchical by nature, consider the following:

a. Sometimes the patient knows about a relative disease but cannot recall the

precise position of that relative on the pedigree (or only knows parental affiliation, i.e., is he/she on the paternal or maternal side)

b. There are intermarriages

c. People are more comfortable with looking at flat representations when they

look at the raw data (underlying representation like XML) and at the same time, the preferred visualization/manipulation format of a pedigree is a graph (e.g., all drawing features in the family history applications)

2. Possible representations:

a. Pure hierarchical representation: the patient as well as all relatives are only

associated with their first-degree relatives:

Pros: No need for relationship codes such as uncle, cousin, etc. beyond the codes for the first degree relatives, i.e., mother, father and siblings

Cons: In order to infer that this relative is a paternal aunt you need to traverse the pedigree; it's hard to read in XML though easy to read when it's being drawn as a pedigree diagram

b. Pure flat representation: all relatives are directly associated with the patient

(proband):

Pros: Easy to get to each relative; ease to read; allows the representation of fuzzy data (e.g., when you don't know the exact location of a relative on the pedigree or you only know that this relative is paternal or maternal)

Cons: need too many relationship codes to represent multiple generations (e.g., grand grand mother's uncle); must have pointers to the father and mother of each relative in order for the parsing application to be able to re-construct the hierarchy of the pedigree

c. Mixed representation: Hierarchical and flat, where some relatives are directly

associated with the patient (mainly those whose position cannot be determined):

Pros: a flexible structure that enables the representation of all use cases

Cons: a complex model with optionally that might create confusion

3. HL7 Modeling considerations:

a. Flat:

i. Using the flat representation requires the use of three ids for each person:

1. Person id

2. Person's mother id

3. Person's father id

ii. These ids allow the parsing application to construct the proper relationships necessary for the risk assessment procedures

iii. Each relative is represented by a Role class andthe above three ids are represented in the playing entity class (Person) id and in the associated Relative/Person classes of the mother and father of that relative

b. Hierarchical:

i. Using hierarchical representation requires recursive association of the

Role class through its playing Person class and back to another Role which is scoped by the Person class

4. Personal relationships codes:

a. HL7 has a personal relationship vocabulary (RoleCode>

PersonalRelationshipRoleType>FAMMEMB) bound to the Role.code attribute

5. Figure 2 (in the model walk-through) shows a portion of the Clinical Genomics

Family History model which is the backbone of the pedigree 'mixed representation' as described above.

6. To assure consistency across different implementations of the Pedigree spec,the

implementation guidance mandates the use of a flat representation, as follows:

7. A Pedigree will have a flat representation with one nesting level

8. The nesting level is used to represent mother and father ids of each relative

9. Globally unique ids are assigned to the relative’s mother & father using Entity

(Person) id attribute

10. Clinical and genomic data cannot be attached to the specification of the mother and father ID's

appendix C: xml schema and samples

In the package containing this document you can find the following files aimed at illustrating the way the model is implemented in specific instances that could be sent through the wire. It is recommended to view those files in an XML browser.

Note that the schema was generated using the HL7 tooling, available at 2007.

1. The Pedigree Schema:

a. POCG_MT000040.xsd

The schema describes the pedigree model and in addition it includes the Genotype schema as a compoenentcomponent model (CMET), used to represent genomic data of the patient and any his/her relatives.

2. Pedigree Samples:

a. FamilyHistorySample-POCG000040-v14.s1FamilyHistorySample-POCG000040-v10.s2.xml

This is the sample included in the normative Pedigree R1 from 2007, adjusted to the constraints of this US implementation guide. It consists of a sample pedigree: patient, father, mother and grandparents of both sides. Also, two sisters, husband and daughter. It illustrates a certain way to implement a specific pedigree, and shows the use of pedigree ids, birth year, vital status and clinical data. It's a 'flat' pedigree as all relatives are directly associated with the patient.

In addition, it shows an example of genetomic data (BRCA1 mutation and optionally full DNA sequence in the extended sample).

The data items currently demonstrated in that file are taken from the spreadsheet "SamplePed" contributed by Dr. Hughes. The file is part of the package where this document is found.

b. FamilyHistorySample-POCG000040-AnnieAnnie Proband without genetic data.xml

Consists of a sample pedigree as described in the sample pedigrees section in this guide.

c. FamilyHistorySample-POCG000040-Annie2.Annie Proband With Positive BRCA Testingxml

Consists of a sample pedigree as described in the sample pedigrees section in this guide.

d. FamilyHistorySample-POCG000040-Emma2.xml

Consists of a sample pedigree as described in the sample pedigrees section in this guide.

appendix D: HITSP specifications on personalized healthcare

This US-Realm specific Implementation Guide utilizes the HITSP specification titled “HITSP Personalized Healthcare Interoperability Specification” (HITSP/IS08, Published on December 18, 2008, Version 1.0) in order to guide the exchange of family health histories across disparate applications.

The HITSP Personalized Healthcare Interoperability Specification describes family history and genetic/genomic lab order and results which are used to provide personalized treatment specific to genetic makeup. In particular, we utilize the following constructs:

HITSP/C90 - Clinical Genomic Decision Support

The Family History Decision Support for Genetic Risk Analysis Component is used to communicate genetic and family history information from healthcare IT applications to a clinical decision support system that provides an assessment of genetic risk of disease for a patient. It uses the HL7 Version 3 Standard: Clinical Genomics; Pedigree, Release 1 to support the communication of genetic and family history information to the clinical decision support system, and to support the communication of risk information from that system back to the originator.

Figure 6.3-1 represents the UML interaction diagram for the Clinical Assessment Scenario 1 from the perspective of the Clinician for Event 7.1.1. The clinician will request the patient’s personal and family history and pedigree, preferably in an interoperable form. The clinician will also gather any previous genetic/genomic test results.

Figure 8: Construct Personal and Family Health History & Pedigree

[pic]

Each HITSP construct uses Information Exchange Requirement (IER) and Data Requirement (DR). For the aforementioned C90 construct, the HITSP specification lists the following IER and DRs:

|DR1 Demographic Data |IER25 Send/receive Decision Support data |

|DR3 Clinical History | |

|DR4 Personal Genetic/genomic data | |

|DR5 Family Genetic/genomic information | |

|DR8 Unstructured Data | |

With regard to family history, the DR5 (Family Genetic/genomic information)is described as follows:

Family genetic/genomic information, including (but not limited to):

1. Genetic/genomic data of family members

2. History of consanguinity

3. Pedigree in structured form when available

4. Consent/access allowance information

The following figure from the HITSP specification shows the IER 25 communicating among EHR, PHR and Genetic Clinical Decision Support systems:

Figure 9: Scenario 1: Clinical Assessment Component Data Flow Diagram

[pic]

Appendix E: Genetic Data RepresenationExample XML SNIPPETS

The following XML example illustartes the way to represnet known BRCA mutations, (optionally) along with additional traits as well as coded interpretations.

The following XML Snippets extracted from the complete sample attached to Pedigree R1, and refined to fit the constraints of the Pedigree US Implementation Guide

Demographic data

Estimated age of a living subject:

Estimated age of death:

Clinical data representation along with age of onset:

Genetic data:

The following XML example illustrate the way to represent known BRCA mutations, (optionally) along with additional traits as well as coded interpretations.

Genetic data – ‘green’ version (no HL7 foundational elements & attributes):

Genetic data – ‘green’ & minimal version (no associated observation examples):

….

-----------------------

[1]Research Staff Member at the IBM Research Lab in Haifa;

HL7 Clinical-Genomics Work Group Co-chair & Modeling Facilitator.

[2]Surgical Director, Breast Screening;

Co-Director, Avon Comprehensive Breast Evaluation Center, Massachusetts General Hospital.

[3] Proband: First affected family member coming to medlcal attention.*

Consultand: Individual(s) seeking genetic counseling/tetsing*

*Bennett RL, Steinhaus KA, Uhrich SB, O'Sullivan CK, Resta RG, Lochner-Doyle D, Markel DS, Vincent V, Hamanishi J. Recommendations for standardized human pedigree nomenclature.Pedigree Standardization Task Force of the National Society of Genetic Counselors.Am J Hum Genet. 1995 Mar;56(3):745-52.

[4] Note that this walkthrough describes the classes along with their main attributes only. Full technical specification of all attributes, data types, etc. can be found in the ANSI Pedigree R1 specification.

[5]By 'source' observation we mean the source of the HL7 ActRelationship class (named 'subject' in this model) that associates a source act to a target act while its type code attribute carries the semantics of this association.

[6] In general, the code attribute in HL7 is a specialization of the structural classCode attribute.

[7] A shadow class means that all its attributes and traversable associations are identical to those of the class it shadows.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download