This page is part of the HL7 FHIR Implementation Guide for Military Service History and Status (v1.0.0: STU1) based on FHIR R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions

Profile Conformance

Profile Base

Most MSH profiles are based on US Core profiles defined in the US Core Implementation Guide (v3.1.1). For example, the US Veteran profile is based on the US Core Patient profile. Because of the way profiles work in FHIR, any resource that validates against an MSH profile that is based a US Core profile will automatically be in compliance with the US Core profile and the associated US Core Data for Interperability (USCDI) data element required by US regulation.

• Military Service Episode profile can be used to create Observatoin resources that describe a Veteran’s military service history; it includes references to Deployment Episode and Military Occupation.

• Military Occupationis similar to ODH PastOrPresentJob. It is referenced by Military Service Episode.

Where US Core does not provide an appropriate base profile, this implementation profiles FHIR resources directly as described below:

Profile	Based on US Core?
Deployment History Episode	No
Military Occupation	No
Military Service Episode	No
US Veteran	Yes

Conformance to MSH Profiles

Each MSH profile expresses requirements and expectations for FHIR instances in terms of structural constraints and terminology bindings. If an instance is required to conform with an MSH profile, it MUST validate against that profile.

Data Sender Expectations

Each MSH profile has a conformance statement describing what data or FHIR instances MUST or SHOULD conform to it.

Data Receiver Expectations

An MSH Data Receiver SHOULD perform validation on instances it receives. The Receiver first of all needs to identify which profile to use for validation. There four ways to identify the correct profile:

1. The instance is received in response to a profile search, so the validating profile is known in advance.

2. The instance self-identifies using meta.profile. Every Data Sender SHALL populate this element to specify which type of information was used/provided to consumer/receivers of military service history.

3. The Data Receiver can examine the contents of the instance to associate it with a profile (in particular, by looking for identifying code or category).

4. The Data Receiver can iteratively attempt to validate the instance against each of the Data Receiver’s supported profiles.

If an instance fails validation, the Receiver may reject the instance.

Element-Level Expectations

Sender and Receiver Expectations

For every element that is required and/or carries a Must Support obligation (MS):

• MSH Data Senders SHALL be capable of populating the element, provided the Sender supports the profile (as indicated by its CapabilityStatement).

• If the Sender lacks the data necessary to populate the element:

  • If the element is required, the US Core rules on missing data MUST be followed.

  • If the element is not required (but is MS), the element SHOULD be entirely omitted. If there is a specific reason the data is missing, a data absent reason MAY be substituted.

  • Senders MUST NOT substitute a nonsense or filler value just to satisfy MS or cardinality requirement.

• MSH Data Receivers SHALL be capable of meaningfully processing MS elements, provided the Receiver supports the profile. Depending on context, “meaningfully process” might mean displaying the data element for human use, reacting to it, or storing it for other purposes.

Required Elements

An MSH data element is required if any of the following criteria are met:

• The element is a top-level element (a first-level property of the resource) and its minimum cardinality is > 0 in the profile.

• The element not a top-level element (a second-level property or below), its minimum cardinality is > 0, and all elements directly containing that element have minimum cardinality > 0 in the profile.

• The element is not a top-level element, its minimum cardinality is > 0, and its immediate higher-level containing element exists in an instance attempting to conform to the profile.

In other words, a data element may be 1..1, but if it is contained by an optional element, then it is not required unless its containing element is actually present.

Must Support Obligations

Interpretation of MS is not straightforward, as there is a difference between a MS obligation and a MS flag. The MS flag is the red S displayed on profile pages: S. A MS obligation means the element must be treated as described in Sender and Receiver Expectations. Significantly, an MS flag (S) does not necessarily imply an MS obligation, and MS obligations may be attached to elements lacking MS flags.

To see which elements have MS flags, consult the “Snapshot Table” view of the profile. The “Differential Table” view hides MS flags inherited from the parent profile. The “Snapshot Table (Must Support)” view reflects the IG Publisher’s interpretation of how MS flags translate to MS obligations, which may or may not coincide with the US Core/MSH interpretation.

The following rules apply in MSH:

• A profile without a MS flag does not have to be supported ¹. A participant MUST declare support for optional profiles in its CapabilityStatement.

• Any MS flag or flags on an unsupported profile (as stated in participant’s CapabilityStatement) do not carry MS obligations.

• An element with an MS flag does not carry an MS obligation if it is nested and any one of the elements directly containing that element lacks an MS flag. However, if the participant elects to support the unflagged element or elements in that hierarchy, the elements below the gap then carry an MS obligation.

• An element with an MS flag whose cardinality is 0..0 does not carry an MS obligation ².

• A required element carries a MS obligation on the part of a Data Sender, regardless of whether that element has an MS flag.

• A required element without an MS flag does not carry an MS obligation for the Data Receiver ³.

Non-Must Support Elements

Data elements in MSH that do not have MS obligations still MAY be supported. If an element is supported, whether it has a MS flag or not, the profile must be interpreted as if the MS flag were present. For example, Observation.category does not have an MS flag, but a data receiver may implement the capability to display it.