Digital health engineering · Controlled workflows · External systems
Give staff a usable route from preparation to authorised action, with the information and external responses needed at each step. Twin builds specialist health applications and the connections around them.
A first engineering scope maps the users, records, external services and release dependencies. It defines what the workflow must demonstrate before people rely on it.
Australian digital health
Twin built ScriptStream for specialist prescribing within Wesley Pharmacy Group. Clinic staff prepare the prescription, an authorised prescriber reviews and approves it, and the software submits it electronically. BOP Plus owns the platform.
ScriptStream was in early production in October 2026. The project record gives separate details for registration, prescriber use and continuing PRODA work.
See ScriptStream’s rollout status · Check the integration and conformance milestones
Roles and states
Keep preparation, review and final authority visible so the next person can continue the work with the right context.
Translate those responsibilities into access rules, permitted actions and tests of the complete journey.
Collect the required information, show gaps and allow correction before review.
Show source context and earlier changes. Reserve the final decision for the permitted role and record the version it applies to.
Keep the external response with the task. Give support staff the access needed to investigate, correct or retry approved actions.
The client and its advisers confirm the applicable legal, clinical, privacy and regulatory obligations. Twin translates those requirements into access controls, acceptance criteria and representative tests.
Status and recovery
External services, incomplete information and review decisions are part of the operating reality. Make their status visible and give the responsible team a practical way to continue.
Check required information, conflicting values and permissions before an exchange. When a service rejects or delays a request, keep the reason, owner and permitted next action with the original record.
Retain the request, response, corrections and recovery attempts. If a change affects an earlier authorised decision, return it through the required review before retrying. The event history should identify who acted, when, what changed and which record version they used.
Quality and release preparation
Test the product as a connected workflow, including user roles, data, external dependencies and the evidence required for applicable conformance work. Agree the release and support responsibilities with the client.
Testing should cover role boundaries, permitted state transitions, information changes, external services, negative scenarios and recovery paths. Environment configuration, deployment preparation and post-release checks make the release easier to verify and support.
Controlled change after release
A change to a role, rule or integration may affect earlier steps and stored records. Version the requirements, test the affected journeys and agree release approval and recovery arrangements.
Australian digital-health delivery in practice
Follow the project from a specialist prescribing requirement to connected early-production use.
ScriptStream’s documented milestones include Healthcare Identifiers NOC and conformance, eRx ETP1 and ETP2, and the version-specific electronic-prescribing register entry. The October 2026 record shows early production, continuing onboarding and full PRODA integration still underway.
View the ScriptStream storyFor a patient mobile application example, explore DYM Medical’s appointment booking, medical-record access and family-profile journeys.
View the DYM Medical storyClient work
Explore the client, delivered application and practical value behind each programme.
The original OMRON Singapore experience linked compatible devices, mobile measurement history and a Patient Data Platform.
Read the customer story
Appointments, reminders and family vaccination records became part of one mobile service before and after a centre visit.
Read the customer story
Booking, QR check-in and controlled access to linked family records supported a continuing patient experience.
Read the customer storyBefore we begin
Yes. We assess the available interfaces, identifiers, user roles and operating requirements, then scope the connection and testing. The existing application can remain where it continues to meet the service’s needs.
The requirements depend on the health service and integration. For ScriptStream, Twin supported the specific Australian integration and conformance work described in the customer story. The product is in early production; further development and full PRODA integration remain in progress.
Yes. A programme can include specialist staff workflows, patient applications, connected devices and the information exchanged between them. Access, consent requirements and release responsibilities are defined for the service being delivered.
Plan the engineering brief
Bring a task that staff or patients find hard to complete, its authorised roles and external services. We can define an initial workflow, its acceptance tests and the dependencies that affect release.
