Dr Andrew, I just went through your website at http://dlab.uow.edu.au/coi/ and am really curious about what exactly is being done in the radiation oncology informatics. Particularly interested in the concept of the clinical markup language. Your introductory page does give a very good and succint idea about what you are attempting to do. However can you add some information as I find these things very interseting. I like the idea that perhaps we can extrapolate the data from the routine clinical practice directly into trials. Indeed it will be a new paradigm in conducting clinical trials
Santam
Dear Santam,
I am shocked! Somebody is reading my website! :)
The CKML notion is an interesting one, and the basis of my Masters thesis. I can across it when establishing the RO vocabulary. I can write more about it later.
The basic notion is that if you developed a mark up language for routine clinical work flow, clinical trials and literature publication, it would be almost IDENTICAL. We do clinical trials to answer questions from the clinical work flow. The literature is published to influence our clinical work flow. When we have a question in the clinical work flow wew go and look at the literature. When we don't find any literature to inform our clinical work flow, we propose a clinical trial. The clinical trial proposes a very structured clinical work flow of 1-4 types applied after randomisation….. get the idea?
Common to all is the tag <diagnosis></diagnosis>, common to all is the knowledge structure of patient > diagnosis & stage > inclusion & exclusion criteria > intent > modalities > modality effects (response & SE) > follow up. All our clinical articles follow this pattern also. All our trials follow this pattern too. All our clinical work follows this pattern too…..
THEREFORE …..
all clinical work can have the same status as trial data, that is impeccable prospectively collected data, if the system we used is used in a rigorously applied fashion. This is where problems start to appear because we constantly call for increased customisability in our systems which leads to divergent use, rather than increased clinical applicability of a single process. I have been all over the place, and honestly, we all do things the same way. The problems with data revolve around the people who don't want to be told how to collect their data or even if they should collect their data. IMPAC v1.0 had the problem that they mandated that a diagnosis and stage HAD to be entered before a prescription, but the first users demanded that it be removed … because they didn't want to have to enter it.
BUT do any of us treat a patient without knowing the diagnosis and stage? If you attempted to sit any oncology exam around the world in any jurisdiction and proposed that you did not need a diagnosis, would you pass? Now I include the presumed diagnosis/stage as a diagnosis. In prostate cancer for instance, in a T1c, PSA3, GS5 case, you might not even image the nodes or do a bone scan, but that is because you have staged the patient clinically as T1cN0M0. I prefer to actually add the prefix 'c' - iT1c cN0 cM0, as opposed to the iT1c iN0 iM0 case. In fact I think that we should be thinking about saving the Bone scans and CT/MRIs and having them processed automatically to map exactly where the mets are showing up (like a GIS!)
But that's enough for now. I can talk some more later. One of my thesis components is to get the CKML into an ontology format and start writing statements so that I can get an assessment of its correctness.
Thanks for asking, but drop the Dr stuff! ;)
A
Thanks Andrew, Do excuse the Dr stuff … a legacy of training in India where people like the suffixes and prefixes very much indeed so it gets kind of ingrained. Anyways nice to to get the detailed explanation. Indeed the concept is very attractive. I presume you by ontology you are referring to this http://en.wikipedia.org/wiki/Ontology_%28information_science%29. I think its similar to what Nepomuk is trying to achieve in KDE :-)
I concept has a mind boggling complexity when I started to think of it after reading your website and some of the articles posted there. But after reflecting on it during the afternoon I realized the concept is very much realizable as we really tend to utilize a set of templates divided in finer subdivisions. The <Examination tag > would be one which lends itself to such a subdivision easily. For example hepatomegaly can be easily characterized. I presume the challenge will be to develop a software that makes it easy for the busy physician to input the data and weed out the unnecessary data points. For example I will want a software that doesn't ask me to input the stage every time I want to .. just referencing the patient should fill in all the relevant data after it has been captured once. Infact your reference to automatic processing .. a system that can be made to be more intelligent and use the available evidence on the topic itself to modify the responses as time goes.. a self learning system in other words
Santam
Yes, an ontology is :
a formal representation of a set of concepts within a domain and the relationships between those concepts. It is used to reason about the properties of that domain, and may be used to define the domain.
The RO domain has a limited ontology if you leave out all the medical stuff leading up to diagnosis - after all we can't solve the problems of the entire medical world! The easiest way to start is to consider the following words and to put them into a meaningful structure/hierarchy.
INTENT, RESECTION STATUS, HORMONE THERAPY, M (as inTNM!), RESPONSE, SURGERY, DIAGNOSIS, PATIENT, OUTCOME, CHEMOTHERAPY, MODALITY, N (as inTNM!), STAGE, HISTOLOGY, ACUTE SIDE EFFECT, RADIOTHERAPY, T (as inTNM!), COMPLICATION, LATE SIDE EFFECT,
The correct order is:
- PATIENT
- DIAGNOSIS & HISTOLOGY > STAGE +/- T/N/M
- INTENT
- MODALITY
- SURGERY
- RESECTION STATUS
- COMPLICATION
- RADIOTHERAPY
- RESPONSE
- ACUTE SIDE EFFECT
- CHEMOTHERAPY
- RESPONSE
- ACUTE SIDE EFFECT
- HORMONE THERAPY
- RESPONSE
- ACUTE SIDE EFFECT
- SURGERY
- LATE SIDE EFFECT
- OUTCOME
- MODALITY
- INTENT
- DIAGNOSIS & HISTOLOGY > STAGE +/- T/N/M
I started by looking at the vocabulary of RO and looked for an objective source. I decided that the only "objective" source was the literature which we all read, and from which we get our concepts and terms. So I trawled through one month of literature (~160 articles) and came up with about 1600 discrete meta-terms (rather than instances). So I counted "Diagnosis" as one item whenever I saw prostate or breast or rectum etc. The overall patterns were pretty much what you would expect - a few items appeared very frequently, and many items appeared only once.
I then started looking at the items and seeing a pattern to them, and when talking to a friend, she said "so you have the hierarchy of domain specialist terms, that fit your domain specific work flow and your domain specific knowledge?" "Yes", I said. "Well, you have yourself an ontology then!" And I think it is true. The main problem then is specifying the ontology in a format that can be machine processed, which you can imagine is well out of our expertise.
It is easy to demonstrate this connection of vocabulary and work flow and knowledge. If I say "10cm", and ask you what I could mean in RO-land and you will come up with about 3 domain specific things. Tell me if there are more RO questions that have the answer '10cm'!
- is it the size of the tumour?
- is it the size of the field?
- is it the size of the recurrence?
The same with PSA = 6.0:
- was it taken when there was no suspicion of cancer?
- was it taken at the time of diagnosis of cancer?
- was it taken during therapy?
- was it taken after therapy?
PS: thanks for the informal name use too! I understand that hierarchy but we Aussies don't really like it in our cores (our convict background tends to see us on an "equal" footing so we don't like separatists, the upper crust or people who wish to occupy a higher place on the hierarchy whether by self promotion or undue respect. Just a little foible we have!)
On a related note Andrew have you ever considered an idea of a bug tracking system for radiation oncology trials? Your system of ontology could be expanded to generate areas where evidence is lacking and we could then use a sort of bug tracking system like they do in major projects now a days to create trial recommendations for future trials.
In simple terms would this lead to the development of anecdotal evidence into hard usable evidence?
I think the basic problem with the use of anecdotal evidence hinges on one basic issue : BIAS … While bias maybe of several types a data collection method that encourages accurate and systemic collection will go a long way towards elimination of this bias.. this coupled with the fact that the system can be modified to build treatment recommendations based on available evidence will go a long way towards collection of good clinical data. Infact this system may enable us to get the final Phase IV trial results in radiation oncology. What this system may not give in the first place is a trial method for Phase I trials. However I am sure that the system will get modified in due time to bring in the "bleeding edge" stuff where people want.
Infact I may be day dreaming in this but one day RO based on informatics can become something LINUX .. a basic kernel which is modifiable into DISTROS to serve diverse requirements depending on the patients and physicians .. you can have solid tested and a stable system (RHEL) or a relatively more trial system (SABAYON/FEDORA) or a middle ground system (UBUNTU). Andrew will know what I am talking about here.
I know I went way out of the RO line here :-D
the main problem with our present IT scene is that:
- we must have R&V software
- machines are vendor specific so R&V is always going to be vendor driven (if there were an FOSS option, the interfaces would be changed deliberately)
- the clinic scheduling/resourcing is required …. BUT able to be undertaken by almost any GP/specialist software available today (except for making 30 daily appointments)
- the oncological knowledge we use to generate literature can exist in any software, but unfortunately does not because there has been little consultation with ROs about knowledge design and structure
- commercial vendors of the above are constantly adding more "functionality" that they can sell (they don't go back and fix problems without complaint)
- commercial functionality usually doesn't match what the customer wanted and doesn't make the system easier to use
- commercial vendors listen to the number and volume of calls for "functionality" and they never say "NO"
- the entire amount of data generated can be saved back into the OIS
When all of this is factored in, it becomes clear that the vendor will promise you everything before you buy ("we'll change it anyway you ask") and then after purchase have every reason why you should fall in line with their modus operandi (we decide on & make the changes). Commercial vendors lock us into their expensive product and prevent us from improving what we have in ways that will change the way oncology is delivered and will deliver back to us our data to be turned into new knowledge.
Let's look at one example. Look at ClearCanvas, a FOSS PACS system that happens to have been written in the .NET framework. It stores DICOM files - CT, MRI, US, DICOM-RT, JPEG2000 and AVI. We have tried all this. What we don't have are viewers for PET/CT, DICOM-RT, JPEG2000 or AVI. But this system can be set up in your department for no purchase cost (you can run it on a PC on the network if you want).
One of our vendors sells a DICOM option which will cost you $200,000 of our local dollars …. AND it doesn't have a viewer for DICOM-RT!
So what stops the ClearCanvas solution from being widely employed? It doesn't have the viewers. What would it take to have the viewers coded? Probably ~$4-5000 of our local dollars. Can we get that money?? NO. Can we get the money for the commercial PACS option? YES???
what? is that a health system trying to save money and be innovative? these decisions are made by managers with self=preservation as their prime concern.
Interested in an Open Source project that can be widely applied (i.e., pick your operating system), look at Luis Falcon's OpenERP-based Medical. There is no oncology component, but that is only because no one has tried. Its based on PostgreSQL so is enterprise grade.
The term "anecdotal" is interesting. Anecdotal dta to me is the evidence of one or two extracted from the large sea of data because of something memorable (and therefore likely to be unusual!) used to justify a systematic stance. For example, "I once treated a 90 year old who died during treatment, so I won't treat any more because they will die during treatment".
The data used for clinical trials is, except where trial-meisters go on data collection expeditions, just plain old clinical data. And the clinical data outnumbers the trial data by a factor of 98:2 in this country! Here is a scenario below:
If I have a useful OIS and developed its use in a department to the point that the following data is 100% present and 100% correct, so that I could select patients with :
- any diagnosis
- any histology of any diagnosis
- any grade of any histology of any diagnosis
- any stage of any grade of any histology of any diagnosis
- any intent of any stage of any grade of any histology of any diagnosis
- any modalities (surgery [e.g., 'mastectomy'], radiotherapy [detailed], chemotherapy [e.g. 'ACx6'], hormone therapy [e.g. does it matter which?], brachytherapy, immunotherapy) of any intent of any stage of any grade of any histology of any diagnosis
- a range of acute toxicities of treatment once a week for every patient [fatigue, weight, PS, skin, mucositis, pharyngitis, proctitis, cystitis, pneumonitis)
- a range of late toxicities of treatment on follow up (including tumour markers - PSA, thyroglobulin, AFP, bHCG)
- an assessment of Local, Regional and Distant disease status [NED, recurrence] at every follow up.
- record of death and cause of death
Answer this question - is this data useful? To do what?
Here is an exercise, go to the IJROBP or R&O and pick a clinical report and tell me if you could reproduce the report with the information above.
Anecdotal evidence is also it worked the last time,maybe it will work again!And is not all hypotheses based on just these anecdotes? I agree that a systematic R&V system would greatly help and my submission is that these anecdotal patients(pardon the term) may just point towards something deeper.An example-I have some patients who discontinued treatment after 30-40 Gy EBRT due to treatment related toxicity and they were all staged as stage 4.Yet they have been coming for review after 5-7 years .What differentiates these patients from the early stage patients who succumb within 1-2 years (again small numbers).But one problem felt is that each year has led to changes in imaging modalities,treatment modalities,histopathology techniques…. This is big money speaking and it will shout out loud for more big money.
I liked the Java solution for auto contouring in JROI.But using it in any contouring workstation would probably mean big $$$$$.
I used to make a rudimentary ROIS with Access and BASIC and DICOM viewers off the net but the bigger better and more expensive systems led me astray(and if the hospital pays for it-why not?).
Anecdotal evidence as you describe it can swing both ways - it can point to a new insight, however it can cloud the obvious also!
For that group who survive unusually, they will become apparent in the systematic chart also, BUT there will be so much more data surrounding them that will enable you to define characteristics and prognosis better. The IRESSA story here is very salient. What do you need to know to pick out the Iressa responders? And the answer is PREDOMINANTLY their DEMOGRAPHIC & DAGNOSIS DATA!
Female, Asian, non-smoker, adenocarcinoma, lung cancer. All very simple and basic stuff!
What other patterns are waiting for us?