Why English Matters in STARE-HI Evaluations

Why English? • Digital evidence

A health-information system is never just a piece of software.

STARE-HI helps writers describe the technology, organisation, people, workflow, study methods and unexpected effects as one connected evaluation.

Why does English matter in health informatics? Because words connect technical behaviour with human work. A digital alert can fire exactly as designed yet interrupt a clinician at the wrong moment. An electronic record can improve access to information while increasing documentation burden. A telehealth service can extend reach while excluding people who lack devices, connectivity or confidence. Numbers alone cannot describe that system of effects.

The EQUATOR Network entry for STARE-HI identifies it as a statement for reporting evaluation studies in health informatics. The original 2009 statement set out the principles, and the later explanation and elaboration paper discusses 35 items with rationale and examples. The guidance covers quantitative, qualitative and mixed-method evaluations.

STARE-HI is not a badge of study quality and does not dictate one research design. Complete reporting can reveal a strong evaluation, a limited evaluation or an evaluation whose usefulness depends on context. That distinction is encouraging: students do not need to accept or reject a digital-health claim on first impression. They can ask whether the report gives enough information to understand what happened and why.

The practical search intent includes how to evaluate health technology, health informatics study reporting, why context matters in digital health and how to write about unexpected effects. These phrases point to one transferable skill: explaining a socio-technical system clearly enough that another reader can judge it.

The whole system story: technology, people, organisation and evidence

Health informatics evaluations sit at a busy intersection. The intervention has code, interfaces, hardware, data and configuration. The organisation has staffing, rules, leadership, time pressure and legacy systems. Users bring roles, expertise, habits, needs and concerns. The evaluation adds a design, measures, sampling decisions and an analytic framework. A useful report keeps these layers distinct while showing how they interact.

This is why context is not background decoration. If an alert appears after a decision has already been made, the timing explains its limited effect. If a dashboard is available only on a workstation away from the point of care, access explains low use. If training occurs during protected time in one institution but not another, implementation support may explain different outcomes. Each explanation depends on precise relational language: when, where, for whom, compared with what and under which conditions.

English also protects the difference between system performance and service performance. A model may have high technical accuracy while the overall service produces no improvement because recommendations are ignored, delayed or unsuitable. Conversely, a modest tool may help because it fits a well-designed workflow. The report must show which level an outcome belongs to.

Students can connect this to how arguments and evidence work. The claim is not simply “the app worked”. It is a structured proposition about a system, population, task, outcome, setting and period, supported by evidence collected through a stated method.

Twelve STARE-HI reporting clusters as communication problems

The official elaboration contains 35 items. To make the ideas usable for students, the discussion below groups them into twelve communication problems. The grouping is educational; researchers should consult the original checklist and elaboration when preparing a formal report.

1. Title, abstract and keywords

The first job is to make the intervention, setting, evaluation purpose and study design discoverable before the full paper is read. This sounds straightforward until the writer must decide which details are essential. STARE-HI encourages enough specificity for a reader to reconstruct the evaluation without burying the central question under an inventory of technical features.

A title that says only “an innovative digital solution” hides whether the study concerns decision support, records, telehealth, alerts or workflow. The abstract can then repeat benefits without naming the design, participants or limitations. The problem is linguistic as well as methodological: broad nouns collapse distinct entities, passive verbs hide who made decisions, and celebratory adjectives replace observable criteria. A stronger report names actors, actions, sequence and evidence source.

Name the system function, evaluation focus, setting and design with economical precision. Select keywords that connect the report to the vocabulary used by health informatics researchers and practitioners. This technique turns description into an auditable account. It also helps students plan before data collection, because a field that will be difficult to report later is often a field that has not yet been defined clearly enough.

For a reader, the practical test is to write a one-sentence reconstruction beginning, “In this setting, these participants used this version of the system for this task, and the evaluators examined these outcomes using this design.” If important blanks remain, the report needs closer reading or additional information.

2. Scientific background

The first job is to locate the informatics problem within existing evidence and distinguish a local inconvenience from a general knowledge gap. This sounds straightforward until the writer must decide which details are essential. STARE-HI encourages enough specificity for a reader to reconstruct the evaluation without burying the central question under an inventory of technical features.

