Iranian Clinical Case Reports Platform

Clinical Case Report Repository, Submission & Search System

Laravel · Livewire · Structured Clinical Data · Nested Search · XML Import · Journal Registry · RBAC

Project positioning

This project originated from a doctoral research idea in Library and Information Science: to build a low-cost, localized platform inspired by PubMed-style medical information retrieval, focused specifically on clinical case reports and adapted to the requirements of an Iranian research context.

The resulting system evolved beyond a simple search website. It became a multi-module platform for:

registering clinical case reports,

collecting structured and unstructured medical metadata,

supporting repeatable and nested medical entities,

importing external scientific data through XML,

maintaining journal metadata,

searching through case reports with nested Boolean queries,

managing users and permissions,

supporting review and administrative workflows,

and preparing the architecture for a future Elasticsearch integration.

A precise professional description is:

A Laravel/Livewire clinical case report repository and scientific data platform with multi-step structured submission, XML ingestion, journal metadata management, Boolean search, workflow control, and role-based administration.

It is better described as PubMed-inspired rather than as a literal PubMed clone, because the system also includes native case submission, structured data entry, review workflows, journal registration, administrative tooling, and educational components that go beyond the core function of PubMed as a biomedical literature indexing and retrieval platform.

1. Project Identity

Project Name: Iranian Clinical Case Reports
Domain: Clinical Case Reports / Medical Research Information System
Primary Framework: Laravel
Reactive UI: Livewire
UI Foundations: Soft UI + Vuexy
Search Model: Custom nested Boolean search
Planned Search Integration: Elasticsearch API / integration point
Import Format: XML
Rich Text: Summernote
Enhanced Selects: Select2
Guided UX / Onboarding: Tour.js
Architecture Style: Relational scientific data platform
Core Users: Researchers, authors, reviewers, administrators
Administrative Model: RBAC / permission-oriented management
Portfolio Relevance: Very High
Suggested CV Relevance: Tier A — Laravel, Livewire, Research Data Modeling, Search, XML Import, Workflow, RBAC

2. Website Card

Title:
Iranian Clinical Case Reports Platform

Subtitle:
Medical Case Repository · Structured Submission · Search · XML Import

One-line Description:
Developed a Laravel/Livewire clinical case report platform with multi-step structured medical data entry, repeatable entities, journal registration, XML ingestion, nested Boolean search, and administrative workflow controls.

Categories:

Laravel
Livewire
Medical Research
Clinical Case Reports
Scientific Data
XML Import
Search Engine
Workflow
RBAC
Journal Metadata

Concept Tags:
Laravel · Livewire · Clinical Data · Case Reports · XML · Boolean Search · Medical Repository · RBAC · Workflow

3. Executive Summary

The platform was created around a research-driven idea:

build a localized and cost-conscious medical case-report information system inspired by PubMed-style search and scientific metadata organization.

The project was not limited to storing published papers.

It supported the complete lifecycle of clinical case information:

Registration
    ↓
Structured / Unstructured Entry
    ↓
Scientific Metadata
    ↓
Clinical Data
    ↓
Files / References / Journals
    ↓
Confirmation / Review
    ↓
Search / Retrieval
    ↓
Administration

This makes the system closer to a combined:

Medical Repository
+
Research Information System
+
Submission Platform
+
Search Platform

than to a traditional content website.

4. Main Functional Domains

The platform can be divided into the following high-level modules:

Clinical Case Reports Platform
│
├── Public Search & Discovery
│   ├── Simple Search
│   ├── Advanced Search
│   ├── Boolean Query Search
│   └── Browse / Journals
│
├── Case Registration
│   ├── Light & Simple
│   ├── Full Structured Registration
│   ├── XML Import
│   └── Journal Registration
│
├── Scientific Metadata
│   ├── Authors
│   ├── ORCID
│   ├── Affiliations
│   ├── Keywords
│   ├── Highlights
│   ├── Literature
│   ├── Learning Points
│   └── Journal Metadata
│
├── Clinical Data
│   ├── Patient
│   ├── Structured Data
│   ├── Diagnostic Assessments
│   ├── Interventions
│   ├── Discussion
│   └── Ethical & Legal
│
├── Workflow
│   ├── Registration
│   ├── Confirmation
│   ├── Review
│   └── Completion / Finalization
│
└── Administration
    ├── Users
    ├── Teams
    ├── Permissions
    ├── Languages
    ├── Countries
    ├── Journal Categories
    ├── Indexed Sources
    └── Blacklist / Governance Data

5. Public Search & Discovery

The public-facing portion of the system presents a search-first interface.

The available screenshots show:

a central search input,
guide/help access,
ICCRs services,
journal browsing,
case-report access.

This immediately positions the platform as a research repository rather than a static publication site.

6. PubMed-Inspired Search Model

The search experience was inspired by biomedical information-retrieval systems.

The system supported advanced Boolean expressions such as:

("gastric outlet obstruction" OR GOO) AND diabetes

and could combine multiple search domains through:

AND
OR
NOT

The search subsystem therefore behaved as a structured Boolean retrieval engine rather than as a simple keyword filter.

7. Searchable Domains

Historical project evidence shows search logic across domains such as:

All Data
Authors
Highlights
Keywords
Learning Point

Each search domain could resolve its own result set and contribute to the larger Boolean expression.

This is important because the clinical case data model is not flat.

A search for an author may involve a relational table different from a search for a keyword or a learning point.

8. Search Architecture

Conceptually:

User Query
   ↓
Boolean Parsing
   ↓
Search Field Resolution
   ↓
Domain-Specific Search
   ↓
Normalized Case / Prototype IDs
   ↓
Boolean Set Evaluation
   ↓
Final Results

This architecture allowed heterogeneous scientific metadata to participate in one unified search experience.

