HL7 for Busy Professionals

by Rahul Bhagat

  Similarly, if two patient accounts are being merged then the surviving account number goes in PID-18 and the non-surviving account number goes in MRG-3. For merges at the visit level, the surviving visit number goes in PV1-19 and the non-surviving visit number goes in MRG-5.

  Query Messages

  Although not as widely used, HL7 query messages play an important role in clinical system communication. They could be used by an ancillary system to confirm the identity of a doctor with the provider registry or a reporting application could use them to request for a list of patients visiting emergency between midnight and 8:00 AM.

  The standard only defines the broad framework for implementing query using HL7 messages. Details, like the information to be shared and the parameters to be supplied, are left to the implementers to decide.

  Queries are implemented as a request/response message pair. The requesting system sends an HL7 message to the source system with search parameters. The source system uses these parameters to look for the information in its database and sends back another HL7 message with the information (or an error message if nothing was found).

  Query messages have been changing and evolving over the years, and currently the standard defines three ways that a requestor can ask for information and three ways that a source can provide the information back to the requestor.

  First, lets look at ways to ask for the information (defining a query). A requesting system can create a query as a query by parameter (QBP), a query by example (QBE) or a complex expression query (QSC).

  All three options use a segment called parameter definition segment (QPD), to supply the details of the query. For those familiar with databases, the process is similar to invoking a stored procedure by supplying the procedure name and parameters. For those unfamiliar, a stored procedure is a pre-defined query with a name. They are useful for frequently used queries where instead of defining the query again and again, you define it once, give it a short name, and whenever you need to run it, you just call the short name with parameters.

  Here is an example. Suppose all patient demographic records are stored in a table called pt_dem. If you want a list of patients by their marital status, then you define a query - "get all last name and first name from pt_dem table where marital status is = x". The marital status field (x) is the parameter that is supplied with the query. This query can be saved as a stored procedure. You can give it a name, for example patient_list_by_marital_status, and whenever you want a list of patients by marital status, you run this query.

  Now, do you want a list of patients who are single? No problem. Call patient_list_by_marital_status where x=single. Simple!

  Query by Parameter (QBP)

  This is the simplest method. The message supplies the query name and parameters in the QPD segment. The system invokes the query and plugs in the parameter, for example,

  QPD|Z05^patient_list_by_marital_status ||single

  Query by Example (QBE)

  This method is similar to QBP with the difference that the parameters are not sent in a QPD segment. They are sent in their respective segment fields. So instead of sending the value "single" in a QPD segment, a PID segment will be added to the message and PID-16, which is the marital status field, will be populated with the value S (for single). For example,

  QPD|Z05^patient_list_by_marital_status||

  PID||||||||||||||||S

  The advantage of this method is that systems don't have to communicate what the parameter is. In the first method, the receiving system has to be told beforehand that QPD-3 is the field for marital status. Otherwise, it won’t know what the value is for and the situation gets worse if there are multiple parameters.

  In the case of QBE, there is no need for any of this. PID-16 is the marital status field defined by HL7. This is universally known and the receiving system uses this knowledge to intelligently extract the parameter from the message.

  Complex Expression Query (QSC)

  This is the most complex of the three methods. In this case, the requesting system defines the exact search criteria of the query as an expression similar to database language SQL. The field, QPD-3, holds the expression, but the data type of QPD-3 in this case is QSC (Query Selection Criteria).

  The QSC data type has four components: field name, operator, value and relational conjunction. These four components are used to form the search expression that goes in the QPD-3 field. For our query, the field is PID-16 (marital status), the operator is equal (EQ) and the value is "single". There are no relational conjunctions (AND, OR, etc.) therefore the query segment will look something like this:

  QPD|Z05^patient_list_by_marital_status||@PID.16^EQ^Single|

  Each method has its advantages and disadvantages. If you want something simple and straightforward to implement, you go with a QBP. On the other hand, a QSC is best suited for situations that require a lot of flexibility and the ability to define complex queries and extract very specific information.

  Now, let’s look at three ways to send the information back to the requesting system. The options are – Tabular, Display and Segment Pattern formats.

  Tabular format is a simple and easy to process option. Data is returned as a table in the message. Column headers go in the RDF (Table Row Definition) segment and rows go in repeating RDT (Table Row Data) segments. This makes it very easy for the receiving system to parse the segments and reconstruct the table.

  Display format is similar to Tabular but is also pre-formatted for human readability. It can be easily displayed on a screen or printed out. The result comes across as repeating DSP (Display Data) segments in the response message. The DSP-3 field holds the pre-formatted data, which can be sent directly to a printer or a computer screen for display.

  Segment Pattern format is different. It sends the result through standard HL7 segments. So if a query is for patient records, those records are returned as PID segments in the response message. If there are multiple records, then multiple PID segments are returned.

  The Segment Pattern format is great for complex and large results. For example, a lab result where entire segment groups (OBR, OBX etc.) are returned in the result message. But cases where only a few fields are needed, this format will add unnecessary parsing and processing overhead.

  We are not going to discuss the segments involved in query messages. There is a lot to learn, especially if you are working with queries. The discussion here is only a precursor for further reading on this topic in Chapter 5 of the HL7 spec. In the spec you will also discover that there are many other message types like financial transaction, scheduling etc. that we didn’t discuss in this book.

  This book is only an attempt to pry open the HL7 doors for you. And the topics we have discussed so far, more than do the job. So this is good place to call it a day for this introductory book. I hope it was a good read and you enjoyed it.

  I don’t know what motivated you to read this book. If it was just to get familiar with the subject, then you are done. You can check it off your “to do” list and enjoy that satisfying feeling. On the other hand, if this is your first step towards mastering the subject, then you are all set to step into the brave new world of HL7 and make it your own.

  Welcome to the world of HL7! ☺

  HL7Book.com

  Please visit the companion website to provide your feedback and suggestions.

  Did you spot a typo? Or an error? Please drop me a line through the feedback page. I’ll appreciate it.