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)
  • Conformance Clause - specifies the mandatory or optional profile components required for conformance to this IG using:
    • Conformance Statements - a normative statement or requirement.

The constraints below are specific conformance statements.

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.

Cross-Paradigm Constraints

Constrains as conformance clauses derived from interoperability requirements. These requirements are basis for implementation guides and they typically documented in a domain analysis model or an external requirements analysis document. Constraints are applied to HL7 specification in their various paradigms (i.e. messages, documents, or atomic resources) manage under HL7 Version 2.x, Version 3, CDA, and FHIR. They may be based on on one or more use case. They are applied to any data elements to narrow the semantics of the data elements in accordance to the project requirements, define an implementable data type, cardinality, usage, terminology, fixed values, or business rules conditions. This way implementers understand no only how to use the various data structures but also how populate those structures business-relevant information in accordance to the requirements detailed by the business stakeholders (i.e. specialty clinicians,

For consistent cross-paradigm implementations, it's important that the implementers have guidance that :

Semantic Constraints

Information Semantics

constraints are intended to clarify to implementers what type of business information an data element is intended to hold. The semantics constraints are based on the consensus understanding based on use case. It tells implementers how to populate or use a field/data element/structure with the most appropriate business information. The domain analysis model information is therefore transferred to individual data elements (e.g. segments, fields, clinical statement, etc.) that are used to meet the requirements.

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
• The vocabulary constraints use a well definedBinding Syntax to associate a vocabulary constraints to a data element

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 project 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 (e.g. 'Act' is replaced by 'CMET for a specific Act' or abstract data type replaced by a flavor). For CMETs this works like a macro expansion: 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).
• "Data type constraints" for a data element will replace a datatype with a data type flavor of the data type specified in the base standard (e.g. PN with a US-localized PN data type). In V3 a base data type could be replaced with a subtype (e.g CD may be replaced by CE).