Ognomy Phase 3 Secretary UI Prototype Part 2

CHALLENGE OBJECTIVES

• Build the UI for the new secretary and technician roles to be added to the web app.

 

PROJECT BACKGROUND

• We are building a mobile app that allows patients to schedule and participate in teleconsultations on their mobile device, and a web app that allows doctors / admins / secretaries to view teleconsult schedules and participate in teleconsults from a desktop device.

• In this phase we are planning to add a lot more features to the web app and update the mobile app with some new features.

 

TECHNOLOGY STACK

• ReactJS

• Redux

• HTML5

• Javascript

• REST

• JSON

 

CODE BASE

You need to work with the provided code base which is a functional web app integrated with backend. You are supposed to implement new pages for the secretary role but NOT break any existing functions. This is considered a major requirement in the scorecard during review.

 

CODE QUALITY

You must take code quality into consideration, for example: you should create components for reusable UI / features instead of copying and pasting the same code everywhere. This is considered a major requirement in the scorecard during review.

 

API INTEGRATION

For the new secretary pages, please make sure you don’t hardcode any data, instead please create local json files and use these as data sources for the new pages. You should create local services to get data from the JSON files and properly implement state management.

 

SCREEN REQUIREMENTS

Home (screen 01)

Please use secretary@dummy.com / topcoder to login to the app, and you’ll see the current secretary role home page.

 

Please make the same home page and all the other pages below accessible to the technician role too: technician@dummy.com / topcoder

 

Right now if you click on a New Order, the right pane shows Discharge Summary, that needs to be updated to match the order pane shown in the design (screen 02):

• The order type should be the header at the top of the pane (can only be HST or PAP)

• The blue card should have patient name and contact information

• Order Status

  • When the order is new, no status bubbles should be filled

  • The ‘Paid’ status should be auto-selected when the stripe API verifies that the patient has paid for the order (simulate this using data from json file)

  • All other items should be manually selectable

  • Please switch the order of “Reviewed” and “Scored”

• Copay card

  • Should auto-populate the patient’s insurance carrier (load from json file)

  • Coplay should default to $0

    • If the user clicks ‘Update’ and the copay amount is still set at $0, a prompt should appear: “You are about to submit an order with a $0 copay. Proceed / Go Back“:

      • Proceed should submit the changes

      • Go back should close the prompt and will not submit the changes

  • Order card (screen 03)

    • Information should populate from orders physicians create (for the purpose of this challenge, load such info from local json files)

    • Secretaries cannot edit the order info (show Edit as disabled)

    • ‘Print’ should print the patient name, contact info, insurance info, order info, and physician info

    • ‘Send to’ should send the order to interoffice messaging but for the purpose of this challenge, it’ll be a dead link

    • Cancel order should open ‘Cancel’ modal (screens 04 & 05)

      • The use cancelling the order, the date, and time should auto-populate

      • The order should not be removed from the database, but should stay attached to the patient

      • The order should stay on the UI, but the Order Status should be ‘Cancelled’

    • Home Care Vendor

      • Change text to ‘Vendor’

      • Default to ‘Ognomy’

      • “New Vendor” should open new vendor prompt (see below)

    • Physician card

      • The ordering physician’s information should auto-populate

      • Replace ‘E & M Code’ with physician NPI number

  • Update button

    • Submits the changes

    • This should create a new entry on the required items screen (see details on screen 10 below)

 

Patient Profile (screen 07)

This screen is mostly built but we need some updates to this screen:

• Add a new card under Quick Links named Orders

  • Clicking it will open the order pane on the right side of the screen (screen 08)

  • The pane should list all orders for the patient in all statuses

  • Clicking on the order name (e.g. HST Order) should take the user to the specific order screen (screen 09)

    • This screen should have the status card from screen 02 (missing in design but needs to be implemented)

    • When the order is in status ‘Paid’ the copay and vendor should no longer be editable.

      • At this point, only the ‘Status’ should be editable

    • Screen 09 is a ‘read-only’ view of 02, with the above exceptions

