BALLOT TITLE: HL7 Data types, abstract spec
SUBMITTED BY: Liora Alschuler, liora@the-word-electric.com, 802/785-2623
SUBMISSION DATE: September 1, 2000
SUBMITTED BY IDENTIFIER: 
OVERALL BALLOT VOTE: 
___	AFFIRMATIVE 
__X_	NEGATIVE 
BLOCK VOTE by:  n/a

Overall comments: Great job on a complex and monumental task. It is difficult to vote “no” but am confident that will be able to reverse this during reconciliation. It does need a thorough copy edit. 

ID #	Section	Vote	Type	Existing Wording	Proposed Wording	Comments	Disposition	Identifier	
1	2	3	4	5	6	7	8	9	
1.		title	N	Mj	Version 3 Data Types	RIM Data Types	Work on this spec started with Version 3 in mind, but these data types are now part of the RIM which has a broader scope than just Version 3. They are used by the CDA which is a new, RIM-based specification and which is not part of Version 3. These data types should be used by all future HL7 specifications, assuming these too are RIM-based, so these data types should be called RIM Data Types. 	This question has been discussed and resolved by the HL7 Board of Directors. The title of ballot material is subject to board determination and we are advised to use this title.		
2.		format		S	small font	do not use; integrate normative material into spec, non-normative to appendix	the small font is hard to read and the distinction between explanatory material that is in 8 pt and in 10pt type is not clear. It used to be normative/non-normative, but this was removed. Suggest that if small font intended as non-normative, that it be collected in non-normatve appendix. Prose required to explain the specification should be normative and in same font as other prose. Non-normative discussion and notes would be more digestible in a section of their own. Furthermore, the notes on design decisions sound polemical, which is not necessary in the expositon of a normative spec. Suggest removing these to an appendix and if meaning of spec is impaired, restore as part of the normative prose. For essential notes, suggest use of standard footnotes.	This has been resolved as follows: no distinctions in small and large font are being made any more. Such material that is more of a rationale than normative content has gone into footnotes. We have not created separate Appendix because that would have taken every note out of its context and would have required many more paragraphs of writing just to reestablish that context in the appendix. The footnote solution should get that additional (and potentially confusing) material out of the face of the reader who may ignore footnotes (as many do). Our hypothesis is that the reader who habitually follows footnotes is the reader who is less likely confused by such notes.		
3.		format			sans serif boxed text	do not use; integrate normative material into spec, non-normative to appendix	not always sure of role of these passages. They are labeled variously: Important Disclaimer, Note, ITS Note, etc. Not sure why ITS notes should be included in an abstract spec when we have one (or possibly more) ITS specs. Furthermore, 	These boxes are emphasized text. The style has been inherited from version 2.x standards.
As for the ITS Notes, these notes are not specific to any particular ITS but are an advice to ITS designers in general. That is why the ITS notes do belong into this document.		
4.		1.6	N	Mi	division into text, quantities, concepts, things	delete or place in non-normative appendix	These distinctions are fuzzy and somewhat arbitrary: why is encoded data “text” while person name, which is a string, a “thing”? (or am I mistaking “encoded” here for “coded”? do you mean “encoding” as a data format or as a code? In either case, I don’t think this is material to the specification.) In general, much of section 1 and 2 strikes me as good material for a white paper or article on data types, or an informative appendix or implementation guide, but not useful with the spec itself.	These three major headings and the text explaining them have been deleted.		
5.		1.6 table 1		S	…bear meaning…	….bear meaning which is tractable or processible by a computer… 	I know what you mean, but it is good to remember that for humans, prose and pictures do bear meaning.	yes		
6.		1.6 table 1		S	HL7 version 3 identifiers	HL7 RIM identifiers	same as for title of this spec; I did not do a search on “version 3” w/in the spec, but suspect there are other references which should be generalized to apply to all HL7 RIM-based specs	same answer as for title		
7.		1.6 table 1		Q	main use of such declared data is to be printed on mailing labels		does this rule out or deprecate use of postal code for epidemiological analysis? are there other, better references for location? (this is a data quality issue, not a data type issue, I’m just curious why this is stated in this manner here.)	Thanks for asking. Yes, this is precisely the issue. It has now been further clarified. For the purpose of data quality we do not advise to communicate this epidemiological grouping data in the AD. While we understand that the address may be a source of such data, the AD data type is not designed to maintain such data. Thus, county, area of living, population, etc. are concepts modeled in higher level structures (RIM class Entity, and Place,) and are not appropriately handled in one data type.		
8.		2		S	A formal definition of data types is used…	A formal defintion of data types is used.	Just think that the full para belabors the obvious	True, but this statement is targeted at people who may be scared away by the formal stuff. To them we tell that all of the obscure grey boxes are described in plain English.		
9.		2		S	The data type definition language employed here is a conclusion of experiments and experience with various alternatives….	move to appendix or white paper	An example of the kind of material that would be excellent in an HL7 white paper on data types. To the extent possible, we should use the spec document to state the result of the design process, not to reiterate the process itself. Also, some of this is stated elsewhere in this section.	Yes. This is one of the things that went into a footnote.		
10.		2.1	 	S	… and extends (specializes)…