A report may describe a new tool enthusiastically but never explain which earlier systems were tried, what they achieved or why another evaluation is necessary. The problem is linguistic as well as methodological: broad nouns collapse distinct entities, passive verbs hide who made decisions, and celebratory adjectives replace observable criteria. A stronger report names actors, actions, sequence and evidence source.

Use sources to build a short chain: known problem, previous response, remaining uncertainty, and the specific contribution of the present evaluation. This technique turns description into an auditable account. It also helps students plan before data collection, because a field that will be difficult to report later is often a field that has not yet been defined clearly enough.

3. Rationale and objectives

The first job is to state why the evaluation is being done and what questions it is designed to answer. This sounds straightforward until the writer must decide which details are essential. STARE-HI encourages enough specificity for a reader to reconstruct the evaluation without burying the central question under an inventory of technical features.

Words such as “impact”, “success” and “effectiveness” can contain many possible outcomes. If the objective shifts after results are seen, readers cannot separate planned questions from attractive findings. The problem is linguistic as well as methodological: broad nouns collapse distinct entities, passive verbs hide who made decisions, and celebratory adjectives replace observable criteria. A stronger report names actors, actions, sequence and evidence source.

Write primary and secondary objectives with named participants, system, outcome or experience, comparison where relevant, and time frame. Label exploratory questions honestly. This technique turns description into an auditable account. It also helps students plan before data collection, because a field that will be difficult to report later is often a field that has not yet been defined clearly enough.

4. Organisational setting

The first job is to describe the institution, service, unit, staffing, workflow and wider environment in which the intervention operates. This sounds straightforward until the writer must decide which details are essential. STARE-HI encourages enough specificity for a reader to reconstruct the evaluation without burying the central question under an inventory of technical features.

A reminder system that helps in a well-resourced specialist centre may behave differently in a busy community clinic. Without setting details, readers may attribute organisational advantages to the software. The problem is linguistic as well as methodological: broad nouns collapse distinct entities, passive verbs hide who made decisions, and celebratory adjectives replace observable criteria. A stronger report names actors, actions, sequence and evidence source.

Explain where work occurs, who performs it, what pressures matter and which surrounding policies or technologies support the intervention. This technique turns description into an auditable account. It also helps students plan before data collection, because a field that will be difficult to report later is often a field that has not yet been defined clearly enough.

5. System details and system in use

The first job is to separate the designed technology from the version, configuration and actual pattern of use during the evaluation. This sounds straightforward until the writer must decide which details are essential. STARE-HI encourages enough specificity for a reader to reconstruct the evaluation without burying the central question under an inventory of technical features.

A system name is not enough. Interfaces, defaults, integrations, training and local customisation may determine outcomes. A report may evaluate one version while readers imagine another. The problem is linguistic as well as methodological: broad nouns collapse distinct entities, passive verbs hide who made decisions, and celebratory adjectives replace observable criteria. A stronger report names actors, actions, sequence and evidence source.

Describe components, data flows, user roles, implementation history, release version and the difference between intended and observed use. This technique turns description into an auditable account. It also helps students plan before data collection, because a field that will be difficult to report later is often a field that has not yet been defined clearly enough.

6. Study design and theoretical background

The first job is to connect the evaluation question to the chosen quantitative, qualitative or mixed-method design and any theory guiding interpretation. This sounds straightforward until the writer must decide which details are essential. STARE-HI encourages enough specificity for a reader to reconstruct the evaluation without burying the central question under an inventory of technical features.

A before-after comparison may be presented as causal even when staffing, policy or seasonal workload also changed. A qualitative study may collect rich accounts but leave the analytic lens unstated. The problem is linguistic as well as methodological: broad nouns collapse distinct entities, passive verbs hide who made decisions, and celebratory adjectives replace observable criteria. A stronger report names actors, actions, sequence and evidence source.

Name the design, justify it, explain the theory or logic model, and acknowledge what the design can and cannot establish. This technique turns description into an auditable account. It also helps students plan before data collection, because a field that will be difficult to report later is often a field that has not yet been defined clearly enough.

7. Participants and study flow

