Hi Tom, I agree with Sam. I think you are correct in principle but the difference, in practice, between a DV_ORDINAL and a DV_SCORED_VALUE is non-existent where the constrained values are unique, which will be the majority of cases. e.g. What makes Apgar and GCS Ordinals? They are essentially DV_SCORED_VALUES which happen to have unique values. The differences will be too subtle for most archetype designers (including this one) to model consistently.
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 29 September 2011 00:06, Sam Heard <sam.heard at oceaninformatics.com> wrote: > Hi Thomas > Sounds OK - just not sure that we need both?? The alternative is to loosen > up DV_ORDINAL. That could be easier? Having different ways of doing the same > thing is always problematic. > Cheers, Sam > >> -----Original Message----- >> From: openehr-clinical-bounces at openehr.org [mailto:openehr-clinical- >> bounces at openehr.org] On Behalf Of Thomas Beale >> Sent: Wednesday, 28 September 2011 7:20 PM >> To: openehr-clinical at openehr.org >> Subject: Re: Multiple values in C_DV_ORDINAL constraints >> >> On 28/09/2011 09:05, Ian McNicoll wrote: >> >> . ? ? ? ? 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? >> >> >> > [IAN] Wel,, yes. But surely the point of archetypes is to formally >> > document as much of this knowledge as possible, rather than leaving >> it >> > to application logic. I have managed to workaround the current >> > restriction for the Waterlow Scale archetype but it is pretty >> > counter-intuitive. The strength of the RM is that it should be rich >> > enough to capture these sort of clinical ideas in a way that is clear >> > ot both clinicians and developers. The idea of a termset mapped to >> > numeric values is, I thikn, valid. The only issue is whether it makes >> > sense to adapt the DV_ORDINAL for these non-unique uses-cases, or >> > whether a new datatype is required >> > >> >> Ruminating on the discussion so far, it seems to me that we do need to >> do this properly. What use are openEHR archetypes if they don't cope >> with common medical things? A new data type seems to make sense - a >> kind >> of DV_CODED_TEXT containing also a score_value attribute. Maybe we can >> call this DV_CODED_VALUE (other possibilities: DV_CODED_RATING, >> DV_CODED_SCORE)? The properties would be different from DV_ORDINAL: >> with >> DV_CODED_VALUE, each possible value in a series must have a distinct >> code and meaning, but may have any numeric value associated with it, >> allowing multiple such DVs to have the same value. If we wanted to make >> it quite score oriented - which seems like a good idea to me, we might >> use the name DV_CODED_SCORE_VALUE, and include in it a reference to the >> score, in the form of a DV_CODED_TEXT. >> >> Thus: >> >> class DV_CODED_SCORE_VALUE >> inherit >> ? ? ?DV_CODED_TEXT >> >> ? ? ?score_value: Real >> ? ? ?score_reference: DV_CODED_TEXT >> end >> >> This requires more thinking by those who know the problem better than I >> do, but it is easy to test any model like this by adding to an >> experimental variant of one of the BMM-schemas used in the ADL >> Workbench. Test archetypes can then be written to see what it is like. >> >> - 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 >
