BALLOT TITLE:	HL7 Version 3 Abstract Data Type Specification  (Committee Ballot)
			HL7 Version 3 Data Type XML ITS (Committee Ballot)
SUBMITTED BY: Vassil Peytchev, vassil@epicsystems.com
SUBMISSION DATE: September 1, 2000
OVERALL BALLOT VOTE: Affirmative

HL7 Version 3 Abstract Data Type Specification Notes
No.	Section/Page	Type	Existing Wording	Proposed Wording	Comments	Response	
1	2.3/14	Wording	Three types of type conversions are defined:	Three formes of type conversions are defined:		O.K.	
2	2.4/16	Typo	For the XML ITS we expect that some of the literals defined here are used.	For the XML ITS we expect that some of the literals defined here will be used.		O.K.	
3	2.5.2/19	Typo	Thus, while any data value can be annotated outside the data type specification, and ITS may not provide for a way to annotate the value of a data value property.	Thus, while any data value can be annotated outside the data type specification, an ITS may not provide for a way to annotate the value of a data value property.		O.K.	
4	3.2.1.2/21	Typo	Thus, every data value is either a proper value or it is it null	Thus, every data value is either a proper value or it is null		O.K.	
5	4.2.1.1/27	Enh.			Table 4: Add mp3 as an audio type	done, it is actually audio/mpeg as per IANA.	
6	4.2.1.1/28	Change			Table 4: Downgrade image/gif from “recommended” to “other”, due to the UNISYS patent. Mention risk of violating the patent.	O.K.	
7	4.2.1.2/28	Change			Table 5: change description of ISO-8859-5 to include Russian, or change the description to simply say “Cyrillic character set for the Slavic languages in Eastern and Southeastern Europe.”	added Russian, how could it be forgotten?	
8	5.1.1.5/35	Query			How would NDC codes for medications be handled with respect to equality of content descriptors? Specifics for NDC codes: the same code can be represented as either an 11-digit, or a 10-digit number with dashes. The extra digit is a zero, which happens to be the leading zero of any of the three sections of the NDC code (specified by dashes). Thus, the dashes are meaningful, as they determine where the extra zero is going to be inserted/removed from, e.g. xxxx-xxxx-xx is converted to 0xxxx-xxxx-xx, while xxxxx-xxx-xx is converted to xxxxx-0xxx-xx. Many systems are also storing the 11-digit number without dashes. How can we express fact that 01234567890 is equivalent to 1234-5678-90?	This is discussed in the section 2.4.3. Resolution in parallel with the similar issue on SSNs (S. 2.5.2.2)	
9	5.1.1.9/37	Query	A concept descriptor can be converted into an ED value representing only the original text of the CD value.
		Is this a demotion? If not, is this a different form of type conversion?	yes, it is.	
10	5.1.110/37	Typo	5.1.1.10 producer : II
5.1.1.12 modifier : LIST CR
	5.1.1.10 modifier : LIST CR
	There also seem to be old changes tracked in this document, or hidden text, which need to be cleared.	yes, was hidden and has now been removed.	
