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.

Describes why the family member's history is not available.

This is a separate element to allow it to have a distinct binding from reasonCode.

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.

Codes describing the reason why a family member's history is not available.

A reference to a location at which the other resource is found. The reference may be a relative reference, in which case it is relative to the service base URL, or an absolute URL that resolves to the location where the resource is found. The reference may be version specific or not. If the reference is not to a FHIR RESTful server, then it should be assumed to be version specific. Internal fragment references (start with '#') refer to contained resources.

Using absolute URLs provides a stable scalable approach suitable for a cloud/web context, while using relative/logical references provides a flexible approach suitable for use when trading across closed eco-system boundaries. Absolute URLs do not need to point to a FHIR RESTful server, though this is the preferred approach. If the URL conforms to the structure "/[type]/[id]" then it should be assumed that the reference is to a FHIR RESTful server.

The expected type of the target of the reference. If both Reference.type and Reference.reference are populated and Reference.reference is a FHIR URL, both SHALL be consistent.

The type is the Canonical URL of Resource Definition that is the type this reference refers to. References are URLs that are relative to http://hl7.org/fhir/StructureDefinition/ e.g. "Patient" is a reference to http://hl7.org/fhir/StructureDefinition/Patient. Absolute URLs are only allowed for logical models (and can only be used in references in logical models, not resources).

This element is used to indicate the type of the target of the reference. This may be used which ever of the other elements are populated (or not). In some cases, the type of the target may be determined by inspection of the reference (e.g. a RESTful URL) or by resolving the target of the reference; if both the type and a reference is provided, the reference SHALL resolve to a resource of the same type as that specified.

Aa resource (or, for logical models, the URI of the logical model).

An identifier for the target resource. This is used when there is no way to reference the other resource directly, either because the entity it represents is not available through a FHIR server, or because there is no way for the author of the resource to convert a known identifier to an actual location. There is no requirement that a Reference.identifier point to something that is actually exposed as a FHIR instance, but it SHALL point to a business concept that would be expected to be exposed as a FHIR instance, and that instance would need to be of a FHIR resource type allowed by the reference.

When an identifier is provided in place of a reference, any system processing the reference will only be able to resolve the identifier to a reference if it understands the business context in which the identifier is used. Sometimes this is global (e.g. a national identifier) but often it is not. For this reason, none of the useful mechanisms described for working with references (e.g. chaining, includes) are possible, nor should servers be expected to be able resolve the reference. Servers may accept an identifier based reference untouched, resolve it, and/or reject it - see CapabilityStatement.rest.resource.referencePolicy.

When both an identifier and a literal reference are provided, the literal reference is preferred. Applications processing the resource are allowed - but not required - to check that the identifier matches the literal reference

Applications converting a logical reference to a literal reference may choose to leave the logical reference present, or remove it.

Reference is intended to point to a structure that can potentially be expressed as a FHIR resource, though there is no need for it to exist as an actual FHIR resource instance - except in as much as an application wishes to actual find the target of the reference. The content referred to be the identifier must meet the logical constraints implied by any limitations on what resource types are permitted for the reference. For example, it would not be legitimate to send the identifier for a drug prescription if the type were Reference(Observation|DiagnosticReport). One of the use-cases for Reference.identifier is the situation where no FHIR representation exists (where the type is Reference (Any).

Plain text narrative that identifies the resource in addition to the resource reference.

This is generally not the same as the Resource.text of the referenced resource. The purpose is to identify what's being referenced, not to fully describe it.

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

Allows determination of how current the summary is.

This element is not currently flagged as Must Support in PS-CA, as early implementers have indicated the element may not be supported by some piloting systems.

Systems that do support the element are encouraged to include it in generated Patient Summary documents, and support it when received.

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

A reference to a code defined by a terminology system.

Allows for alternative encodings within a code system, and translations to other code systems.

While the IPS-UV specification considers this a Must Support element, some systems will not have the ability to support codings for every codeableConcept, further feedback is required on whether these systems are still expected to be able to demonstrate they can construct this element when developing the patient summary instance.

Implementers that support codings should still send the codings for codeable concepts if they are available and receivers should not produce failures or rejections if codings are included in the patient summary in the first release (a base tenet of FHIR).

Additionally vendors should expect that some jurisdictions may further constrain support of this element within the context of their own jurisdictional content

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.

If true, indicates that the age value specified is an estimated value.

Clinicians often prefer to specify an estimaged age rather than an age range.

This element is labeled as a modifier because the fact that age is estimated can/should change the results of any algorithm that calculates based on the specified age.

It is unknown whether the age is an estimate or not

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.

Indicates when this particular annotation was made.

A concept that may be defined by a formal reference to a terminology or ontology or may be provided by text.

For all CodeableConcepts, at least one of coding or text must be present. If coding contains only a display value (no code) then CodeableConcept must include text.

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.

Indicates when this particular annotation was made.