Skip to main content

Document Service — Service Overview

Status: populated Owner: TBD Last updated: 2026-04-18 Companion: Service Template · 03 platform-services · 02 DDD


1. Purpose

The document-service provides enterprise clinical document management for the Ghasi eHealth platform. It owns the full lifecycle of clinical documents: template authoring, server-side PDF generation from FHIR-bound data, upload and virus-scanning of scanned paper records, versioned artifact storage in S3-compatible object storage, and audited retrieval with signed URLs.

It is the canonical owner of FHIR DocumentReference, Binary, and Provenance resources for generated and uploaded documents.


2. Bounded Context

AspectDetail
DDD contextClinical Documents
Module IDPLAT-DMS
Service registry03-platform-services.md
Internal base URLhttp://document-service:3020
External URL (via Kong)https://api.ghasi-health.af/v1/
Package name@ghasi/service-document

3. Responsibilities

ResponsibilityNotes
Template library managementDraft → publish lifecycle; semantic versioning; tenant + facility scope
PDF generation (synchronous + async)Server-side rendering with FHIR data binding; never client-side
Document upload and ingestionMultipart upload; virus scan on every upload
Object storage managementS3-compatible (AWS S3 or MinIO on-prem); AES-256 encryption at rest
Signed URL generationTemporary access URLs; short-lived
FHIR DocumentReference + Binary creationCanonical FHIR metadata for every stored document
Artifact versioning and supersessionrelatesTo + Provenance for clinical amendments
Platform reference form catalogCurated first-class templates (e.g. General Test Requisition)
Audit events on every accessView, download, print, export; 7-year retention
Async render jobsPollable status; downloadable result on completion

4. Non-Responsibilities

Not owned hereOwned by
DICOM pixel data managementradiology-service / PACS
IHE XDS registry/repositoryinterop-service (adapter only)
Qualified electronic signatures (PKI)Future licensed module
Vendor OCR processingOptional integration behind interfaces
Narrative clinical notes (NLP-structured)patient-chart-service
Imaging pixelsradiology-service
Template designer UIehr-web frontend (consumes this service's API)
FHIR gateway routinginterop-service

5. Architecture Diagram


6. Referenced-By Services

ConsumerDocuments used
patient-chart-serviceClinical notes attachments, discharge summaries
interop-serviceCDA/CCD documents for HIE exchange
patient-portal-servicePatient-visible documents
orders-serviceReferral letters, lab requisitions

7. FHIR Resource Ownership

ResourceRole
DocumentReferenceMetadata for clinical and administrative documents; primary search surface
BinaryPDF or image bytes stored in object storage; referenced from DocumentReference.content
ProvenanceSign/amend and system-generated document activity
CompositionOptional structured sections for long-form reports

8. Licensing Gate

License keyCapabilities
ehr.documentsBase: view/list/generate from published templates, store artifacts, audit
ehr.documents.designerTemplate authoring, draft workflow, promote to published
ehr.documents.bulkHigh-volume async generation and admin bulk operations

Unlicensed tenants receive HTTP 403 MODULE_NOT_LICENSED on gated endpoints. Deactivation preserves historical artifacts per retention policy.


9. Key Architectural Decisions

DecisionRationale
Object storage (S3/MinIO) for binary contentScalable; tenant-scoped paths; supports presigned URLs; on-prem via MinIO
Server-side PDF rendering onlyNo PHI in client-side or third-party rendering; regulatory requirement
Virus scan on every uploadMalware prevention; quarantine quarantined uploads to DLQ event
FHIR-first metadataDocumentReference + Binary for interoperability; HIE-compatible
Outbox pattern for eventsGuarantees at-least-once delivery; no audit gap on crash
Signed URL with short TTLAccess control without exposing raw object storage paths
Tenant-scoped storage paths/{tenantId}/{documentId}/ prefix on every object
Offline: view-only for cached PDFsServer render required for generation; client queues render requests for replay

10. Source Reconciliation

Single source module: services/document-service/_sources/document-management/. No multi-module merge required. Legacy module ID PLAT-DMS preserved in legacy FR references. Source referenced the broader spec as version 1.1 (2026-04-06). Platform reference forms catalog (REFERENCE_FORMS.md) is authoritative for platformFormKey values.