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. E.g. RMIMs, message types, some templates
• 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. E.g. most templates, patterns
• 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