Fifteen Places to Look and No Idea Which One Is Current

Somebody in your organization maintains a document that lists where the other documents are. It is probably a Word file. It has a name like "Resource Locations FINAL v3" and it lives on a shared drive, which is one of the places it describes.

I have seen versions of this in every health system I have worked with, and it is always the same artifact: an honest attempt by a competent person to solve a problem that cannot be solved at that layer. They are trying to build an index by hand, for a corpus that grows faster than they can index it, in an organization where nobody told them when a new location was added.

The document is never wrong, exactly. It is just always behind.

Count them honestly

Before arguing about a fix, it is worth doing the inventory properly, because most leaders underestimate their own count by about half.

Start listing. The intranet. SharePoint, which is not the same thing as the intranet even though both are Microsoft and both are described internally as "the portal." A departmental shared drive with a letter that everyone still calls by the letter. Teams channels, where the actual current answer usually sits as a message with eleven replies under it. The EMR's own built-in help, which is vendor content and does not know anything about your build. The tip sheets that informatics maintains separately from the EMR's help. Printed binders at nursing stations, at least one of which is genuinely authoritative for something. Email chains that get forwarded to new hires as orientation material. The learning management system, which contains modules whose content is more current than the policy the module was built from. A ticket system full of resolutions. A policy management platform that has the approved version of everything and is used by almost nobody outside of the people who administer it.

That is eleven and I have not mentioned anything unusual to a particular organization. Add the ones specific to you — the pharmacy formulary tool, the credentialing system, the departmental wiki someone stood up in a burst of energy in a year you would have to look up.

None of these is a bad system. Most of them are doing exactly the job they were purchased to do. That is the part that makes this hard to fix by consolidation.

The problem is not fragmentation

The instinct is to consolidate. Pick one, migrate everything, decommission the rest. I have watched several organizations attempt this and I have not seen one finish.

They do not fail because the migration is technically difficult. They fail because each of those systems has a constituency with a legitimate reason for it. The policy platform exists because a regulator wants versioned attestation. The LMS exists because education needs completion tracking. Teams exists because that is where people actually talk. Tell the policy office their platform is being retired in favour of a wiki and you will discover exactly how much authority that office has, which is more than you think.

So the consolidation stalls about two-thirds of the way through, and now you have twelve places instead of eleven, because the new one did not replace anything. It joined.

I have come around to thinking that fragmentation of storage is not actually the problem. It is a symptom, and it is a symptom of something the organization is doing correctly, which is buying specialized tools for specialized jobs.

The real problem is narrower and more tractable: no one of those systems can tell you which of them is authoritative for a given question. And no person can either, reliably, which is why the shared-drive index document exists.

One retrieval surface, not one storage location

The distinction I would push on is between where a document lives and where a question goes.

Every one of those eleven systems is a storage decision, and storage decisions are made for good reasons — retention, access control, workflow integration, the fact that the vendor bundled it. Those reasons do not go away and they should not.

Retrieval is a different decision, and it is one almost nobody makes deliberately. Retrieval currently happens by folklore. A person learns, over their first year, that questions about scheduling go to the Teams channel, questions about a procedure go to the binder, and questions about anything the surveyor might ask go to the policy platform because that is the version with a signature on it. That folklore is real institutional knowledge and it takes about a year to acquire, which means every new hire spends a year unable to find things, and every float and traveler never acquires it at all.

If you separate the two decisions, the tractable version of the project appears. Leave the storage alone. Build one place a question can go, which knows about all of them, and which can rank an answer by whether the source is current and approved rather than by whether it happened to match the words someone typed. The systems keep their constituencies. The user gets one door.

That is the shape of what Solution Compass does, and I would rather describe it as a narrowing of the problem than as a product category. The ambition is not to be the place documents live. It is to be the only place a person has to remember.

The part that is still work

I do not want to make this sound like a switch you flip.

Pointing a retrieval layer at eleven sources and calling it finished produces a very confident system that returns the second-most-current version of things. Every one of those locations contains material that is obsolete, superseded, or was never authoritative in the first place, and a retrieval system has no way of knowing that unless someone tells it.

So the work is real and it is unglamorous. Somebody has to walk each source and decide what is in scope. Somebody has to decide, for the cases where two sources disagree, which one wins — and to have that decision recorded rather than adjudicated fresh each time. Somebody has to say out loud that the departmental wiki is reference material and not policy, which will annoy the department that built it.

That is a few weeks of committee work and it is the part vendors do not put in the proposal. It is also the part that determines whether the thing works, far more than any technical choice downstream of it.

Where I would start

Take your worst-performing new hire cohort — whichever role has the highest turnover and the steepest learning curve, which in most health systems is patient access or the service desk — and ask five of them to write down every time they had to ask a colleague where something was. Not what the answer was. Where they had to go to get it.

Two weeks of that gives you a ranked list of your actual retrieval failures, weighted by how often they happen, produced by the people least contaminated by knowing the folklore.

Then look at the shared drive for that Word file. Whoever has been maintaining it by hand has been doing your organization a service nobody assigned them, and they will be able to tell you more about this problem in twenty minutes than any assessment you could commission.