Stream: implementers
Topic: Teams represented as Orgs
Michelle (Moseman) Miller (Jun 01 2016 at 14:15):
Currently, the scope of Organization is quite broad (e.g. not limited to legal entities, such as when Organization.type = team)
CareTeam.participant.member (= DSTU2 CarePlan.participant.member) allows a reference to an Organization to satisfy requirements around having a "Blue Team" of practitioners assigned to many patient-specific care teams.
A challenge we are facing is that the "Blue Team" may only have context within the scope of the care teams since it isn't a legal entity represented as a first class organization in our system, so we thought about making the "Blue Team" organization a contained resource, BUT the organization resource doesn't convey the team members (practitioners). Instead, the Practitioner.practitionerRole.organization conveys the relationship, but Practitioner is not a contained resource as the Practitioner has broader context and applicability.
In short, I'm curious if others have implemented organization for teams and whether that has caused similar challenges when the org is contained, but the team members (practitioners) are not contained?
Brian Postlethwaite (Jun 06 2016 at 02:09):
To me personally I interpretted the Organisation on the CareTeam.participant is that the specified organization will provide a practitioner that fills the specified role on that participant during the period specified.
Brian Postlethwaite (Jun 06 2016 at 02:11):
This "Blue Team" approach doesn't give any roles within the team.
I think the CareTeam resouce provides this functionality nicely, and succinctly.
Erich Schulz (Jun 06 2016 at 02:34):
its an interesting question as to how deep and dynamic teams should be
Erich Schulz (Jun 06 2016 at 02:35):
my hospital has both a "code blue team" and "emergency team" (with considerable overlap)
Erich Schulz (Jun 06 2016 at 02:36):
for routing emergency pages the every changing membership needs to be tracked somehow
Brian Postlethwaite (Jun 06 2016 at 02:36):
Sounds like you have a "live" care team setup for these 2 purposes.
Brian Postlethwaite (Jun 06 2016 at 02:37):
I expect that you'd have different roles setup/associated in those 2 teams too?
Erich Schulz (Jun 06 2016 at 02:37):
I also dropped a patient into the recovery ward the other day and discovered that the nureses had decided to organise themselves into teams (rather than the traditional one-one approach)
Erich Schulz (Jun 06 2016 at 02:37):
roles are implied by the employment role
Brian Postlethwaite (Jun 06 2016 at 02:38):
Even if a practitioner has multiple roles available?
Erich Schulz (Jun 06 2016 at 02:38):
i guess once you have a data-model that supports nested and overlapping organisations the question is how far to go
Erich Schulz (Jun 06 2016 at 02:39):
well in a code-blue call its always dynamic and takes account of who is present
Erich Schulz (Jun 06 2016 at 02:40):
the teams is usually defined as "the nurse duty manager, the medical registrar on call, the anaesthetic registrar on call and the ward call intern"
Erich Schulz (Jun 06 2016 at 02:41):
its pretty much declaration by pointer :-)
Erich Schulz (Jun 06 2016 at 02:42):
practical impact is that switch needs to track who's phone to activate when the blue phone rings...
Erich Schulz (Jun 06 2016 at 02:44):
sometimes (often) oncall arrangements can be very complicated with every team member being rostered on a different spreadsheet published by a different clerk with different shift start and end times
Erich Schulz (Jun 06 2016 at 02:45):
ie very easy to imagine strategically deploying some FHIR resources to bring some order to the chaos
Erich Schulz (Jun 06 2016 at 02:48):
the more generic question is "who gets called for when patient X experiences condition Y"?
Brian Postlethwaite (Jun 06 2016 at 02:49):
and staff coming and going earlier/later than expected due to other things.
Erich Schulz (Jun 06 2016 at 02:49):
the "blue team" is an extreme case, but nurses have to determine this all day long
Erich Schulz (Jun 06 2016 at 02:50):
(as to pathology and radiology and pharmacy providers)
Erich Schulz (Jun 06 2016 at 02:50):
yes and private providers organising cover while they go fishing
Erich Schulz (Jun 06 2016 at 02:51):
its often a cause of heartburn...
Erich Schulz (Jun 06 2016 at 02:51):
who to call first, who to call second if the first doesnt answer...
Brian Postlethwaite (Jun 06 2016 at 02:51):
:)
Erich Schulz (Jun 06 2016 at 02:52):
emergency physicians also face the "who to call" issue all day long
Erich Schulz (Jun 06 2016 at 02:53):
there is a real overlap between service and organisation that i havent unpacked yet too
Brian Postlethwaite (Jun 06 2016 at 02:54):
Have you looked into the HealthcareService resource yet?
Erich Schulz (Jun 06 2016 at 10:10):
@Michelle (Moseman) Miller sorry for hijacking your thread
Erich Schulz (Jun 06 2016 at 10:12):
I just had a chance to review the service, organisation, and even the group resources.
Erich Schulz (Jun 06 2016 at 10:15):
It does seem that organisation is the most appropriate, (although argualbly this organisation could provide a "service") - but the way members of on an organisation are defined is a bit limiting (ie it isn't FHIRified)
Erich Schulz (Jun 06 2016 at 10:16):
can track members of an organisation with: http://www.clipular.com/c/4682582567944192.png?k=i-E89Hv3AJUOaVqPtcw1R_Vaa1o
Erich Schulz (Jun 06 2016 at 10:17):
whereas group defines members with http://www.clipular.com/c/6378279814037504.png?k=xDXh2lBQOhXE3J4lo9MOm3B9Jnw
Erich Schulz (Jun 06 2016 at 10:19):
In my perfect organisational map I would have organisation.contact.purpose (or something equivalent to specify the role) but I would have group.entity to have a FHIRirified refence to the members
Erich Schulz (Jun 06 2016 at 10:28):
More to the point @Michelle (Moseman) Miller from an ERD perspective, there is a many to many relationship between organisations/groups and members...
Erich Schulz (Jun 06 2016 at 10:29):
so back in the SQL days this would mean that oraganisation_memberwould be its own table (and ? resource)
Erich Schulz (Jun 06 2016 at 10:30):
when unpacking a many to many into one of two resources it will always be arbitrary and arguable the relationship belongs with both ?
Erich Schulz (Jun 06 2016 at 10:30):
not that we're really done with SQL yet :-)
Brian Postlethwaite (Jun 06 2016 at 10:35):
that resource you're describing sounds a little like practitionerRole.
Brian Postlethwaite (Jun 06 2016 at 10:36):
which is on practitioner in DSTU2 (and we're considering it as a top level resource in STU3)
Erich Schulz (Jun 06 2016 at 10:44):
ah right...
Erich Schulz (Jun 06 2016 at 10:44):
http://www.clipular.com/c/6301980525330432.png?k=0GCzCT4lDW47WKulQii48LoWUu0
Erich Schulz (Jun 06 2016 at 10:45):
promoting to top level sounds like a good plan ?
Erich Schulz (Jun 06 2016 at 10:45):
"managing organisation" doesnt sound like a helpful label here tho...
Erich Schulz (Jun 06 2016 at 10:47):
sorry completely missed this!
Erich Schulz (Jun 06 2016 at 10:50):
I guess main point is that the roles need to be filterable as first class citizens (in which case having role_practitioner wouldn't be essential)
Michelle (Moseman) Miller (Jun 06 2016 at 13:00):
@Brian Postlethwaite , I'm not sure that I understand the recommendation here.... specifically, how/where do you define the practitioners who are part of the Blue Team? (I understand the CareTeam.participant.role will define the role of the team, but the root of my issue is how to represent the practitioners that are part of the Organization when Organization is a contained resource in the CareTeam?).
Organization.contact doesn't have the specific practitioners, just a point of contact (e.g. name, telecom, address).
@Erich Schulz Although Group allows you to specify the specific practitioners, we avoided referencing Group from the CareTeam.participant.member for the reasons listed in the Boundaries and Relationship section http://hl7-fhir.github.io/careteam.html#4.5.2
Brian Postlethwaite (Jun 06 2016 at 13:01):
the practitionerrole on the practitioner.
Michelle (Moseman) Miller (Jun 06 2016 at 13:04):
I don't see how that works when Organization is contained within the context of CareTeam, but Practitioner is not contained. How can a non-contained Practitioner.practitionerRole reference a contained Organization?
Brian Postlethwaite (Jun 07 2016 at 00:39):
If the Organization is contained, then so do all the practitioners that you want in there (which means can't be real prac records)
However if the PractitionerRole resource is approved, then these could do it.
Michelle (Moseman) Miller (Jun 08 2016 at 14:58):
@Brian Postlethwaite, I think there are two issues preventing that from working:
1) The FHIR spec says "Resources can only be contained in other resources if there is a reference from the resource to the contained resource" The Organization resource doesn't reference the Practitioner (team members), so a contained Practitioner doesn't seem like it's allowed.
2) These are real practitioners, who happen to be part of some real Organizations (legal entities) AND contained Organizations (teams that only have context inside the CarePlan/CareTeam).
Jenni Syed (Jun 08 2016 at 18:25):
Does everyone agree that "Blue Team" would only be represented as an Organization in the first place? that was surprising to me.
The containment issue may be something that only we are struggling with do to some internal modeling, and it does cause some issues as Michelle pointed out, but want to make sure (based on some of the comments above) that everyone does agree that "Blue Team" = Organization
Lloyd McKenzie (Jun 09 2016 at 06:55):
Organization is a group of people that can act and take responsibility collectively. I think Team Blue would fit that definition. It can't be Group (Groups can be acted upon, but can't act or take responsibility). CareTeam currently says it's patient-specific, though the relationship to Patient is currently optional.
Erich Schulz (Jun 09 2016 at 12:07):
Maybe it could be an organisation until a code is called... Then it becomes a care team? Baring in mind those that attend may not be the same as those carrying the pages (ie supposed to be on the team) at the time?
Michelle (Moseman) Miller (Jun 09 2016 at 13:00):
@Erich Schulz CareTeam is comprised of the participants/members, which include the Blue Team org + patient + related persons -- and this CareTeam is a planning resource, so it can exist before the code is called. Since CareTeams are generally patient specific, the question was previously asked how to leverage the same team of practitioners across multiple patient-specific care teams, which is when we landed on using Organization to represent one of the care team members (along with patient and related persons).
In my offline discussions with Jenni, I think she wanted confirmation that Organization is the correct representation of a team (in general) that is more dynamic in nature than formally recognized legal entities. I think her question leads to the contained resource dilemma where some teams may not have global context like practitioners do, which is what prompted me to start this discussion thread.
Lloyd McKenzie (Jun 09 2016 at 13:21):
I think the short answer is that if you want to see "Team Blue" as a Practitioner.practitionerRole.organization, then the Organization can't be contained. It might be limited in scope, but it's obviously able to stand alone and be uniquely identifiable. Personally, I'd be somewhat surprised to see something as fine-grained in Practitioner.practitoinerRole.organization, but it's not an "incorrect" use if you wanted to do that.
Michelle (Moseman) Miller (Jun 10 2016 at 16:05):
What are the alternative (less surprising) ways to represent a "Blue Team" if not via an Organization resource?
Jenni Syed (Jun 10 2016 at 19:54):
my (very naive) initial expectation was that they were their own CareTeam, but after reading all the actual CareTeam doc (patient specific) that doesn't make sense :)
Jenni Syed (Jun 10 2016 at 19:55):
Of all the tools we have, I think org is the other option, but I don't like that practioners roles have to point to that org to indicate that they're part of a "blue team" that day
Jenni Syed (Jun 10 2016 at 19:56):
From a pure versioning perspective, the FHIR Practitioner would have to be versioned everytime the team assignments change, which seems nasty, and I'm not sure how many systems would have thought of it that way
Jenni Syed (Jun 10 2016 at 19:59):
Does it make sense to have non-patient specific CareTeams? I'm guessing that goes against some general expectations for "care team" terminology?
Jenni Syed (Jun 10 2016 at 19:59):
IE: CareTeams that can reference CareTeams would be the result of that
Jenni Syed (Jun 10 2016 at 20:00):
I'm just throwing out ideas here, which may be totally off the wall :)
Lloyd McKenzie (Jun 10 2016 at 22:28):
I think it's reasonable to expand CareTeam to allow non-patient-specific care teams. The question is whether implementers will feel comfortable with a single resource that could be patient-specific or patient-independent.
Erich Schulz (Jun 10 2016 at 22:32):
why care team as opposed to organisation?
Lloyd McKenzie (Jun 10 2016 at 22:33):
Organization doesn't allow direct linkage of the members without updating the members
Lloyd McKenzie (Jun 10 2016 at 22:33):
Though I guess an extension on Organization would be an alternative to a Patient-independent CareTeam
Michelle (Moseman) Miller (Jun 11 2016 at 15:07):
Back in the March timeframe (after the new CareTeam resource was drafted), there was a discussion about whether the CareTeam.participant.member should also reference a CareTeam. While there were opinions on both sides, at the time, we decided against it mainly because the existing (DSTU2) CarePlan.participant.member didn't support embedding one care team within another care team, so weren't confident that the use case existed. That was all based on the assumption that "Blue Team" was an Organization (not CareTeam).
Note: CareTeam was previously embedded in context of a CarePlan, which was also scoped to be patient-specific (e.g. "Note that this resource represents a specific plan instance for a particular patient or group. It is not intended to be used to define generic plans or protocols that are independent of a specific individual or group. I.e. It represents a specific intent, not a general definition. Protocols and order sets will be supported through future resources"). The same can be said for Encounters and EpisodeOfCare being patient-specific too. All resources referencing CareTeam seem to be patient-specific.
Last updated: Apr 12 2022 at 19:14 UTC
