Report RAA10 Tvangsforanstaltning, item RDA98

[Dkuzmins]

We are facing a problem right now with the report RAA10 Tvangsforanstaltning

In the Report specification document Result RDA98 “seneste behandlingdato” says it has to be date with format yyyymmdd

In LPR3 Document VEJLEDNING TIL INDBERETNING TIL LANDSPATIENTREGISTERET (LPR3) v1.2. chapter 14.5.1. it says "Most recent treatment date (hours, minutes, seconds can be sent as 00)"

We talked with clinicians and checked the law text and both sources say that only date has to be documented, however during integrated testing we figured out that SDS expects us to send instant in date and time format.

Could you please provide some clarity on what data exactly SDS is expecting us to send? Should it be only date? If yes, what should be the format? (ddmmyyyy, yyyymmdd etc.) If it should be date and time together, than once again what should be the format (ddmmyyyy HH:MM:SS, ddmmyyyy HH:MM)

[jonigkeit]

This issue has an impact on #164 and the DK CDA Header.

[jonigkeit]

We will need to meet with relevant authorities SDS and MedCom to resolve conflicting requirements.

[TueCN]

FYI: Currently, the Drools rule RAA10.RDA98-1 on the test environment expects the date to be formatted as a DK Medcom Timestamp, which has the format YYYYMMDDhhmmss±ZZzz

You can set the hhmmss as you wish, just be aware that LPR converts the datetime to the Europe/Copenhagen timezone, which might change the date.

[Dkuzmins]

The field “Seneste behandlingsdato” is the date until the decision to apply coercive measures is valid (basically the duration of decision from now). According to Patient’s safety regulation it shouldn’t be longer than 4 months and clinicians would document it as a date (without hours, minutes and seconds). We think it makes sense to get back to SDS and ask them to revise the requirement to have this item as an instant, because: • It makes more clinical sense • Users document it in flowsheet rows which could have a data type of Date or String in SP which violates RMIM-009 Could you liaise with SDS on this matter?

Thanks

[jonigkeit]

RESOLUTION We're introducing a new timestamp with the precision of a day and the literal form YYYYMMDD±ZZzz.

Until then you can send it in the orignal medcom format YYYYMMDD000000±ZZzz zeroing out hhmmss.

[jonigkeit]

Regarding RMIM-009, see #164.

[Dkuzmins]

Christian, What does ±ZZzz stand for in this case? Is it Hours/Minutes offset from UTC?

[jonigkeit]

@Dkuzmins see HL7 Implementation Guide for CDA Release 2.0 CDA Header, Draft for Trial Use, Release 1.1, November 15th 2017, section 4.4

[Dkuzmins]

@jonigkeit

The document you are referring to says:

"The representation of time SHALL use the format YYYYMMDDhhmmss±ZZzz" where ZZzz is HHmm offset from UTC

But what about new timestamp format YYYYMMDD±ZZzz you mentioned in your previous post? Why do we need an offset from the date?

[jonigkeit]

Suppose you registered two events

• Event a December 12th 2018 in Greenland, that would be 20181212-0300
• Event b December 12th 2018 in Denmark, that would be 20181212+0100

Now you want to answer the following question which of the events did not happened December 13th 2018 Danish time?

The answer is b.

So specifics matter.

[Dkuzmins]

@jonigkeit do you have an estimate when this new timestamp will be introduced? If you don't have an exact date, do we know if it will be before Feb 2?

[EsbenHenrichsen]

In region Hovedstaden we need a fix asap. This is blocking test cases and we can not wait until 2. feb for a fix. First week of january at the latest, then it may cause delays for the program in RegH.

[EsbenHenrichsen]

Could someone please give a status on this? Is there a solution and when are we able to continue testing in Region Hovedstaden?

[EsbenHenrichsen]

We still do not have a solution.

Risk eskalated to steering @ SDS

[KirstenLHSDS]

Status will be validated with DXC. Transfered to LPR backlog