11	5.2.2.3/43	Typo	However, the root does not have to be an organizational OID, it can also be and OID specifically registered for an identifier scheme.	However, the root does not have to be an organizational OID, it can also be an OID specifically registered for an identifier scheme.		O.K.	
12	5.2.2.5/44	Suggestion	Open Issue: This property needs a vocabulary domain, which is probably very hard to define.  If this property does not have a satisfactory reasonable value domain by summer of 2001, it will be deleted.		Can this be solved by providing a CWE table mapping of a current set of ID types (SSN, US Healthcare ID) to the OID of their assigning authority? It will allow healthcare organizations to add their internal ID types to OIDs, which they may control. For inter-organizational use, the assigning authority OID will be the organization’s but the ID type can be HIS ID, Enterprise ID, Radiology ID…	Mapping the traditional Identifier type codes to OIDs is exactly the way to do it. Since we received no proposal for Id types and you were the only person responding, basically saying what the bias of the data type spec was, the II.type_cd has now been removed entirely and such type code is locally inferred from the OID namespace.	
13	5.3.1.1/45	Query	URL : /[a-z0-9+.-]+/ “:” ST		Shouldn’t the + or – characters be escaped in the character class?	no, they don’t have to. In fact, the grep/awk/regexp character classes do not have any escaping. A + is not ambiguous in the first place and the – is de-amibuized by being the last item in the list.	
14	5.3.1.2/45	Change			Table 8: upgrade the “file” scheme status to “other,” since SMB shares, NFS mounted partitions, and the AFS global file names allow remote systems to access files as if they are local.	O.K.	
15	5.4.1/48	Change	Typical parts that exist in about every address are street, house number, or post box, ZIP code, city, country but other roles may be defined regionally, nationally, or on an enterprise level (e.g. in military addresses).  	Typical parts that exist in about every address are street, house number, or post box, postal code, city, country but other roles may be defined regionally, nationally, or on an enterprise level (e.g. in military addresses).  	ZIP code is US-centric.	O.K. descriptive language changed, to “postal code,” but the code literal is still “ZIP”	
16	5.4.1.1	Change	The type of an address part indicates whether an address part is the ZIP code, city, country, post box, etc.	The type of an address part indicates whether an address part is the postal code, city, country, post box, etc.	ZIP code is US-centric.	see above.	
17	5.4.1.1/49	Wording	The number of a house or lot alongside the street.  Also known as "primary street number", but does not number the street but the house.	The number of a house or lot alongside the street.  Also known as "primary street number", but it numbers the house, and not the street .		O.K. (meant to change this in the draft but forgot. Applied change after ballot draft 2 release.)	
18	5.3.2.2/47
5.4.22/49	Suggestion			Adding TMP and BAD as use codes to TEL seems useful.	this is a problem since issues had been raised with the use code being not “clean”.  So would not want to expand this more than pragmatically needed.	
19	5.4.2.3/50	Typo	invariant(TEL x, y) x.nonNull.and(y.nonNull) {	invariant(AD x, y) x.nonNull.and(y.nonNull) {		thank you, good review (you are one of the three reviewers eligible for a “most thorough reviewer of the year” award – if such award existed!)	
20	5.4.2.4/50	Typo	1050 Wishard Blvd. RG 5th floor,
Indianapoli, IN 46240.
has the following two valid encodings	1050 Wishard Blvd. RG 5th floor,
Indianapolis, IN 46240.
has the following three valid encodings		O.K.	
21	5.5.1.1/51	Query			Is MID just another code for given name? In many cultures the middle name is not given – it is derived from the father’s given name.	I understand, and yet, the MID code had been removed entirely because of too much confusion on what it is. By and large it is a second given name. There may be cultural rules that prescribe how this name is given (e.g., after the father) and if such rules are important to track, we will make a qualifier for each distinct such rule. So far, however, it seems more like customs that some individuals might share but that are not really laws or anything anyone would ever communicate about. We’re generally open to extending the qualifiers though.	
22	5.5.1.1/51	Suggestion			In some cultures there are quite strict rules of forming the names, as noted in the family name type definition. In many cases the father’s given name is used to form the middle name in a three-part naming structure (Russian, Bulgarian). I suggest that the middle name type, together with a “father’s name” qualifier can be used to represent these cases.	A “father’s first name” qualifier might be useful. Given the many issues that we have to arbitrate now, can we hold off adding this until the overall framework is set?	
23	6.2.1.2/58	Typo	INT uint : digit {$.equals($1);}
         | number digit  	{ $.equals($1.timesTen().plus($2)); };	INT uint : digit {$.equals($1);}
         | uint digit 	{ $.equals($1.timesTen().plus($2)); };		thanks, good review!	
24	7.4.1.4/83	Typo	The center is defined of finite intervals and is then the arithmetic mean of the interval (low pus high divided by 2).	The center is defined of finite intervals and is then the arithmetic mean of the interval (low plus high divided by 2).		thanks, we don’t want any pus in here :-)	
25	7.4.1.7/83	Typo	Four different forms are defined	Five different forms are defined		O.K.	
26	7.4.1.7/85	Typo	IVLTS comparator
  | “<”  T { $.high.equals(T);
$.high.closed(false);
$.high.negativelyInfinite; }
  | “>”  T { $.low.equals(T);
$.low.closed(false);
$.low.positivelyInfinite; }
  | “<=” T { $.high.equals(T);
$.high.closed(true);
$.high.negativelyInfinite; }
  | “>=” T { $.low.equals(T);
$.low.closed(true);
$.low.positivelyInfinite; };
};
	IVLTS comparator
  : “<”  T { $.high.equals(T);
$.high.closed(false);
$.low.negativelyInfinite; }
  | “>”  T { $.low.equals(T);
$.low.closed(false);
$.high.positivelyInfinite; }
  | “<=” T { $.high.equals(T);
$.high.closed(true);
$.low.negativelyInfinite; }
  | “>=” T { $.low.equals(T);
$.low.closed(true);
$.high.positivelyInfinite; };
};
		thanks, another award-winning comment!	
