-
Notifications
You must be signed in to change notification settings - Fork 9
Representing Huddle Lists
Intervention Engine will need to support the notion of a huddle list. A huddle list is a list of people who should be discussed during a specific huddle. The following are the features required by huddle lists:
- Huddle Date: This is the date on which the huddle should take place
- Huddle Leader: A reference to the practitioner, organization, or group leading the huddle. This is to support multiple care teams.
- Huddle Patient Roster: The list of patients to be discussed.
- Huddle Patient Reason: For each patient in the roster, the reason the patient was added. Probably a code, but could be text.
- Huddle Patient Status: For each patient in the roster, a flag indicating if the patient was actually discussed during this huddle.
In the future, each patient entry might also contain a reference to the interventions that were decided upon during the huddle, but this is not an initial requirement.
It appears that there are two potential resources that could be used: Group and List. Neither is perfect, however; both would require extensions.
According to the FHIR definition, Group
Represents a defined collection of entities that may be discussed or acted upon collectively but which are not expected to act collectively and are not formally or legally recognized; i.e. a collection of entities that isn't an Organization.
The following fields exist on Group and would be helpful for representing huddles:
| Field | Card | Value / Description |
|---|---|---|
| type | 1..1 | person |
| actual | 1..1 | true |
| code | 0..1 | make up our own code to represent huddle lists |
| name | 0..1 | friendly name, e.g., Hennawi Huddle Feb 2, 2016 |
| quantity | 0..1 | count of patients (optional, but may helpful for UI?) |
| member | 0..* | represents each member in the list |
| member.entity | 1..1 | reference to patient |
| member.period | 0..1 | could potentially use to indicate huddle date (a little creative) |
| member.inactive | 0..1 | could potentially use as flag to indicate the patient has been discussed (also creative) |
This doesn't cover the following requirements: huddle leader, huddle patient reason. For these, we would need to introduce the following extensions:
| Extends | Field | Card | Type | Value / Description |
|---|---|---|---|---|
| Group | leader | 0..1 | Reference(Group | Practitioner | Organization) | the group leader |
| Group.member | reason | 0..1 | CodeableConcept | the reason the entity is a member of the group |
We should also consider not using member.period for the huddle date or member.inactive for the flag. In this case, we should add the following extensions as well:
| Extends | Field | Card | Type | Value / Description |
|---|---|---|---|---|
| Group | active[x] | 0..1 | DateTime | Period | the date or period the group is active |
| Group.member | reviewed | 0..1 | boolean | flag to indicate that the group member has been reviewed |
NOTE: Non-huddle-specific field names were used to encourage flexibility and potential re-use.
According to the FHIR definition,
The List resource is a flat, possibly ordered, collection of records. List resources are used in many places, including allergies, medications, alerts, family history, medical history, etc. List resources can be used to support patient-specific clinical lists as well as lists that manage workflows such as tracking patients, managing teaching cases, etc.
The following fields exist on List and would be helpful for representing huddles:
| Field | Card | Value / Description |
|---|---|---|
| title | 0..1 | friendly name, e.g., Hennawi Huddle Feb 2, 2016 |
| code | 0..1 | make up our own code to represent huddle lists |
| source | 0..1 | either IE (as a device) or the practitioner leading the huddle |
| status | 1..1 |
current if today or in the future, retired if in the past
|
| date | 0..1 | technically the date the list was prepared, but perhaps could be huddle date? |
| mode | 1..1 |
working if today or in the future, snapshot if in the past -- but changes if we choose to use entry.flag or entry.deleted
|
| entry | 0..* | represents each member in the list |
| entry.flag | 0..1 | a code indicating why the patient was added to the list (requires mode: changes) |
| entry.deleted | 0..1 | could potentially use as flag to indicate the patient has been discussed (requires mode: changes) |
| entry.item | 1..1 | reference to patient |
If we take a liberal interpretation of all of the property definitions in list, it covers the major requirements (although the source cannot be a Group or Organization). If we take a more conservative approach, we should consider one or all of the following extensions (but beware that some are very close to existing list properties):
| Extends | Field | Card | Type | Value / Description |
|---|---|---|---|---|
| List | active[x] | 0..1 | DateTime | Period | the date or period the list is active |
| List | steward | 0..1 | Reference(Group | Practitioner | Organization) | the steward responsible for the list |
| List.entry | reason | 0..1 | CodeableConcept | the reason the entity is in the list |
| List.entry | reviewed | 0..1 | boolean | flag to indicate that the list member has been reviewed |
NOTE: Non-huddle-specific field names were used to encourage flexibility and potential re-use.