📝 Condition and Family Module Drafts

input/pagecontent/module_family.md

@@ -1 +1,21 @@
-### Family
+# Family
+
+## Overview
+This module describes family groups and family relationships, often used in genomic analyses to aid in identification of causal variants. We include several articulations of these: Family Study is an entity that describes a collection of participants in the context of a research study. Family Relationships describe the relationship of two Participants, and should be sufficient for generating a pedigree if the source information is present.
+
+This does not include specific methods for managing reports of “family history”. Those elements can either be encoded as specific “Participants” for which data are recorded as assertions and their family relationship to the Participant are recorded OR encoded as assertions from the Participant (eg, “family history of hypertension” or “Maternal history of hypertension”).
+
+### Family Study
+Family Study describes a group of Participants that are related. This is not an expression of all individuals in a “family”, but a tool to identify “family members of interest” that were studied. For example, a family trio in a rare disease study does not exclude the existence of other siblings. Family Studies do not require much detail, but there are often attributes of those families that may be of use to researchers.
+
+### Family Relationship
+Family Relationships describe the relationship between two Participants. The core use case is to present biological parentage of a participant to support family / pedigree analyses. In this spirit, platforms should seek to provide minimally the information in a “ped” file: if known, a Participant should have a Family Relationship to their biological mother and father. Twins are also a high priority item for reporting. Further extended relationships can be made available using Family Relationship, but may not be as widely supported as they are harder to interpret.
+
+
+## Relevant Artifacts
+- [NCPI Study Family](StructureDefinition-ncpi-study-family.html)
+- [Family Relationship](StructureDefinition-ncpi-family-relationship.html)
+- [Family Type](StructureDefinition-family-type.html)
+- [Study Family Description](StructureDefinition-description.html)
+- [Consanguinity](StructureDefinition-consanguinity.html)
+- [Study Family Focus](StructureDefinition-study-family-focus.html)

input/pagecontent/module_phenotype_condition.md

@@ -1 +1,28 @@
-### Phenotype/Condition
+# Phenotype/Condition
+
+## Overview
+
+The Condition Module is used to represent a condition or phenotype linked to a patient in a study. This means that the patient must have an assertion (status) for the given diagnosis.
+
+
+### Condition Assertion
+Condition Assertions are records of a present or absent condition status for a participant. They reflect support for ongoing longitudinal records, and enable the ability to make explicit whether a feature was recorded or not for a participant. The assertion may carry with it additional data, such as age of onset, but it’s not required. Condition Assertions may be contradictory over time- the goal is to represent faithfully what was reported by the study. Consumers of this data should expect to need to aggregate this longitudinal record or reconcile data captured at different granularity. For example, it’s common to capture broad negative categories (No Heart Conditions) but also specific positive assertions (Atrial Septal Defect).
+
+### Condition Asserter
+Condition Asserter is used to represent the source for the condition/phenotype diagnosis. For example, this field can be used to document whether the condition was pulled from an EHR or found in other clinical documentation. 
+
+## Conventions
+These entities describe phenotypes of Participants. The distinction is one of “record of asserted status” and “Details of positively asserted status”. We make these distinctions to support general use cases of “longitudinal, catch all records” and “curated summaries of features”. This distinction is focused on the interoperability utility over the “direct representation of reality”. There is overlap in these data; many assertions about status and onset might be coalesced into a single description of an affected status. In other studies, the “summary” may be derived from a single “assertion” and appear mostly duplicative.
+
+
+
+This distinction is similar to those in OMOP and FHIR, though it does not map precisely. Critically in OMOP and FHIR, Condition_occurrence and Condition are ALWAYS a positive assertion (though they may be wrong). “Assertions of history of disease” are observations in OMOP, eg, ICD9CM V-codes like “Personal history of malignant neoplasm of breast” go in Observation. 
+
+We do not set a distinction in entities here about “Phenotypes” vs “Diseases” as often used in a rare disease setting (eg, in Phenopackets). There is utility in indicating the intent of the submitter where possible, but this is not represented as separate entities.
+
+## Relevant Artifacts
+- [NCPI Condition](StructureDefinition-ncpi-condition.html)
+- [Condition Assertion](ValueSet-condition-assertion-vs.html)
+- [Condition Asserter](StructureDefinition-condition-asserter.html)
+- [Condition Location](StructureDefinition-condition-location.html)
+- [Condition Laterality](StructureDefinition-condition-laterality.html)