Design and Implementation of a Personal Medication Record— MyMedicationList

Abstract

A record of current medications as well as prior medication history is useful if not vital information to an individual. Such information needs to be easily accessible, yet adequately protected. MyMedicationList is a prototype application developed at the National Library of Medicine that helps users manage their medication lists and make the records readily available when needed. This personal medication list can be printed out and serve as a reminder to the individual for taking medications, or as reference information to support continuity of care at doctor’s offices or hospitals. This paper presents the design and implementation of MyMedicationList. As the personal medication record is considered a specialized Personal Health Record (PHR), the experience may be applied to general PHR design and implementation. An early version of MyMedicationList is available at http://mml.nlm.nih.gov/.

Introduction

Patients are increasingly encouraged to take an active role in their health care [1], often by accessing and contributing to their health records. One contribution is maintaining a personal medication list, keeping medications updated and accurate. Errors and drug interactions can occur when patients are treated without full knowledge of medications that have been previously ordered, especially at transition points such as hospital admission, transfers and discharge [2]. An accurate, up-to-date personal medication list helps reduce these errors and contributes to continuity of care by facilitating medication reconciliation. We began the present study by investigating tools that help patients manage their personal medication lists. As a personal medication record is a specialized Personal Health Record (PHR), our search started by investigating the available PHR products on the market.

We identified the following major requirements for this medication list tool:

1. free to the general public

2. adequately protects users’ personal information

3. based on standards for terminology and documents

4. independent from any health institutes, organizations or platforms

Additionally, to ensure adequate protection of users’ personal information, we believe that this tool should have a standalone architecture, because it can store information locally and does not require remote login.

