Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.cplire.ru/rus/telemed/HL7/Catalog.pdf Дата изменения: Tue Dec 10 19:03:36 2002 Дата индексирования: Tue Oct 2 06:55:08 2012 Кодировка: Поисковые слова: вечный календарь

#%
Thoughts on a Publication Format for Version 3 Messaging
(includes notes from discussion 4/26/99 in Toronto) Introduction .............................................................................................................................................. Catalog of Version 3 Documents ............................................................................................................... Version 3 General Information .................................................................................................................. Reference Information Model ................................................................................................................... Version 3 Message Set .............................................................................................................................. HL7 Voca bulary Domains ........................................................................................................................ Implementable Technology Specification ......................................................................................... ......... 1 2 3 4 4 6 6

Introduction
This document contains some thoughts on how version 3 standards might be published. It envisions a suite of discrete documents as described below. It addresses: · · · · · · general description of document contents the macro structure of each document what parts, if any, are normative file formats for electronic publishing maintenance methodology (listed by section of the document) inter-document dependencies.

There should be no plans to publish documents using a commercial word processor format. The electronic publication formats proposed are PDF and XML. The purpose of the PDF format is self-evident; it is portabl y printable across the widest variety of hardware and operating systems. The purpose of having an XML format is to allow the structured information that is part of the standards to be universally available without the need for writing special programs to decode database contents. It is expected, however, that the entire contents of each standards document would be published in XML, including verbal sections that lack structure other than sections, tables, figures, and the other appurtenances of published documents. Eventually, XSL style sheets should allow that information to be printed and browsed on line in a richly formatted form. In the interim, we may rely on special soft ware to generate PDF and HTML versions of the documents for printing and browsing. The XML structure will be immediately useful for retrieving the structured content from the published document. It is expected that both the PDF and the XML versions will each contain a copious set of h yperlinked crossreferences. Whenever a RIM class or attribute is mentioned, its literary description will be available on a click, whenever a domain is mentioned, its definition will be available on a click, and whenever a datatype is mentioned, its definition will be available on a click. (Some of these will be cross-document references.) The overarching maintenance methodology is the HL7 repository; individual sections may be maintained differently according to the degree to which they contain information that is captured developed in structured form and the degree to which they are maintained as natural language documents. We propose the following principles be followed: · All of the documents' contents are contained in the repository. All documents are generated by a program or sequence of programs that retrieves information from the repository formats it and produces PDF and XML documents.

Thoughts on a Publication Format for V3 Messaging

1

April 27, 1999


#%
· Structured sections: some sections or subsections of the document are maintained through the tools that are being devel oped to drive the repository including Rational Rose, RoseTree, and the other HL7 repository tools. Lightly formatted subsections: some subsections of the structured sections contain natural language statements. The devel opment tools may allow some limited formatting of these subsections, but the formatting is limited by the capabilities of the HL7 repository tools. Formatted sections: some sections of the documents may consist entirely of natural language text. These may include introductions, bibliographies, examples, and other explanatory material that is not normative. These sections will be maintained in the repository and individual sections can be "checked out" for revisions by committee members, who will ultimately "check in" a revised section. They will receive the formatted section as an RTF file with styles. Upon checking in the RTF will be stripped of st yles that are not part of the HL7 repertoire of st yles. Certain other types of formatting, such as absolute font size selection and font colors may also be eliminated. Gunther has suggested that authors also be able to check information in and out in HTML format. This would have the advantage of saving authors from the temptation of editing their material much for style, because HTML itself does not support floating images and tight control over style. Gunther's recent work has demonstrated that extensive HL7 work can be documented adequantely while limiting the presentation format to HTML. He further notes that there are compatibility problems with RTF. Upon reflection, Wes comments that this idea has merit, but there may be some concerns. In particular, our previous view of this process included the idea that HL7 would use st yles to control various formatting issues. These styles can be conveyed in a conscribed RTF subset in a wa y that they render correctly in many different word processors; by imposing a filter on incoming RTF, we can hope to avoid the use of features that are specifi c to individual word processors or that pose compatibility problems when rendered in different printing environments.
:H QHHG D PHWKRG IRU GHDOLQJ ZLWK FURVVUHIHUHQFHV DQG LQGH[LQJ

·

·

Mead has commented that the proposal does not include a place for presenting the use case information. This non-normative material can be helpful in understanding message formats. Wes has mad a stab at placing this in the hierarchy of documents and sections; comments are solicited. What follows is a guess at what documents might be in the Version 3 document suite.

Catalog of Version 3 Documents
A listing of the current version of all documents that are required to have a complete set of the version 3 standard. Single document, not normative. Dependency: republished whenever any other document is published.

A.

General Information Description of the document and its contents; ordering information.
Maintenance method: formatted section.

B.

Catalog Actual listing of documents, versions, publication dates, prices.
Maintenance method: structured section.

Thoughts on a Publication Format for V3 Messaging

2

April 27, 1999


#%
Version 3 General Information
Information that does not vary from one message set to the next. (Single document, contains normative sections.) Dependency: republish whenever changes are required to support changes in standard message definitions. Maintain prior versions in the catalog as long as any currently valid message type is dependent on this version.

A.

Introduction Histor y, purpose, process, what are the other documents, how are they developed and how to read them.
Maintenance method: formatted section.

B.

Message Types Non-ITS-specific description of the elements of a message type.
Maintenance method: formatted section. 1. Message Element Metatypes Description of the metatypes of a message. Examples. 2. Data Types Description of the accepted data element types . It includes those aspects of message security, integrity, and privacy that are appropriately defined at the data type level.

C.

Communications Models One or more object models that define the entities involved in communications and communications modes in an ITS-independent manner. It includes those aspects of message security, integrity, and privacy that are appropriately defined at the message level.
Maintenance method: formatted section.

D.

Security General recap of security requirements, including aspects that are not covered in other sections.
Maintenance method: formatted section.

E.

Specifications for an Implementable Technology Specification General enumeration of the topics that must be covered in a complete ITS.
Maintenance method: formatted section. Not normative.

Thoughts on a Publication Format for V3 Messaging

3

April 27, 1999


#%
Reference Information Model
A. Introduction
1. General Introduction Maintenance method: formatted section. 2. Dependencies. Identification of other HL7 documents that must be used in order to apply this document, and the range of version numbers that may be used. Maintenance method: structured section.

B.

Graphical Expression
7KHUH DUH VXEVWDQWLDO SXEOLVKLQJ FKDOOHQJHV KHUH

1. General Introduction Maintenance method: formatted section. 2. Inf ormation Model Maintenance method: structured section.

C.

Literary Expression

a)