The first job is to show who was eligible, who took part, who used the system, who contributed data and who left the study. This sounds straightforward until the writer must decide which details are essential. STARE-HI encourages enough specificity for a reader to reconstruct the evaluation without burying the central question under an inventory of technical features.

Terms such as “users” can collapse clinicians, administrators, patients and technical staff into one group. Attrition may remove precisely the people who struggled most. The problem is linguistic as well as methodological: broad nouns collapse distinct entities, passive verbs hide who made decisions, and celebratory adjectives replace observable criteria. A stronger report names actors, actions, sequence and evidence source.

Report eligibility, recruitment, consent, exposure, follow-up and analysis numbers separately for each relevant participant group. This technique turns description into an auditable account. It also helps students plan before data collection, because a field that will be difficult to report later is often a field that has not yet been defined clearly enough.

8. Outcome measures and evaluation criteria

The first job is to define success before reporting whether the intervention succeeded. This sounds straightforward until the writer must decide which details are essential. STARE-HI encourages enough specificity for a reader to reconstruct the evaluation without burying the central question under an inventory of technical features.

Faster completion, fewer errors, user satisfaction and patient outcomes are different constructs. A composite score or survey label can hide which components changed. The problem is linguistic as well as methodological: broad nouns collapse distinct entities, passive verbs hide who made decisions, and celebratory adjectives replace observable criteria. A stronger report names actors, actions, sequence and evidence source.

Define each measure, its timing, instrument, scoring, validity evidence and threshold. Distinguish process, technical, human, organisational and clinical outcomes. This technique turns description into an auditable account. It also helps students plan before data collection, because a field that will be difficult to report later is often a field that has not yet been defined clearly enough.

9. Data acquisition and analysis

The first job is to explain how logs, observations, interviews, surveys, records and other evidence were collected and interpreted. This sounds straightforward until the writer must decide which details are essential. STARE-HI encourages enough specificity for a reader to reconstruct the evaluation without burying the central question under an inventory of technical features.

System logs record clicks, not intentions. Interviews record accounts, not direct behaviour. Administrative data reflect coding and workflow rules. Treating these sources as interchangeable produces overconfident claims. The problem is linguistic as well as methodological: broad nouns collapse distinct entities, passive verbs hide who made decisions, and celebratory adjectives replace observable criteria. A stronger report names actors, actions, sequence and evidence source.

State who collected data, from where, under what conditions, using which instruments, and how quantitative or qualitative analyses transformed them. This technique turns description into an auditable account. It also helps students plan before data collection, because a field that will be difficult to report later is often a field that has not yet been defined clearly enough.

10. Results with unexpected observations

The first job is to report planned findings alongside failures, workarounds, side effects and surprising patterns. This sounds straightforward until the writer must decide which details are essential. STARE-HI encourages enough specificity for a reader to reconstruct the evaluation without burying the central question under an inventory of technical features.

Technology may reduce one task while creating alert fatigue, duplicated work or new inequities. If only intended outcomes appear, readers cannot see the intervention’s full effect on the work system. The problem is linguistic as well as methodological: broad nouns collapse distinct entities, passive verbs hide who made decisions, and celebratory adjectives replace observable criteria. A stronger report names actors, actions, sequence and evidence source.

Present results in the order of the questions, preserve denominators and uncertainty, and give unexpected observations enough context to be understood rather than dismissed. This technique turns description into an auditable account. It also helps students plan before data collection, because a field that will be difficult to report later is often a field that has not yet been defined clearly enough.

11. Discussion and interpretation

The first job is to connect findings to objectives, design limits, mechanisms and prior evidence without turning association into proof. This sounds straightforward until the writer must decide which details are essential. STARE-HI encourages enough specificity for a reader to reconstruct the evaluation without burying the central question under an inventory of technical features.

A favourable result may be credited entirely to the software even though training, leadership attention or concurrent workflow redesign contributed. The problem is linguistic as well as methodological: broad nouns collapse distinct entities, passive verbs hide who made decisions, and celebratory adjectives replace observable criteria. A stronger report names actors, actions, sequence and evidence source.

