I need to create a program that will be something like a remote diagnosis system. The detail follows:
There will be two separate programs:
1) Patient's end
2) Doctor's end
The Patient's end program will:
a) Present a graphical user interface that is primarily mouse-driven for all user actions.
b) Allow user to create a profile (in a form format) for a patient, which will contain all the vital and necessary information of the patient -- including attachment of reports as an image format. The profile can be in a simple HTML or private file format.
c) Allow user to access a list doctors who are online at that time, select a desirable doctor and send the profile to that doctor.
d) After being prescribed by the doctor, allow the patient to access the prescription and print it.
The Doctor's end program will:a) Present a graphical user interface that is primarily mouse-driven for all user actions.
b) Allow the user to access the list of patients wanting to get diagnosed.
c) Allow the user to view the particular patient?s profile.
d) Allow user to send a prescription to the patient.
Can you help me figure out how I should go about putting this project together? Any guidance would be really appreciated. Thanks.
There is no simple answer to this question, as you are basically asking for a starter design given limited requirements and no specified prioritized objectives outside of basic functionality. Given the medical applications that I've worked on, I know that secure transmission and storage of patient data is a high-priority requirement. Platform support for doctors and patients also dramatically affects the design of the solution. Another design impacting requirement is how much data the application is going to move. I'll attempt to give you a start making assumptions about these additional limited requirements. You're going to need to expand on them before choosing a solution, but this should help get things rolling.
First let's choose a scenario to start with. Let's assume that patient-doctor data exchange must be secured (this is going to be true for all the solutions). Let's also assume the platform for patients can be anything and that doctors are going to be on Windows based platforms. And let's assume that the data to be transmitted from patient to doctor is less than 1 MB (about a 2-four minute transfer on a 56 Kbit connection). Given this scenario, patient data can be managed on the patient's machine and transferred only to the chosen doctor when needed. Therefore, we don't have to worry about securely storing the patient's data on a server anywhere (only on the patient's machine). We'll likely want to encrypt it on the patient's disk with strong password protection.
Now, how do we get the information from patient to doctor? Because the patient's platform can be anything, we'll need to use a Web interface for the patient. The Web server will be responsible for listing online doctors and establishing connections between a patient web session and a doctor who is online. If we assume the doctor uses a web app, then the doctor's session and the patient's session can be connected and maintained by the Web server. Both patient and doctor can be pointed to a common set of pages where interactions can take place. When the patient uploads their data, it goes to a temporary location that is recorded in both sessions. When the data is sent by the client, it will be encrypted automatically during transmission if we are using HTTPS. However, once it is stored in the temporary location, it will no longer be encrypted, and we will need to encrypt it on the server in a fashion that the doctor can decrypt (maybe using a public key owned by the doctor). Now the doctor can view it through his web session. Because the location of the temporary data is known only to the patient and doctor's sessions, this is a fairly secure solution. Once the doctor determines his diagnosis, the prescription can be transmitted back to the client in a similar fashion.
Now, let's tweak the scenario a bit. Let's say the doctor's UI must have more functionality than a web interface can handle. Since he's on a PC platform, we can use Windows Forms for the doctor's applications. However, because the patient is using a web-interface, you'll want the doctor's application to be able to interface to the web server in the same fashion (here I'm thinking Web service). Much of the same functionality discussed above can carry over.
Now, if the patient's platform can be restricted to Windows platforms, we can go to a peer-to-peer solution. Remoting comes to mind in this scenario and removes any need for a Web server to provide the data transmission mechanism. You'll still need some form of a master server that keeps track of online doctors so patient's can query who is online.
If the data that must be transmitted is large (say > 5 MB) you may need a server to keep patient data. Patients log in and enter their data once and then doctors can access this data on a single server. This creates a much more complex solution. Secure access to and storage of patient data is a real concern in this scenario. If you develop applications in the medical industr