Healthcare Network Builds Internal Knowledge System

Context

A regional healthcare network operating 12 facilities—three hospitals and nine outpatient clinics—had a knowledge management problem that was both common and consequential. Clinical and administrative policies were scattered across SharePoint sites, shared drives, PDF repositories, and an outdated intranet. Each facility had slightly different versions of some documents. No single search covered all sources.

The practical impact: a nurse trying to confirm a medication administration policy might check the intranet, find an outdated version, check the departmental SharePoint, find nothing, and eventually call a supervisor—who might know the answer or might have to search themselves. An HR coordinator trying to answer a benefits question would navigate three different document libraries. A compliance officer preparing for an audit would spend days gathering the current versions of relevant policies.

The network had approximately 14,000 policy documents, clinical guidelines, procedure manuals, and reference materials across all sources. Staff estimated they spent an average of 18 minutes per information search. With thousands of searches happening daily across the network, the cumulative time cost was substantial. Worse, the difficulty of finding current information contributed to compliance drift—staff would rely on memory or outdated printouts rather than searching for the current version of a policy.

Constraints

Healthcare knowledge systems operate under constraints that fundamentally shape the architecture:

• HIPAA compliance. While the knowledge base itself doesn’t contain patient data, the infrastructure must be HIPAA-compliant because it operates within the same environment that handles PHI. All components need to meet the network’s security requirements, including BAA-covered services only.
• Accuracy is non-negotiable. In healthcare, acting on outdated or incorrect policy information can have patient safety consequences. The system must surface current, authoritative versions of documents and make the source clearly visible. Hallucinated or inaccurate responses are unacceptable.
• Role-based access. Not all documents are appropriate for all staff. Clinical protocols, HR policies, executive communications, and financial documents have different access requirements. The knowledge system must respect existing access controls.
• Offline consideration. Some clinical areas have limited or intermittent network connectivity. The system needed to be designed for graceful degradation rather than complete failure in low-connectivity situations.

Approach

We structured this as a 10-week engagement in three phases.

Phase 1: Knowledge audit and architecture (weeks 1-3). We cataloged document sources across all 12 facilities, mapped access control requirements, assessed document quality and currency, and designed the system architecture. The audit revealed that approximately 30% of documents were duplicates or outdated versions, and many documents existed in multiple locations with inconsistent versioning.

Phase 2: Pipeline development and indexing (weeks 4-7). We built the document ingestion pipeline, processing infrastructure, vector database, and retrieval system. This phase included significant work on document deduplication, version resolution (identifying the authoritative version when multiple versions exist), and metadata enrichment.

Phase 3: Application development and rollout (weeks 8-10). We built the search interface, integrated it with the network’s single sign-on system, conducted user testing across multiple roles and facilities, and rolled out in a phased approach starting with two pilot facilities.

Architecture

Document ingestion pipeline. Connectors pull documents from SharePoint, shared drives, and the intranet on a scheduled basis. Each connector handles the specific API or file system protocol for its source. New and modified documents are detected through change tracking (SharePoint) or file system monitoring (shared drives).

Processing service. Ingested documents go through a processing pipeline: format conversion (PDF, Word, HTML to standardized text), structure extraction (headings, sections, tables), metadata extraction (author, date, department, document type, version), and deduplication scoring against existing documents. Documents identified as potential duplicates are flagged for a knowledge manager to resolve.

Embedding and indexing. Processed documents are chunked using a healthcare-specific strategy that preserves policy structure (keeping procedures, exceptions, and references together rather than splitting them across chunks). OpenAI Embeddings generate vector representations that are stored in Pinecone alongside the document metadata.

Retrieval layer. The retrieval service uses hybrid search—combining vector similarity with keyword matching and metadata filtering. This approach handles both conceptual queries (“what’s our policy on patient transfers between facilities?”) and specific lookups (“medication administration policy MA-2024-031”). Results are filtered by the requesting user’s role and facility-level access permissions.

