The Last Mile for Healthcare Startups

By Paul Boal, Practice Lead Amitech Solutions; ITEN Mentor

Healthcare is hot for startups.  There are huge opportunities to improve the healthcare industry: introducing new devices, finding diagnostic and treatment patterns from existing data, and streamlining business operations.  Getting your MVP from the demo environment to an actual customer deployment is likely to face a number of unexpected challenges.  If you don’t already have significant prior experience being in your customer’s business, it will be valuable to gain some insight into the day to day operations of healthcare systems and the most common ways that healthcare systems integrate.

  • Healthcare IT professionals are not necessarily the stereotype you have in mind; so respect their individuality and get to know each customer.
  • Healthcare IT departments are often faced with an overload of competing business owners, legacy systems they can’t seem to eliminate, and lots of pressure to innovate; recognize that you are just one of many things on their plate.
  • Healthcare standards are not perfectly standardized; but know how they work and be prepared to collaborate with your customers on the best solution to work within their standards and integration patterns.

The Health IT Lot-in-Life

Healthcare has had a reputation of being less than quick to adopt new technologies and well known for an overburden of legacy applications.  Here are some real examples:

  • We can’t upgrade Internet Explorer because we have an orthopedics application that isn’t certified past IE 8.
  • Our revenue cycle vendor won’t build any new interfaces because all that’s left of the company is a guy in his garage who wants to retire.
  • To integrate your solution with our EHR would require our vendor to turn on another interface, which will cost at least $10,000 just to enable.

It’s important to recognize that all of these things that might make it difficult for a healthcare IT department to quickly incorporate your new technology into their environment aren’t born from stubbornness or ignorance, but are simply facts.  Think about these things as constraints that your product merely has to find a way to work within or work around, rather than people who are choosing to be obstacles to your success.

That’s not say there aren’t certain people who like to be obstructionists, but it’s best to give everyone the benefit of the doubt, hear out their concerns, and spend time understanding the underlying reason for their objection or constraint.  Once you’ve spent time listening and understanding, you’re likely to find common ground and be able to work together more effectively at getting your product implemented.  You’re also more likely to gain insights that will be helpful in making the next implementation more smooth.

Understanding Health IT Priorities

In addition to all the usual challenges of large corporate IT and the glut of legacy applications, healthcare IT departments have other challenges including a unique diversity of priorities, highly regulated and non-profit environment, and special sensitivity around data privacy.  

Whereas a typical corporate IT department might have just a few key lines of business and the regular assortment of shared services to juggle priorities among, the business model for large healthcare systems tends to be more fragmented and diverse.  (Wikipedia lists around 48 common medical specialty classifications used in the US.)  Each of these specialties is often managed as an independent (but interdependent) P&L within the larger organization, meaning that all of the leaders in each of these specialties will set and promote independent priorities.  In addition to competing business priorities, these specialties often have their own business and clinical systems (or modules within a large single-vendor EHR).  Your product will probably be applicable to or internally promoted by one of these specialty or functional interests.

  • Be sensitive to the fact that the IT department will have a lot of priorities and probably some confusion about where you will fit into those.
  • Use daily touch-base calls with everyone involved in the implementation to keep things move smoothly.
  • Ask what you can do to make the implementation go as smoothly as possible.  Offer to take work off of IT’s plate if that’s practical to do.
  • Use your business or clinical sponsor to escalate issues when you aren’t getting the time you need from IT and other shared services.

Health IT Spending

There’s a saying in healthcare that “every dollar spent on something else is a dollar that isn’t being spent treating patients.” However naive you think that saying might be, it does resonate with healthcare leadership, most of whom are in the industry for the mission rather than the money.  As a result, spending on health IT is heavily scrutinized.  Ironically, the same people promoting the importance of spending on patient treatment are likely to also complain about why MS Office hasn’t been upgraded on their laptop since 2007.

“What will it cost us?” When you’re talking with your customers about what your product will cost them, are you thinking about the cost to them or are you actually only thinking about the revenue to you.  When you’re talking to your buyer (a physician or administrator), they are probably not thinking about the time and effort it will take for IT or their other vendors to do any integration and testing work.  The technology teams that you eventually end up working with to get your product implemented are going to resent the fact that their time wasn’t taken into account.  It will look bad that they’re adding cost to the project.  This will likely make your working relationship with them more difficult because they might see you as a the cause of the misunderstanding.

  • Make sure that you’re clear about the costs of implementing your product including licensing costs; any supporting hardware, software, or other infrastructure costs; costs of getting data for or integrating data with other existing systems; the time and effort to deploy your solution; etc.
  • Ask your buyer to engage the IT department and any other vendors sooner rather than later, so that all of the costs of implementation are visible to the buyer upfront.

Healthcare IT Standards

Suggesting that the existing health IT standards solve integration challenges is like saying because the web uses HTML, anyone can read and understand every page. Even so, you need to be familiar with some of the core standards so that you have a common starting point for integration conversations.

