Grahame Grieve wrote:
>>> 5.1.5.2 This section introduces the "match" attribute, which has one >>> of the following values: >>> -1 code provided is more specific than it should be >>> 0 code matches intent >>> +1 code provided is not as specific as the intent >>> The use of values like this seems poorly modelled - surely this >>> is a variation of the datum interpretation concept from the design >>> principles? >> >> >> not sure why you say this - the only meaning for this attribute is to >> indicate match. There is no other data in the attribute. But you >> might argue that it should be an enumerated type rather than an >> Integer. We went for an integer for the following reasons: >> - it is quite common in the C languages for -1/0/+1 to be the results >> of a comparison, e.g. with the string routines. >> - to allow for the possibility in the future that sensible meanings >> could indeed be attached to higher /lower values. > > yes, and we could use 0 to indicate null too, which is common practice > in the c langauges. yes - that is an example of the evil I was talking about. But null is not allowed (or even possible) for this field. > I do argue that this should be an enumerated type. If it get's > extended to higher > and lower values, then begin a terminology makes the problems with > changing it explicit We did originally think of this, and there is a micro terminology in CEN or ISO, I forget which, which defines "<", "=", ">" as symbolic terms with defined meanings. >>> 5.2.1 TERM_MAPPING.purpose - no terminology? how could this have any >>> practical >>> meaning with a controlled usage? >> >> I think it probably should be coded as well (I presume you meant here >> "without controlled usage"). But there are no terminologies for this >> at the moment, although it would not be hard to invent one. > > oh yes - I did mean without. This is one of those horrible little > corners for which > one must invent a terminology I tend to agree (and I've noted this in a compendium of CRs that eventually must be sorted out!) > oh - parsable? interesting. I read that and ignored it since it said > so little > about what it was. why is it constrained to plain text? do you mean - why is the 'value' a String? It is assumed to be parsable text - that's all. It could be XML - but not necessarily. It could also be stored as a DV_MULTIMEDIA - i.e. opaquely. > back to the point. Why don't you want semantic markup? semantic markup is fine, just not in DV_TEXTs - otherwise we will ge people putting all kinds of stuff in there in massive tracts of XML, and others will just put in small strings, which is the intention. This would be a nightmare for decision support. If semantic markup is needed, it can just be a DV_PARSABLE or DV_MULTIMEDIA - no loss of meaning, and much easier to know what to do with. >>> 6.4 reference Range type - this seems a little simple to handle the >>> gloriously >>> complicated reference ranges much beloved by endocrinologists. What >>> is the >>> intent in these cases? >> >> >> to record only the reference range for a given datum, for a given >> patient, for the given test etc - not to record whole reference range >> tables. In most pathology this appears to suffice. But I'll say again >> - it's not to include all the reference range tables or data - only >> to record the particular values for the particular measurement and >> patient ... > > > but the reason endocrinologists have such wonderful reference ranges > is that the particular values may not be > known (or even knowable). LH and FSH are classic examples - here's a > set of reference ranges for different > stages of the cycle. The test as probably ordered to give some > indication of where the cycle is - so instead > of interpreting the test result in terms of the reference range for > the patient's situation, we are interpreting > the patient's situation in terms of the result compared to it's > reference ranges. > > But more generally, pathology test providers do not have enough > information to assign > a patient to one of a set of reference ranges, where they have them what we think is reasonable at the moment is: - to allow multiple reference ranges (e..g normal, critical etc) to be built into the data type - this will take care of all the mundane reference range situations - for complex reference data, it just has to be supplied as its own Entry or Structure as part of an Entry, and will probably need archetyping. I know this is a hairy area, and I doubt we have it 100% correct for now - more experimentation is needed. >>> 3. ST is a problem but it is a list<ST> (oh, err, LIST<CHAR>) not a >>> LIST<BL>. >> >> >> Going by the 4th ballot, I must have missed something - it seems to >> be that ST inherits from ED then BIN, which is bound to LIST<BN>. > > > ah yes, but we tricked you and pulled a fast one by redefining it's > ancestor. This is a fun trick to pull, so > I'll explain it a bit better: > > LIST<T> > head() : T > tail() : LIST<T> > BIN = LIST<BN> > head() : BN > tail() : LIST<BN> > ED > head() : BN > tail() : LIST<BN> > ST > head() : ST > tail() : ST > > because BIN is a LIST<BN>, then the head and tail take types BN and > list<BN>. > But when we come to string, we pull a fast one, and ST is actually a > LIST<ST>. > or ST is actually a ST. or something. So you see what I mean by we > saying that > we pulled a fast one. Though I think mostly we tricked ourselves. And > it should > be clear, that as editor of the spec, my current project is to fix > that little mess! but hang on - ED has no formal type parameter - there is no way that ST can redefine T to be ST - it has already been fixed in BIN. The only way out of this is if ED is ED<T>. And you cannot do a direct redefine of head:ST from head:BN, since ST is not conformant to BN. Nor could tail: ST (or should it be tail:List<ST>?) be a valid redefinition of tail: LIST<BN> for similar reasons. Looking at the above, I doubt if I could make it work in any language. I think there is more work to do here... Not to mention that ST really being a LIST<ST> is not likely to convince too many people! - thomas - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
