Choosing a hospital information system is one of the largest and least reversible investments a private hospital makes. Yet most hospital EHR vendor selection decisions are settled on the strength of product demonstrations, which is a weak test — every credible vendor demonstrates well.

This case study describes how BHS ran a structured discovery engagement for a private hospital in the Caribbean: converting real workflows into standardised demonstration scenarios, testing five HIS/EHR vendors against the same operating requirements, and separating what was proven from what was merely claimed.

It is written for hospital executives, finance leads, and clinical leaders preparing to buy who want a defensible basis for the decision before it is made. No system has been implemented yet, so the outcome described here is decision readiness, not operational results.

At a glance

• Client: a private hospital in the Caribbean preparing for a major HIS/EHR investment
• Problem: manual workflows, approximately three weeks to finalise a bill, and five vendors whose claims all looked equivalent
• What BHS did: workflow discovery, five scenario-based vendor demonstrations, evidence classification, cross-vendor analysis, prioritised risk register
• What changed: documented non-negotiables, comparable vendor evidence, vendor-specific verification questions, and a defined pathway to formal evaluation
• Status: discovery complete; formal evaluation, selection, and contracting still ahead

Client snapshot

A private hospital in the Caribbean. It runs its own admissions, clinical care, operating theatre, pharmacy, inventory, billing, insurance, finance, and administrative functions, while depending on a wider institutional environment for several shared systems and services.

Leadership was preparing to invest in a hospital information system and electronic health record. The goal was for patient information to move cleanly from admission through clinical care, pharmacy, inventory, and billing without the manual handoffs the organisation relies on today.

Situation: a major HIS purchase resting on manual workflows

The hospital was approaching a major HIS/EHR purchase while much of the work the system would need to support was still running on paper. The workflow assessment found patient records, logbooks, spreadsheets, charge sheets, and physical requisition books in active use, with billing information often generated separately from the clinical activity that produced it. Patient information was captured more than once in places, and sometimes failed to reach the next department at the moment it was needed.

The operational consequences were visible. Admission was targeted at roughly 15 minutes but could extend to 30 or 60 minutes when insurance details, bed assignment, or room readiness were incomplete. Bill finalisation was reported at approximately three weeks, with full financial closure sometimes taking around three months once the wider insurance and payment cycle was included — against a leadership objective of collecting within about 30 days of patient departure. Alongside this sat identified risks of duplicate charging and of paying for external services already covered elsewhere.

The deeper exposure was procurement risk. Every vendor in the market could credibly claim registration, clinical documentation, pharmacy, inventory, billing, reporting, and interoperability, which makes hospital EHR vendor selection unusually easy to get wrong. Selecting on the strength of a demonstration, without testing those claims against the hospital’s actual operating rules, exposed the organisation to buying a system that would need expensive rework after contract signature.

Objective: decision readiness before hospital EHR vendor selection

The engagement set out to give the hospital a defensible, evidence-based footing for its HIS/EHR decision before any selection was made.

Specifically, it aimed to establish what the future system genuinely had to do, which manual processes should be redesigned rather than simply digitised, which requirements were truly non-negotiable, and where vendor capability claims had and had not been proven against the organisation’s own workflows. The goal was decision readiness, not a vendor recommendation.

Scope: what the discovery included and excluded

Included

• Current-state workflow discovery across clinical, operational, finance, inventory, pharmacy, and administrative functions
• Conversion of workflows into structured demonstration scenarios
• Facilitation of standardised discovery demonstrations with five HIS/EHR vendors
• Classification and review of the evidence each vendor produced
• Cross-vendor analysis across patient flow, finance, clinical and pharmacy, inventory, integration, security, migration, and implementation
• Identification and prioritisation of open questions and risks
• Worked examples converting broad requirements into testable requirements
• Design of the formal evaluation stage that should follow

Explicitly excluded

• Formal scoring, ranking, or evaluation of vendors
• Vendor selection or recommendation
• Commercial negotiation or contracting
• Technical due diligence, integration design, or migration planning
• Implementation, configuration, or system delivery

Phasing

Workflow discovery → scenario design → five standardised vendor demonstrations → post-session evidence review → cross-vendor analysis and risk register → consolidated readout and next-stage design.

Approach: how the vendor discovery was run

We began with the work, not the software. A facilitated workshop brought together operational, clinical, finance, inventory, and administrative stakeholders to map the current patient journey and surface the bottlenecks, handoffs, workarounds, and priority outcomes that a new system would have to absorb. That session produced the raw material for everything that followed.