The extends-clause has the usual meaning of a specialization relationship		extension and intension are very difficult concepts for this relatively un-schooled reader, but specialization is something that I feel I understand. If these are synonyms, can this be stated where extension is first introduced? overall, a glossary would be much appreciated. 	This particular sentence only speaks about extension (as extending another type) not about extension vs. intension as you thought it would. So, this issue is actually less complex. A footnote has been added here to make that clear (BTW: this is an example where a text in an appendix would not help and where further elaboration in the normative text would be superfluous, but where a footnote is just right.)		
11.		2.3		S	type conversions		it would be useful to have use cases or examples to distinguish between implicit and explicit conversions	use case is mentioned in footnote, however, more examples for this are not given sine the overall directive was to reduce the size and cut back on non-essential (?) belaboration. I am happy to expand, but will it be appreciated?		
12.		2.4		Q	The literal for the Point in Time (TS) type is the well-known HL7 v2.x TS format (e.g., “200004190035” for April 19, 2000, 12:35 am		Is this the same as an ISO timestamp? If so, is this example valid?	This is a controversial issue. The TS as given in this example is a valid ISO 8601 timestamp. The controversial issue is that ISO 8601 is full of optionality and thus not every ISO 8601 timestamp is an HL7 TS. Particularly the W3C schema group has (very unfortunately) decided to go the other way: allow only the decorated option of ISO 8601. We are kind of stuck with this problem. However, the solution is that the literal form is only a default literal form, used within the V3DT spec itself and available (but not required) for use by any given ITS. Thus, the XML ITS may choose to side with the W3C decision and still be complient to the V3DT spec, because the literal forms defined  here are not exclusive.		
13.		2.4.2		S	The BNF variant used here is similar to the Yacc parser and Lex lexical analyzer generator languages but is simplified and…		Other than the comparison to Lex and Yacc, which may or may not be necessary, the balance of this paragraph seems integral to the definition of a literal form and so should be integrated into the regular text, not moved elsewhere.	Went into footnote. The other material you refer to is in fact a repetition from what’s found in the main text.		
14.		3.2.2 table 3		S	OTH		The relationship between OTH and CWE takes some time to grasp and is scattered throughout the abstract spec. I suggest that relative usage guidelines and examples be collected and inserted if not in the spec itself, then in an informative appendix. Presented independently, as here, it is difficult to uinderstand. 	This is now also moved into footnote. The problem is that a discussion of this would require review of parts of the MDF and would probably exceed the scope of this standard. I agree that this issue can be discussed somewhere more completely – but then, who would read it?		
15.		3.2.2 table 3		Q	not present		why is this row in italics?	Because “NP os a presentation layer concept only, not an application layer concept!” So, NP is a specific exception, the italics should underscore that, make people think …		
16.		4	N	Mj	Text
…Written text, spoken text (audio) as well as graphics or images belong in this category.	“Multi-media” or just “Media” in place of “Text” or “Human-readable data” or whatever you really mean. 	It is illogical to include audio (which may or may not be spoken text) and graphics or images (which may or may not include text) under the category “Text”. I’m sure you have a good reason for not doing so, because this has been challenged before, but whatever your point is, it is still not apparent to the reader who will read this and just think that it is illogical and strange. “Media” may not cover what you really mean here, but then, neither does “text”.	This issue has been dropped. I concede even though I disagree :-). But it is not material to this standard. The key to my understanding lies in a more general understanding of “text”. Turns out that defining “text” solid is extremely difficult. Multimedia, image, audio is indeed text, but again, it is no longer in the standard and therefore a moot discussion.		
17.		4		S, Q	Figure 3, caption	Move bulk of caption to normal paragraph. 	caption should label the figure. It is unclear whether the text in the caption is normative, explanatory, or what relation is has to the balance of the prose. I	Done. 
But since you seem to be interested in editorial issues: there are two established ways of using captions – and it’s rather unfortunate that they are both called “caption” in Word. Table captions are usually a short heading phrase. But text written under illustrations is often used to explain the illustration. There are people who take most information out of illustrated documents by reading the text featured with the illustrations. It’s simply a second channel of communication that I use here. 		
18.		4.2.1.1		S		add:
application/x-hl7-cda-level-one+xml	this is from the CDA ballot, section 2.5.3	I added “application/x-cda-level-1” and that may be a mistake. I suggest you have this application type registered with IANA to get rid of the x- prefix, so we can get the final version right before release of document.		
19.		4.2.1.1	N	Mi	text/sgml, text/html
text/xml and application/pdf	change text/sgml and text/xml and text/rtf to recommended  or change /pdf to and /html to other 	PDF is not an “open specification”, it is a proprietary data format, as is rtf. Readers are available for both, while composition tools require a paid license. 
For safety of sharing documents, HTML, while an open specification, carries risk of imcompatibility because it is very loosely interpreted (there is no constraint here to use only HTML conformant with W3C Recs.) Non-specific XML and SGML, while useless from a semantic interoperability standpoint, are at least as useful for “sharing documents” as pdf, rtf, and HTML. We can discuss this in greater depth, but on the face of it, it is not reasonable to deprecate generic XML while recommending pdf, as long as no claim is made for shared semantics.	Yes. PDF is an open specification. An open specification is a specification that is publicly available for anyone to build devices that comply with that specification. The PDF spec can be downloaded for free and implemented and used royalty free. PDF readers are available not only from Adobe, but also from third party, including open source software. PDF generators are also available from third parties (e.g., ghostscript has PDF output, PDFTeX, …)

