HL7 Oid Symposium (INM and VOCAB)

Questions/Observations With Responses

• 0 [Comment from L Mckenzie email 200508252104]:

**  We had a discussion on an HL7 Canada  	conference call today about OID strategy. I've attached the straw-man document we were  	reviewing here for anyone who's interested. As part of the discussion it was pointed out that it is  	pretty much impossible to find an 'official' HL7 position on OIDs and registrations anywhere on the  	HL7 website. (Even the registry itself is hard to see.) Judging by the questions I was fielding, HL7  	desperately needs such a document. 	

• • [Response from C McCay email 200508261652]: Lloyd - Here are some comments from Ian -- I agree that this is an issue that needs to be progressed -- and we need to look at what is the current practice (which is what Ian has addressed here in the main -- and what we would like to see in the future -- which needs to be a far fuller official position as you so clearly request
  • [Response from I Mansell email 200508261652]: There is an 'official HL7 position on OIDs and registrations' available in the Ballot pack (see http://www.hl7.org/v3ballot/html/infrastructure/datatypes/datatypes.htm#section- OID.procedures or see below text), under 2.14.1 in the Abstract datatypes document. [(Larson, document editor): Excerpt from the Abstract Data Types promoted to Question/Observation to facilitate grouping of responses. See item 0.01, key 34]
• 0.01 [Standards excerpt from I Mansell email 200508261652]:

**  Extract from Abstract Datatypes document  	(Ballot Pack 10): 	   	 2.14.1  HL7-Assigned OIDs 	HL7 shall establish an OID registry and assign OIDs in its branch for  HL7 users and vendors upon  	their request. HL7 shall also assign OIDs to  public identifier-assigning authorities both U.S.  	nationally (e.g., the  U.S. State driver license bureaus, U.S. Social Security Administration,  HIPAA  	Provider ID registry, etc.) and internationally (e.g., other countries Social Security Administrations,  	Citizen ID registries, etc.)  The HL7 registered OIDs must be used for these organizations,  	regardless  whether these organizations have other OIDs assigned from other sources. 	  	When assigning OIDs to third parties or entities, HL7 shall investigate  whether an OID is already  	assigned for such entities through other  sources. It this is the case, HL7 shall record such OID in a  	catalog,  but HL7 shall not assign a duplicate OID in the HL7 branch. If possible,  HL7 shall notify a  	third party when an OID is being assigned for that party in the HL7 branch.  	  	Though HL7 shall exercise diligence before assigning an OID in the HL7  branch to third parties,  	given the lack of a global OID registry  mechanism, one cannot make absolutely certain that there is  	no  preexisting OID assignment for such third-party entity. Also, a duplicate assignment can happen  	in the future through another source. If  such cases of supplicate assignment become known to  	HL7, HL7 shall make  efforts to resolve this situation. For continued interoperability in the  meantime,  	the HL7 assigned OID shall be the preferred OID used.  	 	While most owners of an OID will "design" their namespace sub-tree in  some meaningful way,  	there is no way to generally infer any meaning on  the parts of an OID. HL7 does not standardize or  	require any namespace  sub-structure. An OID owner, or anyone having knowledge about the  	logical structure of part of an OID, may still use that knowledge to infer information about the  	associated object; however, the techniques  cannot be generalized.  	  	Example for a tree of ISO object identifiers. HL7's OID is  2.16.840.1.113883. (link to graphic opens  	in a new window) <http://www.hl7.org/v3ballot/html/infrastructure/datatypes/graphics/L- 	datyp2fig5.jpg>  	    	An HL7 interface must not rely on any knowledge about the substructure of an OID for which it  	cannot control the assignment policies. 	

• • [Response from L Mckenzie email 200508262040]: Hi Charlie, Ian - I was aware of the ballot content, having read it once upon a time. However as evidenced by Cecil's response regarding the uniqueness of OIDs, even this information isn't clearly understood by all. Also, the content in the datatypes abstract doesn't go into sufficient detail to answer all of the questions I think need to be addressed to give people appropriate guidance. Further comments (way) below in Ian's feedback section:
• 0.02 [Question from L Mckenzie email 200508252104]:

**  I realize that HL7 may not have answers to all  	these questions yet, but it gets pretty embarrassing trying to sell implementers on the fact that HL7  	v3 is ready for prime time, then to have them ask questions like these and have to give the answer "I 	 don't know, and I'm not sure that anyone else does either . . ." 	 	I believe there was some vocab agenda time scheduled for OID registry discussions. Hopefully  	some of these questions can be addressed. I'm looking forward to seeing a draft document that  	addresses these, and perhaps other questions posted prominently on the HL7 website. :> 	

• • [Response from T Klein email 200508291049]: There is vocab WG agenda time every WG meeting, but we never seem to finish. Or rather, more new issues arise than the volume of the ones we resolve. I have to thank you very much for putting all of these issues in writing, since this can be used to construct an objectves list for stuff we have to deal with around OIDs and the OID Registry.
• 1 [Question from L Mckenzie email 200508252104]:

**  Who can register OIDs? 	

• • [Response from C Lynch email 200508261121]: Any one can register an OID
• 1.01 [Question from L Mckenzie email 200508252104]:

**  a. Is it limited to members can non-members do it  	as well? If members, how are affiliate members who don't have an HL7.org userid handled? 	

• • [Response from C Lynch email 200508261121]: There is no requirement that you be an HL7 member.
  • [Response from I Mansell email 200508261652]: Only members are allowed to register OIDs, and being a member of HL7UK I am free to register my OIDs using the same request forms as the rest of the HL7 membership.
  • [Response from L Mckenzie email 200508262040]: <Lloyd>Based on Cecil's response, it looks like we have disagreement here. There needs to be an official policy.</Lloyd>
  • [Response from C Lynch email 200508270058]: <Cecil>My response is that right now the registry is not in the Members only section of the site and is open to anyone, not just members.</Cecil>
  • [Response from T Klein email 200508291049]: Originally it was to be members only, but there have been credible arguments that anyone using HL7 messaging should be able to do so. You are right, there is currently no "official" policy on this.
  • [Response from T Klein email 200508291106]: Cecil is, as usual, correct. We have never been able to get to an agreement on whether it should be member-only, so its place on the website controls that, and right now it is public access.
• 1.02 [Question from L Mckenzie email 200508252104]:

**  b) Must OID requests be submitted by someone  	with authority in the organization responsible for the identifier, or can anyone register? 	

• • [Response from C Lynch email 200508261121]: No. Anyone can register as long as they submit contact info.
  • [Response from I Mansell email 200508261652]: Any person who will be available to deal with enquiries into the OID can request an OID root.
  • [Response from L Mckenzie email 200508262040]: <Lloyd>So by asking to have an OID registered in the HL7 registry, you're taking on the onus of responding to all queries about that OID? Ouch. Perhaps I don't want to be the one to register Alberta Unique Lifetime Identifier after all . . .</Lloyd>
  • [Response from T Klein email 200508291049]: Hmmm?good question. One would hope that it would be someone in an organization who is supposed to do this, but many organizations are not well enough organized to even track this kind of thing. I wouldn't make any kind of hard and fast rule about it.
  • [Response from L Mckenzie email 200508291140]: <Lloyd>Sounds like the answer would have to be 'anyone can register', unless we can come up with a policy that would allow specific exceptions.</Lloyd>
• 2 [Question from L Mckenzie email 200508252104]:

**  What 'types' of things can be registered? 	the existing OID form doesn't seem to differentiate between requests for OIDs for code systems,  	common identifiers or organizations. It probably should, as the data to be gathered will be distinct.  	For example, common identifiers should include information about the preferred format for the  	extension. 	

• • [Response from C Lynch email 200508261121]: There is no restriction on what a user registers, but there are categories that they may select to register. A user makes one of two choices. <choice="1">Request a new OID under the HL7 root</choice> <option value="4">Externally maintained identifier system</option> <option value="6">External coding system</option> OR <choice="2">Register an existing OID (not assigned by HL7)</choice> <Option value="1">HL7 registered internal objects <Option value="2">HL7 organizational bodies and groups <Option value="5">HL7 Internal Coding Systems <option value="7">HL7 Imported value set Coding Systems (imported tables) <Option value="8">HL7 OID registered documentation products and artifacts <option value="3" selected>HL7 Member requesting OID root for their own use</option> <option value="9">HL7 Registered conformance profiles <option value="10">HL7 Registered Templates <option value="11">HL7 defined and registered Value Sets
  • [Response from I Mansell email 200508261652]: The form includes organisations under the OID type 'External Group', code systems and identifier schemes are included as 'External Coding Systems' and 'External Identifier Systems' respectively.
  • [Response from T Klein email 200508291049]: The issue is that we have a single UI form for use by members, outsiders, and our own committee chairs, as well as the administrators. That is why it is somewhat confusing. General HL7 users should only register identifier systems. Cochairs should be able to register code systems, templates, and a bunch of the other types of things we have. We have some issues with some of the more complex functions in the UI for externally defined OIDs and establishing all of the metadata correctly. It needs to be fixed, but a large part of the problem is there are no cycles to even put together a good requirements document, much less build and debug the thing. We definitely need better documentaiton. No question.
  • [Response from L Mckenzie email 200508291140]: <Lloyd>I would think that general users (perhaps even non-HL7 members) might register templates.</Lloyd>
• 2.01 [Question from L Mckenzie email 200508252104]:

**  Are there other OID types? What are their  	characteristics? 	

• • [Response from C Lynch email 200508261121]: As far as different characteristics, these are not maintained in the OID registry at present. Each OID has the same information associated with it (to the extent that it is submitted by the registrant). Tom Oniki has submitted a form that has a few additional pieces of information that are gathered for a terminology that is being registered but it is not live yet and we may want to expand on that a little as well (my questions for Ted). [Editor, Larson: See item 15, key 26]
  • [Response from I Mansell email 200508261652]: The other HL7 OID types can be seen clearly in the attached document that I compiled from the contents of the HL7 OID registry, for use in along side the HL7UK OID and Artifact codes registry policy document.
  • [Response from L Mckenzie email 200508262040]: <Lloyd>Unfortunately the attachment didn't come through. Do you also identify the distinct meta-data and constraints (on registration or metadata) associated with each type?</Lloyd>
• 3 [Question from L Mckenzie email 200508252104]:

**  What is the 'approval' process for an OID? 	

• • [Response from T Klein email 200508291049]: We used to do all of this when there was a vocabulary technical committee voting process on code system registration and at least some discussion about identifier system registration. It was decided that all of this process was "slowing down version 3", so we took it all out and now it is a bit of a free-for-all. When I get some time occasionally, I look at what has been registered and sometimes send emails to registrants if things look fishy. But sometimes it is months between times of me doing this. The approval process is of two types: a) for a code system, when I change the status from "pending" to "complete", I send an email that says they are good to go. (unless it is rejected for some reason, then the other kind of email goes out) b) for an identifier system, I send nothing unless there is some kind of problem.
  • [Response from L Mckenzie email 200508291140]: <Lloyd>If I were to send you a request for the registration of "Alberta Provincial Health Number", and someone else sent you a request for the registration of "Alberta Unique Lifetime Identifier", would you register them both? How would you know that they're the same thing?</Lloyd>
