Healthcare academic informatics and IT vendors - A modest proposal for a collaborative focus

TY - JOUR

T1 - Healthcare academic informatics and IT vendors - A modest proposal for a collaborative focus

AU - Hammond, William E.

AU - Greenes, Robert

N1 - Funding Information: William E. Hammond william.hammond@duke.edu Duke University, Durham, NC, USA Duke University Durham NC USA Robert A. Greenes greenes@asu.edu Arizona State University and Mayo Clinic, Scottsdale, AZ, USA Arizona State University and Mayo Clinic Scottsdale AZ USA This issue contains as a Special Communication a debate on the topic of health IT vendors and the academic community [1] . The debate was sponsored by the American College of Medical Informatics (ACMI) during the Annual Symposium of the American Medical Informatics Association (AMIA) in November 2014. Although there were disagreements among the debaters on the roles and responsibilities of the two communities, they all concluded that a new path forward should be found to address and resolve the issues that were identified. Perhaps a bit of history is necessary to understand what changes in the relationship between vendors and academia have taken place. In the early years, long before the HITECH act and Meaningful Use (MU), most academic medical centers developed their own IT systems, typically with the involvement of faculty members from the informatics unit. The prevailing view was that “If you want a system to do what you want, you must develop it yourself.” We, as academics, enjoyed the freedom of making quick changes without much regard to the impact or long-term support of our users. If we had a new idea, we could implement it immediately, test it, and change as necessary. With this ability to innovate, academics also had a somewhat different perspective. Clearly one set of motivations revolved around the innovation itself and publication. While academics also were no doubt motivated by the desire to make a beneficial operational difference, they typically had less experience or background in the long-term needs for operation, support, and maintenance. They also, perhaps somewhat naively, expected the IT staff would take over these latter tasks. Vendors have over the past several decades implemented Electronic Health Record (EHR) systems with many of the capabilities that appeared in the homegrown systems. In fact, some of those vendor systems actually have their roots at least in part in the academic systems. With HITECH and the many requirements of MU, the academic medical centers have transitioned from developing their own systems to purchasing and installing commercial systems. The same needs for innovation and experimentation continue to exist, particularly in our rapidly transforming healthcare system and learning health system environment, where people still want the freedom to test new ideas quickly, and moreover, where some of the new requirements for healthcare delivery don’t have robust solutions yet. Consider, for example, a true integrated (perhaps virtually constructed) view of a person’s data (a lifetime record, both as a patient and non-patient), rather than relying on HIE to obtain portions of the data (and having to reconcile it). Consider having a common repository of shared knowledge resources for clinical decision support. Consider a single composite patient care plan, with support for multiple views and interactions with it by different participants in the care team and true care-coordination across venues. Consider integration of personal data sources (including non-clinical data such as social, environmental, and economic data) and EHR data and use of big data analytics to inform personal clinical decision support. The solution to these and other large challenges is difficult to envision as extensions of current EHR products, and many of the suggested tasks need to bridge functionality across different EHRs and other data sources. Thus a modern challenge lies in the ability to interface new innovations with existing vendor products without destroying the integrity of the vendor solution. Bidirectional flow of data into and out of the EHR is essential, but the vendor product must be protected to preserve its quality and integrity. The vendor perspectives, requirements, and responsibilities are very different from the academic. The vendor must support thousands of customers, and the products must have a high degree of reliability. System integrity across a network and across the many variations in the installed base is essential for marketing success. Arbitrary customization cannot be supported. A degree of optionality provides some freedom, but consistency across customers is necessary for maintainability. Vendors are in the business to make money. Therefore, it is reasonable to expect and provide protection of proprietary products. Academics get professional credit for software design, systems architecture, and information presentation. In contrast, vendors protect that intellectual property, viewing it as proprietary. These differences create tensions between the two groups. Can they be solved? Over the years, the requirements of the IT systems have changed significantly. The variety of stakeholders interested in and using the products have changed. We have moved from a focus on financial systems to service systems (Hospital Information Systems) and now to the all-encompassing system of the EHR. We are also moving to enterprise systems, accountable care organizations, and community-based, patient-centered care models that further expand the foci and functionality needed. The academic community has major disagreements about what an EHR is, what it contains, what are required functionalities, and what roles it serves. The government has become more engaged in defining functional requirements, certification, and data sharing. The government has added regulations and privacy requirements. An unresolved issue is where the boundary between public and private should be set. Why should we expect the vendor to be solely responsible for solving the issues created and defined by another community? The problem is further complicated in that there is no agreement on what should be done. EHR functionalities are praised and criticized. So, who do the vendors listen to? Who is the expert? Who should drive change? We would argue that the main frontier is now the patient (person)-centered view to which we are evolving as we pursue the increased capabilities and responsibility for self-care, the need for continuity of care, the emphasis on wellness and quality, bundled payment plans, etc. No EHR systems were designed for this – they were designed for enterprise/practice optimization (if that). This challenge is where the R&D of the future is needed, analogous to where we were with the need for EHRs 40–50 years ago. The difference is that now we must build a new ecosystem on top of and integrating current and evolving EHRs. Thus it is essential that we work together both to evolve EHR products and to devise a future platform/infrastructure and roadmap for interoperability that enables this new ecosystem to emerge. There is competition among vendors as routinely occurs whenever similar products are manufactured by different companies. What is the return on investment (ROI) for any vendor to open its product to any other vendor? If a vendor has a total system product, what is the vendor’s motivation to make it easy for other vendors to plug other products into it, with the added costs and problems of maintenance and synchronization? We must try to articulate a value proposition for vendors to create open products or at least open interfaces that bi-directionally allow the flow of information among systems. Importantly, consider the ill-defined term “information blocking” that Congress has accused members of the vendor community of practicing. If a vendor, for example, provides tools and functionality to interchange data among disparate systems using that vendors’ products but no or limited tools to interface with other vendors’ products, is that vendor guilty of information blocking? If it is deemed that the information must be shared, then who should pay for developing the interface? What should we expect the vendors to provide for the common good at their own expense? An important topic that was not addressed by any of the debaters is the role that standards play in helping to foster an interface between vendors and academia. Most of the current “hot-topic” initiatives require the sharing of data across multiple sites of care, whether we are talking about clinical research or patient care. “Interoperability” is perhaps one of the hottest topics in health IT (although an overused term). The capabilities that are required for interoperability are ambiguous. Interoperability at some level, however, is key for almost all of the new health initiatives: Precision Medicine, Big Data, Population Health, Learning Health Systems, Health Information Exchange, Patient-Centric EHRs, and others. Patient-Centered Outcomes Research Institute [2] (PCORI) and the National Patient-Centered Clinical Research Network [3] (PCORnet), NIH HealthCare Systems Research Collaboratory [4] , the Office of the National Coordinator’s (ONC) Structured Data Capture [5] and Data Access Framework [6] , and activities of the National Library of Medicine (NLM), Food and Drug Administration (FDA), National Institutes of Health (NIH), the Centers for Medicare & Medicaid Services (CMS), and other stakeholders and sponsors require interoperability. Success depends on working partnerships among vendors, among providers of care, among payers, and among government organizations. Thus far, the few successes we see are a consequence of work-arounds that mostly work, rather than a result of dealing comprehensively with the problems for which we understand the solution. Perhaps the best way to identify a workable and acceptable solution is to define the ideal state and work backwards on how to achieve it. How might we accomplish this objective? The first step is to identify the basic problems that we are trying to solve. The academic and vendor community may sometimes seem to be at cross purposes now, with vendor systems being installed in academic medical centers and replacing homegrown systems, and offering little opportunity except at the margins for academic innovation to continue. But if we take the broader perspective of the transforming health/healthcare system, we have many unsolved problems, as we have discussed. These problems were also brought out in the debate. This situation is not dissimilar to where we were in the early days of EHRs. We now have the opportunity to bring together the academic and vendor communities and other stakeholders together and work toward agreeing in defining those problems and developing solutions to them. Are the solutions to create a global network in which all data related to health and well-being is accessible at any place and at any time, with appropriate safeguards? The data must be of highest quality and must be complete and consistent. Data must be exchangeable and understandable, in context, when neither the sender nor receiver has to be previously identified. Data flow must be bidirectional. Provenance must be preserved. Another requirement is that we must be able to identify the person uniquely throughout all transactions. Questions that must be addressed include defining and global acceptance of the words we use to describe health, health care and related topics. We need to define the trigger events that start the movement of data. We need to define the flow and methods of analytics and how to accommodate the new data they create. We need to resolve the differences between financial/claims data and clinical data. We need to define where we draw the line between what is proprietary and what is openly available and sharable. We can view the vendor’s product as a black box, but one that is capable of always correctly providing the data we want with the exchange being triggered by an internal event. We need the vendor to accept data from accredited and authorized sources. We need to define an acceptable model for paying for such systems. We need to provide some expectation that the eventual stability and maturity of what we desire will allow the developers and implementers to achieve an appropriate return on their investment. We need to convince all stakeholders that an investment in this approach will be worth the effort. Can we achieve it? Time will tell. It does seem that the technology and the knowledge is here to accomplish the desired results. We need the leaders to make it happen.

PY - 2016/4/1

Y1 - 2016/4/1

UR - http://www.scopus.com/inward/record.url?scp=84960941114&partnerID=8YFLogxK

UR - http://www.scopus.com/inward/citedby.url?scp=84960941114&partnerID=8YFLogxK

U2 - 10.1016/j.jbi.2016.02.018

DO - 10.1016/j.jbi.2016.02.018

M3 - Editorial

C2 - 26956212

AN - SCOPUS:84960941114

SN - 1532-0464

VL - 60

SP - 363

EP - 364

JO - Journal of Biomedical Informatics

JF - Journal of Biomedical Informatics

ER -