Ann Farrell hit it right on the head: "I'd be impressed if Glenn/AllScripts and other vendors talked about data models (not databases) and data definitions and focused equally on well publicized issues with EHR data integrity used in patient care and decision support, and lack of "normalization" needed for comparative effectiveness, analytics and BI. Await response of vendors and providers as the try to sort out the nomenclature soup."
What is lost in the Allscripts Open marketing discussion is the NORMALIZATION of data that is required just to link two Allscripts products in the inpatient and outpatient space together. Allscripts largest challenge with their Native Integration is just that - multiple hospitals, clinics, pharmacies, etc. ALL use different nomenclature. There's no sexy way of selling or bridging the gap between RxNorm and Multum, for instance. There is no sexy way of cross-tabling Med Allergy lists between acute and ambulatory spaces.
But guess what, that's what you need to be "Open." Community models, HIEs, ACOs - call it what you will, but data sharing requires Normalization, why don't we poll what health systems are going to do to bring all of their data together to start the OPEN discussion.
Bill - 12 years ago
We have been a long time Allscripts customer and have tried to implement many 3rd party solutions. Allscripts insists on us using their APIs which is a significant cost to both us and the 3rd party vendor. These APIs do not have the functionality that we need and have brought our entire environment down multiple times. If Allscripts wants to claim that they are open they need to create a stable set of APIs or Web Services and not charge the customer or 3rd party vendor.
Lacey Underall - 12 years ago
From an HL7 perspective... not even close.
From my perspective, the only thing they are open to is selling consulting to make their stuff work.
My favorite is when we figure out how to integrate their "million little pieces" they send us other customers asking how to do it.
I wish our hospital CIO would figure out how to leverege our consulting services.
Art_Vandelay - 12 years ago
Let's get ONC, CMS, GAO, OMB, DoD, VA and HIMSS to collaborate, release a RFP, have a large consulting/system integrator firm win the bid for $2 million and define "open" for us.
Open is in the eye of the beholder. To me, APIs and interface specs would be widely available. Perhaps my definition of "open" has been changed by vendors' poor responsiveness to calls for the bare minimums over time. Great food for thought!
Is having APIs the new defintion of "open"? To me open implies interoperable, not open source. Glen Tullman at ACE said "open is a state of mind" which is same kind of marketing glitz that keeps us from realities (data level) of interoperability. We've focused on HL7 for decades, then APIs and web services - data transport and exhange - avoiding really hard dicussion of the content and definitions of data we exhange. ICD-10 (a reference terminology used primarily for billing) has caused a near rebellion. Suddenly we're facing necessity for clinical nomenclature(s) and semantic interoperability, having put this on back burner since the 1980s.
Current version of ONC Stage 2 (final in Sept) includes a complex mishmash of LOINC, SNOMED and RxNorm (or libraries within) and other more esoteric standards. As former RN and VP R&D I remain skeptical this can be widely deployed practically and cost- effectively. I'd be impressed if Glenn/AllScripts and other vendors talked about data models (not databases) and data definitions and focused equally on well publicized issues with EHR data integrity used in patient care and decision support, and lack of "normalization" needed for comparative effectiveness, analytics and BI. Await response of vendors and providers as the try to sort out the nomenclature soup.
Whether Allscripts is "open" centers on the definition of the term "open."
"Open" conjures up notions of "open source" or at least multiple read/write APIs for a system, but it also reminds us of the important related concept of "extensible systems." An extensible software system is one that can be "extended" by someone other than the original developer AND in the programming language in which the system was written.
It isn't widely realized that three of the four successful long-lived integrated EHRs (with single patient database) are extensible by this definition.
The VA VistA's programming Standards & Conventions (SACs) allowed the extension of VistA over the years by VA sites nationwide, with -- for example -- the Puget Sound VA developing VistA's Provider Order Entry (POE) system, and the Topeka VA writing VistA's Bar Code Medication Administration (BCMA) module. VistA's extensibility under the VA's Decentralized Hospital Computer Program (DHCP) of the 1980s and 1990s is a principal reason why VistA now has more than 100 major sub-systems and an estimated 125,000 function points.
Cerner's EHR can be extended using Cerner Command Language (CCL), which is a proprietary "scripting language" in which as much as a quarter of the Cerner EHR's logic is written. Many Cerner sites employ multiple CCL programmers, and books on CCL are available from Amazon.
And perhaps surprising to many, Epic's EHR is also extensible by Epic customers, as Epic makes source code and documentation available so that customer organizations can develop name-spaced code and data structures that extend Epic's functionality in a manner similar to Epic's customizations of their system for their clients. Epic encourages customers to use the other mechanisms for enhancing the functionality of the Epic EHR, but they also support what they term "free range programmers" in their customers' organizations.
Meditech, the fourth of the long-lived integrated EHR systems, has a closed code base.
Finally, Allscripts' supports extension of their Sunrise environment using a package called ObjectsPlus that has a reputation for being hard to use, and requires highly skilled and expensive programmers -- which makes it an impractical proposition for many Sunrise customers.
--
Rob - 12 years ago
I would ask Lakeway Regional Medical Center in Lakeway, Texas. They are the most recent customer to implement a complete and comprehensive portfolio of Allscripts products/applications including all administrative, financial, clinical, departmental and medical device connectivity except Cardiology. Partner systems for PACS and Surgery Management. Speak to the hospitals and healthcare clients not the vendor for accurate information.
Bella - 12 years ago
Allscripts is promoting the concept of enabling non Allscripts resources to augment it's offerings via an API. They talk of having add on applications available in a way similar to how Apple does it with iTunes. I think that this is a more contemporary and open approach than seen from other healthcare vendors.
Mundeep Chaudhry - 12 years ago
Open systems don't require $10,000 sign up fees and annual renewal costs in the thousands as well. If the purpose of this open system is to encourage innovation, then the company should be looking at what all comers have to offer whether it is just an idea or a fully functional system. A company the size of Allscripts should be able to take any idea and bring it to market if they think it is worth developing.
Jalapeno...... "On A Stick" - 12 years ago
Until EPIC, Meditech, Cerner and others, allow you to interact with their code at the API level, then yes, I'd say Allscripts is open. If you compare it to GNU/GPL licenses, then no it's not open. Vendors must maintain some level of control if the application is to be supported by the vendor.
The real question is Healthcare ready for any really open systems? Healthcare is one of the worst industries for blaming the vendor for everything negative about an application rather than taking taking control of their own environment. Many healthcare organizations hire a young IT resource that immediately creates an ODBC connection to the HIS database and write a rouge app or report that ties up the database. Then they open a support ticket with the vendor for slowness. I've seen it over and over. They create Citrix environments that map printers, drives, bring over large profiles, etc. Then they open a support ticket complaining about logon times.
An open system is one where customers and vendors can implement various connections to the system, without requiring restrictive access and licensing agreements. Windows is an open system: anyone can develop applications for Windows without having an NDA with Microsoft or having Microsoft approve your license terms.
Ann Farrell hit it right on the head: "I'd be impressed if Glenn/AllScripts and other vendors talked about data models (not databases) and data definitions and focused equally on well publicized issues with EHR data integrity used in patient care and decision support, and lack of "normalization" needed for comparative effectiveness, analytics and BI. Await response of vendors and providers as the try to sort out the nomenclature soup."
What is lost in the Allscripts Open marketing discussion is the NORMALIZATION of data that is required just to link two Allscripts products in the inpatient and outpatient space together. Allscripts largest challenge with their Native Integration is just that - multiple hospitals, clinics, pharmacies, etc. ALL use different nomenclature. There's no sexy way of selling or bridging the gap between RxNorm and Multum, for instance. There is no sexy way of cross-tabling Med Allergy lists between acute and ambulatory spaces.
But guess what, that's what you need to be "Open." Community models, HIEs, ACOs - call it what you will, but data sharing requires Normalization, why don't we poll what health systems are going to do to bring all of their data together to start the OPEN discussion.
We have been a long time Allscripts customer and have tried to implement many 3rd party solutions. Allscripts insists on us using their APIs which is a significant cost to both us and the 3rd party vendor. These APIs do not have the functionality that we need and have brought our entire environment down multiple times. If Allscripts wants to claim that they are open they need to create a stable set of APIs or Web Services and not charge the customer or 3rd party vendor.
From an HL7 perspective... not even close.
From my perspective, the only thing they are open to is selling consulting to make their stuff work.
My favorite is when we figure out how to integrate their "million little pieces" they send us other customers asking how to do it.
I wish our hospital CIO would figure out how to leverege our consulting services.
Let's get ONC, CMS, GAO, OMB, DoD, VA and HIMSS to collaborate, release a RFP, have a large consulting/system integrator firm win the bid for $2 million and define "open" for us.
Open is in the eye of the beholder. To me, APIs and interface specs would be widely available. Perhaps my definition of "open" has been changed by vendors' poor responsiveness to calls for the bare minimums over time. Great food for thought!
Is having APIs the new defintion of "open"? To me open implies interoperable, not open source. Glen Tullman at ACE said "open is a state of mind" which is same kind of marketing glitz that keeps us from realities (data level) of interoperability. We've focused on HL7 for decades, then APIs and web services - data transport and exhange - avoiding really hard dicussion of the content and definitions of data we exhange. ICD-10 (a reference terminology used primarily for billing) has caused a near rebellion. Suddenly we're facing necessity for clinical nomenclature(s) and semantic interoperability, having put this on back burner since the 1980s.
Current version of ONC Stage 2 (final in Sept) includes a complex mishmash of LOINC, SNOMED and RxNorm (or libraries within) and other more esoteric standards. As former RN and VP R&D I remain skeptical this can be widely deployed practically and cost- effectively. I'd be impressed if Glenn/AllScripts and other vendors talked about data models (not databases) and data definitions and focused equally on well publicized issues with EHR data integrity used in patient care and decision support, and lack of "normalization" needed for comparative effectiveness, analytics and BI. Await response of vendors and providers as the try to sort out the nomenclature soup.
Whether Allscripts is "open" centers on the definition of the term "open."
"Open" conjures up notions of "open source" or at least multiple read/write APIs for a system, but it also reminds us of the important related concept of "extensible systems." An extensible software system is one that can be "extended" by someone other than the original developer AND in the programming language in which the system was written.
It isn't widely realized that three of the four successful long-lived integrated EHRs (with single patient database) are extensible by this definition.
The VA VistA's programming Standards & Conventions (SACs) allowed the extension of VistA over the years by VA sites nationwide, with -- for example -- the Puget Sound VA developing VistA's Provider Order Entry (POE) system, and the Topeka VA writing VistA's Bar Code Medication Administration (BCMA) module. VistA's extensibility under the VA's Decentralized Hospital Computer Program (DHCP) of the 1980s and 1990s is a principal reason why VistA now has more than 100 major sub-systems and an estimated 125,000 function points.
Cerner's EHR can be extended using Cerner Command Language (CCL), which is a proprietary "scripting language" in which as much as a quarter of the Cerner EHR's logic is written. Many Cerner sites employ multiple CCL programmers, and books on CCL are available from Amazon.
And perhaps surprising to many, Epic's EHR is also extensible by Epic customers, as Epic makes source code and documentation available so that customer organizations can develop name-spaced code and data structures that extend Epic's functionality in a manner similar to Epic's customizations of their system for their clients. Epic encourages customers to use the other mechanisms for enhancing the functionality of the Epic EHR, but they also support what they term "free range programmers" in their customers' organizations.
Meditech, the fourth of the long-lived integrated EHR systems, has a closed code base.
Finally, Allscripts' supports extension of their Sunrise environment using a package called ObjectsPlus that has a reputation for being hard to use, and requires highly skilled and expensive programmers -- which makes it an impractical proposition for many Sunrise customers.
--
I would ask Lakeway Regional Medical Center in Lakeway, Texas. They are the most recent customer to implement a complete and comprehensive portfolio of Allscripts products/applications including all administrative, financial, clinical, departmental and medical device connectivity except Cardiology. Partner systems for PACS and Surgery Management. Speak to the hospitals and healthcare clients not the vendor for accurate information.
Allscripts is promoting the concept of enabling non Allscripts resources to augment it's offerings via an API. They talk of having add on applications available in a way similar to how Apple does it with iTunes. I think that this is a more contemporary and open approach than seen from other healthcare vendors.
Open systems don't require $10,000 sign up fees and annual renewal costs in the thousands as well. If the purpose of this open system is to encourage innovation, then the company should be looking at what all comers have to offer whether it is just an idea or a fully functional system. A company the size of Allscripts should be able to take any idea and bring it to market if they think it is worth developing.
Until EPIC, Meditech, Cerner and others, allow you to interact with their code at the API level, then yes, I'd say Allscripts is open. If you compare it to GNU/GPL licenses, then no it's not open. Vendors must maintain some level of control if the application is to be supported by the vendor.
The real question is Healthcare ready for any really open systems? Healthcare is one of the worst industries for blaming the vendor for everything negative about an application rather than taking taking control of their own environment. Many healthcare organizations hire a young IT resource that immediately creates an ODBC connection to the HIS database and write a rouge app or report that ties up the database. Then they open a support ticket with the vendor for slowness. I've seen it over and over. They create Citrix environments that map printers, drives, bring over large profiles, etc. Then they open a support ticket complaining about logon times.
An open system is one where customers and vendors can implement various connections to the system, without requiring restrictive access and licensing agreements. Windows is an open system: anyone can develop applications for Windows without having an NDA with Microsoft or having Microsoft approve your license terms.