A message profile is normally thought of as a complete message-structure definition with additional constraints applied to it as a “whole”. However, in some circumstances it is convenient and efficient to employ a modular approach to profile construction. A profile component defines a part or a certain aspect of a message definition and is used to aggregate correlated requirements and/or to differentiate requirements from another profile. It provides a mechanism to support a set of reusable requirements. A profile component can be applied to any construct or section of a message definition. A core profile is used to document the common set of requirements across the set of related profiles. A composite profile is the composition of a profile or core profile and one or more profile components. In the end, a composite profile is a profile with the distinction that the profile was created by combining a profile or core profile and one or more profile components. Profiles and profile components can be combined to develop and manage other profiles. A profile component in a family of profiles can be used to identify different levels of requirements for the same use case or to identify the differences in requirements for different, but closely related, use cases. Table 7.1 summarizes the profile building blocks.
|
Concept |
Definition |
|---|---|
|
Profile |
A message definition and a complete set of constraints applied to the message definition for a use case at the desired profile level. |
|
Core Profile |
A message definition and an incomplete set of constraints applied to the message definition for a use case at the desired profile level. A core profile document a set of common (base) requirements and is intended to be used in more than one composite profile. |
|
Profile Component |
A set of individual independent constraints linked to elements in a message definition. A profile component is used to document differential requirements and is a subset of a message definition. |
|
Composite Profile |
The composition of the profile or a core profile and one or more profile components. A composite profile is a profile but differs in the manner in which it was constructed. |
A profile component defines a part of or a certain aspect of a message definition and is used to differentiate requirements from another profile. A profile component can be applied to any construct or section of a profile. A profile component in a family of profiles can be used to identify different levels of requirements for the same use case or to identify the differences in requirements for different, but closely related, use cases.
Entries in a profile component will identify the element location and constraint value. Entries can apply to any element in the message definition and any constraint can be applied. Examples include specifying the usage for an element or defining a value set and binding that value set to an element.
In one case, a specification may need to express different levels of conformance. For example, a profile in the specification may be written to require the use of Object Identifiers (OIDs) for all Universal ID data elements. Another profile may be written in which use of OIDs for these data elements is not a requirement (i.e., other identifier types are allowed to be used). An intermediate profile may be written that requires certain, but not all, of these data elements to support the use of OIDs. This specification is, in principle, describing three levels (as mutually exclusive sets) of conformance requirements. These three profile levels can be described using a core profile definition and three profile components. The profile components describe the differences in the requirements (this approach can be thought of as a substitution mechanism).
In another case, a profile component may need to be employed to express requirements for a different, but closely related, use case. Here the creators of the new profile component leverage the requirements in an existing profile, since that existing profile contains many common requirements.
In the first case above, the use case is the same, but the requirements in which it can be achieved are different. The profile component is expressing a different level of conformance. In the second case above, the use case is similar, but there are several important differences, and, therefore, the requirements are different. The profile component concept is used to leverage the in-common requirements defined by the profile while allowing any different (additional) requirements to be defined in a profile component.
Profile components can be used as “building blocks” to specify a complete profile (set of requirements) as identifiable sub-units. As such, they can express common requirements, additional requirements, or substitute requirements. Profile components are an efficient utility to manage and define a family (a related set) of profiles.
The descriptions of the different conformance levels, profiles, and profile components should be contained in the conformance clause section of a specification. Based on the information provided in these descriptions, an implementer is able to make a conformance claim as to which profiles they support, and if applicable, the level of conformance they support.
A composite profile is a complete profile consisting of a profile or a core profile and one or more profile components. A composite profile is synonymous with a message profile but differs in that it comprises a set of sub-parts that represents the whole.
This section presents some examples of how profiles can be constructed using the profile building blocks. The examples provide a sampling of uses. When writing a set of related profiles (or a family of profiles), it is important to reuse the profile, core profile, and profile components in order to harmonize the requirements and to gain efficiency. The concepts of the profile levels and profile components provide an effective approach for managing and documenting extensions.
Figure 7.1 through Figure 7.5 illustrate possible configurations for composing a family of related profiles. One design principle is to develop a core profile that applies across a family of profiles with the intention of using the profile component concept to specify complete composite profiles.
In the first depiction (Figure 7.1), a core profile is developed that expresses all of the common requirements for a related set of profiles. Profile component A and profile component B are also created for aspects that are not defined (constrained) in the core profile. Combined, the three definitions are used to describe a complete specification, Profile 1 (composite profile).
For the second depiction (Figure 7.2), the core profile and profile component A are reused and combined with profile component C to specify Composite Profile 2.
In some use cases, a specifier may want to create profiles that differ slightly for the sender and the receiver profile. Profile components can be used to specify these sender and receiver profiles. Figure 7.3 shows an example in which a core profile is created along with a separate sender profile component and receiver profile component. A composite profile for each, the sender and receiver, is the outcome.
In the fourth depiction (Figure 7.4), Profile Y is combined with profile component D to create Composite Profile 3. Example 4 demonstrates how use case expansions can be managed. This may be the case where a complete profile for a given use case is defined, and another use case exists that extends the requirements. An example is laboratory reporting where a profile is created to submit laboratory results to an EHR-S and then extended to a second profile to submit reportable laboratory results to public health. The requirements for submitting to public health are specified in a profile component. Relating this to example 4, Profile Y is the laboratory reporting profile, profile component D documents the additional requirements for public health reporting, and Composite Profile 3 is the complete public health specification for reportable laboratory results. Another example is the case of national and local requirements. A typical domain for which localization is needed is public health, where a national-level profile is created and additional requirements (constraints) are specified at the state- or jurisdictional-level. A constrainable profile for the national level is created for a particular interaction (e.g., send immunization record). State-level requirements could be expressed in a profile component. When combined with the national-level profile, the result expresses the complete requirements for the state.
In this situation, using profile components provides an efficient mechanism to reuse and repurpose in order to accommodate a different, but closely related, use case. Profile components also help reduce implementation efforts by clearly indicating the essential differences.
Profile components also can express new requirements that replace requirements established in a profile or core profile. This approach often is used when different levels of profiles are developed, or when the profile provides utility outside the original intent of the profile. The fifth depiction (Figure 7.5) illustrates a case where a subset of requirements for an existing profile are overridden. Here, Profile Z is used; however, certain aspects are redefined according to the constraint rules and are documented in profile components E and F, which results in Composite Profile 4. It is important to note that if the new profile is intended to be a refinement in the existing profile hierarchy, then the requirement replacement is limited to further constraints (in essence, this is a level). However, if the intent is to establish a new specification to address a similar (but different) use case, then there is no restriction on the requirement replacement, since it is a new profile (i.e., it is not intended to be a specialization of the original). Here, the use of profile components is a mechanism to leverage an existing specification.
For each of the complete specifications illustrated in Figure 7.1 through Figure 7.5, the resulting profile can be a constrainable or an implementable profile.
The key design principles are that when related specifications are being developed, the authors should leverage as much information as possible from existing profiles, or they should design/create core profiles that are a harmonization of requirements for a related set of use cases. The profile components can be developed at any level of granularity; however, caution should be exercised when creating profile components at a fine-grained level or when specifying numerous details. Often, having to manage many building block artifacts can outweigh the benefits these artifacts are supposed to provide. If management tooling is available, then fine granularity of profile components is attainable. A good practice is to introduce an orthogonal structure of the individual requirements (e.g., data type constraints) in one case, message fragments (e.g., for insurance or diagnosis data) in a second case, and value set definitions in another instance, which would allow for easy integration and combinations (i.e., a data type specialization should not include a specific value set binding, as it significantly reduces the ability to reuse).
Frequently, standards developers fully specify each of a related set of profiles, entailing duplication of sizeable sections of the standards document. These profiles typically are not harmonized, which unnecessarily leads to inconsistences and maintenance issues. Furthermore, though it often occurs in practice, it is not a good idea to combine requirements targeted for different use cases (interactions) into a single profile definition. For each interaction, a separate profile needs to be defined, and the use of profile components, as described within, facilitates this approach.
The methodologies described are ideal for managing and creating customized interface products. A purchaser (e.g., a hospital) may want to know the capabilities of an interface in order to assess its suitability for a particular need. In most cases, the vendor provides an interface that supports many features, most of which typically are driven by market demand. The system is designed to be configurable so as to support a variety of specific interface needs. The use and documentation of profiles is a powerful mechanism to manage system configurations. In essence, each installation of an interface is an implementable profile whether it is documented explicitly or not. All of these aspects can be described exactly in the form of profiles as well. The vendor might publish what could be called a “configurable implementable profile”, which declares the implementation capabilities and allows a prospective purchaser to compare the profile to their needs. Once an interface has been installed, the capabilities are clearly defined and configured as the implementable profile, and, ideally, this profile is documented.
Many versions of the HL7 v2 base standard exist. Each version contains message definitions that are constrained by implementers for a given use case. The process of placing constraints on message definitions is called profiling. Typically, constraints are placed on a message definition defined entirely in a given version of the standard. In some cases, however, specifiers and implementers may want to use as a foundation a given version of the standard (e.g., 2.5.1) while selecting certain features offered by another version of the standard (e.g., 2.8.2). In essence, all HL7 v2 base standard versions can be viewed as a single collection of objects from which specifiers and implementers can pick and choose to construct message profiles. Implementation guides can contain message definitions from different versions of the standard and also could contain message definitions that contain objects from more than one version of the standard. The selective adoption only applies to the base version from which the message profile originates. Selective adoption does not apply to implementation guides. Aspects that need to be included from implementation guides can be included by using the profile component mechanism.
This section describes:
The HL7 v2 message profile is the governing artifact for specifying requirements for a message interface. Regardless of the base standard version designation, the profile modifies the standard- level definition to satisfy use case requirements. Such modifications can selectively include objects from different versions of the standard. Therefore, implementers must interpret the requirements based on the message profile (indicated in MSH-21) and not merely rely on the message version (indicated in MSH-12). This premise is true regardless of whether the message profile contains objects from a version other than the foundational version. The message profile declares a foundational version and, for every adopted object, the HL7 v2 version of that object.
In the context of selective adoption, the following terms are defined to help explain the process:
Object – an object from the HL7 v2 standard; can be any element (group, segment, field), data type, or table.
Adopted Object – an object from another version of the standard that is imported into a message profile.
Indigenous Object – an object from the foundational version of the message profile. Indigenous objects do not have an explicit version attribute. The version of the object is the version of the Foundational Version.
Foundational Version – this is the version of the base standard that serves as the core (starting) version of the message definition. All objects in the message profile will comply to this version unless explicitly overridden by an adopted object.
Adopted Version – this is the HL7 v2 version from which an object was adopted.
HL7 v2 has a very large installed base of implementations that are built on earlier versions of the standard. As use cases and needs evolved, so did the standard. For a given use case, some, but not all, features of the newer standard are needed or wanted. In such circumstances, specifiers and implementers may want to add only the features needed (and not be affected by other features that are not needed). Therefore, instead of requiring implementers to upgrade to a newer version of the standard, selective adoption allows them to upgrade only the parts needed for their use. For example, if a domain or a large installed base of interfaces already exists in version 2.5.1 of the standard, and if in an update to an implementation guide a few fields from version 2.8.2 are desired, then only those fields from version 2.8.2 need be included in the message profile definition. This approach likely will have the least impact on implementers. In any project, however, implementers must consider the pros and cons of each approach.
Three methods by which objects can be adopted into a message profile are available:
The details of each method are given in the sections to follow.
The selective pre-adoption method allows a profile definition to be created using a version of the standard while allowing adoption of objects from a later (newer) version (or versions) of the standard. This method is suitable when a specifier or implementer wishes to keep an implementation guide or implementation at the current version level while taking advantage of features from later (newer) versions of the standard. This approach has minimal impact on installed implementations.
Figure 7.6 shows an example of Selective Pre-adoption. An implementation guide is produced in which the foundation profiles are created with version 2.5.1 message definitions. The figure also shows that a segment, field, and table are pre-adopted from version 2.8.2 and a data type is pre-adopted from version 2.7. The pre-adopted objects are used to replace or extend existing objects in the foundational profile (message) definition. Note, the figure does not show the relationship of the pre-adopted objects in the message profiles, because, depending on how the implementation guide is constructed, this relationship can vary.
|
Object |
Example |
|---|---|
|
Table |
One example of a table pre-adoption comes from the laboratory results interface (LRI) implementation guide in which the foundational version of the message profile is 2.5.1, but an updated table definition from version 2.8.2 is sought. Table HL70078 (abnormal flags) in version 2.5.1 contains codes L (below low normal), LL (below lower panic limits), H (above high normal), and HH (above upper panic limits). For table HL70078 (named changed to “interpretation codes”) in version 2.8.2, another level of granularity was added to the code set: LU (very low) and HU (very high), which are levels between L and LL, and, H and HH, respectively. Additionally, the definitions of L, LL, H, and HH were refined. The LRI implementation guide pre-adopted the 2.8.2 version of the table, and this table replaced the 2.5.1 version of the table. |
|
Field |
An example of field pre-adoption comes from the laboratory orders (LOI) implementation guide in which OBX-26 through OBX-29 are pre-adopted from 2.8.1. These fields are not present in the foundational version is 2.5.1. LOI needed only OBX-29 but needed to include OBX-26 to OBX-28 in order to maintain field order. Those fields were kept as optional in the implementation guide. |
|
Segment |
An alternative for the prior example of field adoption is a segment adoption in which the entire 2.8.1 segment is pre-adopted (which would include all updates to those fields if any). This is in contrast to the field adoption in which the first 25 fields are defined as version 2.5.1 and the last 4 are defined as version 2.8.1. |
The selective post-adoption method allows a profile definition to be created using a version of the standard while allowing adoption of objects from an earlier (older) version (or versions) of the standard. This method is suitable when a specifier or implementer wishes to take advantage of the capabilities of a newer version of the standard but doesn’t want to use all upgrades. There may be aspects of the newer standard that the community (or established base) is not ready for, or the cost of such changes is prohibitive, or the earlier functionality suits the use case better. For example, it may be the case where a specifier wishes to use a later version of the standard for certain capabilities but wishes to keep current capabilities for a large installed base. However, if these capabilities have been deprecated (i.e., element changed to B or W) in the newer version of the standard, the specifier can "resurrect" the capabilities using post adoption.
Figure 7.7 shows an example of Selective Post-adoption. An implementation guide is produced in which the foundation profiles are created with version 2.8.2 message definitions. The figure also shows that two fields, a data type, and table are all post-adopted from version 2.5.1. The post-adopted objects are used to roll back capabilities to previous definitions of concepts. Note, the figure does not show the relationship of the post-adopted objects in the message profiles, because, depending on how the implementation guide is constructed, this relationship can vary.
The Selective Post-adoption from the current HL7 v2+ edition is fundamentally the same as the previously explained selective post-adoption. The key difference is that specifiers are limited to using the current v2+ edition as the foundational version.
The type and granularity of the objects (and their attributes) that can be adopted are limited. Below is a list of candidate objects:
|
Object |
Comments |
|---|---|
|
Abstract Message Definition |
Abstract message definitions (AMD) should not be modified to include additional segment definitions. If a desired new segment is needed, then the latest version of the standard should be used that includes that segment. Post adoption can be used for aspects desired from a previous version of the standard. Changing the AMD invalidates MSH-9. If a new AMD is needed, then that AMD should be created in a new version of the standard. |
|
Segment |
The segment would carry along with it the fields and all associated attributes (e.g., vocabulary bindings, tables, usage) from the adopted version. The segment would carry along with it the data types and all associated attributes. |
|
Field |
Fields that are added must maintain the order integrity of the fields in the adopted segments even though all fields may not be added. For example, if the foundational version of the segment has 11 fields, and the specifier wants to add fields 14 and 15 from another version, then fields 12 and 13 must “come along” in the adoption process. If there are more fields, say 16 and 17, then these fields need not come along. The fields would carry along with them the data types and all associated attributes (e.g., vocabulary bindings, tables, usage) from the adopted version. Therefore, the segment would have a mix of objects from various versions. Specifiers that are pre-adopting fields should be aware that some fields may have dependencies on other fields; this factor needs to be considered and addressed in an appropriate manner which may be to include the dependent fields. |
|
Data Type |
The data type can only be wholly adopted. Complex data types must contain data types of the same version (e.g., an XAD data type with a version of 2.5.1 must have components, both primitive and complex of version 2.5.1). Components can’t be added to data types (all or partial). Reason: Data types are fundamental building blocks and should not be implemented piecemeal. Data types are analogous to data types in programming languages. A data type is a “cohesive” concept. A Field references a pre-adopted data type (wholly) of the same root or a with compatible data type. Rules for data type substitution apply equally to data type adoption. For example, CWE version 2.7.1 for ID version 2.5.1 is permissible. |
|
Tables |
Tables (code sets) must be adopted wholly. Modifications can be made through profiling to create value sets. No single codes can be adopted; the addition or removal of a single code can be accomplished via profiling and creating a value set to which codes are added or are removed via exclusion. That is, in essence, individual codes can be “adopted” via value set creation mechanism. |