CeRx4.4.1 issues with prescription version

Since you are talking about a change to a datatype, which affects everything, this needs to be carefully considered. I would like to see former SCWG 6 members weigh in on this.
If it does go ahead, I think we need to lock down the format of the extension. In the interest of keeping things simple, an integer that starts at 1 and increments by 1 for each new version would be best, I think. Is there a need to set a maximum value?
Also, since this is really a convenience feature, and version information can already be inferred from the GUID in the root in conjunction with message envelope information, we would need to specify what is the source of truth in the case of a discrepancy.

This was discussed at the last HL7 Community call and the proposed approach would be to change the definition of II.VER to add an optional extension property:

“displayable” property is permitted. “root” property is mandatory and must contain a GUID “use” property is mandatory and must be “VER” “extension” property is optional.

e.g. <id xsi:type=”II” specializationType=”II.VER” root=”64AC5370-D851-2D2F-2A18-78FBB73BFED9” use=”VER” extension=“201606071400”/>

Implementers who are satisfied with the current definition of II.BUS_AND_VER would could continue operating without using the new extension II.VER extension property.

Are there any thoughts from this group? People on the call seemed comfortable with this, but I wanted to bring that proposal here as this is where the most recent discussion originated. At this point, a formal RFC has not been created. We would need to have a better understanding of who would be looking to implement this change.

This is very interesting discussion. I am working with the DIS implementation and I don't see a need from the business prospective to support multiple versions of the same prescription. The back-end systems may store the point in time data offline or may to the audit/logging, when the traceability is required from legal prospective or when the system is tested, however I didn't see "versioning". It is not available for querying or otherwise. There are linked prescriptions, there are replaced prescriptions, but I didn't see the versions of a prescription. Is this a version of the CeRX? this is solved by other attributes of the message in the Transport wrapper. I agree with the community, multiple identifiers would be confusing for implementers.

Do we have a business case that describes a clear need for it? I would like to hear a business case or a problem that we are trying to solve to make a better suggestion about modifying the standard. or maybe what kind of new functionality it will allow us to enable for DIS systems? Thank you!

Kind regards,
Iryna

Yes. You'd have to move to the current RIM and the current structural vocabulary, though I don't think anything's been deprecated, so I'm not sure there'd be much of an impact other than the ability to use this new data element.

Hi Lloyd,

Would this approach (assuming such a proposal gains traction and is passed at Harmonization) not require the PCS materials to adopt the latest RIM?

We could propose adding a "version" element to the Act class. It would be consistent with what FHIR does, so it may get some traction from that perspective. The next harmonization meeting will be in July, so there's ample time to write up the proposal and socialize it.