Disclosure+of+Services

=//Disclosure of Services //=

Problem Statement
Our team decided to form a proposed method to aid in cutting costs for patients and streamline their wait time during health care visits with doctors. Currently doctors have been able to bill insurance companies higher prices on behalf of patients because they [patients] have no idea of what’s being charged. Patients are unlikely to know that their office visit may entail additional charges for procedures done by their doctor without their knowledge. At times when patients go in to see a doctor they are in so much agony that they do not take the time to ask what procedures will be performed.

These issues can be fixed with the Patient/Doctor Access Application or PDA app. The PDA app will be ethically practical because doctors will no longer be able to overcharge patients. Patients will be able to see the prices of each procedure and consent to have the procedure done or not, so they will be more knowledgeable of the procedures they are undergoing.

The PDA app will also help with office wait time, as it will reduce the amount of time doctors need to spend imputing data into a terminal for an EMR. The PDA app is a tool for both patients and doctors to use. It will help patients keep health-care costs down and allow doctors to get their patients in and out of their offices in a timely manner. It also helps in strengthening trust relations between the two because both are aware of what’s going on and no one is left in the dark.

Evidence to support the problem
It was not until one of our team members brought to our attention that their father was unknowingly charged an excessive amount  to have their ears cleaned. It was from that situation, where we figured out that we need to find a solution in disclosing medical services. Health  insurance fraud is widespread with some health care providers over charging, charging for services that are not necessary, or even billing insurance companies for services they didn't provide. Patients should not be charged for services they did not approve of. We think that having the list of services in front of them before they allow services to be rendered will help patients keep track of what they agree to pay for. This will help to prevent health insurance fraud and keep costs to a minimum, however, any services that the doctor recommends is up to the patient to pay for.

Potential Solutions
>>
 * Website Platform
 * The creation of a website will be the easiest way for a patient/user to be able to schedule appointments with their health-care provider.When making an appointment the patient states the reason for visit which makes it easier to determine what kind of examination doctor will initially perform. There will be an accept/decline button for them to click on before they come to the office which will be set-up for current patients. For example if a patient logs onto the website in reference to flu symptoms a price list for flu examinations can be sent to their phone or email and they can either accept or decline.There will also be a calendar with available appointment times for specific doctors and nurse practitioners for patients to choose from. Booking selections will be immediate so that double bookings don’t occur.
 * Mobile Application
 * On the mobile app portion a doctor can display a single charge for a visit, and then show the patient what other charges there will be in addition.Examinations can be broken down into categories based on the reason for the examination, for example yearly checkup verses a visit because of cold/flu symptoms. During examinations if a doctor should decide to check something else that wasn’t provided before beginning he/she can access another price check list to inform the patient of the additional cost before proceeding with an ear cleaning for example. A price check list for treatments and other services provided by the doctor such as heart rate monitoring or allergy skin testing will be accessible. Also there can be a separate cost for an initial exam verses a more extensive exam. For example there is an initial eye exam in which the doctor just looks at your eye with a light, but there is a more extensive exam that entails using eye charts and other optical tools that may cost more.


 * <span style="font-family: Georgia,serif; font-size: 120%;">Desktop Application
 * <span style="font-family: Georgia,serif; font-size: 120%;">The desktop app will be the same thing as the mobile app, but on a laptop or COW instead. There will also be some additional services offered to health-care providers through the PDA app. Doctors will be able to access patient files/records via the desktop as there is more storage space available.There will also be a medical information search engine as well. Through the search engine there will be a glossary of definitions for treatments, conditions, and human anatomy which will help with providing an explanation and understanding for patients.

<span style="font-family: Georgia,serif; font-size: 150%;">Research on existing/alternate solutions tried by others
<span style="font-family: Georgia,serif; font-size: 16px;">Thus far there have been no other applications developed such as ours to provide patients with on the spot billing information from their health care providers. Medicare has for some time sent billing statements called Medicare Summary Notices to seniors to help curb fraud, but those statements were sent after patients had visited with their health care provider. Recently Medicare has come up with a new billing statement format for seniors to make it easier for them to read. These newly formatted statements will be provided online via the Medicare website and the paper statements, which are mailed to seniors every 3 months, will be phased out in early 2013. Currently the billing statements can have up to 12 pages which contain medical terminology that most seniors don't understand. Medicare now claims that the revisions made to the billing statements online are easier for seniors to understand. These statements are being sent so that seniors can view and possibly aid Medicare officials in preventing and possibly catching fraudulent activity in health care.

