4 ms·

I wonder if current attempts at EHR interoperability are a case of "the perfect is the enemy of the good". Obviously the ideal solution would be one where well-

I wonder if current attempts at EHR interoperability are a case of "the perfect is the enemy of the good". Obviously the ideal solution would be one where well-structured interoperable datasets are produced and shared. This would enable very targeted analysis of patient data, and sophisticated clinical decision support functionality. However, it seems like this is still not happening, and the convoluted nature of many HL7 standards is certainly not helping. So I've come to think that it would actually be preferable to put most of the health data into PDF-like documents, and focus on optimizing the accessibility of the data through good full-text document search that can assemble an overview by showing document snippets (i.e., allowing to get a broad cross-document overview through document previews, rather than requiring opening each document individually). I guess some kind of especially important data, such as information on current medication or drug intolerance should really be kept in a fully structured format to enable clinical decision support, but for a lot of other information, a light-weight system based on unstructured data combined with good information retrieval tools would already improve on the status quo quite significantly.

akira2501 8y ago
> So I've come to think that it would actually be preferable to put most of the health data into PDF-like documents I've thought about this before and came to nearly the same conclusion. It would also help in extremes, allowing doctors to switch back to pure paper should the situation call for it while allowing for that information to be smoothly integrated back into the system once it becomes available again. What good is an EHR if the power is out? > I guess some kind of especially important data, such as information on current medication or drug intolerance should really be kept in a fully structured format to enable clinical decision support Which may help, but as detailed by this article the process of ordering healthcare and the eventual delivery of that care to the patient is often a patchwork of multiple departments and staff with ample opportunities for error anyways. I used to volunteer in the pharmacy. We'd get an order for a medication. We'd fill and then label that medication. It would then go into a bin on a cart, one bin for each department in the hospital. The cart would go out, and the bins would get delivered. The medication would then be stocked in the department using a slightly different setup for each department. Then the nurses would have their own individual processes for getting that medication, taking it to the patient and then delivering it to them. An EHR is _one_ very small part of successfully performing this complicated ballet.
nradov 8y ago
A standard for exporting summary patient charts in plain text or PDF already exists as the VA Blue Button format. It works to an extent, but the lack of coded data limits effectiveness. And there are still practical problems in that most providers don't have easy ways to import files given to them by patients. There are serious security concerns with accepting files from untrusted sources. https://www.va.gov/bluebutton/ https://www.va.gov/bluebutton/
_corym 8y ago
Health care is by nature very complicated and any attempt at standardization is going to be sophisticated. Just look at how many ICD-10 codes there are. HL7 is complicated but I see a lot of work being done to conform with the FHIR standards. FHIR has only been around since 2014 and release 3 was only completed last year. I do have hope for standards to take precedence in the EHR realm but it will take time. Most EHR software was created in the late 80's and there's a lot of legacy code, client customization, and regulations to go through in order to release this code. Healthcare doesn't leverage itself to an agile "move fast and break things" ideology. In addition the Commonwell alliance was supposed to help alleviate these problems, but the fact that Epic didn't join really ruined things there.
- msamwald 8y ago
  Yes, but FHIR was the result of many years that had previously been wasted with HL7 v3, which was so convoluted that at some point some people in the community gave up on it and came up with FHIR to get things done. The clock did not start ticking in 2014. HL7 already wasted a lot of time and effort, to the very real detriment of many patients around the world.
  - nradov 8y ago
    It's easy to criticize in hindsight but FHIR wouldn't have been possible without the lessons learned from HL7 V3 so there was really no wasted time. Sometimes the only way to learn is to make mistakes. FHIR by itself is no panacea; it has some nice improvements, and makes implementations significantly cheaper and more efficient but it doesn't enable any fundamental new use cases. HL7 V3 standards such as CDA R2 are actively used today to deliver patient care all over the world.
