A summary or overview of a single health condition, injury, disability, or any other issue that impacts the physical, mental and/or social well-being of an individual.

Purpose

To record summary information about a single problem or diagnosis.

Misuse

Not to be used to record summary information about a single pregnancy. The clinical requirements for recording summary details about a pregnancy are quite different to typical problems and diagnoses and therefore out of scope for this data group. It is anticipated that a separate ‘Pregnancy summary’ data group will be proposed for future releases of AUCDI. Note: problems or diagnoses identified during the pregnancy or as direct complications of the pregnancy may be added using this data group – for example, ‘Gestational diabetes’, ‘Pre-eclampsia’ or ‘Urinary tract infection’.

Considerations

Both problems or diagnoses can be recorded using this same data model without distinguishing and labelling them as one or the other. The recording pattern is closely aligned, and what may initially be considered a ‘soft’ problem may evolve towards a formal diagnosis as more clinical evidence is discovered.

In future updates, it is anticipated this data group will be extended to incorporate additional detail.

@ internal @

Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.

May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.

Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.

The date when this 'Problem/Diagnosis summary' data group was last updated.

Considerations

For example:

• 7 February 2015
• 7 February 2015, 1:28 pm
• 2015-02-07T13:28:17-05:00

Additional information required to capture local content or to align with other reference models/formalisms.

Considerations

For example: local information requirements or additional metadata to align with FHIR or CIMI equivalents.

@ internal @

Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.

May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.

Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.

Identification of the problem or diagnosis, by name.

Considerations

It is strongly recommended that the ‘Problem/Diagnosis name’ be coded with a terminology capable of triggering decision support, where possible. Free text entry should only be permitted if no appropriate coded value is available.

Example

SNOMED CT-AU:

• 195967001|Asthma|
• 46635009|Diabetes Mellitus Type 1|
• 13746004|Bipolar disorder|
• 307608006|Ewing's sarcoma of bone|
• 254837009|Malignant neoplasm of breast|
• 44465007|Sprain of ankle|
• 112981000119107|Bilateral osteoarthritis of knees|
• 20902002|Fall from bed|
• 315604002|Missed contraceptive pill|

Specific variant or subtype of the Diagnosis, if relevant.

Considerations

For example: 'acute motor axonal neuropathy' as a variant of Guillain-Barre Syndrome. Coding of the name of the variant with a terminology is preferred, where possible.

Narrative description about the problem or diagnosis.

Considerations

Use to provide background and context, including evolution, episodes or exacerbations, progress and any other relevant details, about the problem or diagnosis.

The anatomical location or body structure where the 'Problem or diagnosis' is manifested including laterality.

Considerations

Specification of ‘Body site’ is recommended when it is necessary to provide additional clarity about the Problem/Diagnosis and the ‘Problem/Diagnosis name’ does not include or imply a specific body site.

This data element has multiple occurrences to allow the recording of more than one body site for each problem or diagnosis – for example, to record multiple skin sites affected by a rash.

It is strongly recommended that the ‘Body site’ be coded with a terminology, where possible. Free text entry should only be permitted if no appropriate coded value is available.

Example

SNOMED CT-AU:

• 761920005|Bone structure of shaft of right humerus|
• 51636004|Left ankle|
• 38033009|Amputation stump|
• 110501003|Upper outer quadrant of left breast|

A structured anatomical location for the problem or diagnosis.

Considerations

Use this SLOT to insert the CLUSTER.anatomical_location or CLUSTER.relative_location archetypes if the requirements for recording the anatomical location are determined at run-time by the application or require more complex modelling such as relative locations.

If the anatomical location is included in the Problem/diagnosis name via precoordinated codes, use of this SLOT becomes redundant.

A cause, set of causes, or manner of causation of the problem or diagnosis.

Considerations

Also known as 'aetiology' or 'etiology'. Coding with an external terminology is preferred, where possible.

Estimated or actual date/time that signs or symptoms of the problem/diagnosis were first observed.

Considerations

Data captured/imported as "Age at onset" should be converted to a date using the subject's date of birth.

Estimated or actual date/time the diagnosis or problem was recognised by a healthcare professional.

Considerations