9. Elasticsearch Integration Boundary

An Elasticsearch integration point / API strategy was planned and prepared as part of the architecture.

However, the full Elasticsearch implementation was not completed due to project budget constraints.

The accurate wording is:

The platform was designed with an Elasticsearch integration path, but the full search-engine deployment and implementation were not completed because the project budget did not support it.

This distinction is important.

The historical product had a custom search path; Elasticsearch was an architectural extension, not a fully deployed production dependency.

10. Registration Model

One of the strongest parts of the project is the existence of multiple data-ingestion strategies.

The system supported four major registration/import paths:

1. Light & Simple Entry
2. Full / Structured Multi-Step Entry
3. XML Import
4. Journal Registration

Each path addressed a different operational need.

11. Light & Simple Registration

The simple mode was designed for lower-friction case registration.

A user could create a case report with a reduced set of fields and gradually enrich it.

Visible historical features include:

Title
Running Title
Files
Authors
Keywords
Highlights
Edit
Delete
Completion state

This mode is useful when the contributor does not need the full structured research workflow.

12. Why a Simple Mode Matters

A complex medical data model can make data entry intimidating.

The simple registration path reduces the initial barrier:

Minimal Entry
   ↓
Save
   ↓
Enrich Later

instead of requiring:

Complete Entire Research Model
   ↓
Save

This is a strong UX decision for scientific systems.

13. Full Structured Registration

The advanced registration model is the technical centerpiece of the system.

The UI shows a multi-step workflow with sections such as:

Authors
Literature
Textual
Structured
Discussion
Patient
Ethical & Legal

The user described the full registration as an approximately eight-stage process.

The crucial point is that these stages were not composed only of fixed scalar fields.

Many data groups could be repeated multiple times.

14. Repeatable Scientific Entities

The system supported dynamically repeatable data.

Conceptually:

Case Report
├── Authors [0..n]
├── Literature Entries [0..n]
├── Keywords [0..n]
├── Highlights [0..n]
├── Learning Points [0..n]
├── Diagnostic Assessments [0..n]
├── Interventions [0..n]
└── Other Structured Clinical Entities [0..n]

This makes the registration flow significantly more complex than a standard CRUD form.

15. Nested Repeatable Medical Data

The user described cases where one clinical case could contain multiple nested groups, where a group itself could have repeated sub-elements.

Conceptually:

Clinical Case
   ↓
Multiple Clinical Sections
      ↓
Multiple Diagnoses
         ↓
Multiple Prescriptions / Interventions

The exact historical cardinalities should be documented from the source code where necessary, but the project clearly required repeatable relational structures.

16. Dynamic Form Architecture

A system like this needs to manage:

dynamic row addition,
dynamic row removal,
nested validation,
ordering,
relational persistence,
partial saving,
repeated data groups.

This is a strong use case for Livewire.

17. Livewire as the Reactive Layer

The application used Livewire to handle:

repeatable fields,
reactive forms,
dynamic step workflows,
search,
record updates,
pagination.

This reduced the amount of manual JavaScript required for server-backed reactive behavior.

18. Multi-Step Registration Wizard

Conceptually:

Step 1 — Authors
Step 2 — Literature
Step 3 — Textual
Step 4 — Structured
Step 5 — Discussion
Step 6 — Patient
Step 7 — Ethical & Legal
Step 8 — Finalization

The exact order should follow the final historical build if reconstructed from source.

The important architectural idea is a step-based scientific submission flow.

19. Scientific Metadata

Clinical case reports need more than clinical observations.

The platform also modeled bibliographic and publication metadata.

Examples include:

title,
running title,
authors,
ORCID,
affiliations,
journal,
keywords,
literature,
highlights,
learning points.

This bridges medical and library-information-science concerns.

20. Authors

The system supported multiple authors per case.

The screenshot shows author-related fields such as:

Author
ORCID id
Organizational Affiliation Information

and multiple author rows.

This means authors were modeled as relational entities rather than a single text string.

21. ORCID

ORCID identifiers were included in the author workflow.

That allows a case report to preserve researcher identity separately from display names.

A modern architecture should validate ORCID format, but historical validation rules should only be claimed if confirmed in code.

22. Organizational Affiliations

Each author could be associated with affiliation information.

Conceptually:

Author
   ↓
ORCID
   ↓
Affiliation

This is standard scientific metadata behavior and appears directly in the UI evidence.

23. Keywords

Keywords were a first-class searchable entity.

The data model contains keyword tables and relational mappings.

This enables:

structured tagging,
discovery,
search filtering,
reuse across cases.

24. Highlights

Highlights were also stored separately.

This supports short high-value concepts or summary points associated with a case.

These could also participate in search.

25. Learning Points

Learning points represent educational takeaways.

This is especially important for clinical case reporting because a case can be valuable not only as a record, but also as an educational artifact.

26. Literature

The full registration workflow includes a dedicated literature section.

This allows references to be associated with the case report rather than embedded only in one free-text field.

27. Textual Data

The system supported rich-text sections.

Summernote was used for editing rich content.

This provides support for:

formatted paragraphs,
lists,
tables,
hyperlinks,
images,
HTML content.

28. Summernote Integration

Historical evidence shows Summernote being used as a WYSIWYG editor.

This was appropriate for fields such as:

Case Narrative
Discussion
Learning Point
Clinical Description

or other long-form sections.

29. Structured Data

Separate structured sections existed in addition to rich narrative text.

This distinction is essential.

A medical system should not place all information into one free-text field.

The platform therefore had both:

Narrative Data
+
Structured Clinical Data

30. Patient Data

The workflow includes a patient section.

The database diagram also shows patient-related structure.

This allows clinical attributes to be modeled independently from bibliographic metadata.

31. Diagnostic Assessments

The ERD visibly includes a diagnostic_assessments entity.