- nradov 8y ago
  ICD-10 contains thousands of codes, but unfortunately even with all those sometimes it still isn't complicated enough! There are important diagnostic concepts that can't be expressed with sufficient detail in ICD-10, so we end up having to supplement it with additional code systems such as SNOMED-CT.
- 8y ago
dqv 8y ago
>However, it seems like this is still not happening, and the convoluted nature of many HL7 standards is certainly not helping. I actually think HL7 (as an organization) is beginning to get us to a point where it's not as convoluted. >So I've come to think that it would actually be preferable to put most of the health data into PDF-like documents, and focus on optimizing the accessibility of the data through good full-text document search that can assemble an overview by showing document snippets (i.e., allowing to get a broad cross-document overview through document previews, rather than requiring opening each document individually). I think that's what is intended with FHIR (fast healthcare interoperability resources)[0]: >A domain resource is [a] resource that [...] has a human-readable XHTML representation of the content of the resource IIRC all the other FHIR extend the DomainResource class. So you have the narrative and then the resources (supporting data) that makes up that narrative. [0]: https://www.hl7.org/fhir/domainresource.html https://www.hl7.org/fhir/domainresource.html
- cmiles74 8y ago
  I would disagree that the HL7 organization is looking to make these standards less convoluted. On the contrary, the large and established vendors help write these standards. In my opinion, it is in their interest to leave enough room in the standards to require ever more and more software in order to bridge the gap between systems. I have worked on several integration projects, we always had to customize the interface on both sides of the system (the hospital information system on one side, perhaps a radiology system on the other). Moving one step up and exchanging data between hospital information systems and all of the smaller vendor systems is just that much more complex.
  - dqv 8y ago
    Did you use something like Mirth Connect? I was going to ask what HL7 you were using, but it looks like you were using v2. > In my opinion, it is in their interest to leave enough room in the standards to require ever more and more software in order to bridge the gap between systems. I get your point. When I read about FHIR extensions, my immediate assumption was that a vendor would use it to throw a wrench. But FHIR does have an idea of conformance that I think better addresses the issues with earlier standards.
cmiles74 8y ago
In my opinion, the state of EHR interoperability should be attributed to the vendors of hospital information systems (i.e. Epic, Meditech, etc.) and their larger clients, big healthcare systems. Again, in my opinion, neither of these stakeholders has much, if any, incentive to develop and encourage a smooth or even mostly functional interoperability story. Every vendor wants to lock their customers into their product. Software vendors see interoperability as a wedge into their lock-in on their customers, making it easier to migrate data from one system to another. I believe the incumbents fear an innovator rather than the other established players. But they would prefer to make it harder to migrate away from their systems, regardless of the target. Healthcare companies want to keep customers inside the walled garden of their system and actively discourage them from moving to competing vendors. In their view, patients should receive all of their treatment from them or their close partner organizations. I don't believe that clinicians at these organizations are looking to hurt or bamboozle anyone; they are of the opinion that their healthcare organization provides a higher quality of healthcare. And, in all honesty it is safer: those partner organization who have access to the same central system will have access to all of the customer's data. I once worked for a small healthcare system and my team designed and implemented software to transfer information from one organization to another through disparate systems. The organizations involved were partners, when interoperability with competitors was discussed this was quickly pushed aside: the project needed to be kept "cost effective" and these were "version 2.0" improvements. While these are reasonable arguments, communication with competing organizations was never implemented. The managers of the project were correct: it would cost money to implement this interoperability, money that would be out of pocket for the organization. And to what end? To help customers purchase a competing vendors products. The HITECH act was meant to provide the money to fund interoperability. But now that I've worked for both healthcare and software vendors, it is less clear to me... What was the goal of the HITECH act? For the healthcare side, the goal was clearly to computerize the medical records and this was the cudgel used to force clinicians to carry laptops around as they spoke to patients; the organization I worked for managed to almost entirely eradicate clipboard usage. From the software vendor side the goals were similar, to provide the functionality required by the act in order to qualify as a "meaningfully useful" system. Interoperability between organization seemed to have been sketched in at the end and the guidelines didn't seem nearly as clear. To my mind the question boils down to: how does the government (state or federal) incentivize interoperability? Clearly a single payer system would be the easiest answer: the government would be paying for all care and could simply demand this interoperability be present. While single payer isn't the only solution, I beliebe we will need a change of similar size to push these vendors into cooperating, despite the fact that it might hurt their bottom line.