<span style="font-family: Georgia,serif; font-size: 150%;">Feasibility of each solution
>>
 * <span style="font-family: Georgia,serif; font-size: 120%;">Website Platform
 * <span style="font-family: Georgia,serif; font-size: 16px;">A website would be by far the easiest solution to implement, as web developers are easier to find and more affordable than mobile developers. Websites also tend to add more capabilities than mobile apps can offer. The ability for patients to input information before they arrived in the office would be a convenient one, but this would also mean the system relied on patient-input data, which is not a very reliable technique. There are downsides to using a website for this purpose. The primary downside is the inconvenience compared to a mobile app. A laptop would usually be required to access a website, and if users choose to access it through a mobile device instead, it would have to rely on download speeds much more heavily than a mobile app would.
 * <span style="font-family: Georgia,serif; font-size: 120%;">Mobile Platform
 * <span style="font-family: Georgia,serif; font-size: 120%;">The Mobile app is by far the most portable and user friendly solution on this list. The cost of a mobile developer, while slightly higher than that of a web developer is lower than that of a desktop application programmer. This app also has the benefit of not requiring a user to bring a laptop or a Computer on Wheels with them whenever they see a patient. The downside to this type of program is that it is reliant on an internet connection. This problem can be overcome by caching the data in temporary storage until the connection is restored, however storage space tends to be fairly limited on mobile devices.
 * <span style="font-family: Georgia,serif; font-size: 120%;">Desktop Platform
 * <span style="font-family: Georgia,serif; font-size: 120%;">A Desktop Application would be by far the most difficult and expensive to develop, however it would offer the best stability and ability to operate in an environment without an internet connection. It could achieve this stability by storing data locally while it did not have a connection, and then syncing it with a server when it reconnected. This solution would also have the same problem as the website in that it would require the use of either a laptop, PC, or Computer-On-Wheels to use with the patient in the office.

<span style="font-family: Georgia,serif; font-size: 150%;">The Chosen Approach
<span style="font-family: Georgia,serif; font-size: 120%;">Even though the use of a website to display the information would be the simplest process and a desktop would provide more storage; a mobile app will be easily useable on a ipad or tablet. The mobile app will contain services offered by the provider and allow the patient to see services before receiving them. This will allow them to save money and avoid being overcharged by health-care providers and being charged for services not rendered. Information provided will be viewable from any mobile device so that a patient would be able to accept or decline services. Devices will be connected on the offices network so as the patient chooses each service they want will be sent through the network and straight to the doctors computer. The purpose of the PDA app is to stop doctors from carrying out random procedures that patients did not consent to through a user friendly mobile app. Overall this app would decrease the amount of money spent on healthcare and allow for more ethical practices.

<span style="font-family: Georgia,serif; font-size: 150%;">Timeline for Completion

 * **Task** || **Date of Completion** ||
 * Planning and proposal || October 5th, 2012 ||
 * Application Draft Final || October 19th, 2012 ||
 * Design and Infrastructure || October 24th - November 7th 2012 (Varies) ||
 * Prototype Final || November 9th, 2012 ||
 * Software Testing and Debugging || November 11th - November 17th 2012 (Varies) ||
 * Project Completion || November 26th, 2012 ||
 * Project Presentation || November 27th - December 6th 2012 (Varies) ||

<span style="font-family: Georgia,serif; font-size: 150%;">Team Workload and Roles
<span style="font-family: Georgia,serif; font-size: 120%;">John Seigal: Application Designer/ Team Leader <span style="font-family: Georgia,serif; font-size: 120%;">Felecia Purefoy: Researcher / Auditor <span style="font-family: Georgia,serif; font-size: 120%;">Sohini Lala: Information Research and Developer <span style="font-family: Georgia,serif; font-size: 120%;">David Battle: <span style="font-family: Georgia,serif; font-size: 16px;"> Design & Software Implementation <span style="font-family: Georgia,serif; font-size: 120%;">Dulny Salazar: Researcher/ Auditor