This shows that diagnostic content was captured structurally.

The exact field semantics should be preserved from the original schema when documenting the legacy implementation.

32. Interventions

The ERD also contains an interventions entity.

This indicates structured recording of treatment/intervention information.

The user explicitly described support for multiple treatment/prescription-style records within a case.

33. Discussion

A dedicated discussion section existed in the structured case-report workflow.

This is distinct from raw clinical data and supports scientific interpretation.

34. Ethical & Legal

A separate Ethical & Legal section existed.

This is particularly important for clinical case reporting.

The platform architecture therefore recognized governance as a separate domain rather than mixing it into administrative metadata.

35. Clinical Quiz

Historical UI evidence also shows a Clinical Quiz feature.

This indicates that the system was intended not only as a repository but also as an educational environment.

Conceptually:

Clinical Case
   ↓
Educational Question / Quiz
   ↓
Learning Interaction

36. Repository + Research + Education

The overall platform therefore supports three conceptual purposes:

Repository
+
Research
+
Education

This is a stronger product story than describing it only as a publication database.

37. XML Import

The third ingestion route was XML-based import.

The purpose was to allow existing scientific records from other systems to be brought into the internal database.

Conceptually:

External Scientific Dataset
          ↓
XML
          ↓
Parser
          ↓
Mapping
          ↓
Internal Data Model

38. Why XML Import Matters

Medical/scientific repositories often exchange structured metadata.

Without import support, the platform would require manual re-entry.

XML import creates an interoperability path.

39. PubMed-Style Data Migration

The user specifically described the XML route as a way to import data originating from systems such as PubMed.

The accurate portfolio wording is:

An XML-based ingestion path was designed to map externally available scientific metadata into the platform’s internal relational schema.

This avoids claiming official PubMed API integration unless separately documented.

40. Canonical Internal Model

A robust importer should map external formats into a canonical internal representation.

Conceptually:

External XML
    ↓
Importer
    ↓
Canonical Case DTO
    ↓
Domain Services
    ↓
Database

This reduces direct coupling between the database and external XML structures.

41. Modern Import Architecture

A modern V2 could define:

ImportAdapter
├── PubMedXmlAdapter
├── JatsXmlAdapter
├── CrossrefAdapter
└── GenericXmlAdapter

All adapters produce one common internal DTO.

This is a modernization recommendation, not a confirmed historical implementation.

42. Journal Registration

The fourth ingestion path was the journal registry.

Journal metadata was managed as its own first-class domain.

This is important because cases can reference publication venues.

43. Journal Metadata Fields

Historical screenshots show fields such as:

Journal Name
Publisher
Language
Publishing Place
Indexing
CiteScore
Quartile
Category
Editor
Article Processing Charge
Dedicated Case Report Journal
About Journal / Aims & Scope

This is significantly richer than storing a journal name only.

44. Journal as a Domain Entity

Conceptually:

Journal
├── Name
├── Publisher
├── Language
├── Publishing Place
├── Indexing
├── CiteScore
├── Quartile
├── Category
├── Editor
├── APC
├── Case Report Support
└── Aims & Scope

45. Why Journal Registry Matters

With normalized journals:

cases can reference known journals,
journal metadata can be reused,
search can filter by journal attributes,
publication guidance can be built later.

46. Scientific Publication Assistance Opportunity

A future version could use journal metadata to help researchers identify appropriate case-report journals based on:

subject,
language,
indexing,
APC,
quartile,
publication scope.

This should be presented as a V2 opportunity unless historical implementation confirms it.

47. ERD Complexity

The provided ERD is one of the strongest artifacts for this project.

It shows a broad relational model with numerous domain tables and pivot/relationship tables.

Visible examples include:

authors
authors_uploads
authors_pages

highlights
highlights_uploads

keywords
keywords_uploads

learning_points
learning_points_uploads

users
permissions

all_prototype
all_to_complete

simple
simple_to_complete

diagnostic_assessments
interventions

This proves that the platform is not built around a single monolithic case_reports table.

48. Relational Scientific Model

The database structure suggests a normalized model where concepts are separated into reusable entities.

Conceptually:

Case
├── Authors
├── Keywords
├── Highlights
├── Learning Points
├── Files
├── Journals
├── Patient Data
├── Diagnostic Data
└── Intervention Data

49. Pivot Relationships

The presence of dedicated relation tables is appropriate for many-to-many scientific metadata.

Example:

Case ↔ Authors
Case ↔ Keywords
Case ↔ Highlights

This avoids comma-separated or JSON-only storage for highly relational concepts.

50. Data Reuse

Normalized entities allow reuse.

For example:

Author X

can be linked to multiple case reports.

Similarly:

Keyword Y

can classify multiple records.

51. Search Benefits of Normalization

Normalized scientific metadata also improves search.

Instead of searching one text blob:

Case Text

the system can search:

Author
Keyword
Highlight
Learning Point
Journal

as separate semantic fields.

52. Data Quality Benefits

Structured metadata enables:

consistent filtering,
controlled vocabularies,
validation,
reporting,
deduplication.

53. Workflow

Historical UI indicates that the system had workflow states beyond simple creation.

Visible sections include:

REGISTRATIONS
CONFIRMING REGISTERED
REVIEW

This indicates a lifecycle where records can move through multiple stages.

54. Conceptual Case Lifecycle

A safe conceptual representation is:

Draft / Registration
      ↓
Completion
      ↓
Confirmation
      ↓
Review
      ↓
Finalized / Published Record

The exact state-machine semantics should be reconstructed from code before claiming specific transition rules.

55. Review Interface

The review screenshots show lists of submitted cases and actions for:

files,
authors,
keywords,
highlights,
edit,
delete,
completion state.

This suggests reviewers/administrators could inspect different parts of a record separately.

