Issues with SAIF Artifact Definition
Contents
- 1 By Section
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:
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:
- Traceability - How do I reference my relationships and content constraints back to specific requirements
- 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:
- How to distinguish "requirements statements" from "relationship statements"
- 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.
- 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:
- the RIM Normative Specification itself, or
- Core Principles or
- 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.
