Value Sets in Test Message Generation

 

The Value Sets feature adds another dimension to the use of the MWB in test message generation. Through use of a value set, the tester is able not only to generate semantically correct message instances, but is able to imbue the instances with value context and value consistency and coherence. This in effect imparts the content of the message with significance to the receiver application which can extend the testing beyond the messaging system into the consideration of application behavior.

 

In simple test message generation, the tester is concerned with associating semantically correct values with message elements. In the MWB, this is done most handily with the Values Repository, a construct that associates any number of values with a particular message element. The test message generator, using a Conformance Profile as a template, does a lookup into the Values Repository and randomly selects an appropriate value for the message element, inserting it to the message instance being built.

 

Building a test message with Value Sets on the other hand works in a different fashion. It allows the tester to associate message elements with certain values. This is done in a hierarchical fashion in such a way that in the test message building process, when one of the values in the value set is selected for a given message instance, it is assigned to its associated message element, but more importantly each of the elements associated with the parent value may in turn have a list of values each of which may have message elements associated. By selecting the first value in this ‘value – element’ hierarchy, the content of the generated message is guaranteed to be semantically correct, but coherent application wise as well.

 

It should be understood however that Value Sets do not replace Values Repositories, but instead, compliment them. The creation of Value Sets while straight forward is fairly labor intensive, and requires a great deal of forethought especially when trying to model associations with individual value repetitions. The design intent of this feature is that in most testing scenarios, it will be sufficient to model only a portion of the message instance content in terms of Value Sets while much of the instance content can be left to random instantiation with semantically correct data from the Values Repository. In this way, the coherent data derived from the value set can act as a probe into specific application behavior, while the bulk of the instance data simply passes through the application.

 

As an example of the application of Value Sets, let’s consider a simple use case. We want to create message instances for a determinate subset of the patient population, with a primary identifier specified in PID.3.1. For each such patient id, we want to associate a particular assigning authority (PID.3.4), and for each identifier we want a distinct name attribute (last,first,mi; PID.5.1.1, 5.2 and 5.3 respectively). We want each of the patients to have a definitive date of birth in PID.7.1. Each of them needs to have a distinct religion specified in CE data type in PID.10.1, 10.2 and 10.3. In the PD1 segment, we want each to have a Living Will Code – PD1.7; in PV1 I want each to have a distinct Patient Class – PV1.2; and finally each will have an associated Insurance Plan ID in IN1.2.1.

 

Lets say the first patient identifier is 1234567, assigning authority USVHA; Name - Doe, John E; ; DOB, 03/28/52; race - 2106-3, White, HL70005. That takes care of the PID segment. In PD1.7, this patient’s Living Will code is ‘N’; PV1.2, his Patient Class is ‘I’; and in IN1.2.1 his Insurance Plan ID is JH345.

 

Lets add another patient: identifier 9999999; assigning authority AUSDVA; name – Smith, Jane W; DOB 11/17/49; race – 2054-5, Black or African American, HL70005;

Living Will Code – Y; Patient Class – ‘O’; Insurance Plan ID  - E99999.

 

Once we’ve created the value set (as will be demonstrated below) and specified its use in message generation, every message that is generated will have the ID and its associated information for one or the other of these patients. In other words each patient will have a distinct set of values associated and expressed in each message. Message elements not associated with these values will be randomly selected from the Values Repository or Table Library.

 

To create a value set, invoke the Message Generation option on the Tools Menu; make sure that a Values Repository is selected and start by clicking the on the Value Sets button to the right of the Values Repository List.

 

 

                                                            

Fig 1. Value Set Create/Edit form

 

Referring to figure 1 above, the value set form has a File menu, the options of which will be described later; an upper area containing two tree view windows used to define value relationships and a lower area consisting primarily of list boxes that facilitate value selection for the relationships.

 

Notice that the Message Tree is populated with a copy of the Profile that is currently loaded. This will be used to select the message elements to associate with values either selected from the lists at the bottom of the form, or locally defined values.

 

We’ll start of f the value set Definition by selecting PID.3.1 from the message tree, and dragging it over to the ‘Value Associations’ tree (VAT). Make special note of the fact that the element we are dropping on the VAT tree is primitive. Only primitive elements can have values associated with them, so only they can be successfully dropped on the VAT. Notice that as soon as we do so, the Repositories Values list box is populated with values that may be selected from the repository. If we wanted one of those values to associate with PID.3.1 we would select one from the list, then click the ‘Assign Values to Selected Element’ button to make the association (a double click on the value will accomplish the same).

 

