Category:SAIF Artifact Definition

Meeting Logistics

Weekly Conference Calls will be held each Friday at 1:00PM Eastern.

SAIF Artifact Definition Project.

HL7 Conference Call service

Phone: 770-657-9270

Passcode: 459876#

GoToMeeting Service https://www2.gotomeeting.com/join/846611869

Meeting ID: 846-611-869

PRIOR CONTENT

This topic was originally opened under MnM at MnM Project On Defining SAIF Artifacts.

Purpose

This wiki page provides a means for formally defining all of the artifact types that will be developed, maintained and published by HL7 work groups under the SAIF methodology. This content will form a significant portion of HL7's SAIF implementation guide.

The artifact definitions attempt to identify the purpose for a given artifact, the reasons for its existence as well as the various constraints on when and how it is used and the content it may contain.

Timeline objectives/vision

• Try to have complete 'alpha' artifact definitions complete by May 2011 WGM
• Try to have complete 'alpha' methodology defined by Sept. 2011 WGM
• Committees and projects can start using the definitions & methodology as early adopters when they see fit and can (and should) provide feedback
• Tooling and MIF development could happen any time after May, though may wait for some artifacts deemed "less stable"
• Aim to publish and ballot first draft of SAIF HL7 Implementation Guide for May 2012 ballot
• Hope to have HL7 IG approved by end of 2012
• Ongoing maintenance
• Transition for non-early adopters

Process

The content of these artifact definition documents is open for editing to all participants in HL7 international. However, MnM requests that several guidelines be followed:

1. Follow the format defined in the SAIF Artifact Definition Template to ensure consistency and that all necessary aspects of the artifact definition are captured
2. Don't delete elements from either the template or the artifact definitions (though you can add comments suggesting they be deleted). Decisions to remove content will be made on committee conference calls
3. Make use of the "discussion" tabs for debate about the pros and cons of different approaches. The content in the artifact definitions themselves should only include content that would be expected to be included in the final publication (so a couple of sentences of rationale is fine for the main document. A three paragraph diatribe on why a given approach is better would best be handled in discussion.

At the moment, all of these artifact definitions are in an extremely draft state and the set is incomplete. In fact, the list of artifacts themselves is extremely incomplete. The purpose of the wiki is to gather contributions from the many stakeholders that are interested in the selection of artifacts and the rules associated with them. After we have reached a reasonable degree of consensus within MnM, ArB and possibly other committees (TSC, Structured Documents, etc.), these artifact definitions will be gathered into a publishable form and subjected to formal ballot review by the membership.

Minutes

• 20110125
• 20110201
• 20110211

What is an artifact?

• MIF has some idea of what an artifact is
• Artifacts are the lowest level at which ballot/approval status can be asserted
• Artifacts can be versioned alone
• Artifacts can be published alone (though with linkages)
• Artifacts can be developed independently (when dependencies are present)
  • E.g. Two people can work on two interdependent artifacts simultaneously. Two people can't work on one artifact simultaneously (on separate machines).
• Artifacts may contain independently referencable components (e.g. datatypes within a datatype model, codes in a code system), but they are always maintained as part of the overall artifact
• The same artifact "type" may have variants reflecting level of detail, location in the design space, etc. (E.g. RIM, DIM, SIM, etc. are all "information models", even though they have different constraints
• Artifacts tend to be re-used and referenced by multiple other artifacts. At minimum, they should offer the potential for re-use

Candidate artifacts

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.

• 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
• Operation
• Identity
• Name
• Description
• Inputs
• Outputs
• Pre-conditions (tied to trigger events, potentially)
• post-conditions (tied to trigger events, potentially)
• Invariants

Service Logical Specification

• Serializable Information Model

Service Implementable Specification

• ?Localized Information Model? (need to define what this is better. Is it just 'incomplete' models?)

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