27	7.4.1.7/85	Typo	3.5	3.5	Table 19, third row from the bottom	? we have reviewed this thoroughly, think we got it right this time. (Please double check) Thanks.	
28	7.4.3/87	Typo	However, note that May 12, 2000 9:30 PM to May 13, 2000 8 AM is “200005122130-230800”, and not “200005122130-0830”.	However, note that May 12, 2000 9:30 PM to May 13, 2000 8 AM is “200005122130-130800”, and not “200005122130-0830”.		O.K.	
29	8.3.1.3/96	Wording	Note that the Christian Orthodox Holidays are based on the Julian calendar.	Note that some Eastern Orthodox Christian Holidays are based on the Julian calendar.		Thanks. FMI: which ones would make the exception?	
30	8.3.1.3/97	Typo	Neither does it include religious holidays other than Christian (of the Gregorian (western) tradition), nor does it not contain national holidays on other countries	Neither does it include religious holidays other than Christian (of the Gregorian (western) tradition), nor does it contain national holidays on other countries		O.K.	

HL7 Version 3 Data Type XML ITS Notes
No.	Section/Page	Type	Existing Wording	Proposed Wording	Comments	
1	1.4/5	Typo	Wes Rishel (Gartner Group) was the priniciple author of previous drafts of the DTD and Paul V. Biron (Kaiser Permanente) is has taken over maintainence of the DTD and is the principle author of this document.	Wes Rishel (Gartner Group) was the principle author of previous drafts of the DTD and Paul V. Biron (Kaiser Permanente) has taken over maintenance of the DTD and is the principle author of this document.		
2	2.1.1/6	Typo	the Unicode characters metnioned above could be used could be used if they were "spelled" with their XML character entities,	the Unicode characters mentioned above could be used if they were "spelled" with their XML character entities,		
3	2.1.1/8	Wording	Version 3 Data Types defines two forms of type conversion: demotion and promotion.  The XML ITS support for type conversion are detailed in the following sections.		The Abstract Data Type specification defines Literal Representation as a type conversion as well. Need to mention (and explain the use of) the Literal Representation in this document.	
4	2.3.2/9	Typo	In general, the XML ITS does not support type demotions declared in this manner; exceptions to this general rule will be noted for any data types for which types form of demotion is supported	In general, the XML ITS does not support type promotions declared in this manner; exceptions to this general rule will be noted for any data types for which types form of promotion is supported	Wording needs to be fixed as well.	
5	2.3.2/9	Typo	In general, the XML ITS does not support type demotions declared in this manner; exceptions to this general rule will be noted for any data types for which types form of demotion is supported	In general, the XML ITS does not support type promotions declared in this manner; exceptions to this general rule will be noted for any data types for which types form of promotion is supported	Wording needs to be fixed as well.	
6	5.1.1/21	Typo			Missing the “Code” property, represented by the “V” attribute. All other subsections need to be incremented by one to match the Abstract data type specification.	
7	5.2.1.1/28	Typo	OID: OID "." DIGIT |
     DIGIT
DIGIT: "0" | "1" | "2" |
       "3" | "4" |
       "5" | "6" | "7" | 
       "8" | "9"
	OID: OID "." INT |
     INT
INT: INT DIGIT |
     DIGIT
DIGIT: "0" | "1" | "2" |
       "3" | "4" |
       "5" | "6" | "7" | 
       "8" | "9"
		
8	5.5.2/34	Query			Is “MID” a valid type code? Please see note 21 in the Abstract Data types table.	
9	7.4.1.2/44	Typo	low is represented as part of the literal form in the V attribute, whose XML attribute type is CDATA.	high is represented as part of the literal form in the V attribute, whose XML attribute type is CDATA.		
9	7.4.1.3/44	Typo	low is represented as part of the literal form in the V attribute, whose XML attribute type is CDATA.	width is represented as part of the literal form in the V attribute, whose XML attribute type is CDATA.		
9	7.4.1.4/44	Typo	low is represented as part of the literal form in the V attribute, whose XML attribute type is CDATA.	center is represented as part of the literal form in the V attribute, whose XML attribute type is CDATA.		
9	7.4.1.5/44	Typo	low is represented as part of the literal form in the V attribute, whose XML attribute type is CDATA.	lowClosed is represented as part of the literal form in the V attribute, whose XML attribute type is CDATA.		
9	7.4.1.6/44	Typo	low is represented as part of the literal form in the V attribute, whose XML attribute type is CDATA.	highClosed is represented as part of the literal form in the V attribute, whose XML attribute type is CDATA.