search

hl7-eu / eps

HL7 Europe Patient Summary FHIR Implementation Guide
Creative Commons Zero v1.0 Universal
1 stars 0 forks source link

header.documentData.lastUpdate - check mapping #2

Open costateixeira opened 1 month ago

costateixeira commented 1 month ago

https://build.fhir.org/ig/hl7-eu/eps/ConceptMap-patientSummary2FHIR.html header.documentData.lastUpdate - what is the meaning - so that we can confirm the mapping. 

mgraauw commented 1 month ago

Here is the Zulip chat on meta.lastUpdated for a "last update" time on Patient Summaries which I mentioned today. Was not deemed the right choice. Looking at Meta.lastUpdated, it refers to HTTP Last-Modified (should be the same value on GET) and that is: "The Last-Modified response HTTP header contains a date and time when the origin server believes the resource was last modified" - so this is not a clinical relevant timestamp.

The eHealth dataset says: "Date on which PS was updated (date of most recent version)"

I think for an I/ePS this is a problematic notion anyway, since it is unlikely that the PS is maintained as a FHIR document. If the PS is generated from an EHR database, the date of last update should be the same as the creation date, since at the moment the PS is generated from the database, the Composition is generated and that certainly is an update to the FHIR document. So I suggest no using meta.lastUpdated (the other proposal, careProvisioningEvent, I haven't looked into that).

Even if means "the date this patients record was last updated in the source system" (i.e. a potentially clinical relevant datetime) its meaning is vague - if say one allergy was updated by a doctor, but none of the other content, would that be the "last updated" datetime? That is possible but this datetime says nothing about the up-to-dateness of the rest of the content.

This even leaves aside the possible generation of an PS from multiple sources, which may very well be the case in the Netherlands for cross-border. In the Netherlands we may go for a similar datetime per resource, so a "last updated" on each allergy, problem etc. (maybe using Provenance).

costateixeira commented 1 month ago

Not sure I understand the issue. I see the ePS (at least definitely the IPS) to be a FHIR Document, so the last updated is the time when that document (version) was last updated. Not the content. The content can be as old and up-tp-date as a vaccination 40 years ago or a recent headache. The date of patient record last updated and the date of e/IPS last updated are two completely different dates, because the IPS is not a patient record. it is a snapshot authored by a system and/or person at a given time. In a document, I don't know if we need another element like "date/time the source was last known to be updated" Each resource can have of course its own last updated date, but that doesn't conflict with the date of the document. I haven't seen all options in composition, but if needed we also have this https://build.fhir.org/ig/HL7/fhir-extensions/StructureDefinition-artifact-date.html

mgraauw commented 1 month ago

I agree that adding another element like "date/time the source was last known to be updated" isn't useful on a document level.

My point is that if a FHIR PS is generated and exchanged (which it nowadays usually is), documentData.lastUpdate adds nothing to documentData.created (they should be the same, or the lastUpdate (0..1) could be omitted).

If the patient data is changed, one would probably simply generate a new FHIR PS, and exchange that, and not "update" an existing FHIR PS. In which case there would be a new documentData.created for the newly generated FHIR PS.

In the rare cases where a FHIR PS is generated, altered and then exchanged, one might populate documentData.lastUpdate.

The IG could reflect that: don't populate lastUpdated when generating a FHIR PS, just use created.

When looking further, it gets even murkier:

This suggests that when a Composition is created and changed, .date is the date of change, not of creation. Meaning that in such a case documentData.lastUpdate should go into Composition.date and there is no place for documentData.created anymore.

mgraauw commented 1 month ago

I'm retracting what I said before. Looking at what Documents says about dates in a Doc bundle it's quite clear the mappings should be documentdata.created -> Composition.date and documentData.lastUpdate -> Composition.meta.lastUpdated.

gcangioli commented 1 month ago

In my understanding "The Composition last modified time (optional)." refers to the last update of the Composition as resource managed by a specific HL7 FHIR Server. Not sure than moving one resource from one serve to another you can assure that the meta data are preserved.

The basic question is what is the meaning of the last update. Looking at the ISO 27269 this is even more ambiguous #4 Date of last update to IPS content The content of the IPS may have variable dates of update or change.

So the question is do we want to capture:

  1. when the composition has been updated;
  2. how much the information used by this PS are updated (the time span this PS is covering. I can create today the PS but it documents data updated 1 month ago)
  3. other things