SAIF Artifact List

Proposed organization 1

Candidate Artifact Grouping

The artifacts can be grouped into a number of specifications. These specifications are in fact artifacts themselves and have relationships to each other. In general, *Service Specifications* describe the means to participate in healthcare-oriented interactions. *Solution Specifications* describe communities of systems, some of which may be implementing Service Specifications, that are participating in healthcare-oriented interactions. Specifications ultimately describe what it means to conform to HL7 within a particular context.

• Service Specifications* provide a leveled approach to conformance via the SAIF's ECCF Framework. The conceptual, logical, and implementable levels provide layers of refinement in defining informational and computational components, while taking into account potential overarching requirements from the business and the engineering views. Services are thus defined as sets of behaviors that contextualize information. These behaviors are described as interfaces.
  • Build a Conceptual Model if you need to bind a solution to a set of business analyses, or if you wish to state abstracted assumptions for future refactoring. These abstract assumptions could include architectural patterns or design patterns.
  • Build a Logical Model to further specify a conceptual model, to achieve more semantic precision, or to implement design patterns or implementation patterns.
  • Build an implementable model if a logical model is not implementable as is, if the logical model does not contain enough specificity to be useful in an implementation, if particular platform models need to be intersected to make a logical model more clear to implementers, or if particular transforms (and their consequences) need to be part of a specification stack.

• Solution Specifications* stitch together systems into a community that observes contractually defined behaviors to achieve a goal. These systems take on roles in the community by implementing particular behaviors, that is, interfaces. Contracts are invoked by invoking operations defined on interfaces.

Both types of specifications may comply with any number of other standards or specifications. Thus, information described using RIM modeling and R2 Datatypes can be used in a specification, or an interface may be designed to be compliant with W3C Reliability.

In addition, some artifacts are foundational to HL7, and don't necessarily belong in a specification. These are grouped in the Foundation Artifacts section.

Service Conceptual Specification

• Conceptual Information Model
• State Model
• Flows of Information
• Operation
  • Identity
  • Name
  • Description
  • Inputs - tied to concepts from Conceptual Model
  • Outputs - tied to concepts from Conceptual Model
  • Pre-conditions (tied to trigger events, potentially)
  • post-conditions (tied to trigger events, potentially)
  • Invariants
  • Exception Conditions - tied to vocabulary defined in Conceptual Information Model
• Profiles
  • Behavioral Profiles - groupings of operations that meet particular communities of stakeholders
  • Semantic Profiles - Information Models associated with Conceptual Information Models
  • Conformance Profiles - Sets of Computational and Semantic Profiles required for conformance

Service Logical Specification

• Serializable Information Model
• State Model
• Flows of Information
• Operation
  • Identity
  • Name
  • Description
  • Message Exchange Pattern (In, Out, In / Out, Out / In)
  • Inputs - tied to graphs from Serializable Information Model
  • Outputs - tied to graphs from Serializable Information Model
  • Pre-conditions (tied to trigger events, potentially)
  • post-conditions (tied to trigger events, potentially)
  • Invariants
  • Exceptions - defined in vocabulary in Serializable Information Model, or in stack
• Profiles
  • Behavioral Profiles - groupings of operations that meet particular communities of stakeholders
  • Semantic Profiles - Information Models associated with Conceptual Information Models
  • Conformance Profiles - Sets of Computational and Semantic Profiles required for conformance
  • Compliance Notes - Discussion of which conceptual specs, as well as other standards or specifications, this specification complies with

Service Implementable Specification

• ?Localized Information Model? (need to define what this is better. Is it just 'incomplete' models?)
• State Model
• Flows of Information
• Operation
  • Identity
  • Name
  • Description
  • Message Exchange Pattern (In, Out, In / Out, Out / In)
  • Inputs - tied to graphs from Localized Information Model
  • Outputs - tied to graphs from Localized Information Model
  • Pre-conditions (tied to trigger events, potentially)
  • post-conditions (tied to trigger events, potentially)
  • Invariants
  • Exception - Defined in vocabulary from Localized Information Model, or in stack
• Profiles
  • Behavioral Profiles - groupings of operations that meet particular communities of stakeholders
  • Semantic Profiles - Information Models associated with Conceptual Information Models
  • Conformance Profiles - Sets of Computational and Semantic Profiles required for conformance
  • Compliance Notes - Discussion of which conceptual specs, as well as other standards or specifications, this specification complies with

Solution Specification

• Community of Conformance
  • Description, including storyboards, use cases
  • Goal and Functional Requirements
  • Roles
  • Role Behaviors and Policies (Permissions, Prohibitions)
  • Obligations
• Interoperability Specification
  • Shared State model, including state transitions
  • Work Unit Model, including triggers events, communication patterns, invoked Interoperability Specifications
  • Supplementary Information Model
  • Dependent Operations, including conformance levels, encompassing service, state transition
• Conformance Points
  • Bindings between Community Roles and Interoperability Specification (Application Role)

Foundation Artifacts

• Conceptual Datatypes Model
• Concept Domains
• Reference Information Model
• Abstract Datatypes
• Glossary
• Structures Implementation Technology Specification
• Datatypes Implementation Technology Specification
• ?Behavioral Implementation Technology Specification?
• Code Systems
• Value Set

Questions

• Domain Information Model
• Domain binding

Artifact Bag

(not yet complete)

• Conceptual Information Model
• Conceptual Datatypes Model
• Concept Domains
• Replacement for Trigger Event (conceptual level)
• Replacement for Interaction (conceptual level)
• Replacement for Application Role (conceptual level)
• Storyboards
• Use Cases
• Functional Requirements

