BALLOT TITLE: HL7 Version 3 Data Types
SUBMITTED BY: Fred Behlen; (773)702-7418; f-behlen@uchicago.edu
SUBMISSION DATE: Sept 1, 2000
SUBMITTED BY IDENTIFIER: (assigned by HQ, used below to track individual line items)
OVERALL BALLOT VOTE: 
___	AFFIRMATIVE 
_X__	NEGATIVE 

Section	Vote	Type	Existing Wording	Proposed Wording	Comments	
1	2	3	4	5	6	
5.2	N	SUGGEST	(Overall)	Abridge and simplify	OIDs are a powerful new tool being introduced into HL7 in Version 3.  The concepts will be new to many HL7 implementers, and a concise statement of their principles is needed.
1.	The key feature of an OID is its global uniqueness.  They may be algorithmically derived from identifiers local to a system, but one must never attempt to parse content out of an OID.
2.	OIDs comprised strings of dots and positive integers expressed in ASCII characters.  Implementations will use these as string keys.  There shall be no leading or embedded spaces in the OID, and  the integers shall not have leading zeroes.
3.	An OID comprises a prefix, or “root”, which is obtained from an assigning authority, and a suffix which is created by the implementer.  The implementer must ensure that each installed system generates distinct OIDs, such that it is never possible that two different systems can generate the same OID for a different thing.
4.	OIDs are analogous to “namespace and value” representations of identifiers, but one must never attempt to extract these separate identifiers from an OID.
Actually, we have had subsequent discussions about this issue in general and this had influenced the revision of that section. However, in the last days of ballot 2 preparation, your own contributions to the wording had accidentially been dropped. Will need to fix in the next ballot.	
5.2.1.1	N	MAJOR		The literal form of the OID shall be a string not exceeding 64 characters in length.	No limit is specified for the length of the OID.  In practice, these identifiers will be used as unique keys in databases.  Limiting the length to 64 characters preserves computer, with no loss of utility.  OIDs have an organizational prefix of less than 20 characters, leaving more than 44 characters for unique identification within the organization. DICOM implementations bear this restriction, and implementers have had no trouble staying within the 64-character limit.  Knowing that the length of the OID will not exceed 64 characters enables them to be used in file specifications and query strings that have limits to their length.

The MAJOR objection is that OIDs longer than 64 characters cannot be imported into DICOM systems.  Thus, leaving the length unrestricted would provide no benefit in HL7 implementations, and would greatly complicate the harmonization of HL7 and DICOM standards.
See resolution on separate cover (“Substantive comments”) This statement of the limitation to 64 characters has been added.	
5.2.1.2	N	MINOR	Entire section	Delete the entire section 5.2.1.2:
“Structured Form: Sequence of Integers versus Value and Namespace”	This section is more likely to confuse implementers and result in incorrect implementations, and should be deleted.  It includes invitations to structuring OIDs so that their components may be parsed out, which goes against the principle of an OID. 
See resolution on separate cover (“Substantive comments”) This section is quite important for the use of OIDs for such things as DLNs so it can’t simply be dropped. However, the point has been made very clear that one is not supposed to parse an OID that is not somehow guaranteed to have a parseable structure.