HTML is a neat form to mark up simple text documents that can be rendered virtually everywhere (from lynx on TTYs to your favorite browser.) It is the practical choice (even a PRA level-one XSL will likely use HTML as its target before rendering on a screen. As long as this is so, we can safely recommend HTML. However, I agree that we might want to note that proprietary or advanced featured of HTML should not be used.

Generic XML per se is deprecated because generic XML is not interoperable without further negotiation. Since the beginning SGML has made it very clear that it specifies only structure and no content processing, no rendering, etc. Since this is so, one cannot do any reasonable processing or rendering given only a blob of application/xml.		
20.		4.2.1.1		Q			should dicom be represented here?	Yes, but how? There is no DICOM format registered with IANA and so we have nothing yet to mention. However, this issue might well be resolved in HL7 working groups in the near future. I would like to wait until we know the right solution before mentioning something that doesn’t exist yet. 		
21.		4.2.1.2		Q	Open Issue: There are at least 10 different MIME designators for Japanese charsets…		does not seem appropriate to have an open issue in the body of a specification. Also, this description of the issue is restricted to Japanese. What about other language groups that use 16 bit encoding? Would we need to reballot to include a new 16 bit character set?	Yes. No. (1) this issue is now removed, and the Japanese have what they need. (2) Other languages – all languages, including Japanese are well served by ISO 10646 (Unicode) / UTF-8 the default charset of XML (and likely by default the standard for HL7 XML). Some Japanese people, however, feel that ISO 10646 is not sufficient to represent fine nuances of characters in Japanese texts that also contain Chinese and Korean writing. In any way, no reballot is ever required since this table is not exclusive.		
22.		5.1.1.9		Q	This is the text or phrase used as the basis for the coding.  The original text exists in a scenario where an originator of the information does not assign a code, but where the code is assigned later by a coder (post-coding.)…		question whether this captures all the possible permutation of pre- and post-coding. For example, how does this apply when codes are automatically generated on basis of human selection of text string? when codes are entered after text, by a second person, and original author reviews/does not review the coding? 	It is meant to cover all cases, however, it does not specify whether the coding has been arrived at as pre or post coding, etc.

The issue of review you mention is solved differently. Revision management and digital signatures are the keywords that hint into the right direction.		
23.		5.2.1, 5.3.1		S	28 .9 [quoted material]	reduce to what required for clarity of our spec	what is the significance of the pink color? If every piece of this quote is not directly germane, it should go into an appendix. If germane, should just  be quoted.	The light red is used for all quotations from external standards. This is a genuine quote. I always appreciate a little color on a gray page (especially when the text is so dry), don’t you?		
24.		5.2.1	N	Mi	The HL7 assigned OIDs must be used for these organizations, regardless whether these organizations have other OIDs assigned from other sources.	express preference for the HL7 OID, but don’t require use of HL7-assigned OIDs	this strikes me a unenforceable, unless the Federal Government backs us up in the HIPAA regs. Would it be workable togive  option for non-HL7 OID in addition?	Yes, but may be a misunderstanding. This has been (hopefully) clarified in the current ballot 2 draft.		
25.		5.3.2.2		Q	answering service		Does this include voicemail? if so, is there a mechanism to declare which of several answering services should be used? often, voicemail is available on several telecom addresses, so how would one designate which to use to leave a message?	Yes. No. The tendency is to rather keep the use code simple. But since use codes can be combined, you can well specify an answer machine in an office, vs. an answer machine in a home, vs. an emergency answer machine (?).		
26.		5.4.1.1		S	ZIP	PCD or somethings similar	the concept name and descripion are not US-centric, but the code is; suggest bringing code into line w/its definition.	The code literal should not be looked at. Since the author himself is not am US-American and it doesn’t hurt him, and since the international vote did not see this as an issue, I think that the code literal can stay as is (I believe that the CDA refers to ZIP already.) The text has been corrected, but the code literal is rather unchangeable now.		
27.		5.4.2.2, 5.5.2.1		S	example		in so far as possible, suggest using examples that match our balloted ITS. Also, not sure that formatting should be described in an abstract spec, but rather in the ITS. Since there are provisions for  white space handling in XML and in our XML ITS, how do these match up? if identical, why are both needed? if they differ, what should be used?	XML examples: yes, there is great similarity, however, the XML style is so terse that it would obscure the examples (using “CS” instead of “codeSystem”, for instance.) This particular example, however, should be perfectly aligned with the ITS.
Formatted: This is a misunderstanding. The formatting is not an ITS issue, it happens to be an issue of semantics of the PN and AD data types. Remember that PN and AD describe first what people expect to see, and then may be what the meaning of that stuff is. So, the semantics of many part types and qualifiers (e.g., suffix, prefix, delimiter, inverted, weak, etc.) can only be defined as operationalized in the formatting task. This, however, doesn’t preempt any style decisions and certainly is completely independent of the ITS. The ITS is machine to machine communication whereas this formatting is an abstract to-the-user-communication.		

Legend:
1.	Internal identifier (internal to the organization balloting)
2.	section, e.g., 3.1.2.
3.	(A) Affirmative or (N) Negative
4.	(Mj) Major, (Mi) Minor, (S) Suggest, (Q) Query, (T) Typo
5.	Cut/paste from ballot.
6.	Use revision marks to denote desired changes.
7.	Reason for the change.
8.	Disposition, (editors: e.g., Coordinate change with other TC, voted non-persuasive, etc.  This column can also be used by editors to track that approved edits have been applied to the chapter.)
9.	Identifier of the ballot (this is needed at the line item level because all the ballot items will be combined into a single table.)