SAIF Artifact List

Return to SAIF Artifact page

Current organization

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

• Vocabulary Model (grouper) - WB
• Glossary- List of terms & definitions - WB
• Domain Artifacts (grouper) - WB
• Publishing Package (grouper) - WB
• 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, stakeholders, need for interoperability specification(s). 1/domain or topic - JC*
• Business Function - Describes capabilities and objectives/expectations at the business rather than system level - JC
• Conceptual Assumptions - High-level assumptions used to scope/guide requirements capture - JC
• Conceptual Role - Archetypes of people and systems involved - JC
• Storyboards - JC
• Storyboard Activity Diagrams (usually 1 per storyboard) - JC

Information Model Conceptual Artifacts

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

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)) - HS
• Functional Profile - Grouping of Functional Requirements/Capabilities into logical collections to be used as a basis for conformance - HS
• Non-functional requirements - Additional constraints governing the solution (which are relevant to HL7 design) that are not themselves functional capabilities - HS
• Conceptual Activity Diagram - Shows flows of behaviour between roles

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

• Reference Information Model (Reference) - WB*
• Domain Information Model (Analysis) - WB
• Serializable Information Model (Design) - WB
• Logical State Machine (RIM class state machine or constraint on it) - AK*
• Abstract Data Types Model (Reference)
• Interface Model (CMET & Stub definitions)
• Loose Information Model - (was Localized IM) - SIM having 'incomplete' classes
• Simplified Information Model (for simplified wire formats)
• Code System
• Code System Supplement - Information about an extension to a code system that is referenced by one or more value sets - LM
• Code Translations - A collection of known translations between codes from different code systems - LM

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?
• Non-functional requirements??

Discussion

• Dropped semantic profile - For HL7, this will *always* be a RIM-based profile, so is 1..1 with information model
• What's the difference between logical and conceptual assumptions? Logical and conceptual non-functional requirements?

Implementable

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

• Structures Implementation Technology Specification - PK
• Data Types Implementation Technology Specification - PK*
• ?Behavioral Implementation Technology Specification?
• Value Set
• Context 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

John's notes

As discussed in earlier sections, refinement is a process of providing a further level of detail in one specification from the concepts in another, more abstract specification. This design activity will ensure traceability between different parts of the produced specification. Recall that this aspect of traceability is referred to as compliance and that in SAIF, traceability also includes conformance aspects, stating traceability of an implementation that was built based on the specification.

The rules of behavioral refinement will depend on the type or behavioral expression. Some examples are:

   * A finite state machine defined in the conceptual perspective can be refined in a more detailed state machine, by decomposing its existing state into separate state machines or adding further states to the conceptual one; note that this refinement is more difficult in case of state machines allowing concurrency.
   * A set of interactions between two objects can be grouped to be considered as a higher-level interaction (as in the UML2.3 interaction model regions).
   * A business event can be described in terms of relationships between more primitive events, as in several Complex Event Processing approaches.
   * Exception Conditions can be refined to allow business-level exceptions to subsume other lower-level exceptions

The table describing the elements of logical specification above provides statements of traceability to the elements of the conceptual model listed in the first table. As with the correspondences between related modeling concepts in different viewpoints, the traceability relationships are to be shown explicitly in the model, using, for example, the UML <<trace>> dependency.

At the implementable level:

As with Logical to Conceptual traceability, the Implementable to Logical traceability will specify <<trace>> dependency from Implementable to Logical models. For example, an implementable transport specification can adopt either Web Services or REST protocols, and the interactions specified in this protocol will need to explicitly nominate which logical operations they implement (for example, GET may implement a logical Query operation). This ensures the independence of the logical expression of interactions to those which provide additional, protocol level detail, that are considered irrelevant, from the perspective of the logical model specifiers.

https://wiki.nci.nih.gov/display/SAIF/2.3+-+Behavioral+Framework+-+Implementers%27+Checklist

Proposed organization - Initial

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 Data Types 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 Data Types Model
• Concept Domains
• Reference Information Model
• Abstract Data Types
• Glossary
• Structures Implementation Technology Specification
• Data Types 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 Data Types 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 Data Types
• Code Systems
• Value Set
• Domain binding
• Replacement for Trigger Event
• Replacement for Interaction
• Replacement for Application Role

• Structures Implementation Technology Specification
• Data Types Implementation Technology Specification
• ?Behavioral Implementation Technology Specification?

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