I need ASP.NET + Entity Framework Developers
- or -
Post a project like this3270
$7.5k
- Posted:
- Proposals: 35
- Remote
- #746543
- Awarded
Web & ERP Developer | 15+ years of experience |Businees Development Proventeq India
Pune
33614861129752323764024768995798932830889833144860930925626917604918659
Description
Experience Level: Expert
Estimated project duration: Approximately 3 months
General information for the business: Online Dermatology diagnostics
Kind of development: New program from scratch
Description of every module: Patient System:
- Open sign-up with PII/PHI
- Create Appointments by
- Filling in 4-step intake forms
- Securely upload images
- View Appointment results as fulfilled by Doctors
Doctor System:
- Sign-in with provided credentials
- View New Appointment Forms
- Respond to Appointment with Diagnosis (and possibly prescriptions)
Administrative system:
- Provision Doctor sign-ins
- Monitor sign-up and workflow statistics
- Handle issues reported by Doctors
Description of requirements/functionality: This application should facilitate the processes of a Dermatologist's office--patient intake forms + patient diagnosis questions; routing appointments to doctors; doctor diagnosis and prescription; and in a later phase, billing; currently limited in scope to a single practice in the United States.
There should be three effective interfaces: a system for patients, for doctors, and for administrative staff. At this stage it may be preferable to implement doctor and administrative interfaces within the same application. However, each user type requires its own authentication subsystem. Patients should not be able to log into an application servicing doctors, and vice-versa.
Patient sign-up will be open to the public. Patients will sign up with the relevant personal information, including but not limited to their legal name, their legal address (possibly more than one), and likely a US federal or state ID number: this could be an SSN, a drivers license number, a state ID number, etc. Considerations for future extensions, such as insurance routing numbers, are required; the implementation of such numbers will be performed at a later date.
United States regulations impose several security requirements over this data. It would be best if this information were not accessible by the Patient side of the application.
Doctors will not be able to sign up directly. Doctor accounts must be allocated via Administrative staff. However, Doctor profile information may be editable by Doctors directly (in addition to being editable by Administrative staff).
Administrative staff will not require a profile except for what is necessary for authentication, authorization, and accounting purposes. We may elect to use Active Directory in production for authentication for this role as well as Doctor roles.
Patients will create virtual appointments through a Patient Dashboard. Each virtual appointment will begin with a 4-step process:
- The first step describes the current dermatological issue at hand
- The second step describes (and potentially update/confirm vs. resubmitting) the patient's medical history
- The third step describes current medication usage
- The fourth step requires patients to upload photos of the affected area
There will be seven categories of appointment, each with distinct questions for steps 1 and 2, with the expectation that the number of categories may increase over time.
These appointment specifications must only be viewable by the relevant Patient and the Doctors. Other Patients should not have access to these appointment specifications, and any Administrative access should be restricted to anonymized information for accounting purposes, or if requested by a Doctor.
Patient images must be served via the application directly. They may not be directly accessible to IIS. The controllers handling Patient image viewing must perform access control to ensure that only the relevant Patient and Doctors may view the images, because the images are covered PHI under HIPAA.
For this iteration, once the Patient has created an Appointment, it should be placed in an Appointment queue viewable by all Doctors. Later iterations will include billing considerations before routing to the Appointment queue; this is currently out of scope.
A Doctor should be able to choose an Appointment to handle from the queue without fear of losing the appointment for the rest of the organization. We may need to both try a strategy where Doctors picking appointments temporarily makes them unavailable for the rest of the organization (with an option to return them to the main Appointment queue) and a strategy where concurrency control ensures that only the first attempt at handling the appointment is published throughout the system.
While handling an Appointment, a Doctor should be able to push the Appointment (and relevant information) to an Administrator for further inspection.
Additionally, as per the HIPAA regulations, all actions within the system will need to have audit capability. At this stage, structured logging to a distinct stream should be sufficient.
Specific technologies required: ASP.NET MVC 5, SQL Server 2012+, Entity Framework, ASP.NET Identity
OS requirements: Windows
Kind of development: New program from scratch
Description of every module: Patient System:
- Open sign-up with PII/PHI
- Create Appointments by
- Filling in 4-step intake forms
- Securely upload images
- View Appointment results as fulfilled by Doctors
Doctor System:
- Sign-in with provided credentials
- View New Appointment Forms
- Respond to Appointment with Diagnosis (and possibly prescriptions)
Administrative system:
- Provision Doctor sign-ins
- Monitor sign-up and workflow statistics
- Handle issues reported by Doctors
Description of requirements/functionality: This application should facilitate the processes of a Dermatologist's office--patient intake forms + patient diagnosis questions; routing appointments to doctors; doctor diagnosis and prescription; and in a later phase, billing; currently limited in scope to a single practice in the United States.
There should be three effective interfaces: a system for patients, for doctors, and for administrative staff. At this stage it may be preferable to implement doctor and administrative interfaces within the same application. However, each user type requires its own authentication subsystem. Patients should not be able to log into an application servicing doctors, and vice-versa.
Patient sign-up will be open to the public. Patients will sign up with the relevant personal information, including but not limited to their legal name, their legal address (possibly more than one), and likely a US federal or state ID number: this could be an SSN, a drivers license number, a state ID number, etc. Considerations for future extensions, such as insurance routing numbers, are required; the implementation of such numbers will be performed at a later date.
United States regulations impose several security requirements over this data. It would be best if this information were not accessible by the Patient side of the application.
Doctors will not be able to sign up directly. Doctor accounts must be allocated via Administrative staff. However, Doctor profile information may be editable by Doctors directly (in addition to being editable by Administrative staff).
Administrative staff will not require a profile except for what is necessary for authentication, authorization, and accounting purposes. We may elect to use Active Directory in production for authentication for this role as well as Doctor roles.
Patients will create virtual appointments through a Patient Dashboard. Each virtual appointment will begin with a 4-step process:
- The first step describes the current dermatological issue at hand
- The second step describes (and potentially update/confirm vs. resubmitting) the patient's medical history
- The third step describes current medication usage
- The fourth step requires patients to upload photos of the affected area
There will be seven categories of appointment, each with distinct questions for steps 1 and 2, with the expectation that the number of categories may increase over time.
These appointment specifications must only be viewable by the relevant Patient and the Doctors. Other Patients should not have access to these appointment specifications, and any Administrative access should be restricted to anonymized information for accounting purposes, or if requested by a Doctor.
Patient images must be served via the application directly. They may not be directly accessible to IIS. The controllers handling Patient image viewing must perform access control to ensure that only the relevant Patient and Doctors may view the images, because the images are covered PHI under HIPAA.
For this iteration, once the Patient has created an Appointment, it should be placed in an Appointment queue viewable by all Doctors. Later iterations will include billing considerations before routing to the Appointment queue; this is currently out of scope.
A Doctor should be able to choose an Appointment to handle from the queue without fear of losing the appointment for the rest of the organization. We may need to both try a strategy where Doctors picking appointments temporarily makes them unavailable for the rest of the organization (with an option to return them to the main Appointment queue) and a strategy where concurrency control ensures that only the first attempt at handling the appointment is published throughout the system.
While handling an Appointment, a Doctor should be able to push the Appointment (and relevant information) to an Administrator for further inspection.
Additionally, as per the HIPAA regulations, all actions within the system will need to have audit capability. At this stage, structured logging to a distinct stream should be sufficient.
Specific technologies required: ASP.NET MVC 5, SQL Server 2012+, Entity Framework, ASP.NET Identity
OS requirements: Windows
Chris A.
100% (5)Projects Completed
4
Freelancers worked with
4
Projects awarded
0%
Last project
25 Jul 2019
United States
New Proposal
Login to your account and send a proposal now to get this project.
Log inClarification Board Ask a Question
-
There are no clarification messages.
We collect cookies to enable the proper functioning and security of our website, and to enhance your experience. By clicking on 'Accept All Cookies', you consent to the use of these cookies. You can change your 'Cookies Settings' at any time. For more information, please read ourCookie Policy
Cookie Settings
Accept All Cookies