Halaman

    Social Items

/ Without Label / A Proposal for Disruptive Regulation of EHRs
The latest salvo in the interoperability and information-blocking debate comes from two academic experts in the field of informatics, and was recently published in JAMIA. In the brief article, Sittig and Wright are endeavoring to describe the prerequisites for classifying an EHR as “open” or interoperable. I believe the term “open” is a much better fit here, and if the EHR software happens to come from a business dependent on revenues, as opposed to grant funding from the government, bankrupt may be a more accurate description. Since innovation in the EHR market seems to lack any disruptive effects, perhaps a bit of disruptive regulation would help push everything over the edge.

Although the article seems to be just another shot at Epic, the currently #1 EHR in the country, which is privately owned and run by a woman (a seemingly irritating anomaly in the EHR world), it does have some interesting points worth exploring. The authors propose five overlapping use cases to describe functionality that is important to five stakeholder groups: clinicians, researchers, administrators, software developers and lastly, patients. Let’s look at each one in more detail (pay attention, since we’ll have a quiz at the end), and keep in mind that these requirements are meant to be enforced on all EHRs, including the relatively cheap little one you have in your office.

Use case 1: Extract

The first use case states that a client facility should be able to extract patient records from an EHR, while maintaining granularity of structured data, with the goal of creating “a new secondary-use database”  for internal purposes, or most likely for research. To enable the client to extract data and migrate it to a different database structure, the EHR vendor is required to provide the client with its “data dictionary”. A data dictionary is a detailed description of the EHR database schema, all its tables, views, data types, what the data means, how it connects to other tables, constraints, references, packages, procedures, and a whole lot more.

For the less technically inclined among us, the database structure, or the model, of a serious transactional software application is its heart and soul. The user interface, which is what you as a user see every day, is secondary and easily changed. Chances are that if you used the same EHR for a few years, you have witnessed such changes multiple times. You can certainly build a horrific user interface on top of an excellent model, but you can never build a great user experience on top of a lousy data model. The database structure is not written in stone either, but changes to the model entail excruciating effort and huge expenditures. The data dictionary, if done well, is both description and recipe for recreating the entire application, and as such it is the main portion of a vendor’s intellectual property.

Data dictionaries are usually provided to large clients that host their EHR onsite, and are mostly used to build interfaces with other systems. As health insurers continue to dump risk on health systems, database extractions are increasingly being used for other purposes as well. In the ambulatory market, data dictionaries are not usually shared with customers, since small practices have little to no ability to do independent software development. If your EHR is hosted in some cloud, in truly multi-tenant software as a service (i.e. data from multiple customers is stored in one database structure), you will not get any dictionary and you will never be allowed to access the vendor database, and rightfully so. The best you can hope for in this case is a data dump from your vendor.   

Use case 2: Transmit

This use case is a slightly expanded version of the current Meaningful Use requirement to generate and transmit clinical information in standard format (e.g. C-CDA) to another clinical facility or to an external personal health record (PHR). The goal here is to facilitate referrals or other transitions of care, and to prop up third party PHRs that nobody is interested in using.

Use case 3: Exchange

Here EHRs are required to be available 24/7 to accept programmatic requests from other EHRs for patient records. I am not sure what the significance of 24/7 is in this context, but basically the EHR should be able to respond to ad-hoc queries from any other EHR, locate the requested records, if any, and return a standard based response to the requestor. This use case is supposed to facilitate EHR agnostic community-wide health-information exchange, presumably (and strangely) without using a health information exchange (HIE) entity as mediator. Another peculiarity is the completely superfluous demand that the responding EHR should make its data dictionary available to all querying EHRs, which boils down to publishing the whole thing online, or on demand, for all competing (and aspiring) EHR vendors to enjoy, and to further democratize the hacking industry.

Use case 4: Move

This use case is intended to reduce costs of switching EHR vendors, while ensuring that all data in the old EHR, including metadata and transactional histories are transferred to the new system. To better understand this noble requirement, let’s look at how easily a health system can switch banks. If an organization uses say, US Bank for ten years, and then wishes to transition their accounts, to say, Bank of America, US Bank will first provide its complete data dictionary to the switching organization to be shared with Bank of America developers. Then US Bank will provide an extract of all financial data, including historical transactions and all metadata (e.g., timestamps, source, and authors) so everything is migrated and preserved in the Bank of America system. Other than the logos, the organization would not see any difference really, and this will all be done for little to no cost to the switching health system. If this has not been your experience, then you should call the banks and complain.

Use case 5: Embed

The fifth and last use case is about application programming interfaces (APIs) on steroids, and it enables health systems to develop new EHR features or functionality and seamlessly incorporate those into the EHR. This implies full access to read, edit and delete database content, as well as ability to augment database structures, while the original EHR is expected to incorporate these changes automatically into its basic services such as security and privacy. Essentially, an EHR should become a development platform with functionality exceeding that of the best operating systems out there. For example, if an EHR lacks the ability to collect and process PHQ-9 data, an institution could develop such functionality independently, while the EHR will be expected to incorporate the functionality in its own workflows, screens, decision support, and HIPAA protections, practically out of the box.