akira2501 8y ago

> So I've come to think that it would actually be preferable to put most of the health data into PDF-like documents I've thought about this before and came to nearly the same conclusion. It would also help in extremes, allowing doctors to switch back to pure paper should the situation call for it while allowing for that information to be smoothly integrated back into the system once it becomes available again. What good is an EHR if the power is out? > I guess some kind of especially important data, such as information on current medication or drug intolerance should really be kept in a fully structured format to enable clinical decision support Which may help, but as detailed by this article the process of ordering healthcare and the eventual delivery of that care to the patient is often a patchwork of multiple departments and staff with ample opportunities for error anyways. I used to volunteer in the pharmacy. We'd get an order for a medication. We'd fill and then label that medication. It would then go into a bin on a cart, one bin for each department in the hospital. The cart would go out, and the bins would get delivered. The medication would then be stocked in the department using a slightly different setup for each department. Then the nurses would have their own individual processes for getting that medication, taking it to the patient and then delivering it to them. An EHR is _one_ very small part of successfully performing this complicated ballet.

nradov 8y ago

A standard for exporting summary patient charts in plain text or PDF already exists as the VA Blue Button format. It works to an extent, but the lack of coded data limits effectiveness. And there are still practical problems in that most providers don't have easy ways to import files given to them by patients. There are serious security concerns with accepting files from untrusted sources. https://www.va.gov/bluebutton/ https://www.va.gov/bluebutton/

_corym 8y ago

Health care is by nature very complicated and any attempt at standardization is going to be sophisticated. Just look at how many ICD-10 codes there are. HL7 is complicated but I see a lot of work being done to conform with the FHIR standards. FHIR has only been around since 2014 and release 3 was only completed last year. I do have hope for standards to take precedence in the EHR realm but it will take time. Most EHR software was created in the late 80's and there's a lot of legacy code, client customization, and regulations to go through in order to release this code. Healthcare doesn't leverage itself to an agile "move fast and break things" ideology. In addition the Commonwell alliance was supposed to help alleviate these problems, but the fact that Epic didn't join really ruined things there.

msamwald 8y ago
Yes, but FHIR was the result of many years that had previously been wasted with HL7 v3, which was so convoluted that at some point some people in the community gave up on it and came up with FHIR to get things done. The clock did not start ticking in 2014. HL7 already wasted a lot of time and effort, to the very real detriment of many patients around the world.
- nradov 8y ago
  It's easy to criticize in hindsight but FHIR wouldn't have been possible without the lessons learned from HL7 V3 so there was really no wasted time. Sometimes the only way to learn is to make mistakes. FHIR by itself is no panacea; it has some nice improvements, and makes implementations significantly cheaper and more efficient but it doesn't enable any fundamental new use cases. HL7 V3 standards such as CDA R2 are actively used today to deliver patient care all over the world.
nradov 8y ago
ICD-10 contains thousands of codes, but unfortunately even with all those sometimes it still isn't complicated enough! There are important diagnostic concepts that can't be expressed with sufficient detail in ICD-10, so we end up having to supplement it with additional code systems such as SNOMED-CT.
8y ago

dqv 8y ago

