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 (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)
• CIMI...
• 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)
• HL7 FHIR Resources (Profiles per resource or per bundle, IGs similar Integration Profiles)

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)

An implementation guide identifies at least one focal structure that identifies the domain and scope of interperability:

• messages structure (e.g. HL7 Version ORU_R01),
• document structure (e.g. CDA, HQMF),
• resource (e.g. FHIR Patient, or
• 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

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. 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 the data sets.
• 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 business 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.