>Thanks Graham, it is clear what you mean. >I must tell you, I work directly on the market, I have customers, who want >to get the Insurance-number from a patient in a GP-system, and process it >automated. > >(I already have difficulties with explaining why they have to use a >entityname and find in the connected entityNameParts which one the Lastname is. >Why don't you make a property Lastname, they ask me, and then I explain, >that is the way the standard works, and keep telling them the benefits of >using a standard.) > >Now I must tell them they have to recognize the InsuranceNumbere from >the OID which points to InsuranceCompany, somewhere??. > >There has to be a service on the Internet where one can translate OID's to >friendly names, something like DNS for IP. Or else, this system cannot work
yes, I know what you mean about standards. I straddle both sides (write and implement) I agree about a OID registry - a good automated distributed OID registry like the way that DNS works. I don't know about whether it's being worked on. I would've though it would be trivial if you based it on LDAP - all we would need is a common schema to use in the LDAP setups, and some impetus from ISO or something like that. >>not sure what you mean here? > >Was a stupid remark, I thought, just as with EntityNamePart, where one can >tell which kind of name one is reading, one could use a property to tell >which kind of ID one is reading, as an optional property. Too bad this is >not done. well, that's how the HL7 v2 identifier works, or doesn't work very well. The problem is that what kind of identifier something is is relative, and we are in all sorts of a mess trying to maintain the terminology for that property, to the point where I am starting to think that it has no safe meaning outside hard-coding it for a particular implementation. So, in other words, it's ended up collapsing to an arbitrary opaque string based implementation - like with OIDs, but with added danger because there is no method of being unique Grahame