• 3.01 [Question from L Mckenzie email 200508252104]:

**  Will the organization responsible for the identifier  	or the organization being registered be contacted? 	

• • [Response from I Mansell email 200508261652]: When possible HL7 will contact third parties to inform them that an OID has been assigned to them under the HL7 root.
  • [Response from L Mckenzie email 200508262040]: <Lloyd>So we assign before asking? What if they already have an OID? Shouldn't we check first? Also, what do we mean by 'when possible'. Is it based on having contact info? Is contact info required as part of registration? Is it based on how responsive they are? If we phone on a Friday afternoon and they've already left for the day, do we have the obligation to try again on the following Monday? Is it based on HL7's bandwidth (if so, we could end up with considerable inconsistency).</Lloyd>
  • [Response from T Klein email 200508291049]: I look over the metadata that they have entered, and if it looks like a mess, I contact them to fix it. If it looks like a duplicate entry, I contact them about it.
• 3.02 [Question from L Mckenzie email 200508252104]:

**  What will they be asked? 	- Do you already have an OID? 	- Are you in fact the correct organization to register as the owner of this identifier? 	- Is this contact information correct? 	- Do you follow good identifier practices (i.e. never re-using identifiers, even after 20 years)? 	- Is the description for the identifier accurate (e.g. setting bounding time ranges and jurisdictions -  	"U.S. SSN 1953 and on") 	

• • [Response from T Klein email 200508291049]: I would have no way to know, in general, if they are the corrrect organization to register anything in particular. That is their business. We do need to develop a document for good identifier practices just like the one we have for good vocabulary practices.
  • [Response from L Mckenzie email 200508291140]: <Lloyd>What happens if the person registering isn't the same as the organization responsible for the identifier being registered. Do you contact the 'responsible' organization at all? E.g. Do they get a chance to say 'hey, I've already got an OID', or 'actually, we don't maintain that identifier any longer, responsibility is now held by xxxx'?</Lloyd>
• 3.03 [Question from L Mckenzie email 200508252104]:

**  If asked anything, how long do they have to  	respond? (i.e. can they take two years to figure out if they have an OID or decide they want to  	register it in a different hierarchy?) 	

• • [Response from T Klein email 200508291049]: As far as time to respond, there is no set time. If I haven't heard back in a while, I bug them. The hierarchies are for administrative purposes and convenience only. These things are meaningless identifiers.
  • [Response from L Mckenzie email 200508291140]: <Lloyd>You and I both know that reality has little bearing on the 'political' decision for organizations of where their identifiers live. One of the things we're trying to avoid here in Canada is a continuation of the analysis paralysis that's prevented OIDs we know have been needed for the last two years from being registered. When you want an OID for something that a government agency is responsible for, they get very uncomfortable if it isn't under their direct control, and then they spend forever figuring out what the process is to get it registered in the 'correct' place.</Lloyd>
• 3.04 [Question from L Mckenzie email 200508252104]:

**  What if they say they don't want us to register an  	OID for their identifier/organization? 	

• • [Response from T Klein email 200508291049]: We shouldn't be registering things for someone else. When we do, we mark it as 'PROXY'. After that, there really is no followup.
  • [Response from L Mckenzie email 200508291140]: <Lloyd>My expectation is that most identifiers will be registered for someone else. For example, I doubt all the U.S. drivers license numbers were submitted by their relevant state agencies. The same will likely be true of all of the different college license numbers, provincial health identifiers, etc. It's just too much effort (and time) to bring the relevant organizations up to speed.
• 3.05 [Question from L Mckenzie email 200508252104]:

**  What if they don't respond at all? 	

• • [Response from T Klein email 200508291049]: Then I tend not to follow up any further until someone else complains. :-)
• 3.06 [Question from L Mckenzie email 200508252104]:

**  Do we have a standard package of information  	explaining what OIDs are and what HL7 is, and why we need them to have an OID, and that there's  	no nasty business impact or liability to them getting one? 	

• • [Response from C Lynch email 200508261121]: Ted will have to answer this one except the last point. There is some basic information that Peter MacIsaac submitted that explains what an OID is and why we need them. This will be posted and will be the entry page (likely along with these questions you are asking as a kind of FAQ).
  • [Response from I Mansell email 200508261652]: I don't think such a package exists. But if it is required in the HL7 world that an organisation has an OID then one can be assigned to them under the HL7 root with any explanation being given when required, this is not a process that needs to be carried out by organisations without an immediate use for such an identifier.
  • [Response from L Mckenzie email 200508262040]: <Lloyd>In general it's not the organization that issues the identifier that needs to use it. I doubt that the Maryland Department of Motor Vehicles has heard of HL7 or OIDs, and it's going to take a bit of effort to get them up to speed (while keeping them from panicking and just saying "no"). The need for the package is based on the assumption that we would actually contact the Maryland Department of Motor Vehicles if we decided we wanted to assign an OID for Maryland Drivers License Number. However, I think you just agreed above that we would contact such organizations if possible.</Lloyd>
  • [Response from T Klein email 200508291049]: Not yet. Would you write one for us? :-)
  • [Response from L Mckenzie email 200508291140]: <Lloyd>If you don't actually contact the registered organization who's being registered by proxy, there may not be much point.</Lloyd>
• 4 [Question from L Mckenzie email 200508252104]:

**  If an organization is issued an OID, do they then  	have full control over the arches beneath that node? 	(I.e. can they assign child OIDs to their heart's content?) What about if they register an identifier  	scheme or code scheme? 	

• • [Response from C Lynch email 200508261121]: Yes, they have full control over their tree.
  • [Response from I Mansell email 200508261652]: They do have complete control over the allocation of OIDs under their root, the same goes for affiliates, in HL7UK the registration of these OIDs with HL7UK is optional but if the owners of an OID root opt not to then they are required to maintain a persistent URL to a registry for those OIDs that they create. The registration of identifier schemes and code systems will have to be checked for duplication like any other OID registered and if duplication does exist (as the HL7 OID policy included above states) until the duplication is dealt with, the HL7 OID shall be the preferred OID used. The Hl7UK realm specific policy states that if the message is within the UK profile then the HL7UK OID will be the preference.
  • [Response from L Mckenzie email 200508262040]: <Lloyd>That policy would appear to directly contradict the international policy and also to be a barrier to interoperability. Is it within the mandate of an affiliate to make such decisions? Your response doesn't really address the question which was: If we assign an OID to SnoMed, is snomed allowed to create child nodes under that OID, and if so, what would that mean?</Lloyd>
  • [Response from T Klein email 200508291049]: Yes, yes, and no problem. Once they have a node, what is beneath it is their business, If they create an ontology that is messed up, that is their business. The may or may not register anything else beneath 'their' node. But if they want to use a code system under there in a message, they'd better register it. (unless it is a local code system, then it follows local code system rules).
  • [Response from L Mckenzie email 200508291140]: <Lloyd>Should we provide explicit guidance that says that registering child OIDs beneath code system and identifier OIDs is probably not a good idea, and regardless, can not be used in an HL7 message unless they themselves are registered?</Lloyd>
• 5 [Question from L Mckenzie email 200508252104]:

**  Can code schemes be registered without going  	through harmonization? 	

• • [Response from C Lynch email 200508261121]: What do you mean by "code scheme"? A terminology, domain, value set?? My understanding is that these have differing requirements depending on context of use. Ted will have to weigh in here.
  • [Response from I Mansell email 200508261652]: Yes.
  • [Response from L Mckenzie email 200508262040]: <Lloyd>Has vocab signed off on that? I thought that there was a requirement that code systems registered for use in HL7 must pass some sort of test for 'good vocabulary practice', such as not having 20 codes for the same concept not clearly marked as aliases, not re-using codes that had been deprecated, etc. Was I mistaken?</Lloyd>
  • [Response from T Klein email 200508291049]: It used to be no, but now it is a free-for-all. I don't agree with this, but being myself one of the major bottlenecks of the process when it was more heavyweight, I can't really argue against the current state of affairs.
  • [Response from L Mckenzie email 200508291140]: <Lloyd>So I can register my local lab coding system for my hospital where I happen to re-allocate any code for a test we no longer do to make sure I don't run out of 2-character identifiers?</Lloyd>
• 6 [Question from L Mckenzie email 200508252104]:

**  What are the criteria for determining whether an  	OID should be registered or not? 	I.e. Should ABC hospital register its internal OID for lab test result identifiers? If not, how do they  	know that? 	

• • [Response from C Lynch email 200508261121]: There are no specific criteria on what a user should or could register in their tree. It seems to me that one would determine this based on the use case for the "thing" outside of an institution or whether they find it more convenient to use the HL7 registry than build one of their own.
  • [Response from I Mansell email 200508261652]: If the identifiers are going to be used outside of the local context then yes they should, otherwise no.
  • [Response from L Mckenzie email 200508262040]: <Lloyd>Define local context? Local to one person might be "within the same application" to others, "within the same facility" to others it might be based on city or even jurisdiction. Also, it can be hard to know at the outset how identifiers are going to be used . . .</Lloyd>
  • [Response from T Klein email 200508291049]: The registration process is essentially an adjunct to the publishing process. When you register an OID, you are basically publishing the standard name of something you will be using, and a set of descriptive data about it that others can look up in the registry. Basically anything you want to register is no problem, AFAIAC.
  • [Response from L Mckenzie email 200508291140]: <Lloyd>Can and should are different questions. Do we *want* every hospital and clinic in the world registering their OIDs for prescription numbers, lab orders, lab results, local patient ids, etc.? We'd have over 100k OIDs easily just in North America. Even if we had *no* follow-up, you'd never have time to do your day-job. If we *don't* want all of those identifiers, then we need a clear policy that helps people understand when registration is required and when not.</Lloyd>
• 7 [Question from L Mckenzie email 200508252104]:

**  What's the process used for detecting duplicates  	during the registration process? 	

• • [Response from C Lynch email 200508261121]: Each OID is uniquely generated and no OID registered can be a duplicate (Indexed, no duplicates). As far as someone registering a duplicate "thing" with a different OID, that is legal. Hopefully they would query the registry first to see if exists and this should probably be added to the "instructions for use".
  • [Response to both 7 and 8]
  • [Response from I Mansell email 200508261652]: Currently a manual search through the OID registry.
  • [Response from L Mckenzie email 200508262040]: <Lloyd>By whom - the person registering or the HL7 person processing the registration? How does Ted know that Alberta ULI and Alberta PHN are really the same thing? (not sure there's an answer, but delegation of the duplicate search to realm might help. HL7 Canada HQ probably would know.)</Lloyd>
  • [Response from T Klein email 200508291049]: I eyeball 'em, and run some queries, etc. This is done only for code systems.
  • [Response from L Mckenzie email 200508291140]: <Lloyd>WHOA!! What about identifiers? The whole point of registering identifiers is to ensure that you never have more than one OID approved for use by HL7 for the same thing. It ensures you can perform identify matching by just doing a string compare on root and extension. If we don't check for duplicates, then we have no need for an OID registry for ids. People can get their OIDs where-ever and it won't matter. The datatype specification explicitly says we're going to only allow one OID per identifier system. Why aren't we enforcing that with our process?</Lloyd>
• 8 [Question from L Mckenzie email 200508252104]:

**  What happens if a duplicate OID accidentally gets  	registered? Is one of them deprecated? 	What does deprecation mean? What happens to systems that are using the old OID? 	

• • [Response from C Lynch email 200508261121]: Each OID is uniquely generated and no OID registered can be a duplicate (Indexed, no duplicates). As far as someone registering a duplicate "thing" with a different OID, that is legal. Hopefully they would query the registry first to see if exists and this should probably be added to the "instructions for use".
  • [Response to both 7 and 8]
  • [Response from I Mansell email 200508261652]: If a duplicate is found, until the issue is settled, the Hl7 assigned OID shall be the preferred OID used.
  • [Response from L Mckenzie email 200508262040]: <Lloyd>What if HL7 assigns more than one OID? For example, what if I submit a request for an HL7-assigned OID for "Alberta Unique Lifetime Identifier" and someone else submits a request for an HL7-assigned OID for "Alberta Provincial Health Number" and Ted issues both. Someone then comes along and says "Hey - those are the same thing, which do I use?". We need: a) a process for deciding which one will be the 'preferred' OID; b) a means of identifying that information in the registry; c) an expectation of when implementers are expected to transition; and d) a set of expected behaviour for what to do in the mean-time.</Lloyd>
  • [Response from C Lynch email 200508270058]: <Cecil>I think this is fairly clear in the 2.14.1 snippet as to what happens when there is a duplicate registration. That said, again, there is no prohibition about an entity having more than one OID to identify itself, only the prohibition for someone to use a non-HL7 approved OID in a message. Clearly indicating the OID status in the registry could handle the duplicate problem should it occur.</Cecil>
  • [Response from L Mckenzie email 200508270128]: Hi Cecil, The duplicate issue is where you have duplicate OIDs both marked as "HL7 approved". I could care less about duplicates that aren't HL7-approved.
  • [Response from T Klein email 200508291049]: We try to remove (deprecate) one. It is marked as "obsolete" and the registrants are notified.
  • [Response from T Klein email 200508291106]: [Responding to Cecil] To my knowledge, HL7 has not taken a position for anything other than code systems about duplicate OIDs. For code systems, somewhere it is written (I'll be doggoned if I can find it now) that there is only one OID that should/can be used to identify a code system (in the CD datatype and its children) in V3 messages. We probably need to figure this one out pretty soon before we have a hodge-podge on our hands.
  • [Response from L Mckenzie email 200508291140]: <Lloyd>What about the 10k implementers who are using it? What are the rules if you're currently using an obsolete OID? How do you know what the correct OID is? How long do you have to transition? Do applications have an obligation to check for the use of obsolete OIDs and transform them to the 'approved' OID before invoking matching algorithms?</Lloyd>
• 9 [Question from L Mckenzie email 200508252104]:

**  What happens if someone registers the OID for an  	identifier type, and then the organization responsible for that identifier comes along and insists that  	their own 'official' OID be used instead? 	

• • [Response from C Lynch email 200508261121]: No OID would be deprecated since there is no requirement for a single identifier for an item. Ted can comment on what approach he would take for harmonization between the registrants.
  • [Response from I Mansell email 200508261652]: Same as point 8.
  • [Response from L Mckenzie email 200508262040]: <Lloyd>The question is: What are the criteria for settling the issue? Is the default position "tough luck, someone else got here first", or do we try to accommodate the "responsible organization" even though transitioning OIDs will cause grief for implementers?</Lloyd>
  • [Response from T Klein email 200508291049]: Then they register the new one, and the old one can be marked as 'obsolete, deprecated' or not, it is their choice.
  • [Response from L Mckenzie email 200508291140]: <Lloyd>There should be a lot more barriers than just "whatever you like" given the amount of work involved for implementers. Remember, any implementer who uses a non-approved OID when an approved OID exists is non- conformant.</Lloyd>
• 10 [Question from L Mckenzie email 200508252104]:

**  Who is allowed to change the contact information  	for an OID that's already been registered? 	

• • [Response from C Lynch email 200508261121]: Right now it is only an OID administrator (Ted and Harold have access). This said, I am designing a page that will allow the registrant to edit selected information for the OID they registered.
  • [Response from I Mansell email 200508261652]: Currently only the OID registry administrators can do this, but Cecil Lynch is making / has made changes to the HL7 OID registry to allow the original OID submitter to also make changes.
  • [Response from T Klein email 200508291049]: Me. The responsible party contacts me to change it, and change it I do (but sometimes not in as timely a fashion as everyone would like; sorry...)
  • [Response from L Mckenzie email 200508291140]: <Lloyd>Is that envisioned as staying that way?</Lloyd>
• 11 [Question from L Mckenzie email 200508252104]:

**  How are realms involved? Can they register their  	own OIDs? Are they *required* to register their own OIDs? 	(I have strong reservations about anything other than a global registry.) Are they involved in the  	approval process? How? 	

• • [Response from C Lynch email 200508261121]: Ted has to answer this one in detail. There is a problem in that the old OID site with a form that you download is still reachable by Google search and is referenced by the UK HL7 site so people may go to that site and pull a static pdf for registered OIDS that is not updated.
  • [Response from I Mansell email 200508261652]: Yes as mentioned above, realms can register own OIDs under their root. Up until now there has been no facility to register these OIDs in bulk also with no requirement to register these centrally. I have been an advocate for a centralised OID registry since I brought it up at the January WGM, with discussion continuing since with different affiliates have very different views.
  • [Response from L Mckenzie email 200508262040]: <Lloyd>My preference would be: central registry, delegated submission and decision-making. All registered OIDs must go in the central registry</Lloyd>
  • [Response from T Klein email 200508291049]: Ian Mansell started some very good discussions along these lines, which were continued last meeting. Every WG we move towards figuring this one out, but we don't yet know quite what to do yet.
• 12 [Question from L Mckenzie email 200508252104]:

**  For that matter, who *is* involved in the approval  	process. 	I.e. Who takes requests, looks for duplicates, contacts the respective organizations, answers  	questions, and gets the OIDs actually registered? 	

• • [Response from C Lynch email 200508261121]: That would be Ted.
  • [Response from I Mansell email 200508261652]: The OID registry administrators.
  • [Response from T Klein email 200508291049]: Right now, ME. Getting the picture why I have no cycles for anything else? And why there are a lot of errors that would be cleaned up with a little more time input?
  • [Response from L Mckenzie email 200508291140]: <Lloyd>My recommendation is that we delegate to the realms for the approval function (after providing everyone with a consistent set of approval guidelines). Any chance we can shift some of the U.S. responsibility to HQ? When v3 catches on in a big way there, you're going to get swamped.</Lloyd>
• 12.01 [Question from L Mckenzie email 200508252104]:

**  You should expect 100 odd identifier types coming 	 out of Canada in the next 2-3 months, with more to follow that, not to mention the vendors, hospitals 	 and others who may be registering for OIDs. Will your process scale to this volume * 30 odd  	affiliates? 	

• • [Response from C Lynch email 200508261121]: Ted, do you scale?
  • [Response from I Mansell email 200508261652]: The HL7UK OID registry currently has 159 OIDs which need to be registered along with those from NPfIT that have not been included as of yet. This process will need automating, which I think will be helped in some way by the functionality of NISTs new OID registry being led by Len Gallagher.
  • [Response from L Mckenzie email 200508262040]: <Lloyd>The trouble with automation is that it doesn't solve the issue of contacting the assigning authority nor of duplicate checking.</Lloyd>
  • [Response from T Klein email 200508291049]: If all of that stuff came out of Canada, all at once, I would deputize some Canadians (such as yourself) to help.
  • [Response from T Klein email 200508291055]: [Responding to Cecil] Well, I occasionally stand on a scale to see how much beer weight I am putting on, but that is about it :-)