Partial dates are acceptable. If the subject of care is under the age of one year, then the complete date or a minimum of the month and year is necessary to enable accurate age calculations - for example, if used to drive decision support. Data captured/imported as "Age at time of clinical recognition" should be converted to a date using the subject's date of birth.

An assessment of the overall severity of the problem or diagnosis.

Considerations

If severity is included in the Problem/diagnosis name via precoordinated codes, this data element becomes redundant. Note: more specific grading of severity can be recorded using the Specific details SLOT.

Details that are additionally required to record as unique attributes of this problem or diagnosis.

Considerations

May include structured detail about the grading or staging of the diagnosis; diagnostic criteria, classification criteria or formal severity assessments such as Common Terminology Criteria for Adverse Events.

Narrative description about the course of the problem or diagnosis since onset.

Estimated or actual date/time of resolution or remission for this problem or diagnosis, as determined by a healthcare professional.

Considerations

Partial dates are acceptable. If the subject of care is under the age of one year, then the complete date or a minimum of the month and year is necessary to enable accurate age calculations - for example, if used to drive decision support. Data captured/imported as "Age at time of resolution" should be converted to a date using the subject's date of birth.

A clinical assertion whether a problem or diagnosis is currently active or inactive.

Considerations

None

The level of confidence in the identification of the diagnosis.

Considerations

If an alternative valueset is required, these values can be added to the DV_TEXT data type in a template.

Additional narrative about the problem or diagnosis not captured in other fields.

Considerations

None

@ internal @

Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.

May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.

Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.

A summary or overview of a single health condition, injury, disability, or any other issue that impacts the physical, mental and/or social well-being of an individual.

Purpose

To record summary information about a single problem or diagnosis.

Misuse

Not to be used to record summary information about a single pregnancy. The clinical requirements for recording summary details about a pregnancy are quite different to typical problems and diagnoses and therefore out of scope for this data group. It is anticipated that a separate ‘Pregnancy summary’ data group will be proposed for future releases of AUCDI. Note: problems or diagnoses identified during the pregnancy or as direct complications of the pregnancy may be added using this data group – for example, ‘Gestational diabetes’, ‘Pre-eclampsia’ or ‘Urinary tract infection’.

Considerations

Both problems or diagnoses can be recorded using this same data model without distinguishing and labelling them as one or the other. The recording pattern is closely aligned, and what may initially be considered a ‘soft’ problem may evolve towards a formal diagnosis as more clinical evidence is discovered.

In future updates, it is anticipated this data group will be extended to incorporate additional detail.

@ internal @

Identification of the problem or diagnosis, by name.

Considerations

It is strongly recommended that the ‘Problem/Diagnosis name’ be coded with a terminology capable of triggering decision support, where possible. Free text entry should only be permitted if no appropriate coded value is available.

Example

SNOMED CT-AU:

• 195967001|Asthma|
• 46635009|Diabetes Mellitus Type 1|
• 13746004|Bipolar disorder|
• 307608006|Ewing's sarcoma of bone|
• 254837009|Malignant neoplasm of breast|
• 44465007|Sprain of ankle|
• 112981000119107|Bilateral osteoarthritis of knees|
• 20902002|Fall from bed|
• 315604002|Missed contraceptive pill|

Specific variant or subtype of the Diagnosis, if relevant.

Considerations

For example: 'acute motor axonal neuropathy' as a variant of Guillain-Barre Syndrome. Coding of the name of the variant with a terminology is preferred, where possible.

Narrative description about the problem or diagnosis.

Considerations

Use to provide background and context, including evolution, episodes or exacerbations, progress and any other relevant details, about the problem or diagnosis.

The anatomical location or body structure where the 'Problem or diagnosis' is manifested including laterality.

Considerations

Specification of ‘Body site’ is recommended when it is necessary to provide additional clarity about the Problem/Diagnosis and the ‘Problem/Diagnosis name’ does not include or imply a specific body site.

This data element has multiple occurrences to allow the recording of more than one body site for each problem or diagnosis – for example, to record multiple skin sites affected by a rash.

It is strongly recommended that the ‘Body site’ be coded with a terminology, where possible. Free text entry should only be permitted if no appropriate coded value is available.

Example

SNOMED CT-AU:

• 761920005|Bone structure of shaft of right humerus|
• 51636004|Left ankle|
• 38033009|Amputation stump|
• 110501003|Upper outer quadrant of left breast|

