View source for 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> 	<code code='ADMDX' 	codeSystem='2.16.840.1.113883.5.4' 	codeSystemName='ActCode' 	displayName='admitting diagnosis'/> 	</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"> 	<code code="GIM" codeSystem="2.16.840.1.113883.5.10588"  	displayName="General internal medicine clinic"/> 	
** [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 <b>R1</b>.  	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.