hl7ch / ch-emed

FHIR Implementation Guide which defines the documents for the exchange of medication information in the context of the Swiss EPR
https://fhir.ch/ig/ch-emed/index.html
MIT License
0 stars 1 forks source link

Differentiation List - Card? (Michaela Ziegler, ahdis ag) #140

Closed ziegm closed 1 year ago

ziegm commented 1 year ago

At the moment the only possibility (?) to differentiate LIST and CARD is Composition.title (if de/fr/it/en) when the LIST only contains a MedicationStatement. Should we consider providing a clear differentiation, as there are already use cases in practice that require this differentiation?

lpg-tech commented 1 year ago

The medication actually only needs the following documents:

  1. medication order Medication xy / timestamp beginning / timestamp end for each medication. It is the difference to current medication history. Important: a medication can be added ore removed (medication ends)
  2. medication history: automatically generated from the sum of medication prescriptions in the EHR.
  3. e-prescription: medication that the patient currently needs. Usually subset of medication list (6).
  4. medication dispensing
  5. feedback from pharmacist
  6. medication list: All medication prescriptions whose end date has not been reached; is equivalent to loinc.org#56445-0 "Medication summary". There are all medications that the patient should currently be taking.

Medication treatment plan corresponds to medication history (2) for a single medication, hence it does not need a separate document in my opinion

Wording is to discuss (list, card, order, prescription etc.), what matters are the meanings of the documents.

qligier commented 1 year ago

As discussed in #139, the document code is different in PML and PMLC documents.


Medication treatment plan corresponds to medication history (2) for a single medication, hence it does not need a separate document in my opinion

I'm uncertain whether I've understood your point, but the MTP document is much closer to 1 (a medication order from an HCP or a medication announce from the patient)

  1. MTP document
  2. PML document
  3. PRE document
  4. DIS document
  5. PADV document, but not limited to the pharmacist. Feedback can come from HCPs or the patient
  6. PMLC document
lpg-tech commented 1 year ago

Sorry, we have a different concepts. Why should we need a document that describes the medication history for a single medicament? We want to determine the temporal relationship between clinical symptoms/complaints and drug intake when we are looking for intolerances or allergies. This is a common question that should be able to be assessed comprehensively. For that reason the history should be complete and include all medicaments.

qligier commented 1 year ago

MTP, DIS and PADV are focused on a single medication, but PRE, PML and PMLC can include multiple treatments. What you're describing ("the history should be complete and include all medicaments") is typically the PML document.

ziegm commented 1 year ago
Composition.type.code Document LOINC SCT
LIST 56445-0 Medication summary 721912009 Medication summary document (record artifact)
CARD 56445-0 Medication summary 721912009 Medication summary document (record artifact)
PRE 57833-6 Prescription for medication 761938008 Medicinal prescription record (record artifact)
MTP 77603-9 Medication treatment plan.extended 419891008 Record artifact (record artifact)
DIS 60593-1 Medication dispensed.extended 419891008 Record artifact (record artifact)
PADV 61356-2 Medication pharmaceutical advice.extended 419891008 Record artifact (record artifact)
ziegm commented 1 year ago

Note: At the time of the initial creation of the profiles, only one coding could be mapped via patternCodeableConcept. The second coding was only represented in the examples. In the meantime this is possible (see example below), should this be added?

image

qligier commented 1 year ago

Ideally, we would find another LOINC code to distinguish between PML and PMLC and we would only use the LOINC variant, the SNOMED CT codes being the same for multiple documents, and then not so useful.

ziegm commented 1 year ago

Medication List document and Medication Card document are both based on PML as described in the document tabs. IHE Pharmacy Technical Framework Supplement: Community Medication List (PML)

PML defines the following codes:

Document code: 56445-0, LOINC, Medication summary (CH EMED: Composition.type)

ziegm commented 1 year ago

10.11.2022 Telco PJ/OE/MZ: @pjolo Anderer Code (LOINC/SCT) für LIST Wir haben keine möglichen Codes bei LOINC oder SCT gefunden, ist es möglich einen Swiss Extension SCT Code zu erstellen? Medication List document: Dokumentenbeschreibung (noch ausstehend)

Profil: nur ein Code verlangen (für LIST dann von LOINC auf neuen SCT wechseln)

pjolo commented 1 year ago

After internal discussion. A new code for Medication Card will be added. The proposed code is Medication Plan. In order to reach a quick introduction, the code is proposed for SNOMED International. This means that the code will be introduced around March. If the code is rejected by SNOMED International, the code will be included in the Swiss Extension. As the Swiss Extension is currently frozen for the release, the code could not be included until the summer of 2023.

qligier commented 1 year ago

Thank you Patrick! At what time could we have an idea of the actual code value that would be introduced?

pjolo commented 1 year ago

I think we will have a first proposal by March

qligier commented 1 year ago

Wait, proposed to SNOMED?

The current issue the spec has is that, when you get a CH-EMED document, it's hard to determine of which type it is. The meta.profile is optional and can contain anything, the Bundle doesn't contain anything useful and the Composition only has a type with 3 unique values for 6 document types. We should have one unique Composition type per document type, and it cannot be done by adding one code to SNOMED, but adding one code to LOINC.

So what's the plan here?

qligier commented 1 year ago

More information about why I react to adding a new value to SNOMED CT in #178, I hope it's more clear now.

ziegm commented 1 year ago

Telco 12.01.2023 PJ/QL/OE/MZ: The proposed solution is still fine.

pjolo commented 1 year ago

I have looked at this issue again with Pero. He made me a proposal which only SNOMED CT codes are used for LIST,CARD,PRE,MTP,DIS and PADV:

Document SCT
LIST 721912009 Medication summary document (record artifact)
CARD 736378000 Medication management plan (record artifact)
PRE 761938008 Medicinal prescription record (record artifact)
MTP 761931002 Medication treatment plan report (record artifact)
DIS 294121000195110 Medication dispense document (record artifact)
PADV 423016009 Clinical statement entry (record artifact)

@ziegm, @qligier: Are the defined codes for you ok?

qligier commented 1 year ago

For PADV documents, I am unsure if changing from Record artifact to Clinical statement entry is a good idea. Otherwise it seems good!

But, since this code is used as DocumentEntry.typeCode, the codes 736378000, 761931002, 294121000195110 (and 423016009?) should be added to the value set DocumentEntry.typeCode (beta version). Would that be OK with Pero?

ziegm commented 1 year ago

Thanks @pjolo for the suggestion and @qligier for the feedback! I fully agree with Quentin's feedback.

ziegm commented 1 year ago

@pjolo any updates on this topic?

pjolo commented 1 year ago

@qligier @ziegm Why do you think that the change from Record artifact to Clinical statement entry is not a good idea? For me it is not a problem we can leave it on Record artifact. So we would have the following codes:

Document SCT
LIST 721912009 Medication summary document (record artifact)
CARD 736378000 Medication management plan (record artifact)
PRE 761938008 Medicinal prescription record (record artifact)
MTP 761931002 Medication treatment plan report (record artifact)
DIS 294121000195110 Medication dispense document (record artifact)
PADV 419891008 Record artifact (record artifact)

Pero will add the codes this afternoon in the value set DocumentEntry.typeCode (beta version)

qligier commented 1 year ago

Because a PADV can be issued by a patient or a pharmacist, they don't issue "clinical statements". Also, I'm not sure a GP is considered a clinical environment. For these reasons, "Record artifact" is a more fitting code, although overly generic.

ziegm commented 1 year ago
Composition.type.code Document LOINC SCT
LIST 56445-0 Medication summary 721912009 Medication summary document (record artifact)
CARD 56445-0 Medication summary new: 736378000 Medication management plan (record artifact)
PRE 57833-6 Prescription for medication 761938008 Medicinal prescription record (record artifact)
MTP 77603-9 Medication treatment plan.extended new: 761931002 Medication treatment plan report (record artifact)
DIS 60593-1 Medication dispensed.extended new: 294121000195110 Medication dispense document (record artifact)
PADV 61356-2 Medication pharmaceutical advice.extended 419891008 Record artifact (record artifact)

-> those in bold are listed in the profile as patternCodeableConcept

@pjolo @qligier Should we change the code system for the required type code for both documents (CARD/LIST) with the same LOINC code to SCT? I think the differentiation would be clearer.

@ziegm For me it is ok to change to SCT for both documents with the same LOINC code and so the differentiation is clearer.

qligier commented 1 year ago

LIST: change patternCodeableConcept to SCT code instead of LOINC in profile

Does that mean the patternCodeableConcept would be on LOINC codes for MTP, PRE, DIS and PADV, and on SCT for PML and PMLC? Maybe we should set the SCT codes as primary ones for all types here, and add the LOINC codes as translation?

ziegm commented 1 year ago

Sorry, I've caused a bit of confusion here. I've looked again, in the versions published so far we've used SCT in patternCC for all documents and LOINC in the examples in addition. I will adjust that accordingly, that we continue to do so.

ziegm commented 1 year ago

@pjolo @qligier please review the changes: Changes for Composition.type (see ci-build):

qligier commented 1 year ago

I can't find 294121000195110 in the SCT browser, is it a new Swiss extension? If so, should we apply #224 to it now?

ziegm commented 1 year ago

I guess it will be in the next release (@PeroGrgic )? I'm working on #224

PeroGrgic commented 1 year ago

Hi, 294121000195110 will be in the next release of the Swiss extension.

ziegm commented 1 year ago

Hi, 294121000195110 will be in the next release of the Swiss extension.

When is the next release planed?

PeroGrgic commented 1 year ago

The next release is on the 7th of June.

pjolo commented 1 year ago

The adjustments are good