Separate result, interpretation and recommendation. Compare with prior studies, identify plausible mechanisms and alternatives, and scale the conclusion to the design. This technique turns description into an auditable account. It also helps students plan before data collection, because a field that will be difficult to report later is often a field that has not yet been defined clearly enough.

12. Generalisability and conclusion

The first job is to explain where, for whom and under what conditions the findings may be useful. This sounds straightforward until the writer must decide which details are essential. STARE-HI encourages enough specificity for a reader to reconstruct the evaluation without burying the central question under an inventory of technical features.

The word “scalable” can jump from one implementation to many settings without evidence about infrastructure, resources, regulation or language. The problem is linguistic as well as methodological: broad nouns collapse distinct entities, passive verbs hide who made decisions, and celebratory adjectives replace observable criteria. A stronger report names actors, actions, sequence and evidence source.

Name transferable functions and context-dependent features. End with a conclusion that answers the objective while preserving uncertainty and implementation conditions. This technique turns description into an auditable account. It also helps students plan before data collection, because a field that will be difficult to report later is often a field that has not yet been defined clearly enough.

Worked scenario: an electronic feedback tool for medication review

Consider a fictional hospital that introduces an electronic feedback tool. The tool compares medication records with prescribing rules and displays possible discrepancies. A headline says that discrepancies fell by 30%. STARE-HI prompts a richer account before the reader concludes that the software caused the improvement.

Step 1: place the intervention in workflow

Where does the alert appear? If it appears during order entry, it may influence the prescription. If it appears in a weekly audit dashboard, it may support later learning instead. Who receives it—a prescriber, pharmacist, nurse or quality team? Can the recipient act directly, or must another person approve the change? These details explain mechanism.

Step 2: define the system and comparator

Was the evaluated system a new installation, a configured module or an updated version? Did the comparison period use paper review, a different alert or no structured feedback? Were medication lists reconciled differently after implementation? A meaningful comparison describes both sides. “Before” and “after” are dates, not complete conditions.

Step 3: trace participants and data

The study may involve patients whose records are reviewed, clinicians who receive feedback and pharmacists who verify discrepancies. Each group has different eligibility and missingness. If only records with complete electronic history enter the analysis, the estimate may not represent patients with fragmented care. A clear flow description prevents the word “participants” from hiding several populations.

Step 4: inspect outcomes and unintended effects

A 30% reduction depends on the denominator and definition. Were discrepancies counted per patient, per medicine or per order? Did reviewers know the study period? Did the tool create false alerts, delays or workarounds? Perhaps severe discrepancies fell while low-risk alerts multiplied. Reporting unexpected observations does not weaken the study; it helps future users understand trade-offs.

Step 5: scale the conclusion

A cautious conclusion might say that the configured feedback tool was associated with fewer verified discrepancies in two wards during six months, alongside a rise in low-priority alerts. That sentence is less dramatic than “AI improves medication safety”, but far more useful. It tells the reader what was observed, where, for how long and with what countervailing effect.

Did You Know? The same software can be a different intervention in another setting

A student reporting studio: six documents, six audiences

1. The 80-word abstract

Write one sentence each for context, objective, method, principal result and limitation. Remove claims that cannot fit beside their evidence. This exercise reveals whether the study has a clear question or merely a collection of favourable observations.

Peer review prompt: ask a classmate to underline every actor, time marker, comparison and qualifier. If a key action has no actor or a result has no denominator, revise the sentence. This small language check often discovers a larger evidence problem.

2. The system card

Draw the user, task, input data, system action, output and next human decision. Under the diagram, describe version, configuration, integration and training in 120 words. The aim is functional clarity, not promotional language.

3. The context snapshot

Describe the organisation, unit, staffing, workload and existing workflow. Then identify three features that could change the result elsewhere. This turns the vague word “context” into transferable and non-transferable conditions.

4. The evidence table

Give each outcome a definition, timing, data source, denominator, analytic method and uncertainty statement. Add a column for what the measure cannot show. This prevents a technically convenient metric from being mistaken for the full objective.

5. The surprise log

Record unintended benefits, harms, workarounds, implementation failures and puzzling patterns. For each, distinguish direct observation from participant explanation. This protects unusual findings from disappearing during summary.

