Hi Heath, >>The key thing for me is how fluid these values are, will they change >>requiring an Archetype change? If so, then they shouldn?t be modelled as an >>Ordinal and maintained externally.
The assumption is that the values are not fluid. A change in the values would imply a revision of the underlying scoring instrument, which would non longer be compatible with the previous version. The Waterlow Scale has been revised a couple of times since its original development, with changes in terms and values but these are infrequent >>The other things is that when we using the term mappings, are we talking >>about the DV_TEXT mappings? DV_TEXT mappings don?t support numerical values, >>only coded values and >> hence not able to support this requirement No we are definitely talking about the current arrangement in DV_ORDINAL where a Text term is 'mapped' to an integer value. Philosophically Ordinal seem to have been conceived as being a list of values each of which is assigned a text term. In practice, I think the reverse is true - these are nearly always a list of terms to each of which is assigned a value, which is somewhat arbitrary. GCS, Apgar and many other well-recognised scores are really examples of term lists mapped to values, which in most cases happen to be unique AND integer. I am clear that we need this more open idea of a term-list, to which each member is assigned a real number. The only issue is how this is implemented. 1. Create a completely new datatype. There is so much crossover between this and DV_ORDINAL (which also needs 'real' values) that the creation of a separate datatype is unnecessary. 2. Add a unique/non-unique_values attribute to the constraint, defaulting to unique. This would allow the current uniqueness rule to be applied as default but which could be lifted for specific use-cases like the Waterlow scale. 3. Simply remove the uniqueness requirement. It seems unnecessary to me since all of the possible allowed values are always explicitly expressed in the constraint. It is up to the archetype designer to decide whether uniqueness is required or not. Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant,?Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care ?www.phcsg.org On 28 September 2011 02:30, Heath Frankel <heath.frankel at oceaninformatics.com> wrote: > Hi Heather, > > Good analysis.? The key thing for me is how fluid these values are, will > they change requiring an Archetype change?? If so, then they shouldn?t be > modelled as an Ordinal and maintained externally.? The other things is that > when we using the term mappings, are we talking about the DV_TEXT mappings? > DV_TEXT mappings don?t support numerical values, only coded values and hence > not able to support this requirement. > > > > Heath > > > > From: openehr-clinical-bounces at openehr.org > [mailto:openehr-clinical-bounces at openehr.org] On Behalf Of Heather Leslie > Sent: Wednesday, 28 September 2011 10:32 AM > > To: 'For openEHR clinical discussions' > Subject: RE: Multiple values in C_DV_ORDINAL constraints > > > > Hi Ian, > > > > I'd be very interested to see the extent of these examples and make some > assessment whether an ordinal is the most appropriate way to model this > content. > > Few thoughts: > > ????????? The natural instinct is definitely to use an ordinal but is it > because of the layout/display in the requirements document or based on the > data itself? We could equally suggest that these values could be modelled as > a coded text list and assigned a value mapping in the same way you suggest. > > ????????? Should the values simply be described, or actually assigned, in > the archetype (via the data type itself) and how much of this should be left > in the application GUI/workflow/logic? > > ????????? Is the clinical content reasonable - we have certainly found that > there are many instances of commonly used clinical content that is 'munged' > together for historical reasons, and that when we model, needs to be teased > out into subtlely difference concepts. That these values are directly > related or of similar granularity etc might need further discussion. > > ????????? Or do we have a simple need to emulate the current practice > (rather than best practice/modelling) in the models, perpetuating any > historical practice without any further consideration? I recognise that > there is always a pragmatic argument for this too. > > > > Cheers > > > > Heather > > > >>-----Original Message----- > >>From: openehr-clinical-bounces at openehr.org [mailto:openehr-clinical- > >>bounces at openehr.org] On Behalf Of Ian McNicoll > >>Sent: Tuesday, 27 September 2011 6:18 PM > >>To: For openEHR clinical discussions > >>Subject: Re: Multiple values in C_DV_ORDINAL constraints > >> > >>SPECR-72 posted > >>http://www.openehr.org/issues/browse/SPECPR-72 > >> > >>Dr Ian McNicoll > >>office +44 (0)1536 414 994 > >>fax +44 (0)1536 516317 > >>mobile +44 (0)775 209 7859 > >>skype ianmcnicoll > >>ian.mcnicoll at oceaninformatics.com > >> > >>Clinical Modelling Consultant,?Ocean Informatics, UK openEHR Clinical > >>Knowledge Editor www.openehr.org/knowledge Honorary Senior Research > >>Associate, CHIME, UCL BCS Primary Health Care ?www.phcsg.org > >> > >> > >> > >> > >>On 26 September 2011 20:42, Thomas Beale > >><thomas.beale at oceaninformatics.com> wrote: > >>> On 26/09/2011 18:22, Ian McNicoll wrote: > >>> > >>> I still cannot find the reference to the VCOV rule in the > >>> specifications - can someone point this out? > >>> > >>> I agree that we seem to be mixing up 2 somewhat different ideas here. > >>> One is the 'true' ordinal, where there is a set of ordered terms to > >>> each of which some sort of ordered but otherwise arbitrary integer > >>> value is assigned. If all we are doing is asserting the correct order > >>> of the terms then it is questionable whether anything other than the > >>> index position in the list is necessary e.g 0..n. However there are > >>> many examples of ordered lists in clinical use which have at least > >>> some sort of score attached to each list member. As Daniel has pointed > >>> out, it is somewhat dubious if these really qualify as ordinals and I > >>> agree with Tom's idea that these are really term->value mappings. > >>> > >>> I would vote for taking the simple option of removing the 'uniqueness' > >>> requirement. I doubt very much if this would cause any downstream > >>> problems with decision support, in that if unique constraints are > >>> required, these will be fully defined by the archetyping itself e.g a > >>> GCS or Apgar score. > >>> > >>> > >>> can someone please put an issue on the SPECPR tracker? It should quote > >>> this and Daniel's posts. > >>> > >>> - thomas > >>> > >>> > >>> _______________________________________________ > >>> openEHR-clinical mailing list > >>> openEHR-clinical at openehr.org > >>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical > >>> > >> > >>_______________________________________________ > >>openEHR-clinical mailing list > >>openEHR-clinical at openehr.org > >>http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical >
