Skip to content

Home

Jump to bottom
Keyne Oei edited this page Nov 8, 2018 · 33 revisions

This document shows how our domain problem has been discovered and how ideas are changed from the beginning until the final prototype. After several discussions and researches including interviews and literature, we have finalized our idea which related to the healthcare system but completely distinct from our initial idea that is proposed in the proposal. Please see our process section for full documentation that contains our researches relate to this issue. The concluded idea is to build a platform for doctors to refer their patients to specialist easily without paperwork and a corresponding platform for the patients to check their referenced specialists and make changes regarding the meeting with specialists.

Conference poster & Promotional Material

The exhibition was conducted at 24th October 2018, from 5.30PM - 7.30PM. EasyReferral booth has 4 promotional material, which are:

The details of our promotional material is in this page

Prototype

Our prototype is divided into 3 users which are patient, GP, and specialist (physician). The interactive prototype is available on the website which purposed for GP and physician. The digital mobile prototype is available for the patient.

The details of the final prototype info could be found in this page

TL;DR

Project Summary

There are several cases here in Queensland with the fact that the patient is left waiting to see a specialist for months. One of the cases is how Danielle Nicholas waited for eight months to be told that she had cancer. This news is from Brisbane Times by Lucy Stone on June 2018 which means the news is recent and not yet solved. Referrals are very important to be noticed especially in the remote areas where people had difficulty to conduct consultation with the specialist. They have to travel in certain distant and make an appointment for a consultation. There are many reasons that cause this results, and one of the many is the fact that the referral system is that the referral system is unstructured and unordered where each hospital has a different system that is difficult to be integrated into one system. Our idea is to provide a simple integrated referral systems from GPs to a specialist that could be used on all hospitals.

In this case, we chose to narrow down the specialist type to the physician as some of our team members have several relatives with a physician, thus, it will be easier for us to conduct research. The platform also will include the feature to book an appointment with the physician. We feel it is very important to include this feature as it will make the whole process quicker on both medical and patient sides. As we have done our research more deeply, we've found insight regarding the referral system that Queensland has at the moment. The detailed research could be found in this design process link, Research for Easy Referral. After all the user testing and research from different kinds of literature and published documents, we have concluded our project features as follows:

  1. GP

    • Create referral. Creating referral is divided into 3 steps, which are to choose range of dates based on the patient preference, choose the nearest physician based on both GP and patient preference, and create referral detail based on patient information and patient illness at the moment.
    • Choose nearest physicians. Choosing the nearest physician could be adjusted based on the patient preference of address.
    • See Referral History. Seeing all referral and patient history that the GP has made. GP also could see the status of the referral.
    • Chat with a physician. By having a platform to communicate, GP could address the problem with the assigned physician easier. It's also more straightforward and a smooth process to keep track of any communication history. Each referral has its own chat platform.

  2. Physician

    • Approve referral. By approving referral, it means that the physician is agreeing to the following date that GP and patient choose earlier. The approving referral also makes certainty for the patient regarding having the consultation with the physician.
    • Set schedule. By setting a schedule, when GP create the referral, the system will know whether or not the physician is available at the range of dates. However, the system won't put the detail. The website only will display the available physicians.
    • See detailed referral. Referral detail page is very important for a physician in order to know the referral description and patient history.
    • Chat with GP. By having a platform to communicate, Physician could address the problem with the assigned GP easier. It's also more straightforward and a smooth process to keep track of any communication history. Each referral has its own chat platform.

  3. Patient

    • Have an appointment from referral. By having an appointment with the referral, the date and time are set where it guarantees the appointment schedule for the patient.
    • See referral detail and updates. By having updates, the patient is informed if any changes with the referral are made.
    • Change appointment DateTime. By having a feature to change appointment DateTime, the patient could be more flexible in making free time in order to see the physician.
    • Get notified when the time is near. Having notification on reminding the event will be helpful for the patient and decrease the possibility of late appointment.

Social and Mobile technology