We then converted the hospital’s own workflows into five structured demonstration scenarios covering the major areas of its operation. This replaced the usual dynamic, in which vendors present the parts of their product they present best, with a common set of tasks derived from how the organisation actually works.

Five vendors were taken through the same structured process. Each was asked to show the same scenarios against the same requirements, which made the sessions comparable in a way that generic product demonstrations are not.

Evidence was classified as it was gathered. Each capability was recorded as Demonstrated (shown live), Stated (described but not shown), or Open (incomplete, dependent, or requiring follow-up), and, where it could be established, distinguished as standard functionality, configuration, or customisation. These statuses were deliberately not scores or rankings.

After the sessions, we reviewed the contemporaneous facilitator records against the demonstration transcripts, applying a stricter evidence standard than is possible in a live room. Findings were then compared across all vendors and all functional domains. Unresolved matters were converted into a prioritised Open-Question and Verification Register, organised by potential impact on safety, revenue integrity, integration feasibility, cost, workflow fit, and implementation risk.

Finally, we showed the hospital how the same discipline should carry forward: worked examples converting broad requirements into testable ones, and a designed evaluation framework for the formal stage that must precede selection.

Key decisions

We built the demonstrations around the hospital’s scenarios rather than accepting vendor-led presentations, because a standard sales demonstration answers the vendor’s question, not the client’s. Common scenarios were the only way to make five vendors comparable on the ground that mattered.

We separated “demonstrated” from “stated” from “open,” because a capability that exists in a product is not the same as a capability proven in the client’s workflow. Recording the difference at the point of observation prevented confident assumptions from hardening into requirements later.

We identified four non-negotiables from staff workflows rather than from a feature list, because these were the requirements where failure would be expensive or unsafe:

1. Clinical activity must feed billing without manual re-entry.
2. Patient and medication scanning must support administration, eMAR, and real-time billing.
3. Inventory must support automated stock management, reorder controls, and point-of-use activity.
4. The financial workflow must handle both local and US currency through billing, receivables, and the general ledger.

We treated general interoperability capability as insufficient, because confirming support for HL7, FHIR, or APIs establishes nothing about which systems will actually connect, what data will move, how patients will be matched, how failures will be handled, who owns each interface, what it costs, or who supports it after go-live. The same distinction was applied to multi-currency support, barcode medication administration, migration, security, and reporting.

We designed the next stage to reuse this evidence rather than restart, because repeating five broad demonstrations would spend the client’s time re-establishing what is already documented. Vendors should confirm or correct existing evidence, with further demonstrations focused only on material unresolved requirements.

Work completed: deliverables produced

• Workflow discovery workshop and current-state record
• Five structured scenario-based facilitator demonstration guides
• Completed vendor observation records for all five demonstrations
• Demonstration transcripts and recordings, reviewed post-session
• Five individual vendor demonstration summaries
• Consolidated discovery readout
• Appendix A — Per-vendor discovery snapshots
• Appendix B — Cross-vendor evidence matrix
• Appendix C — Open-Question and Verification Register
• Appendix D — Formal Evaluation Pack Outline
• Appendix E — Requirements Conversion Examples
• A designed next-stage evaluation pack specification comprising 12 distinct instruments, including a requirements catalogue, future-state scenario pack, vendor response workbook, technical and security questionnaire, interoperability schedule, implementation and migration questionnaire, pricing template, scorecard and decision rules, clarification register, focused validation pack, and traceability framework

Evidence of effectiveness: what the discovery surfaced

The discovery separated vendors that broad demonstrations had made look equivalent. At feature level, all five vendors could speak to registration, billing, pharmacy, inventory, reporting, and integration. Tested against the four non-negotiables, the evidence they produced was not equivalent, and the differences were documented rather than assumed.

A dual-currency constraint surfaced before it could become a contract problem. One vendor confirmed during discovery that its current product supports one configured currency at a time rather than simultaneous local and US dollar billing — a direct conflict with one of the hospital’s non-negotiables. Other vendors showed or described varying levels of multi-currency capability that still require detailed financial validation through receivables and the general ledger.

Medication safety claims were tested end to end rather than accepted at the screen. Several vendors showed relevant eMAR and barcode functionality. Discovery established that seeing an eMAR does not prove the complete workflow from physician order through pharmacy verification, patient scan, medication scan, inventory update, and real-time billing — and that is the workflow the hospital needs.

