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

The following conformance clauses used define what a data element means, how it's populated, and how it would be encoded to enable interoperability according to the :

Information Semantics Constraints

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/Terminology Constraints

These constraints apply to coded data element and specify a standard-based terminology by referencing a value sets or coding systems

• Coding System (e.g. LOINC, SNOMED CT, RxNorm) or Value set binding specifies the allowed values for a coded data elements
  • to create a fully interoperable specification these constraints must be very clear
• Value sets may be explicitly enumerated or predicate-based set of allowable values
  • to create fully interoperable specifications these constraints must concrete, well-defined, and governed over tiem
• The vocabulary constraints use a well-defined Binding Syntax to associate a vocabulary constraints to a data element

Fixed Value Constraints

These constraints apply to 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.

Length and Pattern Constraints

These constraints apply to text data or date/time and specifies a format/pattern (e.g. Social Security Number), minimum lengths, and maximum length imitations. These are important constraint because a mismatch in max length could cause a data element to be truncated by a receiving system thus depriving clinicians of the full semantic meaning of that data element.

Structural Constraints

These constraints tell implementers how the structure of an HL7 message, document, or resource must be constrained to carry the information required by project/IG. HL7 standards use a combination of data element presence indicators with conditional predicates and cardinality with conditional predicates to specify which data elements are needed to meet the requirements of the project as documented by the IG.

Data Element Presence Indicator Constraints

These constraints have been used in some form since HL7 Version 2.2 was approved 30+ years ago. Known as"Optionality" before V2.5 or "Usage" in V2+ or "Supported" in FHIR, these constraints tell implementer whether data element or association is needed to meet the interoperability requirements specified by an IG.

• Usage keywords (e.g. SHALL, SHOULD, MAY, S, R, RE, X) indicate whether a data element or association is populate every time a message/document/resource is created or only under certain circumstances. An IG cannot eliminate data elements that are required to present according the base standards but may add data elements or explicitly identify optional data elements as "not applicable" (e.g. SHALL NOT, X).
• Mandatory or "Must Support" usage constraint specifies that null values are not allowed at implementation time. This is particularly relevant for HL7 V3 and CDA based IGs 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.
• Conditional predicates (e.g. conditionally present, conditionally excluded, conditionally valued) may be used to defined the special circumstances that control the presence of a data element. It is sometimes a way of reflecting business rules (e.g. if the patient is female, the number of minor children status must be populated).

Cardinality Constraints

These constraint specify the minimum and maximum occurrences of a data element or association according to the use case. The constraint must constrain not contradict the cardinality specified by the standard. The cardinality is also used to clarify that a data element is excluded/not supported by the IG. In addition to the presence indicator (if used), a cardinality of 0..0 explicitly specifies that a data element or association is not supported by a specific use case this use case.

• Conditional constraints These conditional predicates apply to repeated data elements and tell implementers how a specific occurrence of a data element must be populated based on a conditional predicated. In V2 this is manifested as several optional groups by one may be mandatory. In CDA it specifies that a section may contain different type of clinical statements but one type is mandatory (e.g. specify a "tobacco use" clinical statement is mandatory in the Social History section). In FHIR this type of constraint is referred as "slicing" and affects some reference to a choice of resources. In these cases if the implementers have a several choices for a repeated data element, ,the IG will specify that one occurrence of a data element must meet certain requirements (e.g. one of a provider's identifier must the National Provider Identifier, if known).

Type Constraints

• 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).

Length and Pattern Constraints

These constraints apply to text data or date/time and specifies a format/pattern (e.g. Social Security Number), minimum lengths, and maximum length imitations. These are important constraint because a mismatch in max length could cause a data element to be truncated by a receiving system thus depriving clinicians of the full semantic meaning of that data element.