Title: Digital Health App – DIAGNOSYS
[Start of recorded material at 00:00:00] [A slide displays with a green orange and black image prominently on the screen. On the left of the image is a green and orange vertical stripe, an image of a tablet, half green and half orange followed by the word DIAGNOSYS which is green and orange. In smaller white print the words HIERARCHICAL DIFFERENTIAL DIAGNOSES. At the bottom of the image in small print are the words in white, Team Thundercats: Leo Baldcock, Kathryn Bird, James Ferreira, Michelle Own, Luke Wilson]
The SMART on FHIR app DIAGNOSYS was created to supplement and improve the learning experience of medical students within Case Based Learning sessions.
[A slide displays with the heading ‘PROBLEM SPACE’ and the following dotpoints under the heading. First dotpoint, Poor workflow for differential diagnoses within Case Based Learning (CBL), second dotpoint, Current process utilises a whiteboard (or Google Doc equivalent), third dotpoint, issues with efficiency, use of incorrect terminology and last dotpoint, client requested digital system with 2 main columns, Likely Diagnoses and Critical. The right side of the slide has an example of a whiteboard with multiple columns in multiple colours as an example.]
The current process comprises a whiteboard or Google doc equivalent with two main columns, likely diagnoses and need to rule out. However, the static medium of a whiteboard is unsuitable for the iterative nature of CBL sessions and the continual reordering of diagnoses. This results in a frustrating experience for the students. Further, students tend to generate inaccurate terminologies for their differential diagnoses, which fail to match professional industry standards.
This subsequently detracts from the overall lesson objectives of the CBL and, by extension, the platform’s capacity to stand as an effective learning and revision tool for the students.
[A slide displays headed SOLUTION APPROACH. The slide has one dotpoint under the heading which states, DiagnoSys aims to improve efficiency and accuracy of differential diagnoses generation while actively supporting learning. Below the text the there is the green and orange logo and green and orange text DIAGNOSYS. The bottom section of the slide is split into two, the left side displayed in green and headed LIKELY DIAGNOSES with a list of diagnoses underneath. Th right displayed in orange headed CRITICAL with a list of diagnoses underneath.]
In response to this problem space, we developed DIAGNOSYS, a system which aims to improve the efficiency and accuracy of differential diagnosis generation through actively supporting students in their CBL sessions while leveraging modern advancements in the field of digital health.
[A slide displays headed, LIST ITEMS and SNOMED SEARCH. Underneath the heading the slide is split into to parts. The left half is a green box with the heading LIKELY DIAGNOSES, the right side has two dotpoints. First dotpoint, Uses SNOMED-CT AU API to enforce standardized medical nomenclature, next dotpoint, HTTP GET Request] [The following slides display how to search diagnoses options displayed on the left side of the slide. A window opens as the user starts to enter letters into the search field. The window opens a list of matches relevant to what has been entered into the blank field. The slide continues to add likely diagnoses after each selection dependant on the text the user is entering into the blank field.]
We achieved this through adopting a Web application that facilitates the rearrangement of differential diagnoses across two lists while using the SNOMED-CT AU API to enforce standardized medical nomenclature.
[A slide with the heading SNOMED-CT QUERY displays. The body of the slide displays how a query is broken down for example SNOMED-CT Server, Resource Type, ValueSet expansion operation. Followed by the Code System, Expression Constraint Language Query restricts results to Disorder ValueSet, the Filter term from search input and finally the number of values returned in expansion.]
A http GET request was used to retrieve the SNOMED value sets from CSIRO’s Ontoserver. These results were limited to those within the SNOMED-CT disorder value set and filtered to match the student search input.
[A slide displays with the heading REARRANGEABLE LISTS. There are 2 boxes underneath the heading labelled, Likely Diagnoses in a green box and Critical in an orange box. Likely diagnoses is broken down to three items, 1 Hypertension, 2 Dropped Head Syndrome, 3 Deficiency of Aryl Sulfotransferace. Critical is broken down into two, 1 Cardiac Arrest 2 Aneurysm. Below the green and orange boxes are the following dotpoints. First dotpoint, Facilitates categorising diagnoses into separate ideas, second dotpoint, Ability to move between diagnoses between lists, with sub point below being, Drag and drop, Transfer buttons and Manually input row numbers. The slide displays the user moving items from the Critical side of the screen into the Likely Diagnoses and vice versa.]
[A slide with the heading Annotations displays. Under the heading is a green box with the number 1 on the left, a white field with the text Domed Head. Below the green box the following dotpoint, Allows students to enter free text notes allowing for, sub dot points, Diagnosis justifications, Diagnostic test recommendations, Listing pertinent patient information, Individualised student note systems, All notes can be toggled on and off. The slide display the adding of note to the diagnoses.]
Each of these entries within our list is rearrangable through drag and drop, editing the list number or using a transfer button and students can also add diagnosis specific notes that persist between rearranges.
[A slide with the Heading EXPORT displays. The slide is split in two, the left side shows a window with the green and orange tablet image and word DIAGNOSYS. Below this is a list of Likely Diagnoses and Critical Diagnoses. The right side of the screen has the following dotpoints, Allows students to download a copy of their diagnoses for later reference without needed to return the HER platform, Exports include the student’s notes which are not saved to the FHIR resources, Export formats include, JSON, Markdown and PDF.]
The export functionality allows list contents to be exported into multiple formats such as FHIR, JSON. Markdown and PDF, and this subsequently provides the user with an effective revision material for personal studies.
[A slide displays with the heading SYSTEM ARCHITECTURE. A flow chart displays under the heading, the top section shows three boxes on the left underneath each other, PDF, JSON, MARKDOWN, the next box to the right is DIFFERENTIAL DIAGNOSIS, the third box to the right is EPISODE OF CARE RESOURCE and last on the right is an image of the FHIR SERVER. The flow shows data going back and forth from Episode of Care Resource into the FHIR Server Communication Protocol, and back and forth from Differential Diagnosis to Episode of Care Resource, and from the Differential Diagnosis one way as an export into PDF, JSON and MARKDOWN on the left side of the screen. The bottom section of the slide displays how the data feeds from Differential Diagnosis into Likely Lists and Critical lists, through to List Rows and into SNOMED SEARCH using http Get into OntoServer and back to return disorders into SNOMED SEARCH.]
With respect given to the back end functionality DIAGNOSYS makes use of FHIRs Episode of Care Resource to represent a differential diagnosis allowing differentials to be saved and loaded from a FHIR server.
[A slide with the heading FHIR RESOURCES displays. The slide is split into 2 sections, a left side which has the heading EpisodeOfCare, and the right side which has the heading Condition. Below these headings is a diagnoses element.]
Within each Episode of Care Resource, there is a diagnosis list element, this contains objects, each with a condition, role and rank. In this year’s case, the role element can take on a value of either likely or critical, indicating the list a student has assigned a particular diagnosis to within the application. The rank element represents the position of a diagnosis within the relevant list, and the condition element is a reference to a FHIR condition resource. This Condition resource includes a codable concept which represents a disorder a student has selected within the application.
[A slide displays with the heading SMART ON FHIR. The slide displays the flow of data to and from the App to the HER FHIR Server and from the App to the EHR Authz Server.]
Finally, the SMART App Launch Framework is used to facilitate the connection to the EHR FHIR Server and retrieval of EHR contacts information in order to utilize the FHIR resources. As DIAGNOSYS was designed to be used within the context of a CBL platform, the EHR launch sequence has been implemented.
[The slide displayed at the beginning of the presentation is displayed again with the green and orange tablet image, and the green and orange text, DIAGNOSYS.]
In doing this DIAGNOSYS has privileged the efficient and accurate generation of differential diagnoses within an effective, SMART on FHIR application.
[A slide displays with the heading, More from Aust e-Health Research Centre and a number of images of Artificial Intelligence and Machine Learning in Healthcare and SMART Questionaires.]
[End of recorded material 00:03:3804]