56. Workflow Separation

A good system architecture separates:

Data Entry
from
Review
from
Administration

The historical UI supports this separation.

57. RBAC

The project contains explicit permission management.

The historical permission screen shows:

permission creation,
page selection,
user selection,
permission assignment.

This is evidence of a real access-control subsystem.

58. Permission Model

Conceptually:

User
  ↓
Permission
  ↓
Page / Capability

or more generally:

User
↔
Permission
↔
Resource

59. Administrative Domains

The sidebar shows super-admin/control areas such as:

Permissions
All Users
Languages
Indexed Map
Countries
Black List
Journal Category

This indicates the system had configurable reference data and governance controls.

60. Super Admin Layer

A logical decomposition:

Identity
├── Users
├── Teams
└── Permissions

Reference Data
├── Languages
├── Countries
├── Journal Categories
└── Indexed Sources

Governance
├── Black List
└── System Controls

61. Team Management

The login/dashboard UI also includes team management.

This is relevant in collaborative scientific systems where more than one researcher may work on a case.

The exact collaboration semantics should be confirmed from code before stronger claims.

62. Blacklist

The administration menu includes a blacklist area.

The historical evidence confirms the feature exists, but the exact domain behavior—user blacklist, content blacklist, source blacklist, etc.—should not be inferred beyond the source without code verification.

63. Languages

The system includes language administration.

This is valuable for a localized scientific platform and potentially supports multilingual metadata.

Do not claim full multilingual UI/data support unless verified.

64. Countries

Country reference data is explicitly represented in administration.

This is useful for:

affiliations,
journals,
authors,
publication metadata.

65. Indexed Sources

The control menu contains an indexed-map / indexed-related section.

This appears to support bibliographic/indexing metadata.

The exact semantics should be preserved from the original implementation when source reconstruction is available.

66. UI Architecture

The UI used two design systems/templates:

Soft UI
Vuexy

This was a pragmatic way to accelerate development while keeping the system modular.

67. Vuexy Adaptability

Vuexy is available across multiple frontend technology variants.

The project therefore had an architectural path toward replacing/rebuilding the presentation layer with:

Vue
Angular

without redesigning the entire backend domain model.

The precise claim should be:

The frontend used Vuexy/Soft UI foundations, making future migration to Vue or Angular variants more practical.

Not:

“The application was written in Angular.”

68. Select2 Integration

The system used Select2 for richer selection controls.

This is especially useful for repeatable scientific metadata such as:

authors,
affiliations,
journals,
categories,
controlled lists.

69. Select2 + Livewire Challenge

Third-party JavaScript widgets can conflict with Livewire DOM updates.

This is because:

Select2
→ mutates DOM / controls state

Livewire
→ re-renders DOM from server state

A correct integration requires synchronization between the two state systems.

70. Why This Matters

The screenshot documenting Select2 integration is technically useful because it shows work beyond using default form controls.

It demonstrates:

JS plugin integration,
reactive state synchronization,
multi-value form support.

71. Summernote Integration

Summernote provided rich-text editing for long-form scientific content.

This allows authors to create:

formatted text,
lists,
tables,
links,
HTML-backed content.

72. Rich Text Storage

A modern implementation must consider:

HTML sanitization,
XSS protection,
allowed tags,
safe rendering.

Historical sanitization behavior should only be claimed if confirmed.

73. Tour.js

Tour.js was included to provide guided workflows.

This is particularly valuable for the full multi-step case-registration process.

74. Guided Onboarding

Conceptually:

Start Tour
   ↓
Explain Step
   ↓
Highlight Field
   ↓
Move to Next Section

This reduces the cognitive cost of a complex scientific form.

75. Public Guide

The public interface includes guide/help access.

This supports the project’s educational and onboarding goals.

76. Clinical Case Search

The search engine is directly relevant to case reports because users may search by:

author,
keyword,
clinical concept,
learning point,
highlight,
title,
journal,
other metadata.

The source screenshots confirm only a subset of these; additional fields should be claimed only when documented.

77. Boolean Search Example

Example:

("gastric outlet obstruction" OR GOO)
AND
diabetes

This allows users to express alternative terminology and combine it with another clinical condition.

78. Search as a Research Tool

This search model is especially useful in medical research because terminology often has:

abbreviations,
synonyms,
alternative phrases.

Boolean logic gives the researcher explicit control.

79. Information-Retrieval Positioning

The platform’s search is best described as a Boolean retrieval model.

It should not be confused with:

semantic vector search,
AI retrieval,
relevance ranking,
BM25,

unless those components are added separately.

80. Data Architecture

A high-level domain structure:

ClinicalCase
├── Bibliographic Metadata
│   ├── Authors
│   ├── Journal
│   ├── Keywords
│   └── Literature
│
├── Educational Metadata
│   ├── Highlights
│   └── Learning Points
│
├── Clinical Data
│   ├── Patient
│   ├── Diagnostics
│   ├── Interventions
│   └── Structured Sections
│
├── Narrative
│   ├── Textual Content
│   └── Discussion
│
├── Governance
│   ├── Ethical
│   └── Legal
│
└── Files

81. Domain Separation

This decomposition is important because each area evolves differently.

For example:

Journal Metadata

should not be tightly coupled to:

Patient Clinical Data

even though both belong to one case.

82. Canonical Case Record

A modern architecture should treat the case report as an aggregate root.

Conceptually:

ClinicalCaseReport

owns or references the supporting domains.

83. Aggregate Boundaries

Possible boundaries:

ClinicalCaseReport
Author
Journal
Patient
DiagnosticAssessment
Intervention

The exact aggregate design depends on edit and lifecycle rules.

84. Files

The system supported file attachment in case reports.

The review UI includes file access.

This likely covers supporting media/documents.

