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
