HIM 400 Module 7 Project Two Example

Project Two: Buying the Right Platform, a System Acquisition Proposal for Population Health at Cold Brook Health

[Student Name]

Southern New Hampshire University

HIM 400: Communication and Technologies II

Project Two

[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.

Project Two: Buying the Right Platform, a System Acquisition Proposal for Population Health at Cold Brook Health

Over this term, Cold Brook Health's informatics team rebuilt its diabetes registry as a relational database, wrote queries for outreach and research, found a two-year rise in poor diabetes control and built a model to predict missed appointments. Each piece worked, but each depended on an analyst running code by hand. Leadership now wants a population health platform that does this work continuously for diabetes, hypertension and depression. This proposal describes the need, the requirements, the options, the selection process and the recommended system, followed by an implementation plan.

Needs Assessment

Interviews with care managers, practice managers, the quality director and clinicians, plus a review of the earlier projects, identified five problems. Registry lists are a month old when they arrive. Outside lab results are missing for many patients. Trends are discovered late because no one watches them continuously. Care managers keep their own call lists in spreadsheets. And risk scores such as the no-show model cannot be displayed where schedulers work. A platform that fixes these problems must fit a system with 14 practices, about 40 clinicians and a two-person informatics team.

Requirements

Requirements were written as testable statements and divided into three groups. Functional requirements include registries for at least three conditions with rules the team can edit, daily care gap lists, outreach tracking, risk stratification that can accept Cold Brook's own models, dashboards with control charts and practice comparisons adjusted for size, and patient lists that open directly into the record. Technical requirements include a two-way interface with the current record system, intake of outside lab results from the statewide exchange, standards-based interfaces using HL7 FHIR, single sign-on and a vendor-hosted option. Security and privacy requirements include a business associate agreement, access limited by job role, logging of every record view, encryption of stored and transmitted data and the ability to segment substance use disorder records.

Options Considered

Three options met the basic requirements on paper. Option A is the population health module sold by Cold Brook's current record vendor. Option B is an independent platform that connects to many record systems and is known for strong analytics. Option C is an in-house build that extends the relational registry with a commercial business intelligence tool. Doing nothing was also considered and rejected, because the trend analysis showed that monthly manual reporting had missed a two-year decline.

Selection Process

The team issued a request for information to five vendors and a formal request for proposals to the two that met the requirements, while the in-house option was costed internally. Each vendor gave a scripted demonstration using de-identified Cold Brook scenarios, such as building a list of patients with no HbA1c in twelve months and showing the result inside the record, rather than a sales presentation of its choosing. Care managers and schedulers then completed tasks in each vendor's test environment.

The team added the hands-on test because vendor claims about ease of use are hard to verify. In a study of how eleven record vendors built usability into their products, Ratwani et al. (2015) found practices that differed widely, with some vendors testing with few or nonclinical users. Reference calls with two rural customers of each vendor completed the evaluation.

Weighted Scoring

The steering committee agreed on criteria and weights before any demonstration, so that impressions from the demos could not reshape the rules. Six evaluators, including two care managers, gave each option a rating between 1 and 5 for every criterion, and Table 1 shows the averaged results. Option A scored highest, mainly because it runs inside the existing record, which makes integration and usability for clinicians stronger. Option B offered the best analytics but required new interfaces and a separate login for clinicians. Option C scored lowest on functionality and vendor support, since two analysts would carry the whole system.

Table 1. Weighted Scoring of Options

Note. Scores averaged across six evaluators and rounded; composite data.

Total Cost of Ownership

The purchase price is only part of a system's cost. Adler-Milstein et al. (2013) modeled the finances of record adoption in community practices and found that many would lose money over five years, with results depending heavily on ongoing costs and how the practice used the system. The team therefore calculated five-year total cost of ownership, shown in Table 2, including subscriptions, implementation, interfaces, training and added internal staff. Option C looks cheapest, but nearly all of its cost is staff time, and it depends on two people remaining in their jobs.

Table 2. Five-Year Total Cost of Ownership

Note. Estimates from vendor proposals and internal costing; composite data.

Recommendation

The team recommends Option A. It scored highest overall, costs $288,000 less than Option B over five years and puts care gap lists and risk scores in the record where clinicians and schedulers already work. Its analytics are weaker than Option B's, so the contract should require the ability to load Cold Brook's own risk models and to export registry data to the team's statistical tools. Bates et al. (2014) argued that analytics add value when they help organizations identify high-risk patients and act on the information, which favors the option clinicians will actually use during visits.

Implementation Plan

The Module One interface project ran ten weeks late because it lacked a charter, a sponsor and change control. This plan starts with all three. The chief medical officer will sponsor the project, a steering committee will approve any change in scope and the charter will list diabetes, hypertension and depression registries as the only first-phase deliverables. Work will proceed in four phases over nine months: contracting and build, a pilot in three practices, a system-wide rollout and optimization.

Cresswell et al. (2013) emphasize that large technology efforts need attention to users and organizational change long after launch, and Sittig and Singh (2010) show that software, workflow, people and policy must change together. The plan therefore includes workflow redesign for care managers and schedulers before build, super-users in every practice, a risk register reviewed every two weeks and an optimization phase funded in advance rather than hoped for.

Measuring Success

Success will be judged at twelve months against the problems that started the project: care gap lists refreshed daily instead of monthly, outside HbA1c results present for at least 90% of patients who use outside labs, care managers working from the platform rather than spreadsheets, and the poor control trend monitored on a monthly control chart. The steering committee will also track clinician use of the in-record lists and the share of flagged appointments that receive outreach.

Conclusion

Cold Brook's analysts proved over the term that the data could answer important questions. The purpose of this acquisition is to make those answers routine. A structured process of requirements, scripted demonstrations, usability testing, weights set in advance and five-year costs led to a clear choice, and an implementation plan built on the lessons of a late project gives that choice its best chance to work.

References

Adler-Milstein, J., Green, C. E., & Bates, D. W. (2013). A survey analysis suggests that electronic health records will yield revenue gains for some practices and losses for many. Health Affairs, 32(3), 562-570. https://doi.org/10.1377/hlthaff.2012.0306

Bates, D. W., Saria, S., Ohno-Machado, L., Shah, A., & Escobar, G. (2014). Big data in health care: Using analytics to identify and manage high-risk and high-cost patients. Health Affairs, 33(7), 1123-1131. https://doi.org/10.1377/hlthaff.2014.0041

Cresswell, K. M., Bates, D. W., & Sheikh, A. (2013). Ten key considerations for the successful implementation and adoption of large-scale health information technology. Journal of the American Medical Informatics Association, 20(e1), e9-e13. https://doi.org/10.1136/amiajnl-2013-001684

Ratwani, R. M., Fairbanks, R. J., Hettinger, A. Z., & Benda, N. C. (2015). Electronic health record usability: Analysis of the user-centered design processes of eleven electronic health record vendors. Journal of the American Medical Informatics Association, 22(6), 1179-1182. https://doi.org/10.1093/jamia/ocv050

Sittig, D. F., & Singh, H. (2010). A new sociotechnical model for studying health information technology in complex adaptive healthcare systems. Quality and Safety in Health Care, 19(Suppl. 3), i68-i74. https://doi.org/10.1136/qshc.2010.042085