I'm trying to archetype patient records in a prostate cancer
environment. I see that there are currently no specific archetypes for
common cancer treatments such as radiotherapy, hormone therapy and
chemotherapy. Could hormone therapy and chemotherapy be described as
specializations of the openEHR-EHR-INSTRUCTION.medication.v1
archetype? And could radiotherapy be described with a specialization
of openEHR-EHR-INSTRUCTION.non_drug_therapy.v1? Or should these be
described in completely new archetypes (e.g. INSTRUCTION.radiotherapy/
hormone_therapy/chemotherapy)?
Thanks for your help,
Melanie Spath.
PhD Candidate
Centre for Health Informatics
School of Computer Science & Statistics
Trinity College Dublin
Dublin 2, Ireland
Ocean have been working with NEHTA and the Royal College of Pathologists Australia to develop Cancer Pathology reporting
archetypes and templates - you might find it helpful to have a look at these in CKM at www.openehr.org/knowledge. The key aspects of the prostate cancer archetype is at this link -Microscopic findings - Prostate cancer
If you go to this link then coose the Resource Centre archetype from the toolbar buttons at the top you will be able to have a look at the Operational Templates we have developed. The one which will be of most interest is the
RCPA Prostate Cancer (Radical Prostatectomy) Structured Report Demonstrator - click on the View Template button then View Form and you will see a view of the whole report which includes some of the data elements you wish to model, though these have not been done in great detail as yet.
My feeling is that this is correct for chemotherapy and probably hormonal therapy (which I assume is still mostly ‘prescribable’) but I suspect that radiotherapy will require its own archetype, rather than a specialisation of non-drug therapy, as the latter is a bit of a catch-all, whilst radiotherapy is very common and will require specific detail.
Your email caught my eye for a few reasons, firstly I have done a little work in Cancer information systems over the years, secondly i am working with Prof. Grimson in HIQA.
Having modelled this before in a different environment (trying to awaken a few brain cells that have not been active for a few years) there were other archetypes which need consideration - Chemotherapy Treatment, Course & Cycles, when you get down to the daily administration you are probably close to a specialisation of a medication archetype.
I would consider the Radiotherapy treatment to be a collection of archetypes again if it is external beam you are dealing with, Radiotherapy Treatment, Phases, and Fractions at a minimum and would probably best best modelled as specific archetypes but I am new to contributing to this so others may have different opinions. In my previous life then got into a lot of detail on planned and actualy and treatment sites and used the radiotherapy record to go on to drive a schedulling component for Radiotherapy department. We didn’t look at brachytherapy in much detail.
That is really helpful. If you and Melanie do have some discussions it would be really useful to capture some of this knowledge around radiotherapy, even via something a bit rough and ready like a mindmap.
I am hoping Rong will chip in with his experience of chemotherapy guideline modeling, which, of course, mirrors the actual prescribing instructions.
Would hormonal therapy always be akin to a medication order?
I see some great comments from Ian and Kevin so far - thanks.
You aren’t starting with anything simple - this is a very complicated domain and hopefully you will have access to some oncological advice and resources as well.
The Medication archetype is a great starting point. Please be aware that we are doing some work at the moment to try to bring the Medication family - Instruction, Action and the common description up for collaborative review in CKM soon. We are trying to harmonise the current archetype with many requirements and standards so that we can try to streamline the review process, but I expect that we will find it to be one of our harder archetypes to get agreement on. Keep an eye out, and adopt the archetypes if you would like to participate in the review when initiated.
Intravenous orders and administration of drugs adds a further degree of complexity, and most of your chemo will likely be needing this extra functionality. Plus some of these chemo instructions will be complex orders, potentially with a number of activities within the one order. Some routes may be atypical eg intrathecal etc.
Hormone therapy - hmm trying to remember back… Certainly many will be simple oral medication instructions/actions; some will be IV (as above). We need some expert advice here to determine if there are additional requirements for some hormone therapy that exceed these identified use cases.
Radiotherapy is a completely separate area, and as Kevin/Ian suggest, you need to determine the scope here - potentially it is a whole domain of medicine! I would suggest you mindmap your requirements for recording as a starting point, and from there you should be able to identify the potential archetypes that need development - it may be more than one instruction/action eg related measurements etc requiring recording in an Observation archetype.
I am actually aiming at developing “research” or “omic” archetypes (e.g. test results from experiments on patient specimen, e.g. from genomic/proteomic/metabolomic experiments etc.), since my background is in genetics. The reason for this is to be able to integrate clinical patient and scientific research data to support biomedical knowledge discovery. In this, I am collaborating with a prostate cancer bio-resource which collects specimen from prostate cancer patients. A biobank contains clinical patient information and the “omic” information. I am planning to use this biobank as a test-bed for an “archetyped” biobank information system.
As a start I was trying to see how much of the clinical content in the biobank could be modelled with existing archetypes (to avoid duplicate effort) and to discover “holes”. Some of the information could be modelled with existing archetypes (e.g. results of histopathological analysis with the openEHR-EHR-CLUSTER.microscopy_prostate_carcinoma.v1 archetype), but for others I could not find suitable archetypes (this in itself was not an easy task, I think there needs to be another discussion on a different thread/list about the difficulties of matching database fields to existing archetypes/fields in existing archetypes). I wasn’t sure if the non-existence of archetypes for radio/hormone/chemotherapy was because they hadn’t been developed yet or because it was envisaged that other existing archetypes could be used to model these (e.g. the INSTRUCTION.medication and INSTRUCTION.non_drug_therapy ones).
Until then, in the presence of these “holes”, my approach will be to use “placeholder” archetypes that hold the minimum needed information for this specific case e.g. for radio/hormone/chemotherapy as discussed above, until experts have agreed on their general suitable structure. I am welcoming any developments in this area.
This is now starting to get going and you should really have a chat to Ed Conley, the project lead about possible collaboration, particularly around archetype design, so that as far as possible any research derived data is shareable across different research platforms.
It is not always easy to decide the best approach for a particular piece of clinical information in terms of separate archetype or specialisation , but once you get a good maximal dataset around a particular concept the choices normally become clearer.
This is why we often start the modelling process by looking for existing data models e.g. for Radiotherapy and use Mindmaps to get a good feel for the scope of the concept, well before we begin any formal archetype modelling.
At some stage we would like CKM to direct support this early stage of ‘informal’ modelling using mindmaps and a more conversational. collaborative style of debate between those who are interested in a particular topic. Part of the goal is to encourage people to share ideas at an early stage without feeling under pressure to come up with a publishable solution. By keeping the discussions as public as possible, we avoid the danger of individuals or groups working privately and independently on the same topic, with a resulting clash of ideas and constructs.
We are a bit away from providing this in CKM, but Google Wave has some of the approach we might want to look at - mixture of email, chat, wiki + some support for mindmaps.
Would there be any interest in me setting up a Google Wave to develop the content of a possible Radiotherapy archetype? I have just been given a few Google Wave invitations to hand out.
This would be something of an experiment to see how well Wave might support (or confuse) a collaborative approach to early archetype development.
I would be happy to facilitate the process and, for example, draw up an initial Mindmap but I would need a bit of help getting started in terms of Radiotherapy content. The general idea would be work on the mind map and associated wiki until we had enough consensus to develop a draft archetype to put up into CKM.
It will obviously need input from people like Kevin who have some experience in this area but the intention is just to get the scope and general shape of a Radiotherapy archetype(s) outlined so it will not require anything like as much rigour (and demand on time) as the formal CKM review process.
There is already some interest in the Google Wave community in developing eHeath standards and we could perhaps tap into that group to get a few more volunteers. It would also be a great way of getting more attention for openEHR and the work we are doing in CKM.
We have also just completed a project for an Australian cancer epidemiology center where we converted all their 20 years of data to openEHR - about 1.5 million compositions and 25GB of data. To do this we had to do a lot of modeling (although in the end, they did most of that themselves) and that experience and some of the archetypes that came out of it might be of interest to you. They are now doing poplulation queries across the whole dataset using AQL. Very exciting!
That sounds very interesting - I am wondering how you went about with the conversion? Did you have to do a lot manually? Also, did you rely on existing archetypes or did you create your own? I tried to re-use as much as possible of the existing archetypes, but found this task very tedious since archetypes had to be searched manually to see if they contained the concepts/fields that I needed or were structured in a way that was useful to me. How did you deal with that?
Are those archetypes you created available publicly?
Finally, how did you decide on how to structure certain compositions in your center? Again, did you rely on existing sources or did you make them up yourself?
Were you looking for these archetypes in CKM? If so, I would have thought tat the Find facility would have let you look for specific concepts or terms within the archetypes. Of course, much of this is work in progress, in terms of classifying the archetypes.
I would be interested in knowing more about “were structured in a way that was useful to me”. One of the things that we have to be careful about is that the structures that are in modelled in archetypes will often not exactly match the end-user data entry or reporting requirements. What we are trying to achieve is a semantic match of context and terms, rather than exact match of structure because inevitably this will differ according to local requirements. The classic example is that an application data-entry screen often only roughly matches the underlying templated archetypes. If there is content missing , that is clearly important. We then have to decide if it should be added to the archetype, or if it is a more localised or specialist requirement, do we create a specialisation, or use some other localisation technique e.g by using cluster slots.
We are still at the early stages of getting up to speed on all this, with a focus on the 10 key archetypes, and of course, most of this work is currently unpaid and voluntary but we will shortly be seeing vendor and national programs starting to do formal archetype development and some of this should filter up to the international level.
Can you give some specific examples of problems you had identifying content, possible missing content and what you felt was unhelpful structure? Bear in mind too that most of the draft archetypes may well need a bit of work before they are fit to publish. The idea of the Google Wave collaboration was to get some of this discussion under way in a more informal setting without interfering in the current formal CKM ‘strategy’.
I have had a couple of people ask privately to be involved in the Wave - all welcome. Join the openEHR Wave!! It is new … it is cool .. it is still a bit buggy … but you will be able to tell your grandchildren you were there at the start
It's indeed very exciting! I wonder if it would be possible to know
more about your approach? For example, how many archetypes that you
reused and created for the task, what is the complexity of AQL
queries, and how you solved the terminology bindings in archetypes and
how you used the bindings in the searches etc.
I looked at the openEHR CKM and I used the archetypes found on https://svn.connectingforhealth.nhs.uk/svn/public/nhscontentmodels/TRUNK/cm/archetypes/gen/html/. The CKM didn’t seem to work a few months ago when I started and only contains a subset of the archetypes found on the Connecting for Health (CfH) site. The CKM search functionality is great for archetypes on the CKM site and very useful. But, as I said, there are a lot more archetypes available on the Connecting or Health site and there I had to open each candidate archetype to see if it contained a possible concept.
I am still quite new at this stuff and am trying to find my way round, so maybe I just haven’t found the best way of doing things. One problem I meant with regards to “structure” is the following: for example, I need describe the broad concept “patient history”. There are several archetypes available in the CfH archetype list, e.g. several SECTION archetypes. Each of these links to several other archetypes that can be included or are excluded. So, in a sense, one SECTION.“history” archetypes it the root archetype for several other archetypes that it contains through the slot mechanism. And each of the those archetypes again include and/or exclude specific archetypes. So in a way the SECTION.“history” is the root archetype of an archetype hierarchy. Is there an easy way to see how these are interlinked without having to click through these? Also, is there a way to say download all the archetypes that the SECTION.“history” archetype links to? So that I have all the needed archetypes in one go and don’t have to download them all manually one by one?
One example related to “structuring” is this: I need to model the concept of intravenous fluids given during a prostatectomy operation. I found openEHR-EHR-INSTRUCTION.intravenous_fluid_order.v1 and openEHR-EHR-ITEM_TREE.intravenous_fluids.v1. The prostatectomy operation could possibly be modelled with the openEHR-EHR-ACTION.procedure.v1 archetype (which includes the openEHR-EHR-ITEM_TREE.procedure.v1 archetype through the slot mechanism). How would I now model that the intravenous fluid was given during the prostatectomy operation? I guess I would have to use some kind of COMPOSITION archetype that contains slots for both the intravenous_fluid_order and the procedure archetypes. Would a “co-location” of these two archetypes in the same COMPOSITION be enough to be able to deduce (by query) that the intravenous fluid was given due to or during the prostatectomy operation?
Also, when I find some archetype that models some concept that I need, it is very hard to see how this archetype is linked to from other archetypes (in a hierarchy above it). I think it would be useful though to see which archetypes include that archetype to see in what contexts it is currently intended to be used - because maybe that is how I would like to use it too.
I have to say that the CKM is very useful for searching and finding content and the Mindmap display is a very handy feature.
Part of the problem here is that you are missing an important part of the openEHR picture - Templates. In fairness, this is because the formal openEHR template model specification has not yet been published and most of the real world experience of this area is, for now, within Ocean and other organisations who are using the Template Designer tool. This will change very quickly once the formal specs are published - 'due real soon now".
It is openEHR templates that aggregate together the archetypes required to represent a particular use-case dataset, such as an Operation Note. Gnerally a COMPOSITION archetype is at the root of a template and then it’s slots are filled by SECTION or ENTRY archetypes to represent the content of the template. Note that SECTIONS are generally optional and should not have semantic value. They are there to help human navigation but all of the sematic i.e. queryable content should be in ENTRY archetypes (ADMIN_ENTRY/OBSERVATION/EVALUATION/INSTRUCTION/ACTION).
The other thing that we do in Templates is to ‘constrain out’ archetype nodes that are not required for that particular use case. This is particularly important because of the maximal dataset aspect of archetype design.
“How would I now model that the intravenous fluid was given during the prostatectomy operation? I guess I would have to use some kind of COMPOSITION archetype that contains slots for both the intravenous_fluid_order and the procedure archetypes. Would a “co-location” of these two archetypes in the same COMPOSITION be enough to be able to deduce (by query) that the intravenous fluid was given due to or during the prostatectomy operation?”
Exactly- the context of the IV fluid order is set within the parent COMPOSITION along with the Procedure ,so could be queried as " Show me ACTION.Intravenous fluid details from any COMPOSITION.Operation Note where the ACTION.Procedure was ‘Prostatectomy’" - of course this would be formalised in AQL (Archetype Query Language) which looks like a mixture of SQL and Xpath.
If you can send me a copy of the source Operation Note document you are working from, I could probably create a simple demo template
Just a quick question, is AQL related to EQL (referring to: MEDINFO 2007, EHR Query Language (EQL) – A Query Language for Archetype-Based
Health Records, by Chunlan Ma, Heath Frankel, Thomas Beale, Sam Heard)?
Haven’t used Google Wave myself yet and guess it’s still at the innovator/early adopter stage. But what about starting with something that people are used to, like normal Internet Messaging? I am available on melanie.spath@gmail.com on google chat. Otherwise, if people are brave enough, I’d like a GW invitation also.
I will send you a Wave invite. The reason we are interested in using Wave rather than traditional email, wikis or instant messaging, is that it nicely combines all three. We are interested in using a similar approach within some aspects of CKM, particularly a forthcoming more informal area, we currently call the ‘Sandbox’ where people can collaborate on very early draft archetypes and templates.
Because Wave is still in a testing phase, I appreciate this will limit the numbers who can get involved but after a few weeks new Wavers get their own invites to hand out, so the numbers who have access are starting to grow quite quickly now.
I will send you an invite - it might take a wee while to come through.
The conversion of the data was done by building the models based on an analysis of their data dictionaries. We did a first cut with a mixture of current archetypes and specialisations of current archetypes and some that we built especially for them. They had a look at this and decided to revise the whole set of models themselves. This took an extra month, and it was really gratifying to see a group of people with data management expertise who had had a couple of days openEHR modeling training take on this with really very good results. Not all of the archetypes that they produced were ideal from a pure perspective, but they certainly got a very good understanding of their data that they hadn’t really had before. The great thing was that suddenly they could say that information collected 20 years ago was the same semantically and comparable to information collected many years later and in various different parts of the overall data model.
We produced about 80 templates which were at the composition level and these were based on their data dictionaries. We could have chosen a different level of granularity, but from our experience, the most important thing is to get the archetypes correct (the compositions are important as well for querying I guess).
Once we had the templates, we can automatically generate XML schemas based on the individual templates (Template Data Schemas). These schemas are very specific for each data dictionary and allowed us to generate XSL transforms from the CSV files that their data was available in to XML documents that conformed to these schemas (Template Data Documents). Once we had the TDDs we are able to directly load these into an openEHR repository. The nice thing for this kind of data conversion is that the archetypes not only define the content, but the valid values of data, so on import we were able to do complex validation of all the data and reject data that was invalid. Once the data had been fixed (or the transform changed), those rejected rows could be reimported.
All of this is driven off the original models.
As far as finding the archetypes that we needed, I guess we already had a reasonable idea of what was there. In terms of structure of a particular archetype, we found that in general, the archetypes had many more data points than were required for a particular use case. This is what you would expect from a ‘maximal data set’ which is what an archetype should be. The templates allowed us to use only those parts of the archetypes that were useful for the particular use case. Templates are a very important part of this process. We did find that we had to create some specialisations to meet requirements.
- this is a very complicated domain and hopefully you will have access to some oncological advice and resources as well.
