Hospital Software: Buy, Configure or Commission a Custom System?
Compare hospital software procurement options through workflow demonstrations, integration evidence, migration, support and a practical evaluation worksheet.
Buy and configure an existing hospital software product when it supports the required service workflows and the integration, operating and commercial terms are acceptable. Consider a custom application or extension when an important gap remains after those options are examined. Replacing the whole system should be a deliberate choice, with migration, staff transition and operating responsibilities assessed alongside features. This guide addresses procurement and software delivery. It does not validate clinical functionality, establish regulatory compliance or recommend a medical workflow. Include the appropriate healthcare, privacy, security and legal reviewers in the actual decision.
Let’s plan your hospital software.
Talk through your requirements with Drema. We’ll help you clarify the scope, explore the trade-offs and plan the next steps for your project.
Separate the operational problem from the product category
“We need hospital software” could mean appointment administration, inpatient operations, billing, a patient interface or replacement of a core information system. Those are different scopes.
Start with a named service problem. For example, staff may be unable to see whether an appointment change reached another system. The first investigation should determine why that handoff fails, rather than assume a new hospital-wide platform is necessary.
Create an inventory of the systems already involved and which records they own. Record contractual or technical constraints that may limit an extension. Then compare the available approaches against the same agreed tasks.
Compare four procurement routes
| Approach | When to investigate it | Work that still needs an owner |
|---|---|---|
| Configure the existing product | The required workflow appears supported but setup or use is incomplete | Configuration, staff training and verification |
| Buy a different packaged product | A suitable product can cover the agreed operational scope | Migration, interfaces, transition and support |
| Build a focused extension | The core system works, but one important bounded workflow is missing | Interface ownership, exception handling and lifecycle support |
| Commission a broader custom system | Critical needs cannot be met credibly through the other routes | Full delivery, validation, operations and handover |
The table is a discussion aid, not a rule that one route suits every hospital. Keep evidence next to each conclusion. A planned vendor feature is not the same as a function available for acceptance testing.
Give vendors a common demonstration script
Use scenarios drawn from your own requirements. Start with administrative workflows if that is the scope, and have responsible staff validate the scenario and expected outcome.
An illustrative script for appointment administration might include:
- Create a booking using approved test data.
- Change its time or assigned service and confirm who is notified.
- Attempt a conflicting action from another authorised account.
- Check which system holds the final appointment status.
- Make a connection unavailable and inspect the unresolved state.
- Restore the connection and verify the agreed recovery result.
This is not a clinical test script. Add the separately reviewed clinical scenarios and validation process wherever the product's intended use requires them.
Ask staff to perform the tasks, rather than only watch a vendor presentation. Record any extra manual work needed to finish. A feature can exist in a catalogue while still failing to fit the local operating arrangement.
Investigate the integration evidence
List the interfaces, supported operations, data definitions, identifiers and responsible teams. Confirm access to documentation, a test environment and technical support before treating an integration as a known deliverable.
FHIR is a healthcare information-exchange standard published by HL7. A supplier's statement that it supports FHIR is the beginning of an interface discussion, not proof that your specific exchange works. Ask the parties to agree the applicable specification and demonstrate the required exchange.
Record what happens when a transfer is incomplete, duplicated or rejected. Who can correct it? What is visible to staff? How is the resolution verified? These operational questions belong in the proposal as well as the technical design.
Compare the transition as well as the destination
A replacement decision includes work before go-live. Identify records to migrate, source preparation, mapping, exception handling and the people authorised to approve the result. Explain what remains accessible in the previous system and under what arrangement.
Have the operator approve the service-continuity and fallback procedures. Verify training, support contacts, escalation and restoration responsibilities. Do not assume that a new product's launch plan can be copied from another organisation without review.
The healthcare software service overview provides a starting point for discussing scope. The existing hospital management feature checklist can help identify functions to investigate, but a feature list does not replace an end-to-end demonstration.
Use an evaluation worksheet without false precision
| Requirement | Required outcome | Evidence received | Unresolved work | Decision owner |
|---|---|---|---|---|
| Operational task | Staff can complete the agreed service step | Demonstration record | Training or configuration gaps | Operations lead |
| Interface | The correct record reaches the agreed system | Verified test result | Mapping or recovery gaps | Integration owner |
| Access | Permitted roles can perform only agreed actions | Role-based test evidence | Unresolved access rules | Appropriate reviewer |
| Migration | Included records pass agreed checks | Reconciliation and sample results | Exceptions awaiting decision | Data owner |
| Support | A defined incident has a clear response path | Support terms and exercise | External dependency gaps | Service owner |
Set the actual acceptance conditions with your team. There is no universal “80% feature fit” threshold that determines whether a hospital should commission software. A single critical gap may matter more than several optional features.
Make costs comparable
Compare licences or subscriptions, configuration, custom work, interfaces, migration, training, infrastructure, support and internal transition effort over the same chosen period. State the user counts, service volumes and commercial assumptions.
Keep unknown dependencies visible. If a system owner has not confirmed access to an interface, do not treat its implementation as a free or certain item. Agree how that uncertainty will be investigated before the procurement decision depends on it.
Questions buyers ask
Is a custom hospital system automatically more secure?
No. Evaluate the actual design, access controls, implementation, operating procedures and review evidence. The commercial model does not establish security or compliance.
Can we add a patient-facing app without replacing the core system?
Possibly. Confirm the required interfaces, record ownership and operating responsibilities. The app should not create an unexplained second source of truth.
What should stop a procurement decision?
Unresolved critical requirements, unverified dependencies and an unclear responsibility for transition are reasons to investigate further. Have the relevant decision owners determine which conditions must be resolved before commitment.
Prepare a credible procurement brief
Bring a service workflow, system inventory, critical acceptance scenarios and the names of the responsible reviewers. Use those inputs to discuss healthcare software delivery, including configuration and integration alternatives to a full replacement.