MedicalRecords.in
Last reviewed 29 July 2026

Evidence before claims.

This trust center separates controls visible in the open repository from deployment evidence, independent assessments, and regulatory conclusions that do not exist yet.

Implemented

Code plus automated or reproducible repository evidence.

Deployment-validated

Requires dated evidence from the actual environment. Most items remain open.

Externally verified

Requires an in-scope independent assessment or regulator decision. None is claimed.

Current posture

What the repository demonstrates—and what it does not.

Each open item remains a commercial release gate. Feature completion does not convert it into certification, compliance, or production assurance.

Clinical release boundary

Implemented in the repository

  • Patient APIs withhold machine-drafted clinical content until release.
  • Release requires an active, verified doctor profile and recorded registration number.
  • The assigned reviewer must access the retained source record before release.

Still open

  • Isolated deployment and row-level-security validation
  • Independent RMP workflow and usability review
  • Clinically governed critical-result escalation
Review source evidence

Privacy and patient control

Implemented in the repository

  • The repository includes purpose-specific consent preferences, recorded sharing-event reads, and read-only legacy privacy-request history; new request writes are blocked.
  • The account flow requires an 18-or-older attestation in the browser and API; no guardian flow is offered.
  • Invite attribution uses a random code and returns aggregate signup counts only.
  • Product analytics accepts fixed event names and stores daily counts without user or health fields.

Still open

  • Deployment-specific data-flow and subprocessor register
  • Approved retention and deletion procedures across backups and processors
  • Named operator, grievance contact, and counsel-approved notices
Review source evidence

Security and resilience

Implemented in the repository

  • Production startup rejects mock integrations and missing core configuration.
  • Detailed operational telemetry requires a service API key outside debug environments.
  • Legacy phone-trusting reminder and adherence routes fail closed.
  • A repository threat model covers authorization, malicious documents, prompt injection, integrations, and evidence claims.

Still open

  • Independent penetration test and remediation evidence
  • Deployment-specific threat review, residual-risk acceptance, and independent VAPT
  • Restore, disaster-recovery, and incident-response exercises
Review source evidence

Document intelligence

Implemented in the repository

  • Uploads are checked by content signature and size before private processing.
  • Patients receive a non-clinical receipt while source, OCR, and machine drafts remain private.
  • The safety profile states intended use, limitations, and the evaluation evidence still required.

Still open

  • Clinically reviewed benchmark sets across supported document types and languages
  • Malicious-document and prompt-injection threat testing
  • Deployment-specific provider, region, retention, and model-training evidence
Review source evidence

ABDM FHIR interoperability

Implemented in the repository

  • The target is pinned to FHIR R4 4.0.1 and the published NRCeS package ndhm.in#6.5.0.
  • A strict manifest declares six synthetic DocumentBundle fixtures: HealthDocumentRecord, OPConsultRecord, PrescriptionRecord, DiagnosticReportRecord, DischargeSummaryRecord, and ImmunizationRecord.
  • All six pass the pinned official validator locally and in exact public CI with zero blocking profile or structure issues.
  • Every explicit code, MIME type, and language in all six fixtures passes exact live terminology operations with rejected negative controls in retained public evidence.
  • The DiagnosticReportRecord is a document envelope only and contains no diagnostic measurements, results, or interpretations.
  • The DischargeSummaryRecord contains a synthetic completed inpatient encounter and empty attachment, with no diagnosis, medication, procedure, investigation, care plan, instruction, or other clinical assertion.
  • The ImmunizationRecord is an empty document envelope with no Immunization, ImmunizationRecommendation, vaccine, dose, administration date, lot, manufacturer, eligibility, or schedule.
  • Live ABDM modes fail closed while the real adapter and sandbox evidence are absent.

Still open

  • India-specific extension validation and broader health-information mappings
  • Production terminology-service operations, edition licensing, and availability evidence
  • Dated ABDM sandbox M1/M2/M3 transactions and negative tests
Review source evidence Inspect exact CI run

Allowed today

Specific, inspectable wording

  • Patient-facing clinical content is withheld pending verified-doctor review.
  • The health log displays recorded values without machine-generated clinical labels or advice.
  • The interoperability target is FHIR R4 and the published NRCeS package ndhm.in#6.5.0.

Not claimed

Conclusions that need outside evidence

  • DPDP compliant, ABDM certified, regulator approved, or clinically validated.
  • India-only processing, end-to-end encryption, external security assurance, or production SLAs.
  • Accuracy, outcome, adoption, availability, market-leadership, or doctor-network numbers.

For patients, reviewers, and partners

Challenge the evidence, not a badge.

Open an issue with the exact claim, control, file, test, environment, or missing proof. The register is intended to become stricter as the product matures.