Account trust
Email verification, two-step sign-in, and passkey support.
Approach
Clinical context, product decisions, and engineering stay on one delivery line.
Chiasma does not leave strategy in one presentation and implementation with another team. Problem framing, architecture, experience, testing, and handover advance together.
01—05
A five-stage delivery system
- 01
Clinical and operational discovery
We clarify the problem, users, decision boundaries, and success criteria together.
Visible artifact · Problem frame and decision boundaries - 02
Scope and system architecture
We turn data flows, roles, risks, and delivery boundaries into an implementable plan.
Visible artifact · Scope, data flow, and technical plan - 03
Design and implementation
Content, interface, and engineering are developed within one decision framework.
Visible artifact · Working interface and application increments - 04
Validation and release
We test critical flows, accessibility, failure states, and release conditions.
Visible artifact · Test findings and release decision - 05
Handover and continued operation
Source code, documentation, and responsibilities are transferred visibly.
Visible artifact · Source code and operating documentation
Controlled client area
Project records and access are managed in a production workspace.
The workspace is not designed for patient data. It keeps project metadata, status, and team access within the client boundary.
Workspace boundary
Customer membership and role are checked server-side for every project request.
Audit trail
Administrative operations append to audit records.
Publication permission
Client references are disabled by default and can be withdrawn individually.
Workspace boundary
- Verified account
- Membership and role check
- Authorized project record
Administrative change → audit record
Explicit boundaries
A technical control is not a certification claim.
Regulatory and clinical-safety requirements depend on intended use, data, and contractual scope. These mechanisms support that assessment; they do not constitute compliance declarations on their own.
Clinical purpose
Users, purpose, human role, and unacceptable failure modes are defined in scope.
Minimum data
Every field is tied to purpose; unnecessary and sensitive data is excluded.
Validation
Critical flows, role boundaries, accessibility, and failure states are tested before release.
Ownership
Source code, documentation, and operating responsibility remain visible in the handover plan.
Common starting questions
Do we need a technical specification for the first conversation?
No. A short description of the problem, user group, and current workflow is enough for an initial assessment.
Should we share patient or research data in the first form?
No. Do not enter patient identifiers or sensitive clinical data. Data requirements are considered only after purpose and secure-transfer boundaries have been defined.
Are source code and documentation handed over?
Delivery scope includes source code and documentation handover; detailed ownership and operating responsibilities are clarified at project start.
Next step
The next step is to clarify the problem, not prescribe the solution.
Share brief context and we will assess the appropriate solution line and initial scope together.
Please do not share patient-identifying or sensitive clinical data.