Unified Conformance Guidance

Unified Conformance Guidance (across product lines)

This page is intended to collate information applicable across product lines

Project Scope

This project is intended to consolidate the HL7 guidance regarding conformance across product lines into a single specification that addresses conformance in a consistent way across all the HL7 standard specification:

• Analysis Models (Domain Analysis Models, Detailed Clinical Models)
• HL7 Version 2.x
• HL7 Version 3.0
• HL7 CDA
• HL7 Functional Model
• HL7 Service Functional Models
• HL7 FHIR Resource profiling

This specification may reference existing conformance guidance on specific product lines but it will identify generic concepts applicable across product lines (e.g. usability constraints on HL7 V2 messages structures, CDA documents, FHIR resource Definitions).This specification will document how constraint, templates, and profiles are used generically and then illustrate how each product line may add a specific type of conformance statement or product-specific extensibility rules. Additionally, this project will specify or reference best practices, analysis patterns, and other high-level requirements analysis approaches to ensure that HL7 analysis models and A third objective is to address constraints applied to functional and behavioral specification (e.g. service functional models) in order to create functional or service profiles and provide testable conformance statements.

On going activities

• FHIR Constraints and Rules

=="Abstract Conformance" Concepts"

Abstract Conformance: Information Structure and Semantics Conformance Concepts

Implementation Profile Model Package/Section

This package contains is a set of classes, associations, and data types along with the constraints applied to them to meet the needs of a specific project, based on the interoperability use cases. The classes in the implementation profile model are subject to elaboration and they are eventually related to product-specific construct such as CDA template, V2 profile or FHIR profile.

Focal Class(s)

An implementation profile model contains one or more focal classes. This class represents the business object at the center of the interoperability use case. It may be a "Patient" class if the interoperability requirements revolve around the state changes of a patient. Otherwise the focal class may "Encounter" if the messages deal with the admission/transfer/discharge of a patient. A constrained version of a focal class may result in a corresponding template depending profile on the product used for implementation. However, the constraints and conformance statements may be formulated in product-neutral terms using this abstract conformance definition.

Ancillary Classes

An ancillary class profile contains information associated with focal class that is constrained in a way consistent with the project requirements. The elements of ancillary classes may be subject to constraints resulting in profiles or templates.

Data type Profiles

A data type profile is a constrained specialization of an existing data type that is applicable to specific implementation guide and a certain set of interoperability use cases. The Data type Profile is used to replace the original data type in the definition of a class attribute. Since data types are product specific, this specification identifies the generic need to constraint the reusable data types used by an implementation guide.

Constraints

Constrains related to business requirements and the use cases supported by the IG. They are applied to any data elements to specify not only more detailed semantics but also data type, cardinality, usage, terminology, or fixed ====value constraints==== Since the Implementation Guide Model is primarily a way of representing constraints that may apply to a variety of platform-specific interchanges (e.g. HL7 Version 2.x and 3, CDA, FHIR, etc.) the types of constraints must be sufficiently generic to apply to any target product:

• Class and Attribute Semantics constraints are based on a consensus understanding of the data elements. The FHIM assigns meaning to classes, attributes, and associations between classes of objects. The semantics are transferred to the data elements (e.g. segments, fields, clinical statement, etc.)
• Associations constraints between object are specified very clearly in information my be under-defined or implied in the interoperability standards (e.g. as HL7 Version 2.x nested constructs). “Nesting” or “looping” segments is the typical way to identify how related classes of objects are related to each other using a typical messaging specification. Similarly, CDA documents imply associations between clinical statements/entries specified in different section of a document. The need to have a source-of-truth for associations between classes of objects is very important to understanding the context of a data element and removing any ambiguity.
• Data Element Usage/Mandatory constraints that identifying whether an association or attribute should appear in the FHIM domain or in specific payload based on the contents of one or more business domains.
• Cardinality or repetitions of an association or attributes. The cardinality is also used to identify a data element that is excluded/not supported. If the cardinality is 0..0 then the constraint will identify the data element is not supported in that implementation guide as specified in its interoperability use cases.
• A mandatory usage constraint specifies that a data element or association must be specified in a specific payload. The use of a specific optional element may be required for a specific interoperability use case. However, the IG will enforce specific mandatory elements that are intended to be present in any payload derived from a set of interoperability requirements detailed in a Conceptual or Logical Model (SAIF). This ensures consistency across use cases and across data representations.
• Usage keywords (e.g. SHALL, SHOULD, MAY) Some data elements specified as “optional” or “undefined” in the IG may be specified as “required” or “ not supported” in a specific use case. The constraints applied to the IG may be represented in an interchange-specific way but it is always very important to capture these requirements in a clear and reusable format.
• Data type constraints for complex data types (e.g. person name, address, telephone and other telecommunication numbers) that appear in the messages and document. This type of constraint results in constrained data structures that are reused in a single structure. The IG will identify which version of a constrained Person Name is assigned to a patient name in one context versus another. The ability to constrain and reuse these data types allows for harmonization of basic concepts such patient identify across information exchange standards. The data type constraints fall into two categories:
• Data type substitution (e.g. Any is replaced by ST) where a more generic data type is replaced by a more specific, derived data type. A class may specify a generic type while an implementation guide may require that the type be further constrained and replaced by a more specific type. This type of substitution is common to HL7 Version 3 and CDA implementation guides.
• Data type profiling (e.g. PN-Person Name- is constrained to specific set of use cases to contain a specific suffix). The data type profile is similarly substituted for that specified in the unconstrained/original class attribute.

• Vocabulary constraints apply to coded attributes. These constraints reference value sets or coding systems specified in the Vocabulary bindings associated with the IG.

• The vocabulary binding may specify the Coding System or Value set binding

• Value set allowed for coded attributes ▪ Value sets may be explicitly enumerated or predicate-based ▪ Additional validate constraints based on explicit value sets • Fixed value – in certain cases an attribute value is fixed for specific context. The constraints are the basis for generating computable test cases and the associated with the IG requirements.