A structured anatomical location for the problem or diagnosis.

Considerations

Use this SLOT to insert the CLUSTER.anatomical_location or CLUSTER.relative_location archetypes if the requirements for recording the anatomical location are determined at run-time by the application or require more complex modelling such as relative locations.

If the anatomical location is included in the Problem/diagnosis name via precoordinated codes, use of this SLOT becomes redundant.

A cause, set of causes, or manner of causation of the problem or diagnosis.

Considerations

Also known as 'aetiology' or 'etiology'. Coding with an external terminology is preferred, where possible.

Estimated or actual date/time that signs or symptoms of the problem/diagnosis were first observed.

Considerations

Data captured/imported as "Age at onset" should be converted to a date using the subject's date of birth.

Estimated or actual date/time the diagnosis or problem was recognised by a healthcare professional.

Considerations

Partial dates are acceptable. If the subject of care is under the age of one year, then the complete date or a minimum of the month and year is necessary to enable accurate age calculations - for example, if used to drive decision support. Data captured/imported as "Age at time of clinical recognition" should be converted to a date using the subject's date of birth.

An assessment of the overall severity of the problem or diagnosis.

Considerations

If severity is included in the Problem/diagnosis name via precoordinated codes, this data element becomes redundant. Note: more specific grading of severity can be recorded using the Specific details SLOT.

Details that are additionally required to record as unique attributes of this problem or diagnosis.

Considerations

May include structured detail about the grading or staging of the diagnosis; diagnostic criteria, classification criteria or formal severity assessments such as Common Terminology Criteria for Adverse Events.

Narrative description about the course of the problem or diagnosis since onset.

Estimated or actual date/time of resolution or remission for this problem or diagnosis, as determined by a healthcare professional.

Considerations

Partial dates are acceptable. If the subject of care is under the age of one year, then the complete date or a minimum of the month and year is necessary to enable accurate age calculations - for example, if used to drive decision support. Data captured/imported as "Age at time of resolution" should be converted to a date using the subject's date of birth.

A clinical assertion whether a problem or diagnosis is currently active or inactive.

Considerations

None

The level of confidence in the identification of the diagnosis.

Considerations

If an alternative valueset is required, these values can be added to the DV_TEXT data type in a template.

Additional narrative about the problem or diagnosis not captured in other fields.

Considerations

None

@ internal @

The date when this 'Problem/Diagnosis summary' data group was last updated.

Considerations

For example:

• 7 February 2015
• 7 February 2015, 1:28 pm
• 2015-02-07T13:28:17-05:00

Additional information required to capture local content or to align with other reference models/formalisms.

Considerations

For example: local information requirements or additional metadata to align with FHIR or CIMI equivalents.

A summary or overview of a single health condition, injury, disability, or any other issue that impacts the physical, mental and/or social well-being of an individual.

Purpose

To record summary information about a single problem or diagnosis.

Misuse

Not to be used to record summary information about a single pregnancy. The clinical requirements for recording summary details about a pregnancy are quite different to typical problems and diagnoses and therefore out of scope for this data group. It is anticipated that a separate ‘Pregnancy summary’ data group will be proposed for future releases of AUCDI. Note: problems or diagnoses identified during the pregnancy or as direct complications of the pregnancy may be added using this data group – for example, ‘Gestational diabetes’, ‘Pre-eclampsia’ or ‘Urinary tract infection’.

Considerations

Both problems or diagnoses can be recorded using this same data model without distinguishing and labelling them as one or the other. The recording pattern is closely aligned, and what may initially be considered a ‘soft’ problem may evolve towards a formal diagnosis as more clinical evidence is discovered.

In future updates, it is anticipated this data group will be extended to incorporate additional detail.

@ internal @

Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.

May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.

Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.

The date when this 'Problem/Diagnosis summary' data group was last updated.

Considerations

For example:

• 7 February 2015
• 7 February 2015, 1:28 pm
• 2015-02-07T13:28:17-05:00

Additional information required to capture local content or to align with other reference models/formalisms.

Considerations

For example: local information requirements or additional metadata to align with FHIR or CIMI equivalents.

@ internal @

Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.

May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.

Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.

Identification of the problem or diagnosis, by name.

Considerations

