Profiles innately form a logical hierarchy as levels of constraints are applied to the base standard. That is, profiling is typically an iterative process that proceeds from the base standard to intermediate levels (e.g., a national level profile), to local (implementation) levels. Three profile levels are defined:
Figure 2.1 illustrates the basic profile-level hierarchy and the degree of constraints applied at each level. The standard-level profile (hereafter called “standard profile”) represents the base standard definitions and constraints as-is and establishes the framework for a specific type of event (e.g., an unsolicited vaccination record update – VXU V04 message event). Treating the standard as a profile aids in related discussions and management. At this level, the overall structure (“template”), including the data type definitions, is established; however, the full declaration of requirements has yet to be specified, and, therefore, considerable openness still exists. For example, the allowable segments are defined, but the set of segments that are to be included for this use case has not yet been determined.
Additional profiles are subsequently derived from the standard profile. The standard profile can be defined more precisely by adding constraints for a desired use (e.g., the national level of requirements for the unsolicited vaccination record update message) to create a constrainable profile. A constrainable profile is derived from either the standard profile or another constrainable profile, and it further constrains the definition attributes in accordance to the profile compliance rules stipulated in this document. For example, a U.S. state-level constrainable profile can be derived from a national-level profile by adding more constraints for a specific state. Note, a U.S. state-level profile could have been created from the standard profile directly.
In a constrainable profile, analogous to the standard profile, not all element attributes are fully constrained. An implementable profile defines all elements such that all optionality and openness have been removed. All interfaces deployed in a production setting are implementable profiles whether they are documented (explicitly stated) or not documented (implicitly stated). It is recommended that interfaces be completely documented to the implementable profile level using the profiling mechanisms described in this specification.
An implementable profile may also be derived by further constraining another implementable profile. In this case, all openness has been removed, however additional constraints on attributes are applied; for example, the usage of “required, but may be empty” can be strengthened to “required” if the refined use case needs it to be.
Constraints are added iteratively, thereby forming a hierarchy of profile levels; but a certain set of rules must be followed. A profile can only further constrain, not relax, the requirements defined in its parent profile. For example, if an element (e.g., a field) is “required” in the parent profile, the element can’t be profiled to “optional” in a (compliant) child profile, because “optional” would be a relaxed requirement relative to “required”.
Conformity assessment can be conducted for each profile level. A complete assessment of the interface declaring conformance to an implementation profile can be determined. For standard-level and constrainable-level profiles, not all aspects can be determined. Declaring conformance to the base standard is generally of limited use to perspective stakeholders.
Two typical real-world scenarios demonstrating the use of the profile level model are presented in Figure 2.2. In the first case, a national-level constrainable profile is developed. A hospital (group) adopts and refines the national-level guidance provided in the realm-specific constrainable profile. The hospital procures a vendor’s product that can be configured to satisfy the requirements. The hospital and the vendor finalize the requirements and the software is installed. The resultant interface is documented as an implementable profile. Alternatively, the hospital could have provided their desired implementable profile directly to the vendor.
In the second case, a vendor refines the national-level guidance profile and provides a generic implementation based on this constrainable profile. When working with clients for whom this profile closely satisfies their requirements, a final refinement is made at the specific sites. The vendor often will (or should) provide the documentation for the installed interface in the form of an implementable profile. The examples shown in Figure 2.2 can be nested and refined to any depth as appropriate.