Integration moved from a standards conversation to a site-specific question. Every vendor could discuss interoperability. None produced a site-specific architecture, interface responsibility model, or support and cost structure, which is now a documented requirement of the formal evaluation stage rather than an assumption carried into contract.

Known revenue risks were converted into formal verification questions. Duplicate-charge prevention and reconciliation of services ordered but not rendered were escalated into the register precisely because the hospital had already identified them as live operational risks.

At the final readout, hospital leadership said the team appreciated the information received and believed it had seen enough to move from discovery into detailed requirements.

Outcome: what changed for the hospital

The hospital has not yet implemented a system, and this engagement makes no claim on billing speed, inventory accuracy, revenue, or patient experience. What changed is the quality of the decision the organisation is now in a position to make.

Before the engagement, the hospital held broad high-level requirements, a set of manual workflow problems, a desire for integration, and a collection of vendor claims — with no comparable basis for choosing between them. It now holds documented current-state findings, explicit non-negotiables derived from how staff actually work, five structured vendor evidence records, a clear line between what was demonstrated, what was merely stated, and what remains open, vendor-specific verification questions, a prioritised risk register, and a defined pathway to formal evaluation.

The most consequential shift was in the question the organisation is asking. It moved from “which vendor appears to have the features we need?” to “which proposed solution can meet our approved requirements, under defined operational, technical, commercial, implementation, and contractual conditions?” That is the question a defensible procurement decision has to answer.

What happens next: moving to formal evaluation

The evidence supports moving to a formal requirements and vendor evaluation stage before any selection decision is taken. That stage should validate and prioritise requirements, convert them into testable acceptance criteria, pre-populate vendor response packs with the evidence already gathered, and require each vendor to commit to the exact proposed solution — including standard functionality, configuration, customisation, dependencies, timing, and cost.

Focused validation should be used only where material uncertainty remains, alongside technical, integration, security, migration, and implementation due diligence, normalised commercial comparison, and agreed scoring rules and mandatory gates set before final responses are opened. The output should be an evidence-based decision package for the hospital’s selection authority.

Our role: what BHS owned and what the client owned

BHS owned the discovery process end to end: workshop facilitation, conversion of workflows into demonstration scenarios, facilitation of all five vendor sessions, evidence classification, post-session transcript review, cross-vendor analysis, the open-question and risk register, the requirements conversion examples, and the design of the formal evaluation stage.

The hospital owned its requirements, stakeholder participation, and all decision authority. Clinical, operational, finance, inventory, and administrative staff supplied the current-state detail that made the scenarios credible. Vendors owned their own demonstrations and the claims recorded against them.

Selection, negotiation, and contracting remain with the hospital, supported by an evidence base built for exactly that purpose.

Common questions about hospital EHR vendor selection

What is EHR discovery, and how is it different from vendor evaluation?

Discovery establishes what the organisation actually needs and what vendors can genuinely show against those needs. Evaluation scores and ranks vendors against approved requirements, then supports a selection decision. Discovery comes first, and this engagement stopped deliberately at that boundary: no scoring, ranking, or recommendation was produced.

Why isn’t a feature checklist enough for hospital EHR vendor selection?

At feature level, most mature hospital systems can claim registration, billing, pharmacy, inventory, reporting, and integration. Meaningful differences only appear when a vendor has to execute the buyer’s exact workflow, including exceptions and control requirements. A checklist records the claim; a scenario tests it.

What does it mean to classify vendor evidence as demonstrated, stated, or open?

Demonstrated means the capability was shown live. Stated means the vendor described it but did not show it. Open means the matter was incomplete, dependent on something else, or needed follow-up. Keeping the three apart prevents a sales assurance from being carried forward as a confirmed requirement.

What should a hospital ask vendors about integration and interoperability?

Confirming support for HL7, FHIR, or APIs establishes very little on its own. Ask which specific systems will connect, what data moves in each direction, how patient records will be matched, how interface failures are detected and handled, who builds and owns each interface, what it costs, and who supports it after go-live.

Should manual workflows be fixed before selecting an EHR?

Some should be. Digitising a broken process preserves the fault at higher cost, so part of discovery is deciding which manual processes need redesign rather than automation. That distinction has to be made before requirements are finalised, not after a contract is signed.

Preparing for an HIS or EHR purchase? The questions worth answering are the ones a demonstration will not raise on its own. Book a short introductory call to discuss what your organisation should establish before selection.