Revolutionizing the tracking of surgeons and medical research
Behind every surgeon lie years of training, skills learned and patients cared for. With Surge ID, we imagined a digital tool to track this experience and give everyone a clear view of their journey.
UXUIInnovationMobileBrandingMedtech
Vision
One ambition: simplify the capture of surgical data and improve research.
In neurosurgical training, every procedure is a learning opportunity. Physicians discover a technique, take part in the procedure, then gradually take on more responsibility. Their curriculum must reflect this experience and the categories of procedures they still need to practise.
In 2020, the founder of Surge ID approached atipik with the goal of making this tracking easier. The starting point was the surgical logbook: an essential training tool, whose information was still recorded on paper. How could it fit more naturally into surgeons’ daily routine? How could their progress be made visible, both to them and to the physicians who train them?
Our collaboration began with a prototype. It walked through the future user’s experience, from sign-up to logging a procedure, then to its validation and the tracking of the curriculum. This first step gave the project a concrete shape and opened the product design work.
Where the project began
From a paper logbook to tracking surgical activity.
Taking part in surgery, attending a course, earning a certificate: training is enriched by very different situations. When reviewing their curriculum, surgeons need to be able to find them and put them into perspective. We designed Surge ID around this continuity, bringing the stages of their learning together in a personal space.
A first prototype to explore usage
The first user flows already raised the questions that would run through the project: how to record one’s participation, request a validation, consult one’s curriculum and keep one’s certificates? The prototype connected these moments and made it possible to examine the transition from one to the next before refining the screens.
Training that evolves with the physician
The project also led us to think about changes of hospital and training catalogues that vary from country to country. These questions are a reminder that a curriculum unfolds over time. They shaped the design of a logbook tied to the surgeon’s career and of a space suited to the department’s needs.
All surgical activity, gathered in one place.
Training happens at two levels: that of the physician developing their practice, and that of the team supporting them. We connected these two needs in Surge ID. The mobile app brings together the surgeon’s logbook and curriculum. The web space lets the head of department follow team members and surgical activity. Each procedure can thus be placed both in an individual story and in that of the department.
01
The surgeon
Logs a procedure Specifies their role Consults their curriculum
Mobile app
The common ground
The procedure
Technique · team · hospital Date · duration · clinical data
02
The department
Reviews activity Filters procedures Follows team members
Web Manager
Simplifying data entry to keep the patient at the centre of attention.
We worked to make logging surgical activity as simple as possible. A surgeon, their assistant or a trainee can add every relevant detail in a few seconds, by hand or by voice.
Picking up the thread of a procedure
The record brings together the information that tells the story of the procedure. Surgeons find what they have already entered and complete the details from dedicated sections. This structure lets them resume their entry using the landmarks of their practice.
Familiar landmarks from the very first entry
Categories use the terms neurosurgeons use every day. Logged procedures thus find their place in the training catalogue, linking each procedure to the experience gained.
Securing peer validation of the curriculum with cryptography.
A procedure can involve several physicians, with different levels of experience and responsibility. For residents, specifying their participation and having it recognised is part of their training. We designed a flow that links their entry to the physician in charge of validation. The request remains identifiable in the logbook until it is confirmed. A signature then attests to the validation of the procedure, which the resident can find in their record.
A journey validated by peers
1
Draft
Fill in the information.
→
2
Request
Submit for validation.
→
3
Validation & signature
Confirm participation.
→
4
Curriculum
Review progress.
A curriculum spanning several years, visible at a glance.
The total number of procedures is not enough to understand a curriculum. Training requires practice spread across different categories, with targets to reach. Our designers imagined a reading that starts with overall progress, then lets users explore each category. Rings provide a first landmark. Figures and charts detail the experience gained. Surgeons can see their progress and identify the stages that still require practice.
Cranial
Spinal
Academic
Cranial, spinal, academic: three colour-coded worlds to keep one’s bearings throughout the journey.
Making progress something to look forward to, day after day.
Our product designers gave the curriculum a visual identity that supports the desire to progress. Pink, orange and purple distinguish cranial, spinal and academic activities. These colours appear in the charts and records, alongside the labels needed to understand them. Cards group information together and figures highlight progress. These landmarks follow the surgeon from one screen to the next and extend into the department’s space.
Their training at their fingertips
As soon as they open the app, surgeons find their curriculum and recent activity. They can add a procedure, consult their logbook or access their certificates. These shortcuts bring training information closer to the moments when it is needed.
Intuitive from day one, no training needed
We worked on every flow so that the app fits naturally into surgeons’ practice. Screen layout, labels and the sequence of actions should make it immediately clear what to do, without adding cognitive load to clinical work. Our goal: autonomous onboarding, with no prior training.
Web Manager
Giving heads of department a view of their team, its talents and their progress.
Within the same department, physicians in training do not all follow the same path. Some still need to practise a category of procedure, while others are nearing their targets. Heads of department need to understand these differences to support their team. We designed views that bring curricula side by side and allow activity to be explored by team member, by group and by type of surgery. They provide reference points for discussions about training and the experience to develop.
Understanding the team’s needs
Heads of department can explore activity by period, by type of surgery or by team member. These views bring individual experiences together and show where each team member stands in their training.
Understanding the experience behind the numbers
Every overview gives access to the procedures it is made of. Heads of department can retrieve the context, the participants and each person’s role, linking the displayed progress to actual practice.
Taking care of the information entrusted to us.
A surgical logbook contains information relating to patients and their care. Protecting it has therefore guided our thinking from the design stage. We worked on app access and security steps to explain the actions asked of surgeons and give them clear landmarks.
Protecting sensitive data
Encrypt from the moment of entry. Share with the right people.
Sensitive information is encrypted on the device before it is sent. It can only be read on the device of a user who holds the required key.
01On the surgeon’s device
Data is protected
A random data key encrypts sensitive information with AES-256-GCM. The key is then protected with the surgeon’s public key.
Sensitive data → encrypted data
→
02On the server
Content stored in encrypted form
The server stores the encrypted data, its encryption parameter and the data key protected for the user.
Encrypted data + protected key
→
03On the device when consulting
The surgeon retrieves their information
Their private key unlocks the data key. The app uses it to decrypt the information locally.
Private key → data key → reading
01The surgeon sharing
Preparing a colleague’s access
The app retrieves the data key on the surgeon’s device. It protects it again with the recipient’s public key.
Data key + colleague’s public key
→
02The server
A protected key for each recipient
The server stores this new protected version of the key. Participants access the same encrypted procedure data.
Shared content · individual access
→
03The authorised colleague
Consulting from their own device
The colleague uses their own private key to unlock the data key and read the information in their app.
Their private key → the shared data
01Two custodians
A secret split into two parts
The master recovery account holds a secret split into two parts: one kept by Surge ID, the other by an officially designated trusted third party.
Surge ID + trusted third party
→
02A recovery procedure
Bringing both parts of the secret together
Logbook data is also shared with the master account. Bringing both parts together makes it possible to use this account to restore access.
Two parts → access to the master account
→
03The surgeon
Getting their logbook back
Once a new personal secret has been created, the data keys are protected again for the user, who can retrieve their information.
New access → logbook restored
A fallback built into the design
This master account provides a path for data recovery. Its full secret requires both parts, held separately, to be brought together.
Understanding the protection steps
The app guides surgeons through creating and keeping their security key. Explanations accompany each step so they understand their role in protecting their information.
Anticipating everyday situations
Changing devices or recovering access is also part of an app’s life. These situations were built into our product thinking, to support surgeons over time while taking the sensitivity of the information into account.
Bringing together the full richness of a training journey.
A surgeon’s training is also shaped by courses, conferences and meetings with peers. We gave these experiences a place in Surge ID, with a space to keep certificates and find them when preparing one’s file. The surgical logbook and the academic path thus tell a more complete training story.
Sharing a vision of surgical training.
To present Surge ID to healthcare professionals, we extended the app’s visual identity into a dedicated website. It showcases how the product is used and the role of each stakeholder, from surgeons to hospitals. Visitors can discover this vision and request a demo.
Innovating in healthcare means designing useful tools that protect data.
In healthcare, innovation truly makes sense when it simplifies professionals’ daily work while protecting the information entrusted to them. With Surge ID, we brought product design, UX/UI and development together around these two requirements.
Confidentiality is part of the design choices from the very start: this is the privacy by design approach. End-to-end encryption protects sensitive data on the device before it is transmitted and allows it to be read only by people holding the necessary keys. Access, sharing and validation flows are designed with this protection at the heart of the experience.
Compliance with the new Swiss Federal Act on Data Protection (nFADP) is prepared from the design stage. Privacy by design, access control and data security all contribute to this approach, which combines technical and organisational measures.
Surge ID
•
Published on the 1st October 2026
