Strict Standards for the Structure of Data
William A. Hyman
Professor Emeritus, Biomedical Engineering
Texas A&M University, w-hyman@tamu.edu
Read other articles by this author
The EHR incentive (and penalty) program and its Meaningful Use criteria have set requirements for the capabilities of EHR products and for the use of those products by eligible professionals and hospitals. Some of these criteria are relatively straightforward and the dwindling pool of EHR vendors has created the capability to do that which is required, although they haven’t necessarily created the ability to do those things well or easily. Other criteria such as clinical information exchange have proceeded more slowly, with efficient and useful information exchange being a current stumbling block that has resulted in calls for alteration and delay in the requirement.
In an ideal world one might suppose that a requirement to do certain things would follow the existence of the capability to do those things, i.e. here is the capability and thus you should use this capability to do what we have required you to do. In this approach you would not have requirements until the capability has been built, and preferably tested. From the bad analogy department, this might be like adding seatbelts to cars before requiring their use. This approach might be too timid for some since it depends on the commercial vendors to provide significant leadership.
The alternative, as practiced at least in part in the EHR rollout, is for the government to demand that you do certain things, in multiple stages, and then task the vendors to develop the associated capability in a timely manner in order to have a certified product, followed by the customers of the vendors buying, upgrading and in some cases changing their EHR product in order to keep up with the expanding demands. The analogy here is requiring seatbelt use before there are seatbelts in order to force the vendors to add them.
The latter approach might be seen as bolder and faster in that it doesn’t require waiting for capability before you require that capability, and it makes the players hustle to develop, buy and use the capability in order to meet the requirements. In this regard one person’s bold becomes another person’s headache. This might be fine if there is well known practical methodology, and perhaps even demonstrated feasibility, to achieve the required performance in the given environment. For another automotive analogy, more efficient cars can be effectively required if the increase in efficiency is deemed to be well within the capability of the automobile companies–which is always a battle whenever improvements in fuel efficiency is under discussion. However, if the fuel efficiency demand is too high, and the means to achieve it are unknown or impractical, then the requirement and the availability are not likely to converge.
Part of the challenge in EHR information exchange is that there are still multiple vendors who have built products that have at best cumbersome means to communicate with each other. In fact there have been accusations that some vendors have built in such difficulty on purpose to advance their proprietary interests. Part of the answer is strict standards for the structure of the data so that all EHRs create and receive data in a compatible way. While such standards (of debatable strictness) are under development, to date the requirement to communicate has preceded the ability to communicate.