Stream: implementers
Topic: Representing a Tumor
Mark Kramer (May 11 2017 at 08:49):
I'm trying to find a way to represent a tumor. It is not just an ID, but a persistent entity, tracked over time, with gross and microscopic properties (size, borders, etc.). What FHIR resource should I use?
Josh Mandel (May 11 2017 at 08:50):
What are your thoughts on BodySite ?
Mark Kramer (May 11 2017 at 08:52):
@Josh Mandel That might be the closest thing, but I'm a bit uncomfortable with the idea that a tumor is a body site. My naive interpretation of body site is a place in the body, like "left elbow". A tumor is more than a place.
Mark Kramer (May 11 2017 at 08:56):
In my thinking, a tumor might be located at a bodysite.
Josh Mandel (May 11 2017 at 08:58):
I think that's true @Mark Kramer. Perhaps a Condition with a condition.bodySite is the closest you'd get today.
Sunanda Veeraganti (May 11 2017 at 08:59):
Should we add another field located at to bodysite resource in future version of fhir?
Josh Mandel (May 11 2017 at 09:01):
I'm not sure I follow, @Sunanda Veeraganti. The link Mark's talking about is between a tumor (represented by ???) and its location (represented by BodySite).
Mark Kramer (May 11 2017 at 09:01):
@Sunanda Veeraganti I'm not sure I understand your suggestion. The bodysite itself is a location on or in the body. Do you mean to capture "what is found at this bodysite?"
Mark Kramer (May 11 2017 at 09:02):
Yes @Josh Mandel , and in some cases the same tumor can grow into different tissues over time, and effectively change its bodysite.
Josh Mandel (May 11 2017 at 09:03):
Indeed — though Condition.bodySite can point to multiple sites (it's 0..*), so that's model-able.
Mark Kramer (May 11 2017 at 09:03):
That 0..* makes me feel more comfortable with using Condition.
Josh Mandel (May 11 2017 at 09:05):
Yes, though at this point (and we're getting into philosophy, which you and I never seem to shy away from) we could ask whether the Condition really represents the tumor, or an overall cancer process.
Sunanda Veeraganti (May 11 2017 at 09:06):
@MarkKramer yes I mean to capture what is found at body site
Grahame Grieve (May 11 2017 at 09:06):
Condition is really 'a state of the patient'.
Josh Mandel (May 11 2017 at 09:07):
@Grahame Grieve yeah, this is where I'm going.
Mark Kramer (May 11 2017 at 09:07):
And a tumor is an entity in and of itself
Grahame Grieve (May 11 2017 at 09:07):
I think the correct answer is that we haven't really got the right resources for tracking the progression of a disease, and create a task for PC asking for such a facility
Stefan Lang (May 11 2017 at 10:06):
I'm currently in the same situation as Mark, regarding the representation of a tumor with all it's details. We also had a few words about that during yesterday's lunch meeting of the oncology group.
A tumor would consist of the diagnostic information at least, typically including ICD-10 of the main tumor, ICD-O morphology and location, metastatis, UICC/AJCC/TNM and a bunch of other classifications and pathology information.
Usually, in a specialized oncology documentation system, all these are bundled along with other information like tumor board decisions, therapies, follow ups, recurrence diagnosis and therapy and so on.
I'm not sure whether a special resource is needed here or if a Composition can/should be profiled to fulfill the requirements to put everything belonging to a certain tumor disease into one "bag".
One might then describe the main tumor diagnosis as a Condition, eventually using Condition.category to be distinctive against other Conditions that may be part of the tumor disease.
Stefan Lang (May 11 2017 at 10:08):
The other way around, the tumor Condition would indeed, like Grahame says, need a reference to something like "Disease", possibly using Condition.context.
Condition.context would need the cardinality increased to 0..*, since a condition might be part of an Encounter and of a Disease.
Stefan Lang (May 11 2017 at 10:11):
The whole question might also be applicable to other kinds of diseases, e.g. Multiple Sclerosis or in nephrology (dialysis patients)
Stefan Lang (May 11 2017 at 10:20):
When using Composition, that would have to be updated over time (years), while a distinct "Disease" resource might be more stable in terms of the data contained. But a "Disease" would needed to be referenced from virtually any other resource. So this would need enabling references everywhere (maybe the expanded Linkage resource, or a new Relationship (or similar name?) resource, that was discussed in PC yesterday
Grahame Grieve (May 11 2017 at 10:27):
I had also considered composition as a wrapper. But that's an 'authoring/publishing' wrapper, not a sematic wrapper that carries actual meaning
Stefan Lang (May 11 2017 at 14:40):
That's true. Still, there's much inthe description of Composition that would also fit for a Disease. Especially, for a long term disease it also applies that you have multiple stable documents generated from it over time, like tumor board protocols or several types of letters.
So at least there will be many similarities
Lloyd McKenzie (May 11 2017 at 14:53):
One of the major use-cases for BodySite was the notion of turmor. Another was patches of skin used in decision support. Lesions or moles is another. If it's something easy like "left elbow", there's no need for a resource instance to track that or group observations associated with it. BodySite is what allows you to capture measurements of a particular tumor over time, identify procedures that targeted a specific tumor, etc.
Lloyd McKenzie (May 11 2017 at 14:55):
Those two use-cases are why BodySite is a resource instance (with an id that can be referenced from other resources) rather than just a data type
Sadiq Saleh (May 11 2017 at 15:10):
We have been representing the cancer diagnosis as a condition, with things like the TNM score, etc. associated to the condition as Observations related to the condition through the extension event.reasonReference.
However I understand the distinction of trying to represent the tumor proper as a seperate entity with bodySite. It may be splitting hairs but as far as I understand it there are some observations about the tumor itself (size, necrosis, receptor status, etc.) while others (metastases, TNM, etc.) are in my opinion associated with the condition/diagnosis, but may have been derived from observations of the tumor mass
Stefan Lang (May 11 2017 at 15:43):
@Lloyd McKenzie A body site is certainly a relevant part of a tumor's description, but that describes only half of what ICD-O expresses. So this is rather a part of a bigger tumor entity than the head of a collection of the details I mentioned above
Stefan Lang (May 11 2017 at 15:54):
I also don't see how it would be better to reference to a BodySite's id than to a Condition's id?
Stefan Lang (May 11 2017 at 15:58):
Apart from that, there are tumors that have more than one location (e.g. with metastasis. bilateral tumors).
Basically, tumors are certain types of cells. And secondly, they manifestate at some location(s) of the body
Stefan Lang (May 11 2017 at 16:00):
That's why oncology systems, at least all that I'm aware of, use the diagnosis (often aka ICD-10) as the one central information
Stefan Lang (May 11 2017 at 16:06):
That would be a Condition, so at least to some extent similar to what @Sadiq Saleh described
Mark Kramer (May 11 2017 at 16:21):
@Lloyd McKenzie Let's get back to the issue. The use case I'm supporting involves measuring response to treatment, using a criteria called RECIST (response evaluation criteria in solid tumors). RECIST follows individual tumors (up to 2 per organ, up to 5 total). Measurements are taken to reveal how these tumors change over time. Observations must be linked to specific tumors. Another challenge is that tumors can split, two tumors can merge, and a tumor can spread to new parts of the body. If we can support the unique identification of tumors, so observations of size, receptor status, and other properties can be tracked over a period of months and years, then I'm good.
Lloyd McKenzie (May 11 2017 at 16:22):
Well, Procedures can't be done on Conditions, but they can be done on a BodySite. As well, in general, a patient with multiple lesions or tumors that are all tied to the same underlying type of cancer would typically be captured as one Condition, but multiple body sites (tumors/lesions) would be tracked for repeated observations, procedures and possibly substance administrations. BodySite is intended to represent any identifiable part of the body that can be the focus of a procedure, observation, drug administration, etc.
Sadiq Saleh (May 11 2017 at 16:24):
Point of clarification, though procedures can't be done on a Condition, they can be done as a result of the condition (reasonReference).
Sadiq Saleh (May 11 2017 at 16:30):
@Mark Kramer as far as I can understand your use case however, it would make sense to tie these Observation to a single bodySite resource. However, as I was alluding to before, not all Observations can be tied to an individual tumor but may refer to the cancer diagnosis as a whole. I think distinctions may need to be made for Observations that are lesion (individual tumor) specific vs those referring to the diagnosis as a whole. Thoughts?
Travis Stenerson (May 11 2017 at 16:31):
So the issue we have been having trouble with is that Observations allow for a reference to the subject (Patient) but don't allow for a reference to the target object of the observation. (This lesion has a diameter of 3 cm).. If Observation.bodySite were a reference to a BodySite, then you could allow for observations to pertain to a particular lesion within the same contextual disorder. As in, patient has breast neoplasm, two lesions, each lesion having distinct histology or genomic profiles. Though this doesn't quite cover metastatic disease, which we have also been capturing as a second Condition with a code denoting that that the lesion is secondary, however without a reference to the primary yet.
Mark Kramer (May 11 2017 at 16:35):
@Travis Stenerson Regarding the use of a BodySite resource with an Observation, the documentation on Observation.bodySite says: "Only used if not implicit in code found in Observation.code. In many systems, this may be represented as a related observation instead of an inline component. If the use case requires BodySite to be handled as a separate resource (e.g. to identify and track separately) then use the standard extension body-site-instance."
Mark Kramer (May 11 2017 at 16:36):
I find that rather lame. How do you reliably find the tumors you are tracking via RECIST?
Mark Kramer (May 11 2017 at 16:40):
So, we have arrived at solution, but a rather inelegant one, in my opinion: (1) Use BodySite to uniquely represent a tumor entity located at a body site, and use the body-site-instance extension to link observations to that BodySite.
Grahame Grieve (May 11 2017 at 16:45):
I don't think that's the final word here
Grahame Grieve (May 11 2017 at 16:46):
I thought that the Observation extension http://hl7.org/fhir/StructureDefinition/observation-focal-subject should be part of the solution but I see from it's definition that it's not quite what we want
Grahame Grieve (May 11 2017 at 16:47):
I thought genetics had also dealt with 'which tumour an observation is on'
Travis Stenerson (May 11 2017 at 17:04):
Yes that extension seems to cover what I meant. Though I see some crossover between Condition.extension:targetBodySite and this standard extension 'body-site-instance' in the case of Condition's body site reference for a specific lesion.
Travis Stenerson (May 11 2017 at 17:06):
Or was targetBodySite meant for cases like an autoimmune disorder literally targeting a particular anatomic site?
Grahame Grieve (May 11 2017 at 17:13):
I think that using a body site as the focal subject of an observation is more specific than observation body site
Lloyd McKenzie (May 11 2017 at 17:16):
targetBodySite is horribly defined - or more specifically, not defined at all. I can't think of a use-case for both extensions being necessary. I've submitted a change request to either clarify the distinction or remove this extension. GF#13393
Travis Stenerson (May 11 2017 at 17:16):
I agree, that was my understanding of focal-subject, but I moved on from it because it was a codeableConcept and is a modifier extension.
Mark Kramer (May 11 2017 at 17:17):
Yes, the data type of observation-focal-subject is CodeableConcept. That doesn't get us there. It has to refer to a specifically identified tumor.
Grahame Grieve (May 11 2017 at 17:18):
I think it has the right semantics in the definition but the wrong data type. Want to make a change request?
Mark Kramer (May 11 2017 at 17:19):
To what? Reference(Any)? And then define Tumor as a profile on BodySite?
Lloyd McKenzie (May 11 2017 at 17:19):
Mark, looking at the resource, it seems we should probably have a "kind" element or something like that added to BodySite so you can not only query for all BodySite instances for a patient, but can also filter to only see tumors, lesions, fetuses, skin patches, etc.
Mark Kramer (May 11 2017 at 17:20):
I believe that is what @Sunanda Veeraganti was suggesting at the top of the thread.
Lloyd McKenzie (May 11 2017 at 17:21):
Travis Stenerson (May 11 2017 at 17:32):
focal-subject's definition is right yes. I could see this as Reference(BodySite) and Reference(Condition). ie: This patient's diabetes is well controlled.
The other item I contended with when representing tumors is Recurrence and Remission, which is somewhat covered with Condition.onset and Condition.abatement, but there are clinical decisions made relative to which recurrence of the disorder this is, first or second etc, and onset and abatement are both 0..1. Anyone have suggestions on covering the history of tumor remission?
Stefan Lang (May 11 2017 at 17:33):
The "kind" element sounds reasonable, though I still think that the term "body site" is not appropriate for what is actually to be expressed.
Also, would that mean to drop Grahame's idea ?
Stefan Lang (May 11 2017 at 17:43):
@Travis Stenerson The remission history imho would be easily represented in a "Disease" resource, referencing a Condition with clinicalStatus=recurrence .
I would leave it to business logic ordering them by date to actually get 1st/2nd/... recurrence
Lloyd McKenzie (May 11 2017 at 17:43):
@Stefan Lang What would be a more appropriate name for something that includes tumors, lesions, moles, fetuses, skin patches, etc.? We argued about it for quite a while when defining the resource, but aren't opposed to more intuitive names. I'm not thrilled with expanding focalSubject because I can hypothesize situations where both focalSubject and target-body-site could be relevant.
Mark Kramer (May 11 2017 at 17:45):
I propose AnatomicalStructure or BodyStructure. A structure such as a tumor might have a BodySite, could be related to other body structures, etc. It is in addition to, not a replacement for, body site.
Stefan Lang (May 11 2017 at 17:49):
BodyStructure sounds at least better to me. Site is really strongly associated with location
Travis Stenerson (May 11 2017 at 17:50):
AnatomicalStructure or BodyStructure would kind of align with SNOMED too.
Travis Stenerson (May 11 2017 at 17:55):
@Stefan Lang The issue we thought about with that is will this Disease be represented as a novel Condition resource on recurrence? I know when I would look at medical histories, I wouldn't see multiple instances of breast cancer but just a single one. I'm not sure how FHIR would expect a single disorder's historical occurrences to be represented.
Josh Mandel (May 11 2017 at 17:55):
"BodyStructure" would be the clearer of the two, I think (aligns with SNOMED and avoids the question of anatomical vs pathological)
Josh Mandel (May 11 2017 at 18:01):
SNOMED's BodyStructure is quite broad though (anything from a rash to a knee to a tumor). If we pursued this, we might just have BodyStructure and use it for both cases (so a "Tumor" BodyStructure might be locatedWithin (or something) a "left knee" BodyStructure).
Lloyd McKenzie (May 11 2017 at 18:16):
Anyone who wishes can submit a change request to rename BodySite to BodyStructure. I'd be in favor of the change, but I don't want to dominate the change-request creation process :)
Lloyd McKenzie (May 11 2017 at 18:17):
There's nothing that would stop BodyStructure from being used to represent "left knee" other than the fact that it's already identifiable just with a code. BodySite is really for those things that can't be uniquely identified just with a code.
Josh Mandel (May 11 2017 at 18:27):
The proposed changes would be two, though: a rename, and the addition of a BodyStructure.locatedAt --> Reference(BodyStructure), or something like that
Lloyd McKenzie (May 11 2017 at 18:29):
Add locatedAt to what?
Josh Mandel (May 11 2017 at 18:32):
(Clarified in an edit)
Grahame Grieve (May 11 2017 at 18:56):
Mark appeared to propose an additional resource, not a rename
Josh Mandel (May 11 2017 at 18:59):
@Mark Kramer after this discussion, what're your thoughts?
Travis Stenerson (May 11 2017 at 19:26):
So with this proposal, a confirmed case of lets say invasive ductal breast carcinoma would body Condition with code: IDC of Breast, and Condition.bodySite as a reference to BodyStructure with code: lesion of breast, qualifier: [inner outer quadrant, left breast].
I guess what I mean is which of these two related resources should bear the specifics of the lesion. This patient has Condition: Neoplasm of Breast with BodyStructure: Invasive Ductal Carcinoma, qualifier left breast. Or vice versa. Or is that left up to the implementer and the ontology bindings they want to use?
Lloyd McKenzie (May 11 2017 at 19:33):
In principle you could have multiple BodyStructures tied to one condition. Certainly guidance could be provided about "good practice" in terms of how terminologies should be used, but I'm not sure we can enforce that globally
Stefan Lang (May 11 2017 at 20:20):
From the above discussion I would rather expect the need for multiple conditions (like new tumor/1st/2nd/... recurrence) bound to one BodyStructure. So that would be resolved through the body-site-instance extension
Stefan Lang (May 11 2017 at 20:21):
(Which would have to be renamed to body-structure-instance, obviously)
Stefan Lang (May 11 2017 at 20:49):
GF#13396 for renaming BodySite to BodyStructure
Stefan Lang (May 11 2017 at 21:09):
Looking into http://build.fhir.org/extension-body-site-instance.html
"Body Site Instance: Record details about the anatomical location of a specimen or body part [...]"
This is clearly location related. So, the semantics need to be redefined, since, as we concluded above, a tumor is _not_ a location.
Stefan Lang (May 11 2017 at 21:16):
Maybe this is leading too far, but I'd like to point to the domain analysis we did in Germany years ago for the CDA oncology implementation guide. It's in German, but should be fairly understandable:
http://wiki.hl7.de/index.php?title=IG:%C3%9Cbermittlung_onkologischer_Daten#Dom.C3.A4nen-Analyse_Modell
Stefan Lang (May 11 2017 at 21:21):
Leaving aside adminstrative data for the moment, we basically have (including my ad-hoc mapping to FHIR resources):
- disease ("Erkrankung") => Body[Structure|Site] (?)
- procedure ("Prozedur") => Procedure
- result ("Ergebnis") => Observation
- phenomenon ("Phänomen") => Condition
and of course a lot of detailing when it comes to medication (represented by the medication resources) etc.
Stefan Lang (May 11 2017 at 21:29):
So, if all the relations in that model can be represented in FHIR (and that is to be analyzed), I'd be happy to agree with BodyStructure representing a tumor as such.
Stefan Lang (May 11 2017 at 21:34):
(Location, btw, is part of the phenomenon in that model, just as in Condition.bodySite)
Richard Townley-O'Neill (May 12 2017 at 02:23):
I think that tumours and the newly renamed BodyStructure resource are rather like an un-excised specimen.
The proposed designs treat each tumour as a distinct location of a condition: body-site (location) is enhanced to become body structure.
Another approach would be to consider a tumour as an object (like a specimen) which has a location and is part of a condition.
Is this useful?
Eric Haas (May 12 2017 at 05:03):
Grahame - focal subject's scope shrunk a lot because originally it overlapped with other elements such as BodySite that were added.
Grahame Grieve (May 12 2017 at 05:11):
well, I remember that it definitely could refer to the focal subject by identity not just concept - I don't think that overlaps
Eric Haas (May 12 2017 at 05:19):
Mark nothing lame about how body site is currently defined and used. Most of time the body site is part of a pre coordinated observation code and otherwise a .bodysite code works just fine. Accessing the bodysite resource via an extension is there for a use case like this and its the first time use case based trackers have come up for it - not counting the many attempts to get rid of the resource all together.
Eric Haas (May 12 2017 at 05:27):
Well nobody has raised an issue on focal subject that its too narrowly defined so either its never being used because its too narrowly scoped or it s just right.
Lloyd McKenzie (May 12 2017 at 08:07):
Specimen is about a portion of the body that has been removed. And so there's a bunch of information about the removal that's relevant. BodySite/BodyStructure is about a portion of the body that's in place. Specimen will have a bunch of information about additives, transport and other things that aren't relevant for the BodySite/Structure
Tilo Christ (May 12 2017 at 08:12):
I had to transmit lung tumors in a project last year from a viewer to a reporting system, using FHIR. Since this was previous to this thread, I opted to use Observation as my base-Resource. I represented the properties of the tumor in components (diameters, shape, etc.) and added an extension for the long-term tracking identifier. My main challenge were not my doubts about whether I was using the proper Resource type, but the many missing codes in SNOMED, LOINC, RadLex, etc. to express the many properties of the tumor in a non-proprietary manner.
I am looking forward to the outcome of this thread and might reshape my output based on it. But I think for true interoperability between systems which handle tumor data, one would have to request a plethora of codes from LOINC, etc.
Eric Haas (May 12 2017 at 10:26):
I originally used the OpenEHR archetype to create it, but we shrunk it way down after that removing most of the properties. So if there is a need to add back take a look at that or an early version FHIR Probably pre -DSTU2
Travis Stenerson (May 12 2017 at 15:09):
One of the reasons I overlooked the focal-subject extension is because it was a modifier extension, and being new to FHIR, the documentation made it seem like that's a rather bad idea for developers hoping to work with multiple vendors.
Lloyd McKenzie (May 12 2017 at 19:45):
That's a good reason to be cautious of it. But the meaning doesn't really match either. Focal subject lets you communicate the heart rate of a fetus or the blood type of a donor and have that Observation on the patient's record. In both cases, the observations aren't "about" the patient - they're about someone/something else. But a tumor type measurement or dimension measurement are still properly "about" the patient, so that's not a modifier - and thus helps indicate that the extension isn't the correct thing to use.
Michael Osborne (May 13 2017 at 06:41):
@Tilo Christ Hi Tilo. There is a lot of working going on at the moment, mainly driven by an NLM grant to the University of Nebraska Medical Center to create terms to map to the CAP protocols. There is standardisation work going on internationally (ICCR) which involves many colleges of pathology and UNMC. For the cutting edge, I direct you to the SNOMED CT international confluence pages: https://confluence.ihtsdotools.org/display/iPaLM/Cancer+Synoptic+Subgroup . You will need to create an account there if you don't already have one. Essentially the team at UNMC are encoding the CAP cancer worksheets (synoptic reports) with fully modeled SNOMED CT concepts and then submitting them to both SNOMED international and LOINC. So the codes will be LOINC and there will be Observable expressions in a reference set map which will be published jointly by SNOMED International and Regenstreif.
Mark Kramer (May 13 2017 at 18:23):
Let me try to sum up my point of view: (1) We need to rename and broaden the definition of BodySite to BodyStructure. (2) In Observation, add Observation.BodyStructure (Reference(BodyStructure). I personally don't think Observation.BodyStructure should be an extension. If we keep Observation.BodySite (CodeableConcept) then we need an invariant that says you can't use both BodySite and BodyStructure. (3) We do not need to change the Observation's focal subject - I agree with Lloyd, the subject is the patient, not the tumor.
Stefan Lang (May 13 2017 at 18:42):
I agree completely with Mark's (1) and (3).
Regarding (2): there will be a lot of other resources that need to point to BodyStructure, e.g. when describing surgery or medication and I doubt these will be in the 80% scope, so an extension may be fine.
Also, as a second thought on the proposed invariant, how would one describe that an observation is about a brain metastasis that's part of a breast cancer? So better leave that open and, if needed, constrain it within a profile.
Sunanda Veeraganti (May 15 2017 at 07:25):
@MarkKramer Regarding (2) Are you proposing there should be an exclusion of Body structure if Body site is used?
René Spronk (May 16 2017 at 08:46):
Joke for HL7 v3 old timers: ask Barry Smith - this is very reminiscent of the kind of issue he always raised when pointing out supposed semantic flaws in the RIM. Does the 'observation' (of the tumor) exist, or does the Tumor exist (because I observe it)? No wonder this thread (again) attracts a lot of posts..
There is no perfect answer, HL7 modeling tradition has it that a Timor doesn't exist as such in the modeling space (as an entity), only the observation thereof.
Sadiq Saleh (May 16 2017 at 13:29):
@René Spronk please excuse my naivete in this matter, but I don't quite agree with the statement that the tumor only exists because we observe it. The tumor is a physical specimen that is a part of the body (till removed), that has specific observations that can be associated to it (e.g. size, receptor status, mutations, etc.). The only differentiating factor between a tumor and other body structures (e.g. the heart) is that it is not obligate that all patients will have a tumor structure to be identified.
The condition of "cancer" on the other hand exists only because of the symptoms presented as a result of the development of a tumor mass, and only exists when we "observe" it. But is this not true of all conditions?
Travis Stenerson (May 16 2017 at 15:03):
We had some back and forth on that exact idea. Observation vs existence. If I remember my HL7 Standards class, the idea was that we don't ever 'know' in medicine, even with a gold standard test you aren't always certain. You might have a large tumor and symptoms of lung neoplasm. This tumor could be 3cm across, and some enlargement of the local lymphatics. Then you open the patient up and it turns out to be a giant ball of fungus, an aspergilloma. Yes we 'observed' a tumor, but that was simply what we saw on imaging, not what was true.
Richard Townley-O'Neill (May 17 2017 at 01:06):
Do extra toes (e.g. I have an infection of a 6th toe) exist? or are they also bundles of observations?
René Spronk (May 17 2017 at 14:56):
@Sadiq Saleh I have no desire to hold the same philosophical discussion all over again, I'm just having a deja-vu moment. I do hope you find a workable solution, whatever it is. We found one in v3, so I'm sure you'll find one in FHIR.
Lloyd McKenzie (May 17 2017 at 15:29):
@Mark Kramer The decision of core vs. extension is driven by whether most systems that support Observations will support the concept of an independently managable BodyStructure. Obviously it's "core" for oncology (and for a few other areas), but there's been lots of pushback about it being core for Observation as a whole.
Travis Stenerson (May 23 2017 at 19:36):
So our use case is kind of requiring a good representation of a tumor sooner than BodyStructure is available and I might profile BodySite to do so. I'm just juggling code, qualifier and possibly an extension to represent morphology (either histological or gross in the case that no definitive pathology is defined). So my question is to those of you who are in agreement with this BodyStructure. Should code remain specific to the site, or should code represent 'what' it is.
code: apex of left lung
extension: associatedMorphology: Large cell carcinoma (morphologic abnormality)
or
code: Large cell carcinoma (morphologic abnormality)
qualifier: apex of left lung
or
code: Large cell carcinoma of lung (disorder) [to me it seems a bit discordant to use a disorder code in a BodyStructure]
qualifier: apex of left lung
Does anyone intending on using BodyStructure to represent a tumor lean a particular way?
Stefan Lang (May 24 2017 at 06:47):
I'm currently thinking of BodyStructure as a generic point of reference, where all other information about the tumor should point to. So, as discussed somewhere above, I would rather fill it with either some generic code for the tumor (like "breast cancer", "lung cancer" and so on) or an ICD-10 code (though that would rather be a condition).
At least, morphology and location are just observations related to the tumor, but subject to change over time.
Lloyd McKenzie (May 24 2017 at 13:23):
The definition of BodySite.code already indicates what should go there. The "kind" of thing will need to be a distinct element.
Stefan Lang (May 24 2017 at 13:48):
@Lloyd McKenzie So, as long as BodyStructure and especially BodyStructure.kind ist not available, better use an extension for kind within BodySite?
Travis Stenerson (May 24 2017 at 14:29):
Ah good points, thank you for the replies. Definitely histology should be an observation. I'm going to keep the cancer type in the condition, have condition reference multiple body sites (including in the case of mets), with the body site code and qualifiers only representing the location. The active field will be used to represent whether that tumor still exists (or has been excised or resolved through treatment).
I'm wondering if a tumor being secondary should be denoted somewhere. M category shows that it has metastasized, and it might reference two unconnected BodySites, but in this situation I can't tell which was primary and which was secondary, particularly where it metastasized to the other breast or other lung (maybe something with timestamps but thats not obvious). Should mets be a second Condition?
Were you guys thinking 'kind' would be 'required' bound to a simple value set like [anatomicalStructure, morphologicalAbnormality], or an extensible CodeableConcept that an implementer could bind to a concept like 'metastasis from malignant tumor of lung'?
Stefan Lang (May 24 2017 at 14:36):
Since BodyStructure (or the current BodySite) has such a flexible definition, I would see BodyStructure.kind as a CodeableConcept with just an example binding.
Granularity may vary, "metastasis from malignant tumor of lung" being on the more distinctive end.
Lloyd McKenzie (May 24 2017 at 14:37):
@Stefan Lang Yes, use an extension for now. @Travis Stenerson, I'm not sure if it should be mandatory on the resource overall. We're very cautious about mandatories. But it would certainly make sense to require it in an oncology profile.
Eric Haas (May 24 2017 at 14:48):
here is the current proposal on the BodyStrucure ( nee BodySite).kind element. Is being voted on tomorrow. (If you are interested in changes to the resources can track them here or login to GForge or join the Listserve for the appropriate workgroup- in this case OO.)
Travis Stenerson (May 24 2017 at 18:56):
What's the full title of that group Eric? I'm having trouble finding it.
Would this 'kind' field be better titled as 'type' (aligns with Sequence resource)? or maybe 'category' (aligns with a few other resources)?
Eric Haas (May 24 2017 at 18:59):
Orders and Observations Work Group and btw anybody welcome to lob comments on the tracker as follow-ups. :-)
Eric Haas (May 24 2017 at 19:02):
I am proposing the element name category. 'kind' and 'type ' and 'code' are all intertwined in meaning so I tend to stay away from them.
Lloyd McKenzie (May 24 2017 at 20:56):
This feels different from the other places we've used "category" which is as a filter for user interface/software functionality - separating labs from imaging from vitals seems quite distinct from separating skin patches from tumors from fetuses. To be honest, my real leaning would be rename BodySite.code to BodyStructure.location and then use BodyStructure.code to identify the "kind" of structure. Seeing as the resource hasn't been heavily used that sort of radical change is probably reasonable at this time.
Lloyd McKenzie (May 24 2017 at 20:57):
For R3, we'd need to have an extension for the "kind" though and would need to put the location information in BodySite.code.
Eric Haas (May 24 2017 at 21:02):
OK -that sounds like a reasonable approach. So renaming code to location opens up using kind too. I'll make the updates and pull from the block to vote on separately
Eric Haas (May 24 2017 at 21:33):
so looking at this again. I thought the intent with kind was to broadly categories the context for identifying the site. so tumor, skin patch, bodysite which is how I dispositioned it. What does kind mean?
- a granular code for a specific morphology like a mast cell tumor
- a code to say its a tumor being tracked. ( ie a categorization)
If the latter - then I agree with Mark that the resource is lacking some more stuff like a human readable label ( " mast cell tumor -1" ) and a another element to say what it is we are tracking ( a mast cell tumor).
Travis Stenerson (May 25 2017 at 14:19):
Code might be preferable to represent what it is, like morphology or just like benign neoplasm, lesion NOS, malignant neoplasm, fetus.
It would be a bit odd to have code: uterus, kind: fetus. Most places in FHIR that I work with, code has represented the 'what'. Though this might make the 'qualifier' field a bit ambiguous.
Another point though is that the 'what' is subject to change with tumors, which was pointed out above. A nevus can become a melanoma, an in situ tumor invasive.
Eric Haas (Jun 15 2017 at 23:12):
I've reworked the disposition for BodyStructure.kind here. Feedback sought before bringing up at the OO workgroup call
Richard Townley-O'Neill (Jun 16 2017 at 04:33):
Be careful that the descriptions make it sufficiently obvious that the design supports the common case of specifying a location without saying that there is some abnormality there.
Travis Stenerson (Jun 16 2017 at 17:31):
And probably make sure that qualifier is explicit that it qualifies location, not code. But that looks good.
Eric Haas (Jun 20 2017 at 16:14):
Appreciate the earlier comments. I preapplied the tracker for BodyStructure.kind to give and idea what the proposed disposition would look like. Note the new element is .code and the old .code is now .location with a bunch of cascading edits to the other elements to align it all up. Not approved yet. Feedback welcome.
Eric Haas (Jun 20 2017 at 16:17):
see how is applied to the example and here ( any better examples would be welcome too)
Richard Townley-O'Neill (Jun 20 2017 at 23:47):
Maybe "morphology" is a better name than "code", it is more informative. Also "code" suggests that this is THE central concept, but when specifying a location without mentioning an abnormality code/morphology is unimportant.
And "qualifier" should be "locationQualifier".
Is there a need for "morphologyQualifier"? I have no idea.
Lloyd McKenzie (Jun 20 2017 at 23:52):
We're not necesarily talking about abnormalities. Skin patches, fetuses, etc. wouldn't be abnormalities. As well, we generally try to keep our terms simple when we can.
Richard Townley-O'Neill (Jun 21 2017 at 00:01):
I think that "morphology' just means "shape", not "abnormal shape", and the offered definition for "code" is "morphology".
Travis Stenerson (Jun 21 2017 at 03:19):
Morphology is subject to change, nevus to melanoma, well differentiate to poorly differentiated adenocarcinoma, fetus to whatever they turn into? Though it would be convenient to have that morphology in the tumor instance, we were leaning towards having a tumor histology observation reference a tumor through the body-structure extension. Though I'm torn as our implementation would be a bit simpler if the histology was encoded in BodyStructure.code. I'm looking forward to seeing how the Cancer DTR group looks toward modelling BRCA.
Last updated: Apr 12 2022 at 19:14 UTC
