Clinical Care Systems

For the last six months or so, I have been doing parallel work with Apple Swift and BPMN 2.0.   For each, I decided to do a deep dive, meaning I tried to closely follow object-oriented analysis and design (OOA&D) best practices for Swift and an equivalent methodology for BPMN. The differences in philosophy between the […]

{ 1 comment }

This Week on Clinical Swift

by Jerome Carter on March 18, 2016 · 0 comments

What does an entry in a chart (paper or electronic) mean? How should an entry be interpreted? These may seem like odd questions; however, when designing a clinical system, such issues come up more often than one might expect.    They are especially pertinent when migrating data from one system to another (and it is not […]

{ 0 comments }

EHR Malpractice—Coming to a Location Near You?

by Jerome Carter on March 14, 2016 · 0 comments

The first time an attorney contacted me after reading EHR Science, it was on behalf of a plaintiff who had a delayed diagnosis during a changeover from paper to an EHR.   That was three years ago.   Recently, a defense attorney contacted me because the plaintiff was challenging the validity of EHR data. Although I have […]

{ 0 comments }

Feedback is important for any design process. Whether it is software or a new cocktail recipe, we rely on testers to ensure that the final product is acceptable. What happens, however, when the feedback received is misleading? Then what?; usually hours of soul-searching, head-scratching and frustration. Everyone who has designed software has gone through this […]

{ 3 comments }

As I have spent more time thinking about clinical software design, my ruminations have become more problem-focused. I have begun to look at specific care delivery problems and how changes in software designs might help or hinder clinical work.   Lately, the problem of diagnostic error as it relates to results management has captured my attention.   […]

{ 4 comments }

After last week’s aside into the data vs. processes dilemma, it is time to get back to how one defines requirements for a clinical care system.  Requirements gathering has to proceed along a few different paths simultaneously, and for any completely new system, it is a messy activity.  There are four main requirement pathways: user […]

{ 0 comments }

Traditionally, clinical software has been organized around data.  The reason for this is the paper chart, which is a process-agnostic information source.  At the outset of creating a new software product, this question has to be answered early on: Is this a data-focused system or a process-focused one?  The architectural differences between the two types […]

{ 3 comments }