> I see this as one of the major problems of HL7 actually. It seems to think > that everything should be driven by use cases.
shorter Tom Beale: Only by ignoring use cases can one design usable data types? > Original text can be used in a structured user interface to capture > what the user saw as a representation of the code on the data > input screen, or in a situation where the user dictates or directly > enters text, it is the text entered or uttered by the user > So is originalText the freely entered text of the user, or the > term for the code which is being attached to some text? The second only if it's the basis for the choice of the code. So the two fields may contain the same information. I'm not going to argue about the more general point you are making. I don't think it's obviously true that your proposed alternative is better (though it's certainly not obviously worse). But I agree that there's no question that the data types are HL7's data types. > There is no realistic prospect of physicians or anyone else > going back through gigabytes of medical data and trying to > decide what might have been in the mind of the person > originally recording the data well, I thought so too. But it already happens in some places. > But whatever term is chosen, it must be by definition the > correct thing to record in the data, otherwise the software > and clinical process is a nonsense. please inform the end users that you say that they must behave this way. > well we can make the basic distinction: > > * synonym: a different linguistic rendering of the same concept > * mapping: an association of a term, typically a classification, with some > text, for a particular purpose, e.g. an ICD code or DRG code. where do you get that distinction? I'm not familiar with these terms from any terminology standard, though I haven't yet read the latest version of Heather's glossary > Essentially, these 'standards' are abusing the XML standard itself. heh. XML forever, it will solve every problem in the world. Just if everyone else does it 'my' way, we'll be right. > For example, HL7- and ISO21090 'date' is expressed as YYYYMMDD, > where there is already a base XML-schema datatype 'date' expressed > as YYYY-MM-DD. So when validating an HL7-v3-message against the > schema (and even against the schematron), the date 20070231 > (February 31, 2007) is accepted as a correct date. OpenEHR too. We are all beyond redemption. Actually, I don't know why he thinks that 20070231 is valid, I wrote and tested the regex to make it illegal, though the regex doesn't do the leap year thing. [edit: ahh no, that regex didn't make it in for some reason. I don't recall why, but it was -super- long.]. And we chose not to use the silly XML schema type with care. I don't know if it was the right decision, but, unlike he says, there was a reason, to do with incomplete dates. It's actually more compelling in times than dates but we do both the same way, as does openEHR > So, no 'reinvention' of datatypes, but using the XML native > datatypes right from the start. No fully-automated generation of > XML-Schemas, but development of the schemas by > schemawriters (though part of the work can be automated). When I teach the data types or CDA, I point out that there's two irreconcilable camps in how to use XML. The first camp says that XML is just a transport, and you keep away from being clever, so that it just works. I call this is "the object mapping crowd" (and it solidly includes both you and me). The second camp says that XML is your concrete form, and you leverage it as hard as you can, including tricks in schemas and screwy one off things to make transforms easier. I call this the "XML hacker" crowd. And the two groups want different frequently incompatible things. XML4Pharma who you are quoting is certainly in the second crowd. The interplay between the two camps virtually guarantees that any XML standard is a political compromise. Give that guy a beer or two, and ask him about schema... (and, btw, if one was to follow his recommended method, you'd end up at the same place, unless either camp was to somehow figure out how to exclude the other. The details might be different, but the basic picture would be the same, I reckon) Grahame
