3.5. Retrieve MedMij Core - Treatment objective (zib2020/R4)

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

Allows identification of the goal 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 state of the goal throughout its lifecycle.

Allows knowing whether goal needs to be further tracked.

No zib concept can be mapped (implicitly) to this element. Unless .lifecycleStatus is explicitly recorded, TreatmentObjectives may assumed to be active.

Codes that reflect the current state of a goal and whether the goal is still being targeted.

Describes the progression, or lack thereof, towards the goal against the target.

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.

Indicates the progression, or lack thereof, towards the goal against the target.

Indicates a category the goal falls within.

Allows goals to be filtered and sorted.

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 for grouping and sorting goals.

Identifies the mutually agreed level of importance associated with reaching/sustaining the goal.

Used for sorting and presenting goals.

Extensions are available to track priorities as established by each participant (i.e. Priority from the patient's perspective, different practitioners' perspectives, family member's perspectives)

The ordinal extension on Coding can be used to convey a numerically comparable ranking to priority. (Keep in mind that different coding systems may use a "low value=important".

The level of importance associated with a goal.

A reference to a code defined by a terminology system.

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

Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.

The textual account of the treatment objective.

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.

This element is used to represent the zib concept DesiredHealthcareResult (NL-CM:13.5.5) if present. If instead DesiredHealthCondition::FunctionalOrMentalStatus is used (NL-CM:13.5.3), this element should be populated with a textual representation containg at least FunctionalOrMentalStatus.StatusName (NL-CM:4.26.2) and FunctionalOrMentalStatus.StatusValue (NL-CM:4.26.3).

Receiving systems that need to map back to the zib could look at .target.measure and .target.detailCodeableConcept; if these elements are absent, this element represents zib concept DesiredHealthcareResult. If present, the discrete data can be found in the aforementioned elements.

Coded description of the functional or mental status or limitation. Code systems used include:

• SNOMED CT
• ICF (International Classification of Functioning, Disability and Health)
• NOC (Nursing Outcomes Classification)
• OMAHA

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 to identify the value being tracked, e.g. body weight, blood pressure, or hemoglobin A1c level.

The extent to which the patient is limited by the functional or mental condition.

If both the status name and the status value are recorded in code, then both values must come from the same code system. If the patient uses a medical device, the evaluation of the extent of the limitation will take place without this aid.

The answer codes must be selected from the subselection of the code system corresponding with the request in accordance with the rules applicable to that system.

A CodeableConcept with just a text would be used instead of a string if the field was usually coded, or if the type associated with the Goal.target.measure defines a coded value.

Codes to identify the target value of the focus to be achieved to signify the fulfillment of the goal.

Indicates the date of the DesiredHealthCondition by which the goal should be met.

Identifies when the goal should be evaluated.

Please note that this definition differs from that of zib FunctionalOrMentalStatus. However, ZIB-1657 clarifies that in the current context, the StatusDate should be interpreted this way.

Identifies when the current status. I.e. When initially created, when achieved, when cancelled, etc.

To see the date for past statuses, query history.

Captures the reason for the current status.

This will typically be captured for statuses such as rejected, on-hold or cancelled, but could be present for others.

Indicates whose goal this is - patient goal, practitioner goal, etc.

This is the individual responsible for establishing the goal, not necessarily who recorded it. (For that, use the Provenance resource.).

Indicates when this particular annotation was made.

Explanatory comments as a description of the functional or mental status.

Systems are not required to have markdown support, so the text should be readable without markdown processing. The markdown syntax is GFM - see https://github.github.com/gfm/

Identifies the change (or lack of change) at the point when the status of the goal is assessed.

Outcome tracking is a key aspect of care planning.

Note that this should not duplicate the goal status.

The result of the goal; e.g. "25% increase in shoulder mobility", "Anxiety reduced to moderate levels". "15 kg weight loss sustained over 6 months".

Details of what's changed (or not changed).

Outcome tracking is a key aspect of care planning.

The goal outcome is independent of the outcome of the related activities. For example, if the Goal is to achieve a target body weight of 150 lb and a care plan activity is defined to diet, then the care plan’s activity outcome could be calories consumed whereas goal outcome is an observation for the actual body weight measured.