MedPearl

The published account and the marketing account of this product describe different things, and the grade follows the published one.

The peer reviewed paper describing how the platform was built states plainly that all content and algorithms were built by clinicians in a proprietary environment requiring no code, and characterises the output as human authored algorithmic guidance. That is a content and logic asset produced by clinical experts, mapped against patient data drawn from the record. Remove any model and it remains intact, and it is what the published evaluation actually measured.

Company and trade material from the same period describes generative artificial intelligence being integrated into the platform and calls it an artificial intelligence enhanced clinical intelligence engine. Both accounts are the vendor's. Neither is reconciled with the other, and nothing published states what the generative layer does, which conditions or workflows it touches, or when it entered production.

Graded C on the mechanism that is documented rather than the one that is asserted. This is the moat is the dataset precedent with an enhancement layer of unstated scope on top. The grade should be revisited the moment the company describes the generative component, and a buyer should ask which of the two descriptions applies to the version they would be licensing.

The oversight of the content is documented in more detail than almost anything in this index, and the oversight of the artificial intelligence is not documented at all. That asymmetry is the finding.

On the content side: guidance is authored by clinicians and peer reviewed by specialists together with primary care and urgent care physicians. Development involved input from 270 clinicians, thousands of hours of clinician to engineer feedback, and direct observation of the tool being used in the clinical workflow. The product is positioned as presenting next best actions for a clinician to act on rather than as deciding anything, and the published pilot reports clinicians overriding the implied direction routinely, changing referral specialty or urgency in a fifth of cases and declining to refer at all in another fifth.

On the generative side there is nothing. No statement of what it produces, whether its output is reviewed the way authored content is, whether a clinician can tell which part of an answer was authored and which was generated, or what happens when it has no guidance to draw on.

Held at B for that reason. A product whose authored half is governed this carefully deserves to say the same about the other half, and the question to put is simple: does generated content pass the same clinical review as authored content, and can the clinician see the difference.

The authoring architecture is described with unusual clarity and the model architecture is not described at all.

What is published: content and algorithms built by clinicians in a proprietary environment requiring no code; a jobs to be done design framework; guidance mapped to patient data drawn from the record and presented alongside it; more than 730 conditions covered; a 95 percent success rate in matching a clinician's query to a relevant guide.

What is absent: any model class, provider, version or architecture for the generative component; any description of how retrieval or matching works beyond the headline match rate; and any evaluation of the generative layer separate from the platform as a whole.

The conflicting descriptions recorded on the centrality axis land here too. A buyer reading the peer reviewed paper would conclude there is no model in the product. A buyer reading the press would conclude generative artificial intelligence is central to it. Both are the vendor's own material and both are current enough to be in circulation. Establish which describes the shipping product before evaluating anything else.

One of the stronger evidence positions this index has recorded for a decision support product, and the limits are as clear as the strengths.

A peer reviewed paper in a clinical innovation journal reports operational outcomes across more than 4,000 active monthly clinician users, with statistically significant improvement in total productivity, in after hours time spent in the record, and in incremental margin per referral among heavy users. Reported usage at the time of publication was 6,967 clinicians and more than 189,000 point of care searches. A pilot of 216 participants conducting 14,000 searches produced specific behavioural findings: clinicians decided no referral was needed in 20 percent of cases, reported an improved care plan or workup in 72 percent, and changed the referral specialty or its urgency in 20 percent. Retention runs at roughly 75 percent month to month.

The authors published a disclosure stating that they work for the health system and were participating in commercialisation of the product. Publishing that alongside favourable results is a candour credit and this index records it as one.

Held at B on four honest limits. All of it comes from a single health system, which is also the developer. The authors are the developers. The outcomes are operational and economic rather than clinical, so nothing here measures whether patients did better. And the evaluation describes the human authored platform, predating or excluding the generative layer, so it does not evidence the component a buyer would now be buying.

One outcome measure deserves to be named rather than passed over. Incremental margin per referral is a revenue metric reported as a benefit, in a tool that decides whether a patient sees a specialist and which specialist. Reducing unnecessary referrals and increasing margin on the remainder can point the same way, and they can also diverge. Stated as structure, not as an accusation, and a buyer outside the developing system should ask how the guidance treats referrals that leave the network.

The architectural answer is the strong one. Patient data surfaced from the record is stated not to be stored in the product, so the platform reads the chart to contextualise guidance and retains nothing. This index tracks three answers to the stewardship question, and processing without retention is the second strongest of them, behind only carrying no patient data at all.

That is a genuine design decision rather than a policy assertion, and it is the second instance recorded in this index after Avo, which makes it a pattern worth asking every record integrated vendor about rather than a one off.

Held at B on what is not published. No retention period for anything the product does keep, no encryption practice, no data residency position, no subprocessor detail, and no statement about whether clinician queries are retained or used to improve the platform. The corporate privacy documentation was identified and not opened this pass.

The question that follows from the corporate transition is worth asking directly: if the product moves from a health system that is itself a covered entity to a standalone commercial entity, the stewardship arrangement changes even if the architecture does not.

No statement was located in two retrieval passes. No business associate agreement, no terms, no covered entity or business associate language, no execution path and no tier at which an agreement becomes available.

The practical position has so far been unusual and is about to change. The platform was built and deployed inside a single health system, so for its entire operating history the developer and the covered entity have been the same organisation and no external agreement was required. That is why nothing is published, and it is not evidence of a weak posture.

It is also why the question matters now. Commercialisation moves the product outside the walls it was built in, and an external customer will need an instrument that has never had to exist. A buyer should treat the absence as a gap to be filled during contracting rather than as a settled position, and should establish which entity would be the counterparty given the corporate transition recorded on this record.