Exact file type rules should be verified from source.

85. File Security

For a medical research system, a modern implementation should use:

authenticated file access,
authorization checks,
private storage,
MIME validation,
file-size limits,
malware scanning where required.

These are V2 recommendations unless documented historically.

86. Medical Privacy

The application deals with clinical case information.

A modern deployment must explicitly address:

patient de-identification,
access control,
audit logs,
consent,
retention policies,
jurisdictional privacy requirements.

Historical compliance should not be assumed merely because the system has medical data fields.

87. Security Boundary

The project evidence supports technical RBAC.

It does not, by itself, prove compliance with any medical-data regulation.

This distinction should remain explicit in portfolio wording.

88. Search Privacy

If sensitive clinical content exists, search results must obey authorization.

A secure architecture should never:

Search all records
then hide unauthorized rows in UI

Instead:

Authorization Scope
   ↓
Search

should be applied server-side.

89. Audit Trail — V2

A modern version should log important events:

Case Created
Case Updated
Author Added
Clinical Data Changed
Review Started
Review Completed
Permission Changed
XML Imported

90. Version History — V2

Scientific records benefit from versioning.

A strong V2 would store:

Case Revision
├── Version
├── Editor
├── Timestamp
└── Change Summary

This is a future architecture enhancement.

91. XML Validation

A robust importer should validate XML against the expected schema or mapping rules.

Potential steps:

Upload XML
   ↓
Validate XML
   ↓
Parse
   ↓
Map Fields
   ↓
Resolve Existing Entities
   ↓
Persist
   ↓
Import Report

92. Duplicate Detection

When importing external scientific records, duplicate detection is important.

Possible identifiers include:

PMID,
DOI,
title + publication metadata.

Only identifiers actually present in historical code should be claimed as implemented.

93. PMID

Historical forms visibly include a PMID field.

This is a significant clue that the system was designed to work with biomedical publication identifiers.

94. Publication Metadata

Other visible fields include concepts such as:

PMID
Title
Running Title
Publication
Year
Volume

depending on the registration route.

This reinforces the PubMed-inspired bibliographic model.

95. Journal Linking

Journal entities can be linked to case records.

A normalized design should use:

case_report.journal_id

or a suitable relation rather than duplicating journal metadata in each case.

96. Review Workflow — Modern State Machine

A modern rebuild should formalize lifecycle transitions.

Example:

DRAFT
   ↓
SUBMITTED
   ↓
UNDER_REVIEW
   ↓
CHANGES_REQUESTED
   ↓
APPROVED
   ↓
PUBLISHED

This is a recommended V2 state machine, not a claim about the exact historical states.

97. Workflow Authorization

Transitions should be permission-controlled.

Example:

Author
→ submit

Reviewer
→ review / request changes

Admin
→ approve / publish

Again, roles should match the actual reconstructed legacy implementation.

98. Admin vs Super Admin

The presence of user, permission, control-data, and management areas indicates multiple administrative scopes.

A robust V2 could distinguish:

Admin
Super Admin
Reviewer
Researcher
Author

only where supported by requirements.

99. Frontend Migration Potential

The backend architecture can remain Laravel while the frontend is replaced.

Possible modern split:

Laravel API
+
Angular

or:

Laravel API
+
Vue

100. Why Angular/Vue Migration Is Feasible

The domain logic is server-side.

The presentation layer can be rebuilt if APIs and domain boundaries are clean.

The Vuexy-based visual system provided an easier design path for frontend evolution.

101. Modern V2 — Backend Architecture

Recommended modules:

App
├── CaseReports
├── Authors
├── Journals
├── Patients
├── Diagnostics
├── Interventions
├── Literature
├── Search
├── Imports
├── Workflow
├── Identity
├── Permissions
└── Audit

102. Modern V2 — Application Layer

Each module should contain:

Domain
Application
Infrastructure
Presentation

where practical.

103. Case Registration Service

Instead of persisting everything directly inside Livewire components:

Livewire Component
   ↓
CaseRegistrationService
   ↓
Domain / Repository

This improves testability.

104. Step Components

Suggested components:

CaseReportWizard
├── AuthorsStep
├── LiteratureStep
├── TextualStep
├── StructuredStep
├── DiscussionStep
├── PatientStep
├── EthicalLegalStep
└── FinalizeStep

105. Repeatable Field Components

Examples:

AuthorRepeater
KeywordRepeater
DiagnosticRepeater
InterventionRepeater
LiteratureRepeater

Each should own validation and serialization logic.

106. Validation

Validation should exist at two levels:

UI Validation
+
Domain Validation

For example:

required fields,
valid identifiers,
allowed value sets,
valid transitions.

107. Partial Save

For long multi-step forms, users should be able to save drafts.

This is particularly important in research applications.

Historical persistence behavior should be verified before claiming it as implemented.

108. Autosave Opportunity

A modern V2 could add:

Autosave Draft

with revision recovery.

109. Search V2

If dedicated search infrastructure is still not available, a modern relational alternative could use:

PostgreSQL Full Text Search
+
pg_trgm

110. Search V2 with Elasticsearch/OpenSearch

If infrastructure allows:

Laravel
   ↓
Search Index Service
   ↓
Elasticsearch / OpenSearch

could support:

analyzers,
scoring,
synonyms,
fuzzy search,
faster large-scale retrieval.

111. Search Index Strategy

The index could denormalize selected case data:

Case Document
├── title
├── authors
├── keywords
├── highlights
├── learning_points
├── journal
├── clinical_text
└── structured_terms

while the database remains the source of truth.

112. Database as Source of Truth

Important principle:

Database = Canonical Data
Search Index = Derived Retrieval Layer

This prevents Elasticsearch/OpenSearch from becoming the primary record store.

113. Search Reindexing

A modern system needs:

case.created
case.updated
case.deleted

events to keep the search index synchronized.

114. XML Import V2

A clean importer pipeline:

File Upload
   ↓
Format Detection
   ↓
Schema Validation
   ↓
Adapter
   ↓
Canonical DTO
   ↓
Entity Resolution
   ↓
Transactional Persist
   ↓
Import Report

115. Import Reporting

An import should return:

Imported
Updated
Skipped
Invalid
Duplicate

counts.

116. Transaction Safety

Large structured imports should use database transactions where practical.

If a case import fails mid-way, partial orphaned medical data should not remain.

117. Background Jobs

Large XML imports and indexing should run in queues.

Example:

Upload
   ↓
Queue Job
   ↓
Parse
   ↓
Persist
   ↓
Notify User

118. Notifications

A modern workflow may notify users when:

import completes,
review status changes,
changes are requested,
case is approved.

This is a V2 recommendation.

119. Testing Strategy

This project needs several testing layers.

Unit Tests
Feature Tests
Livewire Tests
Import Tests
Search Tests
Permission Tests
Workflow Tests

120. Repeatable Entity Test

Example:

Given:
A case report

When:
3 authors are added

Then:
3 author relationships are persisted

121. Nested Clinical Data Test

Example:

Given:
One case

When:
Multiple diagnostic assessments and interventions are added

Then:
All relations remain linked to the correct case

122. XML Import Test

Example:

Given:
Valid scientific XML

When:
Import runs

Then:
Mapped internal entities are created correctly

123. Invalid XML Test

Given:
Malformed XML

When:
Import runs

Then:
No partial record is persisted
and
A useful validation result is returned

124. Search Test

Example:

("gastric outlet obstruction" OR GOO)
AND diabetes

should return only records satisfying the configured Boolean semantics.

125. Permission Test

Example:

Given:
A user without review permission

When:
Review page is requested

Then:
Access is denied

126. Workflow Test

Example:

Given:
A submitted case

When:
An unauthorized user attempts approval

Then:
Transition is rejected

127. Journal Test

Example:

Given:
A registered journal

When:
A case references the journal

Then:
The relationship uses the journal entity
instead of duplicated journal text

128. Historical Evidence Strategy

The available screenshots strongly document:

public search,
login,
Full Step registration,
journal registration,
ERD complexity,
Select2/Livewire work,
Summernote rich text,
review lists,
author registration,
permission management.

This is a strong portfolio evidence set.

129. Suggested Screenshot Caption — Public Search

Public research interface for searching and browsing the Iranian Clinical Case Reports repository.

Authenticated researcher/admin access to the clinical case-report platform.

131. Suggested Screenshot Caption — Full Step

Multi-step clinical case registration workflow separating authors, literature, textual content, structured data, discussion, patient information, and ethical/legal sections.

132. Suggested Screenshot Caption — Journals

Journal registry for maintaining publication metadata used during clinical case registration.

133. Suggested Screenshot Caption — ERD

Relational scientific data model covering case metadata, authors, keywords, learning points, diagnostic assessments, interventions, permissions, and supporting relationships.

134. Suggested Screenshot Caption — Select2

Custom Select2 integration with Livewire for repeatable scientific metadata such as authors and affiliations.

135. Suggested Screenshot Caption — Rich Text

Summernote integration for rich-text scientific narrative fields.

136. Suggested Screenshot Caption — Review

Administrative/reviewer interface for inspecting submitted cases and their files, authors, keywords, and highlights.

137. Suggested Screenshot Caption — Authors

Repeatable author registration with ORCID and organizational affiliation metadata.

138. Suggested Screenshot Caption — Permissions

Role/permission administration for controlling user access to platform pages and functions.

139. Historical Capabilities — Confirmed

Based on the project description and screenshots, the following can be safely described as historical functionality:

Laravel backend.
Livewire-based interaction.
Soft UI / Vuexy-based UI.
public case-report search.
simple registration.
full multi-step registration.
repeatable scientific fields.
author registration.
ORCID field.
affiliation data.
literature section.
textual section.
structured section.
discussion section.
patient section.
ethical/legal section.
XML-based import path.
journal registration.
journal metadata.
custom Boolean search.
nested query concept.
Elasticsearch integration path prepared but not fully developed.
Select2 integration.
Summernote rich text.
Tour.js usage.
user management.
team management.
permissions.
language administration.
country administration.
journal category administration.
blacklist/control section.
review workflow UI.
clinical quiz feature.

140. Historical vs Modern Boundary

Historical

The historical system already had:

Laravel
Livewire
Structured Case Registration
XML Import
Journal Registry
Boolean Search
Permissions
Review UI

Modern V2

A modern rebuild would add or formalize:

Domain Services
State Machine
Audit Trail
Version History
Queue-Based Imports
Search Indexing
Elasticsearch / OpenSearch
API-First Architecture
Angular/Vue Frontend
Strict Medical Privacy Controls

141. What Not to Overclaim

Do not claim the historical platform had:

official PubMed integration,
production Elasticsearch deployment,
semantic AI search,
certified medical-data compliance,
automated diagnosis,
clinical decision support,
official journal indexing authority,

unless documentary evidence exists.

142. Accurate PubMed Positioning

Preferred wording:

PubMed-inspired clinical case report repository and search platform

Avoid:

PubMed clone

unless used informally and immediately clarified.

143. My Role — Strong Portfolio Version

I developed a Laravel/Livewire platform for clinical case reports based on a doctoral research concept for a localized, low-cost PubMed-inspired repository. The system supported simple and full multi-step case registration, repeatable structured medical entities, author/ORCID metadata, XML ingestion, journal registration, Boolean search, role-based administration, and review workflows. I also integrated third-party UI components such as Select2, Summernote, and Tour.js and prepared the architecture for future Elasticsearch-based search.

