EHR-Compatible Pharmacist Care Plan Standard Opens the Door to Cross-Setting Data Exchange | Healthcare Informatics Magazine | Health IT | Information Technology Skip to content Skip to navigation

EHR-Compatible Pharmacist Care Plan Standard Opens the Door to Cross-Setting Data Exchange

September 14, 2018
by Zabrina Gonzaga, R.N., Industry Voice
| Reprints
Pharmacists drive information sharing towards quality improvement

Pharmacists work in multiple environments—community, hospital, long term care, clinics, retail stores, etc.—and consult with other providers to coordinate a patient’s care.  They work with patients and caregivers to identify goals of medication therapy and interventions needed, and to evaluate patient outcomes.  Too often, pharmacy data is trapped in a silo and unavailable to other members of the care team, duplicated manually in disparate systems which increases clinical workloads without adding value.

To address these issues, Lantana Consulting Group and Community Care of North Carolina (CCNC) developed an electronic document standard for pharmacist care plans—the HL7 Pharmacist Care Plan (PhCP). The project was launched by a High Impact Pilot (HIP) grant to Lantana from the Office of the National Coordinator for Health Information Technology (ONC).

Before the PhCP, pharmacists shared information through paper care plans or by duplicative entry into external systems of information related to medication reconciliation and drug therapy problems. This documentation was not aligned with the in-house pharmacy management system (PMS). The integration of the PhCP with the pharmacy software systems allows this data to flow into a shared care plan, allowing pharmacists to use their local PMS to move beyond simple product reimbursement and compile information needed for quality assurance, care coordination, and scalable utilization review.

The PhCP standard addresses high risk patients with co-morbidities and chronic conditions who often take multiple medications that require careful monitoring. Care plans are initiated on patients identified as high risk with complex medication regimes identified in a comprehensive medication review. The PhCP is as a standardized, interoperable document that allows pharmacist to capture shared decisions related to patient priorities, health concerns, goals, interventions, and outcomes. The care plan may also contain information related to individual health and social risks, planned interventions, expected outcomes, and referrals to other providers. Since the PhCP is integrated into the PMS or adopted by a software vendor (e.g. care management, chronic management, or web-based documentation system), pharmacist can pull this information into the PhCP without redundant data entry.


Safety & Unintended Consequences of Interoperability: Establishing High Reliability Principles & Techniques

Interoperability may seem like just a technology challenge, but in actuality it is a people, process, and technology challenge. Healthcare systems increasingly look to create high-reliability...

The PhCP allows pharmacists for the first time to share information with support teams and paves the way for them to support value-based payment. The project goals align with the Center for Medicare & Medicaid Services’ (CMS’) value-based programs, which are part of the Meaningful Measure Framework of improved care team collaboration, better health for individuals and populations, and lower costs.

Scott Brewster, Pharm.D., at Brookside Pharmacy in East Tennessee, described the PhCP as a tool that helps them enhance patient care delivery. “From creating coordinated efforts for smoking cessation and medication utilization in heart failure patients, to follow up on recognized drug therapy problems, the eCare plan gives pharmacists a translatable means to show their value and efforts both in patient-centered dispensing and education that can reduce the total cost of care.” (The eCare plan reference by Scott Brewster is the local term used in their adoption of the PhCP).

The pilot phase of the project increased interest in exchanging PhCPs within CCNC’s pharmacy community and among pharmacy management system (PMS) vendors. The number of vendors seeking training on the standard rose from two to 22 during the pilot. Approximately 34,000 unique care plans have been shared with CCNC since the pilot launch.

This precedent-setting pilot design offered two pharmacy care plan specifications: one specification is based on the Care Plan standard in Clinical Document Architecture (CDA); the other standard is a CDA-on-FHIR (Fast Healthcare Interoperability Resources). The latter specification directly transforms information shared using the FHIR standard into CDA. FHIR is straight forward to implement than CDA, so this is an appealing option for facilities not already using CDA. The dual offerings—CDA and CDA-on-FHIR with lossless transforms—provide choice for implementing vendors while allowing consistent utility to CCNC.

