Stream: implementers
Topic: Medications List
Paul Barry (Feb 28 2017 at 21:39):
We want to maintain a medications 'reconciled' list for a patient which we are currently achieving this by creating a list of MedicationStatement entries. We have alot of data we want to store about the reconciled list that may be quite fluid and there is no neat place for data to reside so we were thinking of extending the list to reference a QuestionnaireResponse resource and define the data we want to store using a Questionnaire definition. The UI could also leverage the SMartQ framework. What are peoples thoughts on this approach? And how would I create an extension to a List resource that references a QuestionnaireResponse?
Lloyd McKenzie (Feb 28 2017 at 21:56):
Can you give examples of the kinds of additional data you want to store?
Paul Barry (Mar 01 2017 at 00:06):
Location, reconciliation reason (drop down) , role of clinician, Risk Assessment Options (multi-select check box options), Other identified risks.
Lloyd McKenzie (Mar 01 2017 at 03:35):
Those sound like reasonable extensions to the List or the List item. I wouldn't recommend putting that of information in an embedded Questionnaire. (Though you could use a Questionnaire to define the set of information to populate in the List and generate List instances from QuestionnaireResponse instances.
Jose Costa Teixeira (Mar 01 2017 at 10:14):
What would be most adequate - list or collection?
jens andreas (Mar 02 2017 at 01:51):
We want to specify medication orders for a particular time of day, e.g. Take 2 tablets at 08h00 and at 12h00 and at 18h00.
A great post by Jamie Hignite here http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=12352
Jamie's suggestion looks great, i.e.:
There should be a list of times in the repeat object to allow for this repeated section. So that it is understood that the repeating times are within the outer repeating period
Medication order dosageInstruction would look like this:
"dosageInstruction": [{
"text": "Take 4 tablets daily for 7 days starting January 16, 2015",
"timing": {
"repeat": {
"boundsPeriod": {
"start": "2015-01-16",
"end": "2015-01-20"
}
"timesOfDay":{ //<-- List of times - here is where the times would be for every period
"06:00",
"17:00",
"21:00"
}
}
Lloyd McKenzie (Mar 02 2017 at 05:21):
@Jose Costa Teixeira I'm not understanding your question
Jose Costa Teixeira (Mar 02 2017 at 09:16):
@Lloyd McKenzie questions is whether the resource to convey a medication list (a list of medication-related resources) would be a list or a composition. list seems limited
Lloyd McKenzie (Mar 02 2017 at 16:03):
Medication list would definitely be List. What are the limitations that are causing issues?
Jose Costa Teixeira (Mar 07 2017 at 11:21):
From the definitions:
The List resource - enumerates a flat collection of resources and provides features for managing the collection. While a particular List instance may represent a "snapshot", from a business process perspective, the notion of "list" is dynamic – items are added and removed over time. The List resource references other resources. Lists may be curated and have specific business meaning.
The Composition resource - defines a set of healthcare-related information that is assembled together into a single logical document that provides a single coherent statement of meaning, establishes its own context and that has clinical attestation with regard to who is making the statement. The Composition resource provides the basic structure of a FHIR document. The full content of the document is expressed using a bundle containing the Composition and its entries.
Jose Costa Teixeira (Mar 07 2017 at 11:22):
If I read this, I think that if you want to have somethign that can be authored as a clinically valuable document, you'd use the composition.
Jose Costa Teixeira (Mar 07 2017 at 11:23):
Perhaps relevant: IMO, if you want to exchange medication data, you would use a list (or even bundle?) but for a compiled, authored list, we would have a composition.
Jose Costa Teixeira (Mar 07 2017 at 11:25):
I have been pushing for awareness that "medication records" are not a simple document, but the outcome of several "ingredients" that go through a process -reconciliation, aggregation... and if you want to operate, you'd best exchange the ingredients, and not the summary
Lloyd McKenzie (Mar 07 2017 at 18:21):
If you want a document - frozen, non-updated point-in-time snapshot, focus on human readability and attested by the author, then a FHIR document (with Composition as your 'header') is the way to go. But Medication lists are generally dynamic things and when you query them, you want the current view, not some snapshot that was incorporated in a document 5 months ago. If you have a discharge summary or a referral, those may well be wrapped as documents and will contain frozen snapshots of lists. But the concept of medication list generally is not document-like.
Kevin O'Shea (Mar 29 2017 at 02:59):
-
Last updated: Apr 12 2022 at 19:14 UTC