Graded C on what a buyer can find today, with the reason for the absence stated so the grade is not misread as a finding about practice.

No certification was located in two retrieval passes: no SOC 2 report of either type, no ISO 27001, no HITRUST, no trust centre, no penetration testing statement and no vulnerability disclosure programme.

The same explanation applies as on the compliance axis. A platform built and run inside one health system inherits that organisation's security programme and has no external audience to publish attestations for. The controls almost certainly exist inside the health system's own governance; none of them belong to the product in a form a third party can request.

That position does not survive commercialisation. An external buyer cannot inherit a developer's internal controls, and the first thing a health system procurement office will ask for is a report that does not currently appear to exist in the product's name.

Recorded as a retrieval outcome. The specific ask is whether a security assessment has been completed for the standalone product as distinct from its host system.

No clearance, no submission and no published regulatory positioning statement were located.

The position is reasonable on the face of the product as documented. Guidance is human authored, presented for a clinician to act on, and drawn from a library the clinician can read, which keeps the basis independently reviewable. The published pilot shows clinicians departing from the implied path frequently, which is what adjunctive use looks like in practice rather than in a disclaimer.

One credential needs stating precisely so it is not misread. The founder has been appointed as an alternate to a federal digital health advisory committee. That is a recognition of an individual's expertise and it is a genuine one. It is not a regulatory status of the product, it confers nothing on the software, and it should never appear in a procurement discussion as though it does. This index applies the same rule to awards and to certifications held by parent companies.

Graded C because the vendor publishes no analysis of its own position, and because the undescribed generative layer makes that analysis harder to infer. A product that generates rather than retrieves a next best action is doing something different, and only the vendor can say which it does.

No artificial intelligence governance artefact was located: no published principles, no responsible use framework, no bias evaluation, no subgroup analysis, no error taxonomy and no evaluation methodology for the generative component.

Two real credits sit on the content side and are recorded as such rather than counted as artificial intelligence governance. Guidance is peer reviewed by specialists alongside primary and urgent care physicians before it reaches a clinician, which is a documented editorial control. And the authors of the published evaluation disclosed their employment and their participation in commercialising the product, which is the kind of disclosure this index asks for and rarely receives.

The bias question specific to this product is untouched and it is not the usual one. This platform decides whether a patient is referred to a specialist and how urgently. Referral is a gateway to specialist access, and access disparities in specialty care are well documented, so guidance that systematically discourages referral for particular presentations or populations would restrict access in a way that never appears in a productivity metric. Nothing published examines whether referral recommendations vary across patient groups, and the reported outcomes measure clinician time and margin rather than who got seen.

Integration is not a feature of this product, it is the product. Guidance is delivered inside the electronic health record and mapped against the individual patient's own data so that knowledge and patient context appear together on one screen, and that design is documented in a peer reviewed publication rather than asserted in marketing. Deployment ran system wide across a 51 hospital organisation with more than a thousand clinics, at a reported 7,000 clinicians and 30,000 searches a month.

That is deeper than most records in this index reach, and it is corroborated by outcome data showing reduced time spent in the record, which only makes sense for a tool operating inside it.

Held at B rather than A on sourcing and on what a new customer could actually verify. Availability in the dominant record vendor's marketplace is reported in third party coverage rather than announced on the company's own material, and this index weights a marketplace credential heavily precisely because the record vendor issues it. The current product website publishes no integration detail of any kind, no standard is named, and no second customer integration is evidenced. Confirm the current listing directly.

Delivered inside the electronic health record and through a mobile application, deployed at scale within a single large health system since mid 2022 and integrated system wide.

Depth of that one deployment is real and is credited on the integration axis. Breadth is the gap. No second customer is evidenced, no implementation timeline or effort is published, and no description exists of what deploying at an organisation that did not build the platform would involve, which is the question every prospective buyer has.

No hosting provider, cloud region, data residency position or retention statement was located, and no alternative deployment model is described.

The corporate transition compounds this rather than sitting beside it. A platform moving out of the organisation that built it changes who operates it, where it runs and under whose agreements, and none of that is currently published. Establish the operating entity, the hosting arrangement and the support model before any pilot.

Nothing is published. No price, no tier structure, no pricing basis, no implementation fee and no trial or pilot route were located in two retrieval passes.

The current product website is a single page carrying a positioning sentence, a statement that the platform has been proven at the health system that built it, and a contact form. There are no product pages, no documentation, no integration detail, no security material and no case studies beyond the one publication. For a product with a peer reviewed evaluation and several years of production use behind it, that is a strikingly thin public surface, and it reads as a company in transition rather than one that is hiding something.

One indirect commercial signal is worth recording because it points at how value will be argued rather than at what it costs. The published evaluation reports incremental margin per referral among heavy users, which suggests the commercial case to a health system will be made on referral capture and specialty utilisation rather than on a licence fee comparison. A buyer should ask for that model explicitly, including which referrals it counts and whether the projected margin depends on referrals staying inside the buyer's own network.

Scope is deliberately narrow and well matched to the problem. The setting is ambulatory primary and urgent care, the moment is the decision about whether and how to involve a specialist, and coverage runs to more than 730 conditions with referral guidance spanning the specialties a primary care clinician routes to. The audience is physicians, advanced practice providers and other care team members.

That focus is the product's strength rather than a limitation, and the published outcomes are consistent with it: the measured benefit is in referral quality and clinician time, not in breadth of clinical coverage.

Held at C because the axis measures coverage and this is one care setting, one workflow moment and one deployment. Nothing addresses inpatient use, emergency medicine, or specialist to specialist transitions. No geographic scope is stated. And all demonstrated usefulness comes from a single organisation in one region, so a buyer with a different referral network structure, payer mix or specialist supply should expect the guidance to need adaptation rather than assuming portability.