• Reference Information Model
• Domain Information Model
• Serializable Information Model
• ?Localized Information Model? (need to define what this is better. Is it just 'incomplete' models?)
• Abstract Datatypes
• Code Systems
• Value Set
• Domain binding
• Replacement for Trigger Event
• Replacement for Interaction
• Replacement for Application Role

• Structures Implementation Technology Specification
• Datatypes Implementation Technology Specification
• ?Behavioral Implementation Technology Specification?

• Conformance Profile
• Glossary
• Pattern level behavior
• State machine?
• Interface Model

Proposed organization 2

Candidate Artifact Grouping

The artifacts have been grouped into their approximate level. Some are "agnostic" - they may appear at any level. Some have not yet been categorized.

• Conceptual if you need to bind a solution to a set of business analyses, or if you wish to state abstracted assumptions for future refactoring. These abstract assumptions could include architectural patterns or design patterns.
• Logical to further specify a conceptual artifacts, to achieve more semantic precision, or to implement design patterns or implementation patterns.
• Implementable if a logical artifact is not implementable as is, if the logical artifact does not contain enough specificity to be useful in an implementation, if particular platform models need to be intersected to make a logical artifact more clear to implementers, or if particular transforms (and their consequences) need to be part of a specification stack.

Level-independent

• Glossary - List of terms & definitions
• Publishing Domain (grouper)
• Publishing Topic (grouper)
• Conformance Profile - lists the artifacts (from one or more levels) to which a system asserts conformance

Conceptual

• Artifacts focused on requirements gathering, end-user recognition & validation
• Focus is concentrated on those areas relevant to interoperability standards - don't define the world or boil the ocean
• Artifacts can be used as focus for Compliance. Some may also be basis for Conformance

Business Model Conceptual Artifacts

• Business Context - description of domain area, business function, stakeholders, need for interoperability specification(s). 1/domain or topic
• Conceptual Assumptions - High-level assumptions used to scope/guide requirements capture
• Conceptual Role - Archetypes of people and systems involved
• Storyboards
• Activity Diagrams (usually 1 per storyboard)

Information Model Conceptual Artifacts

• Conceptual Datatypes Model - E.g. Coded, Number, Name - shared across HL7
• Conceptual Information Model - 1 or more per domain/topic
• Conceptual State Model (business terms, may span objects)
• Concept Domains

Note: Some of these may also be a basis for conformance

Behavioral Model Conceptual Artifacts

• Functional Requirement/Capability (name, description, business rules (e.g. pre, post & exception-conditions, other rules), inputs/outputs - references to CIM elements, May be composed into hierarchies with conformance expectations (optional/required))
• Functional Profile - Grouping of Functional Requirements/Capabilities into logical collections to be used as a basis for conformance
• Non-functional requirements - Additional constraints governing the solution (which are relevant to HL7 design) that are not themselves functional capabilities

Discussion

• Ok: Dropped semantic profile - At conceptual level, can't have multiple distinct semantic approaches and vocabulary is part of model definition
• Ok: At conceptual level, "operation" = Functional requirement/capability
• Ok: At conceptual level, functional profile = conformance profile (note that can have compliance and possible conformance against other artifacts)
• Ok: Do we need Conformance statements as a distinct artifact, or can they be derived based on functional profiles? Answer: Probably not

Logical

• Artifacts focused on:
  • Analysis - "How can the conceptual requirements be understood and expressed in terms of common reference artifacts?" - semantic grounding of conceptual artifacts
  • Platform-independent design - Abstraction & constraint to reflect implementation requirements

Business Model Logical Artifacts

• Logical Assumptions - Assumptions used to scope/guide analysis & design
• Use Case (Actors, Flow, Pre/Post/Exception conditions)
• ?More?

Information Model Logical Artifacts

• Abstract Datatypes (Reference)
• Reference Information Model (Reference)
• Interface Model (CMET & Stub definitions)
• Domain Information Model (Analysis)
• Serializable Information Model (Design)
• Loose Information Model - (was Localized IM) - SIM having 'incomplete' classes
• Logical State Machine (RIM class state machine or constraint on it)
• Code System

Behavioral Logical Model Artifacts

• ?Interaction Pattern Definition? (Defines a generic pattern of operations
• Operation
• Behavioral Profile - Logical groupings of operations from an initiator/consumer perspective. Used as basis for conformance
• ?Need to move content from operational profile here?

Discussion

• Dropped semantic profile - For HL7, this will *always* be a RIM-based profile, so is 1..1 with information model

Implementable

Artifacts focused on end use (For HL7, generally information exchange)

• Structures Implementation Technology Specification
• Datatypes Implementation Technology Specification
• ?Behavioral Implementation Technology Specification?
• Value Set
• Domain binding

Note: Technically the ITSs themselves are not Implementable, however the products of them are.

Level-agnostic

These are artifacts that may exist at all 3 levels

• ?Flows of Information?
• Operation
• Specifications and Profiles (collection of artifacts organized to support conformance declaration)
  • Behavioral Profiles - groupings of operations that meet particular communities of stakeholders
  • Conformance Profiles - Sets of Computational and Semantic Profiles required for conformance
  • Solution Specification

Uncategorized

• Community of Conformance
  • Roles
  • Role Behaviors and Policies (Permissions, Prohibitions)
  • Obligations
• Interoperability Specification
  • Shared State model, including state transitions
  • Work Unit Model, including triggers events, communication patterns, invoked Interoperability Specifications
  • Supplementary Information Model
  • Dependent Operations, including conformance levels, encompassing service, state transition
• Conformance Points
  • Bindings between Community Roles and Interoperability Specification (Application Role)

• Replacement for Trigger Event (conceptual level)
• Replacement for Interaction (conceptual level)
• Replacement for Application Role (conceptual level)
• Pattern level behavior