Difference between revisions of "Category:SAIF Artifact Definition"

PRIOR CONTENT

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

Also, there is now a conference call scheduled for Fridays (at 11AM or Noon or 1PM) based on an email exchange on Feb 8, 2011:

Purpose

This wiki page provides a means for formally defining all of the artifact types that will be developed, maintained and published by HL7 committees 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

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

Candidate artifacts

(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?