This wiki has undergone a migration to Confluence found Here
Difference between revisions of "PertinentInformationism"
Jump to navigation
Jump to search
Rene spronk (talk | contribs) (→Cause) |
|||
| Line 7: | Line 7: | ||
:If one has a business-process reason for squeezing a specific set of information into a single static model, then one should seriously consider whether the use of a [[CDA]] document is more appropriate than a message. [[User:Rene spronk|Rene spronk]] 09:20, 1 September 2006 (CDT) | :If one has a business-process reason for squeezing a specific set of information into a single static model, then one should seriously consider whether the use of a [[CDA]] document is more appropriate than a message. [[User:Rene spronk|Rene spronk]] 09:20, 1 September 2006 (CDT) | ||
| + | |||
| + | ''PertinentInformationism'' can also be caused when there is a lack of familiarity with the RIM or a desire to minimize the class-count that might result from fully modeling a concept. | ||
==Symptoms== | ==Symptoms== | ||
| Line 12: | Line 14: | ||
*It often is accompanied by cravings for de-novo attributes, because the relationship of the information to the business processes is neglected, and hence it looks like it's all just some new unrelated attributes. | *It often is accompanied by cravings for de-novo attributes, because the relationship of the information to the business processes is neglected, and hence it looks like it's all just some new unrelated attributes. | ||
*"Complicated data structure" is another alarm-word for this same disease. It's the denial of looking at the processes and wanting to shoehorn a foreign preset model into the HL7 world (or any other model foreign to those preset ideas of those "information structures".) | *"Complicated data structure" is another alarm-word for this same disease. It's the denial of looking at the processes and wanting to shoehorn a foreign preset model into the HL7 world (or any other model foreign to those preset ideas of those "information structures".) | ||
| + | *'Semantics by clone-name'- The model often relies on the use of clone names to express meaning rather than associations and structural attributes. | ||
| + | *Observation proliferation - The majority of the pertinentInformation associations tend to point to bare observations simply containing Observation.code and sometimes Observation.value. This is used as the simplest way to attach a "custom" attribute. | ||
| + | |||
| + | ==Why it is a problem== | ||
| + | The strength of the HL7 methodology is its rigorous and consistent representation of semantics within the model. With pertinentInformationism, the semantics degrade and become less clear. The effect is similar to v2 [[z-segment]]s where custom attributes are added at will with no regard for consistency or underlying object model. | ||
| + | |||
| + | ==Remedies== | ||
| + | *When tempted to use "pertinentInformation", always strive to find an alternate way to model the concept | ||
| + | *When "PertinentInformation" is used, ensure that the semantics being conveyed are "The target act relates somehow or other to the source act. The specifics of the type of relationship are either not known or are irrelvant" | ||
| + | *Also ensure that the selection of any of the specializations of PERT could theoretically be appropriate | ||
| + | *If unsure how to model a particular concept, go back to understand the use of the data from an underlying business perspective and try to think about that business process in terms of the v3 backbone (Acts in different moods, roles, etc.) | ||
| + | *If stuck on how to model something without using pertinentInformation, consult the MnM list server, explaining the concept needed and providing a copy of your existing model. | ||
| + | *Don't be afraid of using a large number of classes to model a small concept. The classes will likely help clarify the semantics and will provide a framework for future extensibility as business requirements evolve. | ||
| + | |||
| + | ==Related Conditions== | ||
| + | *Componentism: Not quite as bad as "pertinentInformationism", this condition stems from the over-use of the COMP association. Root causes are similar. Modelers should ensure that components are true "containment" relationships. | ||
Revision as of 15:53, 1 September 2006
PertinentInformationism is a syndrome, the main symptom of which is the use of a significant number of pertinentInformation act relationships.
Cause
When developing/localizing models, pertinent informationism is a syndrome caused by neglect of business processes in information models. The focus is on (legacy-) information representation and not on the underlying business processes.
The "transformation" of a legacy business process (and a single legacy information representation) should take place at the business process level and its requirements, and not at the information representation level. The business process may be supported by more than one models in HL7 version 3.
- If one has a business-process reason for squeezing a specific set of information into a single static model, then one should seriously consider whether the use of a CDA document is more appropriate than a message. Rene spronk 09:20, 1 September 2006 (CDT)
PertinentInformationism can also be caused when there is a lack of familiarity with the RIM or a desire to minimize the class-count that might result from fully modeling a concept.
Symptoms
- The use of large number of pertinentInformation act relationships.
- It often is accompanied by cravings for de-novo attributes, because the relationship of the information to the business processes is neglected, and hence it looks like it's all just some new unrelated attributes.
- "Complicated data structure" is another alarm-word for this same disease. It's the denial of looking at the processes and wanting to shoehorn a foreign preset model into the HL7 world (or any other model foreign to those preset ideas of those "information structures".)
- 'Semantics by clone-name'- The model often relies on the use of clone names to express meaning rather than associations and structural attributes.
- Observation proliferation - The majority of the pertinentInformation associations tend to point to bare observations simply containing Observation.code and sometimes Observation.value. This is used as the simplest way to attach a "custom" attribute.
Why it is a problem
The strength of the HL7 methodology is its rigorous and consistent representation of semantics within the model. With pertinentInformationism, the semantics degrade and become less clear. The effect is similar to v2 z-segments where custom attributes are added at will with no regard for consistency or underlying object model.
Remedies
- When tempted to use "pertinentInformation", always strive to find an alternate way to model the concept
- When "PertinentInformation" is used, ensure that the semantics being conveyed are "The target act relates somehow or other to the source act. The specifics of the type of relationship are either not known or are irrelvant"
- Also ensure that the selection of any of the specializations of PERT could theoretically be appropriate
- If unsure how to model a particular concept, go back to understand the use of the data from an underlying business perspective and try to think about that business process in terms of the v3 backbone (Acts in different moods, roles, etc.)
- If stuck on how to model something without using pertinentInformation, consult the MnM list server, explaining the concept needed and providing a copy of your existing model.
- Don't be afraid of using a large number of classes to model a small concept. The classes will likely help clarify the semantics and will provide a framework for future extensibility as business requirements evolve.
Related Conditions
- Componentism: Not quite as bad as "pertinentInformationism", this condition stems from the over-use of the COMP association. Root causes are similar. Modelers should ensure that components are true "containment" relationships.
