This week has been an extremely busy week (17 total interviews!) for our team- we have continued to refine our MVP by soliciting feedback from multiple end-users. We developed a second version of the product and are continuing to work through the kinks that we have encountered through last week’s interviews. We have worked to refine both functional and non-functional requirements for our product, with emphasis on back-end architecture to support a working app.
We spoke with several app developers about the requirements to bring our prototype to the real world, and we found that there is a lot more work to do, including storage on the cloud, and interactive communication between devices. As we discover more about our product and the work that’s necessary to bring it to life, we are both excited and daunted about the future.
Thank you for all your support. We couldn’t do it without your help!
Team 3
TW (name withheld): 18A
– Focus on making TUPAC as intuitive and modular as possible.
– Anyone one on a given team could use this app, not just the 18D or a SOFACC grad. Situation dictates.
– Early adoption hinges on the ability to integrate TUPAC in SOCM and SOFACC training.
CM (name withheld): 18D
– Use standardized triage categories for patients: Urgent, Urgent Surgical, Priority, Routine.
– Add ETCO2, SPO2, MAP (Mean Arterial Pressure) to vitals input/ tracker.
Kevin Iskra: Former 18D; current SOF PA
– TCCC portion of TUPAC is not necessary; “I don’t have time to use an app when I am conducting tactical field care for a patient;” the real value of the app is in the prolonged field care documentation/ communication.
– Drug calculators are very important; incorporate basic calculations.
RC (name withheld): 18D
– Incorporate a threat algorithm into long-run vital trends; this would offer a backstop for the medic when patient conditions deteriorate, and help focus care plan accordingly.
– SOAP note: “the most important part of my conversation with a provider is the P (Plan); TUPAC should help me convey my ‘P’ when talking with a remote provider.”
Alex Wilson: Former 18D; current Fuqua student
– We need to get TUPAC in front of the cadre at SOCM; they would be a huge resource.
– Incorporate a way to upload/ download drugs and Class XIII; helpful when working in new AOs and the inevitable stress involved in ‘handing off.
Russell Dallas: 18D
– As an 18D, toughest aspect(s) of conducting telemedicine are (1) presenting the patient (what I have done with the patient, time now); (2) my forecast for the future (where I think the patient is going health wise); and (3) what resources I have to treat the patient (if limited resources, how long I can manage current state before running out of resources, i.e. drugs, equipment, etc.).
– With an app – sometimes more (features) are better; sometimes more is more.
Sean Keenan: Former SF Battalion, Group, and Theater Surgeon; pre-hospital care SME
– Discussion on necessary additional tools for off-line pediatric drug administration; revised input order for primary data recording.
Brian Smedick: (Outgoing) 4BN 3SFG Surgeon
– Add in MAP to automatically calculate from systolic and diastolic blood pressure. ⅓(systolic BP) + ⅔ (diastolic BP) = MAP.
– TCCC card taking a picture. It would be great to be able to add the vitals trend to the SOAP note.
– Two-way communication on the SOAP note.
David VanWyck: (Incoming) 4BN 3SFG Surgeon
– Upload video in addition to photos on the phone would be really helpful to see pt responses, e.g. flexion vs extension in response to pain.
– Tracking “ins” and “outs” would be vital.
Chris Brezina: Navy SARC (MARSOC)
– Demonstrated App V2.
– Each deployment has individual first aid kit in addition to community health aids. The individual first aid kits include: 2 TQ, pack of 2 chest seals, nasopharyngeal airway, combat-delpaks.
– Include SOAP note ability to voice record patient notes.
Roger Dail: Former 18D; CEO & Founder – Ragged Edge Solutions
– What does our business plan say we are trying to accomplish? In one sentence, explain how our app provides a specific solution.
– Don’t try to re-create the wheel unnecessarily; find a way to integrate TUPAC with BATDOK – which will inevitably be successful and adopted by SOCOM.
– Invitation to visit RES/ 3SFG “Mountain Path” exercise in March (March 4-8); opportunity to field test/ solicit feedback from provider and practitioners alike.
Eric Malawer: Team 3 Advisor; Comcast
– Our app’s value comes from ownership of the end user.
– Start with the Front end and work your way back, the only way to own the customer is by first focusing on their experience and then finding the ways to make it possible.
– The challenge here is 1) creating knowledge and matching it to experience and 2) how we own the consumer/user.
Wicar Akhtar: Former Head of User Experience, Nokia
– Provided foundation needed to communicate with developer
– Need list to achievements needed in excel
– Development in non-native environment would provide the widest amount of leeway for app development in different environments
Nick Setterberg: Associate Director, Kessel Run
– Prioritize requirements; error on the side of having less features – roust features are typically stripped at the end. Our value/ strength is speed to market/ user.
– Generate a giant list of assumptions before “deploying” prototype (MVP) to beneficiaries, then work hard to validate them; design tools/exercises like “Crazy Eights” and “Dot Voting” are helpful in stimulating user feedback.
– Avoid groupthink when soliciting feedback – no leading questions.
Matt McGuire: Software Architect & Developer, Protectwise, Inc.
– Requirements document – functional and non-functional requirements documentation.
– Non-functional requirements: (1) RPC (remote procedure calls) for message passing; (2) Strong message broker (create a loss-less form of communication) ; (3) Elliptic Curve Cryptology for encryption; (4) Everything should live in the cloud (AWS).
Nick LaRovere: Software Product Manager at a large home security company
– When building out the back-end of our system, we need to look at available frameworks for easier coding, potential code hosts, and good COTS solutions.
– .mil uses legacy code: TUPAC will need to integrate with older systems; plan accordingly.
Michael Jelen: Director, Berkley Research Group; experience in software consulting
– gave direction on how to visualize our development process: determine core database (level 1), create your logic framework (level 2), create system for user to interface with entire stack (level 3).
– planned call for next week with new visuals provided.