What’s on the horizon for the pharmacy community and vendors? With the support of National Community Pharmacists Association (NCPA), the draft standards will go through the HL7 ballot process for eventual publication for widespread implementation and adoption by vendors. This project will make clinical information available to CCNC and provide a new tool for serving patients with long-term needs in the dual Medicare-Medicaid program and Medicaid-only program.  This is a story about a successful Center for Medicare and Medicaid Innovation (CMMI)funded project that started out as a state-wide pilot and is now rolling out nationwide as Community Pharmacy Enhanced Service Network (CPESN)USA. 

The PhCP is based on a CDA Care Plan standard that is part of ONC’s Certified EHR Technology requirements, so it can be readily implemented into EHRs. This makes the pharmacist’s plan an integral part of a patient’s record wherever they receive care. 

Adoption of the PhCP brings pharmacies into the national health information technology (HIT) framework and electronically integrates pharmacists into the care planning team, a necessary precursor to a new payment model and health care reform. In addition, receiving consistently structured and coded pharmacy care plans can augment data analysis by going beyond product reimbursement to making data available for, utilization review, quality assurance and care coordination.

Troy Trygstad, vice president for Pharmacy Provided Partnerships at CCNC, described the strategic choice now available to pharmacists and PMS vendors. “Fundamentally, pharmacy will need to become a services model to survive. Absent that transformation, it will become a kiosk next door to the candy aisle. The reasons vendors are buying into the PhCP standard for the first time ever is that their clients are demanding it for the first time ever."

The move to value-based payment will continue to drive the need for pharmacists, as part of care teams, to provide enhanced care including personal therapy goals and outcomes. Sharing a medication-related plan of care with other care team members is critical to the successful coordination of care for complex patients.

Zabrina Gonzaga, R.N., is principal nurse informaticist and director of health informatics at Lantana Consulting Group and led the design and development of the PhCP standard. 


Twitter: @lantana_group


2018 Raleigh Health IT Summit

Renowned leaders in U.S. and North American healthcare gather throughout the year to present important information and share insights at the Healthcare Informatics Health IT Summits.

September 27 - 28, 2018 | Raleigh


Health IT Now Pushes for Information Blocking Regulation, Says Administration “Must Uphold its End of the Bargain”

September 13, 2018
by Rajiv Leventhal, Managing Editor
| Reprints

The executive director of Health IT Now, a coalition of healthcare and technology companies, is again criticizing the Trump administration for not yet publishing any regulation on information blocking, as required by the 21st Century Cures Act legislation.

In an op-ed published recently in STAT, Health IT Now’s Joel White wrote, “More than 600 days after the enactment of the Cures Act, not a single regulation has been issued on information blocking.” White added in frustration, “Health IT Now has met with countless officials in the Trump administration who share our commitment to combat information blocking. But those sentiments must be met with meaningful action.”

The onus to publish the regulation falls on the Office of the National Coordinator for Health IT (ONC), the health IT branch of the federal government that is tasked with carrying out specific duties that are required under the 21st Century Cures Act, which was signed into law in December 2016. Some of the core health IT components of the Cures legislation include encouraging interoperability of electronic health records (EHRs) and patient access to health data, discouraging information blocking, reducing physician documentation burden, as well as creating a reporting system on EHR usability.

The information blocking part of the law has gotten significant attention since many stakeholders believe that true interoperability will not be achieved if vendors and providers act to impede the flow of health data for proprietary reasons.

But ONC has delayed regulation around information blocking a few times already, though during an Aug. 8 episode of the Pulse Check podcast from Politico, National Coordinator for Health IT Donald Rucker, M.D., said that the rule is "deep in the federal clearance process." And even more recently, a bipartisan amendment to the U.S. Senate's Department of Defense and Labor, Health and Human Services, and Education Appropriations Act for Fiscal Year 2019 includes a requirement for the Trump administration to provide Congress with an update, by September 30.

White, in the STAT piece, noted a June Health Affairs column in which Rucker suggested that implementation of the law’s information blocking provisions would occur “over the next few years.” White wrote that this is “a vague timeline that shows little urgency for combating this pressing threat to consumer safety and stumbling block to interoperability.”

Health IT Now is not alone in its belief that the rule should have been published by now, nor is it the first time the group is bringing it up. Last month