• Required Items is currently a dead link, update it so that it links to the patient details page (same as clicking on the little edit icon on the top right corner of the blue card)

  • Update the title of the patient details page to Required Items

  • Remove the Medical Questionnaire section

  • Update the Payment section to show a table of orders under the credit card info div (screen 10)

    • New items should be populated from screen 2 on click of ‘Update’ button if there is a copay

    • Appointment copays should also populate (load from local json file)

    • Status should be ‘pending’ until verification comes from Stripe that the user has paid for the order (load from local json file)

    • Then the order is paid for, the status should be ‘paid’

    • If an order is ‘paid’ there should be a ‘refund’ button

    • If the order is ‘pending’ there should be a ‘cancel’ button. 

      • This should trigger the should open ‘Cancel’ modal (screens 04 and 05)

      • Should cancel the order with Stripe

 

Home Care Vendor Info (screen 11)

Clicking on the Home Care vendor card from the patient profile should open the vendor selection pane.

• All previously added vendors should populate

• When a vendor is selected, it should associate with the patient (like a setting)

• Anywhere ‘vendor’ is invoked on the web app should auto-populate the patient’s prefered vendor. 

• On click of the ellipsis, “edit” and “delete” options should be visible

• Edit should navigate to the ‘add vendor’ pane (screen 12) filled with exiting info

  • Changes should reflect across the app

• ‘+’ button at the top right of the pane should open blank ‘add vendor’ pane (screen 12)

  • New vendors added should be globally accessible

  • Vendor Name should auto-populate with existing vendor names (goal here is to keep folks from adding duplicates) 

  • Newly added vendor should be auto-selected for the patient in the left-hand pane

 

Tracking

The tracking page is out of the scope of this challenge.

 

GENERAL REQUIREMENTS

• Must use ReactJS and follow the provided design.

• The main content should have fluid width to fill all the available space, the minimum supported resolution is 1280*720 (height is actually unlimited since the page can scroll).

• Searching / filtering should work whenever applicable.

• Pagination should work whenever applicable.

• Filtering/pagination happens on the server side so you need to pass the query parameters and the server is expected to return the pagination info (pageSize, total etc).

• Implement popup for confirmation and warning messages. Do NOT use browser alerts, but use custom styles popups as shown in the design

• Show loading spinners when populating data from API / local JSON to UI

• Implement validation errors (for example: login error as shown in design)

• No linting errors

• No errors with prod builds

• You are expected to create a detailed README file including information on how to setup, run and verify your application.

 

CODE REQUIREMENTS

• ES6 syntax is preferred, as Babel has been set up to handle transpiling the syntax to the current JavaScript standard.

• Use .jsx extension for React components; using PascalCase for filenames. E.g., ComponentName/index.jsx.

• Do not create a single .css/.scss file for the whole app. Each component should have its own stylesheet file.

• Ensure that there are no lint errors.

• You’re free to choose between CSS & SCSS but you need to use flex instead of float.

• Follow a clean folder structure.

• Create reusable components.

 

JAVASCRIPT REQUIREMENTS

• All JavaScript must not have a copyright by a third party. You are encouraged to use your own scripts, or scripts that are free, publicly available and do not have copyright statements or author recognition requirements anywhere in the code.

• Use ES6 linter for code quality

 

LICENSES & ATTRIBUTION

• Third-party assets used to build your item must be properly licensed and free for commercial use. MIT and Apache v2 licenses are ok, for any others please check with us to get approval first.

• Sufficient information regarding third-party assets must be present in your documentation. This includes the author, license info and a direct link to the asset online.

 

BROWSER REQUIREMENTS

• Windows: IE 11+, Chrome latest, Firefox latest

• Mac: Safari Latest, Chrome Latest, Firefox Latest

Final Submission Guidelines

FINAL DELIVERABLES

• Full code that covers all the requirements.

• A detailed README file including information on how to setup and run your application.