HIM 425 Module 3 Final Project Milestone One Example

Final Project Milestone One: An Unreliable Foundation and an Incomplete Record at Cedar Fork Community Health

[Student Name]

Southern New Hampshire University

HIM 425: Healthcare IT Infrastructure and Network Management

Final Project Milestone One

[Instructor Name]

[Date]

The organization, setting and figures below are a composite written as a model document. No real employer, client, colleague or patient is described.

Final Project Milestone One: An Unreliable Foundation and an Incomplete Record at Cedar Fork Community Health

Cedar Fork Community Health's leaders want to know how to prevent another six-hour outage like the one this spring. Before recommending anything, this milestone defines the problem precisely and analyzes it with evidence. A solution chosen without that step risks fixing the most visible symptom, a failed server, while leaving the underlying problems in place.

Problem Statement

Cedar Fork's clinical record is neither reliably available nor complete. It depends on one aging server with no redundancy, reaches two of its five clinics over a single shared wireless link that fails frequently, and it omits a meaningful share of clinical communication because patient phone messages are recorded in a separate messaging tool that does not feed the chart. As a result, clinicians lose access to the record during outages, video visits fail at the most rural sites and decisions made by phone are missing from the legal health record.

Evidence of the Problem

Table 1 summarizes the evidence gathered for this analysis from system logs, help desk tickets, the internet provider's outage reports and an audit of phone messages.

Table 1. Evidence Supporting the Problem Statement

Note. Data collected by the author for this milestone; composite organization.

Stakeholders

The problem affects patients first: those whose visits fail or whose phone conversations about symptoms and medications never reach their chart. Clinicians lose access to information and spend time re-creating it. Nurses and front-desk staff handle the messaging tool and the paper forms used during downtime. The health information team reconciles downtime documentation and answers for the completeness of the legal record. The contracted IT support provider maintains the server and network. Leadership and the board must fund any solution and answer to federal grant requirements for quality reporting, which depend on complete data.

Root Causes

Three root causes lie beneath the symptoms. The first is a design with single points of failure: one server, one storage array and one link to two clinics, with no backup path for any of them. The second is geography and market: the mountain counties where two clinics sit have limited broadband options, and the fixed wireless service was chosen years ago because it was the only one available. The third is a workflow that grew around a tool: the messaging tool was adopted before the current record system, staff became comfortable with it and nobody was assigned to move clinical messages into the chart.

Impacts

Each root cause has measurable effects. Outages stop care documentation at every site and create paper records that must be reconciled; after the spring outage, 11 notes were still missing a week later. Research shows such failures are growing more common; Sax et al. (2016) documented a rising frequency of IT blackouts in health care and called for formal emergency planning. The unreliable link limits access to care. Drake et al. (2019) found that telemedicine use was lower in rural areas with poor broadband access, and Cedar Fork's own data show nearly a third of video visits at the linked clinics failing or converting to phone. The messaging gap threatens both safety and the record: a clinician who advised a patient by phone to stop a medication left no trace in the chart that the next clinician would see.

How the Problems Interact

The three parts of the problem are not independent. If Cedar Fork moves its record to a vendor-hosted system to solve the server problem, every clinic will depend on its internet link, and the two clinics on the shared wireless link will lose the record whenever that link fails, which happened 14 times last year. Improving the link without addressing the server leaves all five clinics exposed to the next hardware failure. And moving phone messages into the record makes the record even more central to daily work, raising the cost of each outage. Any solution must therefore treat hosting, connectivity and messaging as one design problem rather than three purchases.

Constraints

Any solution must work within real limits. Capital funds are about $120,000 this fiscal year, with some flexibility through a federal grant for health center infrastructure. The IT support provider supplies eight hours of onsite time a month. Broadband options at the two remote clinics are limited, although a cellular carrier recently extended service to one of them. Staff already face heavy workloads. Murphy et al. (2016) found that primary care physicians received dozens of electronic inbox notifications per day, so simply routing 2,300 monthly phone messages into clinicians' record inboxes could shift the problem from missing documentation to overload.

Data Sources and Their Limits

The evidence has limits worth stating. Outage counts come from the provider's reports and may miss brief interruptions that staff never logged. The message audit sampled 200 messages from one month, and judging whether a message was clinically relevant involved the author's judgment, checked by a nurse manager on 40 of them. Video visit failures were identified from scheduling notes, which may undercount visits that simply ended early.

Requirements for a Solution

From the analysis, a solution must meet six requirements. It must remove single points of failure for the record so that one component's failure does not stop all clinics. It must provide at least two independent network paths to every clinic. It must support reliable video at every site. It must bring clinically relevant phone messages into the record in a way that routes them to the right person without overwhelming clinicians. It must include tested downtime and recovery procedures. And it must fit the budget and the support provider's capacity. Milestone Two will evaluate potential solutions against these requirements.

Conclusion

Cedar Fork's problem is not only a failing server. It is an infrastructure without redundancy, a network limited by rural geography and a record missing part of the clinical conversation. Defining the problem this way changes what counts as a solution: replacing the server alone would leave two clinics on a fragile link and phone decisions outside the chart.

References

Drake, C., Zhang, Y., Chaiyachati, K. H., & Polsky, D. (2019). The limitations of poor broadband internet access for telemedicine use in rural America: An observational study. Annals of Internal Medicine, 171(5), 382-384. https://doi.org/10.7326/M19-0283

Murphy, D. R., Meyer, A. N. D., Russo, E., Sittig, D. F., Wei, L., & Singh, H. (2016). The burden of inbox notifications in commercial electronic health records. JAMA Internal Medicine, 176(4), 559-560. https://doi.org/10.1001/jamainternmed.2016.0209

Sax, U., Lipprandt, M., & Röhrig, R. (2016). The rising frequency of IT blackouts indicates the increasing relevance of IT emergency concepts to ensure patient safety. Yearbook of Medical Informatics, 25(1), 130-137. https://doi.org/10.15265/IY-2016-038