General Introduction
Maintenance method: formatted section.

b)

Literary Representation
Maintenance method: structured section.

Version 3 Message Set
This is a category of document. Each instance that HL7 publishes includes the definitions of a group of message types that will usually require coordinated releases during updates, as determined by Technical Committees.

D.

Introduction
1. General Introduction Maintenance method: formatted section. 2. Dependencies. Identification of other HL7 documents that must be used in order to apply this document, and the range of version numbers that may be used. Maintenance method: structured section.

E.

Message Group There can be multiple sections of this category for a single Message Set.
1. General Introduction Maintenance method: formatted section.

Thoughts on a Publication Format for V3 Messaging

4

April 27, 1999


#%
2. Use cases

a)

General Introduction
Maintenance method: formatted section.

b)

Graphical Representation
Maintenance method: structured section.

c)

Literary Representation
Maintenance method: structured section.

3.

Message Inf ormation Model

a)

General Introduction
Maintenance method: formatted section.

b)

Graphical Representation
Maintenance method: structured section.

c)

Literary Representation
Maintenance method: structured section.

4.

Interaction Model

a)

General Introduction
Maintenance method: formatted section. Non normative.

b)

Tabular Representation
Maintenance method: structured section. May include lightly formatted subsections with normative comments.

5. Hierarchical Message Descriptions One or more of these sections will appear with a message group.

a)

General Introduction
Maintenance method: formatted section.

b)

Overview Tabular Representation
The equivalent of a MOD. Maintenance method: structured section.

c)

Full Tabular Representation
Maintenance method: structured section.

F.

Related Domains All domains used in the HMDs are included in this section. Where such domains consist of ver y large sets, or where the domain cannot be expressed without copyright violations, the included information may be only be a verbal description.

Thoughts on a Publication Format for V3 Messaging

5

April 27, 1999


#%
Not normative. 1. General Introduction Maintenance method: formatted section. 2. Domain One or more of these sections will appear with the Related Domains Section.

a)

General Introduction
Maintenance method: formatted section.

b)

Concept enumeration
When present, this material may be used as an example; normative definition of HL7 domains are published separately. Maintenance method: structured section.

HL7 Vocabulary Domains
Multiple documents in this category, as determined by the Vocabulary TC. Normative, where HL7 has the authority to define the concepts involved.

A.

General Introduction Maintenance method: formatted section. Domain One or more of these sections will appear with the Related Domains Section. Some sections will enumerate values, other will describe how the specific subsets of concepts may be obtained from other organizations.
1. General Introduction Maintenance method: formatted section. 2. Concept enumeration When present, this material may be used as an example; normative definition of HL7 domains are published separately. Maintenance method: structured section.

B.

Implementable Technology Specification
This is a category of document. Several such documents will request.

A.

General Introduction Maintenance method: formatted section.
Not normative.

B.

Other Sections One or more of these sections will appear with the Related Domains Section.
These sections will vary widel y from one ITS to another, but they will certainly be required to cover:

Thoughts on a Publication Format for V3 Messaging

6

April 27, 1999


#%
· · · implementation of message element types implementation of data types implementation of the Communications Models described in the Version 3 General Information document.

Thoughts on a Publication Format for V3 Messaging

7

April 27, 1999