Stream: IPS
Topic: Role of Condition.recordedDate in IPS
Morten Ernebjerg (May 03 2021 at 06:53):
Looking at the Condition profile in IPS, I was somewhat surprised that although nine fields are declared must-support, recordedDate is not one of them. From my (admittedly quite basic) understanding, it is quite difficult to interpret the code in clinicalStatus (which IPS requires) without some sort of indication of when this status was asserted. and recordedDate seems to capture this most closely (albeit not exactly). Even if there is an onset date, it might not always help clarify whether the captured clinical status applies if it is not from the recent past (status may have been asserted long after onset). Also, if I read the IPS CDA IG correctly, the Problem Concern Entry there includes an effectiveInterval, for which the low value has this comment: "This element asserts when the concern became active. This equates to the time the concern was authored in the patient's chart and the author started tracking this concern." To me, that sounds like it would roughly correspond to the recordedDate element in FHIR ("when this particular Condition record was created in the system").
All in all, I would have expected recordedDate to be must-support in IPS (the, more targeted, IG from the German Medical Informatics Initiative even make it required). What was the reasoning behind not doing so?
Giorgio Cangioli (May 03 2021 at 07:37):
Hi @Morten Ernebjerg : MustSupport. The initially adopted rule for MS was the reference to the IPS data set (EN 17269/ISO 27269). That data set include the "Onset date" as Required if Known, and not the recording date.
Having said that,
(1) during the IPS calls we are now cleaning up the mustSupport flags (just ended with the IPS composition profile) so we will recheck also the Condition ones.
(2) it should be better understood the real capability of systems to correctly capture these data. In most real implementations of the CDA Patient Summary in Europe I noticed that the act.effectiveTime is filled either with exactly the same data of the observation or just nullflavored.
Morten Ernebjerg (May 03 2021 at 10:02):
Hi @Giorgio Cangioli Thanks for the update, sounds good.
act.effectiveTime is filled either with exactly the same data of the observation
I'm afraid I'm a little out of my depth w.r.t. CDA here, where does date (data?) of the observation map to in FHIR? Is it onset[x]?
Giorgio Cangioli (May 03 2021 at 10:13):
The mapping of the CDA act/observation structure it is not always so straightforward even if you consider the simple case 1 act with 1 observation ..
image.png
Morten Ernebjerg (May 03 2021 at 10:44):
Ah, I see. Do the :warning: -symbols for the status code and effective time for the Act mean that these cannot be/have not been mapped to FHIR?
Giorgio Cangioli (May 03 2021 at 10:50):
it just highlight the fact that the mapping doesn't seem to be so straightforward..but others may have different thoughts :-)
Morten Ernebjerg (May 05 2021 at 07:11):
OK, thanks! I'm getting to appreciate the non-straightforwardness of this :smile: (as evidenced by this other thread I opened).
Last updated: Apr 12 2022 at 19:14 UTC
