Stream: implementers
Topic: Profiling reference choices
Stephen Royce (Sep 02 2016 at 04:18):
I have a Composition profile with a section that has its entry profiled to a choice between Condition and Procedure and I would like to further profile both of these resources. If the entry was profiled to a single resource reference, I could do this in-line, but I'm not how I would do it where a choice is involved. I though of a couple options, neither of which I like (but maybe they're my only choices):
- Slice entry once for
Conditionand once forProcedure. I don't like this because I'd prefer the data to be interleaved in whatever way makes sense to the authoring clinician which may be seemingly arbitrary and not easily reconstructed mechanically. - Create separate profiles of
ConditionandProcedureand reference those profiles instead. I don't like this because as far as I know, the profiling I require here is unique to this situation, and, while it clearly wouldn't matter once, I'm worried about potential proliferation of profiles and the management problems that will come with that as this kind of thing comes up again and again in the future.
Any thoughts or suggestions?
Grahame Grieve (Sep 02 2016 at 12:18):
my first thought it that you shouldn't be doing that. In your use case, what is called 'procedure' is actually the condition of having had the procedure in the past; just use condition. The split between procedure and condition in medical history is spurious and brings no implementer any value
Grahame Grieve (Sep 02 2016 at 12:20):
methodologically, the answer is to profile the resources separately, and refer to the profiles. The fact that there is no re-use of the profiles is neither here nor there
Stephen Royce (Sep 09 2016 at 01:56):
So it is arguable that we could use Condition instead of Procedure in our medical history (although more on that later), but this is a common pattern throughout our models, so the answer is helpful; thanks.
As to whether this is "neither here nor there", it does impact us with regards to our model management. There is a reasonable likelihood that a number of almost identical profiles of the same resource for different use cases will arise and the consequent proliferation of structure definitions will present difficulties; we know this from experience. Of course, in the past, we have probably been over-prescriptive in our modelling -- although, with the amount of hand-holding with implementers that seems to be required, such levels of prescription has been justified -- but even so, the risk of model prolifieration remains. Furthermore, if there is a set of constraints that makes sense in only one particular circumstance, being able to profile it in-line helps with the semantics. Nonetheless, it is what it is, and if we have to explicitly profile each of these, then we'll just have to figure out how to manage it.
As far as whether we should Condition and not Procedure in medical history, I agree that this would satisfy the simplistic primary use case. However, I'm concerned that the loss of semantics from doing so would compromise secondary use cases. Since secondary use cases is ultimately where the real gains are to be made from digital health, I believe we should be building those considerations into every primary use case. I understand that that will increase the cost to the implementers and, in the short term at least, they'll get nothing back from it, but, in my opinion, the benefits to the community far outweigh any such concerns. Of course, with it's 80/20 mind set, FHIR is not well set up for this kind of longer term thinking, but that doesn't mean we should simply push it aside.
Stephen Royce (Sep 09 2016 at 02:50):
BTW, I do understand that a medical history may not be the place from which you would want to harvest such data for secondary use anyway; nonetheless, the point still stands.
Grahame Grieve (Sep 09 2016 at 03:58):
it's always good to be alert long term secondary use but it's also good to consider implemnetation limitations. In particular, the difference between Condition and Procedure is not supported out of the existing medical history records that GPs / Hospitalists keep. It's extremely unlikely that it's coded... in fact, that's been the problem all long....
Richard Townley-O'Neill (Sep 09 2016 at 05:03):
@Grahame Grieve
The docco in the Condition resource does not suggest this use. It mentions pregnancy, but nothing else. Also the patient care work group propose changing Condition.category from a preferred binding to: complaint | symptom | finding | diagnosis to a required binding. http://hl7-fhir.github.io/condition.html#bnr
So your proposal to use condition for "procedure that has occurred" seems to be novel.
Grahame Grieve (Sep 09 2016 at 05:06):
hmm. maybe you're right. I'll talk to PC about it in Baltimore
Grahame Grieve (Sep 09 2016 at 05:07):
do we have any typical examples of medical history?
Richard Townley-O'Neill (Sep 09 2016 at 05:08):
Not to hand. :(
Grahame Grieve (Sep 09 2016 at 05:08):
I'll get an example or 2
Richard Townley-O'Neill (Sep 09 2016 at 05:09):
Another thing that might belong in a medical history is a 'once in a lifetime' administration of a medication. It's been mentioned in my hearing but never explored.
Grahame Grieve (Sep 09 2016 at 05:10):
immunization?
Richard Townley-O'Neill (Sep 09 2016 at 05:10):
I think it is for toxic medications.
Stephen Royce (Sep 09 2016 at 07:19):
I understand that we have a real problem with the source data being little better than free text. 
Stephen Royce (Sep 09 2016 at 07:21):
In fact, because of how the Condition resource is now documented, we have gone so far as mapping our Uncategorised Medical History Item to Basic in case we need to use that! Let's hope we don't.
Michelle (Moseman) Miller (Sep 09 2016 at 13:36):
@Richard Townley-O'Neill , @Grahame Grieve - I have raised concerns with restricting the scope of Condition by having a required binding to a value set with limited choices. The proposed change would be inconsistent with DAF / Argonaut (as the IG has support for additional category codes like problem and health concern). I was on maternity leave when PC decided to add the STU Note, but I think the discussion started as a result of QA - specifically questioning whether the CodeableConcept should be bound to SNOMED instead, per GF#10091.
Also, I will add that we have an open GF#10090 to revamp (expand) the Condition introduction/scope . The ball is in my court to draft the changes. I can include examples of conditions as a result of a procedure (e.g. amputee) in my revision.
Aleksandra Pavlyshina (Sep 09 2016 at 17:12):
I would like to add some input agreeing with the raised by Michelle concerns. There was the discussion on Zulip https://chat.fhir.org/#narrow/stream/implementers/subject/Issue.2FGoal.2FAction on how to represent the Issue/Goal/Action/Outcome model in FHIR, and I was advised by Lloyd McKenzie and Dave Carlson to represent Issues using the Condition resource. As described in the Argonaut IG (http://argonautwiki.hl7.org/index.php?title=Problems_and_Health_Concerns), our Issues seem to fit as Condition with category=health-concern, or problem, or complaint. So, we need these other categories of Condition in order to be able to represent our model in FHIR, otherwise this resource is not suitable for representing our Issues.
Examples of issues in our palliative care management system are the following:
- Patient does not have a primary care physician
- Nausea: Acute due to unknown cause
- Patient is not compliant with Morphine Sulfate
- Patient needs transportation assistance for access to care
- Pain: Acute due to neoplastic disease
- Patient does not understand their copay/deductible obligations
- Caregiver (Jennifer Baker, Wife) has inadequate support
- No documentation of living will
- Patient wants to create a living will
- Patient reports inadequate access to (provider)
Grahame Grieve (Sep 09 2016 at 23:12):
thx for the contributions @Aleksandra Pavlyshina. @Michelle (Moseman) Miller I will try and source some more from my family
Last updated: Apr 12 2022 at 19:14 UTC