The list of PHR products provided by the American Health Information Management Association (AHIMA) (http://www.myphr.com/resources/) was the primary source for our search. Products are listed at that site in three formats (Internet, software, paper) and two cost levels (free, for purchase) [3]. Of the 74 different products listed, only two are free, standalone software: MyFamilyHealthPortrait, which keeps record of diseases histories in families; and ProfileMD, a program that maintains an individual’s family medical history. However, neither of these deals with medication records. During our search, other PHR products examined included widely publicized systems, such as Microsoft^® HealthVault^TM, Google Health and Quicken Health. However, all three systems are web-based and require user logins and information storage on remote computer systems, over which users have no control.

After a study of the PHR products on the market revealed no free medication list tool that met our requirements, we decided to create MyMedicationList—a tool that helps the general public maintain personal medication lists, storing, updating, adding, and deleting medications from their personal medication lists and make the records available to health professionals when needed. The objective of this paper is to discuss the design and implementation choices made while developing MyMedicationList. Our experience may be applicable to other, more general, PHRs.

Background

A few emerging standards are becoming more widely accepted in a PHR setting. Notable among them is the CDA/CCD as the standardized document model for clinical document exchange.

HL7 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of a clinical document (such as a discharge summary, progress note, procedure report) for the purpose of exchange. A CDA document can be transferred within a message, and can also be used independently of the transferring message [4]. CDA Release One became an American National Standards Institute (ANSI)-approved Health Level 7 (HL7) Standard in November 2000. CDA Release Two became an ANSI-approved HL7 Standard in May 2005. CDA documents are encoded in Extensible Markup Language (XML) [5]. A CDA document contains a header and a body. The header identifies and classifies the document and provides information on authentication, the encounter, the patient and the involved providers; the body contains the clinical report and can be structured or not. CDA defines an optional Medication section for a patient’s current medication and pertinent medication history.

Figure 1 illustrates such a Medication section. It contains a narrative block ( ) wrapped by the <text> element that renders human readable contents and several coded CDA entries ( ) for automatic processing purposes. The example document indicates that the patient is currently taking “Celebrex 200 MG Oral Capsule”, identified by RXCUI:213469 in RxNorm ( ). This medication was started on Feb. 4, 2008 ( ). Dose is “1 capsule” ( ) and frequency is “once a day” ( ). The instruction section ( ) is not coded and simply refers to the human readable section. The generic counterpart of this drug is “Celecoxib 200 MG Oral Capsule” ( ).

Figure 1.

An example of a Medication section in the CDA body

Continuity of Care Document (CCD) is a CDA Release 2 implementation that maps the Continuity of Care Record (CCR) elements into a CDA representation, harmonizing CCR and CDA into a common framework. While CDA was established as a standard, CCR was developed as an ASTM International standard. CCR is a core data set of the most relevant administrative, demographic, and clinical information facts about a patient’s healthcare, covering one or more encounters. CDA and CCR have many similarities, yet differ from each other. From the perspective of CDA, the CCR is a standardized data set that can be used to constrain CDA specifically for summary documents. One such constraint is that CCD should contain exactly one and shall not contain more than one Medication section. The resulting CCD specification is a collaborative effort between ASTM and HL7 [6].

RxNorm is a controlled vocabulary of normalized names for clinical drugs [7]. It serves as a standardized nomenclature for prescribable medications. RxNorm organizes drug names from various drug information sources to its standardized concepts, which are assigned a unique identifier (RXCUI) [8].

Distinct, named relationships link all concepts within RxNorm. For example, a clinical drug (e.g., “Celecoxib 200 MG Oral Capsule”) is linked to its ingredient (Celecoxib), ingredient-strength (Celecoxib 200 MG), dose form (Oral Capsule), and ingredient-dose form concepts (Celecoxib Oral Capsule) through explicit named relationships. RxNorm also includes branded counterparts, linked to its branded components (e.g., “Celebrex 200 MG Oral Capsule”).

Design and Implementation

The design and implementation of MyMedicationList is driven by the requirements introduced earlier. From an architectural perspective, users’ information should be adequately protected. At the document level, the document’s contents need to be “understood” by other systems, requiring a model whose semantics is complete, rich and standardized. At the terminology level, due to the lack of a global terminology solution, the terminology needs to support mapping across different vocabularies. And finally, from the usability perspective, the tool should be user-friendly.

Architecture

Security and privacy remains a primary concern for potential users of a PHR. Most PHR products available on the market are web-based, which means that a third party is involved (the provider of PHR service), and that users have little or no control over where their personal information is stored. Additionally, in a web based setting, information is transmitted from the system to the user and vice versa, making information potentially vulnerable during the transmission process. Authentication of the user is a major concern; one which has not been adequately solved.

Our choice is to give users complete control over where their information is stored and how it is accessed. In MyMedicationList, users store medication lists just as they store any other files (e.g., their tax records) on their own computers. Medication lists are stored locally, typically on a hard drive or on a flash memory card. (Users may choose to encrypt the medication list or the entire USB drive.) Users thus control access to their personal information and decide with whom to share it. Sharing of the information requires explicit actions such as uploading the records to other PHR systems or providing pertinent information to healthcare professionals.

In order to accommodate the ability to store information locally, MyMedicationList is developed as a standalone application that runs locally on users’ computers. It is implemented in Java, ensuring that this application can run on all platforms. Java WebStart is the underlying distribution mechanism for the tool, providing a familiar web-like interface in accessing the tool. The tool is available via a URL link, through which the tool is automatically downloaded to users’ computers, but the data are stored locally.

Document model

In the context of MyMedicationList, the document model refers to the document structure or format in which a personal medication list is stored. We evaluated document models against the following three criteria:

1. The model needs to be semantically complete and rich to represent medications. Among the pieces of information that it should capture are medication name, interval (start/stop time), quantity, frequency, patient instruction, indication, available generic substitute of a branded drug, prescriber and supplier.

2. The model needs to incorporate a variety of terminologies. Due the lack of global terminology solution, and the fact that each terminology covers only certain aspects of a PHR, more than one terminology may be present in a PHR document.

3. The document model should be widely accepted, stable and persistent. The information contained the medication list might be exchanged between patients and healthcare professionals or institutes. A standardized document model is crucial for information exchange.

We studied two leading standards for PHR document models: CCD and Indivo [9]. CCD emerged as the better alternative. It specifies the generic counterpart of a branded drug, which is useful for pharmacists when filling out a prescription in which the generic substitute for a branded drug is allowed. In contrast, Indivo only indicates whether or not a substitution is permitted, but does not provide the name and code of the substitution. (This feature also facilitates a variety of decision support processes, including checking that both branded and corresponding generic drugs are not on someone’s current medication list.) CCD provides coded contents for all entries and renders human readable contents in the narrative block. This ensures human readability, as well as computer processability. Indivo, on the other hand, does not systematically distinguish between human readable and coded content. For example, frequency is only stored as string (e.g., “4 times a day”), which can hinder interoperability across systems. A comparison of CCD and Indivo document models on medications is summarized in Table 1.

Table 1.

Comparison between CCD and Indivo document models on medications.

	Indivo	CCD
Coding System for Medication	FDA-NDC	RxNorm
Coding System Reference	ServiceLocation using URI and ShortDescription	OID: “2.16.840.1.113883.6.88”
Frequency	String only: “4 times a day”	String in narrative block; Codes in CDA entry. <effectiveTime> xsi:type=“PIVL_TS” <period value=“6” unit=“h”/> </effectiveTime>
Prescription	Boolean indicating OTC or prescription	Mood: “EVN” for “actual use” or “INT” for “intended use”
StartDate & StopDate	Prescription- Duration is present only if prescription is true	<effectiveTime xsi:type=“IVL_TS”> <low value=“20000328”/> <high value=“20010328”/> </effectiveTime>

Terminology

While the framework provided by CCD is a critical component of semantic interoperability at the document level, it is not sufficient, given the lack of a global solution at the terminology level and the abundance of names and codes in the clinical drug domain. Interoperability across vocabularies requires a mapping that links names and codes that are lexically different but semantically equivalent together. RxNorm is a terminology that provides such mapping. RxNorm is also free and can be accessed via an application programming interface (API). It is the terminology used in MyMedicationList to represent medications.

Usability

The adoption and effectiveness of PHRs will depend as much on system and user interfaces as on the data in the records. Users could be seniors with limited computer experience or people with low literacy or limited language proficiency. MyMedicationList follows general usability guidelines and addresses particular user needs in a PHR setting.

One feature especially interesting for those with low literacy is that medications can be associated with images and instructions illustrated in pictograms.

Data entry in MyMedicationList is facilitated by an auto-completion mechanism, allowing the user to select a generic or branded name. The corresponding drug and code in RxNorm is automatically retrieved. Related information, including start/stop date, frequency and instructions, is entered with widgets such as drop-down lists or formatted fields. Additional useful knowledge, such as prescribing information and lists of adverse reactions, are available through a link to DailyMed [10], an NLM website that provides information about marketed drugs, including the FDA approved labels, as well as links to other information sources.

Result

The first working version of MyMedicationList was delivered within 6 months and required one full-time developer for its implementation. This version includes the following basic functionalities: adding, deleting, updating entries from the list; creating, saving, viewing the list; storing the list in the CCD format; and looking up medications via RxNorm and prescribing information via DailyMed. A typical screenshot (list view) of MyMedicationList is presented in Figure 2. An early version of MyMedicationList is available at http://mml.nlm.nih.gov/.

Figure 2.

MyMedicationList screenshot (list view)

Discussion

Early feedback

MyMedicationList has been welcomed by audiences throughout a series of demonstrations, including one at the AMIA 2007 Annual Symposium. It appears that MyMedicationList has addressed users’ concerns about privacy by giving them control over information storage and sharing. Users are generally relieved to learn that medication lists are stored locally on their computing devices and that no personal information is transmitted to outside entities, such as a server or a database. Users particularly like the fact that they can delete entries from the lists without worrying about the old data being secretly kept somewhere else. They also like features such as “discontinue” and “view label”. Overall, the users generally perceive MyMedicationList as a consumer-friendly, useful tool.

Some additional features suggested to us include prescription import (users prefer doctors’ prescriptions to be imported automatically rather than entered manually), and portability to other personal devices (users wish to be able to view medication lists on PDAs, cell phones, etc.)

Standards in action

We believe it is possible to follow the existing and emerging standards in building a PHR. Our experience in building MyMedicationList indicates that standards can work together effectively: here, CCD at the document level and RxNorm at the terminology level. In our experience, the benefits of using standards outweighed the cost of learning how to implement them. For CCD, as the data model is captured in XML schemas, we used an available software package (i.e., JAXB) that automatically generates object classes from XML schemas. So reading, updating and saving documents in CCD format was implemented in very reasonable amount of time. Analogously for RxNorm, data retrieval required minimal effort, because we could take advantage of the web services API available through RxNav [11].

A medication module for PHRs

In addition to being a standalone application for recording medication lists, MyMedicationList (MML) has the potential for becoming a standard medication module for PHRs. In fact, PHR systems could integrate MML as part of their application or delegate the entry of medications to MML. Because MML it is based on standards, the medication information it records can be easily exchanged with other systems. More generally, the experience gained while creating MML can benefit the developers of the similar tools, including medication module of PHRs and e-prescription systems.

Future work

MyMedicationList has not yet been fully evaluated. We plan to conduct an evaluation through an outreach project of the National Library of Medicine. Using a library suitable as a staging area, our plan is to recruit and to assist a group of individuals to serve as testers of the interface and its features. Ideally, this group would be diverse in education, literacy, age, ethnicity, and racial background. In addition to providing a direct benefit to the users, this effort would be used to guide further development of the software application.

In the near future, we plan to include information such as drug interactions that may be extracted from drug ontologies (for example, DOPE or NDFRT) on MML. We also plan to design an electronic prescribing tool via which doctors’ prescriptions will be automatically incorporated into patients’ medication lists.