HL7 – Health Level 7 is a broad set of standard formats and methodologies for the integration of healthcare related systems.  The most common use of HL7 is in the exchange of messages between multiple clinical and registration systems.  You’ll hear a lot about various messages types like ADT (admit, discharge, and transfer) or ORD (order) transactions.  This standard is heavily used, real-time, and a good one to use for transactional data integration or event messaging.  Unfortunately, not all healthcare systems have a robust enterprise messaging infrastructure. A few are still point-to-point between applications, making it hard to intercept or inject your own messages.

FHIR – Fast Healthcare Interoperability Resources (the most recent HL7 addition) is a REST-style standard for exchanging data between applications.  Most of the large EHR vendors now support FHIR to one degree or another, but many smaller or legacy systems won’t have support for this standard, yet.

CCD/ CCR – Continuity of Care Document and Continuity of Care Record are additional HL7 standards that were developed to provide a snapshot summary of a health record that can be used by health information exchanges.  Most EHR systems support both the export and import of this kind of document.  It doesn’t have the transaction level detail that many operational applications need and can be costly (time and compute resources) to produce.

X12 – Accredited Standards Committee X12 has a series of standard messages types that are used in healthcare billing and claims transactions.  You’ll often hear about 837 messages (a claim transaction) in the world of health insurance.  While primarily financial in their purpose, claims are also commonly used source of diagnosis and treatment records because they transcend any one given provider and they are more standardized that most other healthcare transactions.  Unfortunately for any real-time applications, they also tend to lag behind the actual delivery of service by anywhere from a few up to 45 days.

CCOW – Clinical Context Object Workgroup is another HL7 standard, but is used to define how clinical application user interfaces should share information with one another.  A CCOW enabled application will be able to let other applications on the same workstations know which patient’s information is currently visible and what kind of screen is being displayed.  It is powerful, but underutilized because most implementations rely on low-level technologies like COM and CORBA.

Questions You’ll Face

You need to come into integration conversations with lots of flexibility and your own ideas about how to integrate with existing systems.  The IT teams you work with probably won’t have predefined answers for how integration has to work and may not have complete control over the selection of the solution. Some of the questions and criteria to consider will be:

  • Does you solution need to exchange data in “real-time”? For most most healthcare IT teams, real-time data exchange is more expensive and more challenging that batch data transfer.  In fact, be very clear and careful about what you mean when you say “real-time” – because of their history with other vendors, some healthcare IT professionals will mean “daily” when they say “real-time” because they’re used to batch processes that only run once a month!  “We need that data in real-time by 7:00 AM every morning!”
  • Does your solution need to write data back to any existing system?  Writing to an existing clinical system will likely be more difficult to accommodate than simply reading data, but it may be necessary if you want to embed the value of your solution into the existing business or clinical workflow.
  • Do you have patient identifiers or patient demographics? If your solution will have patient-level data in it, then it’s likely to have some kind of patient identifier or patient demographics that can be tied back to an individual human being.  This data is considered to be as sensitive as passwords and financial information.  Don’t be scared of this, but be prepared to sign a business associate’s agreement and vouch for how that data is being protected in flight and at rest by your solution.

In addition to these high level questions, the technical conversations about how to integrate with existing solutions will likely begin with a question from the IT team asking “what format do you need the data in and how do we send it to you?” or “do you already have a connector for our vendor’s system?”  If you respond with “what format can you send us the data in?” or “what’s the standard for integrating with that system?” the conversation won’t get very far and you’ll feel like the vultures at the end of the classic 1967 Jungle Book movie asking each other “What we gonna do?”  “I don’t know, what you wanna do?”

Here are some questions to ask and options to consider offering:

  • Do you know if that vendor has any existing API, interfaces, or extracts that might provide the data we need?
  • Do you have an existing interface engine that we should connect with?
  • Do you have any standard or typical way of managing batch interfaces?
  • We’re happy to work with files in a lot of different formats – JSON, XML, CSV, pipe-delimited.
  • Do you have any existing extracts from that system that might meet our needs or that we can use as an example?
  • Here’s a list of the kind of data that we’re going to need.  Can we work with someone to map those to your existing system?

If this is the first time you’re deploying your system or integrating with a specific vendor’s solution, recognize the amount of effort that the IT team will need to invest in helping you do the integration.  Don’t trivialize that investment on your customer’s part.  You may even want to consider discounting your costs to show your appreciation for their time and effort.

Don’t Give Up

The opportunity to improve the quality, cost, and experience of healthcare is huge and this is one of the most important industries to be innovating in right now.  As a healthcare startup, you’re certain to face challenges getting your product implemented, but know that as long as you share the same passion for helping patients and improving health care that your customers have, you’ll be able to find a way to work together.

About Paul

Paul is the Enterprise Information Management Practice Lead for Amitech Solutions, and is passionate about delivering big data solutions for healthcare. For the past 15 years, Paul has been leading data management and business intelligence teams, and architecting healthcare analytics solutions. His experience ranges from traditional data warehouses to Hadoop-based solutions, master data management, advanced analytics, and real-time clinical data integration.