This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Issues with SAIF Artifact Definition

From HL7Wiki
Revision as of 16:00, 8 April 2011 by Gwbeeler (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Return to Artifact List

By Section

No problem with:

  • Some Artifact Name
  • SAIF Matrix Location
  • Artifact Technology
  • Publishing Representation(s)
  • Publishing Constraints
  • Tooling Considerations
  • Issues

NEW SECTION - specializes or restricts or includes another SAIF A D

We are going to end up with a MAINTENANCE NIGHTMARE if we create individual SAIF Artifact Definitions for:

  • Conceptual Information Model
  • Reference Information Model
  • Domain Information Model
  • Serializable Information Model
  • Loose Information Model
  • Simplified Information Model
  • Supplementary Information Model

We need a Specialization mechanism such that we start with an abstract Information Model Artifact Definition (particularly the content definition, relationships and content constraints) and then extend that to define the RIM, DIM and SIM

Further, we will need a "generic" include mechanism so that the constraints and relationships for a "derived" model are expressed once and then are part of the constraints and relationships of any derived model.

I strongly suspect this SAME problem is at the root of our inability to determine the granularity of behavioral artifacts

Radical Notion

If we purport to be smarty enough to create information standards for health care, how come we do not "eat our own lunch"??

As I was struggling to assert the "relationships" for vocabulary model, I was struck that every type of relationship needed is in ActRelationshipType. Why are these documents not simply INSTANCES of the following RMIM:

Eclipse "Target" selection Pane for ANT tasks

Definition and Purpose

Issue/Question: Are not "content" and "relationship" assertions an integral part of some definitions?

Audience

Suggest we need a common classification for audience types by both "community" of interest and "role" in defining or using HL7 specifications

Applicability

How much does this differ from "SAIF Matrix Location"?

Requirements

I fear we are have two issues here:

  1. Traceability - How do I reference my relationships and content constraints back to specific requirements
  2. Redundancy - It is very difficult to state a "requirement" without simultaneously defining either a relationship or a constraint, yet we do NOT want to define these in two places.

Relationships and traceability

As I wrote RIM relationships section I was continually faced with two issues:

  1. How to distinguish "requirements statements" from "relationship statements"
  2. Whether to express relationships bi-directionally (which seemed to happen in the Conceptual Information Model example) or to follow the MIF principle that says that the "many" defines its relationships to the "one" and not vice-versa.
  3. How to link relationships to their requirements.

Content Constraints

Whoa! How did we get here without a section outlining the content??

The result is that my RIM content constraints began by defining the contents a bit too. I submit there DOES need to be a hierarchical word-phrase definition of the contents of the artifact

Bigger problem

For most of the content for Information Models, these constraints are expressed elsewhere in:

  1. the RIM Normative Specification itself, or
  2. Core Principles or
  3. Refinement, Constraint and Localization

We certainly do not want redundant specifications.

For #1 ABOVE, I opted for Links to the RIM, but perhaps the Artifact Definition should include all of Chapter 2 of the RIM and then publish from the Artifact Definition.

NOTE: This will require the the MIF-ification of the Artifact Definition.

Content Guidelines

Minor problem in that current guidelines are scattered in many Wiki documents

Development Process Considerations

I did not need much of this for the RIM, but it looks to me as though it will be a MAJOR head-ache for the other specifications. This IS what the HDF was supposed to be all about.