This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Issues with SAIF Artifact Definition"
Jump to navigation
Jump to search
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | + | [[Category:SAIF Artifact Definition]] | |
[[:Category:SAIF Artifact Definition|Return to Artifact List]] | [[:Category:SAIF Artifact Definition|Return to Artifact List]] | ||
=By Section= | =By Section= | ||
| Line 5: | Line 5: | ||
*Some Artifact Name | *Some Artifact Name | ||
*SAIF Matrix Location | *SAIF Matrix Location | ||
| − | + | *Artifact Technology | |
| − | We are going to end up with a '''MAINTENANCE NIGHTMARE''' if | + | *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: | ||
| + | [[Image:SAIFArtifactDefnRMIM.png|thumb|center|768px|Eclipse "Target" selection Pane for ANT tasks]] | ||
== Definition and Purpose == | == Definition and Purpose == | ||
| − | Issue: Are not "content" and "relationship" assertions an integral part of some definitions? | + | Issue/Question: Are not "content" and "relationship" assertions an integral part of some definitions? |
| + | |||
== Audience == | == Audience == | ||
Suggest we need a common classification for audience types by both "community" of interest and "role" in defining or using HL7 specifications | Suggest we need a common classification for audience types by both "community" of interest and "role" in defining or using HL7 specifications | ||
| Line 20: | Line 46: | ||
#'''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. | #'''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 == | == 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 Artifact Definition| 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 == | ||
| + | <big>Whoa! How did we get here without a section outlining the content??</big> | ||
| − | + | 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 [http://www.hl7.org/v3ballot/html/infrastructure/rim/rim.html#true-intro 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 == | == Content Guidelines == | ||
| − | + | Minor problem in that current guidelines are scattered in many Wiki documents | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== Development Process Considerations == | == 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. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Latest revision as of 16:00, 8 April 2011
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.
