CeRx4.4.1 issues with prescription version

If I remember my history correctly, the proposal was for a data type that could carry a human readable version number (I don't recall the specific details of that proposal)...and that was rejected by HL7. So we were left with II.VER being a GUID. Now there may be ways to modify the definition of II.VER so that a human-readable version number could be included without actually calling it a version number.

As for adding a version attribute, the HL7 Act class - from which prescriptions and dispenses are drawn - does not have a "version" attribute.

When you say that HL7 rejected the "version element in the data type" do you mean they rejected adding a version data type or they rejected adding a element to hold the version information that was called version?

We are suggesting that we should remove the second Id element and add a version element of data type INT.NONNEG (not suggesting that we need a new data type defined)

There's no way to do #2 or #3 in a way that's v3-compatible. In v3, identifiers are expected to be globally unique. And there's no separate "version" element in the data type - proposals to add one were rejected when the issue was brought to HL7 international several years ago.

After implementing CeRx4.4.1 we come up with the following suggestions to make implementation easier on other vendors:

1. Always return the prescription version (even when the first version) -- Currently the standard is using II_VER_BUS type to represent prescription id and version information. Infoway requires the system to return the version information only if a prescription has been updated. This approach, and the fact that the initial prescription returns no version information, adds complexity to implementation.


2. Use of second ID element is confusing - having the version present as the second ID element instead of a specific version element adds unneeded complications to the standard. It also reduces the ability for standard schema validation to be used to validate correct adherence to the standard, as conditionals based on attributes are difficult to enforce within message validation processes such as schema.


3. Version GUID numbering does not allow identification of change order -- There should be a way to sort a prescription and its versions to allow the receiver to understand the life cycle of the prescription changes . As per the documentation from Infoway, the version is a globally unique identifier that does not allow any logical sorting of the value.

Our suggestions would be :
1. Always returning the prescription version number. The logic around when prescription version number is not returned adds complexity and provides no real benefit to an implementation.

2. Instead of id element use a version element.

3. Instead of using a globally unique identifier for prescription version we use a sequential number to identify prescription version like 1,2,3…

For example:

<version value =”1”/>
<version value =”2”/>
…
<version value =”n”/>