Surgical Technology Support + iOS Development

Gunnar Hostetler

I work as a Stryker OnSite Specialist at the VA in Palo Alto, providing intraoperative technical support on Endoscopy systems for Stanford surgical teams.

In my free time, I build iOS apps

Every app I've built started as an idea, which led to a question, which led to a doc or two, which led to a prototype, which led to more questions, and so on until it finally worked.

3.5+ Years Operating Room experience
2.5+ Years iOS App Development
4 iOS Apps On the App Store

Selected Work

OpenClinic iOS App Icon

OpenClinic

An EHR prototype iOS/iPadOS App for exploring local-first retrieval around chart-shaped patient data

Why: I wanted to see what would happen if I applied the same OpenIntelligence engine to clinical information. OpenClinic is the prototype where I tested it against chart-shaped data (not production medical software).

Clinical Data Sync: I integrated the SMART on FHIR standard using secure OAuth flows (ASWebAuthenticationSession). This lets the app connect directly to hospital sandbox endpoints and securely download structured Patient, Condition, and Medication resources.

Local Storage: Instead of sending patient histories to a cloud database, the app parses and maps the incoming FHIR clinical resources directly into local SwiftData schemas, keeping health records private and offline.

Current State: I reused the same agentic reasoning loop from OpenIntelligence, wired up SMART on FHIR discovery and OAuth (ASWebAuthenticationSession) to pull demo Patient, Condition, and MedicationRequest resources into a local model. It's surprisingly good at finding relevant information in the chart and answering questions with citations, but the current data is too limited to be more than a demo of the retrieval and reasoning patterns. The next step would be to connect it to real FHIR endpoints and see how it handles the messiness of real clinical data, which comes with a multitude of complexities.

SwiftUI SwiftData SMART on FHIR Core ML SQLite FTS5 RRF OAuth Vision OCR
OpenResponses iOS App Icon

OpenResponses

An iOS/iPadOS App built around the OpenAI Responses API.

Why: OpenAI announced they were deprecating the Completions API, and my immediate thought was "they're killing my first app!" - OpenAssistant - so I opened VSCode with OpenAssistant in one window and OpenResponses in another, using LLMs to help swap out all the endpoints and rebuild the flow on the new Responses endpoints.

Computer Use: I built a custom streaming interface that translates browser tool-calls (clicking, typing, scrolling, screenshots) into a native Swift environment, letting the model navigate web pages in real time.

Connected Tools: To give the model access to the real world, I integrated Model Context Protocol (MCP) connectors and Apple EventKit, allowing it to securely read and update Gmail, Google Calendar, Dropbox, Notion, and Apple reminders.

What I learned: Because of all the App Store Connect rejections on my first two apps, I learned exactly what reviewers looked for. I got this one passed through review without a single rejection on the first pass.

SwiftUI Responses API MCP Connectors Computer Use Request Inspector EventKit Tools File Search SSE Streaming
OpenCone iOS App Icon

OpenCone

An iOS App that meshes the OpenAI Completions API and the Pinecone API together to form a RAG client for testing multi-index document search - later updated to use the Responses API.

Why: When I started getting into deeper development with OpenAssistant, the app would start losing context during large document queries. I looked up vector databases, found Pinecone was the standard, and realized they didn't have an iOS app, so I decided to build one. I wanted to query multiple indexes and namespaces in a single chat thread, which was something the OpenAI Assistants playground was limited in doing.

On-Device File Reader: To feed documents into Pinecone, I built a local parser using Apple's PDFKit and Vision OCR. It extracts text from PDFs, DOCX files, and raw photos, automatically chunking and converting them into embeddings on the fly.

Network Safety: To prevent the app from lagging or getting stuck when a server fails, I built a network circuit breaker. If Pinecone fails twice in a row, the app automatically pauses requests and lets the user know immediately.

What I learned: I took the backend from OpenAssistant and swapped out the storage layer for Pinecone. Honestly, in retrospect, the initial interface looked awful, but I later rebuilt it with the Responses API and clean embeddings. Getting this on the App Store was a personal milestone.

SwiftUI Responses API Pinecone REST API PDFKit Vision OCR Circuit Breaker Speech Recognition SSE Streaming
OpenAssistant iOS App Icon

OpenAssistant

My first shipped iOS App, built around the OpenAI Assistants=v2 API. Engineered to handle vector stores, document uploads, active run polling, and strategy-driven local file preprocessing.

Why: When ChatGPT-4 first came out, it BLEW my mind. I was working with tons of medical documentation at Stryker and using it to learn fast, but their official app was slow, crashed, and limited me to 5 files at a time. I got curious about their API, saw people making wrappers, and thought, why would I pay for someone else's app when I can just build my own?

File Formatting: OpenAI, at the time, would reject standard iPhone files (like live HEIC photos or RTF documents) when uploaded. To fix this, I set up a local conversion system that automatically turns these files into standard JPEGs and plain text on the device before sending them off.