• 13 [Question from L Mckenzie email 200508252104]:

**  Are there any firm rules about when GUIDs  	can/can't be used instead of OIDs? 	

• • [Response from C Lynch email 200508261121]: I have not seen them if they exist.
  • [Response from I Mansell email 200508261652]: There are some rules included in the abstract datatypes document here: http://www.hl7.org/v3ballot/html/infrastructure/datatypes/datatypes.htm# dt-UUID see below: "UUIDs are not the preferred identifier scheme for use as HL7 UIDs. UUIDs may be used when identifiers are issued to objects representing individuals (e.g., entity instance identifiers, act event identifiers, etc.) For objects describing classes of things or events (e.g., catalog items), OIDs are the preferred identifier scheme."
  • [Response from L Mckenzie email 200508262040]: <Lloyd>Cool. This should be incorporated in the OID policy paper. I believe there's also a requirement that all 'common' identifiers must be OIDs (because we have an OID registry, but not a UUID registry).
  • [Response from T Klein email 200508291049]: None that I know of.
  • [Response from L Mckenzie email 200508291140]: <Lloyd>The UK pointed out some language currently in the ballot. Also, seeing as you can't register GUIDs, it would make sense that OIDs would be required for all common public identifiers. Suggest we include language to this effect in the policy document.</Lloyd>
• 14 [Question from L Mckenzie email 200508252104]:

**  Do we have any intention of actually using the  	"HL7-assigned string" thing for II.root? If not, can we get rid of it? 	

• • [Response from C Lynch email 200508261121]: A Ted question.
  • [Response from I Mansell email 200508261652]: The definition of the properties of II can be found here: http://www.hl7.org/v3ballot/html/infrastructure/datatypes/datatypes.htm#prop-II.
  • [Response from L Mckenzie email 200508262040]: <Lloyd>I'm familiar with the definition. And I know why strings were put there - people were worried that instances would be unreadable with OIDs. My question is: Are we ever going to issue strings, and if so, what's the process. If we're not, then there's no point declaring support for it in II.</Lloyd>
  • [Response from T Klein email 200508291049]: "HL7-assigned string thing"??? What is that? The 'symbolic short name' is entered by the registrant. I don't really know what you are talking about here. Can you give me an example?
  • [Response from L Mckenzie email 200508291140]: <Lloyd>No examples cause none exist yet. The II datatype allows the root to be an OID, a GUID or an HL7-assigned string. I believe the 'string' thing was added to get over people's discomfort having long ugly strings in their identifiers. However, if HL7 never approves any strings, then we've really just been playing games . . . </Lloyd>
• 15 [Question from C Lynch email 200508261121]:

**  Can we add additional fields in the data base for  	terminology registration characteristics such as "Is post-coordination allowed/supported? Are  	concepts permanent? Is the terminology available for download? What is the url for access? What is 	 the release schedule for updates?"? 	

• • [Response from T Klein email 200508291055]: As far as adding new fields, I have no problem doing that. BUT - we may have to coordinate with the UK, Finland, and Germany at least. And NIST…
• 16 [Notification from L Gallagher email 200508261739]:

