# 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 ```sequence 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 ```YAML 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! ---