hi Tom thanks
> So considering the notion of order and filler ids, and whatever other ids > are required in a typical clinical process, it is clear that such things > need to be accommodated in archetypes, if they are not already in the > underlying reference model, because they are part of the information > recorded. The clinical process can't proceed without them (and remember, > they would still be needed with no computers and no IT - some identification > system is unavoidable). ok ta > I don't know about any such advice, and I am surprised by that, I would have > said use DV_IDENTIFIERs. ok ta > type: String - The identifier type, such as ?prescription?, or ?SSN?. One > day a controlled vocabulary might be possible for this. > > I don't think the 'type' is confused modelling; it just indicates what kind > of identifier it is. the identifier is a pointer to a thing. The thing has a type. The pointer to the type shouldn't carry the type of the thing it points to. (though I often think that debugging/troubleshooting would be simpler if it did!) You say that the type is the *type of the identifier*. Well, that's interesting. How can a pointer have a type? In the ISO datatypes, we added two properties to the II data type, "scope" and "reliability". Reliability is under appreciated, but adding scope has had a series of interesting consequences. Possible values for scope: BUSN : Business identifier OBJ : Object identifier VER : Version identifier VW : View specific identifier The really interesting one here is "BUSN". Here's the full definition: An identifier whose scope is defined by business practices associated with the object. In contrast to the other scope identifiers, the scope of the use of the id is not necessarily restricted to a single object, but may be re-used for other objects closely associated with the object due to business practice. Making this property explicit has forced everyone to re-evaluate their use of identifiers, and some interesting things have emerged. Firstly, we are crucially interested in two different types of identifier usage: what you might call "direct" and "indirect". (At one time you referred to this division as "real world identifier" and "technical identifier", but this isn't obvious in the tools, and I'm too lazy to look it up again). We have come to recognise that this is the same as a "business identifier" vs one of the other types. On further examination, we've found that business identifiers are almost exclusively linked with "roles" (RIM speak, sorry), and then where there are external registration authorities for the roles (patients, people, doctors, companies, etc) If by "type", you mean things like "scope" or "reliability", then ok. But the possible values need to be enumerated to make them useful to implementers. if by "type" you are referring to the kind of registration authority... then the lack of a controlled vocabulary field forces archetype designers to make the kind of registration authority explicit in the archetype so that the identifiers can be found and exchanged when required So the type is useless - in practice either it is not relevant or it's value is implicitly fixed. At least, I think so. I suppose I should scan the archetypes to check my assertion, particularly the demographics ones which are generally directly concerned with external registration authorities. anyhow, that's a side issue. Grahame