In this case though, we are going to create our own local value to associate with PID.3.1. Notice that in the Local values list, there are already 2 values available. The first is a special “No Value’ token indicating that the element has no value association. The second is the HL7 double quotes indicating that the element should be removed from the receiver’s data base. These are used for special purposes to be discussed later.

 

Below the Local Values list is an edit box that we will use to enter our ID value ‘1234567’ . We then click the ‘Add Value’ button to add the value to the list.  Values remain on the list and may be selected at any time until/unless the list is cleared. To make the association, first select PID.3.1 in the VAT then select the ‘1234567’ value in the list and click the ‘Assign Values to Selected Element’ button. If you had PID.3.1 selected in the VAT before you clicked the ‘Add Val’ button, the association would have been made at that point.

 

We proceed to add the other element associations that we want to define. Select PID.3.4.1 – Assigning authority namespace ID from the Message Tree and drag it over to the VAT. Note that it automatically adds itself to the top level of the tree. Every time a new message element is added to the VAT, it assumes a top level position. In most cases as here however we need to associate the element with a particular value, so we must alter the initial relationship.

 

To do so, select the PID.3.4.1 node in the VAT and drag it to the PID.3.1 node in the VAT. Drop the node, and notice that it is now situated below the ID value. Notice too that it was inserted automatically with the ‘No Value’ token. In most cases as here we want at least one real value and no possibility of “No Value’, so we are first going to add the value we want associated with PID.3.4.1 and then we will delete the ‘No Value’ token.

 

Select PID.3.4.1 in the VAT and notice that the ‘Table Values’ list as well as the ‘Repository Values’ list are populated. In this case, for testing purposes we want the value for PID.3.4.1 to come from the Table (or vocabulary) specified in our profile, so we’ll select the code ‘USVHA’ from the Table values list, and click the ‘Assign Values to Selected Element’ button to make the association.

 

We could leave the ‘No Value’ token if for some reason we didn’t want a value to appear occasionally. This might be the case for example if we wanted to test with error potential. We could also add other values to the list of values for PID.3.4.1 for the same reason, or if there was a real possibility of more than one appropriate value for an element. If there is more than one value in the list for a given element, one of them will be selected randomly for inclusion in the message instance.

 

In this case though, we’ve determined that there is only one proper value, so we will delete the ‘No Value’ token. The easiest way to do that is to double click on the ‘No Value’ token in the VAT. Our form and the VAT in particular now look like Figure 2 below.

 

                                                                

Fig 2 Building a Value Set

 

Let’s proceed to add more detail to the value set in the same way. Add PID.5.1.1 by dragging it from the message Tree to the VAT; within the VAT drag it to the PID.3.1 node, select the newly positioned PID.5.1, add the local value ‘John’ and finally delete the ‘No Value’ token by double clicking on it. Repeat these steps through PID.7.1 Date of Birth, after which we’ll take a little different tack.

 

Before proceeding with the rest of the definition, let’s take the opportunity to save what we’ve done. Select ‘File\ Save to File’ from the main menu. Give the file a name. The value set is now saved external to the profile and may be loaded into any other profile using the ‘File\Open External MVS’ option. In this way, it is often possible to leverage and easily extend work previously done to apply to a new testing episode. Note that another option is to use the ‘Save to Profile’ option which makes the value set an integral part of the profile. This feature facilitates sharing the profile together with the value set and allowing multiple tests at different locations to using the same value set.

 

We will now add the Race elements to the value set. Select PID.10.1 and drop it on the VAT, attach it to PID.3.1 and add the code value ‘2106-3’ from the list of Table Values.

Select PID.10.2 and drop it on the VAT. Instead of associating it with PID.3.1, associate it with PID.10.1. Add the value ‘White’ to it. Select PID.10.3 from the message tree, drop on VAT, and associate it too with PID.10.1 instead of PID.3.1; add value of ‘HL70005’.

 

What we have done here is to associate the race attribute with the patient ID, but the qualifier attributes of the race code are associated with the race code itself, not the patient ID. Consider that if we wanted to model the case where the patient race may vary depending on how it was determined (i.e. patient himself, hospital personnel, transcribed from other record etc.) we would want to add another race code and qualifiers appropriate for that race code. Associating the qualifiers with the race code itself permits unambiguous assignment of the qualifiers in message generation.

 

This is a small deviation from the posited scenario, but to illustrate the point above, and to examine the mechanics of adding values that themselves have associated elements, we’ll add another race value to the VAT. Select the PID.10.1 node in the VAT, then select the 2131-1 code from the table value list; click the ‘Assign Values to Selected Element’ button.

 

Notice that not only is the code value added to the tree, but its substructure PID.10.2 and PID.10.3 nodes are added as well. Each of the substructure nodes has a single ‘No Value Token’ which in this case we want to replace with the values ‘Other Race’ and ‘HL70005’ respectively.

 

