Created an enterprise EHR architecture and web service specification (that also did personal health records, public health, and clinical trial design/management/data analysis) for the US Dept. of Defense (Military Healthcare System) and the Veterans Affairs in just under 2 months ("Capability Set Zero") that would have been a radical improvement over extant EHRS as it was modular, easy to develop new functions, secure, designed to be resilient, interoperable, work in a heterogeneous environment (including need to use legacy systems), and need to be able to work in a deployed, military combat setting on minimal hardware with sync/store-and-forward capability.
It was designed to automate healthcare coordination and delivery, augment the native intelligence of healthcare providers by the ubiquitous delivery of patient-specific clinical decision support at the point of care. It was designed around the premise of a (machine) learning healthcare system, and widespread use of various AI methods (many of which have been proven to work in healthcare for 50 years already!). It did so through the explicit management of complexity, treating it as a first class entity, rather than trying to simplify the most complex domain of human activity. Not only that, but it had a very robust data management architecture that was designed to work even if there were multiple components inoperable due to a malicious attack (or a bug), and the same approach meant that entire components could be replaced whenever there was a better way of doing it, or just have another implementation of the same service stood up based on different technology to provide redundancy in face of attack.
The data management was drawn from an earlier design I did when creating a health record bank start up, that was supposed to get stood up on Sourceforge as openCDR (Clinical Data Repository), and still might when I get to it! But, the CDR provided transactional Retrieve-Locate-Update Services (RLUS) and entity tracking/management/directory (with both a HL7 and LDAP API), and real-time population of an enterprise data warehouse (EDW) with both highly optimized OLAP for the most common uses and a full scale Hadoop ecosystem for anything that did not do. It was designed to work with multiple different database technologies all as the same time.
It was designed to allow adding a new storage capability as a routine activity, as database fads come and go. Since it was intended to run on multiple database platforms, there was a good degree of resiliency that comes from massive data redundancy. It was also intended to allow multiple different implementation of various APIs, as well as using legacy systems with a wrapper to conform with the EHRS specifications as a means of supporting a heterogeneous design.
While it would be unlikely that even a single major component was down very long, my goal was less than 53 minutes of downtime the first year of full deployment (99.99% uptime) and less than 32 minutes of downtime subsequent years (99.9999% uptime). Because of the design, this was reasonable targets as most of the runtime could be built from existing open-source or commercial software with well established track records for durability. It had a separate role-based access control that was dependant on the users clinical credentials, so someone who was allowed to see a schedule but not change it would be interpreted as not giving them the control UI widgets with change/add new appointment, etc. There was another low-level individual data-element attribute-based access control used for privacy and compartmentalization of information.
Pretty much every thing was loosely coupled, and it was anticipated that most of the specific user functionality would be created without writing software, at least in the conventional sense. It was entirely model-drive architecture. This meant that a change in a data element definition or application behavior could be deployed trivially.
Because of the need to be field deployable, it was designed to run on a laptop w/ basic clients on handheld devices even w/o communication to central servers/cloud as would be the case in an Army battalion aid station.
It would have taken us about 3 years to develop with up to 30 programmers and 30 clinical informatics experts to have basic functionality, including the ability to manage problem lists (including allergies/intolerances/risk of disease), automate ordering, document patient care, integrate with devices (like cardiac monitors, BP cuffs, etc.), interface with lab systems (and later, provide our own), interface with/replace pharmacy systems, basic decision support (which would have been more than most commercial EHRS do), results retrieval, integration with PACS, interface to local health information exchanges and immunization registries, notifications/alerts/reminders, secure messaging (real-time text, voice messages, async messages both with and without structured templates, real time video/voice) , a web-based GUI, some apps for Android/iOS (we wanted to support a BYOD in a secure fashion, e.g. so patient's appointment show up on the calendar they use on their phone/Outlook, etc. and they could use regular email clients security for messages to their provider), ECGs, and workflow/task management (with provision for sophisticated branching logic, looping behavior, if..then..else and exception management including escalation and notification of other providers of problems or tasks not completed on time) out to all DoD and VA facilities.
Once core capabilities were working, I would have liked to have started work on a thick-client GUI that provided functionality that was not practical at the time via a web browser, mostly due to the need to download large vocabulary code sets to populate in-browser type as you write, voice recognition, and some of this is less a concern today, but in bandwidth constrained use would have been. Because these were the use cases where a separate server was needed, I initially was expecting an Eclipse RCP application, provided some of the issues w/ Java security could be resolved, as we needed it to not allow access to anything even if a laptop was captured while open and running. Eclpse provided much of the backend server capability needed as well as having a decent GUI and data management capability. The update mechanism (where you can synch up a plug-in to update it anytime--which was not a common software feature at the time) also was appreciated as it would have allowed us to push out updates whenever they were ready and know that our users would have current software.
Initially, it would NOT have done everything commercial EHRS claim to do, but it would do EVERYTHING ESSENTIAL, including the many capabilities lacking in commercial EHRS (e.g. AI based provision of clinical decision support at point of care, like all the academic EHRS did that showed benefit; many commercial EHRS do terrible jobs on the most critical aspects and are driving young, technically savvy, physicians out of medicine they are so bad.).
But, congress in their infinite wisdom, stepped in, and insisted that they deploy a "commercial off-the-shelf solution" because this approach would take too long. They are now a decade behind schedule and a billion dollars over budget.
Somehow, I think we all missed an opportunity there to shine.
Know anyone looking for a slightly used medical informaticist who has a killer EHRS/PHRS/Clinical trial management system/public health platform???
LoL
Do an end-run around/go over the head of the senior partner in the consulting company I was contracted through and get the plans to the clients BEFORE the entire project was scuttled by congress. They wanted to wait for a new RFP to be released and submit a proposal to create what I already created. I didn't think that was completely fair and resigned over the issue.
Also, more animated graphic slides which illustrated the principles would be helpful, as a lot of the architecture and core design principles were hard to appreciate if you were not familiar with the myriad technical aspects of such a complex system, and many design principles were truly novel (e.g. "explicit management of complexity external to the runtime", "algorithmic temporal optimization of multiple patient activities based on available resources"--I.e. Teddy Roosevelt's "Do what you can with what you have where you are", and the "low-hanging fruit antipattern") just are not something you can just look up on Wikipedia
