As you may have noticed, for the last two weeks, resource pages have not been updated and there was no post last week either. That is because a minor accident resulted in a week’s worth of misery, and not much work being done. Thankfully, things are quickly returning to normal. Oddly, one consequence of my being sidelined for a few days has been a rethinking of EHR Science and the role it plays — something I had considered settled.
Clinical software design is a passion that has grown more intense in the last few years. I have written many times that there is a need for a journal devoted to clinical software design. As things now stand, clinical software research has been mostly relegated to the private sector. An immediate consequence of this arrangement is that all discussions of “innovation” are really just discussions of how to incrementally improve specific products. There are even calls to stop “criticizing” vendors and work with them to improve their products. I have no problem with customers working with vendors to improve their products—that simply makes sense. What does trouble me is the idea that saying clinical care systems could be better is somehow subversive, that researching better system designs is somehow anti-vendor. In the last 10 years, we have experienced an explosion in new technology that allows the creation of clinical systems with features that were not previously possible. Why not explore how these advances can lead to better clinical care systems?
Database technology now supports graphs, objects, and documents in addition to two-dimensional relations. Mature workflow technology is available that can vastly improve process support. Mobile devices are robust, and cloud technology mature. Most current EHR systems do not take advantage of these technologies. openEHR, a clinical data management standard that directly addresses many of the interoperability issues everyone complains about, is ignored in the United States. New technologies are ignored because market leaders are doing well without them. Where will truly innovative products come from then? They must come from new market entrants with products that solve problems significantly better than current systems. Such companies must start small by providing tools for small, independent practices. I am encouraged by the growth in direct primary care, which is an ideal market for new clinical care system designs.
So, how does this pertain to EHR Science? In my last post, I mentioned the planned creation of a site dedicated to clinical software design. Originally, the intent was to create a separate site with a weekly post dedicated to design/architecture challenges. However, over the past week, I decided to try a different approach. First, a little background…
In 1991, I decided to write an EHR of sorts for my personal use. Initially, the goal was to create a system that would make being on-call easier. I thought it would take about six months to create the system, and if I had stuck to the original goal, it might have. But feature creep took over. Five years later, I had a system that was far beyond the original plan. I dubbed the system, prn: Clinical Information Manager. Here are the features it offered.
- Telephone call tracker
- Order tracker with abnormal test follow-up support
- Medication list
- Problem list
- Patient note (unstructured)
- Referral tracker
- Care planner – allowed one to create protocols by patient group (Males > 50), diagnosis, or for a specific patient. Visits and interventions could be specified for any arbitrary period.
- Preventive care tracker
The system was built in FoxPro 2.6, and consisted of a series of modules that shared a database and front-end menu system. It worked well, but was cumbersome. I know; I designed it for my personal use and it still required too many clicks for common actions. After creating a manual, and beta-testing with five doctors, I never pursued it further. Subsequently, I became interested in machine learning and never looked at the code again until digging around in my computer graveyard. I demoed the system at UAB before starting the 1917 EHR Clinic Project. There is no code shared between those systems, only many lessons learned.
This summer while experimenting with Swift, I needed a small project to work on. A “to-do list” seemed like a good way to start, but proved to be too simplistic. After mulling other starter projects, I decided to pull out my prn:CIM design and try it in Swift. Not in one large project—I have learned that lesson— but by building one module at a time. Wanting to share my experiences, I decided to write about this project on EHR Science. However, since whatever I build will include discussions about Swift, software design, clinical concepts, databases, iOS, etc., it made no sense to create a separate design site. Ergo, “Clinical Swift” will make its debut as a subsection of EHR Science.
If all goes well, a free app will appear in the iOS app store within eight months (earlier for the intrepid) or so after I start the official project in December. As before, this will be an on-call record for doctors without an office EHR. As for the original prn:CIM source code, I intend to share it with EFF. They fight ludicrous software patents, and my code and system being from 1991-1995 and before many current systems, might help some new market entrant fight a patent suit. (It may also help me, of course).
Here are a few questions I hope to tackle with the Clinical Swift project.
- Is it possible to create a viable UCD process for small developers without having a large in-house staff? Apple offers testing support assistance, and if I can get 7-10 doctors or other primary care providers who are willing to submit on-going feedback, it will allow me to test a rudimentary design process. In addition, it will allow me to discuss clinical workflow issues directly with active clinicians.
- Is it feasible to connect prn:CIM2 (my name for this incarnation) to a backend BPM suite?
- When computerizing workflows, what should be configurable and how is that best achieved?
- Is a standard data set a viable option for clinical care systems?
- How might graph databases work with clinical workflow data?
- Can MongoDB work as a production clinical care system database component?
I want feedback — lots of it, especially nit-picking design comments. So, when the app becomes available, please download it and kvetch to your heart’s content!
This series (and site subsection) is for the tinkerers, dreamers, problem-solvers, the next generation of clinical software designers, and hopefully a few millionaires, which brings up another change…
Despite past statements and intentions, EHR Science will begin to accept outside content. The layout and design will also change. I named my blog EHR Science because I wanted to explore clinical software design and implementation. I am now inviting anyone who shares that passion to join in and contribute. I cannot start an academic journal dedicated to clinical software design, but I can allow anyone with something to say a place to say it. Let’s talk innovation…