A care management application needs explicit rules for who can see a record, who can change it and what staff do when the software is unavailable. Start with those workflows and failure cases before choosing a framework. A scheduling tool, clinical record system and patient messaging service carry different responsibilities even when their screens look similar.
This is engineering guidance for planning a product, not clinical, legal or regulatory advice. Have qualified people determine the obligations for your jurisdictions, customers, data and intended use. No client implementation or compliance certification is implied by the examples here.
Define the product's clinical boundary
List what the software does and which decisions remain with qualified staff. An app that schedules visits should not quietly become a source of medication advice through a notification template or AI summary.
Describe each consequential output: an appointment time, escalation message, care-plan revision or record export. Identify who relies on it, how they verify it and what happens if it is late or incorrect. Separate administrative convenience from functions that could affect care.
Use synthetic records during design. Real patient data should not be the default material for prototypes, demonstrations or development environments.
Turn permissions into testable cases
Role names are only the beginning. A nurse's access may depend on the assigned care team, organisation, location, record type and time. A patient may have a representative whose authority changes. A contractor's access may need to expire.
| Action | Question to settle | Example control to test |
|---|---|---|
| View a record | Which relationship grants access? | Assigned team can read; unrelated team receives a denial |
| Amend a care note | Can the original be overwritten? | Record an attributed amendment and preserve relevant history |
| Export records | Who may export which fields? | Authorised scope, explicit action and audit entry |
| Access urgent information | Is an exceptional access path needed? | Restricted override with reason and review, if approved by policy |
| Act for another person | How is authority verified and revoked? | Separate identities and dated delegation |
These are requirements to agree with the operator, not a universal policy. Enforce them on the server and at every data access path, including downloads, search, exports and background jobs. Hiding a button does not protect the API behind it.
For an organisation-based product, apply tenant isolation as well as user permissions. A valid login to one clinic must not grant access to another clinic's files.
Distinguish authentication from consent and authority
Authentication establishes who is using the system. Authorisation decides what they can do. Consent and other grounds for processing require their own business and legal decisions; a successful login does not resolve them.
Record the source, scope and relevant dates of permissions or consent where the agreed workflow requires them. Design changes and revocation deliberately. A cached export, a previously issued file link and a third-party notification may continue to expose information after the interface changes unless their lifecycles are considered.
Minimise what goes into messages. A reminder can often tell the recipient to sign in rather than carrying a sensitive care note in an email, push notification or lock-screen preview.
Design an audit trail people can use
Application error logs and an audit trail have different jobs. An error log helps diagnose a failure; an audit record explains an important action, its actor, target, time and result.
Define which reads and writes need recording, how support staff investigate them and who can access the audit history. Store useful identifiers and outcomes without copying full sensitive records into every event. Protect the trail from ordinary application edits and define retention with the responsible advisers.
HL7 FHIR includes an AuditEvent resource for security and operational events. Using the resource format does not by itself make a log complete, trustworthy or compliant. Its value is an agreed representation when your integration partners use it.
Make downtime procedures part of the product
Set recovery objectives with the people running the service. How much recent work could be lost? How long can staff operate without the application? Which functions need an alternative process?
A routine appointment system might tolerate a different outage from a workflow used during active care. Do not select an uptime target solely because a hosting plan advertises it. Database recovery, identity-provider failure, messaging outages and staff access all affect whether work can continue.
Test restoring an encrypted backup into an isolated environment. Confirm the necessary keys, attachments, configuration and staff instructions are available. A database restore that leaves every document inaccessible is an incomplete recovery.
Document how staff record work during an outage and reconcile it later. Avoid a fallback that depends on the same unavailable identity provider or network path.
Treat offline changes as a reconciliation problem
Offline capture can help field staff, but it creates copies of sensitive data and conflicting edits. Decide which records are cached, on which devices, for how long and under whose control.
Use stable identifiers and version checks. If two staff members amend a care plan, automatically accepting the latest timestamp may discard a meaningful decision. Some conflicts need a visible comparison and authorised review.
Rehearse an expired login, lost device, interrupted upload and a revoked assignment while the device is offline. The right behaviour depends on the product's clinical and operational requirements. A generic sync library cannot decide those policies.
Integrate through explicit contracts
FHIR provides healthcare data-exchange models; it is not itself a security protocol. HL7's security guidance discusses the additional controls required around exchange. Confirm the version, implementation guide and terminology supported by each actual partner instead of promising generic “FHIR compatibility”.
Validate imported identifiers, units, timestamps and status values. Quarantine invalid records with an actionable error instead of silently dropping fields. Preserve provenance so staff know where information originated and when it was last reconciled.
Use authenticated, replay-safe integrations and observable retry behaviour. See reliable webhooks for the delivery mechanics.
Review the workflow with its actual users
Test keyboard navigation, labels, errors and readable contrast using an accessibility standard such as WCAG 2.2 alongside observation of real tasks. Include interrupted sessions and constrained devices, not only a quiet desktop demonstration.
Before implementation, produce a permission matrix, data inventory, critical-workflow map, audit specification and recovery exercise. These make scope and risk discussable. Apex's enterprise software team can work from that evidence to plan an application with the appropriate operational controls.