Refreshing archetypes related to pathology reporting

GitHub was primarily to have a shared Archetype Designer modelling repo - not to replace Confluence .

1 Like

Thanks, @ian.mcnicoll and @siljelb

Thank you @siljelb. I added the style guide into the confluence page. Please feel free to add feedback.

1 Like

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

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.

That’s a good question, Maurice.


  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.

1 Like

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?

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?

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, 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?

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.

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.

What do you think?

So far I only think I have (via mail to 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 to figure out if that works, and then later move to a separate better named modeling project on Github.

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:

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:

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 ( 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

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.

1 Like

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.



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.

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?

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

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?

1 Like

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.

As per the email, this is the new poll:

Please mark your availability for: Pathology (part 3)

1 Like