144. My Role — Short Version

Developed a Laravel/Livewire clinical case-report repository with structured multi-step submission, XML import, journal metadata, nested Boolean search, and RBAC.

145. Engineering Highlights

Laravel.
Livewire.
Multi-step forms.
Repeatable relational entities.
Scientific metadata modeling.
Clinical data modeling.
XML import.
Journal registry.
Boolean search.
Planned Elasticsearch integration.
RBAC.
Review workflow.
Select2 integration.
Summernote integration.
Tour.js onboarding.
Complex relational database design.

146. Domain Modeling Highlights

The project required modeling both:

Bibliographic Data

and:

Clinical Data

inside one coherent system.

This is a major architectural challenge.

147. Bibliographic Domain

Includes:

authors,
ORCID,
affiliations,
journals,
keywords,
literature,
publication metadata.

148. Clinical Domain

Includes:

patient data,
structured clinical information,
diagnostic assessments,
interventions,
discussion,
ethical/legal information.

149. Workflow Domain

Includes:

registration,
completion,
confirmation,
review,
administrative actions.

150. Identity Domain

Includes:

users,
teams,
permissions.

151. Why This Project Is Strong for a CV

It proves experience beyond standard web CRUD.

The technical story combines:

Scientific Data Modeling
+
Complex Forms
+
Relational Database Design
+
Search
+
XML Interoperability
+
Workflow
+
RBAC

152. CV Relevance

Tier A — Research Platform / Backend Architecture

This project can support claims of experience in:

Laravel application architecture,
complex relational modeling,
dynamic form design,
data ingestion,
search systems,
research data management,
access control,
modular administration.

153. Interview Story

Situation

A doctoral Library and Information Science project proposed building a localized, low-cost platform inspired by PubMed for clinical case reports.

Task

The system needed to support more than search.

It had to allow researchers to:

register case reports,
enter complex structured medical data,
attach publication metadata,
import records from XML,
manage journals,
and search the repository using advanced Boolean logic.

Action

I developed the platform in Laravel and Livewire.

I built multiple registration paths:

simple entry,
full multi-step structured entry,
XML import,
journal registration.

The data model supported repeatable entities such as authors, keywords, diagnoses, interventions, and other scientific/clinical components.

I also implemented nested Boolean search and prepared an Elasticsearch integration path, although the full Elasticsearch deployment was not completed because of the available budget.

For usability and UI integration, I worked with Vuexy, Soft UI, Select2, Summernote, and Tour.js.

Result

The result was a full clinical case-report information platform combining repository, submission, search, review, and administration capabilities within a Laravel-based architecture.

154. Technical Interview Explanation — Short

“The hardest part was not the UI. The difficult part was modeling a clinical case as a large relational structure where many entities—authors, references, diagnoses, interventions, and other sections—could repeat independently. The system also needed multiple ingestion paths and Boolean retrieval. I used Laravel/Livewire for the application layer, normalized the data model, and separated simple entry, full structured registration, XML import, journal management, and search.”

155. Technical Interview Explanation — Database

“The schema was highly relational. Instead of storing the entire case as JSON or long text, the database separated authors, keywords, highlights, learning points, diagnostic assessments, interventions, and other entities. This made search, reuse, validation, and later integration much more practical.”

156. Technical Interview Explanation — Search

“The search layer supported Boolean expressions across several metadata domains. A future Elasticsearch integration point was prepared, but the production project budget did not include completing that migration.”

157. Technical Interview Explanation — Frontend

“Livewire handled much of the reactive server-driven behavior, while components such as Select2 and Summernote were integrated for richer scientific metadata entry. The UI was based on Soft UI and Vuexy, leaving a practical migration path toward Vue or Angular.”

158. Suggested Website Full Description

Overview

Iranian Clinical Case Reports is a Laravel/Livewire scientific information platform designed for registering, organizing, reviewing, and searching clinical case reports.

The project originated from a doctoral Library and Information Science concept for a localized, lower-cost system inspired by PubMed-style biomedical retrieval.

Multiple Registration Models

The system supported:

Light & Simple registration,
Full structured multi-step registration,
XML import,
Journal registration.

This allowed data to enter the platform from both manual and structured sources.

Structured Clinical Data

The full registration workflow separated:

authors,
literature,
textual content,
structured medical content,
discussion,
patient data,
ethical/legal information.

Many of these entities could be repeated dynamically.

Scientific Metadata

The platform supported structured metadata such as:

ORCID,
affiliations,
keywords,
highlights,
learning points,
journal information.

Search

Case reports could be searched through advanced Boolean expressions using AND, OR, NOT, and multiple semantic search fields.

XML Interoperability

An XML ingestion path was created to support importing existing scientific records into the normalized internal model.

Journal Registry

Journals were represented as full entities with metadata including publisher, language, indexing, CiteScore, quartile, category, APC, editor, and scope.

Administration

The super-admin area included:

user management,
team management,
permissions,
languages,
countries,
journal categories,
indexed/reference data,
blacklist/governance controls.

159. Short Website Card Copy

Iranian Clinical Case Reports Platform

Built a Laravel/Livewire medical research repository with multi-step structured case registration, XML import, journal metadata, nested Boolean search, review workflow, and RBAC.

160. Alternative One-Liners

Architecture-Oriented

Developed a relational clinical case-report platform combining structured medical data, scientific metadata, XML ingestion, and Boolean retrieval.

Laravel-Oriented

Built a Laravel/Livewire research platform with multi-step dynamic forms, repeatable entities, XML import, advanced search, and permissions.

Data-Oriented

Designed a normalized scientific database for clinical case reports covering authors, journals, clinical data, diagnostics, interventions, and educational metadata.

Research-Oriented