Application layer. A React-based search interface provides two modes: direct search (type a question, get relevant documents and highlighted passages) and conversational search (ask follow-up questions to narrow down results). Every response includes source document links, version dates, and confidence indicators. The system never generates text that isn’t grounded in a specific document.

Implementation Details

Version resolution. One of the more complex technical challenges was handling multiple versions of the same document across different sources. We built a version resolution system that identifies document families (variations of the same policy), determines the authoritative version based on metadata signals (most recent date, designated repository, approval indicators), and ensures search results return the current version while maintaining a link to version history.

Chunking for healthcare content. Standard chunking strategies performed poorly on policy documents because they split procedural steps, separated exceptions from the rules they modify, and broke up reference tables. We developed a structure-aware chunking approach that respects document hierarchy—keeping complete sections, procedures, and tables as atomic units. This increased average chunk size but significantly improved retrieval relevance.

Grounding enforcement. The system is designed to never generate unsourced content. When users ask questions in the conversational interface, the response is assembled from retrieved passages with explicit citations. If the retrieved documents don’t contain sufficient information to answer the question, the system says so and suggests related documents rather than generating a speculative response.

Access control implementation. Document-level access permissions are synced from the network’s Active Directory groups and SharePoint permissions. When a user searches, the retrieval layer filters results to documents they’re authorized to access before ranking. This happens at query time, so permissions are always current—no lag between a permission change and the search reflecting it.

Results

After 90 days of network-wide deployment:

• Average search time dropped from 18 minutes to 2 minutes. This includes the time to formulate the query, review results, and confirm the document is current and authoritative. The improvement is most dramatic for cross-departmental searches that previously required checking multiple sources.
• Compliance audit findings decreased from 23 to 6 per quarter. Staff are finding and following current policies because it’s now easier to search than to rely on memory. The six remaining findings were in areas where policies themselves needed updating, not where staff failed to find them.
• Staff satisfaction with information access improved from 3.1 to 8.4 out of 10. Surveyed across all roles and facilities after 60 days of use. The highest satisfaction increases came from clinical staff and new hires, who previously found the information landscape most difficult to navigate.
• Document deduplication reduced the effective library by 28%. The knowledge audit and deduplication process eliminated 3,900 duplicate or outdated documents, reducing confusion and improving search relevance.

Lessons

The knowledge audit is the engagement. We initially scoped the audit as a two-week prerequisite. It expanded to three weeks and could have taken longer. The state of document management across 12 facilities was worse than anyone estimated—not because of neglect, but because 15 years of organic growth had created a tangle that no one had visibility into. Addressing this was as valuable as the search technology itself.

Chunking strategy is the biggest lever for retrieval quality. We tested five different chunking approaches. The difference between the worst and best was dramatic—from 62% to 91% relevance on our test query set. For structured documents like policies and procedures, preserving document structure in chunks matters more than chunk size optimization.

Grounding is trust. The decision to never generate unsourced text was questioned early on (“wouldn’t it be more helpful if it synthesized?”), but it proved critical for adoption. Clinical staff trust the system because they can see exactly where every piece of information comes from. In healthcare, that traceability isn’t just nice to have—it’s a requirement.

Next Steps

The network is expanding the system in two directions: adding clinical reference materials (drug databases, treatment protocols) with tighter integration into clinical workflows, and building a compliance monitoring layer that proactively flags when staff in specific departments haven’t accessed updated policies that are relevant to their roles.

Security and Data Handling

The entire system runs within the network’s HIPAA-compliant AWS environment, covered by AWS’s BAA. While the knowledge base does not contain PHI, the infrastructure meets HIPAA requirements because it operates within the same security boundary. All data is encrypted at rest (AES-256) and in transit (TLS 1.2+). Access logs are retained per the network’s compliance retention schedule. The OpenAI Embeddings API is used under an enterprise agreement with a BAA that prohibits data use for model training. Pinecone operates within the same AWS region with equivalent security controls.

This case study represents a real engagement with details modified to protect client confidentiality. Specific metrics are representative of actual results.