Stream: implementers
Topic: Condition Clinical Description
Stephen Royce (Jul 29 2016 at 01:45):
Our Problem/Diagnosis model (which matches the FHIR Condition element) has 2 data elements for notes: one for general comments akin to the note element in Condition and another which is specifically for capturing the clinical description of the condition. The latter is by far the more important, but there is no apparent match in the Condition resource. We could map both data elements to Condition.note, but that doesn't feel right. We could add an extension, but for something that could contain signficant clincial information that shouldn't be ignored, that would not seem to be a safe choice. The other thought was to map it to Condition.stage.assessment.as(ClinicalImpression).description, but that would appear to be quite a stretch. Anyone got any suggestions?
Stephen Royce (Jul 29 2016 at 01:57):
One thought was to create a slice of Condition.note, but making that unique from the other instances would be challenging, what discriminator(s) we'd use.
Lloyd McKenzie (Jul 29 2016 at 02:42):
Did you look at Condition.code.text?
Stephen Royce (Jul 29 2016 at 02:44):
Oh? We are using Condition.code for the Problem/Diagnosis Identification (type) as a code. Are you suggesting that the text component of the code can contain more comprehensive information than just a display name?
Lloyd McKenzie (Jul 29 2016 at 02:45):
It represents the full human description of the concept that is then encoded in the coding. It could be just the display name of what the human selected. But if the human typed a bunch of text and then picked the appropriate code (or someone else picked the appropriate code), Condition.code.text would be appropriate.
Stephen Royce (Jul 29 2016 at 02:46):
Suite! 
Stephen Royce (Jul 29 2016 at 02:49):
How can we put that into a profile?
Stephen Royce (Jul 29 2016 at 04:30):
Hmmm .. this may not work in general. 
Stephen Royce (Jul 29 2016 at 04:31):
There are at least 2 possible problems with using Condition.code.text:
Stephen Royce (Jul 29 2016 at 04:32):
1. Condition.code classifies the condition, but if the user were to type in a free text classification (_not_ decsription) then there's nowhere to put the description.
Stephen Royce (Jul 29 2016 at 04:36):
2. The clincial description we envisage here is _much_ fuller than just a description of the chosen code. It might include a discussion of the presenting symptoms, relevant past history, &c. i.e. it's really a full clinical synopsis of the condition. In v3 speak, it would be equivalent to Observation.text.
Grahame Grieve (Jul 29 2016 at 05:11):
it sounds like the narrative for the resource
Stephen Royce (Jul 29 2016 at 05:39):
That did cross our minds, but we don't think it is. It's more like Condition.note with the scope constrained to describing the condition. We wouldn't, for instance, expect that it would contain information that could be expressed in other ways, such onset/abatement dates, severity, etc. (although with narrative those things might be needed to support language flow). Also, we figured that the data in the narrative still had to have a home in the structure (unlike CDA), but perhaps we're wrong about that. If it were the narrative, can we map to Condition.text? And how would you handle the fact that the narrative would contain other data derived from the structure that is not part of the clinical description.
Last updated: Apr 12 2022 at 19:14 UTC