More From Healthcare Informatics


Are You a Data Blocker? How to Fit into ONC’s New Interoperability Framework and Regulation

Please register to download

By the end of this year, ONC’s implementation and interpretation of data blocking will also be published and available for comment, as was the case with the TEFCA proposed rule. The TEFCA final rule is also anticipated by the end of 2018.

HOWEVER…there’s still time to prepare for TEFCA and the data blocking regulation, and final rules for both in the coming months will set concrete timelines, and for TEFCA it will be interesting to see how ONC reacts to stakeholder comments, internal and external.

Related Insights For: Interoperability


Top Ten Tech Trends 2018: An Open API Movement Seeks to Create App Ecosystem

August 30, 2018
by David Raths, Contributing Editor
| Reprints
ONC makes push for APIs that are ‘standardized, transparent, and pro-competitive’
Click To View Gallery

Editor’s Note: Throughout the next week, in our annual Top Ten Tech Trends package, we will share with you, our readers, stories on how we gauge the U.S. healthcare system’s forward evolution into the future.

In an April 2018 blog post, Donald Rucker, M.D., National Coordinator for Health IT, described the transformational power of map apps on his smartphone to help him get from Point A to Point B in a new city. “What makes our smartphones so powerful is the multitude of apps and software programs that use open and accessible APIs [application programming interfaces] for delivering new products to consumers and businesses, creating new market entrants and opportunities. There is nothing analogous to this app ecosystem in healthcare.”

But regulators, health systems and innovators are working to bring such an app ecosystem to healthcare, making the open API movement one of Healthcare Informatics’ Top Tech Trends to watch in 2018.

The 21st Century Cures Act of 2016 calls for the development of modern application programming interfaces (APIs) that do not require “special effort” to access and use. Rucker has argued that APIs need to be standardized, transparent, and pro-competitive. “Open and accessible APIs have transformed many industries,” he wrote. “We think they can transform healthcare as well.”

The fact that Apple is making a health records API available to developers and medical researchers signals that there has been considerable progress just in the past year.


Safety & Unintended Consequences of Interoperability: Establishing High Reliability Principles & Techniques

Interoperability may seem like just a technology challenge, but in actuality it is a people, process, and technology challenge. Healthcare systems increasingly look to create high-reliability...

Dave Levin, M.D., chief medical officer at Sansoro Health and former chief medical information officer at Cleveland Clinic, describes himself as an “API evangelist.”  He says that ONC (Office of the National Coordinator for Health IT) and the Centers for Medicare and Medicaid Services (CMS) have recognized that interoperability is the central challenge of healthcare IT today. “It is the foundation that so much else is going to have to rest on and a real barrier to innovation,” he says. “I think they picked the right target.”

The federal agencies also have realized that the rest of the digital economy has made huge strides by using API technology. “APIs are not new; they are just new to healthcare,” Levin says.  Work done by pioneering companies demonstrates that APIs, which work so well in other parts of the digital economy, also work quite well in healthcare, he adds.

Dave Levin, M.D.

One question regulators face is how to incentivize people to move in this direction. They have started to link reimbursement and EHR (electronic health record) certification to API use. The key to success may lie in the three words Rucker stressed: No special effort. That’s because APIs could be done in a lot of different ways. Levin equates it with showing up in the United States with a European-style electric plug.  “People will say, ‘I recognize that is for electricity, but I don’t know what to do with it.’ This is what I see with some of the early offerings for APIs.”

For example, he says, a developer might create a terrific third-party application and want to integrate that into a health system’s EHR, where the clinical workflow occurs. The question becomes, whose plug to use?

“If you show up with your app and some APIs, and say to a health system, ‘all you need to do is adapt to my APIs,’ that could represent a significant burden,” Levin notes. CIOs will want your apps to have APIs that readily plug into their existing infrastructure. They don’t want to have to make a special effort to figure out how to use your APIs or adapt them, he says.

Jonathan Baran has seen these issues from the app developer’s standpoint. His company, Healthfinch, a Madison, Wis.-based startup, focuses on making clinicians’ lives easier with software that automates or re-routes routine tasks in their EHR workflow. He says if ONC and CMS are looking to promote innovation in this space, open APIs
are imperative.

