To: HL7 Control/Query Technical Committee Members From: Mark J. Shafarman Date: 7/6/93 Re: Minutes of Control/Query Technical Committee Meeting, Boston, Ma. on 5/19/93 and 5/20/93 1. Technical Committee Ballot Status The HL7 technical committee ballot rules have had a step added to them to make them ANSI compliant: on a technical committee ballot that was not unanimous, the members who voted positively must have an opportunity to review the negative ballots and the chair's reply to them. After review, these same members have an option to change their vote from positive to negative. The latest Control/Query technical committee ballot had two items, the control/query chapter and the master files update chapter. Each of these passed with a single unresolved negative vote. Consequently, all technical committee members who voted in the last Control/Query technical committee ballot will receive the above mentioned materials for their review. These will be sent out in the early part of July 1993. 2. First Session, afternoon, 5/19/93 2.1 BNF Cliff Bernstein of IBAX presented a discussion on the use of BNF, Backus-Naur Form, for describing the syntax of HL7 messages. BNF is a widely implemented formal syntax definition language which can be used to describe complex, hierarchical data structures such as an HL7 message. In addition to being able to describe the syntax of an HL7 message, BNF descriptions can be used as input to widely available utilities to generate code that parses an HL7 message. For example, in UNIX environments, the utility programs YACC ("Yet Another Compiler Compiler") and LEX can use the BNF description of an HL7 message to generate a program that will parse that message. The committee decided that a standard BNF description of HL7 messages, at least to the segment level, would be a useful appendix to the standard. Consequently, Cliff will present a draft version of a BNF specification defining HL7 2.2 messages at the segment level. This draft will be submitted for a separate technical committee ballot as an appendix to the Control/Query chapter of HL7 v. 2.2. 2.2 ASN.1 ASN.1 is a candidate for use by HL7 v. 3 as a method of encoding messages. The Version 3 Task Force (V3TF) is investigating ASN.1 as one of the encoding rules options for HL7 v. 3. Experiments in the use of ASN.1 to encode HL7 messages are being made by some institutions and vendors. Mark Tucker of Philips Labs presented a tutorial on ASN.1. ASN.1 was somewhat demystified, at least as a vehicle for encoding messages. Basically, any hierarchical set of name-value pairs may be encoded via ASN.1. ASN.1 has several advantages over the current HL7 encoding rules. For example, an ASN.1 message carries the both the definition of the structure of the data, and the data itself; ASN.1 can handle binary data. Contrary to popular conception, if an ASN.1 message does not contain binary data, it may be transmitted as a string of printable characters. Since an HL7 message is basically such a string, it may be transmitted as a single field or as a collection of fields within an ASN.1-encoded structure. Following this same line of reasoning, there is no reason why an HL7 Z-segment cannot be defined so that an HL7 field is used to transport the string version of an ANS.1 encoded structure (if the HL7 delimiter characters are escaped). There is a widely available tool called ASN1Tool that can be used on a wide variety of hardware platforms, and operating systems. Further information on ASN.1, contact Mark Tucker at 914-945-6564 (or mct@philabs.philips.com). A report on the encoding schemes discussions of the V3TF will be presented at the September meeting. 2.3 Events Wayne Tracy presented his preliminary work towards what he has named a "unified trigger event model" for HL7 messages. He has created some spreadsheet printouts that summarize the current variable usage of trigger events in HL7 messages. The approach used by different functional areas within HL7 is inconsistent. For example, each event in the ADT/Finance chapter has a separate message definition; and the event is defined in both the EVN segment and the MSH segment. Most ADT events concern single "objects" (such as a person or account or encounter). However, others concern relations between more than one object (such as the merge event). In the current version of the orders chapter, a message may contain several separate events (acting on several different orders). In the Finance chapter, there is the DFT message which may transmit many charge or credit events for a single object, the patient account. A task force was formed to review this work and come up with an approach for clarifying and unifying, if possible, the trigger event usage within future versions of HL7. Members include Jon May, Ted Klein, Jerry Buckert and Mark Shafarman. 3. Second Session, afternoon, 5/20/93 3.1 Master Files The segment definitions for master files needed by most HL7 applications will be the province of the Master Files chapter. Other functional areas will vote on master files segments needed for those areas. Thus, the Order Entry/Results Reporting technical committee is working on Test/Observation master file segment definitions to transmit lab and other ancillary reporting systems test dictionaries. In this context, Francine Kitchen presented her work on Master File Segments for transmitting information about staff and health practitioners to the Control/Query Master Files technical committee. Francine is also working on charge description master file segments with the ADT/Finance technical committee. A number of straw votes were taken during the following discussion. * Should the HL7 Master Files chapter contain segment definitions for entities likely to be used by all functional areas within HL7 (such as the staff and practitioner segments)? Vote: 19 in favor, with 3 abstentions. The other functional chapters will create master files segments according to their own functional needs (as stated in the current balloted version of the Master Files Chapter). For the Master Files chapter, Francine provided drafts of a User and Profession segment. The rest of the straw votes pertain to these two segments. Discussion and votes on the STF (staff) segment. Note that this was formerly the user (USR) segment. * Change the name of the "user (USR)" segment to the "staff (STF)" segment; and change the name of the "professional (PRO)" segment to "practitioner (PRA)". Discussion: the word "user" has too many limitations and connotations (e.g. only computer users, complex password and security issues associated with transmitting these data, etc.). Also, in many health information applications, the term "health professional" may refer either to a person or an institution. The term "staff" connotes more generally a person who is working for or associated with a healthcare institution. Practitioner refers only to a person. Information about other types of staff can be transmitted by creating other secondary segments, as needed. Vote: 19 in favor, 1 against, 2 abstentions. * Add primary key to Staff segment (MFN control ID). Unanimous. * Go to a single address field: use the type component to signify H(home) or O(office). * Beeper # will have a separate field. Vote: 11 in favor, 5 against, 4 abstentions. * Make phone number field repeating; use "C" section to indicate type of phone #. Vote: 15 in favor, 0 opposing, 6 abstentions. * Delete the % employed field. * All fields optional except for the primary key (MFN control ID). Unanimous. Discussion and votes on the PRA segment. Note that this was formerly the PRO (professional) segment. The following changes were voted unanimously: * Everything is optional except the MFN control ID field. * Remove preferred phone, hospital ID, tax status, number of suspensions, currently suspended. * Make specialty a 4 component repeating field containing the following components: specialty name or abbreviation; name of governing board; eligible or certified; certification date (if applicable). * Make practitioner ID field repeating; containing components for ID#, ID type; State where valid (if applicable). This combines the previously separate ID fields, and allows more flexibility in specifying ID's. * Make privileges a repeating field with 4 subcomponents: service; privilege class; privilege name or abbreviation; and privilege expiration date (if applicable). Note: during editing of this segment the activation date was added as an additional component to this field. 3.2 Character sets Dan Levine presented an introduction to the UNICODE standard (a 16-bit international/ universal character set representation standard) and to the new ISO Draft International Standard 10646, a 32 bit standard, which includes UNICODE as a 16 bit subset. In addition, he presented proposals for adding an encoding character set field to the MSH, and an extension to the HL7 escape sequences to allow changing the character set within a single field. The group had a lot of questions about whether the basic character set should be established within the message header or during the interface negotiation and specification stage. The general consensus was that the character set is defined as part of the interface negotiation and specification stage. In order to investigate these concerns further, a small task force, consisting of Ed Schultz, Jon May and Mark Shafarman was set up. The task force will also investigate the work of other standards groups, such as ASTM, CEN, and X12. 3.3 Query Discussion Ed Schultz asked for clarification of ways in which the existing HL7 query specification could be used in a "publish and subscribe" model. Publish and subscribe is an emerging capability of many distributed databases that allows a workstation or client that has been "offline" for a period of time to get request a list of changes to those databases in which it is interested. To implement such a system using HL7 requires setting up HL7 queries to request the data needed. The current HL7 query structures will support creating such requests, but not in an SQL-compatible manner. Another approach to supplying a series of changes for a remote/client system is to implement a store and forward application that sends a broadcast stream of HL7 messages to the desired clients. However, the sense of the meeting was that the query definitions in HL7 are very open-ended, and subject to a lot of interpretation. Thus a well-defined subset of the HL7 query capability must be specified for each operational HL7 interface. The ADT chapter has done the most complete job of defining queries, but even that does not cover all possibilities. One alternate approach suggested was to consider each segment in an HL7 message to be a table in a relational database. Then a standard SQL query could be unambiguously defined on that table. Cliff Bernstein agreed to head a task force (with Don Johnston and Mark Shafarman) to examine and explore this possibility further. Initially the group will try to write a functional set of ADT queries from this model. Note that this approach will need to define an explicit data model. The task force will also check to see if any other HL7 members are taking this approach within their local environments. 4. Additional field suggested for the MFI (Master Files Identification) segment. During the editing of the Master Files chapter, it became apparent that an application identifier is needed to qualify the master file identifier field in certain cases. The use of this field is parallel in meaning to the application ID component of the placer and filler number fields (see Order Entry chapter), or to the facility ID component for the patient and location identifier fields (see version 2.2. draft of chapter III). It is an optional code of up to 6 characters which (if applicable) uniquely identifies the application responsible for maintaining the particular instance of the master file at a given site. It is used in the case where a group of intercommunicating applications may reference more than a single instance of a master file of a certain type (e.g. charge master or physician master). The particular instance of the file can be specified by valuing this field. This field will be balloted separately as a possible addition to the 2.2 draft master files chapter. 5. Upcoming ballots: summary for control/query-master files The following items will be balloted in early July as additions to the master files 2.2 draft. * An appendix containing the STF (staff) segment and the PRA (practitioner) segments * The addition of an application identifier field to the master files identification (MFI) segment The following item will be added to the appendices to the 2.2 draft: * An appendix containing a BNF description specifying HL7 2.2 messages to the segment level. At the same time, members who participated in the previous ballots for the control query and master files chapters will be given a chance to reconsider their votes. 6. Draft Agenda for September meeting Reports of task force subcommittees on: * HL7 Version 3 Task Force meeting, especially concerning encoding rules discussion. * Review of trigger events * Character sets * Queries Review of ballot items. Attendees 5/19/93 and 5/20/93 Rita Altamore ** Univ. of Washington Robert Ackerman ** Fresno County James Barthel ** American Soc. Gastrointest. Endosc. Cliff Bernstein *,** IBAX Jerry Buckert *,** IDX Judy Chang ** Dept. of Vet. Affairs John Crawford *,** HBOC Robert Dorfman ** MetPath, Inc. Sue Fagen * Northwestern Memorial Hospital Mitch Fry ** Sunquest Christine Jasien * KDS Don Johnston ** CHOP Francine Kitchen ** PHAMIS Ted Klein * IBAX Dan S. Levine ** IBM Jon May *,** Sunquest Jay Margolis ** SMS Chuck Meyer ** IBAX Doug Pratt *,** SMS Lawrence Reis ** Health Info. Systems Cooperative Mark Shafarman *,** BAHS Ed Schultz *,** Dept. of Vet. Affairs Wayne Tracy * Cerner Mark Tucker *,** Philips Labs Steve Wagner ** Dept. of Vet. Affairs Jon Wenger ** Cygnet Labs *=attendee 5/19, ** attendee 5/20