The health application challenges being sponsored by the Office of the National Coordinator (ONC) for Healthcare Information Technology (HIT) and organized by Health 2.0, are a tremendous opportunity for the developer community to design innovative healthcare information technology applications. In fact we were recently adjudged a semi-finalists in a challenge sponsored by the NCI. Our application ‘Ask Dory’ asks decision engine that asks personalized questions to help patients connect with clinical trial investigators in real-time – we are about to launch this very soon.
So after attending the Health 2.0 conference in Sept 2011 at SFO, we got a chance to meet the program lead, Dr. Jean-Luc Neptune of Health 2.0 and share with him some ideas on how these challenges can be more structured to address key issues with EHR system design. So much so that the brief discussion has now led to a formal proposal that we just emailed to Dr. Luc. So what is the proposal about?
In this proposal we discuss the use of the ONC Health Challenges as a mechanism to enable the development of technology solutions to address several common shortcomings of Healthcare Information Technology (HIT) systems such as Electronic Health Records (EHRs), Personal Health Records (PHRs) and the like. For the purposes of the discussion we will limit the scope of HIT systems to EHRs. We describe specific problem areas and themes for different developer challenges.
Problem and Motivation
One of the oft-cited reasons for not adopting Electronic Health Records is that they are difficult to use. For instance, all EHRs have documentation capabilities but physicians routinely complain about the difficulty in using EHR data entry forms. Another common, shortcoming identified is the difficulty of integrating one system with another. Some of these crosscutting technical limitations are summarized below:
- Documentation with an EHR can be painstaking – EHR vendor systems either enforce rigid structured data entry or allow free flowing text entry. Both systems have their own drawbacks. Structured data entry is not natural (physicians like to take free flowing notes) but it allows for better coding of the information and its secondary re-use (for reporting and other purposes). Free-form text blobs may feel more natural to a provider, but are difficult to parse and extract coded knowledge automatically, thus severely limiting the decision support and reporting features of an EHR. It is sufficiently understood that the EHR will only be as good as the data that goes into it and most vendor systems have yet to find the right model to balance the need for structured data entry and free-form entry.
- It is difficult to extend database models in EHR systems – EHRs and other HIT systems are known to be painstakingly difficult to extend and maintain in terms of their database schema. Adding new variables or deleting old ones can be challenging as each new variable may necessitate multiple changes in the relational schemas.
- It is difficult for third-party systems to integrate or extract information from an EHR, thereby severely limiting the re-use of the data
- Users often complaint about difficult to use EHR interfaces – EHR user interfaces are known to be “busy”, “cluttered” or “non-intuitive
Proposed High-level Solutions as Application Development Challenges
The EHR shortcomings listed above can be considered to fall under two main categories, a) Information Entry, Storage and Retrieval and b) User Interface and experience Design. Information storage and retrieval solutions could address the issues of data entry, data modeling and methods to extract the data easily. Similarly, the gamut of issues pertaining to user interface can be tackled under solutions to improve the “User Interface and Experience”. Consequently, we can organize specific challenges to develop solutions under each category as described in details below.
Challenges under Information Entry, Storage and Retrieval
Challenge 1: Develop systems/solutions to allow data entry with the ease of free text entry/speech but with capability for extracting structured data.
In this challenge, developers will be asked to demonstrate a software solution that can provide the ease of free-text entry combined with the ability to extract structured data. The goal will be to challenge developers to utilize the advancements in web technologies and Natural Language Processing (NLP) to otherwise tackle this vexing problem. Part of the reason why earlier attempts have not yielded useable solutions is because of the over-reliance on the NLP to understand and parse free text. Can developers build a hybrid model, which uses some NLP but some user-based feedback and correction to improve the parsing of freely entered data? The use of NLP is just one example. Developers could invent their own models for data entry (for example, allowing free text in some places and structured in others).
To operationalize this challenge, developers could be asked to demonstrate their solution using data elements of forms such as physical history from some of the leading EHRs. The challenges would be standardized such as the TREC competitions . Every team would develop systems that will be tested against a common dataset and return the results for evaluation.
Challenge 2: Develop or extend existing frameworks to easily allow export or extraction of data within an EHR using web-based methods
The goal of this challenge is to enable liquidity of data within EHR systems so that it becomes as simple as it is to send or receive data through Application Programming Interfaces (APIs) of common web services such as Google Maps, Facebook, Twitter. Frameworks like popHealth are a step in this direction but they require installation of software by client servers, which makes it use limited to technically savvy organizations. On the other hand REST-based API frameworks allow exchange of data through platform independent web requests. Such frameworks greatly reduce the integration efforts and one such API provided in the healthcare space is TrialX’s API (http://TrialX.com/api). Through the API independent developers can query the TrialX system to retrieve clinical trials matching certain criteria with minimal integration effort.
In this challenge developers will be asked to create their own API standard (an “EHR API”) that would provide guidelines, methods or even code libraries so that each vendor system’s EHR data can be mapped to the developer reference EHR API. Third-party app developers could then theoretically develop Apps that conform to the “EHR API” which would then be able to utilize data from different EHR vendors as each would have exposed their data through common “EHR API” methods. Developers could begin with already existing standards for patient summaries, quality metrics as mandated by some HIT standards.
Challenges under User Interface and Design
Challenge One: Create a framework and use it to demonstrate flexible and user-configurable EHR user interfaces.
A significant limitation of any EHR system is that their user interface screens are pre-set and rigid. For instance a page to view laboratory results of a patient cant be changed by the end-user to highlight say, a particular section above or below another one. EHR interfaces are repeatedly reported to be “cluttered” or “busy” because several pieces of information are provided in the same view. Not all sections are, however, equally important in a given context or for a care provider (the EHR screens are very likely to be same for each function whether a nurse is viewing the record or the doctor is viewing the same). In this challenge, developers will be asked to demonstrate a UI that can be configured for each end-user role type and one that allows further personalization by each user. Developers that can demonstrate UIs that “learn” from user behaviors and adapt accordingly (for example, if a user accesses only 3-4 links on a give page most of the time, then just display them prominently, instead of the entire page).
Challenge Two: Develop methods to record User interactions and events and to provide visualization tools to EHR developers to diagnose User Interface issues.
In this challenge developers will be asked to develop a state-of-the-art UI solution that allows EHR developers to track minute user interface interactions and events by users. For example, the said system should be able to track all mouse movements, all links clicked, track time spent on different sections of a web page, etc. The system should also provide visualization such as heat maps of the time spent in different section of a give page, charts displaying breakdown of types of events for a given users’ different sessions, or by aggregate statistics for different users. Similar, real-time site usage analytics are provided for websites by companies like ChartBeat.com. The intent would be to use this insight to identify UI challenges in given EHR systems and to improve them.
Challenge Three: Develop new displays for a patient record, particularly providing chronological timeline of a patient’s medical history
This is a “far out” challenge that will aim to let developers really think “out of the box” to come up with new models to display information about a patient in a manner that captures their most salient issues at hand and also provides a summative “timeline” documenting the major events in their medical history and profile. Given the emphasis on the “continuity of care’ and the fact that more than 100 million Americans suffer from at-least one chronic condition, providing such chronologically aware medical record summaries can be useful to both providers and patients. Any such solution should be able to demonstrate the ability to distinguish, at sufficient granularity, events that happen in acute episodes of care (where a critical event may happen every few minutes) versus events that span over months and years. Familiarity with “timelines” is likely to become more common with similar timelines being offered of one’s social life on sites like Facebook. Can developers learn from such breakthroughs in web-product design to the medical record?
Concluding thoughts
We believe that the Health Application Developer Challenges can be a significant opportunity to tap the innovation potential of the developer community to solve some of the vexing and cross-cutting challenges in current EHR system design and function. Given the central role of EHRs in the ONC’s strategy to promote HIT, solving such problems could provide significant value in the long run. The ONC has previously awarded $60million in research grants under the SHARP initiatives for innovations in EHR. Funding startup-oriented developer communities to tackle such grand challenges would be a further extension of this effort.
What do you guys think?