Stream: implementers
Topic: Cancer condition profiles
Amir Mehrkar (Jul 19 2016 at 23:33):
Hi group, I am a novice clinician to FHIR but learning fast. As CMIO for Orion Health I'm helping to drive an important vendor driven structured data Open Standards initiative in the UK called INTEROPen (@INTEROPenAPI / www.interopen.org). Akin to CommonWell in US.
Question: I've had a UK CIO approach me to ask about interrogating a UK cancer register in FHIR. I'm not entirely sure what the data model for that register is but has anyone used or come across any FHIR condition / cancer profiles other than http://hl7-fhir.github.io/condition-example-f202-malignancy.html
Grahame Grieve (Jul 19 2016 at 23:35):
Here's an Australian specification for cancer registry reporting - it's work in progress:
Grahame Grieve (Jul 19 2016 at 23:35):
http://fhir.hl7.org.au/fhir/rcpa/index.html
Grahame Grieve (Jul 19 2016 at 23:35):
but that might not at all be what you are interested in
Grahame Grieve (Jul 19 2016 at 23:36):
it's for labs reporting to cancer registries following the CAP/RCPA structured reports - extremely detailed, and disease specific
Amir Mehrkar (Jul 19 2016 at 23:45):
Thanks Grahame. Much appreciated for this. Will take a look.
David McKillop (Jul 20 2016 at 00:31):
@Amir Mehrkar FYI - the Royal College of Pathologists of Australasia (RCPA) have developed a number of cancer protocols:
https://www.rcpa.edu.au/Library/Practising-Pathology/Structured-Pathology-Reporting-of-Cancer/Cancer-Protocols
The link Grahame gave above is the output of the development work on 2 protocols (colorectal and radical prostatectomy) with trials to be done with some selected public and private pathology labs and a selected cancer registry.
The lead clinician is Dr David Ellis who is also President of the International Collaboration on Cancer Reporting (ICCR) and he would be collaborating with your UK colleagues on ICCR matters.
Anyway, have a look and if you have any queries, please be in touch.
Eric Browne (Jul 20 2016 at 06:25):
@Amir Mehrkar any decisions on approach should be governed by the requirements. Firstly, it will depend on whether the UK registry in question is a population registry or clinical registry or some other type. Population registries usually have very stable and well developed data dictionaries designed for aggregation and reporting purposes. They almost invariably use ICO/ICD coding standards.
The draft fhir work referred to by @Grahame Grieve and the 2 protocols referred to by @David McKillop are based on pathologists' views of the world and support transferring tumour case data from lab to cancer registry. They bear little resemblance to what and how data is stored in population cancer registries. It is very likely that much/most of the data will need to be manually translated and recoded once the data reaches the cancer registry taking part in the Australian project.
Having said that, the work being undertaken in Australia may well give you some valuable insight into how complex, tree structured data might be represented in FHIR.
Grahame Grieve (Jul 20 2016 at 06:33):
Eric, I agree that those reports represent a pathologists view of the world, and it might no be everyone's - that's what I was getting at about requirements. But I do think that if this is the data the cancer registries are getting, it will infliuence what they keep and publish
Eric Browne (Jul 20 2016 at 07:00):
@Grahame Grieve, I agree that it may well influence what is kept and published - in the longer term. I don't know enough about the UK, but the content of Australian population registries is often governed by legislative fiat - even Acts of Parliament. Statistical reporting needs to be consistent across years, if not decades, and hence the need for stable data dictionaries. Unfortunately, that culture, coupled with often shrinking funding also cements a reluctance to change and introduce new data items and new approaches to meet changing world needs and changing technologies.
Grahame Grieve (Jul 20 2016 at 07:07):
you're so cheerful Eric ;-)
Michael Osborne (Jul 21 2016 at 07:07):
There is an international push to standardise the Terminology around questions and answers in synoptic cancer reports. ICCR (www.iccr-cancer.org/) is one of the bodies, along with the RCP, RCPA,CAP-ACP,CAP and we teleconference regularly at the IHTSDO iPALM SIG. We are just kicking off a Working Group to look at reviewing the work of the iPALM chair -Scott Campbell and his fellow Univeristy of Nebraska MC colleague James Campbell, in encoding the 82 CAP synoptic reports types. If you are interested in participating (There are members of the UK TC and RCP on the call e.g. Deborah Drake and Laszlo Igali) please subscribe to the IHTSDO confluence page https://confluence.ihtsdotools.org/display/iPaLM and join the calls. This work has the support of the ICCR chairs. It has a good chance of becoming a full IHTSDO sponsored project IMHO.
Eric Browne (Jul 22 2016 at 03:10):
Thanks for providing this info @Michael Osborne It looks as bad as I thought, in that the interests of Cancer Registries do not appear to be taken into account sufficiently - just like the RCPA project here in Australia.
I’ll give a brief example - TNM stage classifications. An anatomical pathologist might record a stage of "T3a". That will likely get encoded, under proposed international ‘collaboration’, in SNOMED as "384988001 | pT3a: Extraprostatic extension (prostate)” in a field such as “synthesis_and_overview.tumour_stage.T_classification” or similar.
However, most cancer registries probably have a field for “pT staging” and expect to populate it with a value “T3a”. Note that the value capture by the pathologist (“T3a”) is probably the same form as might be stored in the Cancer Registry database, yet the canonical SNOMED-CT term is a compound construct, not used either by the pathologist herself, nor the Cancer Registry.
I’m not suggesting that SNOMED-CT should therefore not be used. But I am suggesting that by taking the needs of the Cancer Registry into account, the current ( and probably medium term ) form for storing TNM values might also be readily supported.
Grahame Grieve (Jul 22 2016 at 03:21):
I don't have a clue, from this, what need isn't taken into account? Unless the need is for them not to change at all
Stephen Royce (Jul 22 2016 at 03:26):
The problem is the same as when we discussed this with the RCPA: you don't want a code for "synthesis_and_overview.tumour_stage.T_classification", say, you want a code for just "tumour_stage" bound to a non-body-part-specific code set. You then have tables which record, maybe, that the "tumour_stage" question is used in the "synthesis_and_overview" section and you know it relates to the prostate, not via the terminology, but by an information model association to an anatomical location elsewhere in the model.
Grahame Grieve (Jul 22 2016 at 03:27):
I don't see how that is a requirements issue - rather, it's a bitch about solution choices
Stephen Royce (Jul 22 2016 at 03:31):
Yeah, well, that's debatable anyway -- this sort of thing lies on the boundary -- but even given that it's a solution, the problem is that this is the solution that's been chosen and it makes the useless to at least one sector of the community.
Grahame Grieve (Jul 22 2016 at 03:33):
I think we want non-cancer specific codes for stage too, but they're classification codes, so they shouldn't come from SCT. But I thought we were using noncancer specific codes - @David McKillop do you remember what we did about this?
Stephen Royce (Jul 22 2016 at 03:35):
We did go some of the way towards uncoupling this stuff, but I can't remember how successful we were.
David McKillop (Jul 22 2016 at 03:38):
I don't believe the RCPA are stating anything different to what the ICCR are saying in that the T,N,M tumour staging is different for each tumour type.
It would be a lot easier if the model was to use a generic T3a etc, but that's not what the pathologists want for coding the tumours - they want specific codes for each tumour type. @Matt Cordell is involved with the IHTSDO IPaLM group who discuss pathology terminology and are having discussions with other groups eg Nebraska (Scott Campbell).
To answer @Grahame Grieve question - the RCPA protocols are using cancer location specific SCT codes for tumour staging.
Stephen Royce (Jul 22 2016 at 03:50):
From what @Eric Browne's saying, it not even pathologists who want this, it's the theoretical pathologists who live in ivory towers who want it. Having formerly been an ivory tower resident myself -- some would say I haven't really moved out yet! -- I can attest to the beauty of these solutions, but the practicalities are somewhat different.
Stephen Royce (Jul 22 2016 at 03:53):
We face this tension constantly; it came up again here the other day in relation to allergies: should we record the fact that it's an allergy to a substance as 2 independent data items or a single SNOMED code? I think the former is more generally useful, but if you can actually do real reasoning, having a single SNOMED code is very handy.
David McKillop (Jul 22 2016 at 04:07):
I'll try to get someone from the industry to respond as I'm going on what information I'm aware of.
Yes - the pathology (Australian at least) industry was against structured reporting of cancer due to a number of reasons including:
- thought to be restrictive on pathologists prose
- lack of guidelines
However, a group in Ontario (I think they are the one's who have done significant work with structured reporting) have been able to show the benefits and the industry is coming around, including the cancer registries who will stand to benefit from the standardised information.
So what was theoretical is now becoming practical (Ontario experience) and the RCPA project is trying to produce an implementable form including standardising the terminology for tumour staging.
The terminologists did discuss the option of having generic codes for tumour staging (of which SCT does have some), but they elected for more informative terms for each specific field. If the terminologists are prepared to provide the more specific, more informative codes then I would have thought that that was a good thing rather than have generic codes that need to be bound to other fields indicating the tumour type.
I'll try to get input from the terminologists. @Matt Cordell @Liam Barnes and others from the RCPA.
Eric Browne (Jul 22 2016 at 04:20):
@David McKillop Ontario Cancer Care are world leaders in getting structured pathology reporting into their Cancer Registries. I have explored their solutions extensively. They use CAP eCC. They have a very knowledgeable, technical, HL7-literate, who has been working with CAP for years. i.e. the registry was well embedded in the requirements gathering, the solution design and the ongoing implementation. Please don't just hone in on the representation of stage ( most population registries in Australia don't even collect it yet, unfortunately ). The issue I'm flagging is a need to understand the requirements. Any solution will require adaptation and changes to the existing Cancer Registry infrastructure. Some solutions will minimise that change, even to the point of making ingestion of structured pathology viable in Australia. I would include understanding any necessary changes imposed on the registries through structured reporting, as part of requirements gathering.
Grahame Grieve (Jul 22 2016 at 05:14):
@Eric Browne perhaps you have some traction to encourage them to be involved. Often the problem is that it's not a pressing issue, so people don't become involved until too late (I don't know whether that is the case this time)
Eric Browne (Jul 22 2016 at 05:30):
You're so cheerful Grahame ;-)
Stephen Royce (Jul 22 2016 at 05:30):
David McKillop (Jul 22 2016 at 05:53):
David Ellis who has led the introduction of structured pathology reporting for cancer into Australasia, first as the inaugural chair of the National Structured Pathology Reporting for Cancer Project under the RCPA, Cancer Australia and Cancer Institute NSW, and now as President of the International Collaboration on Cancer Reporting (ICCR), which he also represents on the UICC TNM Staging Committee in Geneva. (copied from his bio) had the following comments:
Hi David,
I logged on to the FHIR chat site and found a lot of chat.
The things I can answer are:
1. The registries have been involved through Ca Institute NSW. Perhaps we need greater reach into the Aust Association of Cancer Registries.
2. TNM is cancer specific just as the other SPR field names/values/terminologies are. The commonality between different tumours is that they all use letters and numbers!I can send you staging protocols if you wish, to show how much the criteria differ by site/cancer.
Please let me know if the group needs more clinical input.
Eric Browne (Jul 22 2016 at 05:57):
Just going back to your point about "generic" stage, @David McKillop . TNM stage designations are specific to each cancer type. The context for a "T3a" is already given in the report from the pathologist that states the primary tumour being reported is, say a prostate tumour.
SNOMED-CT on the other hand is unlikely to have a single "T3a" concept description repeated under each tumour type parent, because it would have trouble with Fully specified name uniqueness, hence it pre-ordinates the 'p' for pathological and the prostate-specific description to form "pT3a: Extraprostatic extension (prostate)” as a complete description that can stand on its own. If I were designing a report for transmission, I would consider sending both a SNOMED-CT encoded value of the tumour stage as well as a simple "T3a" for cancer registry ingestion. But before designing a solution I would try to seek from at least the 8 state and territory registries (e.g. via the AACR) some sort of indication of their preferences. Notwithstanding @Grahame Grieve 's observations about non-pressing issues that I, too, have observed.
Grahame Grieve (Jul 22 2016 at 06:09):
yeah, Eric, you and I can go and be cheerful in the corner. btw, you going to be here in melbourne next week?
Last updated: Apr 12 2022 at 19:14 UTC
