Welcome to Clinical Swift! Those who follow EHR Science know the backstory for this site. Here is a recap for everyone else…
Clinical software design is one of my abiding passions. And by “design,” I mean all aspects — architectural, internal, user interface, and process (see What Do You Mean by EHR “Design”– Architectural, Detailed, User Interface, or Process?). Clinical software is complex, and yet, few resources exist for anyone wishing to master clinical software design and development. There is no “Principles and Best Practices of Clinical Software Development” book. There are no journals that focus exclusively on clinical software engineering.
The EHR incentive programs have led to an increase in EHR-related research, especially as concerns usability. However, that research tends to focus primarily on user interface issues and not the day-to-day challenges of gathering requirements, software engineering principles, mathematical models of clinical concepts, or algorithm design.
Current EHR systems were designed to be replacements for paper charts. Consequently, paper charts are the main design metaphor for today’s systems. Paper charts are passive components that simply provide information–they are data sources. EHR systems designed with paper charts in mind are also mainly data sources, not care-delivery helpers (see Is the Electronic Health Record Defunct?). Clinical care is accomplished via processes, so it seems reasonable that the ideal software design to support clinical work should be process-oriented (see Data and/or Processes: The Designer’s Dilemma—prn: CIM-OnCall, II), which brings me to the goals I have for Clinical Swift.
Clinical Swift is dedicated to asking questions and searching for answers:
- Are there principles for clinical software design/development that differ from other types of software?
- What role can mathematical models play in designing clinical systems?
- What is the best way to incorporate process models into clinical systems?
- Are there design patterns unique to clinical systems?
- How should clinical workflow analysis be used to guide clinical software development?
- Would a standard data set aid interoperability?
- What are best practices for user interface design? Are those best practices role-based?
- How should UIs vary based on the type of clinical work supported (i.e., how do UIs for care coordination differ from those for results management or a typical patient encounter)?
- How does biomedical informatics impact clinical software design/development? Are there informatics principles that are essential for clinical software design/development?
I am not claiming that I will answer any of these questions, only that I intend to explore them. And I am hoping there are others whose curiosity matches mine.
I chose Apple’s Swift programming language because it is a modern language designed specifically for creating modern interactive software. Readability and efficiency are two of its key features. In addition, I am convinced that mobile technology holds the greatest promise for supporting clinical work in clinics and at bedsides in the least obtrusive manner. Mobile systems offer input and data capabilities that are not present in browser-based or LAN-based client/server platforms. Touch/gestures, voice, pen, and keyboard inputs are available for every device. Devices can also store/record sound, video, and photographs along with data from a range of sensors. The value of mobile systems in clinical work support has barely been explored. Most clinical software found on mobile platforms began on the web or a LAN. As a result, this ported software not only fails to take advantage of the newly-available capabilities, but also brings along with it the constraints of the design thinking that gave rise to those systems. Doing mobile right means starting from scratch—reimagining clinical software with mobility and processes as foundational design inspirations.
Until November 2015, the limitations of mobile hardware made creating robust clinical software a risky business strategy (companies have done this, of course, but it is still risky). The advent of 64-bit processors in 2013 paved the way for more powerful mobile systems, and the first tablet that I consider suitable for real clinical work, the iPad Pro, was released by Apple last autumn. Along with mobile technology, cloud technology has rapidly matured as has access to reliable high-speed internet (Google Fiber is available on a limited basis in my neighborhood as of February). Likewise, robust business process management suites (i.e., workflow technology) are widely-available. The stage is set for the next generation of clinical software!!!
Last year Apple made Swift open source. That move has already begun to pay off. IBM offers a browser-based Swift tool that one can use to play around with Swift coding. Even more exciting is Kitura, a Swift web framework for cloud-based apps. It would be great if one day Swift could be used in the same way as PHP is to build web apps, thereby making it possible to use one language to build across desktop, mobile, and web platforms.
The posts on Clinical Swift will be project-based. Each project will be chosen to address specific issues/challenges I wish to explore. Sometimes the goal of a project will be an app, and at others, it will be exploring a principle or a coding conundrum. There will be posts on representing clinical concepts using Swift, but none on basic Swift language features (there are plenty of Swift tutorials available). Every project will have a page that explains its purpose and goals (prn: OnCall).
Since exploring design principles for clinical software is a major objective of Clinical Swift, I have dedicated a page, Clinical Software Design Principles, to that topic. It is here that you will find my design/development philosophy, insights, pronouncements, discoveries, and the like.
Posts will appear weekly on Wednesdays. Hope you find the site worth visiting!