Skip to main content
Glama
spec.md12.8 kB
# Feature Specification: Enhanced Medical Image Search **Feature Branch**: `001-medical-image-search-v2` **Created**: 2025-11-21 **Status**: Draft **Input**: User description: "Create a feature spec for improving the medical image search functionality" ## User Scenarios & Testing *(mandatory)* ### User Story 1 - Semantic Search with Relevance Scoring (Priority: P1) Clinicians need to find chest X-rays using natural language queries like "pneumonia with pleural effusion" rather than rigid keywords, and see why each result was matched. **Why this priority**: This is the core value proposition of the feature. Without semantic search working reliably, users will fall back to manual browsing, making the tool unusable for its intended purpose. **Independent Test**: Can be fully tested by submitting a natural language query (e.g., "chest X-ray showing fluid in lungs") and verifying that: 1. Results are returned ranked by semantic relevance 2. Each result displays a similarity score 3. Results include images matching the clinical description **Acceptance Scenarios**: 1. **Given** the image database has X-rays with various findings, **When** a clinician searches "chest X-ray of pneumonia", **Then** the system returns images with pneumonia findings ranked by semantic similarity scores (0-1), with scores > 0.7 indicating strong matches 2. **Given** a query "bilateral infiltrates", **When** the search executes, **Then** results include textual explanations of why each image matched (e.g., "matched: bilateral pattern detected, opacity in both lung fields") 3. **Given** the NV-CLIP embedding service is unavailable, **When** a search is performed, **Then** the system gracefully falls back to keyword search and displays a warning message --- ### User Story 2 - Filter and Refine Results (Priority: P2) Users need to filter search results by view position (PA, AP, Lateral), patient demographics, or study date to narrow down findings. **Why this priority**: Once semantic search works (P1), filtering becomes essential for clinical workflows where radiologists need specific views or timeframes. **Independent Test**: After searching "chest X-ray pneumonia", apply filters for: - View position: "PA" only - Date range: Last 30 days - Verify only matching results are displayed **Acceptance Scenarios**: 1. **Given** search results contain mixed view positions, **When** user selects "PA View" filter, **Then** only PA (posteroanterior) chest X-rays are displayed 2. **Given** results span multiple months, **When** user sets date range filter "2024-01-01 to 2024-03-31", **Then** only images from Q1 2024 are shown 3. **Given** multiple filters are active, **When** user clicks "Clear Filters", **Then** all filters reset and full result set displays --- ### User Story 3 - Image Preview with Clinical Context (Priority: P2) Radiologists need to preview images with associated clinical notes, patient history, and diagnostic reports before opening the full DICOM viewer. **Why this priority**: Saves time by allowing quick assessment without loading full medical records. Enhances existing search results. **Independent Test**: Click on any search result and verify: - Thumbnail enlarges to full preview - Associated FHIR clinical note displays - Patient demographics shown (ID, age, sex) - Study metadata visible (date, view, technique) **Acceptance Scenarios**: 1. **Given** a search result list, **When** user clicks on an X-ray thumbnail, **Then** a modal displays the full-resolution image with zoom/pan controls 2. **Given** an image preview is open, **When** clinical notes exist for that study, **Then** the notes display alongside the image with symptoms, indications, and findings sections highlighted 3. **Given** a preview modal is open, **When** user presses ESC or clicks outside, **Then** modal closes and returns to search results --- ### User Story 4 - Batch Export and Comparison (Priority: P3) Researchers need to export multiple images matching specific criteria for analysis, and compare images side-by-side. **Why this priority**: Supports research workflows but not critical for initial clinical adoption. **Independent Test**: 1. Select 5 images from search results using checkboxes 2. Click "Export Selected" and verify ZIP download contains all images with metadata JSON 3. Click "Compare" and verify side-by-side view with synchronized zoom **Acceptance Scenarios**: 1. **Given** search results displayed, **When** user selects multiple images via checkboxes, **Then** a "Export Selected (N)" button appears in the toolbar 2. **Given** 10 images are selected, **When** user clicks "Export Selected", **Then** a ZIP file downloads containing JPG images and a metadata.json file with patient IDs, study dates, and finding descriptions 3. **Given** 2-4 images are selected, **When** user clicks "Compare", **Then** a comparison view displays images side-by-side with synchronized zoom/pan and synchronized window/level adjustment --- ### User Story 5 - Search History and Saved Queries (Priority: P3) Clinicians frequently repeat queries for their specialty (e.g., pulmonologists always searching lung conditions) and need quick access to previous searches. **Why this priority**: Improves efficiency for power users but not essential for MVP. **Independent Test**: 1. Perform 3 different searches 2. Navigate to "History" tab 3. Verify all 3 queries listed with timestamps 4. Click "Save Query" on one search 5. Verify it appears in "Saved Searches" with custom name **Acceptance Scenarios**: 1. **Given** a user has performed searches this session, **When** user clicks "Recent Searches" dropdown, **Then** last 10 queries display in reverse chronological order 2. **Given** a query "bilateral pneumothorax view:PA", **When** user clicks "Save This Query" and enters name "PTX Surveillance", **Then** query saves and appears in "Saved Searches" list 3. **Given** saved query exists, **When** user clicks it from sidebar, **Then** search executes immediately with saved parameters --- ### Edge Cases - What happens when a query contains medical terms not in the embedding model's vocabulary (e.g., rare disease names)? - **Expected**: System should tokenize and attempt partial matches, explaining "limited semantic understanding for term: [rare-term]" - How does system handle very long queries (>500 characters)? - **Expected**: Truncate to 500 chars with warning message "Query truncated to 500 characters for processing" - What if image files referenced in database no longer exist on disk? - **Expected**: Display placeholder image with "Image not available" message, but still show metadata and allow user to report broken link - How does system behave when database contains 10,000+ images and user doesn't apply filters? - **Expected**: Paginate results (50 per page), display processing time, suggest using filters for faster results - What happens when user's browser doesn't support WebGL for image rendering? - **Expected**: Fall back to standard IMG tags, disable zoom features, show compatibility notice ## Requirements *(mandatory)* ### Functional Requirements - **FR-001**: System MUST generate semantic embeddings for text queries using NV-CLIP model and return results ranked by cosine similarity score - **FR-002**: System MUST display similarity scores (0.00 to 1.00) for each search result with visual indicators (color coding: green ≥0.7, yellow 0.5-0.7, gray <0.5) - **FR-003**: System MUST support filtering results by: view position (PA/AP/Lateral/LL), study date range, patient ID pattern, and similarity score threshold - **FR-004**: System MUST retrieve and display associated FHIR DocumentReference clinical notes for each image when available - **FR-005**: System MUST provide image preview with zoom (1x-5x), pan, and window/level adjustment controls - **FR-006**: System MUST implement graceful degradation when NV-CLIP service is unavailable, falling back to keyword search on ViewPosition and StudyID fields - **FR-007**: System MUST support batch export of selected images (max 100) as ZIP containing JPG files and metadata JSON - **FR-008**: System MUST paginate results (default 50 per page) for queries returning >50 images - **FR-009**: System MUST cache embedding computations for common queries to improve response time - **FR-010**: System MUST log all searches with query text, result count, and execution time for analytics **Uncertain Requirements**: - **FR-011**: System SHOULD support DICOM viewer integration [NEEDS CLARIFICATION: Which DICOM viewer? Cornerstonejs? OHIF? Embedded or external launch?] - **FR-012**: System SHOULD anonymize patient data in exports [NEEDS CLARIFICATION: Remove patient IDs? Hash them? Requires HIPAA compliance review] ### Key Entities - **ImageSearchQuery**: User's search request with text, filters (view position, date range), and pagination parameters - **ImageSearchResult**: Individual matched image with metadata (ImageID, StudyID, SubjectID, ViewPosition, file path), similarity score, and optional thumbnail - **NVCLIPEmbedding**: 1024-dimensional vector representation of query text or image content - **ClinicalContext**: Associated FHIR DocumentReference with clinical notes, findings, and patient demographics - **SearchSession**: User's search history with queries, timestamps, and result counts - **SavedQuery**: Named search with predefined filters and parameters for repeated use ## Success Criteria *(mandatory)* ### Measurable Outcomes - **SC-001**: Users can find relevant chest X-rays in under 10 seconds for natural language queries (measured from query submission to first result display) - **SC-002**: Semantic search returns top-5 results with ≥0.6 similarity scores for 80% of common clinical queries (e.g., "pneumonia", "cardiomegaly", "pleural effusion") - **SC-003**: System handles 50 concurrent users performing image searches without degradation (response time <5s for p95) - **SC-004**: Fallback keyword search activates within 2 seconds when NV-CLIP service fails - **SC-005**: 90% of users successfully apply at least one filter to refine results (telemetry tracked) - **SC-006**: Image preview loads in <3 seconds for p95 of requests - **SC-007**: Zero patient data leaks in exported files when anonymization enabled (validated via automated tests) ## Technical Considerations ### Current Implementation Gaps 1. **No relevance scoring**: Current implementation returns images but doesn't expose similarity scores to users 2. **No filtering UI**: Database supports ViewPosition, StudyID, etc., but no UI controls exist 3. **No clinical context integration**: Images returned without associated FHIR clinical notes 4. **Image paths may be invalid**: Database has file paths but no validation if files exist or are accessible from Streamlit 5. **No caching**: Every query recomputes embeddings even for identical searches 6. **Error handling**: Current fallback to keyword search happens silently without user notification ### Database Schema (VectorSearch.MIMICCXRImages) Based on code inspection, table contains: - `ImageID`: Unique identifier - `StudyID`: Study identifier - `SubjectID`: Patient identifier - `ViewPosition`: Radiographic view (PA/AP/Lateral/LL/etc.) - `ImagePath`: File system path to image - `Vector`: 1024-dim embedding vector for semantic search ### Dependencies - **NV-CLIP**: NVIDIA multimodal embedding service (requires NVIDIA_API_KEY) - **IRIS Vector Search**: InterSystems IRIS vector database with VECTOR_COSINE function - **FHIR Resources**: DocumentReference resources in SQLUser.FHIRDocuments table - **Streamlit**: Frontend framework (currently used) - **Plotly**: Not directly needed for images, but could support result visualizations ### Open Questions 1. **Image Storage**: Are images stored locally on Streamlit server or on remote IRIS server at 3.84.250.46? 2. **Image Format**: Are files DICOM (.dcm) or converted to JPG/PNG? 3. **Thumbnail Generation**: Should system pre-generate thumbnails or create on-the-fly? 4. **Authentication**: Does search need user authentication to comply with HIPAA? 5. **Audit Trail**: Should system log which user accessed which patient images? ## Next Steps 1. **Review & Approval**: Share spec with stakeholders (clinicians, compliance team) 2. **Technical Design**: Create implementation plan addressing: - UI mockups for search results with filters - API endpoint design for image retrieval - Caching strategy for embeddings - Error handling and fallback UX 3. **Prototyping**: Build P1 user story (semantic search with scoring) as proof-of-concept 4. **Testing Strategy**: Define test datasets and expected results for semantic search accuracy

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/isc-tdyar/medical-graphrag-assistant'

If you have feedback or need assistance with the MCP directory API, please join our Discord server