Stream: implementers
Topic: patient roster
Josh Mandel (Jul 06 2018 at 16:13):
I've been noodling on approaches to representing a "roster" of patients for a given practitioner or organization. I'm considering just defining GET /Practitioner/:id/$roster to handle this, because Group search and List search and List/$find don't seem to cover this use case. Some surprising things I noticed:
-
Groupdoesn't have a clear way to say "the common characteristic of this group is that all patients are associated with a specific practitioner or organization" -
Listdoesn't have a clear place to indicate a specific practitioner or organization that is the common link between the members
John Moehrke (Jul 06 2018 at 16:19):
Is this just the other perspective on Patient.generalPractitioner and/or .managingOrganization? Thus a query on Patient ?general-practitioner or ?organization?
Lloyd McKenzie (Jul 06 2018 at 18:15):
Could the roster ever be the focus of an action? If so, Group is probably a better fit. We could extend the criteria to allow valueReference
Josh Mandel (Jul 06 2018 at 20:08):
@Lloyd McKenzie Yes, the roster could be the focus of an action. (I mean, honestly what couldn't?). I'll add a tracker for valueReference
@John Moehrke it's not as straightforward as Patient.generalPractitioner because it won't always be someone in a 1:1 relationship, or someone directly serialized within the Patient resource. This kind of "has on roster" relationship is more fluid/functional, less static.
Grahame Grieve (Jul 06 2018 at 20:09):
why doesn
Grahame Grieve (Jul 06 2018 at 20:09):
why doesn't list search work?
Josh Mandel (Jul 06 2018 at 20:12):
Re: List Search... How do you say GET Listfor Practitioner 123}}? The practitioner can't be the subject, and it doesn't semantically fit as the source.
Grahame Grieve (Jul 06 2018 at 20:13):
it would work if you knew the list, yes? The problem is knowing the list? you certainly need tighter semantics than subject or source
Josh Mandel (Jul 06 2018 at 20:14):
If you knew the list (or Group) Id you wouldn't need search, just read.
Josh Mandel (Jul 06 2018 at 20:14):
Exactly.
Grahame Grieve (Jul 06 2018 at 20:14):
so I don't find it surprising that list doesn't have this, it would be extension - that seems ok to me. I agree that Group would be good to characterise users by their relationships of various kinds.
Josh Mandel (Jul 06 2018 at 20:15):
Yeah, I added GF#17456 for this.
Grahame Grieve (Jul 06 2018 at 20:16):
what reference would this be though?
Josh Mandel (Jul 06 2018 at 20:16):
I think it would be a reference to the practitioner.
Grahame Grieve (Jul 06 2018 at 20:16):
I'm not following.
Josh Mandel (Jul 06 2018 at 20:16):
With Group.characteristic.code meaning "roster for".
Grahame Grieve (Jul 06 2018 at 20:16):
Group would work: the practitioner lists all the patients on their roster.
Josh Mandel (Jul 06 2018 at 20:17):
Sorry, here's an example. If we wanted to represent the patients like "Dr Smith's Hypertension Panel"...
Grahame Grieve (Jul 06 2018 at 20:17):
I don't know where else "roster of patient" is represented ; group would be the primary source. So I don't understand what reference gives you
Josh Mandel (Jul 06 2018 at 20:18):
{
"resourceType": "Group",
"characteristic": [{
"code": {"text": "On Hypertension Roster For"},
"valueReference": {
"display": "Dr. Smith"
"reference": "Practitioner/123"
}
}],
"member": [
// enumerated here
]
}
Grahame Grieve (Jul 06 2018 at 20:19):
but no, the group is the roster, and you list patients in there. characteristic can't help you
Josh Mandel (Jul 06 2018 at 20:20):
It helps me by enabling a search like
GET /Group?characteristic={}&value=Practitioner/123
Grahame Grieve (Jul 06 2018 at 20:21):
I think you're thinking about it wrong; characteristic is what makes things a member of the group, not a description of the characteristics of the group itself - and you're trying to express the latter
Josh Mandel (Jul 06 2018 at 20:24):
I understand what you're saying; I'm not sure it's what the spec says or what should be true though. In particular, we agree that you can expresscharacteristic and member in a single Group, right?
Josh Mandel (Jul 06 2018 at 20:25):
When I provide a characteristic like the one above, why is this not "what makes [patients] a member of the group"? That's precisely how I'm using it, I believe.
Josh Mandel (Jul 06 2018 at 20:25):
As in
"What makes patients a member of Group 456 is the fact that they are on Practitioner 123's roster".
Grahame Grieve (Jul 06 2018 at 20:26):
ok so yes but I was getting at 'prospective'or 'descriptive'. I understand that you have either member or characteristic based on "The Group resource is used in one of two ways:" in scope.
Grahame Grieve (Jul 06 2018 at 20:26):
if you specify a characteristic, it is used to computationally determine the membership
Grahame Grieve (Jul 06 2018 at 20:27):
I think you are understanding it descriptively
Josh Mandel (Jul 06 2018 at 20:27):
I'm thinking about a scenario where groups are read-only data. So it might as well be both; it's hard to say how you'd disentangle them.
Josh Mandel (Jul 06 2018 at 20:28):
In any case, the solution I have right now is GET /Practition/123/$roster, which avoids some of the philosophical grey area :-)
Grahame Grieve (Jul 06 2018 at 20:29):
"groups are read only"?
Josh Mandel (Jul 06 2018 at 20:29):
The use case I'm trying to address is "A financial system wants to let clients ask 'who is on the roster for Practitioner 123?'"
Grahame Grieve (Jul 06 2018 at 20:29):
$roster like that is legal, but substitutes implicit knowledge in the place of explicit knowledge so it would be good to sort that out
Grahame Grieve (Jul 06 2018 at 20:30):
right. so in that case, who actually provides the information that a patient is on the roster, and how?
Josh Mandel (Jul 06 2018 at 20:30):
Quite -- which is why we're having this conversation in parallel :-)
Josh Mandel (Jul 06 2018 at 20:30):
The source financial system provides the information, based on its own internal know-how. Business logic, historical records, attribution algorithms, whatever.
Grahame Grieve (Jul 06 2018 at 20:30):
in the real world, who does?
Josh Mandel (Jul 06 2018 at 20:31):
Does that make sense?
Grahame Grieve (Jul 06 2018 at 20:32):
I think that in some cases it makes sense that the server would already know the answer, but in lots of other cases, some system other than the server knows the list, but wants the server to know the list too
Grahame Grieve (Jul 06 2018 at 20:32):
btw @Lloyd McKenzie do you know the answer about specifying both characteristics and members?
Josh Mandel (Jul 06 2018 at 20:33):
Sure -- most definitely. https://github.com/smart-on-fhir/smart-on-fhir.github.io/wiki/Bulk-data:-thoughts-on-rosters-and-groups includes that use case, too.
Josh Mandel (Jul 06 2018 at 20:33):
Re: characteristics + members, there's no invariant prohibiting it, at least.
Grahame Grieve (Jul 06 2018 at 20:34):
no but no information about what it would mean
Grahame Grieve (Jul 06 2018 at 20:34):
in other similar cases where you can list or provide rules, we've spent years arguing about the relationship between them
Josh Mandel (Jul 06 2018 at 20:34):
I assumed it'd mean: here are some people + here's what they have in common :-)
Grahame Grieve (Jul 06 2018 at 20:35):
I assumed it would mean, here's some people, and here's some more people
Grahame Grieve (Jul 06 2018 at 20:35):
or here's some rules for the people, and here's what I think the correct list for the rules is right now.
Josh Mandel (Jul 06 2018 at 20:35):
Yeah, so specifying this stuff this abstractly is hard!
Josh Mandel (Jul 06 2018 at 20:36):
Your last one also works for me in this use case :p
Josh Mandel (Jul 06 2018 at 20:36):
The middle one though, "people + more people" not so much.
Grahame Grieve (Jul 06 2018 at 20:36):
no. so we definitely need to clarify this.. can you make another task?
Josh Mandel (Jul 06 2018 at 20:36):
Of course. Coming right up.
Josh Mandel (Jul 06 2018 at 20:40):
Lloyd McKenzie (Jul 06 2018 at 20:45):
You're allowed to specify both characteristics and members. If you do, then the members are the set of individuals you found who met the characteristics.
Grahame Grieve (Jul 06 2018 at 21:01):
which is not quite the same as 'this is the set of individuals and this is their common characteristics'
Lloyd McKenzie (Jul 06 2018 at 21:51):
Agree. Group characteristics are definitional, not incidental
Grahame Grieve (Jul 06 2018 at 22:02):
there's use cases for both, though
Lloyd McKenzie (Jul 06 2018 at 22:04):
I'm not really understanding the use-case for "incidental". Josh's would be definitional - these are the people that are part of Practitioner X's roster.
Grahame Grieve (Jul 06 2018 at 22:35):
if I remove the members, and then rebuild them, will I get the same list? If no, then it's not definitional
Lloyd McKenzie (Jul 06 2018 at 22:39):
If I say "all females age 15-60 in a 5 mile radius of x" and build the list, then wipe it, then build it again, it's possible there might be a change, but it's still definitional. Or if I define a list of criteria for a clinical study and I enroll a set of subjects, that doesn't mean the subjects are all of the people who met the criteria, it's those who happened to get enrolled. But they can't be enrolled if they don't meet the criteria. And the criteria weren't developed by looking at the characteristics of the members.
Grahame Grieve (Jul 06 2018 at 22:40):
but if build a list of members, and then say - this list, it's the set of people who have y - then the relationship is reversed. And that's what Josh is trying to do
Lloyd McKenzie (Jul 07 2018 at 00:03):
I thought he was defining the type of roster, then adding people to it?
Lloyd McKenzie (Jul 07 2018 at 00:04):
I wasn't familiar with a situation where you'd compile a list of patients and then say "oh, turns out all of these people have diabetes". Is that what's happening?
Grahame Grieve (Jul 07 2018 at 01:26):
the group is defining the membership - it's saying 'this list members have this property because I say so' not 'you use this property to figure out who are members'
Lloyd McKenzie (Jul 07 2018 at 01:48):
I thought you were defining the group as "These are the patients of Dr. X" - and then adding the patients.
John Silva (Jul 07 2018 at 11:51):
Trying to follow this discussion to learn ... I noticed that there is a property, actual ( https://www.hl7.org/fhir/group-definitions.html#Group.actual ) which seems to imply that a Group can be either 'real' (i.e. that has the list in members[] or definitional, to me this implies that the list is dynamically generated by a search based on the characteristic(s) ) , it doesn't seem to allow for a Group to be both --- at least reading the spec page that what it seems to imply. [If the spec isn't clear enough on this then maybe something, like some examples, could help clarify this distinction.]
Brian Postlethwaite (Jul 11 2018 at 11:34):
This is the first time I've ever thought of making a practitioners roster a group, that just seems totally not appropriate, unless we're really just trying to flesh out uses of group and fabricating a theoretical one with a roster.
Depending on the context of a roster, and the type of services being applied, these could be a few different things.
Brian Postlethwaite (Jul 11 2018 at 11:36):
Were you really referring to the list of patients that a practitoner might do on his rounds of a hostpital? Or the list that a general practitioner is expecting to appear in their office, or a community care practitioner that has to go out into the field?
Most of these are related to appointments and encounters, and nothing to do with list or group at all.
Brian Postlethwaite (Jul 11 2018 at 11:38):
(not to forget schedule and slot for the availability side of the practitioners roster)
Grahame Grieve (Jul 11 2018 at 11:45):
I think that we're assuming that all these groups are associated with some kind of workflow, but the workflow is maintained on some other system, and that the 'patient roster' is just a denormalization of that onto a different system
Josh Mandel (Jul 12 2018 at 14:07):
The use case here is really: how can a healthcare payer communicate to a provider "these are the patients we currently attribute to you as a provider organization" (or "to you as an individual provider"). It's important for managing populations effectively.
@Brian Postlethwaite Can you say more about why Group is "totally not appropriate"? It seemed like the best fit; what would you recommend instead?
Brian Postlethwaite (Jul 13 2018 at 01:05):
Thanks, not really a roster (from a scheduling perspective), its the patient list. That now makes sense.
MHIN have done some stuff with this in their state based directory.
Brian Postlethwaite (Jul 16 2018 at 05:21):
@Josh Mandel , looking at that smart on fhir page
https://github.com/smart-on-fhir/smart-on-fhir.github.io/wiki/Bulk-data:-thoughts-on-rosters-and-groups
Think that you should be more clear that this is not a roster from a scheduling perspective...
Josh Mandel (Jul 16 2018 at 12:04):
Thanks Brian -- definitely. I think we can call this an "attribution list".
Isaac Vetter (Jul 17 2018 at 22:26):
Hey @Paul Knapp - How would you expect a payer to represent the provider organization that it was attributing a specific patient to, in FHIR? The current suggestion is that a Group of Patients have Group. characteristic as a reference to a Practitioner or Organization resource.
Would it be reasonable for a Contract.topic to be a reference to a Group ?
Last updated: Apr 12 2022 at 19:14 UTC
