HIS Implementation Plan: MHA-FPX5064 Assessment 3
High-level licenses you to skip the server specs, not the sequence — and a plan that would fit any hospital unedited is a methodology, not a plan.
Editorial process
Last reviewed · August 9, 2026
A plan, not a methodology
The word doing the most work in this brief is *high-level*, and it cuts both ways. It gives you permission not to specify server configurations or write training materials, which is a relief in four to six pages. What it does not give you is permission to be vague. A high-level plan is still a plan: it names the phases, says what has to be true before each one starts, identifies who owns them, and places them on a timeline. The failure mode is a document that describes implementation *in general* — planning, testing, training, go-live — without ever committing to a sequence or a duration for Vila Health specifically. If your plan could be handed to any hospital in the country without editing, it has described a methodology rather than produced a plan, and that is the distinction being assessed.
Notice that the decision itself is still open. The brief says Vila Health is considering *either* upgrading its current system *or* implementing a completely new one, and that you must be prepared for either. That is not an invitation to duck the choice. The stronger submissions state the criteria the decision should turn on — the age and vendor support status of the current system, whether required functionality can be added or only replaced, migration burden, total cost of ownership, disruption tolerance, and whether the acquisition runs something incompatible — then say which way they point on the simulation's evidence. A plan that works for either option without distinguishing them is usually a plan that is specific to neither. Say what you would do if the evidence is genuinely balanced as well, because recommending a structured evaluation with named criteria and a decision date is a defensible answer, and better than pretending to a certainty the simulation did not give you.
The brief lists what the chief operations officer actually wants, and it is worth reading as a checklist rather than as prose: each key step in developing the plan, a process and timeline to collect and analyse data, and report generation. Those requirements point at a document with phases and dates in it, not an essay about change. Build backwards from go-live. Decide when the system must be live, then work back through stabilisation, cutover, end-user training, integration and user acceptance testing, configuration and build, data migration and validation, contract and procurement, and requirements gathering. Working backwards exposes the constraint that actually determines feasibility — usually training capacity or the availability of clinical staff — far faster than working forwards from today does. Name the dependencies explicitly rather than implying them through order, since two phases printed one after another look sequential even when one could run in parallel, and parallelism is usually where a compressed timeline finds its slack.
Data migration is where these projects fail and where student plans are thinnest. Moving records from one system to another is not a technical formality: it raises decisions about how far back to convert, what to leave in a read-only archive, how to reconcile duplicate patient identities across systems, how coded data maps when the two systems use different value sets, and how you will *prove* the migration was faithful before you rely on it. Give it its own phase with its own validation step, and say who signs it off. Because Vila Health is a growing system absorbing new acquisitions, also say what happens to the acquired site's historical records, which is a question the brief's own framing raises and most answers never notice. Say what the read-only archive costs to maintain too, because leaving records behind is often presented as the cheap option when it commits the organisation to running a legacy system for as long as retention rules require.
Treat the human side as project scope rather than as a closing paragraph about resistance to change. Name the governance structure: an executive sponsor with authority to decide, a steering group, clinical champions in each affected department, and a defined escalation path for decisions that stall. Name the training approach and be realistic about its cost, since training a hospital's clinical staff is usually the single largest line in an implementation and the one most often compressed when the schedule slips. Say what support looks like in the first fortnight after go-live, when productivity reliably drops and confidence is either built or lost. And state the contingency: what triggers a rollback, and who is authorised to call it, because a plan with no failure path is not a plan a chief operations officer can approve. Say who covers the clinical work while staff are in training, because a training plan without backfill gets cancelled quietly by the departments expected to absorb it.
Finish with the things that make it a document rather than a narrative. Include an actual timeline — a table of phases with durations and dependencies is entirely acceptable at this level and communicates far better than paragraphs describing sequence. Include a risk register with a handful of genuine risks, their likelihood and impact, and the mitigation for each; vendor delay, insufficient testing time, clinician availability and data quality problems are all real here. Say how the project will be measured, since the brief asks about report generation and a project without defined reporting cannot be governed. Use the APA template supplied, and remember this assessment builds on your earlier work in the sequence, so referring back to what you established there is expected rather than repetitive. Say what the project will cost to run as well as to build, since a system carries a support and licensing bill that outlasts the implementation, and a plan stopping at go-live has costed only its first year.
Phase | What must be true before it starts | The risk if it is rushed |
|---|---|---|
Requirements gathering | Stakeholders identified and available | Building the wrong system correctly |
Upgrade-or-replace decision | Criteria agreed and costs known | A choice that cannot be defended later |
Procurement and contract | Requirements signed off | Scope disputes after money is committed |
Configuration and build | Workflows documented | Automating the current mess |
Data migration | Mapping agreed; archive scope decided | Silent data loss discovered after go-live |
Integration and UAT | Migrated data validated | Interface failures found by clinicians |
Training | System stable; staff released from duties | Go-live with staff who cannot use it |
Go-live and stabilisation | Support model and rollback trigger defined | No route back when it goes wrong |
Likely learning objectives
Inferred from the brief — check these against your own rubric.
- 01Produce a phased plan specific to one organisation rather than a generic methodology.
- 02State the criteria that decide between upgrading and replacing a system.
- 03Treat data migration as a phase with its own validation and sign-off.
- 04Build governance, training and contingency into project scope.
Read the full question
Review every instruction before using the planning guidance that follows.
What the implementation plan must contain
- 01A high-level implementation plan of 4-6 pages on the APA template.
- 02The key steps involved, in sequence.
- 03A process and timeline for collecting and analysing data.
- 04Report generation addressed.
- 05Criteria for the upgrade-versus-replace decision.
- 06Resource requirements identified.
- 07A risk register with mitigations.
From the upgrade decision to a rollback trigger
The decision before the plan
State the criteria for upgrading versus replacing and recommend one.
Phases, built backwards from go-live
Sequence the work and expose the binding constraint.
Data migration and validation
Set out conversion scope, identity reconciliation and proof of fidelity.
Governance, training and support
Name the sponsor, the champions, the training load and the first fortnight.
Risk, contingency and reporting
Register the risks, define rollback, and say how progress is reported.
Take your risks from the evidence, not from intuition
Recommended databases
- The Vila Health simulation
- PubMed Central
- Project Management Institute standards
- HIMSS implementation literature
Search sequence
- 1.Run the simulation and record the business needs and resource constraints it gives you, because your timeline has to be built on those rather than on generic durations.
- 2.Read a systematic review of hospital EHR implementations, since the recurring failure points are exactly what your risk register should contain.
- 3.Find evidence on what determines whether an implementation succeeds, so your governance and training sections rest on findings rather than on assertion.
- 4.Look for a documented case with a stated timeline, which gives you a defensible basis for the durations you assign to each phase.
What determines whether implementations succeed
These are authoritative starting points, not a ready-made bibliography. A qualified reviewer must confirm that each source fits the assignment and supports the claim beside which it is cited.
Nothing here is cleared for citation until you have read it.
- 01
Implementing electronic health records in hospitals: a systematic literature review
BMC Health Services Research · 2014
The core reference for this assessment, because it synthesises what actually determines success and failure across many hospital implementations. Use it to populate the risk register with evidenced risks rather than plausible ones.
- 02
Implementing Electronic Health Records in Primary Care Using the Theory of Change: Nigerian Case Study
JMIR Medical Informatics · 2022
A worked implementation with an explicit change framework behind it, which is useful when you need to justify your phase structure rather than assert it. Also a model for linking activities to intended outcomes.
- 03
Strengths, Weaknesses, Opportunities, and Threats (SWOT) Analysis of Hemodialysis Electronic Health Records
Cureus · 2024
Demonstrates a structured way to weigh an existing system against its replacement, which is exactly the upgrade-versus-replace judgement the brief leaves open. Useful as a method for the decision section.
- 04
Facilitators and Barriers to Implementing a Patient Portal at a Dental Hospital From the Implementers' Perspective
Journal of Medical Internet Research · 2025
Recent evidence from the people actually running an implementation, which supports the governance and training sections where student plans are usually weakest. Good for the post-go-live support argument.
Before the Assessment 3 plan is submitted
Common mistakes
- Writing a plan that would fit any hospital without editing.
- Treating 'high-level' as permission to omit sequence and duration.
- Avoiding the upgrade-versus-replace question the brief leaves open.
- Offering a plan that works for either option and is specific to neither.
- Presenting phases with no dependencies between them.
- Giving data migration a sentence instead of a phase.
- Never saying how migration fidelity would be proved before go-live.
- Ignoring the historical records of the newly acquired site.
- Reducing change management to a paragraph about resistance.
- Underestimating training, which is usually the largest line item.
- Providing no rollback trigger and no authority to call it.
Submission checklist
- Phases are named, sequenced and dated.
- Dependencies between phases are explicit.
- The upgrade-or-replace criteria are stated.
- A recommendation on that choice is made.
- Data migration has its own phase and validation step.
- The acquired site's historical records are addressed.
- An executive sponsor and governance structure are named.
- Training effort is estimated realistically.
- Post-go-live support is described.
- A rollback trigger and its owner are stated.
- A risk register with mitigations is included.
Use this guide to plan and review your own work. Follow your institution's rules and read our academic-integrity policy.
Written by
Aaron Bishop
MA, Education
assignment interpretation and research-methods coaching across disciplines
Aaron leads the EssayCrackers editorial desk. He works on how assignment briefs are read — what a rubric is actually asking for, and where students most often answer a different question than the one set.
Reviewed by
Dr. Nathan Cole
PhD, Rhetoric & Composition
Argumentation and thesis development
Nathan teaches first-year composition and directs a university writing center. He reviews EssayCrackers guides for argumentative soundness and citation accuracy.