Putting all five use cases together and using a tortured way to come up with an acronym, the authors dubbed their framework for defining an open and interoperable EHR, EXTREME, and extreme it is. The framework is written from the point of view of a large health system dealing with a large EHR vendor, and understandably so, since this seems to be the authors’ natural habitat. Applying this framework to the hundreds of EHRs and EHR modules that have been certified by the government to date will ensure that this big business habitat is the only model left standing. There is a cost to transitioning a software package from being a product or a service, to being a development platform. That cost is beyond the reach of most existing EHR companies. For the remaining few, the cost will eventually be passed down to current customers, as was the case with all government mandates imposed on EHRs. Small practices and small hospitals, already struggling to stay afloat, will be dealt the final coup de grâce.

The authors state that this upheaval is necessary “if we are to realize the enormous potential of an EHR- enabled health care system”. Six years and billions of dollars since we embarked on this journey and all we can come up with is some elusive “potential” that will certainly materialize if only we could spend a little more money, and if only we could drive a few more people out of this business, and only if we take the necessary next step, which we are told is to dismantle “the myriad socio-legal barriers to widespread health information exchange”, which is newspeak for removing any and all remaining privacy and informed consent protections for individuals, whether they like it or not. The truth is that we have no research, no proof and no reason to believe that the mythical “potential” even exists, let alone that the bigger-is-better, top-down model of health surveillance is best suited to unlock this “potential”.

I have to confess here that I have no idea what an open and interoperable EHR is. I also don’t know what a high usability EHR looks like. I do however know what a good EHR is, not a perfect one, but a good enough EHR. Just like any other piece of software, from Microsoft Office to Oracle Financials, a good EHR is one that people choose to purchase. If other people think there are better ways, then by all means, they should build amazing new software and fairly compete in the EHR market, instead of engaging in armchair quarterbacking of rules and regulations to advance theoretical concepts that captured neither market interest nor customer dollars on their own merit.

Quiz Question: Of the 5 stakeholders listed at the top, which one is absent, from all EXTREME use cases? Answer: The patient. Even in the tangential use case where data may be transmitted to a PHR, the patient is a passive entity, while the “organization” decides when, if and what to transmit. At some point, the few patient advocates who have not yet been thoroughly corrupted by the deluge of cash and fame, will have to come to terms with the grim realization that everything done and said nowadays is not intended to benefit the people, and health care is no longer an exception.

A Proposal for Disruptive Regulation of EHRs

The latest salvo in the interoperability and information-blocking debate comes from two academic experts in the field of informatics, and was recently published in JAMIA. In the brief article, Sittig and Wright are endeavoring to describe the prerequisites for classifying an EHR as “open” or interoperable. I believe the term “open” is a much better fit here, and if the EHR software happens to come from a business dependent on revenues, as opposed to grant funding from the government, bankrupt may be a more accurate description. Since innovation in the EHR market seems to lack any disruptive effects, perhaps a bit of disruptive regulation would help push everything over the edge.

Although the article seems to be just another shot at Epic, the currently #1 EHR in the country, which is privately owned and run by a woman (a seemingly irritating anomaly in the EHR world), it does have some interesting points worth exploring. The authors propose five overlapping use cases to describe functionality that is important to five stakeholder groups: clinicians, researchers, administrators, software developers and lastly, patients. Let’s look at each one in more detail (pay attention, since we’ll have a quiz at the end), and keep in mind that these requirements are meant to be enforced on all EHRs, including the relatively cheap little one you have in your office.

Use case 1: Extract

The first use case states that a client facility should be able to extract patient records from an EHR, while maintaining granularity of structured data, with the goal of creating “a new secondary-use database”  for internal purposes, or most likely for research. To enable the client to extract data and migrate it to a different database structure, the EHR vendor is required to provide the client with its “data dictionary”. A data dictionary is a detailed description of the EHR database schema, all its tables, views, data types, what the data means, how it connects to other tables, constraints, references, packages, procedures, and a whole lot more.

For the less technically inclined among us, the database structure, or the model, of a serious transactional software application is its heart and soul. The user interface, which is what you as a user see every day, is secondary and easily changed. Chances are that if you used the same EHR for a few years, you have witnessed such changes multiple times. You can certainly build a horrific user interface on top of an excellent model, but you can never build a great user experience on top of a lousy data model. The database structure is not written in stone either, but changes to the model entail excruciating effort and huge expenditures. The data dictionary, if done well, is both description and recipe for recreating the entire application, and as such it is the main portion of a vendor’s intellectual property.

Data dictionaries are usually provided to large clients that host their EHR onsite, and are mostly used to build interfaces with other systems. As health insurers continue to dump risk on health systems, database extractions are increasingly being used for other purposes as well. In the ambulatory market, data dictionaries are not usually shared with customers, since small practices have little to no ability to do independent software development. If your EHR is hosted in some cloud, in truly multi-tenant software as a service (i.e. data from multiple customers is stored in one database structure), you will not get any dictionary and you will never be allowed to access the vendor database, and rightfully so. The best you can hope for in this case is a data dump from your vendor.   