>However, it seems like this is still not happening, and the convoluted nature of many HL7 standards is certainly not helping. I actually think HL7 (as an organization) is beginning to get us to a point where it's not as convoluted. >So I've come to think that it would actually be preferable to put most of the health data into PDF-like documents, and focus on optimizing the accessibility of the data through good full-text document search that can assemble an overview by showing document snippets (i.e., allowing to get a broad cross-document overview through document previews, rather than requiring opening each document individually). I think that's what is intended with FHIR (fast healthcare interoperability resources)[0]: >A domain resource is [a] resource that [...] has a human-readable XHTML representation of the content of the resource IIRC all the other FHIR extend the DomainResource class. So you have the narrative and then the resources (supporting data) that makes up that narrative. [0]: https://www.hl7.org/fhir/domainresource.html https://www.hl7.org/fhir/domainresource.html

cmiles74 8y ago
I would disagree that the HL7 organization is looking to make these standards less convoluted. On the contrary, the large and established vendors help write these standards. In my opinion, it is in their interest to leave enough room in the standards to require ever more and more software in order to bridge the gap between systems. I have worked on several integration projects, we always had to customize the interface on both sides of the system (the hospital information system on one side, perhaps a radiology system on the other). Moving one step up and exchanging data between hospital information systems and all of the smaller vendor systems is just that much more complex.
- dqv 8y ago
  Did you use something like Mirth Connect? I was going to ask what HL7 you were using, but it looks like you were using v2. > In my opinion, it is in their interest to leave enough room in the standards to require ever more and more software in order to bridge the gap between systems. I get your point. When I read about FHIR extensions, my immediate assumption was that a vendor would use it to throw a wrench. But FHIR does have an idea of conformance that I think better addresses the issues with earlier standards.

cmiles74 8y ago

In my opinion, the state of EHR interoperability should be attributed to the vendors of hospital information systems (i.e. Epic, Meditech, etc.) and their larger clients, big healthcare systems. Again, in my opinion, neither of these stakeholders has much, if any, incentive to develop and encourage a smooth or even mostly functional interoperability story. Every vendor wants to lock their customers into their product. Software vendors see interoperability as a wedge into their lock-in on their customers, making it easier to migrate data from one system to another. I believe the incumbents fear an innovator rather than the other established players. But they would prefer to make it harder to migrate away from their systems, regardless of the target. Healthcare companies want to keep customers inside the walled garden of their system and actively discourage them from moving to competing vendors. In their view, patients should receive all of their treatment from them or their close partner organizations. I don't believe that clinicians at these organizations are looking to hurt or bamboozle anyone; they are of the opinion that their healthcare organization provides a higher quality of healthcare. And, in all honesty it is safer: those partner organization who have access to the same central system will have access to all of the customer's data. I once worked for a small healthcare system and my team designed and implemented software to transfer information from one organization to another through disparate systems. The organizations involved were partners, when interoperability with competitors was discussed this was quickly pushed aside: the project needed to be kept "cost effective" and these were "version 2.0" improvements. While these are reasonable arguments, communication with competing organizations was never implemented. The managers of the project were correct: it would cost money to implement this interoperability, money that would be out of pocket for the organization. And to what end? To help customers purchase a competing vendors products. The HITECH act was meant to provide the money to fund interoperability. But now that I've worked for both healthcare and software vendors, it is less clear to me... What was the goal of the HITECH act? For the healthcare side, the goal was clearly to computerize the medical records and this was the cudgel used to force clinicians to carry laptops around as they spoke to patients; the organization I worked for managed to almost entirely eradicate clipboard usage. From the software vendor side the goals were similar, to provide the functionality required by the act in order to qualify as a "meaningfully useful" system. Interoperability between organization seemed to have been sketched in at the end and the guidelines didn't seem nearly as clear. To my mind the question boils down to: how does the government (state or federal) incentivize interoperability? Clearly a single payer system would be the easiest answer: the government would be paying for all care and could simply demand this interoperability be present. While single payer isn't the only solution, I beliebe we will need a change of similar size to push these vendors into cooperating, despite the fact that it might hurt their bottom line.