6. The conclusion ladder

Write three conclusions: a direct result, a mechanism interpretation and a recommendation. Label them separately. Then remove any causal verb unsupported by the design. The ladder makes the inferential step visible.

Advice for parents and teachers

Start with a familiar digital system rather than advanced clinical software: a school portal, appointment app or transport dashboard. Ask the learner to describe what the system is supposed to do, who uses it and what “success” would mean. Then introduce a complication such as low uptake, delayed data or a workaround. The conversation becomes an evaluation without requiring specialist coding knowledge.

Praise precise uncertainty. When a student says, “The result may reflect training as well as the tool,” the student is not being indecisive. They are recognising a plausible alternative explanation. Invite them to propose evidence that would distinguish the explanations. That next-step habit is more valuable than performing certainty.

For multilingual learners, allow initial mapping in the language in which the workflow is easiest to explain. Then translate key roles, actions and conditions into English. Compare where the translation becomes broader or narrower. This respects the learner’s full knowledge while strengthening the precision needed for shared academic communication.

Limits: what STARE-HI cannot do for the reader

It cannot choose the best evaluation design for a question.
It cannot make an unsuitable measure valid.
It cannot prove that a well-reported association is causal.
It cannot guarantee that another organisation will achieve the same outcome.
It cannot replace ethical, privacy, security or regulatory review.
It cannot turn completeness of reporting into an overall quality score.

These limits matter because checklists are tempting shortcuts. A reader should use STARE-HI to locate information, then apply design-specific appraisal. The EQUATOR guidance explicitly distinguishes reporting guidelines from design and quality-appraisal tools. Clear reporting makes critical appraisal possible; it is not the same thing as a favourable appraisal.

Frequently asked questions

What does STARE-HI stand for?

It is the Statement on Reporting of Evaluation Studies in Health Informatics. The acronym identifies guidance for writing reports about evaluations of health-information technologies and systems.

How many items are in the elaboration?

The 2013 explanation and elaboration paper discusses 35 STARE-HI items. They span title, abstract, keywords, introduction, study context, methods, results, discussion and conclusion.

Does STARE-HI apply only to randomised trials?

No. The guidance was developed for evaluation studies using quantitative, qualitative or mixed methods. The chosen design still needs its own appropriate reporting guidance where relevant.

Why are unexpected observations important?

Digital interventions can alter workload, communication, access, error pathways and behaviour in ways the original objectives did not predict. Reporting surprises helps others anticipate benefits, harms and implementation problems.

Is user satisfaction enough to show success?

No. Satisfaction is one possible outcome and must be measured clearly. A system can be liked without improving the intended process, or disliked while reducing errors. Multiple outcome levels may be needed.

What is the difference between a system and a system in use?

The designed system is its technical capability and configuration. The system in use includes how people actually interact with it, including partial adoption, shortcuts, workarounds and local routines.

Why does organisational context affect generalisability?

Staffing, resources, workflow, leadership, infrastructure and policy can enable or constrain the same technology. Readers need those details to judge whether another setting is sufficiently similar.

Can students use STARE-HI for non-health apps?

The formal guidance is for health informatics evaluations, but its questions about users, workflow, context, outcomes and unintended effects can inspire careful evaluation of other digital systems. Do not relabel that adaptation as formal STARE-HI compliance.

Does a complete STARE-HI report prove the study is high quality?

No. The elaboration states that adherence does not automatically imply good study quality. Completeness allows readers to judge trustworthiness, validity and generalisability more effectively.

How should a conclusion be worded?

Answer the stated objective, use a verb that matches the design, preserve the population, setting and time frame, mention important countervailing effects, and avoid generalising beyond the reported context.

Useful next reading

Read the original STARE-HI statement, the open explanation and elaboration, and the EQUATOR entry. Then strengthen source handling with eduKate’s guide to sources, attribution and verification and this academic-writing guide on structure, evidence, sources and clarity.

The optimistic lesson is that clearer reporting helps technology learn from experience. When a report names the setting, system, people, methods and surprises, future teams can see what to retain, what to adapt and what to test again. English becomes a bridge between technical performance and responsible human use.