Today, he says, working with EHR vendors requires that Healthfinch software engineers have domain expertise with specific EHRs to build applications. “We can’t just hire engineers to interact with an EHR platform like you would with Facebook,” he says. “That adds to the cost of innovation. Our expectation of a well-formed API is that I could bring someone in who has expertise and knows this space well, and they could work with a new EHR without having to understand a lot of the specifics about how that application works.”

Jonathan Baran

Baran is encouraged that ONC and CMS are focusing on APIs now. The challenge is that the timeline for startups and innovators and the timeline that ONC talks about rarely match up, he says. “We might have a year to prove a model is going to work or not,” he says. The regulators’ timelines are by necessity much longer. “It is going to be good for the industry, but it is hard for me to translate it into what it means for someone like us trying to innovate in the next 12 months. It probably isn’t going to change much.”

Standards under development such as HL7’s FHIR (Fast Healthcare Interoperability Resources) offer ways of representing clinical data that are friendlier to web developers. In addition, EHR vendors, including Cerner, athenahealth, Allscripts and Epic Systems, have embraced the idea of creating app stores for their customers. Sumit Rana, Epic’s senior vice president for research and development, believes the “app store” model will flourish in healthcare. Epic launched its “App Orchard” in 2017 with 13 applications and it is now nearing 100, he said. These third-party developers have access to APIs, documentation and testing tools.

Rana explains the genesis of the App Orchard this way: Customers started developing their own tools to work with Epic and asked the company to create a mechanism to help them share innovations. “We also realized this was a neat thing to extend to third parties and would standardize how our customers could discover applications offered by third parties,” he says. “It lends a certain level of confidence that things will work well in the future, and in terms of considerations on security, privacy and scalability.”

Sumit Rana

Epic’s first App Orchard conference last year had 300 attendees. “This requires collaboration from the platform provider and developers but also the customers,” Rana stresses. “We have a customer community that is very involved. The combination of all three parties leads to a better result.”

Much of the work on APIs involves sharing data at the individual patient level, but ONC also is working with HL7 and the SMART (Substitutable Medical Apps & Reusable Technology) team at Boston Children’s Hospital on the idea of a FHIR-based population-level data API. One goal is to create automated communication between back-end services and EHRs/clinical systems. The idea is that systems should be able to communicate with each other without a user having to log in once a connection is set up.

Possible use cases include:

Exporting population level data to automatically compute quality measures.

Gathering data required under CMS alternative payment models in a more automated way could be done more quickly and much less expensively.

Using population-level data to identify the most appropriate patients to enroll in care management programs.

A writeup of a December 2017 meeting on population health APIs found that the most interest among EHR vendors, payers and providers involved instances where population-level data are already being aggregated, transferred and extracted, but doing so is difficult, inefficient and costly. Some EHR vendors expressed reluctance to spend time and effort where they have already created interfaces, but are open to a population-level data API for new situations where there is not an existing interface.

“Most of the effort with FHIR has been about sharing clinical information about an individual patient. ‘That is a fine and logical place to start, but in healthcare we need to be able to identify cohorts of patients for a service or intervention,” explains Sansoro’s Levin. “It makes great sense that you would want an API that could show you a list of patients who just got critical lab results. You could take that in a lot of directions for population health, clinical research or optimizing scheduling. To me, that is a compelling use case.”

In his blog post, Rucker points out that population-level data transfer that is aligned with HIPAA is “central to having a learning healthcare system, advancing many research priorities and use cases, and modernizing public health reporting.”

Perhaps the most interesting business case-related question is whether the big health IT platform vendors will really be open to third-party apps that start to take on significant tasks.

Some developers have complained that although the large health IT players have committed to the FHIR standard, they still make it difficult for the startups to access their FHIR APIs or only implement some portions of the specifications.

“At some level, you can draw parallels to Apple and Android,” Healthfinch’s Baran says. “Android lets you change what you want. That creates one type of environment, while Apple is going to hold some things in its core and allow you to do other things. It is going to be specific to each EHR how open or closed they are going to be.”

See more on Interoperability