ShareMedical Announces MediLine Engine, a “Medical AI Harness” for the Safe Execution of AI in Healthcare
— Rather than limiting what AI is capable of, MediLine Engine structurally controls what AI is permitted to do, providing a shared foundation for safely connecting generative AI with electronic medical records and healthcare systems —
ShareMedical Inc. (Chiyoda-ku, Tokyo; President and CEO: Yoshimasa Mine), a healthcare ICT company, today announced MediLine Engine, a medical AI platform designed to enable the safe and practical use of generative AI in clinical environments.
At the core of MediLine Engine is a safety architecture that ShareMedical calls the “Medical AI Harness.” The capabilities of generative AI are advancing rapidly. In healthcare, however, simply deploying a “smarter AI” is not enough.
How much patient information may the AI access?
What level of medical inference is it permitted to perform?
Should the AI only make suggestions, or may it take actions within a system?
Is each task being handled only by AI models that possess the capabilities required for that task?
And does the actual output remain within the boundaries that were defined in advance?
These conditions cannot be left solely to individual prompts or to the judgment of the AI model itself.
ShareMedical therefore adopted the concept of a “Medical AI Harness”: an architecture that places safety constraints, execution controls, verification, and audit mechanisms outside the AI model itself.
Defining Where AI Can Work Safely, Rather Than “Restraining” AI
A harness is a mechanism designed to control power safely, such as horse tack or a safety harness. Similarly, the Medical AI Harness in MediLine Engine is not intended to make the AI itself more intelligent.
Instead, for a highly capable AI, it defines externally:
not “What can this AI do?” but “What is this AI permitted to do in this healthcare workflow?”
The AI is then executed within those defined boundaries.
MediLine Engine’s master architecture governs two distinct utilization paths—MCP and FaaP—through a common Medical AI Harness, supporting the safe connection, execution, verification, and auditing of AI and healthcare systems.
To execute medical AI safely, MediLine Engine combines multiple mechanisms: Constraints, Context, Verification, Evaluation, and Audit.
In healthcare in particular, ShareMedical believes it is not sufficient to inspect only the final AI output. It is important to maintain evidence that allows organizations to subsequently verify which policies were applied, which models, data, and tools were used, what decision path was followed, and how the resulting output was generated.
For this reason, Audit is positioned not merely as log storage, but as an independent capability supporting the entire Medical AI Harness.
“Capability ≠ Permission” — A More Capable AI Is Not Automatically Granted More Freedom
Capability ≠ Permission
An AI model may possess advanced medical reasoning capabilities, but that alone does not mean it should be free to generate diagnoses, prognostic predictions, or treatment recommendations.
MediLine Engine therefore defines a Minimum Capability Floor (MCF) for the capabilities required of the AI model, while each AI function is assigned an Inference Boundary defining the maximum scope of inference it is permitted to perform.
In other words, the architecture works in two directions:
Require a minimum level of capability from below, while constraining the permissible scope of inference from above.
An AI model that lacks the required capability is not allowed to execute the task.
At the same time, greater capability does not result in greater authority.
Rather than increasing an AI model’s freedom as its performance improves, MediLine Engine explicitly separates model capability from execution authority. This architecture is intended to preserve its safety structure even as more powerful AI models emerge in the future.
Safety Should Not Be Entrusted to Prompts
Many generative AI systems today express safety instructions in natural-language prompts, such as “Do not make a diagnosis” or “Do not infer information that is not present in the input.”
Prompts, however, are fundamentally one implementation mechanism for communicating tasks to an AI.
MediLine Engine instead adopts the following principle:
Safety should be specified as policy, compiled into execution constraints, and verified against outputs — not entrusted to prompts themselves.
Safety requirements are maintained as a structured Safety Policy and compiled into runtime constraints. The generated output is then verified to determine whether it has exceeded the permitted boundaries, while the entire process is recorded as evidence in an auditable form.
This creates a consistent safety execution lifecycle:
Policy → Compile → Execute → Verify → Audit
Defining Healthcare Workflows as “FaaP”
MediLine Engine adopts the concept of FaaP (Function-as-a-Product) as the unit for AI functionality.
FaaP is not simply a prompt or a wrapper around an LLM API. Instead, it defines an individual healthcare workflow as an independent functional contract and executes it by appropriately combining LLMs, medical data, MCP Tools, RAG, search, rule engines, statistical processing, and other components.
A FaaP consists of four elements.
Functional Contract Defines what data the function receives, what it outputs, and what healthcare workflow it is responsible for.
Execution Pattern Defines whether the function is executed through explicit user action or invoked automatically in response to events such as opening an EMR screen or updating data, as well as the execution method to be used.
Safety Policy Defines the medical safety boundaries permitted for the AI, including Clinical Risk, Execution Authority, and Inference Boundary.
Performance Requirements Defines the responsiveness required by the healthcare
workflow, such as real-time processing during screen interaction, standard processing, or background processing.
Safety and performance are not treated as competing dimensions within a single score.
MediLine Engine instead follows the principle:
Safety defines the feasible set. Performance optimizes within it.
Only candidates that satisfy safety, authority, and minimum capability requirements enter the feasible execution set. Latency and cost are then optimized within that set.
The system does not make compensatory trade-offs such as lowering safety requirements because a model is faster, or using an underqualified model because it is less expensive.
AI Function Studio — Turning Healthcare Workflows into AI “Execution Contracts”
The development environment for creating FaaP functions is called AI Function Studio.
Developers do not need to begin by writing complex prompts, code, or model configurations.
Instead, they can start with the healthcare workflow they want to implement, for example:
“Summarize a patient’s medical record in five lines.”
“Check for interactions among prescribed medications.”
“Draft a referral letter.”
In AI Function Studio, users describe the healthcare workflow they want to implement in natural language and validate the results using sample data. Once completed, the function can be saved as a FaaP and embedded into a healthcare system.
Through an interactive design process, AI Function Studio structures not only the required inputs and outputs, but also execution conditions—for example, whether a function runs through explicit user action or is automatically triggered by events such as screen display or data updates.
For example, when implementing a function that “summarizes patient information in five lines when the medical record is opened,” the execution contract can specify that opening the screen triggers the function automatically and that a fast response is required.
However:
Automatic invocation does not imply autonomous execution authority.
Automatically invoking an AI summary when a medical record is opened does not mean the AI must also be granted authority to modify the electronic medical record.
Keeping such independent concepts from being collapsed into a single configuration value is another important design principle of MediLine Engine.
Integration-related information, including endpoint specifications, can be obtained through the “Download Specification” function. The downloaded specification itself serves as implementation instructions and can be used directly with AI-assisted development approaches such as vibe coding to build applications or integrate the function into services.
Approximately 40 Medical Data and Tools Available as Standard Resources
MediLine Engine provides approximately 40 types of medical data and tools required for practical medical AI workflows.
These resources span both clinical and administrative domains, including drug information, package inserts, safety information, drug recall information, clinical guidelines, medical reimbursement information, claims checking, ICD-10, healthcare facility information, medical literature, and clinical research information.
For example, drug recall functions can utilize recall information published by Japan’s Pharmaceuticals and Medical Devices Agency (PMDA). Beginning in 2026, CSV data containing GTINs and applicable lot information has also become available, expanding the ways this information can be used within healthcare information systems.
Importantly, users do not need to select and connect each of these resources to the AI individually.
In AI Function Studio, users describe what they want to accomplish in natural language. The system then combines the data and tools required for that purpose to construct the AI function’s output.
For example, an AI function designed to “review prescriptions and identify safety considerations” may combine package inserts, safety information, interaction data, recall information, and other relevant resources rather than relying on drug information alone.
Similarly, a function designed to “identify potential billing issues from clinical documentation” may use tools related to medical reimbursement and claims checking.
The approximately 40 tools are therefore not merely “databases that AI can search.”
They are shared resources within MediLine Engine that allow medical AI to use necessary evidence and deterministic processing rather than relying solely on inference. They can be incorporated as components of FaaP (Function-as-a-Product) functions created through AI Function Studio.
Conceptually, the workflow is:
Describe the healthcare workflow → AI Function Studio configures the required tools, data, and execution method → MediLine Engine executes the function under defined safety conditions → The system returns output with the necessary supporting evidence
This environment is intended to allow healthcare professionals and healthcare system vendors to focus on designing the functionality required in clinical practice without having to manage the connection method for each individual API or data source.
LLM Intelligence Router — Selecting an AI That Meets the Requirements, Not Simply the “Smartest” AI
MediLine Engine incorporates an LLM Intelligence Router that enables different generative AI models to be used according to the requirements of each healthcare workflow.
The LLM Intelligence Router is not simply a mechanism for “selecting the highest-performing model.”
Models must first pass Hard Gates based on factors such as PHI handling, usage conditions, modality, and context length. Only models that meet the Minimum Capability Floor required for the target workflow and are executable under the applicable Safety Policy become candidates.
The execution model is then selected from those candidates based on factors such as required responsiveness and cost.
Once a model satisfies the required capability level, a higher-tier model is not automatically preferred merely because it is “more powerful.”
This reflects an approach in which medical AI routing is treated not as an AI performance ranking, but as an eligibility determination against the execution contract of each healthcare workflow.
The underlying technology is embodied in ShareMedical’s patent-pending technology, “Multiple Generative AI Utilization System and Program” (Japanese Patent Publication No. 2026-70499 / P2026-70499A), which the company positions as a core element of its medium- to long-term intellectual property strategy.
MCP and FaaP — Different Paths, One Medical AI Harness
MediLine Engine does not limit access to medical AI to a single integration method.
MCP provides a way for users to connect familiar AI clients such as ChatGPT and Claude to medical data and tools.
FaaP/API provides a way to embed AI functionality into electronic medical records, medical devices, healthcare systems, and proprietary applications.
Although these integration methods differ, MediLine Engine provides the common underlying layer for safety constraints, data access, model selection, verification, and auditing.
Rather than recreating guideline compliance and safety architecture separately for every AI client, electronic medical record system, or AI model, ShareMedical aims to provide medical AI execution control as a shared infrastructure layer.
Creating a Safe Path for “Shadow AI” Rather Than Simply Prohibiting It
As generative AI becomes more widespread, healthcare institutions increasingly face the challenge of “shadow AI”—the use of individually subscribed AI services by healthcare professionals in their work.
Simply prohibiting AI use altogether, however, risks losing the productivity gains and support for healthcare professionals that generative AI can provide.
ShareMedical believes that what is needed is not a mechanism that prevents people
from using AI, but rather:
a safe path that allows healthcare professionals and healthcare systems to use AI within explicitly permitted boundaries.
Even as models change and AI becomes increasingly capable, safety constraints remain outside the model.
That is the idea behind MediLine Engine’s “Medical AI Harness.”
Future Development
MediLine Engine is moving from a platform for research and proof-of-concept projects into the phase of real-world deployment in healthcare environments.
FaaP (Function-as-a-Product) functions defined on MediLine Engine are already being adopted by an electronic medical record vendor, and an AI-enabled electronic medical record incorporating FaaP-based AI functionality is scheduled for release in 2026.
Rather than introducing generative AI into healthcare as a standalone chat service, AI functions can be embedded directly into clinical and operational workflows with predefined safety and execution conditions, allowing medical AI to become a more natural part of everyday healthcare operations.
ShareMedical also plans to gradually make the AI Function Studio, which is currently under development, more broadly available.
The company envisions an environment in which users can describe what they want to achieve in natural language, validate results with sample data, design AI functions with appropriate safety conditions and execution methods, and embed those functions into existing healthcare systems as FaaP—without requiring specialized AI development expertise.
ShareMedical’s goal is not simply to “make generative AI usable in healthcare.”
The company aims to transform medical AI development—which has historically been accessible primarily to organizations with AI engineers or large development teams—into an environment where healthcare professionals, healthcare institutions, electronic medical record vendors, and healthcare startups can safely turn their own challenges and business models into working solutions.
The ability to build medical AI should not belong only to a small group of technical specialists.
By providing safety as a shared infrastructure layer, ShareMedical aims to enable ideas originating in healthcare settings to be implemented by a much broader range of people.
Through MediLine Engine and AI Function Studio, ShareMedical seeks to democratize not AI technology itself, but the ability to create healthcare services.
ShareMedical welcomes inquiries regarding MediLine Engine demonstrations, MCP connectivity, embedding AI functionality into electronic medical records and healthcare systems using FaaP, as well as joint development and proof-of-concept projects.
MediLine Engine：https://mcp.mediline.jp
Comments