Resources
Buyer’s guide: how to evaluate a records system
A checklist you can use with any vendor, including us. Each question shows how AuroraMed answers today, including where the answer is “not yet”.
Six steps
Write your must-haves
Ten workflows you cannot live without. Mark each as daily, weekly or rare.
Ask for status, not slides
Built, simulated, planned or open, in writing.
Test failure
Ask what happens when the network, power or a server fails.
Test exit
Request a sample export before you sign.
Check the evidence
Independent reviews, references you can call, drill records.
Price the whole thing
Hardware, installation, support, interfaces, training and exit.
How to read status labels: In the pilot (v0.2.0, synthetic data) Simulated in the pilot Coming (Wave 2, rolling out) Designed, not yet built Open decision Not offered / no claim made Planned partner integration
Comparing approaches by category
We do not compare named products. These are typical trade-offs of each approach; individual products vary, so verify with any vendor.
| Approach | Where it tends to help | Where to probe | Where AuroraMed sits today |
|---|---|---|---|
| Paper and spreadsheets | No software cost; familiar to staff | Lost or unreadable records, no audit, hard to share safely, hard to search | Aims to replace them; today a synthetic-data pilot only, not for real records |
| Traditional on-premises suite | Local control; can run without the internet | Upfront and upgrade cost, in-house IT effort, dated interfaces, slower change | Design keeps a local primary database like this approach Designed, with a cloud replica; not built |
| Cloud-only subscription | Low upfront cost, vendor handles updates | Dependence on connectivity, data location, exit terms, price changes | The pilot is cloud-only today, with the weakness that implies; local-first is the design goal |
| Build or assemble your own | Fits exactly; no licence fee | Long build, security and safety work, staff turnover, no support | AuroraMed Packaging assembles configurations from a catalog, but is a vendor tool |
| Regional or government-provided system | Common records across facilities; no local cost | Fit to small-clinic workflows, local control, timeline | Not an alternative; interfaces to national systems are designed, not built |
The checklist
Safety and clinical fit
| Ask this | How AuroraMed answers today |
|---|---|
| Which of the workflows we use every day are actually built, and which are planned? | Ask for a status list, not a slide. Ours is here. |
| What happens to an urgent alert if the network fails? | Ask for the failure behaviour in writing. Ours: the pilot stops alerts; the on-site design continues locally and is not built. |
| Who confirms the meaning of emergency codes? | Codes are local. Ours are editable templates marked “confirm local meaning”. |
Security and privacy
| Ask this | How AuroraMed answers today |
|---|---|
| Is there an independent review, and can we read it? | Ours: none yet. Developer self-review and open findings are published. |
| How are staff prevented from browsing records? | Ask for audit, break-glass and review evidence. Ours: audit chain, VIP hiding and break-glass review in the pilot; anomaly detection designed. |
| Who can read our data, including the vendor’s staff? | Ours: the design says vendor administrators cannot decrypt patient columns; not built. In the pilot everything is synthetic. |
Data ownership and exit
| Ask this | How AuroraMed answers today |
|---|---|
| Can we get all our data out, in a standard format, and when? | Ours: portability is a design principle; export tooling is not built. Ask any vendor for a test export before you sign. |
| What happens if the vendor stops trading? | Ours: no escrow or continuity plan is published. The local-database-is-primary design reduces cloud dependence but is not built. |
Integration
| Ask this | How AuroraMed answers today |
|---|---|
| Which connections are live today, and at which customers? | Ours: none live. FHIR is planned; everything else is simulated or absent. |
| Who pays for each interface? | Ours: undecided. |
Operations
| Ask this | How AuroraMed answers today |
|---|---|
| What happens when the internet or power fails? | Ask for a drill record. Ours: no drills yet; the design has an on-site server, UPS and downtime reports. |
| Who supports us at 3 a.m.? | Ours: support tiers are undecided. |
| How are updates delivered and rolled back? | Ours: signed manifests today; rollback screen and staged rollout are not built. |
Cost and contract
| Ask this | How AuroraMed answers today |
|---|---|
| What is not in the price? | Ours: for small clinics installation and equipment are separate; support fee undecided. |
| What is the minimum term and exit fee? | Ours: not decided. |
| Can we try it with no patient data? | Ours: yes, on synthetic data. |
A note on “nobody gets fired for buying the big name”
Established suites have long track records, references and certifications that AuroraMed does not have and does not claim. The right question is not whether we are as proven as they are (we are not), but whether a small clinic, working with a candid early pilot, gets something that suits it better and can change course if it does not. The risk-reversal points below are how we try to make that safe.
Risk reversal, only where it is real
- Evaluate on synthetic data with no patient information, no payment and no installation.
- Ownership: the clinic is the system of record for its patients and the design forbids selling or secondary use of patient data. Contract wording is not yet written.
- Exit: standards-based export and a data-return procedure are design principles. Export tooling is not built and no exit guarantee exists yet.
- No production commitment: nothing is offered for real patient care until the open findings are closed and an independent review is done.
Questions
Should we choose AuroraMed today?
Can this checklist be used for other products?
Bring your list
Send us your questionnaire or your must-haves. We will answer honestly.