---
title: Argo Patient List Summary Slides
tags: argo-pl
description: View the slide with "Slide Mode".
---

# Argo Patient List Summary Slides


<!-- Put the link to this slide here so people can follow -->
slide: https://hackmd.io/DRTZx4jlRIWqpean8sLVEQ

---

## Who Participated?

#### Servers ( in addition to the open HAPI test server )

- Epic
- Cerner
- Meditech
- Microsoft

---

## Who Participated

#### Clients

- Apple
- Epic
- PeraHealth?
- MIcrosoft : ([Demo App](https://aka.ms/patient-lists-demo) , [CodeLab](https://aka.ms/patient-lists-codelab))
- Health eData Inc: [Argo Patient List Demo Client](http://www.healthedata1.co/)

---

### Usage flow

Note left of Client: Discovery:\n Fetch Summary of\n Patients Lists
Client->EHR FHIR Server:GET Group?...
Note right of EHR FHIR Server: Based on User\n return Bundle of \nUser Facing Lists
EHR FHIR Server->Client: Bundle
Note left of Client: End User\nselects Patient List\n they want 
Client->EHR FHIR Server:GET Group/[id]
Note right of EHR FHIR Server: Returns full Group\n resource
EHR FHIR Server->Client: Group
Note left of Client: Client Application\n MAY fetch more data for \neach member using a \nseries of FHIR API\n queries
Note right of EHR FHIR Server: Returns search results
Client->EHR FHIR Server:Query 1
EHR FHIR Server->Client:
Client->EHR FHIR Server:Query 2
EHR FHIR Server->Client:
Client->EHR FHIR Server:etc
EHR FHIR Server->Client:
Note left of Client: Client Application\n processes/displays/etc\n Group Members\nto End User

---

1. Discovery
1. All lists
1. By ManagingEntity
2. By Characteristics
3. Fetch User Facing List
4. Fetch Additional Patient Data
1. By Simple Search
2. By _include
3. By Questionnaire as Form Definition and QuestionnaireResponse as Data Container.

---

### Accomplishments

- **Able to demonstrate basic proof of concept for above workflow**
- Clients *and* Servers
- Fixes to Demo Application to handle the various scenarios
- Update and correct errors to Sample data ( Group resources)
- Servers to added more capabilities for discovery by characteristics
- Clients able to demonstrate getting additional data using Q and QR lookups

---

Some Screenshots...

---

Getting User Facing List filtered on Characteristic:


---

Fetching User Facing List and Getting Additional Data:


---

Fetching additional patient data via Questionnaire/QuestionnaireResponse Data attached to the Group:

Epic


---

### Issues

- Need more complete set of test data
- Example patient list for different use cases
- Patients, Practitioners, Organizations, Locations, CareTeams, Groups, Questionnaires, QuestionnaireResponses + more
- Next Steps EH,CA to create more test data:
- larger lists for next time to test scalability
- EH - added more data 20-30 patients range with Q + QR extensions
- More Robust Servers to test against
- _summary search..Ref est servers not set up to handle summary + characteristics for _summary search..

---

Next Steps:
- CA stand up public server
- Transaction bundles to load onto existing test servers.
(Saved Sept 2020 data as Transaction Bundle so can load to any server.)

---
### Issues

- How to fetch Encounters for each members?
- Search vs "custom" extensions vs Q/Qr (see below for Q/QR issues)
- e.g. custom extension on member ( see similar request [FHIR-23863](https://jira.hl7.org/browse/FHIR-23863) which was voted down by FHIR-I)

for mock up each option - see below...

---

### Issues

What is the next step beyond display. What does the end do with t list-user

e.g. pract scheduling list - patinet + appt + preseenting complaint

or discharge list :

- Is Encounter a special case or does this extend to other resources as well
- active vs inactive - can client modify group? (not in scope)

---

### Issues

- Issues when number of members is large
- fetching additional data etc
- i.e. multiple queries vs one large query.
- becomes asynch at some point
- Test at next Connectathon
- Quantity element in Group Summary for dynamic Groups
- how is known without creating Group?
- handy for client to have in Summary view but may not be easy to compute for server.

---

### Issues

- RE Q/QR
- keeping structure flat vs allowing deep nesting
- structure of QR == Q and rendering arbitrarily nesting is hard for clients
- this constraint would make is more accessible IMO
- what about multiple Forms available for the same list? aka different views for different audiences?

---

### Issues

- Q/QR "just for Display" ? (IMO this would be too heavy a solution for just display)
- what kind of data - uses for the data beyond display
- Q has ability to define item and provide reference for more data.
- can be inspected:e.g...

---

### Issues

resourceType: Questionnaire
url: 'http://registry.fhir.org/argonaut/Questionniare/argo-pl-q1'
name: ArgoPLListTestQuestionnaire1
title: Argo PL List Test Questionnaire 1
subjectType:
  - Patient
date: '2020-09-24T22:17:44.629Z'
publisher: The Argonaut Project
description: >-
  *Argo PL List Test Questionnaire 1*  is an example Questionnaire to test out
  the use case for providing additional data for a patient list.
useContext:
  - code:
      code: workflow
    valueCodeableConcept:
      text: 'My use case, for example, ICU Rounds List'
purpose: >-
  This Form is designed for displaying additional patient list data in the "XYZ"
  Setting for "ABC" use case.
item:

---

### Issues

see [Demo](http://www.healthedata1.co/) for how it can be used

---

### Issues


---

### Issues

-vs Supporting Info extension on `Group.member`

---

~~~YAML
resourceType: Group
active: true
type: person
actual: true
name: 'Argo Patient List #102: "all" Use Case'
managingEntity:
reference: Organization/a9f20dc1-5147-3789-bcef-bbecb41c5983
display: HOLY FAMILY HOSPITAL
member:
# ===========EXTENSION HERE =================
- extension:
- url: http://registry.fhir.org/argonaut/StructureDefinition/current-encounter
valueReference:
reference: Encounter/5fe62cd5-bfcf-4d3b-a1e9-80d6f75d6f82
display: Argo PL List Encounter Reference
# ===========================================
entity:
reference: Patient/06e1f0dd-5fbe-4480-9bb4-6b54ec02d31b
display: Mr. Elden718 Halvorson124
period:
start: '2020-09-29'
inactive: false
~~~

---

### Issues
- What Do servers and Clients prefer?

- Other options if just for display:
- json file in reference.display element
- contained csv as Binary or DocReference resource
- reference to FHIR Parameters.

---

### Issues

- Group Resource
- Restrict references to references (not only identifiers)

---

### Issues

- what do multiple Characteristic means?
- based on comment "All the identified characteristics must be true for an entity to a member of the group." is an intersection
- how to do a union like location1 + location2? or location1 + practiitioner1?

---

### Issues

from [FHIR-24849](https://jira.hl7.org/browse/FHIR-24849)
*Within the existing structure, the 'or' capability can be achieved by defining sub-groups that are members of the parent group (they can be 'contained' if it would be inappropriate to reference them independently).*

---

### Issues

- Etensions should be on `group.member` instead of `group.member.entity` element?
- I think so - in general is better on the "root" element

- member.entity not intuitive element name: how about "reference"
- changing elements names is painful- is 'juice worth the squeeze'

---

### Next Steps

- Add more test data to Servers
- Servers that can handle the fetching additional data using the Q/QR
- Add more info to developer panel in CodeLab
- Servers to add more capabilities for fetching additional data
- e/g support _include and batch processing
- Simplify codes for characteristics
- Define formal definition for extensions, codesystem
- Ultimately IG

---

### Wrap up

---

### Thank you!

---