It is strongly recommended that the ‘Problem/Diagnosis name’ be coded with a terminology capable of triggering decision support, where possible. Free text entry should only be permitted if no appropriate coded value is available.

Example

SNOMED CT-AU:

• 195967001|Asthma|
• 46635009|Diabetes Mellitus Type 1|
• 13746004|Bipolar disorder|
• 307608006|Ewing's sarcoma of bone|
• 254837009|Malignant neoplasm of breast|
• 44465007|Sprain of ankle|
• 112981000119107|Bilateral osteoarthritis of knees|
• 20902002|Fall from bed|
• 315604002|Missed contraceptive pill|

Specific variant or subtype of the Diagnosis, if relevant.

Considerations

For example: 'acute motor axonal neuropathy' as a variant of Guillain-Barre Syndrome. Coding of the name of the variant with a terminology is preferred, where possible.

Narrative description about the problem or diagnosis.

Considerations

Use to provide background and context, including evolution, episodes or exacerbations, progress and any other relevant details, about the problem or diagnosis.

The anatomical location or body structure where the 'Problem or diagnosis' is manifested including laterality.

Considerations

Specification of ‘Body site’ is recommended when it is necessary to provide additional clarity about the Problem/Diagnosis and the ‘Problem/Diagnosis name’ does not include or imply a specific body site.

This data element has multiple occurrences to allow the recording of more than one body site for each problem or diagnosis – for example, to record multiple skin sites affected by a rash.

It is strongly recommended that the ‘Body site’ be coded with a terminology, where possible. Free text entry should only be permitted if no appropriate coded value is available.

Example

SNOMED CT-AU:

• 761920005|Bone structure of shaft of right humerus|
• 51636004|Left ankle|
• 38033009|Amputation stump|
• 110501003|Upper outer quadrant of left breast|

A structured anatomical location for the problem or diagnosis.

Considerations

Use this SLOT to insert the CLUSTER.anatomical_location or CLUSTER.relative_location archetypes if the requirements for recording the anatomical location are determined at run-time by the application or require more complex modelling such as relative locations.

If the anatomical location is included in the Problem/diagnosis name via precoordinated codes, use of this SLOT becomes redundant.

A cause, set of causes, or manner of causation of the problem or diagnosis.

Considerations

Also known as 'aetiology' or 'etiology'. Coding with an external terminology is preferred, where possible.

Estimated or actual date/time that signs or symptoms of the problem/diagnosis were first observed.

Considerations

Data captured/imported as "Age at onset" should be converted to a date using the subject's date of birth.

Estimated or actual date/time the diagnosis or problem was recognised by a healthcare professional.

Considerations

Partial dates are acceptable. If the subject of care is under the age of one year, then the complete date or a minimum of the month and year is necessary to enable accurate age calculations - for example, if used to drive decision support. Data captured/imported as "Age at time of clinical recognition" should be converted to a date using the subject's date of birth.

An assessment of the overall severity of the problem or diagnosis.

Considerations

If severity is included in the Problem/diagnosis name via precoordinated codes, this data element becomes redundant. Note: more specific grading of severity can be recorded using the Specific details SLOT.

Details that are additionally required to record as unique attributes of this problem or diagnosis.

Considerations

May include structured detail about the grading or staging of the diagnosis; diagnostic criteria, classification criteria or formal severity assessments such as Common Terminology Criteria for Adverse Events.

Narrative description about the course of the problem or diagnosis since onset.

Estimated or actual date/time of resolution or remission for this problem or diagnosis, as determined by a healthcare professional.

Considerations

Partial dates are acceptable. If the subject of care is under the age of one year, then the complete date or a minimum of the month and year is necessary to enable accurate age calculations - for example, if used to drive decision support. Data captured/imported as "Age at time of resolution" should be converted to a date using the subject's date of birth.

A clinical assertion whether a problem or diagnosis is currently active or inactive.

Considerations

None

The level of confidence in the identification of the diagnosis.

Considerations

If an alternative valueset is required, these values can be added to the DV_TEXT data type in a template.

Additional narrative about the problem or diagnosis not captured in other fields.

Considerations

None

@ internal @

Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces.

May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

May be used to represent additional information that is not part of the basic definition of the element and that modifies the understanding of the element in which it is contained and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.

Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).

There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.

Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.