**  Vocab - Attached below is a portion of what  	Cecil sent to Vocab earlier today in response to one of Lloyd's  questions. I [as the one who needs  	to make appropriate extensions to ObjectType in the HL7 Artifact Registry (cf  	http://www.nist.gov/hl7xreg )] extract from it to derive a list of the different options that a User of  	the OID Registry has to Register something.  	  	      <Option value="1">     RegisteredObject - Internal 	      <Option value="2">     Organization - Internal 	      <Option value="3">     RegistrationAuthority - Under HL7 	      <Option value="4">     IdentifierSystem - External 	      <Option value="5">     CodeSystem - Internal 	      <Option value="6">     CodeSystem - External 	      <Option value="7">     CodeSystem - Imported 	      <Option value="8">     RegisteredDocumentation/Artifacts - Internal 	      <Option value="9">     Profile - Conformance 	      <Option value="10">   Template 	      <Option value="11">   ValueSet 	

• • [Response from ]:
• 16.01 [Question from L Gallagher email 200508261739]:

**  Is it correct to assume that option values "1", "2",  	"5", "7", "8" are off limits to a normal user of the OID Registry because they are reserved for Internal  	HL7 affairs? Only HL7 Staff or approved  Editors, etc. would be able to use these options to register 	 something. 	

• • [Response from T Klein email 200508291101]: Yes, exactly.
• 16.02 [Question from L Gallagher email 200508261739]:

**  Is it true that Option "3" is the way that an  	Organization (HL7 Member or not) makes a request to HL7 that it be registered as a Registration  	Authority (as defined by ISO/IEC) under the HL7 root OID? 	

• • [Response from T Klein email 200508291101]: Yes, exactly.
• 16.03 [Question from L Gallagher email 200508261739]:

**  Is there any chance that a single Organization will  	unintentionally be assigned two different OIDs by HL7, one under Option "2" and one under Option  	"3"? 	

• • [Response from T Klein email 200508291101]: No. An administrator creates entries under '2' for things like HL7UK, etc. Others create 'em themselves under '3'. So unless I really screw up, this shouldn't happen.
• 16.04 [Question from L Gallagher email 200508261739]:

**  Is it true that Options "1", "2", "5", "7" and "8" are  	really just IdentifierSystem registrations used internally by HL7? In particular, does Option "8"  	represent the InstanceIdentifier base that  should be used when referencing an HL7 artifact by  	ArtifactId? e.g. COCT_MTddddddUVdd would be uniquely identified by: 	  	baseOID:    2.16.840.1.113883.8     (where 2.16.840.1.113883 identifies HL7 as a Registration  	Authority and the trailing 8 identifies the IdentifierSystem for HL7 artifacts) 	 identifier:     COCT_MTddddddUVdd 	

• • [Response from T Klein email 200508291101]: This was the original intention when this branch was created, but it never got any traction up to now.
• 16.05 [Question from L Gallagher email 200508261739]:

**  Is it valid to conclude that the OID Registry  	supports registration of OIDs for a limited number of different object types (when used by a normal  	user - not HL7 staff), and if one were to classify the things being registered by ObjectType, that list  	of possible object types might be: 	  	     RegistrationAuthority 	     IdentifierSystem 	     CodeSystem 	     Profile 	     Template 	     ValueSet 	

• • [Response from T Klein email 200508291101]: Kinda. Right now, I am assuming that registration of Templates will come through the Templates committee. I don't know much about 'Profile'. Up to very, very recently value sets were not registered at all. There is still some disagreeement whether or not they should be (I support their registration).
• 16.06 [Question from L Gallagher email 200508261739]:

**  To harmonize the HL7 OID Registry with the HL7  	Artifact Registry is it sufficient to ensure that the Artifact Registry be able to properly handle this list  	of six different object types? I.E, to include appropriate classifications, associations and external  	identifiers for these basic object types. 	

• • [Response from T Klein email 200508291101]: I'm not sure without looking at it more closely. We should sit down and talk about this in San Diego. Will you be around for the Sunday meetings?
• 17 [Notification from C Lynch email 200509091419]:

**  The OID Registry has been migrated to the  	production server thanks to Mike Craig, and is now operational again at  	http://www.hl7.org/oid/frames.cfm or via the link from the HL7 home page. I would appreciate  	suggestions for improvements, usability comments, etc. 	

• • [Response from T deJong email 200509110701]: First time I took a serious look at this; looks very good in general. Two questions: 1) Registration is now limited (as far as I can tell) to OIDs directly below the HL7 node. Any chance of allowing child nodes to attach their own OIDs (etc. etc.)? 2) If that would not be the case. Any chance of supplying the source for the registry, so child nodes (most notably affiliates) can use this for their local registry?
  • [Response from C Lynch email 200509111327]: You can actually register an External (not under the HL7 root) OID as well as generate an HL7 OID. One way to accomplish what you want is to generate your HL7 OID, then register your self generated children OIDS as External OIDs. NCI has done this. Alternatively, you are certainly welcome to the source code to maintain your own registry, but there might be advantages in just using the main HL7 registry (the OIDs would all be registered as artifacts in the NIST registry automatically, just one place to update when features are added to the OID registry site, only one place for a user to have to look, etc).
• 18 [Notification from M Stephens email 200510260727]:

**  I have uploaded an OID registry validation tool to 	 the vocab documents page[1]. The stylesheet was written to ensure all of the entries in the HL7 UK  	registry appear in the HL7.org registry. The stylesheet accepts two parameters for the subset and  	superset registries and could be useful to other affiliates who want to check all of their OIDs appear 	 in the HL7.org registry. 	

• • [Response from ]:
• 19 [Question from P Aitchison email 200511220313]:

**  In a SET<II> I have been asked to allocate an OID to 	 a UUID in order to make it obvious within the SET. The other values in the SET all use OIDs. I am  	unhappy about allocating an OID in this manner because the UUID stands as a UID on it's own. I can  	understand that there would be an issue if I had 2 UUIDs in the SET but I haven't. 	Can anyone advise please? 	

• • [Response from G Grieve email 200511220334]: I believe this is a very bad practice for several reasons. The point of oids is that they don't have meaning. Why have you been asked to do this? We are going to have an OID symposium at the next WGM (joint meeting between Vocab and CQ), maybe we can explore the bigger issue there?
  • [Response from D Markwell email 200511220548]: I absolutely agree with your unhappiness. Allocating an OID to a UUID means some one is assuming the OID has a meaning. OIDs have no meaning other than to uniquely identify. Identification and meaning are often confused by people but they are very different. I can identify a thing without knowing its purpose/meaning AND I can appreciate the meaning of something without uniquely identifying it. I can understand perhaps how the confusion arises since OIDs are also used to identify coding systems. However, the coding system identified gains it meaning from the link between codes and meanings within the system and not from the OID itself. It would also be possible to construct a coding system in which OIDs or UUIDs were used as the"codes" (or concept identifiers). However, in this case the code system would need to link each of the permitted values to a meaning. Furthermore, the resulting expression would go in a CV or CD datatype not in an II and whats more it would only identify a concept not the class it was in. Therefore, in my opinion you should not allocate an OID to a UUID. The use-case should be examined and met by a more appropriate mechanism.
  • [Response from L McKenzie email 200511220724]: Wholly agree. You either have an OID or a UUID but having both is silly. Systems should match the OID + extension as a string. If you care about the "meaning" of an identifier, then it should be on a separate Act or Role and the Role.code or other attributes should be used to convey that meaning.
  • [Response from G Jewell email 200511221025]: So, there really are only very specialized scenarios where I should have a set of identifiers. If I can't tell the person's SDS User Id from their GMP Code except through the scoping organization or the role.code, then the UK's use of SET<II> is incorrect. I should only use a SET<II> datatype when the entity can have multiple identifiers of the same type (role.code) assigned by the same organization. I'm going to guess they should be using the "OtherIDs" relationship. In the current model of the UK interfaces, we need to use the OID to tell us the "assigning authority" and "identifier type" that was part of the v2 EI data type.
  • [Response from L McKenzie email 200511221047]: The number of circumstances where SET<II> makes sense on Role is very limited. I believe the UK has the concept of "business identifier" as well as "version identifier" and even "view identifier" which allow referencing to specific versions and specific subsets of information about the role. Because we haven't provided separate places for these to be conveyed (yet), they may be using SET<II> to meet that purpose. Also, be careful about the assumption that the identifier is assigned by the scoper. Identifiers are *used* by the scoper, but could well be assigned by another organization. For example, a hospital might use SSN as their patient id (not recommended, but it happens). In that case, the identifier is *assigned* by the U.S. government, but the scoper would still be the hospital. SET<II> is much more appropriate when used on Entity, where it basically says "Here's a bunch of identifiers by which this entity is known", but no information is provided about whether the identifiers are patient ids, drivers' licenses, credit card numbers, insurance ids or whatever. Their sole purpose is to allow matching. It is technically possible to do a lookup for a particular OID to determine the assigning authority and 'type' of an identifier. However, systems should never depend on the receiver having this information. If it's important to know that a particular id is a driver's license, then this should be conveyed as part of the message.
  • [Response from G Grieve email 200511221356]: Personally, I believe that there is no place where SET<II> is appropriate given the current scope of the II. It tells you nothing about the meaning of the II, and I have an real interoperability problem with the idea of getting a set of II's and having no meaning for them. (also I don't like the idea that there can be multiple ID's with the same role and meaning). I also believe that implying [the "assigning authority" and "identifier type"] is not really sustainable, but I don't think that there's any other choice right now. I also know that there's serious unhappiness with this currentarrangement. Hence why we (vocab abd INM) are hosting an OID symposium at the next WGM. This will let us air - and hopefully start to resolve - questions like this.
  • [Response from T Klein email 200511270702]: Penny- Each II in the SET<II> is of type UID.A UID may be a (root, extension) tuple or just a (root) if that uniquely identifies the object. For many identifier systems, the identifier is not guaranteed globally unique, therefore we use an OID as the root, and the identifier as the extension However, a UUID is globally unique, therefore there is no need for an OID. In fact, doing so is bad practice.
