Stream: implementers
Topic: Diagnosis/Patient's diagnosis?
Jose Costa Teixeira (Sep 27 2017 at 06:09):
Hi. Perhaps I am missing the obvious, but how do i inform about a diagnosis in a) non-patient-specific and b) patient-specific scenarios?
Jose Costa Teixeira (Sep 27 2017 at 06:12):
Examples:
a) these are the infections that this medication treats (so if I have a medication resource, i can link to some established resources or code sets)
b) patient has this kind of infection with these bacteria.
Jose Costa Teixeira (Sep 27 2017 at 06:13):
condition seems to be patient-specific only so only works for b, and the description of condition seems to be circumstancial things about the patient, rather than an asserted diagnosis.
Observation also would be patient-specific.
Jose Costa Teixeira (Sep 27 2017 at 06:14):
for a), should we work with only the code as an attribute ? that may be limiting if the adopted terminology does not support some nuances that we may want to use
Jose Costa Teixeira (Sep 27 2017 at 06:16):
for example, icd-10 code for kidney cancer is just one, but we'll likely need a few variants
Jose Costa Teixeira (Sep 27 2017 at 06:25):
use case for a): catalog of treatments per disease
Lloyd McKenzie (Sep 27 2017 at 15:01):
Scenario A is about Medication knowledge/master-file type information and could include not just what conditions, but whether it's recommended as a first line or second line treatment, what the recommended dosages are, what clinical evidence supports those recommendations, etc. Pharmacy is working on a MedicationKnowledge resource that should tackle some of this. It would certainly reference the diagnosis as a code, not as a reference to Condition which is indeed intended to be patient-specific.
Jose Costa Teixeira (Sep 27 2017 at 20:33):
that information is something i expect in a catalog, as curated information by some entity for a specific context. We shouldn't to say 'this drug is for that condition' but rather 'in this context, this drug is for that condition'.
assuming that there should be a common construct for catalogs, instead of each domain specifying their catalog formats, then this can indeed be an attribute, but the concept of Condition seems so clear that it could make sense to have it separate, no?
Lloyd McKenzie (Sep 27 2017 at 21:05):
Cataloguing it is a use-case. But it should be possible to pass the knowledge information around independent of whether you've got a catalog. I'd like to see some consistency/re-use of structures that we use to capture knowledge around substances, medications, devices, orderable therapies, protocols, etc. Whether we can fit that into a single resouce seems unlikely though.
Lloyd McKenzie (Sep 27 2017 at 21:08):
As an example of reuse, I'd expect pointers to PlanDefinition to talk about recommended therapy uses.
Jose Costa Teixeira (Oct 03 2017 at 19:12):
@Lloyd McKenzie I'm not following. You mean we'd have a way to say "by the way, this is the full definition of this medication/device"?
Lloyd McKenzie (Oct 03 2017 at 19:30):
I'm saying that I think having a supplemental resource for Medication that represents MedicationDefinition or MedicationKnowledge makes sense. I'd then expect that resource to be leveraged in the regulatory, knowledgebase and cataloging use-cases.
Jose Costa Teixeira (Oct 03 2017 at 19:40):
The approach behind the "catalogEntry" (name can surely be challenged, since it was made just for the original purpose) was to have a "here's some definitionalstuff about this entry - additional attributes and any extra relations"
Jose Costa Teixeira (Oct 03 2017 at 19:41):
thus extending attributes to things like price with tax, price without tax, price for regimen A, whether it can be sold for use outside hospital, schedule (if that applies)
Jose Costa Teixeira (Oct 03 2017 at 19:43):
and creating a graph of things like medication-substance relation, drug-food interaction, drug-diagnostic relations (both indications or contraindications)
Jose Costa Teixeira (Oct 03 2017 at 19:44):
that is the part in the catalog that provides additional contextual information (concrete definitions or more extended knowledge)
Jose Costa Teixeira (Oct 03 2017 at 19:44):
the rest of the catalog is just a curated list - well, actually composition but pretty close :-)
Jose Costa Teixeira (Oct 03 2017 at 19:52):
the use case I have at hand is treatment protocols. if we want a catalog of treatment protocols for a simple disease, doesn't it start making more sense to start considering the indications or usage as a resource which exists on its own, instead of an attribute of another resource?
Lloyd McKenzie (Oct 03 2017 at 19:53):
Catalogues can have different purposes and contain different types of information. I'd expect cost information to be handled by a BillableItem type resource that includes the price, effective period, link to the associated resource and qualifying information - who the price applies to. It could be passed in conjunction with resources in a variety of situations - including catalogue uses. Similarly I'd expect a MedicationKnowledge resource to include information about ingredients, known side effects, links to recommended protocols. A catalogue might include some combination of those resources.
Lloyd McKenzie (Oct 03 2017 at 19:54):
I don't understand your last sentence. What do you mean by "node in the graph, instead of an attribute"?
Jose Costa Teixeira (Oct 03 2017 at 19:54):
so far so good. agree.
Jose Costa Teixeira (Oct 03 2017 at 19:55):
ah sorry, had the wrong neuron activated. the disease is a code value. So to express it we use an attribute in the resources
Jose Costa Teixeira (Oct 03 2017 at 19:56):
the idea is that if it became a resource, then we could link to it using our "graph" construct.
Jose Costa Teixeira (Oct 03 2017 at 19:57):
difference between being an attribute of a resource (no lifecycle outside of it) and a resource.
Lloyd McKenzie (Oct 03 2017 at 20:02):
Well, at some point we might have a resource for "ConditionKnowlege" too, but I expect the linkage will always be via the code.
Jose Costa Teixeira (Oct 03 2017 at 20:02):
"Similarly I'd expect a MedicationKnowledge resource to include information about ingredients, known side effects, links to recommended protocols. A catalogue might include some combination of those resources." - that is exactly what we want - those things that you mention can either be attributes or links to other resources. Given the wealth of information expected, links would be more adequate
Jose Costa Teixeira (Oct 03 2017 at 20:03):
e.g. a link between a drug and a condition can be: indication or contraindication. A link between a drug and another can be interaction, any kind of combination...
Jose Costa Teixeira (Oct 03 2017 at 20:04):
Exploring all possibilities seems a long, path and would always need extensions since databases have different information supported.
Jose Costa Teixeira (Oct 03 2017 at 20:06):
so, we have a graph that can link things. This was meant for the catalog, but would be good to reuse for any other purpose where we have to convey additional information
Jose Costa Teixeira (Oct 03 2017 at 20:08):
the starting point for this was a treatment protocol linking to diseases or intended uses of that protocol . e.g. http://build.fhir.org/plandefinition-example-kdn5-simplified.json.html
Lloyd McKenzie (Oct 03 2017 at 20:12):
I would expect things like indications and contraindications to be explicit elements. Conformance is much easier to manage that way than pushing things down into codes. The set of relationships that are supported by most systems isn't going to be that large. And edge cases can be handled using extensions as usual.
Jose Costa Teixeira (Oct 03 2017 at 20:14):
That sounds very good. I think that indeed, relationships are not that big, and it is easier to maintain a code set of "relationshipTypes" in the graph (catalogEntry) than to make a new extension for each new relation in the resources.
Lloyd McKenzie (Oct 03 2017 at 20:16):
We would rather have new extensions than a value set
Jose Costa Teixeira (Oct 03 2017 at 20:17):
why?
Lloyd McKenzie (Oct 03 2017 at 20:17):
Anyone can create their own extensions and it's easy to profile those. Profiling value sets and maintaining a shared set of codes is much harder for the edge cases.
Lloyd McKenzie (Oct 03 2017 at 20:18):
With FHIR, we've got a built-in name-value pair mechanism with extensions
Lloyd McKenzie (Oct 03 2017 at 20:18):
So unless there are a lot of "core" relationship types, we tend to avoid using codes to disambiguate them.
Jose Costa Teixeira (Oct 03 2017 at 20:18):
with that in mind, and if you see the catalogEntry as a "wrapper" to provide definitional and contextual information about a resource, would it help to rename CatalogEntry to e.g. entryDefinition?
Jose Costa Teixeira (Oct 03 2017 at 20:20):
ok, i was thinking of the code set for relation types: it can be a preferred binding, with some core values "...contains, requires, interacts with, to be mixed with..." - which is what i thought is better than having each of those in the resource
Lloyd McKenzie (Oct 03 2017 at 20:21):
I'm not convinced we should have CatalogEntry at all. In general, "wrappers" are something we tend to avoid in FHIR.
Jose Costa Teixeira (Oct 03 2017 at 20:21):
i know. let's consider that as a scaffold or something that simply serves to show the requirements.
Lloyd McKenzie (Oct 03 2017 at 20:22):
Contains would need to be an element as it would presumably want to indicate quantity, or possibily a "does not contain" attribute. Interacts with would likely require an explaination of "how". Etc.
Lloyd McKenzie (Oct 03 2017 at 20:22):
So leaning even further towards explicit elements.
Jose Costa Teixeira (Oct 03 2017 at 20:23):
indeed, catalog will eventually require these.
Jose Costa Teixeira (Oct 03 2017 at 20:24):
I don't feel comfortable with not having some sort of flexible mechanism for expressing relations and attributes (and attributes of relations indeed)
Jose Costa Teixeira (Oct 03 2017 at 20:25):
can't really pinpont to my discomfort but it hurts somewhere...
Lloyd McKenzie (Oct 03 2017 at 20:26):
What's more flexible than extensions?
Jose Costa Teixeira (Oct 03 2017 at 20:31):
i think it is about governing all that, making things predictable so that different implementers will not have opposed ideas on how to handle it. But i won't figure out the issue until I see a solution.
Jose Costa Teixeira (Oct 03 2017 at 20:36):
one question that could appear: what resources would we extend? is there a risk of overlap? Say you have a medicationResource, and PharmaceuticalProduct resource (if that is defined by BRR, to cover IDMP). where would you express "this product contains this substance"? Normally I would put this in the BRR resource for regulated products. Not sure how i would do it for other products.
Lloyd McKenzie (Oct 03 2017 at 20:37):
Having it be codes doesn't help if implementers can create their own codes - which they'd need to be able to do.
Lloyd McKenzie (Oct 03 2017 at 20:38):
Medication already reflects containment. I expect MedicationKnowledge will do so too, though probably at finer granularity.
Jose Costa Teixeira (Oct 03 2017 at 20:39):
True - but if they have a previously populated list of codes, it is easier to see if something is there already. Possibly I think I have a working approach (the Catalog discussions reinforce my faith) but it's not easy to reconsider paradigm until a solution starts being visible even if fuzzy.
Jose Costa Teixeira (Oct 03 2017 at 20:39):
I do think the "medicationKnowledge" is a scope trap because of these aspects but that is not this discussion.
Jose Costa Teixeira (Oct 03 2017 at 20:42):
the contained substances are defined at the regulator side, and i believe in a peaceful coexistence between those resources. medication is clinical, so does not have to repeat the regulated information, right?
Jose Costa Teixeira (Oct 03 2017 at 20:43):
And someone said meat doesn't come from the butcher - meaning that this information is created and maintained at the regulator side.
Jose Costa Teixeira (Oct 03 2017 at 20:46):
Here's my summary:
I started by wondering whether we could eventually consider "condition/indication/disease" as a resource.
I agree that catalog it a list (with some curation information).
I propose that somewhere in that list we should support extra attributes and links - in the catalog itself, in the middle, or in the resources. Best not in the catalog, since these attributes and links can exist outside a catalog.
I think that the mechanism to express these attributes and links should aim at some predictability/consistency. My experience from designing this (in a past life, before I knew that there was this things called REST) is that people tend to see information in silos and ask the wrong questions, like "who is the master of all the data" and "where is a simple list of everything" - it really helps starting to think all of it is a graph.
Perhaps a resource like "catalogEntry" is not the final solution, but I think the "definitional" part can be either a) so generic it is consistent or b) so specific it is, well, specific. And I would prefer a).
Lloyd McKenzie (Oct 03 2017 at 21:09):
My general leaning is that "catalogue" has no information in it that isn't purely about organization/presentation. All of the "knowledge" would exist in other general-purpose resources that could be used in the catalogue context, but could be used other places too.
Extensions have predictability/consistency about what they look like. But anyone can create them - and that's what we want. FHIR is not a top-down thing. If there's a need for top-down, that can be accomplished through IGs.
If you like to think if things as a graph, that's fine - all information models can be visualized that way. But in general we try to avoid vocabulary-driven name-value pairs. That tends to conceal complexity and make conformance harder to manage.
Jose Costa Teixeira (Oct 03 2017 at 21:37):
we'll eventually have to see how to handle context-sensitive and context-independent information.
Jose Costa Teixeira (Oct 03 2017 at 21:38):
medication that has a price for one department and another price for another department. It is still the same medication, right?
Lloyd McKenzie (Oct 03 2017 at 23:13):
That's why I believe pricing should be handled with a separate resource. There could be 10s or 100s of "BillableItem" instances all with the same medication code reflecting different prices for different contexts and time-periods.
Lloyd McKenzie (Oct 03 2017 at 23:14):
A catalogue would expose the subset of those relevant to the time-period and context that the catalogue was produced for.
Jose Costa Teixeira (Oct 04 2017 at 11:55):
I think I see. So the fact that all these 100 billable items are catually the same product is defined by the medication code.. My thinking is that it would be one medication(/definition/knowledge) resource linked to billableItems
Lloyd McKenzie (Oct 04 2017 at 14:49):
The billing stuff and the knowledge stuff are somewhat orthogonal. You might want to link directly from a MedicationPrescription to cost info (or Procedure.code to cost info). Linking could be done by Reference, but I don't think that's how most systems behave. Every system I've seen links knowledge, prices, protocols, etc. based on codes.
Last updated: Apr 12 2022 at 19:14 UTC
