You can download the solution to the following question for free.
For further assistance in Information Technology Assignment help, please check our offerings in IT solutions. Our subject-matter-experts provide online assignment help to IT students from across the world and deliver plagiarism free solution with free Turnitin report with every solution.
(AssignmentEssayHelp do not recommend anyone to use this sample as their own work.)
IT Assignment Question on Claim Generation System
The national health insurance system “Medigood” that pays for patient’s visits to family doctors has provided a new category of service that family doctors can be funded for. This is for a Telehealth medical specialist consultation for a qualifying patient. To qualify patients need to be any one of:
- over 65
- diabetic or suffering other chronic disease.
A consultation can occur when a family doctor with a patient in attendance links up for a consultation with a medical specialist using Telehealth equipment. Medigood will make a payment to both the family doctor and the specialist.
Medigood has already provided Telehealth equipment to all doctors and specialists, but to date very few doctors have taken advantage of this; it is believed this is because it is a disruption to their normal workflow and takes too long for them to set up a Telehealth consultation with a specialist. You should do a search of the Internet to understand Telehealth and how it can be used.
Your friend Lee has come up with a new business idea and has asked you for help due to your studies in Business Analysis. Lee proposes to develop a software package that will sit on the doctor’s computer alongside any other patient management system (PMS) they may have taking advantage of available interfaces. Most doctors use the same PMS and the APIs are readily available. Lee’s software will monitor appointments and when it sees the doctor is entering notes or searching for a qualifying patient, or if a qualifying patient has an appointment,it will alert the doctor that the patient is eligible for a Telehealth consultation and search for an available medical specialist. Medical specialists are expected to register with the system which will monitor when they are on-line and potentially available for a Telehealth consultation with a patient and their family doctor. When the doctor and the specialist accept the Telehealth consultation the Telehealth equipment at either end is activated. Once the consultation is completed the software will process the claim for payment to the insurance.
The new system should do the following:
- monitor the doctor’s use of their Patient Management System and check the patient’s record to see if the patient qualifies for a Telehealth Consultation
- alert the doctor if the patient they are currently seeing, or next scheduled patient, qualifies for a Medigood Telehealth consultation
- identify through an already-existing on-line register of specialists available for Telehealth consultations to find a suitable specialist who is available to participate in an on-line consultation
- if the doctor and a specialist at both ends accept the consultation then it will switch on their Telehealth equipment (web-cams and voice) to enable the consultation
- update the PMS with any notes taken by the doctor
- issue a claim form to Medigood for both the doctor and the specialist to be paid for the Telehealth consultation
This system should provide the following benefits:
- automatic alert the doctor that the patient qualifies for Telehealth and invite the doctor to accept the proposed consultation through Telehealth
- search for an available specialist through an already-existing hub
- automatically send a claim to Medigood so both doctors can be paid for the consultation
Following the work you did for Lee that you undertook in Assignment 1 you have been invited back to participate in the project. At this stage you are well ahead with your university assignments and happy to help. Lee has decided to invite tenders for development of the system and has asked you to develop the specification, evaluation methodology that will be made available to companies that express interest in the development project for Lee. Lee has decided to go through a 2-phase tendering process involving an RFI (Request for Information) then a closed RFT (Request for Tender). You are asked to support this through the following tasks.
- Draft the RFI (Request for Information) which will be advertised widely. Search for examples.
- Review the case study and prepare an event table for the information system to support the business processes as described.
- Prepare a Use Case intermediate description for the use case ‘Process the payment claim’, as documented in the event table solution and the use case diagram solution.
- Draw the design class diagramfor the Patientand FamilyDoctorclasses. These two classes should be part of the Domain model class diagram solution for the previous question.
- Each of these design class diagrams are expected to have a complete attributes list and a comprehensive methods list which supports the specified functionality as described in the case study.
- Solutions must follow the methodology as outlined within the Satzinger et al textbook.
- Draft a summary of the functional specifications which will be included in the RFT (approximately 1 page).
- Presume you have completed the processes of RFI, RFT, evaluation of tenders and selection of a solution. Write the executive summary of the Report to Lee where you explain the processes undertaken and recommend a preferred supplier(approximately 1 page).
IT Solution for on Claim Generation System
Task 1: Request for Information (RFI)
- Claim Generation System
- Request for Information
- Purpose of the RFI
- RFI Submission content
- Schedule for the RFI
- Registration process
Read more in the complete solution PDF document at the end of this page.
Task 2: Event Table for the solution
Task 3: Use-Case intermediate description for the ‘Process the payment Claim’
For processing the claim, the below set of primary and exception flow occurs(Bramble, 2003).
1. The software checks if the patient qualifies for a Telehealth treatment
2. The software searches for registered specialists who are online.
3. Doctor and specialist both are sent an invitation to connect on Telehealth
4. The software sets up the Telehealth session and consultation starts.
5. The doctor takes notes on the further treatment process.
6. Either of the doctor or the specialist chose to end the consultation.
7. The notes are automatically updated on the PMS.
8. The system automatically creates a claim form for the consultation.
9. The software automatically dispatches the claim form generated, to Medigood so that both the doctor and the specialist receive their payments.
Task 4: Design Class diagrams for Patient and Family-Doctor classes
The class “Patient” contains two sub-classes, the Telehealth-eligible and Telehealth-non-eligible.
Each of the class have been listed along with the necessary attributes and the functions contained in them(S. Bennett, 2005).
Read more in the complete solution PDF document at the end of this page.
Task 5: Functional specifications for the RFT
1. The software is intended to be used by two kinds of users. The doctors and the specialists.
2. The software should smoothen up the process of Telehealth consultation by finding out if the patient is eligible for a Telehealth treatment and then automatically searching for specialists if the result is true.
Task 6: Executive Summary and vendor selection
We started the process of vendor selection with a notice to submit a request for Information. In our invitation we explained all our requirements to the vendors. We explained about the criteria based upon which we would be evaluating the submissions. We also asked them to relate any prior experiences that they might have had in this field. We asked the vendors to also let us know the approach that they would be having for the pricing, whether it would be a pay-per-user system or a subscription based system. Apart from stating their strengths, we also asked the vendors to put in the weaknesses of their solution as well. A good response was achieved and we received a large number of entries.
After all the submissions were made, we began with the process of reviewing them. While reviewing the solutions we laid stress on the clarity and simplicity of it. Those solutions requiring large amount of changes in the existing set-up were all ignored. Others which seemed too costly to operate were also sidelined. We focused on a cost effective solution with a good degree of robustness.
After shortlisting the vendors with a good RFI, we invited them to register with us. This registration was made mandatory. It was clearly specified earlier that only the registered vendors would be allowed to give a demo of their product.
We had around ten demo sessions. We evaluated the solutions basing upon how accurate they were in searching for online specialists. How well they were tracking the changes in the PMS? How quick they were establishing the connection between the doctor and the specialist for conducting the Telehealth session? How accurate they were in identifying whether the patient qualified for a Telehealth service? How accurately was the claim generated? Based upon the above factors we shortlisted three solutions to carry over to the next stage.
In this stage we did a compete testing of the shortlisted applications. All the test cases covering the complete functionalities were prepared. Each of the solution was subject to a thorough round of testing to find out how will it is designed to handles errors and exceptions and if the error messages were user-friendly enough for the doctors and specialist to understand and remediate or restart. Based upon the above criteria we selected the best solution out of the three shortlisted ones. The vendor that we selected is Vendor ‘A’ who seems to have just the solution that we need and thus I recommend him for the final contract.