Business identifiers assigned to this family member history by the performer or other systems which remain constant as the resource is updated and propagates from server to server.

Allows identification of the family member history as it is known by various participating systems and in a way that remains consistent across servers.

This is a business identifier, not a resource identifier (see discussion). It is best practice for the identifier to only appear on a single resource instance, however business practices may occasionally dictate that multiple resource instances with the same identifier can exist - possibly even with different resource types. For example, multiple Patient and a Person resource instance might share the same social insurance number.

The URL pointing to a FHIR-defined protocol, guideline, orderset or other definition that is adhered to in whole or in part by this FamilyMemberHistory.

see Canonical References

The URL pointing to an externally maintained protocol, guideline, orderset or other definition that is adhered to in whole or in part by this FamilyMemberHistory.

This might be an HTML page, PDF, etc. or could just be a non-resolvable URI identifier.

A code specifying the status of the record of the family history of a specific family member.

This element is labeled as a modifier because the status contains codes that mark the resource as not currently valid.

A code that identifies the status of the family history record.

A human language representation of the concept as seen/selected/uttered by the user who entered the data and/or which represents the intended meaning of the user.

The codes from the terminologies do not always capture the correct meaning with all the nuances of the human using them, or sometimes there is no appropriate code at all. In these cases, the text is used to capture the full meaning of the source.

Very often the text is the same as a displayName of one of the codings.

The person who this history concerns.

References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.

The date (and possibly time) when the family member history was recorded or last updated.

Allows determination of how current the summary is.

This should be captured even if the same as the date on the List aggregating the full family history.

This will either be a name or a description; e.g. "Aunt Susan", "my cousin with the red hair".

Allows greater ease in ensuring the same person is being talked about.

Note that FHIR strings SHALL NOT exceed 1MB in size

The birth sex of the family member.

Not all relationship codes imply sex and the relative's sex can be relevant for risk assessments.

This element should ideally reflect whether the individual is genetically male or female. However, as reported information based on the knowledge of the patient or reporting friend/relative, there may be situations where the reported sex might not be totally accurate. E.g. 'Aunt Sue' might be XY rather than XX. Questions soliciting this information should be phrased to encourage capture of genetic sex where known. However, systems performing analysis should also allow for the possibility of imprecision with this element.

Codes describing the sex assigned at birth as documented on the birth registration.

Describes why the family member history occurred in coded or textual form.

Textual reasons can be captured using reasonCode.text.

Codes indicating why the family member history was done.

Indicates a Condition, Observation, AllergyIntolerance, or QuestionnaireResponse that justifies this family member history event.

References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.

The actual condition specified. Could be a coded condition (like MI or Diabetes) or a less specific string like 'cancer' depending on how much is known about the condition and the capabilities of the creating system.

Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination.

Identification of the Condition or diagnosis.

Indicates what happened following the condition. If the condition resulted in death, deceased date is captured on the relation.

Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination.

The result of the condition for the patient; e.g. death, permanent disability, temporary disability, etc.

This condition contributed to the cause of death of the related person. If contributedToDeath is not populated, then it is unknown.

An area where general notes can be placed about this specific condition.

For systems that do not have structured annotations, they can simply communicate a single annotation with no author or time. This element may need to be included in narrative because of the potential for modifying information. Annotations SHOULD NOT be used to communicate "modifying" information that could be computable. (This is a SHOULD because enforcing user behavior is nearly impossible).