Loading VIS in HL7 2.5.1


Loading the VIS (Vaccine Information Statement) in a HL7 2.5.1 message sounds straight-forward enough. Most of the time it is, the challenge comes in when you want to maintain both backwards and forwards compatibility and be able to send a Multiple Vaccines VIS. Once you start doing this you find you have to start supporting multiple methods of collect the VIS.

Method 1: Multivaccine VIS via bar code

In this case you are using 69764-9 (Vaccine Information Statement (VIS) document type) to identify a single multivaccine VIS via it’s bar code 253088698300026411121116. The list of valid concept/bar codes is available here.

If you look at the last 6 digits of the concept code:
You can actually pull out the edition/published date which is in the format YYMMDD. So in the case 11/16/2012.

For more information in regards to how to read the bar code string check the bottom of CDC Barcode.

Method 2: Multivaccine VIS via CVX (NOS/UF)


Now we are seeing the vaccine components be passed in via individual CVX code.  You’ll also notice that we have to manually specify the published date now as that’s not built into the concept code like in example 1.

When passing VIS for a multivaccine we need to have a Vaccine Type, Published Date & Presented Date for each vaccine component in the combo/multi vaccine.

Even through 2.5.1 supports passing in VIS via barcode (and is in fact the recommended way) you still need to support passing by CVX code. The reason being that in 2.3.1 everyone supported this method and it’s very likely you’ll still see it this way. Also, if a system hasn’t integrated in barcodes into their system they just won’t be able to send it you that way.

Method 3: Multivaccine VIS via CVX (Non – NOS/UF)


So the challenge here is say you had one EHR send you the data like you saw in Method 2. Now you have another vender send you data like you see in Method 3 above. Guess what, even though there are different CVX codes both vendors meant the same thing. It’s up to you to choose to reject on CVX components you think they should not have sent, perhaps try to realize that DTAP(20) meant 107(DTAP,NOS), maybe even you just end up taking in everything, but then you run the risk of having 6 VIS statements in your database when their should just be 3.

A whole other blog could be on what to do if your system matches different components of the multivaccine than what came in the message. In the example above they all came in via NOS(Not Otherwise Specified).  So for example 107 (DTAP, NOS) but another system might have sent in a VIS for all the components that were CVX codes for the vaccines actually identified.  You run the risk of either doubling the number of VIS statements collected or try to map what people really meant

Method 4: Single VIS with CVX

In this method you may choose to ensure the CVX code in OBX-5 (ObservationValue) matches what is in RXA-5 (AdministeredCode). But you need to know they only have to match if this is not a multivaccine.

Method 5: Single VIS void of CVX

In method 3.1 you need to ensure that the CVX code specified by the OBX ObservationValue 30956-7 matches the CVX code in the RXA-5 (AdministeredCode). Remember though, if the CVX code RXA-5 (AdministeredCode) was a multivaccine then we would need to make sure it was one of it’s components instead of a match.

Technically if it’s a VIS for a single vaccine the missing OBX segment identifying the vaccine shouldn’t stop you from being able to load the VIS since you could actually pull it from RXA-5 (AdministeredCode). The challenge is you can only make that assumption if it’s a single vaccine, in other words, there is only one possible VIS match.

Method 6: Single VIS via barcode

And finally we get to the straight forward method.

OBX|2|TS|29769-7^VIS Presentation Date^LN|1|20091010||||||F|||20120223

In the example above if could be argued that technically you should validate the VIS does match the vaccine. Also that the presentation date was indeed supplied. If either weren’t present a possible warning or information tag could be returned in the Acknowledgment. In other words, even the most straight forward method could be tricky.


We’ve just seen 6 different ways that Vaccine Information Statements may be passed in. One could make an argument that this complicates things and you are only going to load by bar codes but the challenge is all of the methods described above are valid and at least at this point of time most of them are going to pass by CVX.


Another questions comes up in regards to what do you do if two different sources report to you a different CVX code or barcode for the VIS statement.  If it’s for a single-antigen vaccine it doesn’t matter too much what they put in the OBX for the CVX code, and if you pulling by the VIS bar code it’s really more about the published date.  So regardless of what they passed in the OBX identifying the VIS you should be able to reasonably deduce what the value should be.

If you dealing with a multi-antigen vaccine each individual VIS needs to be passed in.  In this case they might pass in the CVX of the administered component or perhaps pass in the CVX of the NOS/UF version of the vaccine.  You just can’t control what they pass you, you can however decide that you will trust the source that said they administered the vaccine over the source that said the vaccine was historical.  In fact you could almost argue that you would not load the VIS if it would a historical vaccination, but really that comes down to local implementation rules.

Leave a comment