Stream: implementers
Topic: List - Additional CodeableConcept
Sean O'Quinn (Jul 07 2020 at 14:09):
General question concerning the List resource. We currently have a use case where we could benefit from the List resource having an additional CodeableConcept like "type" added to the specification. Has anyone implemented List and needed an additional CodeableConcept?
Lloyd McKenzie (Jul 07 2020 at 14:16):
How is that distinct from List.code?
Sean O'Quinn (Jul 07 2020 at 14:22):
Lloyd McKenzie said:
How is that distinct from List.code?
List.code could be something like "Waiting List", but I have a need to type the Wait List. So the consumer can provide a code that defines the Waitlist as "ambulatory" or "elective surgery"
Lloyd McKenzie (Jul 07 2020 at 14:23):
@Michelle (Moseman) Miller
Michelle (Moseman) Miller (Jul 07 2020 at 19:57):
FHIR-I owns List if you want to log a change request. I don't recall having any Patient Care discussions related to List types.
Jose Costa Teixeira (Jul 07 2020 at 20:04):
@Sean O'Quinn What I think is meant is that in your list of values, you can have a code for "Waiting List" and another code for "Elective surgery waiting list". Whetever the granularity of your codes you can add them there - more granular = more specific lists.
Jose Costa Teixeira (Jul 07 2020 at 20:05):
Or do you really need multidimensional codes for the types of list? (if so, I'm curious about an example use case)
Sean O'Quinn (Jul 07 2020 at 20:07):
Michelle (Moseman) Miller said:
FHIR-I owns List if you want to log a change request. I don't recall having any Patient Care discussions related to List types.
I did log a change request for the list spec, but wanted to reach out to the community for additional thoughts.
Sean O'Quinn (Jul 07 2020 at 20:11):
Jose Costa Teixeira said:
Sean O'Quinn What I think is meant is that in your list of values, you can have a code for "Waiting List" and another code for "Elective surgery waiting list". Whetever the granularity of your codes you can add them there - more granular = more specific lists.
I have a specific use case concerning lists of Coverages. A patient can have Medicare as a coverage. That usually means they have Medicare Part A and Medicare Part B. In an acute setting, Part A is the primary coverage. In an ambulatory setting, Part B is the primary. Rather than the consumer constantly changing the priority of the patient coverages, you could have a multiple lists of Coverage. So List.code would be "coverage", and my proposal for List.type would further codify the list to "inpatient" and "outpatient". That way the list has Medicare Part A and B prioritized correctly for the venue of care where the coverage is being utilized.
Lloyd McKenzie (Jul 07 2020 at 21:01):
@Michelle (Moseman) Miller weird - it seems like something that should be owned by PC...
@Sean O'Quinn When you capture the coverages for the patient, there shouldn't be any prioritization. Prioritization should always be in the context of an encounter - or even a specific claim.
Sean O'Quinn (Jul 07 2020 at 21:12):
Lloyd McKenzie said:
Michelle (Moseman) Miller weird - it seems like something that should be owned by PC...
Sean O'Quinn When you capture the coverages for the patient, there shouldn't be any prioritization. Prioritization should always be in the context of an encounter - or even a specific claim.
How did you come to that conclusion? Where on the Coverage resource is there a reference to encounter on R4?
I agree that the priority should be for Coverage in the context of an encounter, but I am not seeing that in the spec.
Lloyd McKenzie (Jul 07 2020 at 21:29):
Encounter points to Account, Account points to Coverage. Coverage wouldn't point to Encounter.
Sean O'Quinn (Jul 07 2020 at 21:35):
Lloyd McKenzie said:
Encounter points to Account, Account points to Coverage. Coverage wouldn't point to Encounter.
Your order is still on the Coverage. So I dont know how the consumer gets around having to constantly update the coverage.order unless the you are looking at an entirely different resource.
Lloyd McKenzie (Jul 07 2020 at 21:40):
Account allows specifying Account.coverage.priority - so each Account would be able to specify different precedence for the Coverage instances it points to. You can have one Account for ambulatory and a different one for acute. Based on the type of Encounter, you point to one Account or another.
Last updated: Apr 12 2022 at 19:14 UTC
