Key Insights and Decisions

The two hypotheses we intended to examine this week were:

Is there enough inefficiency in the EHR hierarchy to warrant further discovery?
After further discovery with Medical Professionals, it appears that this is an even bigger issue than we had originally anticipated. The worst patient scenario for a clinic, the referring clinic not having the same EMR system and not sending along patient records, happens roughly 30 times a day out of 120 patients for a mid-size specialty clinic, or 25% of the time. Each occurance of this takes roughly 20 minutes, meaning this specific instance of copying faxed information over costs a clinic more than 5 hours per day transferring patient records. These are nurses making about $30 an hour. Amounting to over $39,000 a year, for each mid-sized clinic. Extrapolating across the entire country to 25,750 health clinics fitting the description of in and outpatient care, we find the total savings at roughly $1.01 Billion being spent on this specific issue. This is only taking into account 25% of the data transfering they do, meaning we could potentially find more savings within each clinic.

Do we have enough talent in house to manufacture the fundamental technology?
While we are still working on consulting more experts, the conversation with Dr. Yiran Chen has given us the impression it is certainly possible for us to build this technology off of publicly developed programs in Database conversion and Optical Character Recognition.
This project, while as an overall design may be intensive, has very few new components. Simply, we will leverage many existing products to create a more encompassing tool than what currently exists. This means that internally, with the help of some Code Monkeys, we will be able to create a functioning version of this product. More robust and encompassing versions will require at least Junior Developers to complete. So, while we continue consulting Software Experts, we will continue to assess our teams readiness to complete this project.

1. Next Couple Weeks:
   Continue to address two major areas of concern:
   What technology will be required and how much development will it take. While we are not planning to build a functioning version of this for a few months, we want to continue understanding the framework of what we are designing.
   What specific tasks could we tackle first that would lead to a small stream of revenue as proof our idea has value.
   We will also wireframe a sample UI, one that we would potentially use for initial customer discovery as we continue talking to prospective beneficiaries.

Interviews

Dr. Julie Anderson
Started her own private Primary Care facility. Primary is the major source of referrals, she is much less dependent on other doctors patient notes. The majority of her patients she ends up referring to a specialist, meaning they need her notes.
She is apart of a Conglomerate healthcare system called CentraCare. She uses EPIC as she is apart of this system, and that allows her to very easily send patient notes to other physicians within CentraCare. However she ends up referring about 25-35% of her patients outside of CentraCare meaning she has to share patient notes with other systems.
When this happens she has a nurse scan and fax over her notes to that clinic. However, there are times she either doesn’t know what information is relevant or forgets so she will recieve calls asking for the records or a more detailed version of them.
For her, this is not a huge pain point as she is able to keep a lot of the referrals internal and all her notes are viewable to the internal doctors. But before she wasn’t involved with this large group, this was a frustrating part of her job.
Worried that the large EHR businesses will not want us getting involved.
Next area is where she suggests us looking is Imaging. Will give a contact.

Dr Chris Roth
Radiologist at Duke Hospital and Vice Chair of Information Technology and Clinical Informatics Director of Imaging Informatics Strategy, so deals with EPIC and related systems frequently
EPIC allows for information to easily be passed between clinics/hospitals all on EPIC, but this is not all of the patient information- only information mandated by the ACA and stored in subsystem called EPIC Care Everywhere
Automation may not be the way to go because you don’t want to share all patient information between hospitals
Getting information from clinics/hospitals that don’t use EPIC can be a pain- have to call specific department, ask for files to be transferred and those files often end up getting faxed or given to the patient themselves to deal with
Imaging is a different process, and EPIC can’t transfer imaging. Duke and UNC have a shared system that allows for them to transfer imaging from one place to the other but there is no standard there
HIPAA likely prevents automation of non-EPIC information- have to ask patient permission in order to authorize that transfer and so automation would be difficult

Dr. Billy Willis
CTO of Duke University Health Care System
Duke Hospital along with 70/80% of hospitals use EPIC- transferring information is easy between places that both use EPIC
Additionally all Duke Health Clinics run on the same EMR system as Duke Hospital so despite not using EPIC there aren’t problems transferring data between the two places
Clinics that aren’t part of Duke Health have no standard way of transferring specific patient information. There are programs that can be used but there is no standard
Harmonizing patient information is big in the health care world right now, since more companies are moving to a value service from a fee-for-service so we might run into larger companies trying to block us

Yiran Chen
Ph.D. in Computer Science/ Electrical Engineering. Talked with me for a half hour about this project and what he knows about the spaces we are getting into.
Brother has an RPA firm and knows a bit about what he does, says his firm goes into businesses that think they have a computing problem and then figures out what the problem is, then has a team that builds the software to fix it.
Says it is profitable and that there is plenty of room from what he’s seen. There is high demand, and that is just from people who know that they have a problem that can be fixed. He thinks the majority of people don’t even know that software can solve some of their problems so RPA firms generally aren’t going in to talk to random clients.
The idea of a software tool for creating backend infrastructure is something he hadn’t thought much about, but pointed me to a professor who specialize in DB design.
He wants us to look into OCR by Google and Facebook as potentially free ways of building a Machine Learning app to read in PDFs

