OpenMed founder Maziyar Panahi's portable skills cover de-identification, entity extraction and FHIR export; deployers still own privacy controls and clinical review.
By [RuntimeWire Staff](https://runtimewire.com/author/runtimewire-staff)
· Published
Primary source: [X](https://x.com/OpenMed_AI/status/2104239653037694999)
Why it matters #
OpenMed is making healthcare-data workflows easier for coding agents to reproduce, but its documentation correctly leaves privacy, clinical validation and deployment decisions with the teams using them.
OpenMed founder Maziyar Panahi has turned clinical-data procedures into portable skills that coding agents can load and inspect. The package aims to make common healthcare software tasks easier to build without asking an agent to make clinical judgments. The release landed on August 21st.
The skills cover workflows including clinical de-identification, entity extraction, FHIR export and leakage checks. They are Markdown instruction folders, each centered on a SKILL.md; they do not include a new clinical model or standalone agent. OpenMed says compatible coding tools can use the same files, including Claude Code, OpenAI Codex and OpenCode. The current catalog lists 73 skills across 14 categories, extending beyond OpenMed's core functions into data ingestion, deployment and evaluation.
For Panahi, the package extends a project built around a specific deployment premise: healthcare developers should be able to run clinical-language tooling locally and inspect the steps that shape its output. His public biography says he spent seven years leading Spark NLP at John Snow Labs before starting OpenMed, and describes earlier research and infrastructure roles at the University of Malaya and Telekom Malaysia. The skills focus on wiring established data operations into software. They assign no clinical judgment to the coding agent.
Procedures agents can read
The instructions translate requests such as "de-identify this dataset" or "export these entities to FHIR" into repeatable coding tasks. OpenMed's agent guide shows how a coding agent can combine de-identification and entity extraction in a local pipeline, using synthetic text in its example. The repository offers an installer for multiple agent hosts and instructions for placing skills in each host's expected directory.
The packaging gives developers a reusable place to keep domain-specific instructions for coding agents working on healthcare-data pipelines. A reusable procedure can give the agent a shared recipe and point it toward OpenMed's APIs. It also makes the recipe visible to a human reviewer, who can read or modify the instructions instead of treating the workflow as an opaque model response. The skills remain guidance; they do not turn the underlying agent into a constrained clinical system.
OpenMed's documentation draws that boundary explicitly. It describes de-identification as a technical control, not a guarantee of privacy compliance or an automated clinical decision, and says clinical outputs need qualified review. The project's validation documentation says its catalog checks matters such as frontmatter, file structure, links and whether executable helpers respond to --help in an offline environment. Those checks help keep the package orderly and reproducible; they do not establish that a model catches every identifier or that a workflow is clinically fit for a particular hospital.
Local code does not make every agent interaction local
The privacy boundary is the hard part. OpenMed's agent guide says model inference can run locally after an initial model download, and warns developers to keep real protected health information out of cloud-agent prompts, logs and copied examples. A skill may guide code that runs on a user's machine while the coding agent interpreting the request still relies on a hosted model. Installing a local workflow does not, by itself, make every step local.
OpenMed's design notes make the same distinction in practical terms: deployments must validate model behavior and privacy for their particular data and use case, and using the SDK does not itself establish HIPAA compliance. The skills can help developers follow repeatable steps, but responsibility for choosing a model, controlling prompts and logs, checking leakage and reviewing results stays with the people operating the system.
Panahi's background at John Snow Labs gives him a direct line to the healthcare NLP problems OpenMed is trying to make easier to handle. The strategic bet is that open, inspectable procedures can bring that domain knowledge into everyday coding-agent workflows without requiring each developer to invent a fresh integration pattern. Teams will need to verify resulting pipelines against their own clinical data, infrastructure and privacy requirements to judge the package's usefulness. The documentation sets that bar; it does not claim to clear it for them.