Difference between revisions of "Talk:ITS Acceptance Factors"
Rene spronk (talk | contribs) |
Rene spronk (talk | contribs) |
||
| Line 12: | Line 12: | ||
This is a hard rule to maintain, since "non-optional" is ill defined in this context. It is possible to create HL7v3 artefacts without defining interactions (they are not needed for CDA documents) - so the definition of the interaction is an "optional" part of the HDF. | This is a hard rule to maintain, since "non-optional" is ill defined in this context. It is possible to create HL7v3 artefacts without defining interactions (they are not needed for CDA documents) - so the definition of the interaction is an "optional" part of the HDF. | ||
A reasonable constraint would be that the ITS must be derived from artefacts that are products of the HL7 Development Framework. [[User:Charliemccay|Charliemccay]] 09:50, 1 Jun 2006 (CDT) | A reasonable constraint would be that the ITS must be derived from artefacts that are products of the HL7 Development Framework. [[User:Charliemccay|Charliemccay]] 09:50, 1 Jun 2006 (CDT) | ||
| + | :Suggest to add the context stuff, but not relax the requirement. The HDF describes some things that are optional, e.g. Application Roles. One should not be able to create an ITS that is based on Application Roles. The UML ITS requires a DAM-DIM mapping, a) something that's not in the HDF -this is also covered by your suggestion to relax the requirement-, and b) something that may not be a *mandatory* product of the HDF. If committees aren't forced to create the artefact (and they may choose not to create it), then how can it ever be a basis for an ITS? There needs to be consensus first within the organization that an extension to the HDF is useful before the ITS can be created. [[User:Rene spronk|Rene spronk]] 15:17, 1 Jun 2006 (CDT) | ||
Revision as of 20:17, 1 June 2006
Tooling requirement
I agree that the availability of tooling to support an ITS is crucial -- but think that requiring a beta of the tools to be available before INM accepts the workitem is too high a hurdle - I would suggest that the proposed work item should include a plan that will deliver tooling prior to a specification being brought forwards for ballot Charliemccay 09:50, 1 Jun 2006 (CDT)
- This is a discussion item - but I'd prefer to be strict and not work on theoretical ITSs until it can be clearly shown that tooling can and will be generated. Rene spronk 15:12, 1 Jun 2006 (CDT)
scope of an ITS
The scope of an ITS should not be limited to representing RIM objects "for transmission in messages" -- so I have removed that part of the criteria Charliemccay 09:50, 1 Jun 2006 (CDT)
- The point of the ITS is to represent data so that it may be transmitted. We don't define database models, so the communication aspect has to be emntioned somewhere. Rene 15:10, 1 Jun 2006 (CDT)
requirement for dependance upon non-optional HDF artefacts
This is a hard rule to maintain, since "non-optional" is ill defined in this context. It is possible to create HL7v3 artefacts without defining interactions (they are not needed for CDA documents) - so the definition of the interaction is an "optional" part of the HDF. A reasonable constraint would be that the ITS must be derived from artefacts that are products of the HL7 Development Framework. Charliemccay 09:50, 1 Jun 2006 (CDT)
- Suggest to add the context stuff, but not relax the requirement. The HDF describes some things that are optional, e.g. Application Roles. One should not be able to create an ITS that is based on Application Roles. The UML ITS requires a DAM-DIM mapping, a) something that's not in the HDF -this is also covered by your suggestion to relax the requirement-, and b) something that may not be a *mandatory* product of the HDF. If committees aren't forced to create the artefact (and they may choose not to create it), then how can it ever be a basis for an ITS? There needs to be consensus first within the organization that an extension to the HDF is useful before the ITS can be created. Rene spronk 15:17, 1 Jun 2006 (CDT)
