MACH
Health Uyari
- License — License: Apache-2.0
- Description — Repository has a description
- Active repo — Last push 0 days ago
- Low visibility — Only 5 GitHub stars
Code Gecti
- Code scan — Scanned 12 files during light audit, no dangerous patterns found
Permissions Gecti
- Permissions — No dangerous permissions requested
Bu listing icin henuz AI raporu yok.
Machine-Actionable Catalog for Healthcare
MACH — Machine-Actionable Catalog for Healthcare
An open, machine-actionable catalog of open-source healthcare software, AI/ML models, clinical standards, datasets, and MCP servers — curated for humans, queryable by agents.
Every entry is a structured JSON-LD record aligned with established open metadata standards (CodeMeta, MLDCAT-AP, DCAT-AP, Croissant), so hospitals, researchers, governments, and AI agents can discover and consume the open healthcare commons.
Project status: Active — CI pipeline live. A project of FORSE-H.
Why MACH?
The open healthcare technology ecosystem is fragmented across hundreds of repositories, blog posts, and HuggingFace model cards — none of which is structured for agent discovery or aligned with open metadata standards.
MACH fills that gap:
- Structured, evidence-backed entries — every entry includes a curated rationale, clinical domain tags, deployment context, and at least one live evidence URL
- Three-ring editorial judgement — Adopt / Assess / Caution, data-driven and explained, adapted from the ThoughtWorks Technology Radar
- Machine-readable exports — MLDCAT-AP 3.0, CodeMeta 3.0, DCAT-AP, Croissant, llms.txt
- FAIR alignment — stable entry URIs, DOI-archived on Zenodo, ORCID-attributed
- Agent-native — MCP server and FAIR Data Point RDF/SPARQL endpoint (Phase 2)
Why open source in healthcare?
Open source enables transparency, reuse, and collaborative improvement. These principles matter everywhere, but are especially critical in healthcare, where the cost of opacity is borne by patients and health systems, not vendors.
UK Government (DSIT/GDS, 2026) · AI, open code and vulnerability risk in the public sector: Recommends "open by default" even in an AI-accelerated threat landscape. Closing source does not remove vulnerabilities. It removes the external scrutiny that helps find and fix them.
Ibrahim Haddad, LF AI & Data Foundation (2026) · Governing Our Digital Future: Every Government Needs an Open Source Program Office: Open source redistributes cost from vendor licensing to internal capability. Without deliberate governance, those costs accumulate as security and operational risk.
Adler-Milstein, Murray & Wachter, JAMA (2026) · The Market Dynamics for Third-Party AI Tools Trying to Compete With Electronic Health Record Developers: 79% of hospitals use AI tools bundled by their EHR vendor, even when third-party alternatives are superior. Structural lock-in — not clinical evidence — drives adoption. Open standards and open-source alternatives are the primary counterweight.
Leupen & Van Poll, Het Financieele Dagblad (2026) · Hoe een vader en zoon buiten de schijnwerpers een software-imperium bouwden (paywalled, Dutch): ChipSoft — a secretive family-owned company — controls the EHR systems of most Dutch hospitals, with no governance guarantees, no public accountability, and a ransomware attack that cost €3–5M. Hospitals have no viable alternative. The article ends with a hospital CIO asking: "Why don't hospitals organise themselves?" — the answer is what MACH is building toward.
Who is MACH for?
| Audience | Use case |
|---|---|
| Hospitals & health systems | Evaluate open-source tools against structured criteria before procurement |
| Researchers & data scientists | Discover FAIR-aligned datasets, models, and pipelines with citable metadata |
| AI / agent developers | Query the catalog programmatically via JSON-LD, MCP server, or SPARQL |
| Governments & ministries | Identify open standards-compliant tooling for national digital health infrastructure |
Catalog categories
| Category | What it covers |
|---|---|
| Software | EHR/EMR, imaging tools, pipeline software, clinical systems |
| AI / ML Models | Clinical LLMs, imaging foundation models, NLP |
| Datasets | Benchmarks, clinical datasets, evaluation suites |
| MCP Servers | FHIR MCP, OMOP MCP, clinical AI interfaces |
| Data Sources | Public health APIs, open data portals, surveillance feeds |
| Catalogs | Other open healthcare catalogs and registries |
| Specs | Interoperability standards and specifications |
How to use the catalog
Browse the website:
Visit the GitHub Pages site for a searchable, filterable view of all entries.
Use the data programmatically:
All entries are JSON-LD files in entries/. Clone the repo or fetch individual entries directly:
# Clone
git clone https://github.com/FORSE-H/MACH
# Fetch a single entry
curl https://raw.githubusercontent.com/FORSE-H/MACH/main/entries/software/openmrs.jsonld
Entry structure:
Each entry is a JSON-LD file with fields from CodeMeta, MLDCAT-AP, and the MACH vocabulary:
{
"@context": "../../data/context/mach.jsonld",
"identifier": "openmrs",
"name": "OpenMRS",
"description": "...",
"url": "https://openmrs.org",
"license": "MPL-2.0",
"mach:judgement": "Adopt",
"mach:judgementReason": "...",
"mach:clinicalDomain": ["primary-care", "global-health"],
"mach:evidence": [...]
}
Vocabulary reference: data/context/mach.jsonld
Taxonomy reference: data/taxonomy/categories.yaml
How it works
GitHub Issue (suggest an entry)
│
▼ Maintainer approves → CI harvests from source systems
│
▼
DuckDB ← Catalog sources (Git · HuggingFace · arXiv · etc.)
│
├── Scoring (Adopt / Assess / Caution)
├── Validation
└── Draft PR → Maintainer reviews → Merges
│
▼
Catalog goes live
├── API (JSON-LD · REST · Phase 2)
├── GitHub Pages (searchable UI)
├── MCP server (Phase 2)
└── FDP / SPARQL endpoint (Phase 3)
Contributing
Suggest an entry via a GitHub Issue — fill in the template with a name and source URL. The CI pipeline handles harvesting and metadata enrichment; a curator reviews before anything goes live.
Prerequisites for contributors:
- A GitHub account
- Familiarity with JSON (entries are JSON-LD files)
- Access to the project's source URL for the tool you're suggesting
See CONTRIBUTING.md for the full entry checklist, judgement criteria, and conflict-of-interest policy.
License
| What | Licence |
|---|---|
| Code (CI pipeline, scripts, site tooling) | Apache-2.0 |
Catalog data (entries/ JSON-LD files) |
CC0-1.0 — no rights reserved |
Cite this catalog
@misc{mach2026,
title = {MACH: Machine-Actionable Catalog for Healthcare},
author = {Ojha, Priyanka},
year = {2026},
doi = {10.5281/zenodo.20155320},
url = {https://zenodo.org/records/20155320},
orcid = {https://orcid.org/0000-0002-6844-6493},
note = {CC0-1.0}
}
Contact & community
- Issues / suggestions: GitHub Issues
- Discussions: GitHub Discussions
- Maintainer: Priyanka Ojha · ORCID 0000-0002-6844-6493
Acknowledgements & references
Design inspiration
- ThoughtWorks Technology Radar — three-ring Adopt / Assess / Caution editorial model
- CNCF Landscape — category-based open ecosystem catalog design
Metadata standards
- CodeMeta 3.0 — software metadata crosswalk (schema.org + W3C)
- MLDCAT-AP 3.0 (SEMIC / EU) — ML model metadata, EU AI Act aligned
- DCAT-AP 3.0 (SEMIC / EU) — dataset and catalog metadata
- JSON-LD 1.1 / schema.org (W3C) — linked data serialisation
FAIR scoring
- FAIRsoft indicators — Martin del Pico et al., 2024
- FAIR4RS principles — Chue Hong et al., RDA/FORCE11/ReSA, 2022
- howfairis — Netherlands eScience Center
Archival & indexing
- Software Heritage — persistent SWHIDs (ISO/IEC 18670)
License integrity
- Jewitt et al. (KDD 2026) — Permissive-Washing in the Open AI Supply Chain: A Large-Scale Audit of License Integrity — informed the addition of
mach:licenseUrlandmach:licenseVerifiedfields and MACH's decision to verify actual LICENSE files, not just metadata tags
AI assistance
- Parts of this project were developed with assistance from Claude (Anthropic). All content has been reviewed and is the intellectual responsibility of the project curator.
Yorumlar (0)
Yorum birakmak icin giris yap.
Yorum birakSonuc bulunamadi