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. 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
