OpenEvidence's partnership with Penn Medicine offers a concrete way to examine what international clinical AI implementation involves. The announcement, published on 15 September 2026, described access across Penn Medicine's US health system and work through the Botswana-UPenn Partnership to develop tools around regional clinical practice. It is a story about implementation, not simply a wider registration map. The partnership release is the primary source.
The distinction matters because opening an account and embedding a useful service in clinical work are different undertakings. The latter requires decisions about sources, professional roles, local workflows, evaluation and responsibility for updates.
This article separates what the release states from the implementation questions it creates. The proposed assessment framework is iatroX's analysis, not a claim that every element has already been delivered or evaluated by the partners.
Two settings, not one assumed deployment
The 15 September release describes Penn Medicine's more than 10,000 clinicians across its seven-hospital US system. It discusses bringing literature and electronic health record information into Penn's clinical workflow. The Botswana work is described through the Botswana-UPenn Partnership, with locally shaped tools and involvement from clinicians and partners in the region.
Those descriptions should not be collapsed into an assertion that the same electronic-record integration, information infrastructure or implementation exists in every setting. Nor should the US clinician figure be treated as the number of Botswana users or participants in an evaluation.
The release names collaboration with the University of Botswana and Botswana's Ministry of Health through the existing partnership. That is relevant institutional context. It does not, by itself, disclose who approves each product adaptation, what evaluation has been completed or which operational arrangements apply to a particular clinic.
A locally developed implementation needs those questions answered at the level of the actual use. The presence of respected institutions is a reason to examine the work carefully, not a substitute for examining it.
International access versus locally developed implementation
The following comparison is a general framework. It is not an assertion that the partnership has completed every implementation step in the right-hand column.
| Dimension | International access | Locally developed implementation |
|---|---|---|
| Starting question | Can an eligible user reach the service? | Can the service support a defined local task? |
| Sources | A collection is available to the user | Relevant sources, versions and local modifications are selected and maintained |
| Clinical context | The user can describe a setting | Important setting variables are deliberately represented and tested |
| Participation | Clinicians may provide feedback | Named participants influence design, approval and correction decisions |
| Evaluation | Accounts or usage can be counted | Performance and usefulness are assessed for specified tasks and users |
| Maintenance | The application remains available | Local content and responsibilities remain current as practice changes |
Access is not the lesser achievement. Without it, the rest may be impossible. The point is that the right-hand column describes additional work, not a benefit that automatically follows once access exists.
This distinction also changes what should be published. A launch account can accurately report participating organisations. A subsequent implementation report should describe the task, users, workflow, source arrangements and evidence supporting continued use.
Local clinicians should help define the problem
A team can ask local clinicians to review an almost-finished product, or it can involve them in deciding what the product needs to do. Those are materially different forms of participation.
Early involvement could identify the questions clinicians actually struggle to resolve. The difficulty might not be a rare diagnosis. It might be knowing which pathway applies, interpreting a recommendation when a test is not available through the usual route, or identifying who will act on a result.
A local clinician can also identify misleading assumptions in an otherwise plausible demonstration. A recommendation may assume a referral service that does not exist in that setting, a professional role with different responsibilities or a document that is not the approved local source.
The design question is therefore not simply "Is this answer medically reasonable?" It is "What would someone working here need to know before this answer could help?" That question should be asked before the interface and evaluation cases are fixed.
A fictional implementation workshop
Imagine a workshop for an outpatient service considering an evidence-search tool. The team chooses a common, non-emergency information need: identifying which document governs a routine referral and what information accompanies it.
The first demonstration retrieves a relevant national recommendation. A local clinician points out that the service's accepted referral route uses an additional approved document. An administrator identifies a contact route that changed recently. A patient representative explains why the wording used in the suggested patient information is difficult to understand.
None of those contributions changes the underlying research finding. Each changes whether the resulting workflow is usable.
The team could turn the discussion into a testable requirement: show the national source and the approved local pathway separately; do not infer current contact details from an old document; and label draft patient information as requiring review. A local reviewer could then approve or reject the implemented change against that requirement.
This is a proposed workshop exercise, not a description of a meeting held by Penn Medicine or its partners. Its purpose is to show the difference between collecting opinions and converting local expertise into accountable design decisions.
Ask who can change the product
Meaningful participation requires more than a channel for comments. A clinician needs to know how a reported problem reaches someone who can act on it.
An implementation plan could identify who selects priority use cases, who approves local source material, who resolves a disputed adaptation and who can suspend a problematic workflow while it is reviewed. It should also identify which decisions remain with the supplier and which belong to the participating organisation.
Patient and community involvement may identify issues that a technical or clinical team overlooks, including comprehensibility, access barriers and concerns about information use. The relevance of that involvement is consistent with WHO's January 2024 guidance, which calls for early, structured participation by stakeholders, including healthcare professionals and patients.
This does not mean every participant should approve every technical change. It means that the people affected should have an intelligible route to influence decisions within an explicitly defined scope.
Evaluation needs local questions and independent scrutiny
A useful evaluation would begin with the clinical tasks the implementation is intended to support. It should include ordinary questions, incomplete information, disagreement between sources and situations in which the local pathway cannot be established.
The assessors need relevant local expertise. An answer may be plausible to an external reviewer yet rely on an unavailable service or misinterpret a professional role. At the same time, familiarity with local practice should not prevent scrutiny of a local convention that conflicts with the source evidence.
The assessment should preserve both perspectives: fidelity to evidence and applicability to the setting. Where reasonable clinicians disagree, the disagreement should be recorded and investigated rather than erased by forcing a simple consensus score.
The DECIDE-AI reporting guideline, published in 2022, is useful background for reporting early clinical evaluation of AI decision support. It does not prescribe the partnership's study or validate the product. It reinforces the importance of describing the system and the human setting in which it is evaluated.
An implementation can change without a new model
A local policy revision, a new referral route or a change in service availability can make an earlier answer less useful even if the generating model remains unchanged. Maintaining the implementation therefore requires attention to more than model upgrades.
A practical arrangement could assign an owner to each local source collection and record when it was approved, reviewed or superseded. It could distinguish a temporary service interruption from a permanent pathway change. It could also test whether a withdrawn document continues to appear in answers.
These are proposed maintenance practices. Their value is that they make an otherwise vague promise of local adaptation operational. Someone can inspect whether a source has an owner and whether a known change was handled, instead of relying on a general assurance that the system is kept current.
Continuity matters as well. If a partnership changes, the local organisation should understand what happens to its guidance, configuration and authorised records. Sustainable implementation is a continuing responsibility, not only a launch event.
What clinician-reviewed should mean for iatroX
The same precision is needed when iatroX describes its educational material. Per iatroX product information, September 2026, its simulation cases are clinician-reviewed and used within structured practice and feedback workflows. That identifies a review activity, not an independent validation of every generated interaction.
A responsible account distinguishes review of the case content, assessment of the interaction and evidence about learner outcomes. It should not turn the first into proof of the other two. Clinician review also does not imply endorsement by an examining body.
For reference tools, iatroX's published methodology, checked on 23 September 2026, describes intended retrieval, ranking, grounding and uncertainty handling. The relevant question remains whether those processes produce useful, appropriately supported answers for the actual task.
This is the broader lesson from examining implementation rather than access alone. Local expertise is valuable when it changes requirements, tests and responsibilities in ways that can be inspected. The partnership announcement creates an opportunity to look for that evidence, not permission to assume it already exists.
Frequently asked questions
Does the Penn Medicine partnership mean the same system is deployed in Botswana?
The 15 September 2026 release describes US deployment and locally shaped work through the Botswana-UPenn Partnership. It does not establish an identical electronic-record integration or implementation in every setting.
What is the difference between international access and local implementation?
Access concerns whether an eligible user can use a service; implementation concerns whether it supports a defined task within the relevant sources, workflows and responsibilities. The latter requires additional design, evaluation and maintenance.
Does involvement from local clinicians prove a medical AI tool works well?
No: participation can improve the design and evaluation process, but performance still needs to be assessed. The useful question is how local contributors influence requirements, approvals, corrections and the evidence collected.
Explore practical clinical AI evaluation with iatroX Insights →