Ben Spain
Siloed systems
Have to go all the way to the top to get things to start working
Even generals can’t do much
Contracting for software
Once contract is approved, there’s little recourse
Similar TCPT/MOL situation in USAF
An attempt to put everything on one system back in the 90’s is terrible
Why isn’t there a mandate for products to be integrated?
People writing contracts are not experts
Turnover
Potential legal restrictions
RPA
Loves the idea, happens a lot
Definitely sees a lot of application from the USAF side
Ex: flight scheduling, still doing on paper and then pasted into a computer algorithm
Ex: training, lots of individual training programs as a pilot; each flight has a grade sheet compiled into a grade book; lots of regulation on how those books have to be kept/reviewed; have the review be done automatically + prevent wrong info
Ex: post-flight reports; can technically put in he flew 28 hours and system wouldn’t stop him
Even thought about making and selling his own software
Genesis
VA doesn’t talk to USAF medical records
Print + bring records physically
Ex: saw Dr. twice in Kuwait, those visits recorded in USAF med record

Patrick Nevins
RPA Projects
Helps lead the business in public sector practice
Used a lot in back office (HR, financial management)
Civilian DoD, Health, Justice, etc.
In-House MVP
Find a vendor (can get us names, ???)
Software companies that own the software packages that run RPA
Automation Anywhere, BluePrism, UiPath, CoFax
UI interface/backend looks different for each
Lots of them have free user trial licenses, see how they structure it
Building from ground up
Feasible with talent set (dispatcher problem), just keep it simple
Biggest hurdle would be mimicking client’s environment
Gaining access to systems/information
Funding issue will always be there
What contracts does BG have?
Could have contract that hasn’t reached funding cap
Could be given $ to develop PoC as a part of that larger contract
Would want to find a way to add onto
Deloitte usually tests MVP’s outside of client systems, but still need the correct information to test
Genesis
Look at the VA to see their EMR

Adam Beauregard
Former Aviation Operations officer in US Navy.
Followed up with Adam to go deeper into a couple of off-hand comments he made when I first spoke to him two months ago that now have more relevance.
I asked him about the reason for the white-board containing aircraft status and upcoming missions that he referenced in our original conversation. Initially, he chalked it up to established procedure. Upon probing deeper, that procedure is in response to the fact that the aircraft maintenance system is not connected to the mission planning system. This results in a weekly meeting pattern and the resultant white-board for resourcing missions. The roots and effects are highly analogous to the Marine dispatchers.
Adam also cited that the Navy has 4 personnel-related systems – awards, leave, physical fitness, and overarching central personnel system – that do not communicate well. For example, a person receives an award – it is immediately in the award system but usually takes a couple months to be populated into the central personnel system.

Dale Swink
Director of II MEF MMCC
Dale took the results of our work on TCPT and contacted 10 of his colleagues on our behalf with the goal of generating interest in advancing the TCPT implementation as well as the identifying other potential use cases our solution might address. The roles contacted include – the GCSS program manager, the TCPT program manager, as well as personnel whose roles involve working with other applications Dale is aware of that need a connection to TCPT.
Dale identified the following applications that require manual rekeying or data hand-offs
Cargo Movement Operations System (CMOS), POWERTRACK, MMCC Access database, SSDM, GOPAX, SABERS, Fleet Anywhere, Airforce DD1149 website, ITV.

Douglas Kaminsky
Engineering Lead at MongoDB, previously worked tech at Bank of America and Broadridge
Dual-use
Finance
Lots of information needs to be readily available across platforms to create a “public marketplace” of info within firms
Information is currently difficult to coordinate amongst different teams, causes inconsistency and too much redundancy

Mr. Allen Byrne & Mr. Torres
Byrne
Deputy SPO of Army Support Battalion, 1st Special Warfare Training Group
GCSS-A expert who is intimately familiar with the processes and uses of the system
Business applications/management/reports
Can see anything on GCSS w/ proper permissions
Torres
Supply and maintenance supervisor, very familiar w/ GCSS
Army transitioned to GCSS 3 years ago, seem to have a much more positive experience than GCSS-MC
Phased out all legacy systems (equivalent to TCPT, MCTMS, etc) and now only use GCSS for most things
Since making the transition, supply and maintenance takes 5 steps instead of 3 (for example)
Training is required for all people, and necessary to operate system, but there are help buttons on every GCSS page that walk you through everything step by step (first time hearing of this)
Legacy systems DO talk to GCSS-A, but there are issues with it
Whoever did what we are trying to do messed up the process, data is communicated between systems incorrectly
Both emphasized correct data validation a LOT
Asked if we wanted to visit Fort Bragg and do MVP testing