Healthcare IT, integration, and making patient care better
Category Archives: Uncategorized
February 19, 2013Posted by on
Since I started Ignis Systems in 1999 as a one-person software consulting organization, I have tried periodically to look at “what comes next”, as difficult as that is when in the middle of running a business. Over the past couple of years it had become clear to me that we were approaching a major fork in the road: whether to continue to grow our business organically, or to create a partnership that would allow for the next stage of our growth. If the latter, the two big questions were (a) what form such a partnership might take, and (b) who would be the ideal partner.
We believe we have found the ideal partner in Liaison Healthcare, a division of Liaison Technologies. Their focus is on interoperability, cloud-based solutions, and being able to scale to meet the data management challenges emerging in healthcare. And that’s exactly what we have been doing, on a smaller scale.
As important as their business model is, we also were looking for someone with the agility and the focus on customer success to allow us to continue to grow and adapt in our segment of the market, and where there were strong synergies with their solutions and services offerings. And we had to like their people.
We have just started this journey together, but personally I am enthusiastic about this next stage of our business growth. I look forward to keeping you posted.
January 2, 2013Posted by on
Several years ago the promise of patient access and control of their own health data was being promoted by organizations such as Google and Microsoft, as well as smaller players, where any person could have immediate access to information about their health. This view was patterned on the success of online banking, which is now ubiquitous, sophisticated, and (usually) free. But Google Health is now gone, Microsoft HealthVault provides only very limited capabilities, and progress in fulfilling this promise has largely stalled.
There are newer players who are attempting to continue moving this vision forward: Dossia and Avado are examples. But currently, access to health data by patients is essentially limited to “tethered” PHR’s or Patient Portals, which can access data from a single EHR and present it to the user via a single application.
Contrast this limited view with the “ecosystem” model of web applications and now, increasingly, mobile applications. Interesting combinations of these apps can be assembled that share data and present it in novel ways. Developers are free to create new tools and plug them into existing data, and users have a wide range of choice in selecting these apps.
The missing ingredient for doing this in the healthcare domain is a data platform that provides simple, secure access to health data about the user/patient, gathered from a number of sources: primary care providers, hospitals, labs, outpatient service providers, pharmacies, etc. An HIE could conceivably provide a significant portion of this data. But are HIEs really equipped to do this?
The current generation of HIE technology is generally tethered to a large EHR system, or perhaps a few such systems, and doesn’t have the ability to gather data from a wide variety of sources. And while there are standards that allow for transmission of data into an HIE from a variety of other systems, the ability to access this data in a multitude of ways from a variety of applications is very limited. HIEs are not currently designed with an Open Systems philosophy.
There are technical and business reasons for this. Technically, standards for HIEs data access have not kept up with the current world of online applications. HIE standards are still based on a messaging paradigm between large software systems, and address only a limited number of use cases. On the business side, HIEs are very expensive to deploy and their sponsors generally have a “pay to play” data access model to fund HIE operations. This makes them unattractive to the small app developer, who wishes to provide a healthcare application at little or no cost.
So, it seems that for now we are stuck. Valuable health information is locked in EHR and HIE systems where it’s not available to patients or to their other providers. App developers are ready to create novel applications, and users are ready to use them, but these applications are hampered by inability to access the patient’s health data. And the business model around a truly open health data system is not at all clear; the government-sponsored HIE initiatives really haven’t moved things forward in this respect.
There is at least a glimmer of hope in the SMART application model (see: http://smartplatforms.org/). The data access is simple and this technology could allow common apps to connect to different healthcare data repositories. The ONC has gotten behind this approach but it isn’t clear yet whether it will get the required commercial traction. However, this appears to be a promising direction to enable much more widespread use of this data.
November 2, 2012Posted by on
Like most of America, we at Ignis Systems were watching the development of hurricane Sandy over the weekend, and as it hit the East Coast late last Sunday. While we are located in Portland, Oregon, many of our clients are on the East Coast.
By Monday we were not only seeing the same news reports as everyone else, but were getting independent confirmation of how serious the situation was: our systems started alerting us that communications links to labs and medical practices were dropping in large numbers. This was largely a function of power outages, though we found out in some cases that there was major physical damage to some of these facilities.
As a provider of cloud-based lab and radiology applications, we were actually in a position to help. In one case, a lab who lost power at their data center was able to relocate their servers to another facility, and by creating an emergency VPN for them we were able to reconnect them to their practices. We also offered our web-based ordering and lab results review system to those practices whose EHRs were offline, so they could continue caring for patients.
This situation has been a forceful reminder of one of the key attributes of cloud technology: location independence. As providers and labs have scrambled to provide services from temporary locations, cloud-based services have continued to be available.
Of course, cloud services themselves need to be robust against disasters like this. At least one major EHR hosting provider lost power at their data center, affecting numerous hospitals on the East Coast. In our case, our cloud-based services are hosted by a global hosting partner with much more experience in disaster recovery than we have. We depend on them to keep us up no matter what.
As millions on the East Coast are trying to get back to normal, we were glad to be able to help in a small way to allow healthcare to continue during the disaster.
October 24, 2012Posted by on
A recent posting on Michigan Health Connect indicates that while this state-wide HIE is handling 820,000 lab results per month, it is only handling about 5000 orders per month. This 160-fold disparity highlights the issues with trying to use HIEs for bidirectional lab communications.
Lab results distribution is a relatively straightforward problem for an HIE. The format standards are relatively mature, and technology exists for routing data through a network to the correct ordering provider, based on identifiers in the message itself. The results may or may not be mapped to a standard vocabulary; many EHRs have not made this a requirement for lab data. However, with LOINC adoption increasing, result code mapping will also become a straightforward exercise.
Standardizing orders is much more difficult, because it’s not just a data routing and formatting problem. Most EHRs don’t create a complete order that’s ready to send to the lab. And many legacy Lab Information Systems don’t accept unsolicited inbound orders, because they require manual patient registration before the order can be accepted.
Meaningful Use Stage 2 will at least require the EHR to be able to record the ordered tests in the patient chart. Many EHR vendors who are new to lab orders will probably limit their development to that basic capability; there are too many other conflicting priorities with MU2, ICD-10, and other mandatory requirements.
Recording the requested tests and associated diagnoses, as part of a patient’s assessment and plan, is only the first step in the ordering process. The remainder of the ordering workflow of capturing billing data, patient status at the time of the draw, specimen collection or scheduling, and transmission of the order to the lab require additional user actions beyond the basic order capture. This is complicated by order splitting requirements, routing to multiple labs based on insurance rules, future and standing orders, etc.
Well-designed lab ordering systems can greatly increase the electronic order-to-result ratio. Electronic orders not only make operations more efficient for the lab, but they greatly simplify the tracking and reconciliation process of orders at the practice. Some lab hub vendors have shown that the combination of good ordering workflow support and these operational efficiencies can raise the electronic order ratio to 60-70% or higher.
These ordering efficiencies are not going to result from an HIE alone. At best the HIE can provide the necessary communications link from the ordering system to the lab. And until there are certification requirements around generation and transmission of complete lab orders, it is unlikely that more than a few EHR vendors will create robust ordering solutions. Until that time, lab ordering applications that bridge the gap between the EHR and the HIE are likely to persist.
September 5, 2012Posted by on
With news that a number of public HIEs are struggling or have already terminated services, it seems time to look closely at the HIE landscape and see if we are really on the right path. If the goal is to have a place where all the relevant data about a patient can be accessed for the patient’s care, by all providers involved with that care as well as by the patient, it doesn’t seem that we are making significant progress.
The private HIE market, i.e. HIEs owned and operated by health systems to meet their own needs, is seeing robust growth. Large health systems have a variety of internal interoperability challenges, as well as a need to provide specific types of information to providers in their community, such as lab results. But these private HIEs rarely incorporate patient data created outside the health system. Connecting ambulatory EHRs to the HIE remains a slow, expensive process, and neither the practice nor the health system have been able to build the business case for doing this.
State and regional HIEs have used their stimulus funding to try a variety of architectures. The one that seems to have the most traction is based on NwHIN Direct, which allows a provider to send patient information securely to another provider. There are currently significant policy challenges in allowing Direct communication across HIE boundaries, because each HIE has its own strict rules on participation. These Direct-based HIEs generally provide a web portal for sending and receiving messages, but don’t provide integration into each provider’s EHR. As a basic email-like messaging system Direct is useful, but it doesn’t address the need to provide an overall view of the patient’s health or allow later access to existing data.
State and regional HIEs that were intended to provide a database or repository of patient data for query access have run into a number of significant barriers: cost, complexity, consent requirements and access control policies to name a few. These are the HIEs that are currently struggling the most, because large entities that might fund the operation of the HIEs (insurance companies, health systems, or the states themselves) haven’t seen the value.
Even if these HIEs were sustainable, the barriers imposed by regional and state boundaries will inhibit creating a consistent view for many patients who seek care in different states.
Health Information Exchange is enormously complex and we shouldn’t expect to see results immediately. But it is critical to assure that we are moving in the right direction or we’ll never get there. I believe some critical elements of a successful approach are:
– A data architecture organized around the patient, not around existing political and business boundaries.
– A radically simpler and more lightweight data model than currently defined by HL7 and IHE standards.
– An open architecture and business model that allows vendors, provider organizations, consultants, and government entities to build and deploy connections to the data with minimal legal and financial barriers. Cloud-based technology seems like a natural fit for this but most of the challenges are not technical.
We have learned a lot in the past few years as HIEs have been started across the country, and the stimulus funding has allowed rapid progress in a number of areas. Now we need to assure that we are moving in the right direction.
May 20, 2012Posted by on
In 2008, my wife of 30 years, Theresa, succumbed to ALS, also known as Lou Gehrig’s Disease. This is a progressive neurological disorder for which there is currently no effective treatment. It is invariably fatal, and robs the sufferer of the ability to perform even the most basic human tasks: moving, talking, eating, and ultimately, breathing. As the disease progresses it requires more and more equipment and support to maintain a modest quality of life.
I have worked with the ALS Association for over seven years, and they do a wonderful job of supporting families and caregivers who are doing their best to assist those living with this disease. This year, Ignis Systems is proud to be a sponsor of the Ride To Defeat ALS, a bicycle event in Mount Angel, Oregon. Funds to this organization assist with equipment, education, and other support resources as well as clinical research. The ride is in the beautiful Willamette Valley and has options for 25, 50 and 100 mile rides. Our team goal is to raise $5000.
If you are in the Oregon area and are interested in riding with us, we would encourage you to join our team. If not, we would really appreciate any financial support you can give us for this event. For more information or to join our team, see: Ignis Riders Team Page
April 13, 2012Posted by on
Besides the onslought of new EHR installations that is resulting in a great increase in the number of connectivity requests for lab results, there are additional requirements coming from a variety of directions that will present further challenges to already stretched lab IT resources:
- The ICD-10 conversion which was going to happen by 2013 has been pushed out to 2014 but will still require considerable work.
- HHS is considering requirements for labs to send electronic results directly to patients.
- Meaningful Use Stage 2 will require specific coding standards to be used (specifically ICD and LOINC). In Meaningful Use Stage 1, there were requirements for structured data but the actual code sets were unspecified. The Stage 2 requirements are still in process but a proposal has been publicized.
- Meaningful Use Stage 2 may also require use of the Lab Results Interface (LRI) Implementation Guide developed as part of the ONC-sponsored Standards and Interoperability (S&I) Framework project.
- New Regional and State HIE initiatives expect to receive lab results from labs; in addition public health reporting will become a stronger requirement for Meaningful Use.
- The S&I project has now turned its attention to standardizing orders from EHRs, which has been a notoriously difficult area.
- All of these standardization efforts are based on HL7 version 2.5.1, but most lab systems are still generating HL7 v2.3. Upgrading the HL7 version will require requalifying existing intefaces to the new standard level, and will depend on the HL7 capabilities of data partners (practices and HIE vendors).
A number of these initiatives have incentive funding or other funding sources directed to providers and hospitals as part of ARRA, but none of the funding is directed to independent labs (and little of it benefits hospital labs). In the meantime business pressures are increasing on labs. Hospitals are under pressure to reduce redundant testing and readmissions, and these will result in lower test volumes for hospital labs. Outreach and commercial lab business is under pressure from larger national competitors as well as new competitors (physician office labs and perhaps even drugstore chains).
Many labs continue to address data exchange with their customers via software packages purchased from their LIS vendor, coupled with add-on packages such as integration engines and LIS front-end products. This approach leaves the lab’s IT team to do much of the technical work of establishing secure communications, mapping formats and data from the lab system to a variety of EHRs, maintaining and upgrading existing interfaces, and providing technical support to practices. They may have the perception that outsourcing lab integration is expensive, but the combination of predictable costs, much more rapid response, and expertise in dealing with the variety of integration scenarios can result in substantial savings to the lab over the long run.
A successful lab integration relationship requires a partner with significant lab expertise in both orders and results; a scalable data distribution infrastructure; a variety of integration capabilities including web and mobile orders and results; and the implementation and customer support resources to understand the practice’s workflows and bring clients live quickly and predictably. And that partner is in a better position track and respond to the variety of standard activities impacting the lab.
March 29, 2012Posted by on
The ONC has recently published guidelines for patient security, privacy and access related to HIEs funded by the ARRA program. Given the case that sustainable funding for HIEs is already a serious issue, anything that increases HIE complexity is going to make that situation worse. The new ONC guidelines do exactly that, because they add a strong requirement for individual patient access and control to the HIE.
HIPAA already requires that patients have the ability to request EHR data from their providers, to determine who has accessed their data, and to correct any errors. The ONC guidelines now apply those same requirements to any HIE funded through the State Health Information Exchange Cooperative Agreement Program.
One of the major consequences of this rule is that the HIE will require a patient portal. Given the level of access that patients are entitled to, it’s unrealistic to expect that the state or State Designated Entity (SDE) can respond to patient access requirements any other way. Along with the portal will be a requirement for a reliable way to identify patients who are attempting to access the information in the HIE. The policy also requires that patients can designate others to access this data on their behalf.
The policy requires that individuals have meaningful choices as to whether to share their data with the HIE, and to be able to restrict access by provider. There is a strong recommendation (though not a requirement) that this control can be exercised at a finer granularity than “all or nothing”. This will place a burden on providers to either receive opt-in permission, or give the patient an opt-out opportunity, before sharing that patient’s data with the HIE. A blanket notification that data will be shared with the HIE unless the patient objects isn’t sufficient according to these guidelines.
An interesting requirement is that, in order to access data about a patient stored in the HIE, a provider must have or be in the process of establishing a treatment relationship with the patient. Presumably this is to prevent providers from using the HIE to search for new customers. But it will require very strict controls on who is allowed to access data, and leaves open the question of how the HIE would verify that a provider has a right to access the data for a particular patient.
It is important to note that these regulations only affect HIEs funded through the federal program, and specifically excludes HIEs that only support directed exchange between known parties. So one side-effect of these regulations may be to weaken state-level HIEs that “store, assemble and aggregate” data and drive providers to private HIEs, commercial clinical hubs (such as the Surescripts ePrescribing hub or the Ignis lab and radiology hub) or directed exchange networks, which aren’t governed by these policies.
March 23, 2012Posted by on
“Cloud Computing” has become a common buzz-phrase in Healthcare IT over the past few years, and as often happens with jargon like this, the definition becomes fuzzier the more people use it. This ambiguity makes it hard to really discuss the pros and cons of different remotely hosted architectures.
In common usage now, Cloud Computing or Cloud Hosting tends to mean an application is hosted remotely and accessed via an Internet connection. But the original usage of the term was much more specific: hosting of multiple instances of an application or applications on a set of servers, using Virtual Machine technology.
Prior to the Cloud explosion, remotely hosted applications generally had a set of servers for each customer. If the resource requirements for a particular customer were small, having its own servers would be very expensive. Conversely, if resource requirements grew beyond the capabilities of the current servers, an expensive hardware upgrade was required. Virtual machines allow the resources for the application to be initially limited, then smoothly increased as needs change, and a virtual machine containing the customer’s application and data can be transparently moved to new hardware.
This approach works extremely well for applications which were originally designed to support one customer. Each customer has their own dedicated computing environment in the same way as if they had their own servers: their own copy of the operating system (e.g., Windows Server), their own version of the application, and their own database. However, not all internet hosted applications operate this way. Highly scalable systems, for example Facebook and this blog site (WordPress), use a different architecture referred to as a “multi-tenant architecture”.
A multi-tenant system is designed from the ground up to support a large number of customers. There is a single instance of the application (perhaps spread across multiple servers for performance and availability) and an integrated data management system. Unlike cloud applications where a new virtual machine is created and configured for each customer, a multi-tenant system usually just requires a small amount of registration data to set up a new customer.
Multi-tenant systems minimize the per-customer maintenance work, because software updates apply to all customers immediately. Operations that cross customer boundaries, such as reporting, monitoring, and communications with other systems are simpler to implement in a multi-tenant system.
The EMR-Link lab hub system that Ignis Systems has developed is a multi-tenant system, supporting thousands of users in an integrated architecture. We believe that this is the best architecture for scalability and for data distribution from hundreds of labs and radiology services to all our providers.
So, when you look at a system that uses the term “cloud”, you may need to dig a little further to understand what that means for your particular needs, since not all applications referred to as cloud-based have the same characteristics. And a cloud solution may not be the best fit in all cases.
March 11, 2012Posted by on
The Apple iCloud system, and similar online backup systems for non-Apple systems (e.g., Carbonite and Dropbox) have added a new dimension to data backup. Yes, part of their role is to keep your data safe in case something bad happens to your computer. But they also provide a simple, intuitive way to make your data available where ever you need it. It seems that this is a capability that could be of significant use to healthcare providers with regard to their EHR data.
I’m not talking about an HIE system. HIEs attempt to address a much more complex set of problems: sharing data across organization boundaries, reconciling data about the same patient from different sources, reporting biosurveillance and immunization data to government entities, etc. What an ambulatory provider needs is much simpler: a way to get to data about his or her own patients, reliably and under a variety of circumstances.
Web-hosted EHRs can do some of this. Data is available from home or office; some of these EHRs have mobile device support; and the EHR vendor (presumably) backs up the data to insure against loss. However, the vast majority of EHR users don’t have this ability, and can only access their EHR in the office.
Healthcare practices have a range of disasters they need to protect against. Besides the usual failed hard drive, office fire or natural disaster, there is a new one: failure of an EHR vendor. There are now some 600 ATCB-certified EHRs on the market; within a few years the majority of those will no longer be in business. That means that many providers will be switching EHRs during that time, and trying to salvage their patient data to be loaded into their new EHR.
If data were stored in a cloud-based system in a neutral format, such as XML, it could readily be provided to a different EHR or to an HIE. It would also be possible to provide outcomes reporting beyond what is provided by an EHR vendor on their own internal data. Such a system would stimulate its own ecosystem of tools and applications, without requiring an EHR vendor partnership for each one.
There are risks, or course. Updates to this storage system would need to be reliable and automatic, as they are with iCloud, to assure that information was up-to-date. HIPAA requirements would need to be met to assure privacy and availability. Internet outages would still be an issue for access to this data. But overall, data availability would be much better than it is today.