Defining HL7 Search Tables

The HL7 search table class, EnsLib.HL7.SearchTableOpens in a new tab, automatically indexes popular HL7 properties; see the subsection Properties That Are Indexed by Default.

If you need more items to search, you can create a subclass. The subclass inherits the Identifier property, plus the infrastructure that makes search tables work. For details, see Defining a Search Table Class.

For HL7, InterSystems supports an additional value for PropType. You can use DateTime:HL7 in addition to the types listed in Using Virtual Documents in Productions.

When you create search tables, do not use reserved package names; see Reserved Package Names.

Properties That Are Indexed by Default

When you choose EnsLib.HL7.SearchTableOpens in a new tab as your search table class, it enables InterSystems to search HL7 messages for the following virtual properties.

Choose...	To refer to this value...
MSHTypeName	The message structure name. To create this string, InterSystems concatenates the following values from the HL7 message: The MSH message header segment Field 9 (message type) Subfield 1 (message type: ADT, ORM, etc) The literal character _ The MSH message header segment Field 9 (message type) Subfield 2 (trigger event: A01, A12, O01_2, etc) The result is a message structure name in the format ADT_A01, ADT_A12, ORM_O01_2, etc.
MSHControlID	The unique identifying number for this message. The production retrieves this value from: The MSH message header segment Field 10 (message control ID) InterSystems interprets this value as a case-sensitive string.
PatientID	The patient identifier for this message. This is a field whose location has shifted as the HL7 standard has evolved. For this reason, InterSystems looks for this value in all of the following locations. That way, the patient identifier can be found regardless of which HL7 schema category the message conforms to: The PID patient identifier segment Field 2 (patient external identifier) Subfield 1 (patient identifier) The PID patient identifier segment Field 3 (patient identifier list), all entries in the list Subfield 1 (patient identifier) The PID patient identifier segment Field 4 (patient identifier list), all entries in the list Subfield 1 (patient identifier)
PatientName	The PID patient identifier segment Field 5 (patient name)
PatientAcct	The PID patient identifier segment Field 18 (patient account number) Subfield 1 (ID)

Examples

The following example consists of one virtual property path that uses {} syntax. This <Item> element refers to the value at Segment 1, Field 10 of the HL7 message:

<Item DocType=""
      PropName="MSHControlID"
      PropType="String:CaseSensitive"
      StoreNulls="true" >
      {1:10}
</Item>

The following more complex <Item> element uses the ObjectScript _ operator to concatenate three strings. From left to right, these are:

The value within Segment 1, Field 4
A literal - character
The value within Segment 1, Field 3

<Item DocType=""
      PropName="SendingFacilApp" >
      {1:4}_"-"_{1:3}
</Item>

The following <Item> example uses most of the possible syntax options: concatenation, virtual properties, a literal hyphen character (-), and the ObjectScript string function $PIECE:

XData SearchSpec [ XMLNamespace="http://www.intersystems.com/EnsSearchTable" ]
{
<Items>
 <Item DocType="Mater:ORM_O01 "
       PropName="RelationKey" >
 $P(
 {ORCgrp(1).OBRuniongrp.OBRunion.OBR:UniversalServiceID.text},"-",1,2
 )_"-"_{MSH:12}
 </Item>
</Items>}

The following sample search table class provides several examples of valid <Item> entries. This class inherits from EnsLib.HL7.SearchTableOpens in a new tab, as is required for HL7 search tables. Comments above each group of <Item> entries describe the purpose of that set of entries. For details about {} or [] syntax, see Syntax Guide.

Class Demo.HL7.MsgRouter.SearchTable Extends EnsLib.HL7.SearchTable
{

XData SearchSpec [ XMLNamespace="http://www.intersystems.com/EnsSearchTable" ]
{
  <Items>
   <!-- Items that do not depend on DocType, indexing any HL7 message -->
   <Item DocType="" PropName="SendingFacilApp" >{1:4}_"|"_{1:3}</Item>
   <Item DocType="" PropName="RecvingFacilApp" >{1:6}_"|"_{1:5}</Item>
   <Item DocType="" PropName="MSHDateTime" PropType="DateTime:HL7" >{1:7}</Item>

   <!-- Get fields from named segments found in any HL7 message -->
   <Item DocType="" PropName="PatientName" >[PID:5]</Item>
   <Item DocType="" PropName="InsuranceCo" >[IN1:4]</Item>

   <!-- Get patient name from any HL7 message declared type ADT_A05 -->
   <Item DocType=":ADT_A05" PropName="PatientName" >{3:5}</Item>

   <!-- Get specific field from specific segment when the        -->
   <!-- HL7 message is assigned a specific DocType. Only in this -->
   <!-- case can you use names for segments, instead of numbers. -->
   <Item DocType="Demo.HL7.MsgRouter.Schema:ORM_O01 " PropName="ServiceId" >
     {ORCgrp().OBRuniongrp.OBRunion.OBR:UniversalServiceID.text}
   </Item>
   <Item DocType="2.3.1:ORU_R01 " PropName="ServiceId" >
     {PIDgrpgrp().ORCgrp(1).OBR:UniversalServiceID.text}
   </Item>
  </Items>
}

}

Important HL7 Scenarios

Defining DTL Data Transformations for HL7