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)
  • typically a source of requirements and constraints
  • CIMI - similar to DAMs they provide business requirements and are source of constraints
• HL7 Version 2.x (Profiles per transaction, profile components, datatype flavors, IGs similar to Integration Profiles )
• HL7 Version 3.0 (CMETS are similar to V2 profile components and FHIR resource profiles)
• HL7 CDA R2 (Template per doc/section/clinical statement, IGs for multiple doc)
• HL7 FHIR Resources (Profiles per resource or per bundle, IGs similar Integration Profiles)

• HL7 Functional Model (Functional profiles, conformance criteria high-level can be leveraged by Integration Profiles/IGs )
• HL7 Service Functional Models (Capabilities and operations references to other profiles/templates starts an OMG RFP process)

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: Information Structure and Semantics Conformance Concepts

Implementation Guide Modeling

An Implementation Guide (IG) describes how a product line is used to meet one or more interoperability use cases. An IG describes constraints applied to data structure in a base standard. A set of constraints applied to a FHIR or HL7 data structure is typically known as "profile". The IG describes how set of related standard data structures (e.g. classes, resources, segments) had to be constrained to meet interoperability use cases. The IG constraints have to testable and they must elaborate the semantics of the base standard such that implementers can reach semantic interoperability.

• Use cases
  • Scenarios
  • Use case description
  • Alternate Scenario
• Actors
• Interactions/Transactions (request/response, query, unsolicited notifications)
• Structure Definitions (V2 message profiles, CDA document templates, FHIR profiles)

Focal Structure (s)

When constraining a standard, it is necessary to identify where the constraints are placed in order to meet the business and interoperability requirements: An implementation guide identifies at least one focal structure that identifies the domain and scope of interoperability:

• messages structure (e.g. HL7 Version ORU_R01),
• document structure (e.g. CDA, HQMF), Section, Entry/Clinical
• resource (e.g. FHIR Patient, Composition, Bundle)
• class (e.g. HL7 Version 3 Encounter class).

This focal structure 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 structure may result in a corresponding template/profile. This document proposes to describe the constraints and conformance statements may be formulated in product-neutral terms using this abstract conformance definition.

Ancillary Structure(s)

An ancillary structure profile contains information associated with focal structure that is constrained in a way consistent with the project requirements. The elements of ancillary classes may be subject to additional constraints resulting in profiles or templates. CDA Clinical Statements templates are examples of ancillary structure (clinical statements in entries) that support the detailed interoperability requirements of the IG.

Data type Profiles (aka Flavor)

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. This type of element allows localized constraints in a consistent way.

• Examples: Address in US may be required to include "county" for specific IGs; therefore two related "address flavors" may be created and referenced when the requirements call for address with or without "county" information.

Constraints

Constrains are related and derived from requirements documented as the use cases (included in 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.

Element 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:

Semantic Constraints

• Data Semantics (e.g. meaning of segments, fields, CMET,resource, clinical statements, class, attribute) constraints are based on a consensus understanding of the data elements meaning in that use case. This is a clue to implement on how to populate or use a field/data element/structure. As the domain analysis meaning to data elements and associations between data elements. The semantics are transferred to the data elements (e.g. segments, fields, clinical statement, etc.) that are used to to implement business data sets.
• 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

add reference to "value set binding" wiki page

• Fixed value apply to certain text or coded data element; 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.

Structural Constraints

• 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.
  • FHIR Slicing, V3 Occurrence Constraints
• Data Element Usage (aka "Optionality" before V2.5 or "Usage" in V2+) constraints that identifying whether an association or attribute should appear in the business domain or in specific payload based on the contents of one or more business domains. The conformance keywords are more effective than conformance statements.
  • Usage keywords (e.g. SHALL, SHOULD, MAY) may be used to create conformance statements. 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.
• Cardinality (or repetitions, occurrences) Constraint specifies occurrences according to the use case; cardinality is also used to identify if a data element 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 or "Must Support" usage constraint specifies that null values are not allowed. 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.
• Type substitution for V3 only (e.g. 'Act' is replaced by 'CMET for a specific Act') works like a macro to expand a single class to a structure. A minimum structure (e.g. Act) could be replaced by a structure that represents "maximum representation" (e.g. a CMET that has Act has a focal class).