• 19.01 [Question from D Markwell email 200511230321]:

**  I think it is important to disentangle the SET<II>  	discussion in general from the specific question that Penny raised on UUIDs. 	 	I take a slightly different view on SET<II> in that I think it is reasonable for two identifiers that refer to  	the same instance to exist. These are rather like "translations". The OID root can/does identify the 	source identifier scheme it just does not provide any semantics. In this sense the root (OID) identifies 	 the assigning source scheme - the scope within which the identifier is unique (whether this is an  	authority is debatable). 	 	In the case of a UUID there is only one source scheme (e.g. the standard UUID algorithm) and it  	makes no sense to carry the added burden of identifying the source separately. I believe the use  	case that Penny referred to was such that an OID might be allocated to UUIDs used for a particular  	purpose (it would be pointless to add an OID just for uniqueness). This is clearly a wrong use of the  	root OID because it seeks to assign a meaning to the identifier. 	 	These is another issue related to identifiers of instances in different views (business, snapshot and  	templated-snapshot) which needs to be handled by HL7 and which is properly a topic of an active  	debate. This does need to be resolved but doing it through addition of semantic significance to an  	OID is not the way to manage this. It is incorrect, verbose and breaches a key element of  	standardisation. 	 	[Editor, Larson: promoted to observation level to facilitate grouping of responses.] 	

• • [Response from C McCay email 200511230505]: I agree that there can be "translations" for identifiers -- but as soon as there are there is (almost) always a requirement to know how to select which of the identifiers to use for a given purpose (by "assigning authority" or some such). Such discrimination between members of the set of identifiers can only be done on the basis of semantics. Thus since II.root does not carry semantics there is no use case for SET.II -- and both the NHS MIM and the HL7.org PA messages should be modified to allow only one II, and use otherIds for the rest. It is of course counter-intuitive, frustrating and confusing for users of the standard when there is an II.root OID that is registered as the OID for "UK NHS number", and be told that it must be sent in the message, but that should not be used to establish that the identifier in the extension is an NHS number -- this information must be obtained from elsewhere in the message (and/or its specification). However this frustration and confusion is something that can only be overcome by providing models where it is clear where that information does come from, and by having a fruitful oid symposium to produce further clarity as to why II works the way it does
  • [Response from D Markwell email 200511230630]: Charlie - I think your logic is incomplete regarding semantics and identifiers. If multiple identifiers are present then the recipient can look for a match on any one of these. That is if they have an existing record of with the complete root/extension pair they have a match. So SET<II> works in a heterogeneous loosely coupled environment to allow exchange of information identified differently in two systems - provided that one reference system has both identifiers. I am not sure this is really a major use case but have heard it advanced in the past and it certainly has the potential to work. However of course for UUIDs it is irrelevant to have the OID even if there are multiple UUIDs as a simple match on the UUID is enough. The primary problem is the overloading of the idea or identifier. A sensible reworking of this would be extraordinarily helpful. A Instance identifiers of information objects: 1. Business process identifier - where an information object content can evolve without changing the ID 2. Snapshot identifier - where the information object contents represent information at a given point in time and are immutable 3. Templated identifier - where the information object contents as stated are complete and immutable (completeness being defined by a scoping template??) B Real world identifiers: 4. Named identifiers having a specific "purpose" (e.g. to "identify a person" or to "identify a business transaction in a given context" - such as a "claim number" or"referral number") and a specific "issuing authority" (e.g. "UK NHS")
  • [Response from L McKenzie email 200511230650]: Would it be fair to say that Type #4 is really a special case of #1 that is flagged as "human readable"?
  • [Response from D Markwell email 200511230703]: I think that #1 and #4 have much in common but while type #4 may be able to serve as #1 the reverse is not the case. An essential feature for #4 is for communication of a processable form of the "name" (purpose and authority) - not just human readability. The computer application needs to know which field to use to display a particular named identifier or where to print it on a report and with what title. For roles this may be managed by scoping but it's a fairly heavy weight way to name a common field. In principle #1 to #3 types can serve a useful purpose by just knowing they are always unique references to the same information object.
  • [Response from C McCay email 200511230719]: David- Many thanks -- I accept your possible usecase, and also your expression of the need to deal with the different forms of identification and instance versioning. II and act.id as they stand with their semantic-free roots are not up to this task, and we agree that kludging semantics into the II.root is not the fix. While act.id as SET-II is needed for your usecase, it is an uncomfortable kludge for dealing with the different forms of identification+versioning needed -- which are not analogous to translations for codes, but seem to me genuinely different attributes which support different processes. I attach a draft write-up on the subject that is yet to be fully updated following feedback from the HL7UK technical committee and others.
• 20 [Question from P Biron email 200511292124]:

**  In RoseTree an OID is specified for each vocab domain 	 (well, actually, only for "T" domains and not "D" domains...BTW, what is a "D" domain?). However,  	those OIDs are not listed in the HTML rendition that is part of the 2005 Edition. As these OIDs are  	what people are supposed to use for  	CD.codeSystem, shouldn't they also be listed in the spec (and not just in RoseTree)? I note that they  	are also not in the XML export from RoseTree (which is most likely why they are not in the HTML,  	which is generated from the XML export :-). Am I just missing something here or is there  	something wrong? 	

• • [Response from L McKenzie email 200511292210]: Hi Paul, The OIDs are for the "code system", not for the domain. I.e. We only have an OID for tables, not for domains. Domains are abstract and don't actually have codes in them.
  • [Response from M Walker email 200511292240]: Hmm, I need a refresher from someone out there. I know why code systems have OIDs, and I have heard some strong arguments suggesting that providing OIDs for value sets is a good idea. Now, why should an OID be assigned to a Domain?
  • [Response from L McKenzie email 200511292303]: Hi Mead, They shouldn't. Domains are identified by globally unique name. There's no reason for them to ever have OIDs. The only reason for value-sets to have OIDs is so we don't have to worry about giving them globally unique names when the number of them starts approaching the 100k level. Code systems have OIDs for identification in the instance.
  • [Response from T deJong email 200511300211]: That may all be true, but I'd still like to support Paul in his request. Fact is that the values associated with an HL7 defined domain (take Confidentiality as an example) are often used as the code system in instances. As such, the vocabulary listing is the source for all HL7 defined code systems.
  • [Response from L McKenzie email 200511300806]: Hi Tom, Confidentiality is a domain, as wll as a table from which a valueset is drawn and bound to the domain for the representative realm. Domains *never* have codes of their own. If you see a code in RoseTree, you'll see a code system.
  • [Response from P Biron email 200511301452]: [Referencing McKenzie statement] The OIDs are for the "code system", not for the domain. I.e. We only have an OID for tables, not for domains. Domains are abstract and don't actually have codes in them. [end reference] Sorry...I can NEVER keep the vocab definitions straight (and the recent "definitions" document that is going around only confuses me more, BTW). I use "domain" for everything...sorry if that clouded my question.
