In fleshing out the final class list, one of the major decisions is what to give “life” to in the system. A medication could be no more than a text string added to an array or stored in a table, or it could be an object with properties and behaviors. The final choice is determined by how much functionality one wishes to confer on medication concepts. It is very much the same type of decision when one is building a relational database. A medication could be an entity with interesting properties or simply a string of text in a field. Since I want to reuse the code (and possibly the data model) in future projects, I went with objects for nearly every information type in the system. Although I have not taken the pains to build a detailed domain model, essentially, that is what I have.
One difficult decision that I may have to revisit is that of representing the app’s user. My original intention was that only clinicians would use the app and that the app would be single-user for iPhone or iPad. However, there is nothing preventing the application from having a cloud-based data store that could be accessed by members of a small practice. If there will be multiple users from the same practice, then there will be a need for user accounts. Accordingly, I have created separate concepts for users vs. practice providers. Key classes (those with the most important properties) are detailed below (methods are not listed).
The User class provides a basis for managing multiple users from the same practice. The PracticeAccountID field would be set to a dummy non-null value for single-use purposes. Since I don’t plan to make this multi-user anytime soon, I have added the extra properties now to prevent having to do so later. Likewise, the Active property would be set to “Yes” on installation and could not be changed (deleting the app would inactivate the account). Phone numbers and email addresses are treated as objects for reasons that will be discussed shortly.
A major design goal of the app is providing small practice providers with a way to manage on-call interactions with patients. Many times this might require interacting with other clinicians or facilities. The Provider class models outside clinicians along with their contact info to provide the ability to keep notes about outside providers. The Locations property is an important class that keeps track of all the places that patients may encounter. In the case of Providers, Locations refers to their practice locations. This class will be the basis for a provider look-up list in the user interface.
LocType (Home, Office, ER, Pharmacy)
The Location class provides a way to attach people to places. They are also selected from a UI list and may be associated with providers and patients. Locations can be added, but not deleted from the database if they have ever been used (the same is true for providers).
Episodes are the cornerstone of the app. All interactions are recorded using Episodes. Episodes are not limited temporally; they may extend over days. I made this design choice to allow for future flexibility. For example, this design could just as easily be the basis for a care coordination application. From the standpoint of the application, an episode ends when both the EpisodeEndDateTime is set AND a non-blank DispositionNote is finalized. Notice that EpisodeNote is an object collection. This specific design choice allows for multiple notes to be written during an episode and each one can be saved and finalized independently. This can provide a trail of what occurs during an episode while providing maximum flexibility to the user.
The DispositionNote is intended to hold the description of the ultimate outcome of the interaction. As mentioned earlier, once it and EpisodeEndDateTime are finalized, the episode is officially closed.
Individual patients have problems that may be associated with them in the equivalent of a problem list. Episodes are initiated by a specific issue or problem (i.e., the EpisodeIssue.) An EpisodeIssue may turn into a patient problem. For example, “headache” could be an episode issue and a patient problem. Lost medications would be an example of the former and not the latter. Medications called in for a patient would be added to Both EpisodeMedications and the patient’s medication list.
prn: OnCall is not an EHR, but it still has to maintain searchable patient data. I learned from previous EHR experience that MedRecNums should be treated like phone numbers: Allow patients to have as many as needed as long as they are NOT from the same facility. Since MedRecNums are given at every unique provider location, patients may have different numbers every place they receive care. Tracking this information down (remember this app assumes a small practice with no EHR) can be a pain. Having lived this, I have allowed patients to have one number per unique location. Consequently, MedRecNums are objects with their properties and validation checking methods.
Patient maintains lists of meds, problems, providers and locations. Episodes come into existence because of patients. Therefore, every episode is associated with a patient, but patients may be registered in the app and never have an episode.
The remaining classes are there to support the main group. They are Problem, Medication, MedRecNum, EpisodeNote, PhoneNum, and Email. Now that I think about it, though, support is not the best description for this group. For instance, EpisodeNote helps to track thoughts and actions over time without causing an episode to end and muddying the timeline. Problem will allow me to add “smartness” in the form of links to information sources, user-entered clinical information, reminders, or other features. No decision support is offered for medications; prn: OnCall merely records what the patient was prescribed or is assumed to be taking.
Thus far, things have proceeded as expected. For the next week or so, I will be working out the final class properties, methods, and object interactions. After that, I will experiment with the classes in Swift playgrounds and try Xcode unit testing features. Once I am happy with the classes, I will go back to my use cases and start to design (on paper) the outline of the user interface. However, I am getting ahead of myself; the next post will be about Swift language features (finally). See you then…