Drop the Message Tree Nodes for PD1.7, PV1.2 and IN1.2.1 onto the VAT, associate them with PID.3.1 and supply the values indicated above. The VAT will now appear as in figure 3 below.

 

                                                         

Fig 3 Value Set for a single patient

 

That completes the value set for one patient, we will add the second. To do so, first collapse the VAT tree under the first patient id node (1234567) by clicking on the ‘-‘ next to it. Select the top VAT node – PID.3.1. Add a local value 9999999 and click the ‘Add’ button’. Note that a second patient ID is added to the VAT tree, and that all of the substructure for the ID has been instantiated as well. Beyond the ID node however all of the elements have been assigned a ‘No Value’ token. The job now is to replace all of these ‘No Value’ tokens with the values indicated in the scenario above.

 

The VAT appears as in Figure 4 below after the addition of our second patient.

 

                                                                  

Fig. 4 Value Set with two patients

 

 

If we click the ‘Save’ button at this point, our value set will be saved and we may begin using it to generate test messages. Click on the ignore button only if you want to abandon your work.  If we do use the value set in test message generation, each message we generate will contain data values from one value set or the other for the elements that we have defined in our data set.  For example a given message will represent John E Dow with insurance plan id JH345 or it will represent Jane W Smith with insurance plan id E99999, but it will never be the case that a given message contains data from both value sets e.g John W Smith.

 

Before the the value set can be used for generating messages the generation options for Value Sets must be turned on. The generation options are accessed from the Message Instance Gen tab using the Generation Options button. Figure 5 below shows the Msg Instance Gen tab with the Generation Options form on top.

 

                                                             

Fig 5 Message Instance gen tab with Generation Options form visible

 

 

The principle option to be set is the ‘Use Value Sets’ check box. If this is activated then values from the value set will be inserted into generated message instances as described above. If it is not set, then the value set will be ignored even if it exists.

 

The Use Value Set Values Only option will ensure that when a ‘No Value’ token is encountered, the message instance value for the element will be null. If this is turned off then values repository values will be substituted for value set ‘No Value’ tokens.

 

Figure 6 below shows a couple of message instances extracted from a run using the Value Set that we created here. The data values from the value set are colored to make them stand out. Note that the message instance for John Doe (green highlight) selected the second of two Race values that we defined.

 

 

 

MSH|^~\&|||||20080110132747.590-0500|||813058EDE97D3C9A

PID|||9999999||Smith^Jane^W^^^^^^^19960111140323-0500&19941024150730-0500|^^^^^^^^^19200409000000-0500&20020107021541-0500|19491117|||2054-5^Black or African American^HL70005|RT ^^^^^^^^^^^19990930091225-0500&20020619133000-0500|||||||100||||2135-2-OBS|||||N||19980303150500-0500||||20030320161835-0500|||||DU

PD1|||||||Y

PV1||O

IN1||E99999

 

 

 

MSH|^~\&|||||20080110133106.860-0500|||A5CA9790FD1C1FB2

PID|||1234567||Doe^John^E^^^^^^^19940108161500-0500&19970402094805-0500|^^^^^^^^^20010522095700-0500&19950614123700-0500|19520328|||2131-1^Other Race^HL70005|121^^^^^^^^^^^20020503094100-0500&20000403095000-0500||||||||||387||||||||20030320161833-0500||||19960401204700-0500|||||PL

PD1|||||||N

PV1||I

IN1||JH345

Fig 6 Two message instances generated with the example Value Set

 

 

Be aware that Value Sets need not be used just to link data values to a given patient. They may be used anywhere that data coherence is required. For example we might want to add OBX elements and values to ensure for example that when a particular lab test (OBX.3) is selected from the value set that it is associated in the message with the appropriate values for the test (OBX.5) the appropriate units for the test (OBX.6) and the appropriate flags for a given value (OBX.8). Furthermore these two top level nodes PID.3.1 and OBX.3.1 can exist in the same Values Repository having completely independent affects on segments of the generated message.

 

This is a brief introduction the use of Value Sets for test message generation in the MWB. Hopefully it presents enough information for the enterprising tester to begin using the tool and to discover the nuances of its application to HL7 V2.x messaging testing. The distribution package of the MWB that includes this help article will include the profile used in this article (Example Profile for ValueSet.mwb) and an external file for the value set created (ValSetEx for HELP article.mvs). External ValueSets are stored in the \Lib folder while the profile will be located in the \Projects\Examples folder. In addition an external value set is included (ValSetEx for HELP article -Extended.mvs) that contains the OBX extension suggested above.