Difference between revisions of "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

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.

PRIOR CONTENT

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

Timeline objectives/vision

• Try to have complete 'alpha' artifact definitions complete by Jan 2012 WGM (was May 2011 WGM)
• Try to have complete 'alpha' methodology defined by May 2012 WGM (was Sept. 2011 WGM)
• Work Groups 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 first step, though may wait for some artifacts deemed "less stable"
• Aim to publish and ballot first draft of SAIF HL7 Implementation Guide for Sep 2012 ballot
• Hope to have HL7 IG approved by mid-2013
• 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

• Aug: 20110819
• Jul: 20110708 20110715
• Jun: 20110617
• May: 20110506
• Apr: 20110401 20110408
• Mar: 20110304 20110311 20110318
• Feb: 20110225 20110218, 20110211, 20110201
• Jan: 20110125

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

See SAIF Artifact List