Address EPRTime extension usage about ch-emed-epr HOT 12 CLOSED

OK, thanks! But that is inherited from CH Core, and therefore shown in the Snapshot Table. We can't change anything in the CH EMED IG. If we do not have the Extensions somewhere described or used in the examples, I would suggest to leave it as it is, because that's the way IG dependencies work.

from ch-emed-epr.

I will propose the equivalent changes to CH-EMED and depending on the feedback we might just wait for the changes to be done upstream. Otherwise and again depending on the feedback, we might just implement these in CH-EMED-EPR or change to align to any other proposed solution by CH-EMED.

from ch-emed-epr.

We have removed the ch-ext-epr-time extension in hl7ch/ch-emed#165 because it seemed of limited usefulness at the time.
What is the use case for the authorship timestamp? What is the difference with the document creation time?

from ch-emed-epr.

For PML and PMLC, we are not providing the documents or compositions themselves, so it is a way of specifying the time of authorship, otherwise not present anywhere. This is needed for PDF generation and I guess useful information to have in PML documents as well. Keep in mind authorDocument is optional, so its timestamp might not be present either.

For the provided documents, its usefulness is indeed arguable, but the extension is already there (0..1) for the composition.author so I thought it would be coherent to have it, also optional, on the section author, in case a different timestamp can be specified for the medical authorship. The PMP code will treat these optional timestamps as follows:

• the entry's document authorship will be the composition.author.time if specified, otherwise the document's timestamp.
• the entry's medical authorship will be the composition.section.author.time if specified, otherwise the document authorship's timestamp as resolved above.

from ch-emed-epr.

For the provided documents: the Composition.date is described as when the author wrote the document logically. Is it really different from the time of authorship?

For the PML/PMLC documents: the items have datetime fields that could cover that use case too, e.g. MedicationStatement.dateAsserted or MedicationRequest.authoredOn. Could that be enough?

from ch-emed-epr.

For the generated documents, yes I also thought about the possibility of using those fields but after discussing it with Stéphane, but:

• Those elements are already supported in the provided documents, with the exception of the MedicationStatement.dateAsserted, if we are going to use these fields in the generated documents, then we need to either also specify that they are not supported in the provided docs as already done with the MTP doc or we add rules to ensure they match the document timestamp if we go for "there is only one authorship timestamp" per bundle. This is not a big issue, it could be done.
• At the moment, things have been done so that we use authorship information from the composition only, hence the removal of support for the author fields in the entries and the use of composition.author and composition.section.author as specified in the ch-emed guidelines. We thought it was coherent to keep this the same. Since composition.author and documentAuthor have explicitly the time extension in the ch-emed specs we thought it was natural to do the same with the medical author fields.
• We do not know if any of the other fields might have a meaning not necessarily tied to authorship, i.e. "whenHandedOver". Although we could assume they can be used for authorship timestamp.
• Regarding if we should make a difference between document authorship timestamp and medical authorship timestamp, it seems that since the moment you might have both, their timestamps might be different and hence should be recorded (if different), otherwise why have a time extension in composition.author and documentAuthor at all? Furthermore, our understanding of the profiles, e.g. https://www.ihe.net/uploadedFiles/Documents/Pharmacy/IHE_Pharmacy_Suppl_MTP.pdf is that even if the author itself is the same, differences in timestamp between the document authorship and the medical authorship could exist and should be supported.
  

Please let me know if you think I am forgetting or missing the point over something.

from ch-emed-epr.

Feedback from professionals on whether the timestamp of the medical authorship is relevant or not is needed.

from ch-emed-epr.

@dvribeira where did you find the still used extension in ch emed?

from ch-emed-epr.

In the author slices of all the stable document compositions:

For PML composition:

• in dataEnterer:
  
  
• in author:
  

For PMLC composition:

• as for PML composition, in dataEnterer
• as for PML composition in author

For PMLC CHEMEDMedicationStatementCard:

• in authorDocument:
  
  

from ch-emed-epr.

Understood.

In the meantime, the [meager] professional feedback we have had so far is that the two timestamps (document authorship and medical authorship) should be kept. If the policy is to avoid using the time extension, then the only choice without further altering the IG structure is to use the following fields:

• MTP:
  • document: CHEMEDEPRCompositionMedicationTreatmentPlan.date
  • medical (if present): CHEMEDEPRMedicationStatement.dateAsserted (currently flagged as not supported, flag should be removed)
• PRE:
  • document: CHEMEDEPRCompositionMedicationPrescription.date
  • medical (if present): CHEMEDEPRMedicationRequest.authoredOn
• DIS:
  • document: CHEMEDEPRCompositionMedicationDispense.date
  • medical (if present): CHEMEDEPRMedicationDispense.whenHandedOver
• PADV:
  • document: CHEMEDEPRCompositionPharmaceuticalAdvice.date
  • medical (if present): CHEMEDEPRObservation.issued
  • CHEMEDMedicationStatementChanged:
    • document: CHEMEDEPRCompositionPharmaceuticalAdvice.date
    • medical (if present): CHEMEDMedicationStatementChanged.dateAsserted
  • CHEMEDMedicationRequestChanged:
    • document: CHEMEDEPRCompositionPharmaceuticalAdvice.date
    • medical (if present): CHEMEDMedicationRequestChanged.authoredOn
• PML:
  • CHEMEDEPRMedicationStatementList:
    • document (if different from medical): ? should we use the time extension on documentAuthor?
    • medical: .dateAsserted (currently flagged as not supported) (cardinality should be changed to 1..1)
  • CHEMEDEPRMedicationRequestList:
    • document (if present): ? should we use the time extension on documentAuthor?
    • medical: .authoredOn (cardinality should be changed to 1..1)
  • CHEMEDEPRMedicationDispenseList:
    • document (if present): ? should we use the time extension on documentAuthor?
    • medical: .whenHandedOver (cardinality should be changed to 1..1)
  • CHEMEDEPRObservationList:
    • document (if present): ? should we use the time extension on documentAuthor? otherwise no field available
    • medical: .issued (cardinality should be changed to 1..1)
    • CHEMEDMedicationStatementChanged:
      • document: not provided, use CHEMEDEPRObservationList's if provided.
      • medical: .dateAsserted (we use the same profile as for provided PADV entries, is splitting it worth it just to specify 1..1 cardinality?)
    • CHEMEDMedicationStatementChanged:
      • document: not provided, use CHEMEDEPRObservationList's if provided.
      • medical: .authoredOn (we use the same profile as for provided PADV entries, is splitting it worth it just to specify 1..1 cardinality?)
• PMLC:
  • CHEMEDEPRMedicationStatementCard:
    • document (if different from medical): ? should we use the time extension on documentAuthor? otherwise no field available
    • medical: .dateAsserted (currently flagged as not supported) (cardinality should be changed to 1..1)

Consequences:

• Authorship information on provided documents is now split between composition and entry.
• PML and PMLC entries lack a document authorship timestamp field unless using the time extension on documentAuthor, but is the document authorship timestamp relevant here? It is stored with the documents and available upon request, would this suffice?

from ch-emed-epr.

This is now somehow related to this open issue on CH-EMED: hl7ch/ch-emed#241

from ch-emed-epr.

Dealt with by changes to authorship to CH EMED and integrated with #39

from ch-emed-epr.