"Is it done yet?": Since OpenAI's Assistants API didn't respond instantly, I built a timer system that checks in with OpenAI every 2 seconds to see if the assistant is done thinking, so the app can display the answer the second it's ready.

What I learned: Making an iOS app isn't easy. I built it by copying OpenAI API references into text files, uploading them to a playground vector store for context, and copying and pasting the red errors back in to get corrected code. I repeated this until it worked, spent $99 on a developer account, and finally got it on the store after being rejected upwards of 30 times because they kept telling me everything that was wrong with my app.

SwiftUI Assistants API (v2) Vector Stores Run Polling Strategy Pattern NotificationCenter Firebase SDK

What the Work Looks Like Over Time

Syncing commit history...
Mon Wed Fri
Syncing commit activity...
Less
More

Repo History

A quick visual of how the repos changed over time. Each ring comes from commits, grouped by the kind of work: features, fixes, refactors, and docs or config.

Features
Fixes
Refactorings
Docs / Config
OpenClinic Icon

OpenClinic

Syncing...
- commits
- weeks active
OpenIntelligence Icon

OpenIntelligence

Syncing...
- commits
- weeks active
OpenResponses Icon

OpenResponses

Syncing...
- commits
- weeks active
OpenCone Icon

OpenCone

Syncing...
- commits
- weeks active
OpenAssistant Icon

OpenAssistant

Syncing...
- commits
- weeks active
PlaudBlender Icon

PlaudBlender

Syncing...
- commits
- weeks active

How I Build

I operate with a childlike curiosity and high energy. I look for solutions to inefficiencies even when I don't consciously want to, and build tools to understand things that go beyond what I already know.

I've wanted to build software for a long time, but I didn't have a way to get from “I wonder if this could exist” to actually making it exist.

LLMs changed that for me. I leverage AI and RAG architectures to build the working foundations of my apps through the literal ingestion of complex API documentation. Once the core foundation is set, I build the real structure around it and just go nuts filling in the gaps.

My process is built on relentless, iteration-driven execution.

I use AI as an implementation partner to move through code, documentation, errors, and debugging fast enough to stay with the idea. I still decide what the thing should do, how it should feel, and whether it's actually useful.

I've learned to just roll with the chaos of building, and because of that, I have created things I never thought I'd be able to.

At the end of the day, the things I make still have to work. They have to run, handle real inputs, survive weird edge cases, and function well for the reasons they were built in the first place.

What I Use

Surgical Operations & Logistics

Working inside ORs where equipment, timing, sterile process, documentation, and relationships all matter.

Intraoperative Support HIPAA Compliance PIV Security Clearance Censitrac Instrument Tracking Surgical Workflow Support Endoscopy Video Setup Account-Level Operations

iOS Mobile Systems

Building native Apple apps around files, data, auth, state, local storage, and release details.

Swift / SwiftUI SwiftData / CoreData AppContainer DI Keychain Credentials Store OAuth / ASWebAuthenticationSession Security-Scoped Bookmarks Xcode Build Errors App Store Release Flow

Model APIs, Tools & Retrieval

Working across model APIs, local models, vector stores, tool calls, OCR, and source-backed answers.

OpenAI Responses / Assistants APIs Gemini API Apple Foundation Models Core ML / BNNS Vectors Pinecone / Qdrant Vector Stores SQLite FTS5 / RRF MCP Tool Servers Tool Calls / Function Calling Code Interpreter / File Search Vision OCR / PDFKit Parsing Streaming Event Payloads Source & Citation Checks Recursive Reasoning Loops

Work Context

OnSite Specialist

Stryker | VA Palo Alto Health Care System

Aug 2022 – Present
  • Provide intraoperative technical support across 8 operating rooms, including Stryker endoscopy towers, cameras, instruments, video setup, troubleshooting, and equipment functionality.
  • Serve as the first on-site Stryker resource when a room needs fast troubleshooting, configuration help, escalation, or readiness support.
  • Support case readiness by making sure equipment, instruments, supplies, documentation, and account-specific needs are ready before procedures start.
  • Help keep the account healthy across procurement, vendor coordination, inventory, par levels, schedule-based forecasting, repairs, replacements, and equipment availability.
  • Integrated 1,500+ surgical instruments into the Censitrac instrument tracking system.
  • Coordinate daily with surgeons, nurses, scrub techs, anesthesiologists, sterile processing, biomedical engineering, vendors, and hospital staff.
  • Hold Government Contractor PIV clearance with VA intranet access for secure workflows, system changes, documentation, and account-related operational needs.
  • Work independently in a high-pressure surgical environment where priorities shift constantly and problems require fast, practical judgment.

Get In Touch

Contact

I'm always open to connecting! Whether it's about my apps, what I used to build them, or just to chat about similar curiosities, reach out here or through the links below.