Op dinsdag 15 maart 2005 11:44, schreef Grahame Grieve: > 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.
What if the context is patientExtendedInformation? A patient can carry many identifiers. > > 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. I don't know what the intention was, but the use, is to present one or more identifiers, connected to an entity. It seems to me a good 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. I do not want to substitute OID by metainformation, but add metainformation to II, as an extra property. A qualifier, like "insurance_number", "social_security_number", "local_system_id", etc > > 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. Even the least of all worries still is a worry, and it depends. I am not writing a general datamining tool, but I am writing a CEN layer to present data from local GP-systems in a standarized form. This works fine, and third parties know where they can find their data, independent of the underlying GP-system. And the patient carries a few identifiers, in a Set, and I want to mark one of the identifiers as an insurance-number. That is all. Though, the layer I am writing can be used for datamining, and will be used as such, but there are many more uses. I have no complaint about market-interests. > > Grahame -- Met vriendelijke groet Bert Verhees ROSA Software - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
