1. An Alternative Plan Virgil Bierschwale

2. Redesign Effort? In the “Outline of Redesign Effort” proposal that I received from Scott Henson, we find a massive development proposal that includes: – Transition Planning – Requirements Gathering – Requirements Analysis – Design, Data Mapping and Workflow – Development Setup – Development – Testing – Deployment to Production – Maintenance/Sustainment All of this will take approximately 3 to 6 months and it is a well thought out plan

3. A development perspective I’m sure that all parties that will be part of this solution such as the business stakeholders, the developers, the sustainers have been consulted as part of our due diligence? After all, the business stakeholders are looking to us for guidance and solutions to their problems and I’m sure that our: – Developers can offer alternative views – Sustainment team can offer alternative perspectives

4. Problem areas The problems that I have heard from the Navy are that: – They are not sure they are receiving all of the data – That during an audit last year they were unable to answer the auditors questions as to where the data ultimately ends up at The problems that I have heard from TCIG are that: – We want to port the whole thing to Sharepoint

5. Problem with where the data goes to. So lets address these issues first: – To solve the problems of our team and our business stakeholders not knowing where the data is ending up at, lets create a ICD to History Table cross reference table similar to the acronym listing we have, except in an excel format that all interested parties can utilize to show exactly where the data comes from and goes to. – Lets do this because to wholesale rename tables to better confirm to the ICD naming conventions will risk adding data loss problems during the process and also require changing of all associated programs, which also will introduce the problem of more errors to the process I submit this alternative because I believe it is better to solve the problem rather than introduce new problems without having solved the original problem.

6. Not sure they are receiving all of the data. There currently are two development efforts under way that will not solve the problem, but they will offer an early warning type solution so that the Navy can dig further to fix the problem. – TraCR – TAMA On the next slide I will offer an alternative that will allow the Navy to immediately validate all data files that have been received in a real time solution.

7. An alternative to TraCR and TAMA Every time a file is added to the following tables, a record is written to the files_combined table that shows the amount of records that were processed and the amount of records that failed the process – Load_SIDR – Load_SADR – Load_Patient – Load_WWR – Load_DRG (assuming on this one because it does not exist on the development box)

8. An alternative to TraCR and TAMA (continued) Now we develop a web based front end within sharepoint that queries the files_combined table and offers the business stakeholder an option of choosing by day, or by file type. – To start with, lets give them a hyperlinked list of: The last 7 days, and A list of all distinct filetypes – On this list, next to the hyperlink, lets show them the totals for that hyperlink showing: Total Number of Records Processed Total Number of Records Accepted Total Number of Records that failed

9. An Alternative to TraCR and TAMA (continued) The operator can now click on a date, or a file type and this will take them to: – To a list of all files processed on that date if they selected a date, again showing records that were processed, accepted and failed – To a list of all dates process by that file type if they selected a file type, again showing records that were processed, accepted and failed In a nutshell, we continue this drill down process until we ultimately reach a “diff” program that will show the business stakeholder the raw file before being processed and the raw file after it was processed so that they can see for themselves what actually happened to that file.

10. Sharepoint Integration Each of the applications displays data from various databases and tables and they work at the present, even though all of us believe that there is a better solution out there So instead of risking breaking that which is not broken, lets break it down into a more manageable approach and we do that for each application in this manner: – Step 1 – The development team will take 1 week to reverse engineer the display portion of the code, meaning the asp, asp.net or whatever code and not the portion of how the data gets populated into SQL Server – Step 2 – The development team will take 4 weeks for each application (finish one before moving to the next one) and create the sharepoint front end from scratch in sharepoint pointing to the tables that are being populated via the backend – Step 3 – The Testing team will take 1 week to verify the correct operation of the application

11. Sharepoint Integration (continued) After all applications have been ported so that their front end is running live totally within sharepoint, we now repeat the process except this time we focus on the data portion of how the tables are populated, operating under the old saying of “Don’t fix that which is not broken” so that we will not introduce any new problems into the environment

12. Questions that I have not heard asked! I’m hearing redundancy, cubes and all kind of expensive and potentially overkill solutions, but I have not heard anybody discuss: – How many users per day (as recorded) are actually using each of these applications so that we can do our due diligence and recommend the appropriate solution to the usage level

13. To summarize Lets solve existing problems first before introducing new problems into the environment Lets gain an intimate knowledge about the system so that we can share this knowledge with our client. Then lets work closely with our client so that we can be proactive and take them to the next level in solving their business problems.