4 ms·

Thinking back on the overall strategy, would it have been better to "just" digitize, OCR and timestamp the coordinating documents for logging and audit purposes

Thinking back on the overall strategy, would it have been better to "just" digitize, OCR and timestamp the coordinating documents for logging and audit purposes? A "document management system" rather than "an eldercare management system"? That way it's "just" "Pull up the most recent documents relating to or updated for patient Doe, Jane" or "What has changed in the medications prescribed in this district?" The Document Management System would still manage all the PDFs or caretaker notes, but would (eventually) be searchable, and would still support the primary workflow of "I just want to see all the recent documentation for my patient" or "This is caretaker Alex's most recent route assignment document".

Jtsummers 5y ago
Right. When I've seen these kinds of efforts they seem to take one of two paths: 1. Specialized, monolithic systems. These try to do everything for everyone and usually end up devolving into the 12-month (or longer) release cycles. "Monolith" doesn't mean monolith vs microservice in this context. Just that the system is trying to be all encompassing. This is the norm. It rarely works well because it massively increases the cost for change (money, personnel, and time) even for what should be minor things (Oh, you need a custom report? We'll get it to you next year.). 2. Generalized, flexible systems. A document management system like you discuss would be one potential solution. These tend to be more data-oriented (sharing a common database or a common set of databases) with potentially custom front ends. The front ends tend to permit flexibility for the user, including generating their own queries and workflows. These usually work out better, but are not that common among mega corporation or government digitization efforts. The former is easier to "sell". You get to manage a massive contract, it looks more productive than it is. The latter tends to be more grassroots, an internal effort. The former is highly visible, the latter is nearly invisible. Related, people tend to overvalue work that appears difficult and undervalue work that appears easy. The second approach tends to make modifications "trivial", so the managers ask, "What are we paying you for?"

Jtsummers 5y ago

Right. When I've seen these kinds of efforts they seem to take one of two paths: 1. Specialized, monolithic systems. These try to do everything for everyone and usually end up devolving into the 12-month (or longer) release cycles. "Monolith" doesn't mean monolith vs microservice in this context. Just that the system is trying to be all encompassing. This is the norm. It rarely works well because it massively increases the cost for change (money, personnel, and time) even for what should be minor things (Oh, you need a custom report? We'll get it to you next year.). 2. Generalized, flexible systems. A document management system like you discuss would be one potential solution. These tend to be more data-oriented (sharing a common database or a common set of databases) with potentially custom front ends. The front ends tend to permit flexibility for the user, including generating their own queries and workflows. These usually work out better, but are not that common among mega corporation or government digitization efforts. The former is easier to "sell". You get to manage a massive contract, it looks more productive than it is. The latter tends to be more grassroots, an internal effort. The former is highly visible, the latter is nearly invisible. Related, people tend to overvalue work that appears difficult and undervalue work that appears easy. The second approach tends to make modifications "trivial", so the managers ask, "What are we paying you for?"