-
Notifications
You must be signed in to change notification settings - Fork 0
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
Comments
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). |
Not sure I understand the issue. |
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. |
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. |
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 So the question is do we want to capture:
|
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.
The text was updated successfully, but these errors were encountered: