At Karolinska University Hospital, we have just initiated a project with the goal of enabling openEHR-based primary documentation for multidisciplinary tumor board meetings in lung cancer care.
I have been in contact with @amanda.herbrand , who conducted a proof of concept to evaluate openEHR as a standard for data persistence in multidisciplinary tumor boards. But we are also interested to know if anyone else has worked on similar modeling projects. We would love to hear your experiences, thoughts, and ideas regarding MDTs
I will share our ideas, thoughts, and progress as we move forward with the project
There has been, and still going on, a cross-regional work in Norway regarding documenting cancer in general, including the Multidisplinary team meetings/boards. There should be a possibility to develop structures suitable for all types of cancer and across health service providers (âhospitalsâ), regions and countries. Most of the archetypes already exists.
For our MVP, we are focusing solely on the actual MDT meetings (lung cancer and solid tumors in childhood cancer). We have started identifying the information relevant to lung cancer MDTs (attaching an X-mind file) and have divided it into two main parts:
Information that serves as the foundation for determining the treatment strategy, i.e., information created earlier in the process.
Information that includes assessments (TNM classification, staging, etc.) and the recommended treatment strategyâthis is the information actually created during the MDT meeting.
I would appreciate insights regarding how to best handle the ârecommended treatment strategy.â
I have two main questions:
Is the ârecommended treatment strategyâ best represented as an evaluation or an instruction archetype?
Should this be a new archetype?
When looking at the âClinical Investigator Recording Process,â I find it challenging to determine whether the ârecommended treatment strategyâ fits better as an evaluation or an instruction archetype.
The information sometimes includes more detailed elements, such as dosage and frequency, which might suggest it being an instruction. However, this information is still in the form of a recommendation. And since it is merely a recommendation and not an actual instruction, evaluation might be a better choice. In fact, there is an existing evaluation archetype called ârecommendation,â which could have been appropriate, but it lacks slots for adding more detailed information.
I have reviewed the instruction archetype âService Request,â which includes relevant data elements and, from that perspective, could be a good archetype to use in this case. However, my understanding is that after the MDT meeting, once the ârecommended treatment strategyâ has been established, concrete requests will be madeâfor example, for surgery or medical oncology treatment. These requests then function as actual instructions. This might suggest that the âtreatment strategyâ itself is more appropriately categorized as an evaluation.
Hi Oscar! If the only reason EVALUATION.recommendation canât be used for this purpose is that itâs lacking a slot for âAdditional informationâ, Iâd suggest adding that slot. In fact, this is almost a standard slot in many new archetypes for generic clinical concept such as this.
If this makes sense to you, feel free to add a change request for this archetype to add the slot
Maybe I hadnât fully thought this through. The cluster archetype I would use to fill the slot would need to be a new archetype containing much, if not all, of the information regarding âtreatment strategy.â I suppose it doesnât really make much sense to use the EVALUATION.recommendation then. However, the INSTRUCTION.service_request, I believe, contains all the necessary data elements for treatment strategy. I just couldnât quite understand if the information should be categorized as EVALUATIONor INSTRUCTION. But maybe Iâm overthinking this? Iâm not sure I fully understand the consequences of choosing EVALUATION or INSTRUCTION.
Either way, it makes sense to have a slot in EVALUATION.recommendation
Quick reply as Im travelling. We definitely see this as needing some sort of summative evaluation. Evrn if this is partiallly executed via instructions and actions., the teatment plan itsrlf sits at a higher level. Eg the treatment plan will define the SACT regime but not individual dosages or specific schedules.
Recommendation coild work but so dar our understanding is that the content is really quite complex so we devised a specific treatment plan archetype which we will share. Wd could convert to a cluster but the recommendation wrapper would be very lean.
We had exactly this use-case in HiGHmed, some of these are outdated or need more love, we are still working on a backflow ( @Leo can maybe say more about this ) of some of the archetypes (genomics archetypes on the international ckm where e.g. done as part of this together with other members of the community CRS4 âŚ) .
Here is the template the colleagues did for the MTB recommendation itself maybe its of any help
I wasnât directly involved in the project myself, but there is such a project in the HighMed CKM. Feel free to reach out to me if youâd like to access it, or you can contact my colleague who was directly involved in the project. We modeled the MTB recommendation as an EVALUATION class. There is also an archetype available here: https://ckm.highmed.org/ckm/archetypes/1246.145.1454.
We have a very similar requirement coming up - which is an MTB recommendation for âGenetic cancer riskâ (usually on the basis of a tumour sample from an index case).
Iâd still definitely see this a some sort of Evaluation / recommendation and not an Instruction. So I guess it then comes down to whether there is any advantage to specialising/ extending the generic Recommendation archetype, or whether the MTB Recommendation(s) are so specific that a specialisation (or cluster extension) is not really that helpful.
