Grahame Grieve wrote: > Regarding OIDs and II, I think there's a misunderstanding > about the point of the OID part of the II > > The OID is computationally opaque - it's not intended to > tell you anything about the identifier, only to make it > unique. Any scheme based on reverse engineering the OID > into some form of information about the II that contains > it will founder. Even if we turned around and based it on > DNS, it still founders. The point is that the context of the II tells > you what
> kind of identifier it is. > > OK, I lie. I see that in it's common usage, certainly in > HL7 and apparently in CEN and openEHR - though I haven't > checked - things have a SET<II> or equivalent, which requires > that the II semantics themselves tell you more than simply > the value of the identifier. > > So I see a mismatch between the intention of II and it's use. Dear Grahame, For example the CEN GPIC subjectofcare which has a property id The type is a Set of II The use is excplained as: "An identifier or identifiers that may be used to uniquely identify the subject of care. Examples: social security number, health service number, hospital number, case notes number" Please indicate where there is a mismatch between the intention and the use of II. CENTC251 may want to learn from that. It would be a great benefit to the standard if this will be sorted out. And if it will, then the need for an extra qualifier to tell which the type of identifier is presented, may disappear, depending on your solution Kind regards Bert Verhees > > The problem with information about the identifier is that it's > rather hard to come up with a formal strategy for providing > metainformation about the II. Take for instance, the HL7 V2 mess > of codesets for describing the source identifier type. As a HL7 V2 > implementor, I know that it's done by site specific decisions, since > the mess is too far out of control. And V2.6 will only make this > worse. Rather like doing it by OID, and configuring it by hand. I > wouldn't want to be writing a general nation-wide HL7 receiver that > had to sort out identifiers. > > No wait, I did write such a spec for Australian usage. And we took > considerable care to nail down the Identifier usage so that this > situation didn't arise. > > From my perspective (V2 implementor and V3 data types editor), the > only possible solution - though I very much doubt it's feasible - is > for there to be an LDAP based health OID repository to allow dynamic > querying of the OID metadata. Sure, this would mean that you'd need > a live internet connection to do the query, but if you really are > writing a general case data mining tool with no ability to nail > the identifiers down in your incoming data, then this is the least > of your worries. > > Grahame > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
