# Refreshing archetypes related to pathology reporting **Category:** [Clinical](https://discourse.openehr.org/c/clinical/5) **Created:** 2022-02-23 15:21 UTC **Views:** 2788 **Replies:** 87 **URL:** https://discourse.openehr.org/t/refreshing-archetypes-related-to-pathology-reporting/2393 --- ## Post #1 by @erik.sundvall Hi! @heather.leslie, @SDubois, I and others have exchanged som emails regarding refreshing archetypes related to pathology reporting and agreed it would be better to continue (and repeat some of) the discussion here on discourse so that more people can join. **Starting question:** What is the status of the project [Pathology Synoptic Reporting](https://ckm.openehr.org/ckm/projects/1013.8.19)? **Background:** Several pathologists in Sweden are interested in shared development of structured data entry form parts for the pathology investigation and reporting process. A Swedish proof of concept (PoC) project is currently investigating how an openEHR CDR (EHRbase) can be used as a shared read/write-documentation hub for pathology lab systems (from TietoEVRY) and digital imaging/analysis/PACS systems (from Sectra) and possibly EHR systems. A national cancer registry is also involved in the project. During this work e.g. both @SDubois and @elham2222 found things that could be improved in the current set of related archetypes. For examle Stefan posted a mindmap at [https://ckm.openehr.org/ckm/archetypes/1013.1.386/resourcecentre](https://ckm.openehr.org/ckm/archetypes/1013.1.386/resourcecentre) with parts colleced from different international reporting projects. --- ## Post #2 by @heather.leslie Erik asked me to post my email response... The Pathology Synoptic Reporting project is ancient (2009) and the models are likely to need considerable revision, given pattern evolution since they were drafted and in unfinished review limbo. We could/should consider setting their status to rejected - to discourage active use and create a clean slate to work on reimagining the domain and patterns without being unduly influenced by the existing work. They can still be found with CKM when searching for archetypes in the ‘rejected’ state if we need them for reference. Then we can rejuvenate the Project name/metadata etc for our purposes. Stefan’s work, plus others who seem to be working in the area in India etc, will be integral to due diligence on the ‘whole of domain’ that will allow us to distil the clinical concepts and repeating patterns that will inform the archetype design. This is potentially a massive project – even to limit scope to one or two cancers requires a deeper and broader investigation to ensure that we have a plan that can cater for future additions. (At least as best we can do without a crystal ball). There is definitely an ‘art’ to deciding how deep and broad we need to go before doing the deep dive design for one cancer. The OBSERVATION.lab_test_result was designed to be the anchor and generic framework for all lab-related modelling. The current anticipated pattern will require devising a ‘histopathology/anatomical pathology’ framework as a core/universal CLUSTER to nest inside the OBS. This will support more detailed CLUSTERs of the nature that exist in the existing project. I suspect we will revise the concepts considerably if we cast a wide lens on the variety of histopathology reporting requirements, and the new CLUSTERs will be required. You can see a parallel family of genomics archetypes and example templates, designed on these same principles, here: https://ckm.openehr.org/ckm/projects/1013.30.50 The same archetype design pattern is intended for modelling microbiology, serology, cytology etc. subdomains within the Lab test result family – a core framework CLUSTER for each subdomain, that will carry more CLUSTERs containing the specific details. This pattern is also underpinning the Imaging result family of archetypes. Stefan and other domain experts can guide us, but I would imagine using https://documents.cap.org/documents/synoptic_reporting_definition_examples_v4.0.pdf , or similar, as the basis for the histopath framework CLUSTER to ensure that we get the core reporting framework as standardised as possible. Then we can hopefully discern modelling patterns across all cancers, also considering that lymph nodes and metastases and details such as resection margins etc should be good candidates to model for broad reuse across all cancers. I’m sure it is much better to continue this discussion on Discourse. My concern is that there are a number of people who have already been working in this area, without understanding how to align with these patterns and we need to create a forum to bring this work into one central communication collaboration (ie at announcement/major communication) point. Slack, or similar, may be better for daily/weekly working interaction. Just thinking out loud. All thoughts welcome. Editors/CKAs need to help shape this, but we can support you to drive the detailed design and reviews if you’d like. Cheers Heather --- ## Post #3 by @erik.sundvall This was discussed again in the Swedish project and we've got some pathologists willing to help and will also look into funding of some consultancy hours from international archetyping experts. We'd suggest trying to create a first verison of a general cluster archetype to be used together with a first specific cluster archetype for at least the "micro" part of breast cancer. Then a second specific cancer "micro" archetype could be added and/or heading over to the "macro" part of breast cancer. Who else in the openEHR community would be interested in getting this started? --- ## Post #4 by @heather.leslie I agree that designing a generic micro and macro examination findings would be a really valuable starting point. It will take quite a bit of research/investigation to discern the common patterns from amongst the variations across the common use cases. However I find it is usually worth putting in the effort in the beginning as it means the review process is more a refining than redesigning. I'd be interested to participate... Cheers Heather --- ## Post #5 by @erik.sundvall An update from Swedish pathology work: There has now been some serious (non-openEHR) modeling work done regarding breast cancer in Sweden (e.g. concept- and information-models) by @sanna.asberg, @LindaAulin and others. Karolinska University Hospital has been asked to see if/how that can be represented in openEHR so that the coverage and usefulness can be tested/evaluated using e.g. openEHR template based forms. For a first (too tighly time-limited) proof-of-concept (POC) version we'll likely have to include the "paused" [openEHR-EHR-CLUSTER.microscopy_breast_carcinoma.v1](https://ckm.openehr.org/ckm/archetypes/1013.1.381) archetype and some other not so stable/finished or homegrown archetypes, but we hope that we via the POC can feed some comments back and gain experience regarding what would be gereral vs specialiced for different cancers. (sterting with breast cancer). Some of that division/generalisation has already been considered in the national (non-openEHR-based) work. We'll get back with info here when we have something more to share. Meanwhile it would be interesting to hear about similar work being done elsewhere. --- ## Post #6 by @ian.mcnicoll Definitely, There is work in Wales @johnmeredith and other places on the same track @varntzen @bna see https://discourse.openehr.org/t/cancer-treatment-in-general-particle-therapy-omop-digione-european-particle-therapy-network/3599/9?u=ian.mcnicoll Personally I would start at the other end @Erik and work down from a broad pattern for anatomic pathology, which is largely understood but which we have never formally agreed on. Then tackle some other generic pattern issues - how to do staging in a way that works for both national reporting and MDT support. That may help guide patterns around direct invasion, tumour margins etc. After that the very detailed requirements that are e.g. unique to Breast cancer microscopy will fall out naturally. Or perhaps a twin track - one to see how much the clinical requirements for microscopy still line up internationally (essentially a clinical exercise) vs. the work above which is really more informatics. --- ## Post #7 by @erik.sundvall Yes @ian.mcnicoll working from the "broad end" would be our preferred way too, but I suspect we'll have to do things partly in the "twin track" way in order to get our first POC verison out in time. Then we'll want to iterate towards more generic patterns when there is some international consensus (hopefully before filling our CDR with real patient data based on this). We hope to be able to contribute a bit to that consensus at the same time as POC:ing. --- ## Post #8 by @mar.perezcolman Hello everyone, My name is Marlene, I'm fairly new to the community so I have tons of questions and no answers, but I would like to collaborate with your project @erik.sundvall. I am currently working in Wales where we are also trying to model our 'Cancer Datasets' for reporting and we have come across the same difficulty that you have. Currently, we have created a generic cluster archetype for microscopy details and we are trying to get it into the best shape possible but we know we re working based on a reduced number of cancers at the moment, and might need expansion. I don't know how to share the archetype here to see if it could be a starting point. I looked at the mind map, and I was wondering if you were planning on creating a specific cluster for each tumour site or build a generic and plug in smaller clusters with very specific details? As well, I see that you have included bilateral as a laterality, which isn't in the openEHR laterality archetype. How are you handling that? Out of what we have analysed, there are two points that we have identified as most challenging. First is the differentiation between solid tumours and haematological tumours as these have different pathology, location, staging, treatment. etc; the other are sarcomas, which can also be located anywhere and their classification varies. These also happen to be the most frequent tumours in childhood. Have you done any specific work on either of these? From a pathological point of view, would it make sense to have Elements for nucleic markers, cytoplasmatic markers, etc. to be able to reuse a generic cluster with whichever tumour? In our model we have used 'runtime constrains' for nuclear expression, but it might be 'extendable' for other uses. As well, we are starting to do some work on tumour progression/metastasis (including lymph nodes)/transformation. Regarding this, it would be interesting to discuss if that 'classification' would need to be done at a higher-level archetype and then reuse the same microscopy clusters under that heading, or if it warrants a separate archetype to record how it was detected, when, etc. Thanks for attaching: [Clinical Knowledge Manager (openehr.org)](https://ckm.openehr.org/ckm/projects/1013.8.19). @ian.mcnicoll knows of our struggles :joy:. It would be amazing to work on this together to align how we record this. Thanks, Marlene --- ## Post #9 by @ian.mcnicoll Welcome Marlene, Good to see you here!! To make your work visible , there are a couple of things you can do... 1. Just upload an archetype exported as adl. nTHe only issue here is that people cannot easily visualise it. 2. Send a link to the archetype or template from AD using the share button to the left of te archetype or template name ![image|690x324](upload://6vXHVNMxXxizNpxiqP4DpuW5VO6.png) THis allows you to share a read-only view e.g.https://tools.openehr.org/designer/#/viewer/shared/Pz9zaGFyZWRJZD0xJGQ4NTg0MmRjNGFjYTQzOTliYjVjMGFjZWMwOWZkM2Iw @erik.sundvall - Perhaps we could setup a shared Github repository and associated documentation? --- ## Post #10 by @mar.perezcolman Hi all, Hope this helps: [openEHR-EHR-CLUSTER.microscopy_dhcw.v0.adl (github.com)](https://github.com/marperezcolman/cancer-dataset-sections/blob/1/local/openEHR-EHR-CLUSTER.microscopy_dhcw.v0.adl) I cannot share it that way, I guess because we are using GitHub, but that is the link to the repository. And this is a screenshot of the model so far: ![image|415x500](upload://iwoHERN4h7Lva6yqfPZsEuHxWqB.png) These are the current runtime constrains: ![image|662x500](upload://iiHwPVzi9HOyfN2cOtal7W8gvlL.png) And this is the adl: [openEHR-EHR-CLUSTER.microscopy_dhcw.v0.adl|attachment](upload://peCsLrs5iLRzecZziJ02IDlzhwN.adl) (6.0 KB) Cheers, Marlene --- ## Post #11 by @Maurice247 Hi Marlene, Thank you for sharing. I noticed you created a Cluster Archetype from scratch. I found this archetype: https://ckm.openehr.org/ckm/archetypes/1013.1.2881, which might be suitable for IHC - Its purpose is: "To record a single value laboratory analyte result, commonly found in clinical pathology testing." The new archetype could be named for instance "MLH1 nuclear expression", each IHC would be an archetype and these could be clustered in for instance "Immunohistochemistry results" and added to the respective Microscopic finding e.g. https://ckm.openehr.org/ckm/archetypes/1013.1.381. Since I am new to openEHR as well, I would appreciate feedback from the community. Best, Maurice --- ## Post #12 by @siljelb [quote="Maurice247, post:11, topic:2393"] I noticed you created a Cluster Archetype from scratch. I found this archetype: [Clinical Knowledge Manager](https://ckm.openehr.org/ckm/archetypes/1013.1.2881), which might be suitable for IHC - Its purpose is: “To record a single value laboratory analyte result, commonly found in clinical pathology testing.” [/quote] Hi Maurice! Just as a quick note, I'm not sure you saw the misuse section of the Laboratory analyte result archetype: > Not to be used to record anatomical pathology macroscopic/microscopic findings, other than for additional testing such as cytometric flow studies. In general, modelling for anatomical pathology has been immature and not a core focus for a number of years. It looks like a lot of different people are focussing on it now though, which may be a perfect chance to improve the situation and create some published models which can be used by everyone :smile: --- ## Post #13 by @Maurice247 Thank you, @siljelb you are right, I overlooked it. An archetype that I've frequently observed being used is `OBSERVATION.lab_test.histopathology`. However, I can't seem to find this in CKM or Archetype Designer. It only appears in the "use/misuse" section of other archetypes. --- ## Post #14 by @siljelb [quote="Maurice247, post:13, topic:2393"] OBSERVATION.lab_test.histopathology [/quote] The regular OBSERVATION.laboratory_test_result is intended to be used for anatomical pathology results also. I haven't seen this specialisation you're referring to, but initially there shouldn't be a need for one (I'd be happy to be proven wrong though). Details about the tests/examinations and results can be modelled as CLUSTER archetypes and inserted into the standard OBSERVATION in a template. --- ## Post #15 by @Maurice247 ![Screenshot 2023-08-31 at 11.45.28|690x488](upload://1O4e2mdWBxQptFVdOqpPOgy561J.jpeg) --- ## Post #16 by @mar.perezcolman Hi both, That archetype has been rejected [Clinical Knowledge Manager (openehr.org)](https://ckm.openehr.org/ckm/archetypes/1013.1.351) You can find it by clicking on 'Lifecycle' -> ![image|374x500](upload://e3PSd6Zu9SgoUFZs95E32mkkwlV.png) I was looking for this archetype in the CKM a little while ago because I could download it to the AD but I kept getting an error message, and I was pointed to this section. It is odd that the AD allowed me to import it, but the warning and that the template kept 'braking' prompted the question. ![image|684x311](upload://cjvc2QGJCBW7IO5QP3frqbL5bWx.png) --- ## Post #17 by @varntzen @mar.perezcolman, a tip whenever finding an deprecated or rejected archetype, go to the Archetype history ![image|49x41](upload://9gGPYA0VopJxlfO18DBQGnQPPpm.png) and see the Log message when it was rejected/deprecated. It should tell why, and also point to another archetype. In this case the Log message says: "Old pattern, superceded by OBSERVATION.laboratory_test." --- ## Post #18 by @varntzen [quote="mar.perezcolman, post:16, topic:2393"] It is odd that the AD allowed me to import it, [/quote] Well, if one would work with it to improve or correct it, then not allowing to import it to AD would be wrong. But maybe AD could give a warning? "You are about to import an rejected archetype. Proceed?" or similar. --- ## Post #19 by @ian.mcnicoll As one of the original authors I just want to confirm that the histopathology archetype mentioned is not the direction of travel and I agree with @Silje and @Heather that the Anatomic pathology work should be based on the current generic OBSERVATION.laboratory archetype. There is a pattern applicable to anatomic path that can be added re Macrosopic, macroscopic, intraoperative that we can build from, and I think is still an open question on whether this should be a specialization and not just a looser templated pattern. But we can build from there. Also, just a note on the background to the archetype that Marlene posted. It was built to reflect the needs of Welsh Cancer Standards reporting so is a somewhat 'flatter/simpler' view of the world than we will need for Anatmic path reports and Cancer MDT support, where e.g staging and 'nodes' is way more complex and tumour specific. This seems to be a pretty universal issue. We tried to solve it with the original set of Anatomic path archetypes by using largely generic representations of e.g 'nodal spread' then templating out of specific cancer types but this became pretty messy. I think we might be better to accept that whilst there may be some gneric ideas like nodes examined/nodes positive, that these will only really ever be used for reporting, and that further detailed per-cancer nodal spread clusters will be required. I think there is enough joint interest and momentum her to perhaps arrange a joint bit of a 'show and tell' call perhaps in latter part of September? --- ## Post #20 by @erik.sundvall Wonderful to see all the action in this thread! If you want some scandinavian input and don't mind translating via Google Lens or similar transalation tools you can have a look at: * The Norwegian template at [https://arketyper.no/ckm/templates/1078.60.792/orgchart](https://arketyper.no/ckm/templates/1078.60.792/orgchart ) that seems to have a pretty nice structure for creating a complete report and clarifies where smaller clusters etc may belong in a larger structure. Does anybody know of similar template examples? * A work in progress snapshot of Swedish models, currently focused on the microscopy part, see below: * Swedish concept model - useful for discussions. (The greener the box, the more mature/reviewed it is) ![2023-08-21 Begreppsmodell patologi|542x500, 50%](upload://9jfx3uqh0cF1Lq0PtVdrknMMbbd.jpeg) * Rough Swedish information model - it will in the openEHR implementation case need to be replaced/expressed by templates/archetypes covering (at least) the same data content somehow. The light blue boxes are breast-cancer specific and the others are hoped to be more generally reusable for other cancers. Red border means more unfinished. ![2023-08-21 Informationsmodell bröstcancer|682x500, 50%](upload://1l8PnXBwWW1xHWWcFyU48HQHYyz.png) @ian.mcnicoll a a ‘show and tell’ call sounds like a nice idea! Does the [Clinical Program Board](https://openehr.org/programs/clinical/board_members) (ping @joostholslag @vanessap @Paulmiller) and/or super-experienced modelers like @heather.leslie @siljelb or others be involved somehow? Suggestions/thoughts: 1. refreshing/creating a general archechetype for m**i**croscopic findings might be a good start 2. and then (or simultaneously) testing compositional design patterns and/or specialiations to cater for breast cancer specific needs and perhaps some other cancer type (depending on participants' interests). 3. refreshing/creating a general archechetype for m**a**croscopic findings 4. ... --- ## Post #21 by @Maurice247 Thank you for taking the initiative Ian and Erik. It would be great to have a call for everyone involved in pathology reporting. Depending on the number of interested individuals, I'm happy to assist in finding a suitable timeslot for everyone using Doodle. Please like this post if you are interested in joining the call. --- ## Post #22 by @varntzen Late to the party, but we're currently working on both pathology reporting related to cancer, and also cancer archetypes in general. Lots of discussions. Would be nice to collaborate. Count us in, go through me. Vebjørn --- ## Post #23 by @mar.perezcolman I would be interested in participating too. We could probably be present as a team, @johnmeredith. Thanks --- ## Post #24 by @Maurice247 To find a suitable time slot please fill out the doodle -> https://doodle.com/meeting/participate/id/dwro0Nwb --- ## Post #25 by @SDubois That I missed this discussion last year February is beyond me, but I'm very grateful that @Maurice247 contacted me from Basel to consider cooperating in this venture! We had a great discussion today. I read the thread with great interest. I'm happy @erik.sundvall shared the concept for data collection in breast cancer pathology as created by the Swedish team, built according to the "Nationell Informationsmodell" (National Information Model (applying UML)), which the Swedish Health Care system uses more broadly. Not an IT person myself, though, I find this model difficult to navigate with regards to the algorithmic approach of a pathology report. Maybe it just takes more getting used to! I'm very curious to see the work by @mar.perezcolman and the Norwegian team @varntzen. I was fortunate to be involved in de openEHR CDR project in Sweden that Erik mentioned. Meanwhile, I have been collaborating with SNOMED International to help create a central repository that aligns several international protocols / datasets to SNOMED-CT codes (ICCR, CAP, RCPath, RCPA, Palga). The repository is meant to be fully searchable in a system now being developed as a specific project by IT in the University of Nebraska: this means agreement on the international terms/variables and their S-CT codes to be utilised when building protocols. The world has spun a few times, but a consensus seems to be emerging that the ICCR protocols would be acceptable internationally, and therefore be the model protocols one would aim to construct when designing archetypes in openEHR. Hopefully I can be of help in the building of archetypes and forms and perhaps share some of the very mundane and non-IT'ish work on the protocols I have done. Personally, I would think that for the development of archetypes we'd easier find common ground in the area of macroscopy than in microscopy. Also, one can wonder whether a simpler protocol such as colon might be a better starting point than breast. Happy for the momentum as @ian.mcnicoll mentioned! I've filled in the Doodle. --- ## Post #26 by @theresehogbergmarder I'm also interested in participating and listen to interesting discussions! @sanna.asberg , maybe this could be interesting for you? --- ## Post #27 by @Maurice247 We've received responses from 6 individuals, and the only overlapping availability is on October 3rd, 10 am - 12 pm CET. **Please provide your email address in pm so I can send you a video call invite to block this time.** Additionally, I suggest we outline objectives, the agenda, and potential action points in preparation. Please refer to the Google Docs link and feel free to add your thoughts. Looking forward to a productive discussion with you! https://docs.google.com/document/d/16yk_BAwmvEINhoJHzGCEXJfjromBQguwjijv_Ub8MGk/edit?usp=sharing --- ## Post #28 by @varntzen I'm sorry, but in this utterly hard-working-country-but-still-with-a-lot-of-time-off-such-as-holidays, we have what was known as "potato holidays". Meaning, children were pulled out of their school to help harvest potatoes. In modern Norway, it still exist, but named "autumn holiday". To complete the un-convenience for all, this happens in different weeks throughout the country. For my part, Oslo region, this is in week 40. And for Silje in Bergen, week 41 (not sure if she is off or working). So, unfortunately I'm not available in week 40, I'm off on an isolated island. Not picking potatoes, though. --- ## Post #29 by @erik.sundvall @varntzen I would guess there will be more than one meeting before pathology modeling is all sorted out ;-) so you'll likely get a chance to join later. @Maurice247 can the meeting be recorded and later shared with @varntzen and others missing it? --- ## Post #30 by @Maurice247 @erik.sundvall @varntzen I'll be recording our meeting. Additionally, I've prepared a protocol, accessible via the provided link above. This ensures everyone can stay informed and actively contribute. --- ## Post #31 by @mar.perezcolman Good morning - Apologies for asking this, but I cannot find the meeting invite. Could you forward it to me? My email is marlene.perezcolman@wales.nhs.uk Thank you so much! --- ## Post #32 by @SDubois I don't think the actual Zoom invite has been sent yet, am I right, @Maurice247? --- ## Post #33 by @Maurice247 Hello everyone, I hope I have successfully invited everyone to this discussion. If not, please feel free to send me a private message. @SDubois and I have been exploring the creation of universal core archetypes for microscopic reporting, focusing on common elements like tumor presence, tumor diameter, and others. While comparing guidelines for various cancers, finding a consistent and reusable structure seems to be challenging. In preparation of our meeting, I would like share my thoughts. I was thinking to focus on the actual finding that we want to describe and structure the archetypes accordingly. I believe this method could simplify the creation of a universal template and can be used for multiple microscopic exams . I've attached a mind map to further illustrate this idea. Happy to get your feedback. Best, Maurice ![Microscopic findings|690x262](upload://v1hZSli1AmHZJyfqdcxPNIXRIJk.jpeg) [Microscopic findings.xmind|attachment](upload://8F892I7T7LEgR4jmS0CNHKpdlrJ.xmind) (294.7 KB) --- ## Post #34 by @theresehogbergmarder Hi, unfortunately I won’t be able to attend the meeting but I look forward to watch the recording later on! /Thérèse --- ## Post #35 by @ian.mcnicoll The RCPA synoptic reports are a good attempt to standardise in this area e.g. https://www.rcpa.edu.au/getattachment/17dbc0d6-589e-4475-a318-34815aca63b0/Proforma-pancreatic-cancer.aspx A number of years ago we came up with a few templates based on RCPA e.g. https://ckm.openehr.org/ckm/archetypes/1013.1.381/resourcecentre The main challenge was in trying ot find commonality at high-level for reporting purpose, whilst accepting that each tumour type and indeed each surgical procedure might require quite different, unique detail. ![image|99x500](upload://h8Na4fzp5sD6DdF3EUb1Gycf5Qt.jpeg) --- ## Post #36 by @ian.mcnicoll We tried to create generic archetypes for aspects like [Tumour margins](https://ckm.openehr.org/ckm/archetypes/1013.1.355) but found that this became pretty complex for simple use but not sufficiently detailed for particular tumour types. This might be a good start for a higher-level 'reporting driven' set of models, then allow detailed per-tumour clusters to be plugged in to support frontline care. http://hl7.org/fhir/us/mcode/STU2/ --- ## Post #37 by @heather.leslie I think if I were to attempt this work again, I'd try spend more time on investigation and research. Increasingly in my most complex work, the data patterns are often there if we look hard enough and across enough use cases. That's the tension - available time/resources vs. long-term/quality patterns. No easy answer. --- ## Post #38 by @SDubois Thank you everyone for a great meeting and thank you Maurice and Erik for driving this. Appended the ICCR protocols with SNOMED-CT bindings I mentioned, as well as the MindMap for macroscopy. Best regards, Stefan [general cancer - macr MindMap v1.32.xmind|attachment](upload://wBTbljickhP3mHWABO7neYjvLQT.xmind) (769.3 KB) [ICCR-CXC-1st-ed-v1_Updated_20230310.docx|attachment](upload://aMTt5tbxejmEeryaxBML1CyMkzz.docx) (506.8 KB) [ICCR-Invasive-Breast-WSC_SNOMED_20230412.docx|attachment](upload://qEKio7UhD9g9tnd4JGzWW8s5NES.docx) (883.1 KB) --- ## Post #39 by @Maurice247 Thank you all for your contribution today. It is a pleasure to work with likeminded. Whenever you have a moment, could you kindly review the meeting notes provided in the link above? Once everyone has had a chance to go over it, I'll post it in this thread, along with the video recording of our session. --- ## Post #40 by @mar.perezcolman It was a really great meeting. Thanks especially to Maurice who also did all the admin work. We could take turns in doing it. I could schedule next one, and that is my only question regarding the summary, as I don't think we agreed on a next date. Cheers --- ## Post #41 by @SDubois At the SNOMED-meeting in Atlanta (I'm attending virtually :upside_down_face:) we will hear about building FHIR questionnaires using the widget on the Nat'l Library of Medicine site. Nothing new, certainly, but as the CAP and ICCR cancer protocols are all now almost fully bound to their SNOMED-CT codes, it gives an exciting opportunity to see a functional algorithmic digital protocol with S-CT codes take shape. The widget is at https://lhcformbuilder.nlm.nih.gov/ . Click "start with existing form" and "import from local file", which is the appended .json file for colorectal ca. Most of the work is by Alejandro Lopez Osornio and Hwang Ji Eun, a Korean postdoc working with Scott Campbell (University of Nebraska) at SNOMED International, I added some stuff, it's dead easy. This is only a preliminary file shared a few weeks ago and work in progress, but since this came out I think Alejandro and Hwang have continued the build on colon and on other cancers, which they will present. [Colorectal-Cancer-STDU-v1.1.R4.json|attachment](upload://jT2Ko81Qv5IR9IbIOkcog027A8b.json) (42.2 KB) I have as yet not found a way to extract the generated data into a report or summary, but from previous experience working with Sectra I know that that is not a difficult task - for the initiated! :innocent: What appeals to me is the ease with which one can create a "goal" for a form in openEHR. I see it as a platform to easily add national or regional variables, grasp how it all functions and share a protocol with learned communities / pathologists at an early stage to get their input. I will pursue the matter and keep you posted. Meanwhile I'm working on the specifications files and MindMaps. When have we planned our next meeting? --- ## Post #42 by @bna [quote="SDubois, post:41, topic:2393"] When have we planned our next meeting? [/quote] I would also like to now :-) --- ## Post #43 by @mar.perezcolman Good morning all, Hope you are ok. I was wondering, should we have a shared document/map for this " **mapping all data elements from ICCR reporting for the colon**" that is one of the action points from our last meeting? And would it be good to reconvene on the first week of December? --- ## Post #44 by @SDubois The mapping for ICCR is pretty much completed in Excel and will be even more accessible in the FHIR questionnaire as mentioned above, as these will contain the SNOMED CT codes too, and allow for checking for updates on S CT codes in something called the "FHIR Questionnaire Terminology Bindings Validation Tool". I'm currently going through the Palga variables and adding it to the ICCR and CAP mappings, and hope to share the full list shortly. The RCPath mappings can come at a later stage. A shared document / map would be good, yes! I do not know when the "official" FHIR questionnaire that Alejandro c.s. are working on will be released by SNOMED Int'l, but I've requested a peek preview... ! :grin: I do not intend to continue building the colon FHIR questionnaire since it will already be done by Alejandro c.s. I believe we should also apply our time in chopping up the protocols into common and digestible parts that could be converted to archetypes. I hope to get some possibilities out within a week or two - certainly before our next meeting. The beginning of December sounds excellent. I hope several people in this thread will be in Arnhem on the 17th of November! --- ## Post #45 by @SDubois OK, I've received the finished .json files on Breast and Colon from SNOMED; prostate to follow some time this week. I will check the files and submit them for your perusal together with the Excel files shortly. --- ## Post #46 by @mar.perezcolman Hi everyone, I have created a poll (hopefully I've done it correctly) to try to find the best spot to meet: Please mark your availability for: Pathology modelling - part 2 https://whenavailable.com/event/Uniz8e2BZj3adsBp6 I set it up so there's time to reply until the 17th (next Friday) --- ## Post #47 by @SDubois Great Marlene, thanks. I've filled in the poll. --- ## Post #48 by @mar.perezcolman Hi all, I have attached a draft meeting agenda to the calendar invitation. If you would like to add something to it, please let me know. I made it very high-level. Marlene --- ## Post #49 by @SDubois Hi Marlene! Thanks for your lead. I can’t find the agenda, I must be looking in the wrong place – please advise! --- ## Post #50 by @mar.perezcolman [quote="SDubois, post:49, topic:2393"] I can’t find the agenda, I must be looking in the wrong place – please advise! [/quote] Hi Stefan, I just sent an update of the invitation which should contain the agenda. I though I had saved it correctly. Please could you confirm that it is attached in there? It might be that if I only save changes and not send the update it won't show outside the organisation. Sorry! --- ## Post #51 by @SDubois Hi Marlene! Yes, attached: all in good order – thank you! --- ## Post #52 by @Maurice247 Dear all, Please excuse my long silence. In recent weeks, I have built, tested and discarded many concepts for capturing microscopy findings in openEHR. The three concepts I tested are: the specialist design, the generic design, and the name/value design using the existing archetypes laboratory test result with the analyte cluster. One challenge in mapping microscopic findings or any diagnostic reports in openEHR is representing complex, interconnected data elements. For example, in microscopic assessments, all data elements of a tumor must be assignable to that tumor (e.g. squamous cell carcinoma, 2cm, lung). Some information like diameter only contain one data element, while others like IHC analyses contain at least 4 elements (TTF1, 90%, membranous, moderate) that also need linking together. And within one microscopic assessments, an adenocarcinoma could be found alongside the squamous cell carcinoma. The question is how do you want to reflect this? To better understand here an example. Imagine we found two tumors in one microscopic assessment, how do you link the correct tumor diameter to the respective tumor? In the simplest design (name - value) we can address this by providing specific names e.g. Tumor1 - 3cm and Tumor2 - 5cm. While this would work for information with a single data element in scenarios with n data elements this will be difficult. For instance, how do you map the link among data elements of IHC? E.g. in the example below is ROS1 or ALK 50% positive? ![Picture 1|690x164](upload://tXJK8CIdZvThAZamDk00xStWQpx.jpeg) **The specialist archetype design** In the specialist archetype model for each report, like prostate cancer, lung cancer etc one archetype is created. The design is straight forward, for every information a data element is created and linked with the NodeID path. Below is the example of the Microscopic findings – prostate cancer archetype that captures all required data elements for prostate carcinoma. ![Picture 2|690x173](upload://roPVkqU6mKhIinj7UWxQqJ4hpUL.jpeg) **Advantages:** * Easy querying as data elements assignable via specific node ID paths * Can comprehensively capture the complexity of diagnostic workflows * Intuitive archetype design as focused on one narrow domain * Allows optimizing data capture for certain applications **Disadvantages:** * Significant duplication across many niche archetypes * Cumbersome to govern and maintain numerous archetypes * Updates required across multiple redundant archetypes * Lack of reusability leads to siloed data * Complex to query across diverse specialized archetypes * Risk of inconsistent data from slight differences in designs * Change management overhead multiplied many fold **The generic archetype design** The generic archetype is designed for one examination modality like microscopic findings, MRI findings etc. Here the Microscopic findings archetype contains core information captured in an microscopic assessment. Customization for different findings can happen at the template level. ![Picture 3|451x181](upload://qwHKuGpmwk1vZdZkLWT7NzeC9rV.jpeg) Since each data element has a standardized node ID path that is uniform for all microscopic findings, the information can be easily queried. ![Picture 4|690x52](upload://1EXvmN5uG3Nk7YdlLgQ22C2OjvB.jpeg) **Advantages:** * Highly scaleable since it promotes reuse across diverse clinical scenarios * Consistent structure enabling simpler governance * Easier to manage updates and extensions * Avoids duplication of data elements * Simplifies querying since node ID among all reports are consistent **Disadvantages:** * More conceptual complexity designing generically * Less optimized for specific workflow needs * Can underfit specialized use case requirements * Need for localized customization may emerge * Monolithic archetypes require bigger change sets * Lose intuitive real-world specificity **Name/value design** The last approach is the name/value design. As you can see, I plugged in the analyte cluster multiple times into the laboratory test result archetype to capture all values. ![Picture 5|451x484](upload://7QCPzoXaP1rWQGXelqAuL9WDMmz.jpeg) **Advantages:** * Very simple and flexible structure * Easy to add new named data points as needed * Enables recording almost any test-result combination * Loose coupling allows mixing diverse data elements * Querying across name-value pairs is straightforward **Disadvantages:** * Lacks rich semantics to interpret findings * Highly limted to structure relationships between findings * Unable to express complex clinical concepts * Risk of inconsistent naming for same elements * Requires significant terminology binding work * Inadequate representation of contextual meaning * Limited ability for computational inference While this problem and potential solutions are described in the context of microscopic findings, it is a generic issue affecting radiology, genomics, immunology and other domains too. I would be very interested in your thoughts. --- ## Post #53 by @ian.mcnicoll Very many thanks for this. It brings back (un?) happy memories of the challenges we faced the last time around. I'll try to simplify the problem space by immediately excluding the name/value pair option. This essentially mimics FHIR Observation / v2 lab pattern, and works well for simple Biochemistry type labs since these are generally simple name/value results The problem with applying this pattern to histopathology is that you end up having to apply increasingly complex constraints on these simple patterns to represent the constraints in a path report. You are essentially just deferring the complexity, unless there is not attempt to add constraints or validation to the models- Fire and forget message exchange, essentially. So that leaves **The generic archetype design** vs ** specialist archetype design** What is probably not apparent is that in the earlier work we did actually start out with the aim of doing generic archetype design, albeit broken down into individual clusters like tumour_invasion or tumour_margins but increasingly we found that at the leaf node level ,, in supporting direct care, the generic pattern tended to break down - we were having to add more and more cancer-specific elements, and to constrain out the generic elements. So at that point we decided to build cancer-specific archetypes to handle those parts of the data tree that were unique to that tumour. The prostate microscopy cluster is actually a really good example - if you look closely you should see that the element defined are all very specific to the way e.g that tumour margins are defined for prostate cancer, quite differently from e.g bowel cancer. The generic pattern does allow more reuse, in theory, but as for the name-value pair option, the reality is that different cancers are reported quite differently in many cases, and you end up with just as much of a management burden down stream to turn the generic patterns into something more specific. The generic pattern does also, in theory, have the potential to make cross-tumour querying possible, and attractive for pre-populating registries e.g for 'Tumour margins". Again this is less easy than it seems because cross-querying because very often the detailed direct care representation for prostate cancer is quite different from that for bowel or lung and is simply not directly cross-queryable from the original data. However, this is not too dissimilar from the issue we already faced in Wales when looking at the challenge of Tumour staging - the direct care perspective is often cancer-specific, whereas the reporting/cross queryable dataset is often more generic. The solution/suggestion there is to carry both generic and specific representations, and wherever possible calculate the generic response from the specific in real-time. So using your examples, a prostate cancer template would carry both the generic and specialised archetypes. For tumour margins, the specialised archetype would carry the detailed prostate specific representation but with a set of rules to also populate as simple generic representation "clear margins" I think this is probably where we will land Great work!! --- ## Post #54 by @SDubois I agree, wonderful work, @Maurice247 ! And thank you very much for your critical appraisal and additions, @ian.mcnicoll - as well as the historical perspective! :wink: I've had a little time to look at this using the ICCR protocols as the first reference re content (although not nearly as granular as one may wish, as I will demonstrate with the expanded NLM questionnaire for coloncancer). I would also aim for a hybrid generic-specialised distribution of data elements. We can certainly come a long way with generic, and perhaps dedicate one separate archetype which collects cancer-specific questions from different cancer types. This would maybe help limit the amount of changes/amendments that would become necessary when further ICCR protocols are published. Maurice and I have arranged to meet online ahead of the upcoming meeting on 8th december. We hope to align our thoughts and find further inroads into this very fundamental question, to be shared with you the 8th. --- ## Post #55 by @ian.mcnicoll Thanks Stefan, Agree. 1. Try to use generic pattern when we can 2. Accept that this will breakdown or become cumbersome to constrain for quite a number of places. For that accept the need for tumour-specific specialist clusters 3. Where we need specialist clusters, try to pre-populate the generic and simplified representations from the specific, automatically in real time. --- ## Post #56 by @SDubois Great, thanks Ian. I don't understand the "automatically in real time." Can you explain - or otherwise leave it for next week. --- ## Post #57 by @bna [quote="ian.mcnicoll, post:55, topic:2393"] Where we need specialist clusters, try to pre-populate the generic and simplified representations from the specific, automatically in real time. [/quote] This might be a key point working with structured health data where the complexity and depth of data is infinite. Going deeper in the structures try to leave summaries back on the higher defined models. This way different applications and users can use the same data in multiple contexts. When adding a new CLUSTER to a shared/generic archetype to i.e represent specific details, leave some data in the generic archetype. Is this what you meant @ian.mcnicoll ? --- ## Post #58 by @Maurice247 @ian.mcnicoll thank you for sharing your experience. During my testing, I met with a former Siemens engineer who worked on the AI Pathway Companion (a product to retrospectively organise clinical information). He confirmes your crictics to the generic approach. I therefore believe that @SDubois' hybrid proposal is promising. If we create a "core archetype" that covers a basic structure needed in the majority of cancer reports and clone it for the respective cancer reports, we would have advantages from both worlds. The core model allows for centralized governance, provides a clear structure on how to further specialize it (e.g. how to nest information to preserve semantics) and standardized querying. I am super excited to further discuss this with the entire group and create a first draft. --- ## Post #59 by @SDubois We're going places with this, nice! Thank you @bna for your explanation. I believe strongly that trying to assemble "all" available variables from all cancer protocols, be it in ICCR or elsewhere, should be the first step to have an overview of what is needed, what will be included in the generic and what will necessitate specialist clusters. The centralized governance @Maurice247 brings up is paramount. Otherwise we may end up with all sorts of dialect protocols. --- ## Post #60 by @Maurice247 Thank you @mar.perezcolman for organizing the meeting! For the agenda, Stefan and me would like to suggest we invest some time to discuss how to best map relationships among data elements (semantics). My post about specialist vs. generalist approaches could be a starting point for the discussion. Looking forward to meet you! --- ## Post #61 by @SDubois Hi! @Maurice247 (and perhaps I) will present some things in a few hours, I just thought it might be nice for you to peruse at your leisure the colon FHIR questionnaire which is nearing completion. Again, the widget is at https://lhcformbuilder.nlm.nih.gov/, start with "existing form", import the following file and click on "preview". [Colorectal-Cancers-Combi-v1.18.R4.json|attachment](upload://6dCXBsLIxyW5slO3AGXWiGqNEg.json) (282.6 KB) Looking forward to the meeting! --- ## Post #62 by @SDubois Improved: [Colorectal-Cancers-Combi-v1.19.R4.json|attachment](upload://oVQ1w7UugB8oJy3zJukEIKQwXAg.json) (290.1 KB) --- ## Post #63 by @mar.perezcolman Hi all, This is great discussion. Rather than modifying the agenda (which means re-sending the invite to everyone) we can start directly with the discussion here. From my little understanding I think that the hybrid option would be the preferred. To have a generic core set of elements which are loosely modelled to capture different tumours and possibly slots for margins, IHC, or other elements that repeat at 'title level' in all tumours, but have very different data being captured. This is really great :slight_smile: PS: I'll take down notes to try to summarise the discussion --- ## Post #64 by @Maurice247 **Style Guide for Diagnostic Archetype Design in openEHR** **Introduction and Purpose:** This guide aims to provide a structured approach for designing diagnostic archetypes in openEHR. The purpose is to ensure that archetypes are consistently, accurately, and effectively modeled to represent diagnostic data, particularly in the field of pathology. **Requirements:** * Completeness of data elements * Correct mapping of relations among data elements (semantic) * Standardization **Background:** Unlike clinical chemistry laboratory data, which primarily consists of name/value pairs, diagnostic pathology data is characterized by its rich semantics. For example, a malignant tumor requires detailed information such as morphological descriptions and specific tumor characteristics. **Structure of the Generic Archetype:** The generic archetype contains standardized core data elements applicable across various examinations. From these, more detailed and specific information is differentiated. **Checklist for Adding New Data Elements:** 1. **Generic Element Check:** Is the data element generic enough for various examinations? 2. **Multiplicity Check:** Determine the occurrence of the data element (once or multiple times). 3. **Grouping/Nesting Check:** Decide how to group or nest the data element. 5. **Data Type and Format Rule (Datentypen- und Formatregel):** Confirm the data element's conformity to established types and formats. **Example: Modeling "Malignant Tumor"** **1. Generic Element Check:** * Is the data element generic enough for various examinations? * **Application:** Yes, "malignant tumor" is a generic concept applicable across numerous types of pathological examinations, such as lung, breast, or colon biopsies. **2. Multiplicity Check:** * Determine the occurrence of the data element (once or multiple times). * **Application:** "Malignant tumor" can occur multiple times within a single examination. For instance, in a lung biopsy, there could be multiple distinct tumors. **3. Grouping/Nesting Check:** * Decide how to group or nest the data element. * **Application:** Each instance of a "malignant tumor" should be nested within the biopsy report. Further, specific information like tumor type, size, location and ICH results should be nested under each tumor instance. **4. Data Type and Format Rule:** * Confirm the data element's conformity to established types and formats. * **Application:** The "malignant tumor" data elements should conform to established medical terminologies and formats. For example, tumor size should be recorded in standardized units (like centimeters), and tumor type should use recognized classifications (like those from SNOMED CT). I tried to keep it concise and hands-on using an example. The stage is open for feedback. --- ## Post #65 by @SDubois Thank you, @Maurice247, and thank you everyone for today's meeting. --- ## Post #66 by @siljelb This is great work, congrats to everyone who's participating! :raised_hands: :clap: Regarding the way forward, would it be an idea to continue working on the style guide proposal on Confluence, by creating a new sub-page here? [Specific content models (needs review and updates) - openEHR Clinical - Confluence (atlassian.net)](https://openehr.atlassian.net/wiki/spaces/healthmod/pages/2949175/Specific+content+models+needs+review+and+updates) --- ## Post #67 by @SDubois Would that be instead of, or parallel to, working in Github? --- ## Post #68 by @siljelb The Confluence site is where openEHR International publishes style guides, so it would have to be published there at some point anyway. And using a wiki may lower the threshold to comment or otherwise participate, compared to using Github :smile: --- ## Post #69 by @ian.mcnicoll GitHub was primarily to have a shared Archetype Designer modelling repo - not to replace Confluence . --- ## Post #70 by @SDubois Thanks, @ian.mcnicoll and @siljelb --- ## Post #71 by @Maurice247 Thank you @siljelb. I added the style guide into the confluence page. Please feel free to add feedback. https://openehr.atlassian.net/l/cp/A0YcV2YB --- ## Post #72 by @Maurice247 Also looking beyond relationships within an archetype we should consider how to connect data elements across archetypes. For example, radiology typically provides the tumor locations, while microscopy determines if and what type of tumor it is. This means all forms for prostate cancer like MRI, microscopic findings, lab results provides us with pieces of the puzzle. Like in the image below ![metric_hexagon_fertig4|690x434](upload://7wda70va3VMzb075n5rSzJqQDhr.jpeg) To provide the full picture of e.g. prostate cancer we need matching at archetype/database level. I know many might think this is done through queries, but it's not that simple. In radiology, there can be multiple PIRADS lesions, each has its unique finding in microscopy. If data elements have relationships across the archetype we need a primary key, e.g. the exact location. This would also enable for quality control. Our radiologists are very interested in knowing the actual results of their PIRADS predictions. I will put that in the style guide. --- ## Post #73 by @ian.mcnicoll That's a good question, Maurice. Options... 1. Match an anatomical location (probably SNOMED coded), by using the cluster.anatomical_locaiton archetype, that can be indepedently queried across ENTRY archetypes. e.g imaging, pathology. DIPS have done somewthing like this in opthalmology @bna ? 2. Add a specific tumourID or another pathway/journey ID for every interaction, either embedded in each relevant composition or use openEHR FOLDERS @sebastian.iancu -can explain how they use folders for mental health care planning. 3. Both Better and ehrbase are developing the option in AQL to look for Elements within archetypes that are labelled with a particular external code (this is similar to how FHIR Observation.code works). This would allow us to use term mappings on nodes to semantically label and query elements with e.g SNOMED that are internally coded differently. --- ## Post #74 by @ian.mcnicoll https://discourse.openehr.org/t/openehr-github-repository-to-back-shared-modelling/4763/2 Making progress on this but it might take a little while to establish the governance arrangements. @erik.sundvall - can we start by creating the shared repo in the Karolinska Github repo (preferably on a separate Organisation), then we can transfer to openEHR in due course? --- ## Post #75 by @SDubois Thanks @Maurice247 and @ian.mcnicoll . When I read Maurice's post I also felt that anatomical site would be the first possibility for interconnection. Are we only talking about tumours? Taking prostate as an example: an anatomically defined lesion might be deemed PIRADs 4, but histologically only show inflammation. Would you still be able to / want to give that lesion a specific tumour ID, as you suggest? On the other hand, anatomy within SNOMEDCT still has some gaps and ambiguities (eg, thoracic lymph nodes). Would this last problem be addressed with your 3rd solution? --- ## Post #76 by @SDubois **whom at SNOMED could we contact re the inclusion of S-CT codes in openEHR?** Scott Campbell at the University of Nebraska suggested the openEHR organisation get in touch with **Jane Millar**, jmi@snomed.org. Who at openEHR would know whether Jane or anyone else at SNOMED already has been contacted re our request? How do we take this further? --- ## Post #77 by @Maurice247 Thank you, @ian.mcnicoll, for the overview. I agree with @SDubois, what we actually would need is a cancer ID since tumor can be anything. The problem is that you only know at the end if it was cancer. I think for solid tumors, the anatomical site can serve as the primary key to correctly assign findings between examinations, since it is unique. For example, a PIRADS lesion can only occur once in a zone. I also looked into archetype and SNOMED-CT, and I think if we use 'body site name' as a coded text and then utilize SNOMED-CT body structures. It’s granular enough even for the prostate. ![Screenshot 2023-12-18 at 12.33.42|690x149](upload://vwGsd9am92GaJWcW0coTyzpoVe5.jpeg) ![Screenshot 2023-12-18 at 12.34.44|690x490](upload://rs6TkWGtd05xnP40Y6PoDKvDOiV.jpeg) For non-solid tumors, theoretically, it could be genetic changes, but we only know these at the end. Here, the specimen site would be appropriate since it is collected once and all tests can refer to it. ![Screenshot 2023-12-18 at 12.41.54|626x500](upload://2p82hppO1myBBCdT2KErZQRrJ22.jpeg) What do you think? --- ## Post #78 by @erik.sundvall [quote="ian.mcnicoll, post:74, topic:2393"] @erik.sundvall - can we start by creating the shared repo in the Karolinska Github repo (preferably on a separate Organisation), then we can transfer to openEHR in due course? [/quote] So far I only think I have (via mail to erik.sundvall@regionstockholm.se) been sent the Github username of @SDubois , and I believe I already know the id of @ian.mcnicoll, so others please mail your Github IDs to me (not passwords etc). I think we could start experimenting with shared pathology modeling in a brannch and subdirectory of [https://github.com/openEHR/Sandbox](https://github.com/openEHR/Sandbox) to figure out if that works, and then later move to a separate better named modeling project on Github. --- ## Post #79 by @erik.sundvall There is now a test repository set up and, just for fun and furher testing, also the `modeling-test` branch to work in instead of 'master'. You can connect Archetype Designer to this and hopefully start working: ![image|690x397](upload://8Ufo7HEDBSvSRCZNpdwuaAEP8QB.png) RIght now it is pretty empty, but perhaps @siljelb or @ian.mcnicoll could import some relevant archetypes there to get us strted. Things can get messed upp (overwritten) if several people save the same archetype /template in the same branch during overlepping timeslots. (Last save wins, but previous saves can usually be found as versions.) We may want to later workin several branches. Anybody in the world can open/read files but as of this writing, the following have write (save) permissions: ![image|206x500](upload://i6JHcr14g4e0pigVwRSFMlUerfP.png) --- ## Post #80 by @mar.perezcolman [quote="SDubois, post:75, topic:2393"] give that lesion a specific tumour ID [/quote] Hi all, apologies for a very delayed reply. Identifying the correct tumour in the correct body site and being able to associate all the documents to that specific tumour is something that we have been going over. I think it all begins with a 'lesion' that at some point, with the pathology result, becomes a tumour. But in order to have the whole story it needs to be identified from when it was suspected. There is an archetype that has been paused in its revision: [Clinical Knowledge Manager (openehr.org)](https://ckm.openehr.org/ckm/archetypes/1013.1.2109/mindmap) specific for lesion. Could that work as a glue-cluster to associate them if we added an ID? And apologies @erik.sundvall, I thought I had sent my GitHub ID. I'll email now --- ## Post #81 by @ian.mcnicoll I agree there probably needs to be some kind of 'glue archetype but I would see it as more of an administrative notion of a 'tumour' not necessarily tied in detail to a particular physical growth or body site, because the original focus might be quite misleading as the true picture emerges. --- ## Post #82 by @mar.perezcolman Good afternoon all - Hope you are ok. I wanted to check if there has been any progress in this area. As well, I wanted to check if you think we could/should meet. We have been working on some modelling, which we can probably share to discuss. Thanks! --- ## Post #83 by @ian.mcnicoll It would be good to report what we have been building, if only for people to react and tell us why we are wrong!! The field was Breast Cancer Pathology Reporting, primarily to meet Swedish standards but we have tried to align with ICCR as much as possible. --- ## Post #84 by @SDubois Hi @ian.mcnicoll and @mar.perezcolman, Sounds good. I've been busy with other areas and have relinquished my duties re the breastprotocol, especially since @LindaAulin gave a heads up a while ago that we should get together to thrash something out. I'll pick up the trail again. Marlene, will you be setting up the meeting? --- ## Post #85 by @mar.perezcolman Hi all, I have created a poll to see when it would be best for everyone. If this is too soon I'll look for another date further ahead. Please mark your availability for: Pathology modelling - openEHR https://whenavailable.com/event/kXrBY98htd2YF4aQA --- ## Post #86 by @mar.perezcolman Good morning all - I have received some replies regarding dates, and it isn't going to be next week. It is probably going to be on Friday 26th 10-11 UK time (11-12 CET). Could I confirm with @Maurice247 , @erik.sundvall and @siljelb if that would work for you? Thanks! --- ## Post #87 by @siljelb I may be able to make it at that time, although I do have conflicting meetings. However, don't let it stop you if I can't make it. --- ## Post #88 by @mar.perezcolman Apologies, As per the email, this is the new poll: Please mark your availability for: Pathology (part 3) https://whenavailable.com/event/uHWkEdvCBHpXvPvDA --- **Canonical:** https://discourse.openehr.org/t/refreshing-archetypes-related-to-pathology-reporting/2393 **Original content:** https://discourse.openehr.org/t/refreshing-archetypes-related-to-pathology-reporting/2393