Difference between revisions of "Talk:New ITS Guide"
| Line 5: | Line 5: | ||
==HL7 Class== | ==HL7 Class== | ||
--[[User:Lmckenzi|Lmckenzi]] 16:32, 28 March 2007 (CDT) Technically speaking, we don't serialize classes. We serialize associations. Multiple associations from Class A may reference Class B. Each must result in a separate element name because each will have distinct semantics. (E.g. Role played and scoped by the same Entity). Class names are "type" names in the same way that Datatype names are "type" names. Associations and attributes are the actual data elements which are typed by Classes and Datatypes respectively. | --[[User:Lmckenzi|Lmckenzi]] 16:32, 28 March 2007 (CDT) Technically speaking, we don't serialize classes. We serialize associations. Multiple associations from Class A may reference Class B. Each must result in a separate element name because each will have distinct semantics. (E.g. Role played and scoped by the same Entity). Class names are "type" names in the same way that Datatype names are "type" names. Associations and attributes are the actual data elements which are typed by Classes and Datatypes respectively. | ||
| + | |||
| + | ==Reshaping of RIM-based Models== | ||
| + | --[[User:Lmckenzi|Lmckenzi]] 16:46, 28 March 2007 (CDT) Is there a reason for manual re-shaping in preference to automatic re-shaping? E.g. If you have a fixed value, why would you '''not''' want it collapsed out of the model? At a minimum, this document should make reference to the fact that there are two approaches to re-shaping: | ||
| + | # Manually walking through the model and identifying what you want collapsed | ||
| + | # Manually walking through the model and identifying what you ''don't'' want collapsed, and then automatically collapsing everything else. | ||
| + | |||
| + | --[[User:Lmckenzi|Lmckenzi]] 16:46, 28 March 2007 (CDT) Discussion on re-shaping of datatypes should deal with datatype flavors. In general, re-shaping of datatypes based on usage should be avoided. However, reshaping based on the assertion of a particular datatype flavor (e.g. GTS.BOUNDEDPIVL) could be quite useful. | ||
| + | |||
| + | ==Requirement for Serialization Models== | ||
| + | --[[User:Lmckenzi|Lmckenzi]] 16:46, 28 March 2007 (CDT) I would be strongly opposed to a single serialization that spanned all clinical models. While the theory might be that we could do this with "Clinical Statement", there are too many things that are "out of scope" for clinical statement that need to be supported within a domain for this to be appropriate. We'd basically end up with a model that pretty much looked like the RIM. Starting out at the Domain model level would be more reasonable, though we'd still have issues in that not all D-MIMs are serializable and we'd thus need to create a serializeable view for each potential entry point. | ||
Latest revision as of 21:46, 28 March 2007
Contents
Design Principles
--Lmckenzi 16:22, 28 March 2007 (CDT) Why in the design principles does it state that the use of CMETs and wrappers should not be transparent in the instance? CMETs and Wrappers are design artifacts related to consistency and re-use. We should be able to introduce them and remove them without impacting instances. That was a founding principle in the original ITS and if we're going to reverse it, there should be extremely good reasons for doing so.
Specification Walkthrough
HL7 Class
--Lmckenzi 16:32, 28 March 2007 (CDT) Technically speaking, we don't serialize classes. We serialize associations. Multiple associations from Class A may reference Class B. Each must result in a separate element name because each will have distinct semantics. (E.g. Role played and scoped by the same Entity). Class names are "type" names in the same way that Datatype names are "type" names. Associations and attributes are the actual data elements which are typed by Classes and Datatypes respectively.
Reshaping of RIM-based Models
--Lmckenzi 16:46, 28 March 2007 (CDT) Is there a reason for manual re-shaping in preference to automatic re-shaping? E.g. If you have a fixed value, why would you not want it collapsed out of the model? At a minimum, this document should make reference to the fact that there are two approaches to re-shaping:
- Manually walking through the model and identifying what you want collapsed
- Manually walking through the model and identifying what you don't want collapsed, and then automatically collapsing everything else.
--Lmckenzi 16:46, 28 March 2007 (CDT) Discussion on re-shaping of datatypes should deal with datatype flavors. In general, re-shaping of datatypes based on usage should be avoided. However, reshaping based on the assertion of a particular datatype flavor (e.g. GTS.BOUNDEDPIVL) could be quite useful.
Requirement for Serialization Models
--Lmckenzi 16:46, 28 March 2007 (CDT) I would be strongly opposed to a single serialization that spanned all clinical models. While the theory might be that we could do this with "Clinical Statement", there are too many things that are "out of scope" for clinical statement that need to be supported within a domain for this to be appropriate. We'd basically end up with a model that pretty much looked like the RIM. Starting out at the Domain model level would be more reasonable, though we'd still have issues in that not all D-MIMs are serializable and we'd thus need to create a serializeable view for each potential entry point.
