Project Profile: New Computing Model Helps Hamilton Health Sciences Address Changing Business Requirements
Bibliographic record
Abstract
This case study presents the impetus, business case, chronology and benefits of implementing a new server-based computing model at Hamilton Health Sciences that solved a critical desktop management problem while reducing IT costs.The new approach also provided a robust, flexible and scalable technology platform that is helping the hospital address business requirements driven by the emerging virtual healthcare community. Hamilton Health Sciences at a GlanceHamilton Health Sciences (HHS), which serves the more than 2.2 million residents of Hamilton, Central South and Central West Ontario, was formed through the merger of five hospitals and one cancer centre: Chedoke Hospital, Hamilton General Hospital, Henderson General Hospital, McMaster Children's Hospital, McMaster University Medical Centre, as well as the Juravinski Cancer Centre.Together, these facilities offer a range of acute and specialized services, catering to healthcare needs from preconception through to aging adults.This, in combination with its focus on academics and research, makes Hamilton Health Sciences the employer of choice for nearly 10,000 people.(www.hhsc.ca) Increasing Automation Strains IT ResourcesThe adoption of technology at HHS is now in high gear as decision-makers begin to see its full potential as a critical enabler for reducing cost, improving clinical and operational efficiency, attracting and retaining the best medical professionals and improving patient care and safety.As technology began to gain traction at HHS, however, the hospital's IT infrastructure and its Information & Communications Technology team (ICT) began to feel the strain.Growing pressure from users for more and better applications was a big challenge, for example.ICT, a group of 80 people that was already managing more than 100 servers, 5,000 PCs and 10,000 users, was facing a queue of 177 application requests.Worse yet, the demand from users to keep up with the latest versions of PC applications such as the Microsoft Office Suite, presented an almost insurmountable problem, requiring the continual upgrading of application and operating system software in 5,000 PCs, a huge, time-consuming and expensive undertaking, even with the help of advanced tools.With the growing number of users and PCs, the ICT budget would not be able to sustain this operating model. Server-Based Computing Offers Significant BenefitsRather than throwing more people and money at the escalating desktop management problem, ICT decided to look for a new computing model that would enable the group to keep desktop systems current, reduce ongoing operating and support costs, address growing requirements for user mobility and quickly, easily and cost-effectively realign the hospital's IT infrastructure to meet rapidly changing business requirements, including emerging regional, provincial and national e-health initiatives.A thorough analysis of the infrastructure supporting the hospital's current desktop implementation and a review of alternate approaches led to an investigation of how server-based computing (a.k.a."thin-client computing") could help ICT achieve these objectives.Server-based computing (SBC) simplifies the management and support of the desktop environment by moving applications and data off personal computers and onto corporate servers.While the look, feel and functionality of applications remains the same as perceived by the user, the user's PC becomes just a terminal device, passing keystrokes and mouse clicks up to, and displaying screen images sent down from, the applications running on the centralized corporate servers.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.002 | 0.002 |
| Meta-epidemiology (narrow) | 0.000 | 0.000 |
| Meta-epidemiology (broad) | 0.000 | 0.000 |
| Bibliometrics | 0.000 | 0.001 |
| Science and technology studies | 0.002 | 0.001 |
| Scholarly communication | 0.003 | 0.002 |
| Open science | 0.001 | 0.002 |
| Research integrity | 0.001 | 0.001 |
| Insufficient payload (model declined to judge) | 0.017 | 0.004 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".