Swift is a modern programming language created by Apple to make application development simpler. Version 2.0 of the language is out and adds much needed error trapping/exception handling capability. Swift is similar to other C-derived languages, and is easy to read for anyone familiar with Java or PHP.
My interest in Swift is a result of a desire to write mobile apps. I prefer mobile to web-based because mobile provides direct access to the underlying hardware. Tablets and phones have all kinds of gadgets and capabilities that can be used for clinical care systems. Apple hardware is targeted because of the data security offered. Data stored on Apple devices and in the cloud can be encrypted at rest and even Apple cannot access the data. Further, if a device is lost, all info can be wiped remotely. Thus, HIPAA-related concerns are greatly reduced.
Clinical software is complex, even supposedly simple software. Clinical processes require support in the form of data supplied at discrete steps. There is no formalism for representing clinical systems in this fashion. Likewise, there is no data model that all vendors or software designers use for clinical systems— everyone has a proprietary data model. I am wrestling with solutions to these problems and some elements of those solutions will appear in this series. (A book is in the works specifically for workflow and process issues.) However, at the outset, no attempt will be made to solve deep informatics problems. Instead the focus will be on conveying how software goes from idea to system so that readers might gain insight into development practices and what is possible with today’s technology.
Swift is an object-oriented language, and for this project I will be using object-oriented analysis and design methods. A limited amount of UML will be used (use cases, class diagrams). Process modeling will be done using use cases and BPMN (and possibly YAWL). Version 1.0 of the planned app will have enough features to be useful, but since I believe in YAGNI (you ain’t gonna need it), no elaborate features will be added until users demand them. Okay, let’s get started.
Scenarios are narrative statements that describe the basic features of a planned software system (1). They contain the kind of info one might say about a potential app when thinking out loud. As with prn: Clinical Information Manager, 20 years ago, the current app is intended to solve a simple problem—allowing on-call clinicians to keep notes and access patient data.
Scenario for prn:CIM-On Call
After hours, patients may have questions or become ill. Patients may contact clinicians to seek information or advice for their illnesses. When contacted, the clinician obtains the name, diagnoses, and medications the patient is taking. For each patient contact episode, the clinician will obtain the reason the patient made contact and suggest an appropriate disposition. Episode information must be stored permanently. It cannot be deleted. Episode information should be searchable within the text, and by date, patient, time, and reason for contact.
From this basic description, a software system will eventually emerge. However, there is a lot of distance between scenario and software. First, we need a detailed set of requirements. The main way to get requirements is from potential users. Assuming that such a system has never existed, users won’t know the requirements, but they will know what they want (or what they think they want, anyway). There are two non-mutually exclusive ways to move forward from this point.
The most obvious next step is interviewing users and watching them work. No one has an exclusive claim on these methods. Everyone uses them. Software engineers (SE) and human factors specialists (HFS) may have their own jargon for what they do, but each group is trying to solve the same problem (as regards software development, not everything). HFS tend to focus more on the UI while SE tend to focus more on the underlying system, which strikes me as a good separation.
Another very useful, but more time-consuming, step is creating a mock-up that users can interact with. Mock-ups that support simulation can save hours of fruitless discussions over features that are considered essential until actually experienced (I have seen this many times). Best-case approach: Do a few basic interviews, create a mock-up, then use that as the basis for all future UI design discussions.
User-centered design is receiving more attention these days. A good design process should include users from the beginning, as discussed above. I have no idea how most clinical developers approach UCD; however, there is no way I would try it without mock-ups and simulators. Writing software is expensive and time consuming, and there is no reason at all to write even a basic system THEN show it to users for their opinions. Simulation can give one a feel for workflow issues, information needs, colors and layout—everything needed to get started.
Essential Features: prn:CIM – On Call
With the above in mind, here is a brief narrative describing the most essential features of prn:CIM-On Call.
This is a single-user system designed for primary care clinicians in small practices that do not have an EHR. It is not intended to be an EHR, but rather a peripheral brain for after-hours patient contacts. The application must allow a clinician to add patients, medications, diagnoses, and at least a brief, unstructured note (key board or dictation). All information should be searchable. For legal purposes, data cannot be deleted or altered; amending and annotating are allowed. The patient display will offer demographics, medication list, problem list, and note.
Export data to an external system
Allow multi-user access to data
Capture of video, photo, or sound data
I’ll stop here. I have a set of requirements in mind, but they are derived from my personal experiences. I would love to hear from readers regarding how they handle on-call data access or to suggest specific requirements for the app. A few years ago, I tried out simulation programs and may revisit them in an upcoming post. Apple has also made it easier to distribute apps for testing. If that seems feasible, I may offer some of you the opportunity to try out a mock-up. In any case, I would love to hear from you. Until next time…
- McLaughlin BD, Pollice G, West D. Head First Object-Oriented Analysis and Design. 2006