Stream: conformance
Topic: careteam lifecycle
Jens Villadsen (Aug 26 2020 at 07:52):
Whats the intended lifecycle on careteams? In my setup, careteams are sort of static - eg. careteams groups a set of pracititioners, and the careteams can themselves treat multiple patients. Moreover, careteams don't tend to update much - they more or less reflect the team of people that you work with on a daily basis. While this seems like a good fit for the careteam resource so far, it seems a bit muddy that patients can also be part of a careteam in that sense that the practitioner members seldom change on the careteam, and the careteam can exist for years without changed. However the list of patients that are treated by the careteam can grow indefinitely over time as the team treats more and more patients and they too can be members.
Jens Villadsen (Aug 26 2020 at 07:55):
Shouldn't the practitioner then also have a set of patients that they provide care for?
Grahame Grieve (Aug 26 2020 at 07:56):
Sounds like a question for PC @Michelle (Moseman) Miller
Jens Villadsen (Aug 30 2020 at 20:48):
@Michelle (Moseman) Miller could you please elaborate on the current design?
Michelle (Moseman) Miller (Aug 31 2020 at 21:53):
I can raise this with Patient Care, but based on past discussions, we've identified multiple categories of CareTeams. The http://build.fhir.org/careteam.html#bnc summarizes the different use cases.
The CareTeam includes all the people and organizations who plan to participate in the coordination and delivery of care and is assigned to:
- a single patient, or
- a group (such as a married couple in therapy or a support group), or
- an event, prior to a subject being identified (such as a code blue team or emergency response team)
The above aligns with subject of Patient (singular), Group (e.g. married couple), or not valued (e.g. event based). The resource doesn't support multiple subjects. If the same set of Practitioners are treating 2 to N Patients, then I would expect to have 2 to N instances of CareTeam. Each Patient (subject) would have their own unique CareTeam.status, period, reason despite CareTeam.participant.member referencing the same Practitioners
Michelle (Moseman) Miller (Sep 09 2020 at 17:22):
After Patient Care briefly discussed, we concluded that we wanted to log a change request (done: J#28457) to clarify when to use Group vs multiple CareTeam instances (one per patient). @Jens Villadsen Feel free to add yourself as a watcher and/or comment on the J#28457
Jens Villadsen (Sep 09 2020 at 17:55):
I would say a careteam is still a careteam, regardless of a prior identification of the subject or not - at least in real life. If careteam cannot be used or is not intended to be used to model a group of clinicians across delivery of care to different patients, what resource should then be used @Michelle (Moseman) Miller ?
Michelle (Moseman) Miller (Sep 09 2020 at 17:56):
You can absolutely use a CareTeam in absence of a patient (event-based care team)
Jens Villadsen (Sep 09 2020 at 17:58):
my case is not event based. My case concerns more or less static careteams that covers care for multiple patients.
Jens Villadsen (Sep 09 2020 at 17:59):
my careteams are sort of micro organizations with 4-5 clinicians that provide care for eg. 20 patients
Jens Villadsen (Sep 09 2020 at 18:00):
and those 20 patients are not a group as such.
Michelle (Moseman) Miller (Sep 09 2020 at 18:04):
Feel free to comment on the JIRA if you would like more examples added of CareTeams without a subject. The piece that might warrant yet another JIRA is clarifying whether your use case could be solved with the patient-specific CareTeams (plural) all referencing the same CareTeam (for providers)
Jens Villadsen (Sep 09 2020 at 18:08):
I would like to add that my careteams are also required to be externally identifiable as they are subject to be referenced from other systems. From that perspective, it would seem odd if the system needed 20 different careteams each with the same identifier
Michelle (Moseman) Miller (Sep 09 2020 at 18:09):
For example:
CareTeam [1] has no subject and all CareTeam.participant.members are Practitioners
CareTeam [2] is specific to Patient A and its CareTeam.participant.member references CareTeam [1]
CareTeam [3] is specific to Patient B and its CareTeam.participant.member references CareTeam [1]
CareTeam [N] is specific to Patient N and its CareTeam.participant.member references CareTeam [1]
Jens Villadsen (Sep 09 2020 at 18:16):
yes, thats one logical way to solve it. I'll give you that
Jens Villadsen (Sep 09 2020 at 18:18):
but what is gained since a caretem can eg. be referenced from an episodeofcare which has its own patient reference
Michelle (Moseman) Miller (Sep 09 2020 at 18:19):
Seems like you are suggesting that you might want CareTeam.subject to support 0..* but that implies all subjects share the exact same CareTeam attributes (which I don't think is true). For example:
- The time period (when the team came into effect per patient/subject) will differ.
- The reason/Condition will differ (Condition.subject is singular as well)
John Moehrke (Sep 09 2020 at 18:21):
might you use HealthcareService or Organizatino? It can be many layers of Organization within Organization..... so you could use it for a team http://build.fhir.org/administration-module.html#dir-reg
Jens Villadsen (Sep 09 2020 at 18:22):
but essentially you can build a graph where the careteam has patient A as subject, and the careteam is referenced on EoC which has patient B as patient reference
Jens Villadsen (Sep 09 2020 at 18:23):
but that case maybe apply to multiple places
Michelle (Moseman) Miller (Sep 09 2020 at 18:26):
In the example of EpisodeOfCare (which is one category of CareTeam), I agree that there is some overlap in the CareTeam attributes and the EpisodeOfCare (since EpisodeOfCare has a time period and diagnosis/Condition too) - meaning you might not need the patient-specific CareTeams(?). It seems possible that EpisodeOfCare references the non-subject specific CareTeam [1] in my earlier example. However, there are other types of CareTeams (unrelated to a given EpisodeOfCare) where the dates/reason are captured as part of patient-specific CareTeam.
Jens Villadsen (Sep 09 2020 at 18:40):
I dont need patient specific careteams in my setup as it brings nothing but overhead. My point here is mostly that the case is possible (and maybe even likely) , but the documentation does not really cater for that case, eventhough it seems pretty central, IMHO.
Jens Villadsen (Sep 09 2020 at 18:41):
the case being the careteam that isn't (necessarily) defined as a team "prior to a subject being identified" as well as not being patient specific.
Jens Villadsen (Sep 09 2020 at 18:42):
my case would then be a fourth bullet, if I may suggest
Jens Villadsen (Sep 09 2020 at 20:10):
@Michelle (Moseman) Miller whats your take on that?
Jens Villadsen (Sep 09 2020 at 20:15):
John Moehrke said:
might you use HealthcareService or Organizatino? It can be many layers of Organization within Organization..... so you could use it for a team http://build.fhir.org/administration-module.html#dir-reg
well ... yes and no. I can easily see that healthcareservice has some potential, and in some areas it could be an ok fit, however it totally lacks the part about participants
Michelle (Moseman) Miller (Sep 09 2020 at 21:21):
Agree that we should consider adding a fourth bullet to describe another use case....feel free to log a JIRA with any proposed language that you think covers your use case.
Jens Villadsen (Sep 10 2020 at 07:50):
https://jira.hl7.org/browse/FHIR-28461
Last updated: Apr 12 2022 at 19:14 UTC