Use case 2: Transmit

This use case is a slightly expanded version of the current Meaningful Use requirement to generate and transmit clinical information in standard format (e.g. C-CDA) to another clinical facility or to an external personal health record (PHR). The goal here is to facilitate referrals or other transitions of care, and to prop up third party PHRs that nobody is interested in using.

Use case 3: Exchange

Here EHRs are required to be available 24/7 to accept programmatic requests from other EHRs for patient records. I am not sure what the significance of 24/7 is in this context, but basically the EHR should be able to respond to ad-hoc queries from any other EHR, locate the requested records, if any, and return a standard based response to the requestor. This use case is supposed to facilitate EHR agnostic community-wide health-information exchange, presumably (and strangely) without using a health information exchange (HIE) entity as mediator. Another peculiarity is the completely superfluous demand that the responding EHR should make its data dictionary available to all querying EHRs, which boils down to publishing the whole thing online, or on demand, for all competing (and aspiring) EHR vendors to enjoy, and to further democratize the hacking industry.

Use case 4: Move

This use case is intended to reduce costs of switching EHR vendors, while ensuring that all data in the old EHR, including metadata and transactional histories are transferred to the new system. To better understand this noble requirement, let’s look at how easily a health system can switch banks. If an organization uses say, US Bank for ten years, and then wishes to transition their accounts, to say, Bank of America, US Bank will first provide its complete data dictionary to the switching organization to be shared with Bank of America developers. Then US Bank will provide an extract of all financial data, including historical transactions and all metadata (e.g., timestamps, source, and authors) so everything is migrated and preserved in the Bank of America system. Other than the logos, the organization would not see any difference really, and this will all be done for little to no cost to the switching health system. If this has not been your experience, then you should call the banks and complain.

Use case 5: Embed

The fifth and last use case is about application programming interfaces (APIs) on steroids, and it enables health systems to develop new EHR features or functionality and seamlessly incorporate those into the EHR. This implies full access to read, edit and delete database content, as well as ability to augment database structures, while the original EHR is expected to incorporate these changes automatically into its basic services such as security and privacy. Essentially, an EHR should become a development platform with functionality exceeding that of the best operating systems out there. For example, if an EHR lacks the ability to collect and process PHQ-9 data, an institution could develop such functionality independently, while the EHR will be expected to incorporate the functionality in its own workflows, screens, decision support, and HIPAA protections, practically out of the box.

Putting all five use cases together and using a tortured way to come up with an acronym, the authors dubbed their framework for defining an open and interoperable EHR, EXTREME, and extreme it is. The framework is written from the point of view of a large health system dealing with a large EHR vendor, and understandably so, since this seems to be the authors’ natural habitat. Applying this framework to the hundreds of EHRs and EHR modules that have been certified by the government to date will ensure that this big business habitat is the only model left standing. There is a cost to transitioning a software package from being a product or a service, to being a development platform. That cost is beyond the reach of most existing EHR companies. For the remaining few, the cost will eventually be passed down to current customers, as was the case with all government mandates imposed on EHRs. Small practices and small hospitals, already struggling to stay afloat, will be dealt the final coup de grâce.

The authors state that this upheaval is necessary “if we are to realize the enormous potential of an EHR- enabled health care system”. Six years and billions of dollars since we embarked on this journey and all we can come up with is some elusive “potential” that will certainly materialize if only we could spend a little more money, and if only we could drive a few more people out of this business, and only if we take the necessary next step, which we are told is to dismantle “the myriad socio-legal barriers to widespread health information exchange”, which is newspeak for removing any and all remaining privacy and informed consent protections for individuals, whether they like it or not. The truth is that we have no research, no proof and no reason to believe that the mythical “potential” even exists, let alone that the bigger-is-better, top-down model of health surveillance is best suited to unlock this “potential”.

I have to confess here that I have no idea what an open and interoperable EHR is. I also don’t know what a high usability EHR looks like. I do however know what a good EHR is, not a perfect one, but a good enough EHR. Just like any other piece of software, from Microsoft Office to Oracle Financials, a good EHR is one that people choose to purchase. If other people think there are better ways, then by all means, they should build amazing new software and fairly compete in the EHR market, instead of engaging in armchair quarterbacking of rules and regulations to advance theoretical concepts that captured neither market interest nor customer dollars on their own merit.

Quiz Question: Of the 5 stakeholders listed at the top, which one is absent, from all EXTREME use cases? Answer: The patient. Even in the tangential use case where data may be transmitted to a PHR, the patient is a passive entity, while the “organization” decides when, if and what to transmit. At some point, the few patient advocates who have not yet been thoroughly corrupted by the deluge of cash and fame, will have to come to terms with the grim realization that everything done and said nowadays is not intended to benefit the people, and health care is no longer an exception.

No comments

Subscribe to: Post Comments (Atom)