________________________________________________________________ To: HL7 Control/Query Technical Committee Members From: Mark J. Shafarman Date: 2/16/93 Re: Minutes of Control/Query Technical Committee Meeting Orlando FLa, 14 Jan 93 ________________________________________________________________ 1. Technical Committee Ballot Status: Not all ballot responses were available at the Orlando meeting. However, they were available by the end of the next week. Results are as follows: 1.1 Chapter VIII: This chapter had passed the technical committee with the previous ballot. Minor edits were accepted at the September 1992 meeting, and the edited chapter was distributed as an "fyi" with the Dec. 11, 1992 ballot. However, a new chapter VIII ballot was also inadvertently distributed with the Dec. 11, 1992 ballot. Since Chapter VIII had formally passed the technical committee ballot, no new discussion was initiated at this meeting. However, were the Dec. 11, 1992 vote to be considered, however, it would have passed again. * 12/11/92 technical committee ballot results were: 28 positive, 1 negative, 1 abstention (93.33% positive). The negative was the same unresolved negative as the prior ballot (see ballot notes for discussion (sent out with the 12/11/92 ballot)). 1.2 Chapter II: This chapter had also passed the previous technical committee vote, on the previous ballot. However, it was the consensus of the committee meeting at the September '92 working group that the changes suggested were substantive enough to warrant a new ballot. The chapter again passed, but this time with only one unresolved negative votes (see discussion below). * 12/11/92 technical committee ballot results were: 29 positive, 1 negative, 96.66% positive. The negative was the same unresolved negative as the prior vote (see discussion below for details). 2. Meeting notes: Morning session: The new version 2.2 acknowledgement protocols were reviewed and discussed. Various FAQ's (frequently asked questions) were reviewed for new members. For example, HL7 does not describe how to implement a store-and-forward application, but instead concerns itself only with point-to-point links between applications. Since any store and forward application can be decomposed into a number of point-to-point links, a store and forward application can be built using HL7 for each point-to-point link. In fact, the distinction between "accept" and "application" acknowledgements available in HL7 2.2 makes using HL7 with a store and forward application much easier. Further discussion was held on acknowledgment interpretations and how they might be handled in future versions. The next "FAQ" item discussed concerned sequence numbers. It was decided that the implementation guide should be used to explain the usefulness of sequence numbers instead of enhancing the discussion in the standard. The FAQ of null vs empty fields was discussed, with it being agreed that 2.2 explains this somewhat better than version 2.1. 2.2 Ballot discussion: Chapter VIII. This chapter had passed the technical committee as of the last ballot, and was inadvertently distributed for ballot again with the Dec. 11, 1992 ballot. Since it was formally out of committee, no new discussion was opened at this meeting. Chapter II. Chapter 2 was opened for discussion of issues to resolve the negative ballot from Gary Dickenson of HDS. Gary Dickenson of HDS was given the floor to discuss his negative ballot on chapter 2. The notes that follow are keyed to his ballot response. See appendix A for a copy of his response. General Comments: Much of the concern from HDS was based on the difference between a specification such as HL7 that describes an interface between two loosely coupled systems vs. a more tightly coupled (more "plug and play") specification. It was suggested that the implementation guide include a discussion describing the following HL7 scope issues: 1) HL7 supports interfaces between loosely coupled systems -- it is not plug-and-play; 2) site specific negotiations will be necessary to implement an HL7 interface. HDS# 1. It was moved that the writers of chapter 1 be asked to include the following language: HL7 is not plug and play. HL7 requires site negotiated agreements for implementation. Hl7 does not make assumptions about the architecture of systems or resolve architectural disparities. * This motion was unanimously approved. HDS# 2. Chapter header naming formats. Agreed to pass this one to the group working on the publication of v. 2.2. HDS# 3. Implementation agreements. The motion was: A list of implementation issues should be in the implementation guide. * This was also approved unanimously, but Gary Dickenson commented that the implementation guide should also be balloted. HDS# 4. Coding systems identification issues. This was discussed in some detail. HDS's point was that a coding system that was not an international or national standard should only appear in a Z- segment field. This would cause severe backward compatibility issues with the 2.2 specification. A motion to accept the proposal from Gary Dickenson's negative ballot numbered 4c. was made and seconded. 1 in favor, 7 opposed, 1 abstention, the motion failed. Other motions made in response to these issues were: A motion was made, "Take the discussion of coded values from [its current location in] chapter II and find a more appropriate place for discussion." Passed unanimously. Chairman's comment: look for either a more appropriate place in chapter II, and/or a place in chapter I. A motion was made: "Add under what is needed in negotiation in chapter 1 a statement concerning site defined tables." It passed unanimously. HDS #5, 6, and 7.Trigger event issues. We discussed the HDS concept of a source and a receptor trigger event (see below). It turns out that when HDS talks about an application supporting a source or receptor trigger, this does not necessarily imply knowledge of the design of the application. It means only that the source or receptor application is capable of creating or processing an HL7 message according to some application-defined "event". We also discussed the fact that the current structure of HL7 messages is not uniform in regards trigger events: some messages transmit variable event information about more than a single object of a given type, some messages transmit information only about a single event for a single object, etc. See further discussion of this in appendix B. In light of this discussion, a motion was made "Some edit language describing the variety of HL7 triggering events [needs to be] added to chapter 2." Passed unanimously. HDS #8. A motion was made: " Add to the ADDRESS datatype (AD) a type component value 'B' for business address." Passed unanimously. HDS #9, 10, 11. The ID datatype does not include a coding system identifier, unlike the CE datatype. There is a similar inconsistency with the CN datatype, that has been fixed in v. 2.2. As a result of this discussion, the following motion was made: "An optional trailing component be placed on the ID type that references the table number". Result: 1 in favor, 6 opposed, 2 abstained. HDS #12. Add the Mod11 check digit algorithm (the Mod10 is already present). Accepted as an edit for v 2.2. HDS# 13, 14, 15, 16, 17, 18, 19, 20. Various motions concerning coding systems identifications. Withdrawn by HDS. See discussion under HDS #s 4, 9, 10, 11. HDS #21, 22, 23, 24. The use and need for the RP datatype were discussed. In addition, the following motion was made:"Edit RP definition to include string types and NS[non-scanned image] types. Add an example of RP to chapter VII." Passed Unanimously. HDS #25. QT datatype. This is fully defined in chapter IV, but included here only for reference and completeness. It will be available concurrently with chapters IV and VII when those chapters are balloted. It's inclusion here is an editing issue. HDS's objection was thus withdrawn. HDS #26-29. Discussion of the MO datatype. These issues will be be resolved if covered by appropriate ISO standard. HDS #30. HDS agreed that this item was discussed above under #s 5, 6, and 7. Chairman's note: The various changes to chapter II agreed to in this discussion are not considered substantive enough to require a separate technical committee ballot, but will be included, along with other edits, in the version of Chapter II to be balloted by the HL7 general membership. Afternoon Session: The afternoon agenda included the following: Control changes Event structures 2 byte and other character sets Query modifications Binary file transfer Masterfile updates Note that all these issues apply to versions of HL7 subsequent to version 2.2. 2.3 Query discussion: There was a discussion about how to query for a single data element. The first part of the discussion falls into the "frequently asked question" category; i.e., "why are the HL7 query messages defined the way they are?" Some historical background was given stressing that the current set of query structures work well between loosely coupled systems. The further question came up: how do you query for an ADT data element that is not presently in an ADT message (e.g. great aunt's maiden name)? One approach consistent with the current standard would be to define Z-segments to carry the necessary data within the current query framework. Another, more general approach, would be to use an OBX-type segment that functions as a name/value pair. This may require changes to the existing query structure. Is there a volunteer to explore it more fully? 2.4 Using SQL as query language. Should SQL be used for HL7 an query? Again, this approach requires some additions to the existing query structure. In particular, there is the question, "Does this require the initiating system to know the structure of the database being queried?" A related question is "Should such queries be restricted to a commonly agreed upon HL7 data or object model?" Doug Pratt is going to investigate this with Mead Walker and report back. 2.5. Dan Levine talked about the need for extended character sets in foreign countries such as Taiwan. It was decided that this was probably a version 3 issue and that more work needed to be done. Dan is going to generate a proposal to implement this. It was also suggested that the European HL7 members be consulted as to how they have handled extended character sets. 2.6 Another FAQ: A question was asked about how to submit proposals. Proposals should be submitted to the chapter chairs, preferably in a text or Word-Perfect file on a DOS-formatted diskette. It is also helpful if the person making the proposal can bring printed copies of the proposal to the next working group meeting and discuss it with the technical committee. If a proposal is submitted prior to the deadline for the next meeting's minutes, it can be distributed to the membership with the minutes. 2.7 Binary file transfer. Under HL7 2.2, the way to do this is to use the RP data type, as an address to the system that has the data file and where the data file is located. The OBX segment carrying the RP value can be part of an ORU message, or part of a response to a results query. 2.8. Master Files. Francine Kitchen, of PHAMIS, is soliciting information to use in defining desired fields for various masterfile segments. The master files that she is addressing initially are the common ones of doctor, location, charge, and test. It was also suggested that the OBX segment, which is capable of transmitting name/value pairs, may be used in place of Z-segments in the master-files messages. 2.9 Event discussion: The HL7 event structure, as encoded in current HL7 messages takes several different forms, to support several different types of events. See appendix B for a further discussion of this. Control should provide other chapters with better, clearer language to describe event structures. If the individual chapters wish, they can come back with further enhancement recommendations. Events need to be described by the control chapter (as to the various types and how they are encoded into messages). The other chapters need to describe events in terms of their use and meaning. 2.10 A suggestion was made that the control section should be redefined in a more rigid structure such as BNF to make it rigorous. It would help take the ambiguity out of the present control structure. Mark Tucker volunteered to try encoding HL7 control structure in ASN1 and Cliff Bernstein will assist. 2.11 Mark Shafarman reported on the version 3 task force. One of the important goals of this task force is moving towards "plug- and-play". An important concept in these discussion is whether two intercommunicating systems are tightly or loosely coupled. Loosely coupled systems send messages as notifications rather than as instructions for particular field level operations for the receiving application's database. One way to describe this range of loosely-to- tightly coupled systems is the concept of multiple levels of compliance. The DICOM group is using this concept in their standard. The DICOM message header indicates the compliance level required for the receiving application. It is possible that some variety this strategy will be used in HL7 version 3. Attendees: Cliff Bernstein IBAX Hauppauge, Ny Pat Cahill Mayo Foundation Rochester, Mn Alan Coltri Johns Hopkins Baltimore, Md Gary Dickenson Health Data Sciences Corp San Bernadino, Ca. Mike Edwards Philips Med Sys Shelton, Ct Sue Fagen Northwestern Mem Hosp Chicago, Il Darryl Huneycutt MUSC Charleston, SC Francine Kitchen Phamis, Inc Seattle, Wa Dan S. Levine IBM-Health Sys Gaithersburg, Md Sue Meadows Daughters of Charity NHS East Linthicum, Md Chuck Meyer IBAX Orlando, Fl David Paradis Ubitrex Corporation Winnipeg, Canada Mark Shafarman BAHS Greenbrae, Ca Doug Pratt SMS Malvern, Pa Mark Tucker Philips Labs NY Jon Wegner Cygnet Labs San Jose, Ca Scott West Space Labs Medical Redmond, Wa Appendix A: HDS negative ballot for Chapter II. Appendix B: Notes on HL7 event paradigms. Current HL7 Event Types and Event Requirements for Version 3. 1. Definition of an event. We have implicitly described in HL7 2.1 two semantically distinct types of events. The first type of event applies unambiguously to what we usually consider a single instantiated object (e.g. a patient, an account, a clinical result). Thus, an admit is conceptualized as a single event acting on a single object, the patient. In our current message model, the external or message-level event of admit will be broken down into distinct actions on each of several other instantiated objects. Thus, an admit may require the registration of a patient (create or update patient demographics, create a new account), the assignment of a census location, the recording of certain management information (an admitting physician, the attending physician, etc.), and the recording of some clinical information (e.g. allergies). The second type of event applies to two or more objects. For example, in the ADT chapter we have several types of merge events possible in the MRG message; we also have the swap beds transaction, and the patient link transaction. In the merge event, we allow events that require actions on two patients, two accounts or two patient/account combinations. The swap event affects the census locations of two patients (or two patient encounters). The link event clearly relates two PID segments (implying a link between two patients). In the future, one can imagine the link event being extended to allow the specification of various types of heriditary/familial relationships on more than two patients (e.g. the following four pid segments are all siblings). In the current ADT chapter, this second type of event is applied to only two objects at a time. In the order entry chapter, the scope of this second type of event has been expanded to allow specification of one-to-many, many-to-one, and many-to-many relationships between objects. For example, we can specify a single parent order "generating" multiple child orders (one-to-many) (see note F., pp. IV-9). We can specify several orders that have a single report (many-to-one, see note J., pp IV-10). We also have a syntax that allows us to replace one group of orders with another group of orders (many-to-many) (see note C., pp IV-7). We need a name for both types of events. I suggest calling the first type of event "unitary", since it's action is conceptualized to effect a single entity. The second type of event could be called a "linked" event, because it can only be understood in terms of the relationship or link between the two groups of objects. 2. Messages need to support unitary and linked events. In terms of a message based protocol, all the information needed to described a "linked" event needs to be contained in a single HL7 message. If this is not the case, implementation on the receiving system becomes very complex if not impractical. The message containing the first part of the information cannot be fully processed until the remainder of the information arrives in another (later) message. Thus the HL7 message event syntax needs to be able to support both unitary and linked events. 3. Multiple events within a message. Whether more than a single event of either type should be allowed in an HL7 message is a distinct issue from whether messages need to support both unitary and linked events. We also need to clarify this issue. In what follows, I am suggesting a clarification by describing several common cases that exist in the health industry and are reflected in the current version of HL7. The most common case of multiple event messages is found in the query-response paradigm. For example a record-oriented results query typically generates a response containing multiple results, often in a reverse chronological sequence (see page VII-4). The current response message definition allows multiple results for multiple patients. In the ADT chapter, the patient query (see page III-7) also allows multiple encounter objects to be returned. Both of these cases support common needs, and both support the return of multiple objects (with possible differing statuses (or events)). Another common case is described in the finance chapter, where the "add/update billing account"transaction (see page VI-2) allows the transmission of multiple accounts (events) in a single message. Also in this chapter we have the "post detail financial transaction" message, which clearly allows creating a message with multiple events (at the financial transaction level). In the above examples, I am not discussing the way the current HL7 encoding rules are used to generate the message, but I am noting that in certain common cases that HL7 needs to support, we already make use multiple event messages. The above cases are all examples of messages containing multiple unitary events. Even in the case of the response message for the results query (pg.VII-4), where the message allows multiple patients, each having multiple results, there is no linking between the events. The semantic meaning of each event is understandable without reference to another event. In the current orders chapter we allow multiple unitary events in a single message. Actually, we allow multiple linked events (or a mixture of unitary and linked event types) in a given message. 4. We clearly need to allow multiple unitary events within the response message. Whether we want to allow a message to contain a mixture of linked and unitary events is something we'll want to address for version 3. 5. Syntactic representation of unitary events, linked events, and multiple events. This is an open issue at present. HL7 has only one "formal" way of representing an event at the message level: using the second component of the MSH segment's message type field (formally defined by table 0003). The EVN or ORC segment may be used within a message to specify an event on the ADTf or orders/results object following it. But both the EVN and the ORC may be used to specify both unitary or linked events. In addition both the EVN and the ORC may be used more than once in messages with multiple EVN or multiple ORC events. Thus we currently specify events at the message level, and possible again at the EVN or ORC or even DFT segment level. There is also confusion between various status values and the message or object event. (e.g. the result status field of the OBR vs. the order control code of the ORC; or the transaction type of the FT1 vs the event code of the EVN segment). Is the status value an event on a component of an object? Should we have a formal definition for this type of event? In version 3 I suggest that we develop a message event syntax that allows specification of either unitary or linked events, and that allows multiple unitary events (on the same type of object) to be transmitted within a single message. In other words, a message should be able to transmit information about: 1) a single unitary event; b) multiple unitary events (on the same type of object (class)); or a single linked event (either a one-to-many, a many-to-one, or a many-to-many type).