Home » Uncategorized » Week 12: Looking Ahead

Week 12: Looking Ahead

Key Insights and Decisions


The hypotheses we intended to examine this week were:


  1. Can we leverage existing technologies as well as our teams technical capabilities to design, develop and deploy Spear.
    1. After discussions with a few professors in the areas we will need help in as well as research into the field. It appears there are many interesting solutions to this problem out there that we can build our product off of. For example, Tamr Inc. is a database connecting company that is developing technology to automatically detect database types. Whatever information about the technology that is publicly available we will implement into our system. Designs and initial features will also be based on existing tools such as the Azure data lake tool.
  2. How can we develop this product in a way that would allow us to start making money and prove our concept while still making progress in final product development?
    1. One method of doing this we imagined, was individually build out solutions for customers on a case by case basis. This would give us experience with many different databases, and when we begin seeing repeating database types, we can implement old solutions. The end goal being creating a swiss army knife of database translations that our product can tap into to detect and translate between databases.

Next Couple Weeks:

  1. Refining our presentation and all of its components.
    1. Building out a UI wireframe for the pitch
    2. First four minutes
    3. Structure of second six minutes
  2. Work with Niebel on deploying in the Marine Corps.
    1. We got a response Monday morning but haven’t heard back since then.
  3. Continue to develop the scope of what we are trying to build.
    1. Talk to professors.




Dr. Carlson

  • OCR – The publicly available Optical Character Recognition technology is roughly 99.99% accurate in transferring records. If we were to implement it in Medicine, we would need to also use Tesseract, Google’s Computer Vision tool, to validate our data.
  • TAMR – Data Integration company that is doing along the lines of what we are hoping to do. Their approach is much more about large scale data siloed integration through a large tool called Unify. They are working to develop a database translation tool that could be useful to us.
  • Azure – Data management tool internal to Databases. A drag and drop application to make writing SQL scripts easier but very limited. Could be a good place to look for inspiration for how to write the code for the tool.
  • Record Linkage – The buzzword for what our tool would be doing. Connecting entities from different Databases that are unrelated as far as the computer is concerned.

Dr. Cory Duncan

  • Emergency Room director in large emergency room in Atlanta. Roughly 175,000 patients move through the three ERs he oversees. His system is on Epic and have access to the patient records of patients who have been to other Epic clinics. He estimates that only about 5% of all patients in the country move through Epic systems.
  • In his specific clinic, about 33% of patients come in and their records are not available. In an emergency room this can be a matter of life and death as they may have certain conditions or allergies that could prove fatal if the surgeons don’t know about them. These records can take anywhere from 30 minutes to a full day to receive depending on how well staffed the clinic with the records is. His guess is four hours per patient.
  • There is an added cost of excess testing and imaging. If a patient comes in without records but says he has a broken arm, they either need to wait for the imaging center to fax it over or, more often, just image the patient again which is expensive.
  • In the private Emergency Rooms he owns in Texas, he estimates every patient comes in and needs records from somewhere else. Which is how he sees the majority of the country working.

Vicky Tamblyn and Kayla Rediner

  • Nurses at Dvorak Eye Clinic in Sauk Rapids, MN. Laughed when I asked if the problem of not having instant access to EMR was relatable for them.
  • They are not connected to Epic, every new patient requires them to get records from a different clinic. Process below:
    • First step is getting patient consent, which involves them mailing out a form, the patient signing it, then sending it back.
    • Next step is getting that signed form to the appropriate resource who has their medical record (past eye clinic, general family practice, etc.)
    • Next step is waiting for that clinic to process their request then fax over the patient records.
    • Next step is entering the information into their system.
  • This process takes roughly an hour of a nurses time combined but that isn’t their major pain point. The biggest issue is accurate information.
  • If a patient is diabetic, but doesn’t tell the eye clinic, they don’t request that information. So when the patient’s general doctor asks for the results of a diabetic eye test, they don’t have the results because they didn’t perform the appropriate diabetic tests.
  • Another example is if the patient is allergic to something that isn’t included in the report they get, and the medication they give them makes their condition worse.

Dr. Chakrabarty

  • Chairman of the ECE Department. Immediately understood the challenges we would run into with this product.
  • The most important aspect of what we are trying to achieve is the patentability of what we could do. His expertise does not involve any of what we are going into, but from a business and technology standpoint, he thinks the best scenario for us is to develop some technology that is patentable as soon as we can. With the idea being it gives us the advantage in the industry we need for funding and would allow us to distribute our technology to anyone without worrying about IP theft.
  • Thinks if we are able to make this useful for the average person he sees many applications of the technology, from building online stores from scratch with a few clicks to creating a version of IFTTT or Zapier that is customizable to non-programmers. The idea being if someone thinks, wow it’d be cool if this did that, it can with a few drags and clicks.
  • Wants me to do this as an Independent Study next semester. Putting me in touch with professors who could help more but also some who may want to sponsor my independent study.

Dr. Board

  • CIO of Duke University. Had the most coherent understanding of what we were trying to do and the challenges we would face. BAA for working with hospitals is the only way to do that stuff. We would be liable for everything the hospital is unless we prove we took industry standard precautions.
  • Three approaches to tool:
    • One is building out capabilities with as many systems as possible, using them as templates next time we encounter it. Problem is we would have to continually maintain our interfaces with the APIs to make sure it works. (Worst Option)
    • One is generating an “API Compiler,” definitely the most interesting option. Would be difficult, but if it works we would have a billion customers in way more areas than this. (Most Difficult Technically)
    • One is connecting directly to a database and reading from that. Issue is proprietary. What stuff is allowed to go through our system? That is the function of an API but if we’re bypassing an API we need to figure out how to only grant access to the fields the information provider wants us to. (Most Difficult Politically)

Pam Welle

  • Nurse at Minnesota Clinic. One of the nurses who actually goes through and gets medical information.
  • Laid out how here clinic does patient reports.
    • Patient makes an appointment, they request from the referring clinic for a fax of a subset of patient records they think is relevant. (About 90% of patients this is necessary for)
    • Depending on the location they request from, this can take anywhere from 30 minutes to an entire day and night. Once it is in, they have to spend 30 minutes or so translating the data from the fax into their system then scanning the records into their chart.
  • Overall she estimates each patient is roughly an hour of a nurses time to transfer information. So potentially way more time than we had originally estimated.

Nikki Lockett

  • Marketing at Whirlpool. Duke grad in Business, worked investment banking.
  • Couldn’t think of any examples at her current company but the job she had before that worked more with graphic designing there was a system for writing comments and they printed off those comments and were then distributed to the designers and the designers had to type in those comments to their system.
  • Other areas she has worked where stuff like this seems likely:
    • HR – Many systems that are responsible for different parts of the company
    • Global Finance – High level positions that see many divisions or regions
    • Acquiring companies – Consulting firms or big companies that are buying others, need Systems Integration. Maybe we simplify this.
  • Not the most helpful but really nice and could be a resource in the future when we have a more refined idea of a product.

Missy Barcelemy

  • Imaging Center Nurse. Their company uses three different EMR systems internally. These systems do talk somewhat but there are a few disconnects.
  • Emphasized how this could be a viral product within clinics as a marketing tool, “Patients won’t want to go to clinics who don’t have you because they’ll be deciding between a place that faxes their information back and forth and a place that is seamless and immediate.”
  • Story about a nurse who had bad headaches for a few weeks, finally got an MRI and it showed a massive blood clot in her neck that could have killed her. They sent her to the appropriate physician who asked her for the images, she didn’t have them because she didn’t think she’d need them since they were in her system. The doctor didn’t have access to their system so her husband had to sit on the phone for thirty minutes with the other clinic trying to get the information over as quickly as possible. Meanwhile, she could have died any second from this.

Mr. Britt

  • Freight Shipment Control Supervisor – his group arranges the commercial shipping needs.
  • Process begins when a unit submits a DD1149 TCM. That comes to his team in the CMOS system (Air Force software). From there his team routes it to the SDDC system from which it goes out to industry for bids. Once those bids come back, his team lets the unit know which provider(s) will be servicing the move.
  • According to Mr. Britt, there are no data transfer gaps in his groups workflow to address. After probing much more closely – “walk me through that step by step”, “where does that data come from” – it became clear that at a minimum TCPT is not connected on the final step.
  • That final step involves his team going into TCPT to enter: #Trucks, Cost, Bill of Lading #, Carrier, Type of Truck. On average, he estimates his team spends 10min/day entering this info into TCPT. The rare large order involving 100 trucks takes much longer but those are few and far between.

Chief Parker

  • Air Mobility Officer II MEF
  • Chief Parker has been the business SME for development of the SSDM system. That system was just started in 2015 so he specifically wrote the specifications so it integrates with the related applications. While there should not be many gaps, he strongly believes he is not going to get entirely what he wanted. He expects that he will not get all he wants from the TCPT connection. The API will likely be able to support tactical movements without a problem. However, he does not believe the API will support all the data fields needed for movements that require Commercial.
  • He walked me through the process of building SSDM. Concept was proposed in 2012. Funded to begin development in 2015. The program office found a contract developer and Parker defined the requirements just as a technical Product Owner / Business Analyst would need to do. He was taken aback by the amount of detail and work involved. Each API takes about a year to deliver from concept through coding. He has been able to work multiple APIs in parallel.

Leave a comment

Your email address will not be published. Required fields are marked *