The Future Looks Great!

As many of you know, I have made my share of optimistic predictions regarding next-generation EHR systems.     Those predictions are based on assumptions about how technology will evolve in the next few years. When those assumptions bear fruit, it makes for even more optimism. So, as everyone is preparing for travel and the upcoming holiday season, I offer these optimistic updates.

Apple Developer Program
When Apple announced the Swift programming language, I was delighted that learning Objective-C was no longer a requirement for creating iOS apps.   Having spent time playing around with many different programming languages, Objective-C still felt odd, like a Frankenstein language with odd seams and the occasional bolt sticking out of it.   The few times I tried to learn Objective-C always ended in exasperation and cursing.

In only a couple of years, Swift has gained significant acceptance. Apple’s decision to make it open source has contributed to its rapid growth.   IBM has adopted it for numerous projects and has even created a server-side framework to build web applications.   Server-side Swift is an unexpected and very welcome innovation.   The ability to use a language for everything from mobile and desktop to web applications is very attractive.   Java has reigned in this manner for years, but the Java world seems to be trying to manage its way forward despite Oracle, and all does not seem as rosy with Java as it once did. IBM’s aggressive moves with Swift would seem to indicate that Swift has a future in challenging Java–not tomorrow, but no one should count the rookie out.   Besides IBM, three other groups are offering server-side Swift frameworks, and even at their current state of development, they seem capable of challenging Node.js.

Moving into iOS development is not simply a matter of downloading Xcode and typing away.   iSO development fully embraces MVC architecture, which became the darling of web applications a few years ago and has been widely adopted.   However, MVC is in the eyes of the beholder, so implementations differ. iOS has many moving parts and learning one’s way around it is daunting.


Learning Swift was a piece of cake compared to learning iOS frameworks and Xcode.   At the outset of learning iOS and Xcode, I set a goal of completing a medium complexity app (one that made use of a data store and major interface elements).   My thinking was that if I could complete a medium complexity app with a good understanding of iOS, then I would go for something more ambitious and enroll my company in Apple’s developer program.   Happily, my company is in the final stages of becoming an official iOS developer!   My second app will be a productivity aid for my personal use, and the first clinical app will be a version of the one I have been writing about at Clinical Swift.

CareKit offers 50-60% or more of the infrastructure required for patient-facing clinical apps.   It cleanly encapsulates the main concepts—UI, patient interaction modes, information types – that are essential for patient engagement, so that even those who are not developing for an Apple platform may glean good design ideas.   While it seems most CareKIt development, thus far, has been in large medical centers, it seems to be the perfect platform for professional societies and similar organizations to create patient engagement tools for members and their patients.   Lack of iOS developers with healthcare knowledge or informatics expertise is a potential impediment, but one that can be overcome (assuming that the powers that be accept that clinical software design is a specialized area that requires training beyond being a programmer or software engineer).

User Interface Design
Prototyping is a great way to work out UI designs with potential users. Tasks and workflows are much easier to discuss and test with interactive UI prototypes than with sketches or screenshots, making prototyping applications effective usability tools. Of course, effective tools should make designers’ lives easier as well. While I have used web prototyping tools and been happy with them, my turn to iOS left me looking for design tools that help with icon creation and similar graphic elements as well.   I am not an artist, so my interest is in simple tools that are easy to learn, but are still capable of high-quality work.   Until now, I have been using Fireworks from Adobe. However, going forward, Sketch seems to be exactly what I need.   It comes with a range of templates for mobile development and works in a manner that is similar to Xcode.   From now on, all client discussions will involve Sketch prototypes.   Capturing client ideas has become a lot easier!

Testing Workflow Ideas with an EHR
From time to time, EHR vendors contact me about a product or to ask a question.   Since I have no interest in promoting or being involved with the latest iteration of a patient data repository, such discussions tend to be brief. Recently, however, more inquiries concern adding workflow capabilities to EHR systems, which I do find compelling.   It looks like we are finally coming to an inflection point in thinking about what an EHR is and what one should be able to do.   Yeah!!!

openEHR is a specification for creating electronic patient records that support true semantic interoperability.   The key term here is “specification.”   openEHR specification documents are blueprints for creating EHR systems.   The problem is that they are blueprints and not working software.   Just as having a specification for a compiler does not make me want to build one from scratch in my den, having an openEHR spec does not make me want to spend months creating a system based on openEHR. Given the uptake of Epic and Cerner, it seems that sentiment holds true equally for large healthcare orgs that have the resources to implement openEHR.

A few days ago, I received an email announcing the availability of openEHR EHRServer 0.8, an open source implementation of openEHR that one can download. Now we’re talking!!!! openEHR supports interoperability at the atomic level. For so many years it was just a beautiful idea, and now, it is coming to life in a way that will be accessible (I hope) to the little guys.

My beef with current EHR systems is that they are patient data repositories that have been pushed beyond their original designs in terms of workflow support (includes UI issues) and data management capabilities. Data management is propriety, and all of the twists and turns of HL v3 and FHIR have been invented to solve a problem that should never have existed–moving data between systems with differing semantics and formats. Why should every EHR system designer delve into data semantics and formats if interoperability is going to be required for all vendors anyway?

openEHR directly addresses interoperability issues and removes the need for system designers to reinvent the wheel.   The availability of an implementation that potential EHR developers can use for their projects moves us closer to a time when we will wonder why passing data among EHR systems was considered such a hard problem. A stable implementation of the openEHR spec—either open source or available for a fee—would likely push me to do something totally ridiculous like trying to create a true clinical care system.

BPM suites in the cloud
It has been less than a year since I began evaluating BPM suites. The rate of development in this area is amazing.   The BPMN 2.0 spec, while supported by nearly every vendor to some degree, suffers from uneven implementation of many features.   While I find YAWL more to my liking, it suffers from a lack of vendor support, so BPMN it is. BPMN started as a diagramming tool that morphed into a programming tool with BPMN 2.0; that is, one can write executable workflow applications in BPMN 2.0, assuming the BPM suite supports this functionality.

In testing BPM suites, I have found significant variations in the quality of the development environments and support for BPMN 2.0 and the cloud.   As a result, every month or so, I have found myself leaning toward a different system because of issues with the one at hand.   Recently, Camunda seems to be pulling away from the pack.   Camunda’s modeling tool is the best – lightweight, frequently updated, good BPMN 2.0 support, and great tutorials.   Even better, they have a 30-day cloud evaluation offering.   IBM tools are also compelling.     The path to experimenting with solid BPM tools in a cloud-based setting has gotten much smoother and more inviting.   This is a big deal!

The pieces needed to create the next-generation of clinical care systems are rapidly falling into place.   Small practices will likely be the first to benefit.   After looking over the developments of the past year, I am more optimistic than ever!!!

Happy Thanksgiving!!!





Leave a Reply

Your email address will not be published. Required fields are marked *