• 20.01 [Question from T deJong email 200511300211]:

**  I too find it very cumbersome to have to resort to the  	OID repository every time I reference one of the code systems in a spec. Couldn't we integrate them  	in the listing? 	

• • [Response from P Biron email 200511301412]: I didn't even realize they were in the OID registry (I guess I should have figured that out). But, like Tom, I don't see why someone who looks in the vocab chapter to find the term they want then has to do a search in the OID registry or fire up RoseTree to know what OID to use! p.s. ActCode, etc. ARE referred to as Vocabulary Domains in the vocab chapter...hence my use of the term in my initial message :-(
  • [Response from L McKenzie email 200511301715]: Hi Paul, The tricky bit is that because it's universal, ActCode is a domain, a code system AND a value-set.
  • [Response from M Walker email 200512011023]: [responding to McKenzie] I would have said that Act Code is associated with a whole collection of domains - which ideally would be arranged in some sort of hierarchy, a bunch of code systems, and a whole host of value sets.
• 20.02 [Question from P Biron email 200511301452]:

**  Act.code is a CD. Suppose I want to encode an  	admitting diagnosis. I need to say something like: 	 	<act> 	 	</act> 	 	The ONLY place I know of to get the proper OID to populate @codeSystem with is from RoseTree.  	Why? Shouldn't that OID be listed in the Vocab chapter of the spec? 	

• • [Response from L McKenzie email 200511301710]: Hi Paul, It may be reasonable to ask for the OID in the ballot, however the best place is the OID registry. (OIDs for LOINC, SNOMED, etc. Won't be in RoseTree.). Might be good to have a hyperlink to the registry in the vocab intro.
• 20.03 [Question from M Walker email 200512011023]:

**  One interesting and important question is how should 	 these be documented under HL7 auspices, and to what extent should they be included in the  	standard. 	[Editor, Larson: Mead is talking about a hierarchy of associated domains, code systems and value  	sets.] 	

• • [Response from M Cassidy email 200512011118]: re: Mead's question on how and where (in the standard?) this should be documented - my opinion is that whether part of the standard or not, there should be a concise document hanging off the "HL7 OID registry" page - something like a whitepaper or other informative document.
• 20.04 [Comment from T Klein email 200511301731]:

**  Paul and Tom, 	The issue is a tooling issue, and the lingering confusion borne of the (bad) practice in the past of  	naming a domain, value set, and code system with the exact same string of characters, thereby  	confusing all and sundry. 	 	A Domain is a semantic type, and is a reference to a non-rigorously defined constraint statement  	(prose). In the tooling it is used in the binding of a specific collection of coded values to specific  	items in a static model. The only reason a Domain could ever be argued to have an OID would be for  	convenience only, since we have machinery that deals with OIDs for globally unique objects. 	 	It would be nice if all the tooling and publications surfaced the OIDs easily so that you didn't have to  	check many places for the information you need, but again, that is a tooling issue. 	 	You can't 'know' the code system from the Domain, since there is a 1..n relationship between a  	domain and a code system. You have to go through the Realm and Value Set machinery to identify  	the code system. For complex structures in a message instance where you have Realm- 	specializable objects inside templates with different conformance profiles that are part of  	CMETs...well...you actually have to do some pretty fancy run-time evaluation of parallel streams of  	stuff to figure out whether or not a particular vocabulary term is valid in a particular place in a  	particular message instance. It took me many hours of discussions with Lloyd and Woody before I  	finally grasped what was going on. These relationships are NOT static, and cannot be directly  	expressed in a static structure, such as an excel table. 	 	We have also had issues in the past that we are still trying to get the last remaining bugs out of  	where the denormalized copy of the OIDs in the RIM Repository from which the ballot is derived and  	against which the tooling (such as RoseTree) run became desynchronized with the OID registry on  	hl7.org, which is the Source Of Truth for code system and value Set OID assignments. Only a  	handful of errors remain. 	 	We recently decided that all Value Sets would have OIDs, again for convenience primarily since the  	machinery is already in place. Note that the identification of a Value Set is NOT contained in a  	message instance 'on the wire'. 	 	We are spending time with the definitions because it is a fairly complex piece of gear, and everyone  	who is not immersed in vocabulary full-time seems to be getting confused by all the published  	documents we have so far. Volunteers to improve the documentation are welcome (and solicited). 	

• • [Response from T deJong email 200511301926]: Hi Ted, Thanks for you excellent explanation. I knew the difference between vocab domain, value set and code system, but can certainly understand why the difference is sometimes hard to explain to 'outsiders' (i.e. people that implement but don't design HL7 models and messages). In the end of course, implementers only care about code systems, and the OID that belongs to them needs to be present in their instances. Fact is that many vocabulary domains in the HL7 ballot have an associated code system in the universal realm (i.e. an HL7 defined code system). Wouldn't it be possible to link directly to the OID associated with that code system from the vocabulary domain (at least in those cases where there is an HL7 defined OID). The difference between the concepts would need to be clearly explained, but it would be very practical for the people who implement the messages we design. Just because things are conceptually different, doesn't mean we can't link them (while making it clear that the actual OID is dependent on the realm binding to the vocabulary domain).
  • [Response from T Klein email 200511302329]: Tom, This would be very useful, but again is a tooling issue. If the tools were 'smart' enough, they could do a 'look aside' and if something was not realm-specializable and had a single code system referenced by a single value set, then that could indeed be surfaced, maybe 'defaulted' in somewheres. I live in a world where implementers are trying to take SQL queries on databases and use the data to populate instances; since they are using already 'bottled' message specs, they are mostly dealing with the stuff in Act.code and Act.value (and the specializations of Act). Therefore, there are usually multiple code systems involved, and many value sets include concepts from multiple code systems. We supply these guys with the 'boilerplate' of the stuff that is universal so that they don't even have to think about it. I dunno, there just seem to be so many pressing issues...right now I am most consumed with the OID gremlins… 200512011118]: This may have been overlooked in another thread ("OIDs for vocab domains")... Ted said: "Volunteers to improve the documentation are welcome (and solicited)." While I can't do any coordination of this at the moment, I would be happy to review what others
• 21 [Question from I Eiron email 200512021923]:

**  In the CDA sample document there's a  	healthCareFacility.code from a coding system oid "2.16.840.1.113883.5.10588". I could not find it in  	the HL7 OID repository. Does anyone know what it is and where it is defined? 	 	<healthCareFacility classCode="DSDLOC"> 	 	

• • [Response from R Hamm email 200512051132]: This may not help much, but that OID and thus codeSystem do not appear in the HL7 Vocabulary tables.
  • [Response from I Eiron email 200512061349]: Russ, My current understanding is that this oid is the oid of practice_setting_cd from CDA R1. Where can I locate this information? Is there and XML definition of these terminologies somewhere?
• 21.01 [Question from T Klein email 200512030659]:

**  Harold, 	I never was in the ballot pool for CDA so I never looked at the OIDs that were in it. I never issued  	OIDs in this kind of number range, and in any case, all of the branch '5' OIDs were setup by Woody  	and I think yourself. Any idea what is going on here, and how we can fix it? 	Thanks. 	

• • [Response from R Dolin email 200512040735]: Hi Ted, Three things: [1] Look at Table 148: CDA R1 to CDA R2 Vocabulary Correspondence and you'll see the OIDs we used for CDA R1 and the corresponding OIDs for CDA R2. [2] There are a bunch of OIDs used in CDA R1 that seem to have disappeared. I don't remember where I got them and I don't know why there is no history of them anywhere: ServiceConfidentiality (2.16.840.1.113883.5.10228) ServiceRelationship (2.16.840.1.113883.5.10317) PracticeSetting (2.16.840.1.113883.5.10588) ServiceActorSignature (2.16.840.1.113883.5.10282) PersonNamePurpose (2.16.840.1.113883.5.200) ServiceActor (2.16.840.1.113883.5.10246) ServiceActorFunction (2.16.840.1.113883.5.10267) ServiceTargetType (2.16.840.1.113883.5.10285) MaterialResponsibility (2.16.840.1.113883.5.10416) [3] The sample document contains an error, and the OID should be updated, per Table 148 (to 2.16.840.1.113883.5.111). I'll include this in the CDA R2 errata when we issue it.
• 21.02 [Question from I Eiron email 200512061106]:

**  A continuous question: 	I understand from the CDA R2 example document and from our latest correspondence that the  	appropriate vocab domain (am I using the right term?) for healthCareFacility.code is  	ServiceDeliveryLocationRoleType.  	However, 	 	- The only place in the CDA R2 specs (HL7 Clinical Document Architecture, Release 2.0) where this  	vocab domain is mentioned in the CDA R1 to CDA R2 Correspondence section. This recommendation 	 is not outlined in the section discussing the EncompassingEncounter. - Moreover, the  	healthCareFacility.code in the xml schema is simply a CE type. There is no reference to RoleCode or  	OID 2.16.840.1.113883.5.111, or to ServiceDeliveryLocationRoleType. 	 	My point is, that being a simple CDA user and implementer, the fact that HL7 have actually made a  	recommendation with regard to healthCareFacility.code which is that the values should be drawn  	from the sub-types of ServiceDeliveryLocationRoleType if possible, is very much hidden. One  	requires a really good eye in order to detect this connection. With CDA R1 the constraint on  	practice_setting_cd was much more explicit since that table of values was part of the  	documentation and part of the  	schema. 	 	- Why not explicitly say this is a CWE code and the appropriate vocab domain is such and such? 	- Why not create a vocab xml file defining RoleCode and ServiceDeliveryLocationRoleType and  	constrain healthCareFacility.code is ServiceDeliveryLocationRoleType. However, to these values? 	

• • [Response from K Boone email 200512061148]: Iris, The information you are looking for is in the Hierarchical description. It appears in the Domain column in line 223 of POCD_HD000040.xls. That's the column you would use to determine vocabulary domain for any element in the CDA. Furthermore, the CS column indicates whether this is a CNE or CWE domain. It took me a while to figure this out, and I still don't like HDs and HMDs, but I've learned to live with them. It does make it difficult to validate an instance, because you've got to deal with large lists of vocabulary to really do the validation. That's why I'm using schematron to validate implementations as well as schema, because I can use a few XSLT tricks to verify that a particular element (e.g., healthCareFacility/code) uses the appropriate coding system and values. It gets a lot harder when the particular vocabulary domain is too broad (e.g., SNOMED CT), because you may actually want to restrict the code value to a domain subset, and right now, that's pretty difficult, especially when the vocabulary domain subset is not easily described. For example, relatedEntity/code in CRS is limited as indicated below: The value of relatedEntity/code should be present and indicate the type of healthcare provider. If present, the values shall be drawn from SNOMED CT, using concepts that descend from the healthcare professional subtype hierarchy (SNOMED CT Concept ID: 223366009). The problem is that SNOMED CT is the codeSystem, but the domain is a subset of SNOMED CT, and there's no easy way to represent that in an HD for vocabularies that are not controlled by HL7.
  • [Response from I Eiron email 200512061213]: Keith, Thanks. That was very helpful. I still think the best would be if this could be pointed out more clearly in the specs and in the XML schema.
• 21.02 [Question from I Eiron email 200512061106]:

**  A continuous question: 	I understand from the CDA R2 example document and from our latest correspondence that the  	appropriate vocab domain (am I using the right term?) for healthCareFacility.code is  	ServiceDeliveryLocationRoleType.  	However, 	 	- The only place in the CDA R2 specs (HL7 Clinical Document Architecture, Release 2.0) where this  	vocab domain is mentioned in the CDA R1 to CDA R2 Correspondence section. This recommendation 	 is not outlined in the section discussing the EncompassingEncounter. - Moreover, the  	healthCareFacility.code in the xml schema is simply a CE type. There is no reference to RoleCode or  	OID 2.16.840.1.113883.5.111, or to ServiceDeliveryLocationRoleType. 	 	My point is, that being a simple CDA user and implementer, the fact that HL7 have actually made a  	recommendation with regard to healthCareFacility.code which is that the values should be drawn  	from the sub-types of ServiceDeliveryLocationRoleType if possible, is very much hidden. One  	requires a really good eye in order to detect this connection. With CDA R1 the constraint on  	practice_setting_cd was much more explicit since that table of values was part of the  	documentation and part of the  	schema. 	 	- Why not explicitly say this is a CWE code and the appropriate vocab domain is such and such? 	- Why not create a vocab xml file defining RoleCode and ServiceDeliveryLocationRoleType and  	constrain healthCareFacility.code is ServiceDeliveryLocationRoleType. However, to these values? 	

• • [Response from R Dolin email 200512062253]: Hi Iris, When it comes time to start thinking about CDA R3 (and in the interim, as we produce implementation guides), I agree that we should take another look at this, and make it as easy as possible to find the OIDs that you need to include in the instances. I've added this to our open issue log. At the very least, we can include the OIDs in the narrative portion of CDA in the future.
• 22 [Comment from L McKenzie email 200512192258]:

**  Here's a few more [questions], more relating to  	the "how do we use" rather than the administrative questions earlier: 	

• • [Response from J Larson email 200512200844]: Thanks, Lloyd. I will add these to the database.
• 22.01 [Question from L McKenzie email 200512192258]:

**  How does an application capture an identifier in a  	use case where a hospital asks to see "proof of identification" and gets shown a drivers license,  	passport, whatever from some state/province/country and there's a need to capture that in the  	application. 	It's unlikely that the application will have an exhaustive list of the potential OIDs.  In v2 they just  	would have captured the id, selected the id type, typed in the scoping facility as the  	state/country/whatever and would have been done.  This wouldn't be sufficient for guaranteed  	matching, but is good for record keeping, and would at least do possible matching. 	

• • [Response from ]:
• 22.02 [Question from L McKenzie email 200512192258]:

**  What happens if you are presented with a real- 	world identifier (say on a piece of paper) but have no clue what the OID root for it is.  You need to  	capture it in your system for record-keeping sake, though you won't be able to use it for exact  	matches? 	Suggest the answer is that II.root should be non-mandatory, with a rule that the equality relationship 	 of two identifiers only returns true if both roots are non-null.  If one or more of the roots are null  	and the extensions match, then the answer to "equal" is unknown. 	

• • [Response from ]: 22.03 [Question from L McKenzie email 200512192258]: What is good/expected practice in terms of populating or not populating "Assigning authority name" in an II?
  • [Response from ]:
• 23 [Comment from L Coller email 200512201130]:

**  Here are a couple of more things to consider that I  	hear from people trying to deal with OIDs who are outside of the HL7 conversations that we all see: 	

• • [Response from T Klein email 200512201151]: Lotsa questions and confusions for sure.
• 23.01 [Question from L Coller email 200512201130]:

**  Is OID purely an HL7 concept? 	I've had people argue that if something didn't come in via an HL7 message, they should use an OID. 	

• • [Response from T Klein email 200512201151]: OIDs are used in lots of places, not just HL7. We at HL7 need to deal with namespaces and unique identifiers. Most folks in databases and applications like to use GUIDs since these are easy, and are unique. However, in HL7 we deal with interoperating systems, which means you want the parties that are communicating to be able to know something about a namespace or an identifier that is being used, ie be able to look up metadata. Once you say you need to have some kind of universally accessible registry of unique identifiers, GUIDs lose most of their advantages.
• 23.02 [Question from L Coller email 200512201130]:

**  SSN vs. something that happens to be an SSN for  	people that have them.  In other words, Institution X uses as their primary identifier for people their  	SSN.  Not everyone has one, and at times they get multiple people who claim to have the same SSN.  	 For these cases they assign numbers that sort of look like SSNs but our outside of the range of  	numbers assigned by the SSA.  What should the OID be? 	For this case I believe that the OID should not be the SSA OID (I suppose they could use  the SSA  	OID for those that really are SSNs and their own OID for the others, but that would introduce the  	problem of identifying the two at some point. 	

• • [Response from T Klein email 200512201151]: You case (2) is interesting. I would argue that the namespace that is being used is absolutely NOT being managed by the US SSA, but my the Provider in question. It is incidental that they happen to use the same values for identifiers as those used in another namespace for most of their identifiers; this doesn't matter and is a red herring in the argument. So - you are right - the namespace does NOT use the SSN OID.