The context of social and mobile computing is that the platform will interconnect users on the move and have interaction based on the location.

  • Semantic & Social Relationships: Social software aims to coordinate, collaborate, and communicate through a software/display. The system outcome of this platform will combine three parties that were mentioned above in the target audience sections. Three of them are expected to have an active engagement to the platform where all parties could participate in supporting the creating an appointment based on the referral. By participating, the platform will build relationships between all parties that is based on our main goal. One other important relation is to keep GP and Physician communicate if there is an issue regarding a referral. This communication feature is achieved by providing a platform for both parties to chat. The content that is in the platform is created by both parties combining the patient need.

  • Location-based: The mobile software is the technology that travels with individuals. The platform also will support the location awareness where GP could search for the nearest physician from the designated address. For example, an individual lives somewhere near Birdsville. Thus, by having this location awareness, GP could recommend patient to have physician near Birdsville by searching the physician in this platform. Our team sees the location issue as a very important issue because travel distance becomes one of the vital barrier issues in rural healthcare. By having this feature, the distance that a patient needs to travel is reduced.

Theoretical Concept

CSCW - Collaboration Awareness

  • Synchronisation & Shared feedback. synchronous communication happened in a centralized architecture which is in the website platform that is hosted by one server website. One example is when users are using the chat feature in our platform. The chat feature aims to make communication between GP and physician easier and quicker. The system also aims to have a painless system where both GP and physician could keep track of their history in each referral. After the user typing and sending the message, another user would automatically receive the message at the same time. This concludes the communication happened synchronously. In the chat page, users could see who is in the chat forum and what is happening. The chat will send notification inside the chat platform if there is a new user in the forum and who is active or inactive at the moment.

  • WYSIWIS ( What you see is what I see ). This expresses similar characteristics of face-to-face meetings. This platform does not support strict WYSIWIS because not everyone could see what anyone is pointing at on the website. We implement relaxed WYSIWIS where it shows the same display space whenever the user is placed geographically. We support multiuser interfaces in chat features and also other referral interface related. For example, users are able to see the same status as the referral whenever users visit the same referral ID.

  • Centralized program for GP and Physician (Website). Centralized portion and replicated program for Patient (Mobile App). Despite having a centralized program is slow and lacks responsiveness, this technical consideration has given our group many advantages. One of the most important advantages is that the content is maintained consistently. The referral content consistency for all users is very crucial and vital for our project. The centralized portion (application) for patient aims to bring more responsive feedback to the users, including notification. The centralized portion also comes into our expenses which is difficult to be applied and synchronous with the centralized program for GP ad Physician.

Process

Our design process is separated into 3 sprints. Sprint 1 and 2 are ended with stand up meeting that is conducted inside contact session. Sprint 3 is ended with showing our final iteration prototype in exhibition. Concisely, here is our visualized design process:

Each process detail information could be accessed in the links below.

Sprint 1 (start - stand up meeting 1)

Sprint 2 (stand up meeting 1 - stand up meeting 2)

Sprint 3 (stand up meeting 2 - end)

Team Members Contribution

Keyne Oei - 45114551

Attend all meetings outside the contact session. Meet with UQ Centre Health for research. Do research based on literature and published documents. Make design guidelines. Collaborate on deciding task flow. Collaborate on low fidelity prototype. Make full high fidelity prototype. Make all interactive prototype interfaces including its APIs. Make the brochure and poster. Shooting and editing the promotional video. Make a full informative website. Collaborate on final documentation. Make most of the final documentation and final iteration. Proof read all the code and documentation.

Immanuel Lucky Ndilowe - 44241469

Do user testing. Collaborate on documentation. Shooting for promotional video. Collaborate on prototype development. Interview users using Skype and email. Do presentation. Attend all meeting outside contact session.

Fong Yng Dong - 45196520

Attend all meetings outside contact session except during mid-semester break. Collaborate on low fidelity prototype. Collaborate on second user testing's interview questions. Print and collect jobs on poster. Collaborate on all documentations.

Wei Shan Liew - 44661665

Attend all meetings outside contact. Collaborate on low and high fidelity prototype. Collaborate on documnetation. Decoration on the showcase.

Sprint 1

Sprint 2

Sprint 3

Clone this wiki locally