<span style="font-family: Georgia,serif; font-size: 150%;">Meeting Minutes
<span style="font-family: Georgia,serif; font-size: 120%;">September 20th, 2012 //Discussed project plans and roles. Went over outline and guidelines.// <span style="font-family: Georgia,serif; font-size: 120%;">September 25th, 2012 //Went over when we are free and exchanged emails and times we are available//. <span style="font-family: Georgia,serif; font-size: 120%;">October 10th, 2012 //Went over application draft// <span style="font-family: Georgia,serif; font-size: 120%;">November 5th, 2012 //Tested Prototype// <span style="font-family: Georgia,serif; font-size: 120%;">November 15th, 2012 //Formed patient waiver and disclosure message.//

<span style="font-family: Georgia,serif; font-size: 150%;">Solution Prototypes
<span style="background-color: white; font-family: Georgia,serif; font-size: 12pt;">Our Group is working on an app that will allow physicians to notify their patients of what procedures and charges they will be paying for, along with allowing them an option to opt-out of any particular procedure. Overall we've made great progress. At the beginning of the semester, none of us had any Android development abilities. Now we have a functioning app. While not all of the functionality of the app is completed at the moment, we will be able to have the basic functionality described completed by the end of the semester. The main issue we're facing is that our developers are having to learn Android development as we go throughout the semester. However, we do have access to a number of skilled developers who have offered to help us if we get stuck at any point.


 * [[image:1.jpg width="202" height="317" align="left"]] || <span style="font-family: Georgia,serif; font-size: 120%;">__**Page 1**__

<span style="font-family: Georgia,serif; font-size: 120%;">Patient reads over the Patient Waiver form saying they agree to pay for the time they will spend with the doctor. During this time they will explain their symptoms to the doctor and the doctor will provide feedback of what they think could be wrong. ||
 * [[image:2.jpg width="204" height="335" align="left"]] || <span style="font-family: Georgia,serif; font-size: 120%;">__**Page 2**__

<span style="font-family: Georgia,serif; font-size: 120%;">This page is where a doctor can make a selection of the different procedures that he/she has to offer a patient. ||
 * [[image:3.JPG width="204" height="339" align="left"]] || ​**__<span style="font-family: Georgia,serif; font-size: 12pt;">Page 3 __**

<span style="font-family: Georgia,serif; font-size: 12pt;">After the doctor has made the selection for the procedures he/she would like to perform, here is where the patient, before proceeding, can review the prices of the procedures. The patient will select what they agree to pay for and the doctor visit will carry on from there. ||
 * [[image:4.jpg width="202" height="336" align="left"]] || <span style="font-family: Georgia,serif; font-size: 120%;">__**Page 4**__

<span style="font-family: Georgia,serif; font-size: 120%;">This page demonstrates the procedures the patient agreed to and the total price of everything they’ve selected. The patient accepts the total charges and the doctor will begin with tn 2.he selected procedures. ||

<span style="font-family: Georgia,serif; font-size: 150%;">Final Solution
<span style="background-color: white; font-family: Georgia,serif; font-size: 12pt;">At the moment, this app Works on all Android distributions between 2.1 and 4.0. There is still quite a long way for it to go before it would be marketable to any actual businesses. However, as none of our group had any sort of Android development experience going into this semester, to have a functioning application is more than we anticipated being able to accomplish at the very beginning.

<span style="font-family: Georgia,serif; font-size: 12pt;">The Application as it stands is comprised of 4 pages which pass data from one to another.
 * [[image:1.PNG width="293" height="474"]] || **__<span style="font-family: Georgia,serif; font-size: 12pt;">Page 1 __**

