# Argo Patient List Connectathon 26 Summary Slides
![](https://i.imgur.com/ccRcmMx.png)
<!-- Put the link to this slide here so people can follow -->
slide: https://hackmd.io/13214aLMQrW4-lYWYSYgUQ
---
## Who Participated?
#### Servers ( in addition to the open HAPI test server )
- Meditech
- One Medical
---
## Who Participated
#### Clients
- Epic
- Meditech
- *add your name to the list*
- 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/)
---
### What we covered:
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 Questionnaire as Form Definition and QuestionnaireResponse as Data Container.
3. By Encounter and Appt extensions
---
### Accomplishments
- **Able to demonstrate basic proof of concept for above workflows**
- Clients *and* Servers
- Test Data available for the various scenarios
- Demo apps able to demonstrate getting additional data using the extensions
- Review of Argo Group Profile and IG
- Validated that Using the *Group* resource is the right choice.
---
Some Screenshots... (*contributions welcome*)
---
Getting Additional data using Q/QR:
![](https://i.imgur.com/4VlXILa.png)
---
Getting Additional data using the Appointment extension:
![](https://i.imgur.com/jHCL74U.png)
---
Getting Additional data using the Encounter extension:
![](https://i.imgur.com/U6cn2gk.png)
---
### Gaps/Things we did not Accomplish
1. Lack of Server participation (but we talked about conformance requirement)
2. Looking at intersection with bulk data as list get large and [guidance on paging](https://hackmd.io/tBVF57gERz-REm3_QkWtCg#Fetching-User-Facing-List?view)
---
### Issues
---
1. Group vs List confusion to people new the the project
- Suggestion to change name to *Provider Patient Lists* or * *User-Facing Patient Lists* ?? to reflect current scope
- [ ] Discuss at next Argo-PL meeting
---
2. API extended to other contexts of use such as Payer-Provider, Research
- Encourage down the road when move to HL7
- Using Group consistently in FHIR
---
3. Patient focused search (e.g. what cohorts is this patient a member of)
- `Get Group?member=123`
- Out of Scope - wait until move to HL7 (...especially if change name of guide...)
---
4. Require that all `Group.member` structures are the same. This means the same kind of argo extensions for each member.
- This means for Q/QR the QR item may need to be unanswered for some members
- [ ] Document this in IG
---
5. Keep extension on `.member` instead of `.member.entity`
- [ ] Confirm at next Argo-PL meeting
---
6. Discovery of what extension are available ahead of time for each Group instance is not possible.
- general issue in FHIR
- Servers SHOULD advertise what extensions the MAY support in the CapabilityStatement. (out band OK too)
---
7. Review of Group profile:
- see comments in IG
- Extensions are not Must Support
- Other elements not Must Support
- See above re conformance
- Encounter and Appt extension 1..* instead of 1..1
- [ ] Update IG and discuss at next Argo-PL Meeting
---
Next Steps:
1. Updates to Argo IG
2. Discuss at next argo meeting
3. "publish" Argo IG
4. Continue hand-off to HL7
5. Complete demo/codelab applications
---
Wrap-up
---
Thank you!!!!
{"metaMigratedAt":"2023-06-15T18:34:01.939Z","metaMigratedFrom":"YAML","title":"Argo Patient List Connectathon 26 Summary Slides","breaks":"false","description":"View the slide with \"Slide Mode\".","contributors":"[{\"id\":\"20c0d774-7b10-4501-a676-04936b05fcb3\",\"add\":10870,\"del\":7173}]"}