Implemented a PubMed-inspired localized platform for registering, reviewing, importing, and searching Iranian clinical case reports.

161. Suggested Website Slug

/projects/iranian-clinical-case-reports

Alternative:

/projects/clinical-case-report-platform

162. Cover Direction

Title

Iranian Clinical Case Reports

Subtitle

Medical Case Repository & Research Platform

Supporting Line

Laravel · Livewire · Structured Clinical Data · XML · Search

Visual Direction

The cover should communicate:

CLINICAL CASE
→ STRUCTURE
→ INDEX
→ SEARCH
→ REVIEW

Visual elements:

medical case/report document,
structured data nodes,
journal/document icon,
search field,
XML symbol,
relational/database graph,
medical cross/clinical symbol,
clean research-oriented blue/teal palette.

Avoid making it look like:

a hospital management system,
a patient-monitoring dashboard,
a generic medical website,
an AI diagnosis product.

The visual identity should communicate:

scientific clinical data repository and retrieval platform

163. Modern V2 — Recommended Stack

A modern rebuild could use:

Backend:
Laravel

API:
REST / JSON

Frontend:
Angular
or
Vue

Database:
PostgreSQL

Search:
PostgreSQL FTS / pg_trgm
or
Elasticsearch / OpenSearch

Queue:
Redis + Laravel Queue

Storage:
Private Object Storage / S3-Compatible

Authorization:
RBAC / Policy Layer

164. Modern V2 — Domain Modules

CaseReports
Authors
Journals
Patients
Diagnostics
Interventions
Literature
Imports
Search
Workflow
Identity
Permissions
Audit

165. Modern V2 — Search Architecture

Database
   ↓ events
Search Indexer
   ↓
Elasticsearch/OpenSearch
   ↓
Search API
   ↓
Web UI

If dedicated search remains unavailable:

PostgreSQL
+
tsvector
+
GIN
+
pg_trgm

is a robust alternative.

166. Modern V2 — Import Architecture

XML File
   ↓
Format Adapter
   ↓
Validation
   ↓
Canonical DTO
   ↓
Domain Services
   ↓
Transactional Persistence
   ↓
Indexing

167. Modern V2 — Workflow Architecture

Use an explicit state machine:

Draft
Submitted
Under Review
Changes Requested
Approved
Published
Rejected

The exact states should be adapted to the real business process.

168. Modern V2 — Permission Architecture

Preferred model:

User
↔
Role
↔
Permission

plus record-level policies.

Examples:

edit own draft,
review assigned cases,
manage journals,
manage users,
publish cases.

169. Modern V2 — Audit Architecture

Record:

Who
What
When
Before
After

for sensitive actions.

170. Modern V2 — Medical Data Protection

Key concerns:

de-identification,
consent,
least privilege,
encrypted transport,
secure storage,
audit logging,
retention,
controlled export.

These are mandatory design concerns for any serious deployment involving patient-related data.

171. Modern V2 — Search Synonyms

Medical search benefits from synonym management.

Example:

GOO
↔
gastric outlet obstruction

A search engine such as Elasticsearch/OpenSearch can support analyzers and synonym filters.

172. Modern V2 — Controlled Vocabulary

Future expansion could integrate controlled vocabularies.

Potential examples include:

MeSH,
SNOMED CT,
ICD,

but only where licensing and project scope allow.

These were not claimed as historical features.

173. Modern V2 — ORCID Integration

The existing ORCID field could evolve into verified ORCID integration.

Conceptually:

Author
→ ORCID API
→ Verified Researcher Identity

This is a future enhancement.

174. Modern V2 — DOI / Crossref

Publication metadata could be enriched via DOI/Crossref adapters.

Again, this is a future extension, not historical functionality.

175. Modern V2 — Publication Export

A future system could export metadata as:

XML,
JSON,
JATS,
RIS,
BibTeX.

This would improve research interoperability.

176. Modern V2 — API

An API-first design would support:

Web Frontend
Mobile App
Partner Systems
Research Integrations

using the same backend.

177. Modern V2 — Search Explainability

For complex Boolean searches, the system could expose:

Why did this case match?

Example:

Matched keyword: diabetes
Matched phrase: gastric outlet obstruction
Matched author criterion

This can improve researcher trust.

178. Modern V2 — Saved Searches

Researchers could save complex queries.

Example:

My Gastroenterology Search

and rerun it later.

179. Modern V2 — Notifications

Saved searches could optionally notify users when new matching cases are published.

This would convert search into a research-alert system.

180. Modern V2 — Research Dashboard

Potential dashboard metrics:

Cases by Specialty
Cases by Journal
Cases by Country
Cases by Keyword
Cases by Year
Review Status

Only as future capabilities unless historical evidence exists.

181. Final Portfolio Statement

The project should not be introduced as:

“a medical website.”

Its real value is the architecture behind the content.

The strongest final description is:

I developed a Laravel/Livewire clinical case report repository and research platform based on a doctoral Library and Information Science concept for a localized, low-cost PubMed-inspired system. The platform supported simple and full structured case registration, repeatable clinical entities, scientific metadata, XML ingestion, journal registration, Boolean search, review workflows, and role-based administration, with an Elasticsearch integration path prepared for future expansion.

Conceptually:

CASE SUBMISSION
      ↓
STRUCTURED MEDICAL DATA
      ↓
SCIENTIFIC METADATA
      ↓
REVIEW / GOVERNANCE
      ↓
INDEX / SEARCH
      ↓
RESEARCH DISCOVERY

182. Portfolio Strength Summary

This project demonstrates the ability to design and implement a system that combines:

Complex Relational Data
+
Dynamic Forms
+
Scientific Metadata
+
Clinical Information
+
Search
+
XML Interoperability
+
Workflow
+
RBAC

That combination makes it one of the stronger architecture-heavy projects in the portfolio.