<span style="font-family: Georgia,serif; font-size: 12pt;"> This page is the same as the page on the prototype but with more styling to make it readable. There is more text further down, the waiver is scrollable. There are some placeholder values in the document for now, holding place of the name of the facility this app is being used for. This waiver gives the doctor basic permissions to treat, as well as accepting the charges for a short examination to allow the physician to decide what other charges will be necessary. ||
 * [[image:2.PNG width="288" height="475"]] || **__<span style="font-family: Georgia,serif; font-size: 12pt;">Page 2 __**

<span style="font-family: Georgia,serif; font-size: 12pt;"> This Page shows all of the procedures that a physician using this application offers. <span style="font-family: Georgia,serif; font-size: 12pt;"> For the moment this is limited to 10 procedures for proof of concept, though it could be expanded to encompass procedures described by CPT codes. ||
 * [[image:3.PNG width="294" height="472"]] || **__<span style="font-family: Georgia,serif; font-size: 12pt;">Page 3 __**

<span style="font-family: Georgia,serif; font-size: 12pt;"> This Page shows only the procedures which the physician recommended after the first examination. It also shows the price for each procedure, so that the patient will be able to decide which procedures they will choose to allow. ||
 * [[image:4.PNG width="291" height="484"]] || **__<span style="font-family: Georgia,serif; font-size: 12pt;">Page 4 __**

<span style="font-family: Georgia,serif; font-size: 12pt;"> This Page shows the final list of charges approved by both the physician and patient. When the patient accepts, the data would be transferred to the main billing system used by whichever practice was using this app. ||

<span style="font-family: Georgia,serif; font-size: 150%;">Next Steps
<span style="background-color: white; font-family: Georgia,serif; font-size: 12pt;">As this application was created only to demonstrate the basic functionality of this idea, it still needs several improvements that our development team did not have time to accomplish.
 * 1) <span style="font-family: Georgia,serif; font-size: 12pt;">A Way to sort through different types of procedures.
 * 2) <span style="font-family: Georgia,serif; font-size: 12pt;">Integration of CPT codes as the main ID for each procedure.
 * 3) <span style="font-family: Georgia,serif; font-size: 12pt;">Integration with a billing system
 * 4) <span style="font-family: Georgia,serif; font-size: 12pt;">Movement of procedures from a static text file to a relational database

<span style="background-color: white; font-family: Georgia,serif; font-size: 12pt;">All of these could be accomplished with integration into an EMR system. With more time the end goal would have been integration with Open EMR, open source EMR software available online.

<span style="font-family: Georgia,serif; font-size: 150%;">Citations
[|Uses and Disclosures for Treatment, Payment, and Health Care Operations] [|Disclosure of Sensitive Health-Risk Behaviors] [|Disclosure Services] [|MRO Software and Services] [|Patient Confidentiality]


 * Name || Phone || Email ||
 * John Seigel || 305-528-6558 || jts09f@my.fsu.edu ||
 * Felecia Purefoy || 850 264 6098 || flp3301@my.fsu.edu ||
 * Dulny Salazar || 786-366-9978 || ds11u@my.fsu.edu ||
 * Sohini Lala || 239-989-4414 || srl10@my.fsu.edu ||
 * David Battle || 8503450685 || ddb08@fsu.edu ||

After 8:00pm || 1:30-1:30pm After 4:30pm || After 5:00pm || 11:30-1:30pm After 4:30pm || 10:30-12:00pm After 8:00pm || All Day || All Day ||
 * Name || Monday || Tuesday || Wednesday || Thursday || Friday || Saturday || Sunday ||
 * John Seigel || 1:10-2:30pm
 * Felecia Purefoy || After 5:00pm || After 5:00pm || After 5:00pm || After 5:00pm || All Day || All Day || All Day ||
 * Dulny Salazar || After 8:00pm || After 8 pm || Between 2:30-5:00 pm || 1:00- 3:00 or after 8 || After 2:15 || Varies || Varies ||
 * Sohini Lala || 8:00AM- 11:00AM || 8:00AM-1:00PM || 8:00AM-11:00AM || 8:00AM-1:00PM || 8:00AM-1:00PM || All Day || All Day ||
 * David Battle ||  ||   ||   ||   ||   ||   ||   ||