Versioning in the Forløbselement GUI is not working properly

[HanneRegSyd]

Versioning in the Forløbselement GUI is not working properly - See at attached document.

[jonigkeit]

Hi @HanneRegSyd There is no attached document

[HanneRegSyd]

Versioning in the Forløbselement GUI is not working properly.docx

[HanneRegSyd]

It is attached now.

[HanneRegSyd]

It is attached now

[HanneRegSyd]

This problem seems to to be the same as issue 284.

[TueCN]

Hi Hanne. I will try and answer your questions. I am quoting your issues from the attached word document.

1

The version number does not match the vision inside the CDA element

The version number in the GUI is not taken from the input CDA document. In CDA, version numbers can be negative numbers, do not have to start with 1 and do not need to only incremet by 1. The version numbers displayed in the GUI always begin with number 1 and increment by 1 for each new version.

Also note, as explained on https://github.com/scandihealth/lpr3-docs/issues/284#issuecomment-459681808, versions can be generated from other actions than submitting CDA documents (e.g. an LPR administrator executing a "Genvalidering" of the "Forløbelement" - which generates a new version with the same CDA data, but possibly different validation errors)

---

2

Your file version #1 on the 11-12-2018 is not a file we have sent to you – and it seems like you have made the file yourselves?

Due to an internal data model change in test, we "reset" our history data the 11-12-2018 which meant that all history data was dropped and the current active version of each record at the time became version #1. This explains the observation you outlined in your table

SDS CDA file datetime	RSYD CDA file datetime
????	#1 06-12-2018 15:05
????	#2 07-12-2018 08:34
????	#3 07-12-2018 09:41
????	#4 07-12-2018 10:43
#1 11-12-2018 00:00:00	????
#2 17-12-2018 22:24:53	#5 17-12-2018 22:24
#3 19-12-2018 11:43:18	#6 19-12-2018 11:43

We have not planned any more history data purges.

---

3

When using “Hent råfil” you always get the latest version

This is a bug. We will fix this when there are no other issues with higher priority.

[HanneRegSyd]

Hi We also have the problem in production. Is there is a time horizon for correction of this error?

[TueCN]

Hi, sorry for the late reply. A fix for this issue was actually delivered to production with version 3.8.867 on March 27.

RESOLUTION Pressing "Hent råfil" button now always downloads the CDA XML that caused the specific version update, instead of downloading the latest CDA XML that contained the episode of care itself

However, the fix is not retroactive. Meaning, only submissions from March 27 and forward will yield the correct CDA XML when pressing "Hent råfil" button when viewing a previous version of the episode of care.

Note

• No XML data has been lost. All CDA XML has been stored in the database also prior to March 27, however the way that an XML document is linked to the correct Episode of Care version was only fixed March 27.
• It can take a very long time to open a previous version of an episode of care (upwards to 5 minutes or more, depending on the size of the database). Unfortunately the UI does not have a "loading..." indicator that shows the data is being fetched, instead the UI will simply update when the data is ready. We may add a loading indicator at a later time.
  • Currently the time out value for all GUI operations is set to 1 minute in TEST and PROD. This will be updated to a much higher value during next service window. This means that a time out can happen before the previous version can be fetched. Unfortunately the time out error for opening a previous version is silent on the UI and can only be seen by activating developer console in the browser.

[KirstenLHSDS]

Expected to be resolved. Otherwise please report to SDS Servicedesk.