Stream: implementers
Topic: Condition Resource - Past Medical History
Ben Grey (Aug 22 2019 at 20:21):
I am investigating the best practice way to encode a patients medical history collected in a specific history template form within an application.
Firstly, the condition category - would it be appropriate to use ' History of clinical finding in subject (situation)' to establish condition context? I guess any past problem list item or encounter diagnosis would be seen as part of a patients history but its not created/maintained within these categories in the application.
I am also debating on which snomed concepts to use for the condition.code - there are snomed situations which already establish a 'history of' context to a disorder, but this does not cover every disorder so I could:
(a) Use situations where it is established in snomed and then use disorder tagged concepts for everything else
(b) stick to consistency and just use the disorder concept and have the context established by the condition.category
(c) Use post-cordination to establish a history context to a disorder concept
(d) include multiple concepts e.g. the situation and the disorder codes
Does anyone have any experience/recommendations on this and any considerations for consistent querying these resources later?
Example scenario below:
{
"resourceType": "Condition",
"id": "123",
"meta": {
"versionId": "1"
},
"patient": {
"reference": "Patient/2218124"
},
"encounter": {
"reference": "Encounter/335466"
},
"code": {
"coding": [
{
"system": "http:/snomed.info/sct",
"code": "85921000119107",
"display": "History of pancreatitis (situation)"
},
{
"system": "http:/snomed.info/sct",
"code": "75694006",
"display": "Pancreatitis (disorder)"
}
]
},
"category": {
"coding": [
{
"system": "http:/snomed.info/sct",
"code": "417662000",
"display": "History of clinical finding in subject (situation)"
}
]
},
"onsetDateTime": "2019-08-08T07:00:00.000Z",
"notes": "Additional history note recorded"
}
Lloyd McKenzie (Aug 22 2019 at 20:37):
@Michelle (Moseman) Miller
Michelle (Moseman) Miller (Aug 22 2019 at 22:35):
Patient Care discussed this briefly today, but wanted more information / context on why the use case is trying to query conditions by "history of". Category is loosely defined as there can be multiple axes of categorization, but isn't generally used as a means to post coordinate the code.
Rob Hausam (Aug 23 2019 at 03:28):
Unfortunately, as @Michelle (Moseman) Miller knows, I wasn't able to make it for the PC FHIR call today because I was in the air. In International Patient Summary (IPS) when we create an IPS document (not the only choice) we have separate sections for IPS Problems Section and IPS History of Past Illness Section, but both of them use the IPS profile on Condition which fixes the 'category' value to "Problem" (because that's what we're interested in here). It was done this way largely because of the confusion around the use of 'category' and allowing different and multiple categories wasn't felt to be useful in the IPS context (and it also may not be in others). So with that there is no way to declare a 'category' of "History of clinical finding in subject". But even if that was allowed, declaring the 'category' in that way is not intended to provide additional context for interpreting the data in Condition.code - it only serves (or should serve) to further describe the data in ways that may make it easier to search or display (or for some other reason). We don't actually say very much about that in the documentation for Condition, though, and we probably should. But we do say in the comments for Condition.category that "The categorization is often highly contextual and may appear poorly differentiated or not very useful in other contexts." So that at least provides a bit of a disclaimer on its use.
So if 'category' isn't really a good option, then what is the solution for the issue that @Ben Grey describes? We don't say a lot about it in Condition (or in IPS), but the Condition documentation does say that "The Condition.code may also include such concepts as "history of X" and "good health", where it is useful or appropriate to make such assertions." That would mean that if the desired "history of X" concept doesn't already exist in SNOMED CT then you would need to use a SNOMED compositional grammar expression (i.e. post-coordination) to say it or (more likely) you would need to have that concept added to an appropriate SNOMED CT extension until it could potentially be promoted to the International Edition. The only other real alternative that I can think of that might make sense is to interpret the 'onset' and 'abatement' values to determine whether a particular Condition resource should be considered as current or historical (I think that would need to be tested to see if it actually would work).
Lloyd McKenzie (Aug 23 2019 at 03:31):
Do you fix it to category or do you just indicate that one of the values must match the pattern "Problem". (I sincerely hope it's the latter, because prohibiting other category values (or other translations of the code 'problem' would interfere with interoperability, not help it.)
Rob Hausam (Aug 23 2019 at 03:37):
You're referring to the situation I described in IPS. And in that case, it was actually constrained by declaring a required binding to a single code value set. In partial defense, this was done before pattern was a reliable and well recognized (at least by us) option. And it may have been somewhat of an overreaction to the messiness of figuring out what 'category' is and how it is supposed to be used. I think your point is well taken, and it probably needs to be reconsidered. I'm sensing a ballot comment coming on. :)
Lloyd McKenzie (Aug 23 2019 at 03:48):
Ballot comment is too much work. But a tracker item I can do :) GF#23740
Rob Hausam (Aug 23 2019 at 03:50):
ok, fair enough - thanks
Ben Grey (Aug 23 2019 at 17:56):
Thanks, this is helpful. In this case I will keep the category as a 'problem-list-item'. In this use case the medical history is basically a tick list template form of disorders with no other attributes collected with it such as date of onset/resolution. So sending or querying a condition resource, it will impossible to ascertain whether it is part of their 'past' history. looks like for this .code is where i will have to establish some history context. @Rob Hausam Have you dealt with many implementations consuming refinement post-coordinated expressions included in resources? Or is this something to try avoid?
Rob Hausam (Aug 23 2019 at 22:27):
@Ben Grey No, I haven't encountered very many implementations that do handle SNOMED CT post-coordinated expressions. There are now some terminology servers available that can support this, and as that becomes more prevalent and people become aware of it the situation might possibly begin to change. But at present it seems that nearly all implementations avoid it (like the plague). We do intend to focus the Terminology Track efforts at the Connectathon in Atlanta this time on implementation of SNOMED CT in particular, and we will try to use that opportunity to more fully engage the participants in the other tracks around their current or desired use of SNOMED (everyone needs terminology, and many or most likely need SNOMED CT), including raising awareness of possibilities with post-coordination. I think many of us working with SNOMED have always assumed that we would get there - sometime. And now could be a time to begin trying to inch forward on it.
Zoljargal (Oct 09 2019 at 03:18):
@Ben Grey Hello, our colleagues are working on the development of FHIR compatible front end of EMR system. Did you manage to find a solution to gather current and past medical history in a granular form while keeping them not painful for doctors? Right now I'm working on it. Because of the big diversity of patient's complaints and medical history /and it differs depending on whether the current illness is chronic or acute condition/, it is really hard for me to prepare a template for current and past medical history. Any solution or idea shared on that issue will be highly appreciated. Thank you!
Christopher Marchand (Apr 23 2020 at 17:10):
@Brett Marquard In a similar theme as the above but, we're running into a problem where we don't know how to show if a condition is episodic vs chronic? Doesn't look like US Core supports this.
Brett Marquard (Apr 23 2020 at 17:46):
How do you track the difference in your current system?
Lloyd McKenzie (Apr 23 2020 at 20:57):
@Michelle (Moseman) Miller
Michelle (Moseman) Miller (Apr 23 2020 at 23:00):
J#20358 introduced http://build.fhir.org/extension-condition-diseasecourse.html
Also see: http://community.fhir.org/t/modeling-condition-chronicity/1191/10
Michelle (Moseman) Miller (Apr 24 2020 at 13:09):
Oh, and per comments in JIRA, although the extension is available, a precoordinated Condition.code can be used as well -- such as Acute otitis media (disorder) SCTID: 3110003 or Chronic otitis media (disorder) SCTID: 21186006
Christopher Marchand (Apr 24 2020 at 16:07):
@Michelle (Moseman) Miller , thanks. @Brett Marquard we infer this data based on the condition coding against AHRQ (ICD-10-CM) term definitions. I see Michell's response in the base FHIR R4 standard, doesn't look like this was pulled into US Core?
Brett Marquard (Apr 24 2020 at 19:05):
Correct, most FHIR core extensions aren't pulled into US Core unless a specific requirement came up during development -- you are allowed to use this and other extensions in US Core!
Matt Rouhana (Nov 17 2020 at 00:00):
On this topic - is it better practice to use a Condition resource or an Observation resource when recording medical history? The Condition resource documentation seems to contradict itself on this point.
The Use of Condition.code section seems to clearly indicate that Conditions are the appropriate resource:
The Condition.code may also include such concepts as "history of X" and "good health", where it is useful or appropriate to make such assertions.
Yet, in the Assertions of Condition Absence section, the above appears to be refuted:
It is common as part of checklists prior to admission, surgery, enrollment in trials, etc. to ask questions such as "are you pregnant", "do you have a history of hypertension", etc. This information should NOT be captured using the Condition resource but should instead be captured using QuestionnaireResponse or Observation.
Can anyone shed some light on this subject?
Lloyd McKenzie (Nov 17 2020 at 00:09):
Condition is used to capture and manage a long-term assertion of patient state. Observation is used to capture a point-in-time statement. An Observation can be used to support the assertion of a Condition
Last updated: Apr 12 2022 at 19:14 UTC
