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.