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

Key Insights and Decisions

 

Key Decision:

 

• As we explored both the input and output of relevant logistics information into and out of the maintenance area of the Marine Corps, we realized our goal as a group was becoming extremely spread out. As we began thinking about how we could wrap up two different problem that were connected but still required separate solutions, we came across an article explain a issue similar to ours that finance firms encounter and have hire outside firms to accomplish similar goals to what we have been proposing between GCSS and TCPT. After deliberating as a team, we have decided focusing our remaining few weeks on developing and enhancing the “Connectivity” piece of our teams overall model. This means we are abandoning the idea of a maintenance app for a few reasons.
  • The solutions to the input issue only tackle small parts of it and none of these issues caused enough pain nor solutions caused enough value to make it worth the effort of developing a product to solve just one pain point.
  • A solution that would provide enough value to be worth development would potentially require a significant amount of time to develop as well as would require an amount of cooperation that has seemed to be unreasonable from the 2nd MLG.
  • In the private sector, this idea of connecting isolated systems is perhaps more important than we had originally believed. An industry that was at $250 million in 2016 and is projected to reach over $2 billion in 2021. We may be a bit late to the party, but having worked with the Marine Corps to understand some of the most fundamental issues with systems that do not communicate and understand the value of a flexible solution that could potentially continue to evolve into a valuable tool that requires little technical knowledge to use. We believe this along with the idea that most of the companies who have utilized this service are primarily large cap corporations that have the money to spend on customized services. If we are able to develop a generic solution, we would allow for business of all sizes to benefit from systems that communicate.

 

• We will spend the remainder of the semester exploring areas (Beneficiary Discovery) of both the public and private world where this appears to be an issue, with the goal of sizing a market and developing an extremely rudimentary version of what could potentially be used outside of the Marine Corps to solve this reoccurring issue.

 

With that being said, the hypothesis we intended to examine this week was:

 

1. The idea of connecting siloed systems is one that would provide significant value to other areas of the military and civilian industries through saved time, more accurate data, and more timely information.

 

This week, in part because of Spring Break, in part because we changed directions, we were unable to fully attack the areas of the hypothesis we had hoped we’d be able to. However, we were able to look into a few other areas that seem promising for expansion. The one area we have had the most luck in finding beneficiaries on three minus day notice has been healthcare. We have been able to talk with the retired CIO of a hospital, a CTO of a health IT start-up, as well as the head nurse at a private clinic regarding the practice of sharing medical information between clinics, hospitals and other healthcare providers. The overarching idea being that clinics with different Electronic Healthcare/Medical Records (EHRs/EMRs) systems have various but similarly labor intensive processes for keeping patients records updating in their own system. All of which require varying levels of the manual entry of data from another healthcare provider’s system to their own.

Next Couple Weeks:

 

Interviews

 

David Ward:

• Four different clinics he has worked with has asked if this is an issue his company could solve. While his company is not in this business, he has often noted the demand for this.
• His understanding of the process:
  • There is one major player in the EMR system business in his area (EPIC), large healthcare groups (conglomerates, hospitals, etc.) are the firms that can
    • Afford it – Many clinics that don’t have the large revenue base either from the government or private practice are unable to pay the large cost of EPICs system.
    • Be payed attention to – There are many specific features smaller clinics or groups need for their specialty, size or simply because they want it. And EPIC does not have the capacity to implement changes into every individual organization and thus reverts to only customizing the larger groups. Therefore, smaller organizations are forced to contract out their work, often resulting in 5-10 EMR systems implemented within even a small community.
• He was unfamiliar with the specific process of transferring EMR data between clinics but has said he can get us plenty of people who do (including Emily Jacobs, see below)

Emily Jacobs:

• Overview of patient record transfer:
  • Roughly 5% of the time, the referring clinic/hospital has the same EMR system and in that case all information is perfectly transferred, no paper.
  • Three ways patient information gets from one clinic to another (Keeping in mind that at the other clinic that the patient came from this information has already been entered into their chart.):
    • The referring doctor sends the patient notes over with them (20% of the time). When this happens, the receiving nurse takes the patient information (PDF/Handwritten) and enters it into that patients chart in their EMR system.
    • The patient’s notes are not sent over but the clinic has access to the online system of the other clinic, meaning the nurse logs into the other system, prints off a PDF of the information and then manually enters it into their system. (50% of the time)
    • The patient’s notes are not sent over and the clinic does not have access to the online system of the other clinic. This is the absolute worst scenario for them, they must call the other clinics and request the information. This takes hours and sometimes doesn’t get processed until the next day. Resulting in patients care being delayed as their information on prescriptions, diagnosis, and recommended action are unknown to the receiving clinic and likely the patient as well, as this information is generally technical and requires very specific components such as amount of a certain medication or specific muscle/bone/organ that is injured. (25% of the time)
• “Certainly one of the most frustrating parts of my job”
• This is an issue with 95% of patients meaning it is happening from the time they open until close.
• Has a couple other nurses in her clinic she wants me to talk to.

Capt. Baker:

• Informed her of our change in direction toward a focus on connectivity. She understands the decision and supports us, she is hoping to get us through the Defense boundaries in order to get our solution implemented effectively.
• Discussed who we need her to call for military contacts. These will be people we hope to expand our efforts with
  • Medical Group
  • Engineering Support
  • Infantry
  • Special Forces
• Need her help with TCPT and GCSS
  • Have the project manager of GCSS’s name but need to get in touch with him
  • Need the PM of TCPT
  • Need some sort of IT team to talk with.
• She is planning on calling them all this week and will hopefully have a few names for us by EOW.

Parker Erickson:

• Does not work in RPA/tech space; only insight is from a policy perspective
• Could see RPA being beneficial in a lot of ways
  • Interest groups often have tons of personal data about constituents (name, address, etc.) but lists can be outdated/inaccurate
  • Healthcare ERP
    • Cut need for bloated admin staff / get doctors more patient time
  • From lobbying prospective, attending/scheduling meetings, conducting research, sending/processing emails would be nice to have automated
    • Interns might send the same email to a list of Hill contacts dozens of times
    • Would be helpful to RPA search congress.gov, find appropriate contacts and then email (e.g. letter of support w/ correct office, addressee, etc.)
  • Personally, would like to have expense accounting automated
    • Keep track of receipts, submit to accounting
    • “Pain in the ass”
    • Does at least once a month, can take several hours

Cpt. Trinh

• Seymour Johnson AFB has made substantial progress since Team 5
  • Revamped workflow
    • Moved pharmacists to filling station
    • Pod system
  • Delegation of hours
    • Call in and activate refills, can’t pick up until next day
    • Refill during off hours
  • Text notification
    • Turned on for refill verification
  • QFlow
    • Still down, not fully integrated
• RPA
  • USAF already doing this for MDG’s
  • Genesis
    • Cnytrx?
    • DoD did a bid on it 15 years ago to integrate entire medical system
      • Order drugs, verify scripts, can pull medical records from different bases, etc.
    • Currently in Phase 1 (1.5yrs), rolled out around half a dozen bases (USAF, USN, Army)
      • First year rough, bugs fixed and new features added
      • But, if one system goes down, you’re sort of left with nothing
      • Planning on rolling out DoD-wide in 5 years (doubtful)
      • Overall, very positive response

Charlie Covin

• IT-based communication between hospitals and clinics is a longstanding problem area for basically every area of operation: ordering tests, transmitting results, patient record exchange, payment/reimbursement, scheduling.
• Communication between institutions is quickly escalating in importance due to the progress made in implementing electronic medical records (EMR). Hospitals/practices have largely put their own houses in order with regards to implementing EMR systems.  Now they are looking externally. There is not an EMR standard. There is also not an intercommunication standard for EMR and other areas. As a result, hospitals and individual practice systems frequently cannot communicate.
• This is not a sporadic situation as it is not uncommon for a physician with hospital rights to have his practice on a different system than the hospital.

 

Dale Swink

• Thrilled to hear about the progress on connecting GCSS & TCPT.  He just met the Colonel in charge of GCSS recently and should be able to find the contact info.
• Because of his group’s work, he is exposed to a number of different systems that do not communicate but should. As a result, he sees lots of “swivel chair” hand-offs between functions. He actually wrote a paper about it and will send it over.
• At least one of the groups he works with – and requires a swivel chair handoff – uses a Navy system. Chasing this one down could lead to applications within the Navy.
• He volunteered to circulate a write-up of the dispatcher solution to some of his contacts to surface even more areas in which it might be applicable.

John Myrka

• Thrilled to hear about the progress connecting GCSS & TCPT.  He has the contact info for the TCPT program manager and will send it over when he gets back to the office.
• Bridging a one-way connection from GCSS to TCPT is great. It would be even better if you could also go from TCPT to GCSS. (This was news to us!) Turns out motor operations should be entering the vehicle mileage from last service back into GCSS to spark the routine maintenance cycle.  I wondered at why no one had mentioned this in all of my conversations. Our guess is because people just aren’t doing it because of the hassle.
• John also cited a number of other processes that have inter-system gaps. On the supply side – there is frequently a gap between the Distribution Management Office and Material Distribution Center.  Specifically, only partial data is communicated such as the first line of a crates contents. That means that the Material Distribution Center is aware one of their parts is on the way but has no idea what else is on the way.
• John also raised additional gaps that took us into potential applications of the scanner technology and app concepts we explored for other areas.  He saw promise in a few different areas particularly for forward operating elements such as MARSOC operating in low bandwidth environments that could not support full GCSS.

Key Insights and Decisions

Going into this week, here were the two hypotheses we intended to examine:

 

1. Would OVE checks being partially automated be both feasible as well as increase accountability and accuracy to a significant enough degree where Marines would be willing to switch from the paper based system.

 

Our biggest concern with changing how Marine’s operate their inventory/OVE checks is that whatever technology solution we implement, while it may save time and money, will not be adopted because it could be more inconvenient than paper. This meant when we asked OVE officers if they could get behind a technology, we specifically addressed this issue. The biggest gap between tech and paper was the difference in typing versus handwriting. To address this, what will need to do is minimize the instances where writing is necessary. So a solution we raised that was received well was simply making everything checkboxes, as in inventory there are not too many times where you would need to write extensively.

The next concern is how do we make this applicable to both the environment at Lejuene where internet is extremely slow and unreliable as well as in country where there is no internet service. Obviously this requires doing everything locally and transmitting information physically. One solution that we believe would certainly work because it is already being used is a scanner technology that reads relevant information from barcodes and can be scanned directly into fields in GCSS. These fields are all public knowledge and the Marine Corps already has them. Our solution would utilize this by taking any relevant information processed by the application and converting it into a barcode. Then having the OVE officers take the device at lunch or the end of the day to their CO who scans in all of these barcodes to get the relevant information.

 

1. How could we most effectively (in terms of most time saved, mistakes prevented, and flexibility/durability) improve the LTI reporting system.

By utilizing the aforementioned scanning technology, would could have maintainers scan a code with their tasks for the day, use our app to update them as the do them, the have the QC clerk scan each person’s barcode at the end of the day into GCSS. The design for this seemed to be the most well received by both the actual users as well as the COs who we would need by in from. The app would certainly save time and mistakes, but what remains to be discovered is whether or not it alone would be significant enough to be embraced by COs.

 

Next Couple Weeks: We will design the flow of two apps. One that solves the LTI issue and one that solves OVE checks. We will present both to our contacts in 2nd TSB and hopefully get constructive feedback on whether or not they would like us to actually build a working version. GySgt List was very eager to have us use his company for a trial. He has four scanners ready and if we were to pursue the scanner technology we could use them to effectively use our app. Many of the members of his platoon have experience working with his scanner app, we believe it is most likely to be adopted there and will hopefully continue to spread throughout the Marine Corps if it is successful.

 

Interviews

 

Michael Jelen:

• Blockchain
  • Add an augmenting layer via blockchain API
  • Would cost more network resources
    • Not all are as intensive as Bitcoin bc it’s a private blockchain
    • Search up consensus algorithms
  • Shipping Industry
    • Maersk
      • Signed up with IBM to use blockchain
    • Starbucks
      • Wanted to use blockchain to verify coffee beans for fair trade, specific regions and farmers, specific date
    • Walmart
      • Food safety
    • Lot more manual, could benefit from blockchain
    • Who’s shipping, who owns the containers, etc. is on paper or PDF
      • Being emailed around the port
    • Add scanners/sensors
      • Ex: temp scanner in produce
• Scanners
  • How to maximize efficiency? Still need people to go out there
  • Inventory
    • RFID, machine could move around the room and check on everything
    • Sort of like Vault from Team 5
  • Maintenance
    • Scanner app, just take them off paper
• Dashboard
  • Tableau
  • Composite Readiness Score of some kind

 

Scott Frederick:

• ITPR, MC Forces Systems Command, extra approval layer
  • Procurement
    • New system/idea/concept
      • PMC (procurement money), 3yr money
      • RDT&E (research development tools & equipment), 2yr money
      • DoD FMR (financial management readiness manual)
        • USN’s; USMC 7300B
    • Commander (BG) will go to comptroller and tell him he wants to buy this new product
      • Comptroller will create an initiative slide
        • Breakdown purpose, cost, etc.
        • Take that and next palm submission (in one atm, this won’t happen until next year)
          • Palms happen every year for every unit,
        • Then gets routed up to P&R (programs and resources) at the Pentagon
    • Pentagon
      • If approved, MC HQ will program that money to 2nd MLG
      • When 2nd MLG gets money they can get money
      • Need contract to tie the money to the product (need contractor to do that)
        • Part of the contract will have an ITPR #
    • ITPR
  • Contract Mechanisms
    • Need to be an approved contractors
    • DUNS #
    • Need to create an LLC (48hrs in NC), get a DUNS # (30 days), then work with an RCO officer to get the contract done
      • Can’t do any of this until money is distributed
      • UNLESS general wants to free up money from elsewhere
  • Would take 12-36 months by his guess
  • OMMC (day to day money), PMC (investment money, 3yr), RDT&E (research money, 2yr)
  • Deployment
    • IT implementation template
      • RCO (resource contracting officer)

GySgt Hinds:

 

• Provided information as to the role of an Operations Chief: checking what operators do, verify that missions are being run and that there are drivers for missions
• Uses GCSS, MOL and TCPT on a daily basis, and often has to enter the same information twice every day
• Believes that all systems (GCSS and MOL) are supposed to talk through MCTIMS and thinks that this is the ideal world. Wants to just be able to use MCTIMS
• Has to validate all equipment every three months, and believes that a scanner would make this process much smoother and easier

 

MSgt Lemus:

• Demonstrated the MMR auditing tool, it works sometimes but doesn’t measure the things the CG and higher command want to see.
• What is really needed is something that can go line by line through the MPR and flag discrepancies.
• A General went through a TSBs MPR and took their readiness from a 90+ to a sub 50.

 

GySgt List:

• Scanner to Keyboard Emulator technology is how we
• The major factors in determining what he will use are how durable and flexible it is. For example, it needs to be able to work with no internet as well as withstand people messing around with it.
• OVE Checks – showed us the OVE room as well as which tools he thinks a scanner would be helpful for. Our goal for the day
• LTIs – This is his biggest pain. Maintainers need to debrief their parts as well as updated the status on their tasks but they don’t so if we could help fix that, we could dramatically change the flow of the maintenance floor.
• Workflow – Introduced us to a group of Marines who walked us through the workflow

 

Capt. Baker:

• Is working to understand the problem better. Wants us to continue working but is nervous about roadblocks.
• She will work to free up GCSS IT people for us.
• Believes our best bet is TCPT as it is Marine Operated.

 

LCpl Hernandez (Mechanic), Cpl De Silva (QC), and LCpl Casillas (floor chief):

• • Collectively walked us through process of service request
  • Mechanic examines vehicle, finds an issue, issues a service request (all of this is written on paper and reported to floor chief

 

• Floor chief directs QC to examine vehicle and determine if a service request is needed

 

• QC examines vehicle and takes paper notes on what services he recommends for the repair process/if a repair is needed
• QC inputs information from check into GCSS with

 

LCpl Lawrence (OVE Officer) and LCpl Batton (OVE Officer):

• Walked through the process of performing OVE checks:
• Showed us the paperwork they fill out when a check is performed on the equipment for each vehicle.
• Simple checklist
• Confirmed that a scanner application would be useful in performing the OVE checks

 

LCpl Garrett and LCpl Mark:

• Determines where service requested parts are stored
• Uses Gunny List’s technology everyday, says it cut down his work from 8 hours to 1 hour.
• Information relevant to his job is contained in a barcode that he scans, the data is then taken from an excel sheet and the appropriate field is populated in GCSS

 

Sgt Zyglov:

• Helped us diagram flow of how an MPR is generated and what can be done with it
• Many different formats to export to, most important to us is Excel
• The Excel sheet contains the next date available field also, this is the most relevant to TCPT.

 

SSgt Christ (Head Dispatcher), Sgt Thomas, Sgt Hess, Sgt Howie (Dispatchers):

• Walked us through the process of updating personnel information and vehicle status in TCPT
• Confirmed the capability of TCPT to import excel spreadsheets for both personnel and vehicles but unable to determine whether importing updates different fields in TCPT. This highlighted an issue we had heard before, no one understands how these cool features work. TCPT has all these awesome capabilities but if no one knows how to use them it’s pointless.
• Reinforced the number of redundancies within GCSS and TCPT- there are multiple areas where they enter the same information
• Confirmed that connecting systems would lead to huge reduction in the time spent using TCPT and GCSS
• Suggested automating process from MOL to TCPT first since MOL is marine owned

 

Cpl Murphy:

• Walked us through how a 3400 sheet works
  • There is a barcode and QR code associated with every part.
  • These can be scanned into a computer with the ID Innovator.
  • This information is placed in the input of GCSS and uses keyboard emulation to do this.
• Showed us how he thinks we could potentially utilize the same technology for any maintenance app