Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

header.documentData.lastUpdate - check mapping #2

Open
costateixeira opened this issue Oct 18, 2024 · 5 comments
Open

header.documentData.lastUpdate - check mapping #2

costateixeira opened this issue Oct 18, 2024 · 5 comments

Comments

@costateixeira
Copy link

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
Copy link

mgraauw commented Oct 18, 2024

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
Copy link
Author

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
Copy link

mgraauw commented Oct 18, 2024

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:

  • in the LM-to-Composition mapping .documentData.created is mapped to Composition.date, comment: "if it is the date of creation of this document"
  • but Composition.date is "The composition editing time, when the composition was last logically changed by the author."

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
Copy link

mgraauw commented Oct 19, 2024

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants