Melissa McCormack, a medical researcher with EHR consultancy group Software Advice, recently published their medical practice management BuyerView research, which found that 63% of the buyers were replacing existing PM solutions, rather than making a first-time purchase.  This mirrors the trend we’ve seen across medical software purchasing, where the HITECH Act may have prompted hasty first purchases of EHR solutions, followed by replacements 1-2 years later. For PM vendors, this means there’s a huge opportunity to market your products to practices as an upgrade, even if they’re already using PM software. I reached out to Melissa to ask her to elaborate on the implications of the trends she found in her recent research. Here’s some advice for vendors and solutions providers.

1. As EHR meaningful use requirements grow more involved, standalone billing or scheduling systems are becoming less viable. In fact, nearly 70 percent of the buyers we spoke with wanted integration between practice management and EHR. The trend of PM buyers looking for robust EHR integration grows more pronounced each year, and shows no signs of tapering off since EHR meaningful use requirements increasingly require physicians to utilize charting, billing and scheduling in tandem. Vendors who can offer seamless integration between these applications will have a clear advantage over those who cannot.

2. Another regulatory pressure influencing PM software replacement is ICD-10. Compliance with the new code set is a major driver not only of practice management purchases in general, but specifically of replacements—25% of buyers replacing an existing solution cite a concern that their current solution wouldn’t support the code set switch. Despite the implementation deadline having been extended to October 2015, we’re seeing practices give a lot of thought to preparation, and they’re realizing the software they use will play a major role in their own readiness. Vendors who are confident in their ICD-10 readiness should take care to communicate that confidence to their existing users, as well as marketing it to prospective customers.

3. The medical practice management software buyers we talk to clearly prefer cloud-based systems. Among buyers with a preference, 88% want cloud deployment. We’re hearing from smaller practices that they value the low up-front costs, as well as not needing to maintain servers and dedicated IT staff. Additionally, buyers appreciate the remote access options afforded by cloud solutions. Some buyers even seem to conflate “cloud” with “remote access” and “mobile access” (even though those features aren’t unique to cloud-based products), suggesting these are the features of cloud-based software they are most concerned with. In fact, almost 20% of buyers identified mobile access as a top priority. Vendors who offer mobile support are at an advantage and should highlight their capabilities prominently.

4.  Practice management software buyers come from diverse roles within practices. We saw clinicians and administrative staff represented almost equally—46% and 40%, respectively—among our buyer sample. Vendors should consider their audiences when marketing their products and tailor communication accordingly, giving equal weight to the unique benefits for clinicians and administrators.


I recently saw a demo of the platform and left impressed with the workflow engine, business rules execution, forms automation, and data integration platform. I’m very familiar with almost all the major HL7 routers and integration engines out there but Carl Hewitt, Founder and Chief Architect at Decisions, is releasing something fairly unique — an visual HL7 interface definition and integration platform for use by analysts and non-technical personnel charged with healthcare data connectivity across business workflows. I found their approach unique enough that I’ll be something that I don’t do often — a review. But, before I post the review in the coming days, I reached out to Carl to help set the stage and share the most common questions and answers we get about HL7.

What is HL7?

HL7 is how healthcare applications talk to each other – for example, when a patient is admitted to a facility, when a patient schedules an appointment, when a lab test is ordered, or when a medication is prescribed an HL7 message can be sent from one system to another. HL7 is what disparate systems use to tell each other about patient activity. HL7 is a widely adopted text based communications standard created in 1987 that can run on almost all modern hardware and software systems that support the standard.

The HL7 specification is governed by Health Level Seven International, a not-for-profit, ANSI-accredited standards developing organization.

How do HL7 systems communicate?

HL7 is human readable text that is broken up into meaningful sections and sent as data packets from application to application across well defined communication mechanisms with handshaking and acknowledgement procedures.  Because the data is sent over widely adopted communication mechanisms in a readable format (i.e., text that can be opened on any computer), HL7 tends to work pretty well.

What are the various components of HL7 messages?

Like any technology, HL7 uses a glossary of specific terms that have specific meaning.  While an interface engine alleviates the need to directly integrate with all of these concepts, understanding them will help you know what the HL7 engine is actually doing.

  • Envelope: Each communication from one system to another is contained in a block of data.  This block of data (Envelope) could contain one or more messages.
  • Message: A message is a set of data that is logically related (for instance, about a specific patient encounter or hospital admission).  A message is bounded by its type (Message Type) and contains a number of (Segments)
  • Message Type:  A message type is the definition of the structure of a communication and provides rules for what data sections (Segments) are required, which are optional, and the order of the data.  The order of the data in a message is important as one section (Segment) can have different meanings depending on where it is in the message.  Messages are usually referred to by their message type and event type, for example: an ADT^A01 is an ADT message with an event type of A01 which means that this is an Admission, Discharge, or Transfer type message (ADT) and is signaling the event that a patient was Admitted (A01).
  • Event: Events allow a message type to have slightly different meaning as described above.  Events are related to the message type and an important part of the standard.  The same message structure can be used to signal different types of events.  The same basic data is needed to admit and discharge a patient with only small differences.

HL7 has evolved over many years and new events have been added to the standard that weren’t there in previous versions.  For instance, an ADT A01 (ADT Patient Admit) and an ADT A08 (ADT Patient Data Update) were initially defined as different message types, but later combined.  So, a message that comes in as an ADT A08 in version 2.5 of HL7 will actually have the structure of an ADT A01, however, because it is sent as an A08 – the meaning of the message will be an update.  Confusing?  No worries, most interface engines hide this fact and make you think you are still getting an A08.

  • Segment: A segment is a section of a message that contains the actual values that are being sent between systems.  Generally, a segment can be thought of as a line in a message and it always starts with an identifier that indicates what the segment type is.  An example of a segment is “PID” (patient identifier) where information about a person or patient is sent, or “MSH” (message header) which is described below.  Segment identifiers are always 3 characters.
  • Message Header, MSH Segment:  Every message starts with an MSH segment that declares information about the message including its version, type, which text delimiters are used, etc.  This special segment is used to provide information as to how to interpret the entire message.
  • Optional, or Z Segments:  HL7 is a flexible standard and allows for users to send data between systems that the specification does not accommodate.  This is done by using a Z segments, which is a custom segment with an identifier that starts with Z.  Most people use the Z and then follow it with characters that are part of the specification.  For example, to send additional data about a patient identity someone might use ZID, a derivative of PID.
  • Data Type:  Every segment is composed of data elements.  Each of these data elements has a “type.”  Types may be number types like integer and decimal or dates, or more complex types defined by the standard.  These data types are positional in the ‘segment line’ and delimited by the defined character (usually a pipe, |) for the message.  A data type might have one or more pieces to it (itself being delimited by another delimiter).  For instance, a ‘Code’ data type has an ID and Description, but it is one element inside the segment.
  • Delimiters:  While the characters that can break up a message are by convention pretty standard, they can be defined in the MSH segment.  Each message segment is always on a new line, and each segment is subdivided into data by a pipe character, ‘|’, and each data type is subdivided into its elements by a caret, ‘^’.  See example message below for more information.
  • ACK/NAK:  Acknowledge or NOT acknowledge the receipt of a message.  Most HL7 systems can be configured to send back receipts of communication.  This allows systems to keep a careful audit of data sent between them.  Sending systems can generally be configured to resend or at least report messages that get no receipt or get a NACK (not acknowledge message) returned.
  • Interfaces:  An interface can mean slightly different things between software and hardware vendors, but essentially an interface is usually a connection between two systems.  When an HL7 data feed is configured from the Emergency Department in a hospital to the Electronic Medical Record system this is usually referred to as an interface.

 Some interfaces are one way – they either send data to another system or listen to data from another system.  Most interface engines or interface technologies support sending and receiving data as these technologies normally sit in between two medical systems and modify the messages as they are sent.  Different interface engines might have functionality to transform or route messages attached to interfaces.

How are HL7 text messages transmitted?

There are two primary technologies used to send message in most healthcare applications: TCP and Files.

  • Direct Connection (TCP):  Data can be transmitted over a network connection using TCP (also referred to as LLP or MLLP).  This is often referred to as a ‘direct’ connection or a real time connection between applications.
  • File Connection:  A simpler way of transmitting messages is by sending the data in a file or multiple files.  This can involve loading it into an application or configuring a directory to watch for new files to appear.  A file connection can also take the form of an FTP or SFTP server.

What does an HL7 Message Look like?

HL7 messages are made up of segments. Each carrying specific information about anything from a patient’s name to an allergy, a radiology image, a transcript, etc.

PID|||56782445^^^UAReg^PI||KLEINSAMPLE^BARRY^Q^JR||19620910|M||2028-9^^HL70005^RA99113^^XYZ|260 GOODWIN CREST DRIVE^^BIRMINGHAM^AL^35 209^^M~NICKELL’S PICKLES^10000 W 100TH AVE^BIRMINGHAM^AL^35200^^O |||||||0105I30001^^^99DEF^AN
PV1||I|W^389^1^UABH^^^^3||||12345^MORGAN^REX^J^^^MD^0010^UAMC^L||678 90^GRAINGER^LUCY^X^^^MD^0010^UAMC^L|MED|||||A0||13579^POTTER^SHER MAN^T^^^MD^0010^UAMC^L|||||||||||||||||||||||||||200605290900
OBX|1|NM|^Body Height||1.80|m^Meter^ISO+|||||F
OBX|2|NM|^Body Weight||79|kg^Kilogram^ISO+|||||F

In the message above you’ll notice some things that are ‘bold’ to call your attention to them.

  1. MSH the message header segment identifies the message.
  2. ADT^A01 shows us that we have a patient being admitted (A01) and the message structure is an ADT message.
  3. EVN is the event data with some key dates like when the message was sent
  4. PID is the patient identifier.  This has medical record numbers, names, and contact information.
  5. PV1 is the patient visit data which details this specific visit to a facility.
  6. OBX is an observation, like vitals taken by a nurse
  7. AL1 is the description of patient allergies

What type of data does HL7 Transmit?

The HL7 specification is fairly comprehensive.  It contains data about many aspects of health care and data including patients, schedules, appointments, interactions between providers and patients, insurance information, information on diagnoses and procedures, medical records and much more.  If an application is configured to receive all messages of all types from another application, it is likely that much of the data that is received is not relevant to what is needed.  For instance, if I have a scheduling application, it might not be relevant for me to get information on updates of patient allergies – but changes to patient demographic information is very important.

What are challenges with HL7 in the Healthcare Enterprise?

A growing challenge with contemporary Healthcare IT Solutions is the “app-centric” approach many vendors are taking to solving problems. With more and more of these enterprise apps being designed as standalone systems, Healthcare IT teams are faced with unique integration challenges involving sensitive patient health information.

Many teams are trying to figure out how to implement a data layer that can bring all of the healthcare provider systems (billing, lab, patient, etc.) and partner systems together so each has access to the data that it needs. Some are taking home grown approaches with custom message services and open source technologies. Others are discovering a new breed of data management tools. Let’s take a closer look at what some of the primary tools have been and what some of the new tools look like.

There are a number of unique challenges to handling a standard driven data structure such as:

  • Handling multiple versions to and from multiple sources.
  • Complicated nesting
  • Non-conformity
  • Communication Infrastructure
  • Dirty data
  • Cost of Integration



Zach Watson over at Technology wrote a nice piece on EHR Trends in Nashville. I’m not a big fan of “trends” articles because trends aren’t that important, the implications of those trends and how to operationalize the implications are most important. I enjoyed Zach’s article so I asked him to tell us what those trends mean for EHR buyers and health IT vendors writ large. Here’s what Zach said:

Our study of office-based physicians across the city of Nashville to gain insight into which EHR systems they were using, as well as how pleased they were with their systems revealed these insights:

  • Adoption rate among certain specialties is significantly higher than available national averages
  • Satisfaction rate among Nashville doctors is higher than benchmarks established by previous studies
  • 16 percent of respondents have already switched EHRs
  • Cost appears to be the priority with Nashville buyers, with Epic not cracking the market top 5

We chose to survey Nashville because of the city’s vibrant technology market, which includes an eclectic healthcare IT industry subset. Spotlighted in the Wall Street Journal, Nashville’s healthcare market features billion dollar organization Hospital Corporation of America, and has played host to over a billion dollars of investment capital in the last decade.

For buyers of electronic medical records, several key points can be taken from the results of the study.

For specialists, a mix of specialty specific products and highly customizable options has led to higher satisfaction than previously recorded averages. For example, 75 percent of dentists in Nashville use a best of breed system, such as Dentrix or Patterson Eaglesoft. The Satisfaction of dentistry EHR users was 8.5/10: significantly higher than previously tallied national averages. Not only do best of breed EHRs still have a place in the market, it seems that providers who chose such platforms realize high satisfaction rates.

However, it’s not quite as simple as just choosing a best of breed platform. Many other specialties – from Radiology, to Pulmonary Disease, to ENTs and Podiatry – reported using eClinicalworks, the market leader in Nashville. These providers were mostly satisfied with their selection as well as eClinicalWorks averaged an 8.5/10 satisfaction rate, leaving one to wonder what the answer truly is: a more general platform, or a best of breed solution.

Examining eClinicalWorks platform can provide some insight. Specialty EHRs are defined by their alignment with the workflow of a particular type of physician, particularly in the charting feature. Basically, good templates can result in satisfied users. Though eClinicalworks services a broad market, it has a particularly robust customization feature. Branded eCliniSense, this function stores information about past diagnoses, such as labs and diagnostic imaging orders, which can then be used to construct ordersets (in this context synonymous with templates) based on usage data. This feature can make creating customized templates much easier, which can allow providers to speed up their work, rather than struggling to populate the same fields over and over again.

To be clear, eClinicalWorks is not the only software to feature highly customizable templates, but given the diversity of specialists that use it in the Nashville market it’s clear that if specialists don’t go with a best of breed platform, they should seek a platform with customizable modules and templates.

Essentially, they should find a system that lets them create their own best of breed solution.

Another surprising finding was the absence of Epic in Nashville’s office-based physician population, as well as Practice Fusion’s prominence (it has the second-highest market share). These results seem to suggest that price is a large factor in EHR purchases in the Nashville market.

Epic is renowned for its high prices, so much so that it makes for good headlines. Practice Fusion is free, and is increasing its market share on a national level at a faster pace than any other vendor (this is also supported by its strong showing in the Nashville market). Of Practice Fusion users in Nashville, 20 percent were on their second EHR, again indicating that the price of this cloud-based vendor may have been an incentive (especially if they had lost money on their last EHR investment).

Providers are often admonished not to let price rule their EHR buying process, but the Commonwealth Fund’s recent study found that small and single physician practices lag behind other EHR populations in terms of adoption. What’s slowing them up? Price.

Despite Meaningful Use incentive money, EHRs are still not cheap, and federal subsidies don’t cover the productivity loss or drop in quality scores that sometimes accompany the shift from paper to digital records. EHRs like Practice Fusion and Kareo are offering free models that these small practices can afford. Depending on which source you trust – the National Center for Healthcare Statistics’s 78 percent or SK&A’s 61 percent – the number of providers adopting EHRs has reached a tipping point, and the laggards are balking at the price.


The push towards shifting the patient’s role from a passive recipient of care to an active member of the care-team looks set to gain further legislative backing. Earlier this year, the Health IT Standards Committee, along with The Joint Commission and ONC, laid out recommendations for integrating patient generated health data (PGHD) into Stage 3 Meaningful Use requirements. To see what this might mean to health IT and med tech vendors, I reached out to Zach Watson of TechnologyAdvice, who covers EHR related news, along with business intelligence, and other topics. Zach mentioned that health records banks might be an interesting future direction so I asked him to share his thoughts on PGHD, how trustworthy it might be, and what the future for PGHD and health banks might be. Here’s what he said:

Greater integration of PGHD into clinical practice and research opens the door to innovative treatment standards, specifically for population health management and risk-bearing delivery models, such as accountable care organizations. Broadly, PGHD helps reduce costs by allowing providers to view a patient’s previous procedures and tests, and avoid adverse reactions through access to up to date medication information.

On a more granular level, PGHD could give providers, researchers, and device manufacturers access to real-time biometric data that infers day-to-day changes in patient health and activity. This type of data could be essential in developing care plans and technologies for patients with chronic conditions who need daily treatment to address their symptoms.

PGHD already exists in clinical practice today in the form of patient reported outcomes, but Stage 3 requirements envision a greater expansion and integration of these data, with the patient as the main comptroller.

However, questions remain around data reliability, data standards, exchange architecture, and of course privacy.

When searching for a solution to these issues, providers, legislators, patients and other stakeholders must examine the architecture of existing EHR and health information exchanges (HIE). The most common iteration of an HIE, also referred to as a decentralized or federated model, requires that a physician’s EHR showcase interoperability with every other EHR from every other provider from every previous point of care for each individual patient. The physician’s EHR must query all these previous EHRs to receive the required health information, while verifying patient consent and correcting inaccuracies in real-time.

Such decentralized architecture has led to constant citation of low interoperability rates, and scalability issues in the context of PGHD. Patients now have to contribute data to numerous EHRs, with each possibly using a different portal for access. In this federated system, EHRs must not only perform complex functions required by their end-users, but also interface with disparate systems to form an interconnected information transfer network.

A separate framework for interoperability and patient participation in HIEs was proposed back in 2007. Dubbed “The Independent Health Record Trust Act,” the legislation developed an infrastructure for health record banks (HRBs). Essentially, these are untethered portals that act as repositories for patient information, designated by region. When physicians need a complete view of a patient’s record, their EHR queries the HRB for all the patients records and returns updated records to the HRB after the episode of care is completed.

In the HRB model, patients, and providers for that matter, don’t need to worry about portal redundancy, or about receiving inaccurate or incompatible records. One of the worries about utilizing patient generated health information lies in the human error associated with manually entered data. However, positioning the patient as the final quality assurance mechanism should ensure greater accuracy as the patient ultimately risks the greatest harm from health information mistakes.

Further, if physicians notice inaccuracies in the information, they can immediately make the changes if given permission by the patient, or send the patient a note about the inaccuracies. Patients can then deal with information within the HRB platform, instead of the incorrect information being transmitted back to multiple EHRs.

As an example, Geisinger piloted an ONC-funded project where patients reviewed their medication lists through patient portals and provided feedback on current and expired medications prior to an upcoming office visit. This data was reviewed by Geisinger pharmacists who followed up with the patients. Pharmacists changed the medication info as needed, notified the patient’s provider, and marked the source of the change in the EHR system.

How accurate were the patient’s changes? Pharmacists made the patient recommended changes 80 percent of the time. The providers who participated also reported that the program saved them time.

In terms of compatibility, developing one standard for HRBs will make interoperability cheaper and quicker to realize. Since the HRB would be under direct and complete control of the patient, providers could use the direct protocol to exchange information between platforms. The HRB model also offers system architects the opportunity to settle on a smaller range of standardized forms, such as CCDA.

In relation to privacy, patients can determine the level of data access they want providers to have. While this is far from a perfect solution – it’s feasible that patients may restrict information they find unflattering – it does offer a compromise for including patients, and the data they create, in health information exchanges.

Unfortunately, the aforementioned legislations for HRBs (HR 2991) died on the vine after making its way to the House Committee on Ways and Means in 2007. However, the bill’s failure didn’t signal the death of health record banks – eHealthTrust opened a health record bank in 2010 designed to scale with Arizona’s nascent HIE. Additionally, the Health Record Bank Alliance has outlined many of the ideas posited here in greater detail, along with compelling evidence of financial incentive for the HRB model.

Influential stakeholders need to incorporate PGHD to make their population health management attempts yield positive gains, both financially and clinically. The patient-facing infrastructure already largely exists, with an increasing amount of patients generating relevant data through wearable medical devices.

In lieu of a regional HRB, providers can still leverage PGHD using the following practices:

  • Begin by identifying existing information gaps in your EHR system. What data could you and your patients benefit from integrating into the decision making process?
  • Consider the mediums patients can use to record and transmit data: over 60 percent of patients want to communicate with providers electronically, while a further 30 percent are eager to utilize their smartphones and tablets. This is huge resource that potentially going untapped.
  • Implement structured and semi-structured forms that capture the data you need from patients, and can be easily accessed on a mobile device through your patient portal.
  • Consider personal health record applications such as Microsoft HealthVault. These PHR tools function much like health record banks, and provide many of the same benefits. HealthVault is even free to use.

PGHD has a great deal of potential, but still needs standards built around it. How will your organization utilize PGHD? Share your insights in the comments.

{ 1 comment }

There’s no difference between mHealth & telemedicine, come to ATA May 17-20 in Baltimore to learn more

I’ll be heading to the American Telemedicine Association (ATA) annual conference in Baltimore in a couple of weeks. To see what I might learn there I interviewed Jon Linkous, CEO of ATA. The first question I asked him was “what’s the difference between mHealth and telemedicine?” Basically nothing, he said — but, he noted that […]

2 comments Read the full article →

Consolidation and other insights from the 2014 Meaningful Use EHR Market Share Report

EHR review site Software Advice recently published their 2014 Meaningful Use EHR Market Share Report (a SlideShare version is also available). They reported that in contrast to the buzz about this impending market consolidation, they found a trend toward fragmentation; in fact, the number of vendors in the health space with MU attestations actually grew 25% in the […]

3 comments Read the full article →

More practical, relevant, and actionable health IT advice to be doled out at HealthIMPACT East in NYC on Wednesday

Our vision of providing a packed one day event focused on practical, relevant, and actionable health IT advice was very well received in Houston earlier this month. We wanted to focus not on canned PowerPoint decks and promotion of tech hype but specific advice on how and where to apply IT in healthcare settings. Based […]

0 comments Read the full article →

Guest Article: Secure message exchange using the Direct Protocol is not a myth, there really are people using it

I recently chaired a couple of conferences and my next HealthIMPACT event is coming up later this month in NYC. At each one of the events and many times a year via twitter and e-mail I am asked whether the Direct Project is successful, worth implementing in health IT projects, and if there are many […]

4 comments Read the full article →

Anecdote-driven systems engineering and complaint-based interoperability design will not solve health IT woes

As I’ve been preparing to chair the HealthIMPACT conference in Houston next Thursday I’ve been having some terrific conversations with big companies like Cisco, some of our publishing partners, and smaller vendors entering the health IT space for the first time. One great question I was asked during a discussing yesterday by a tech publisher […]

5 comments Read the full article →

What does it take to get beyond hype in health IT and focus on valuable, actionable, practical, relevant content?

My friend John Lynn was kind enough to cover the new HealthIMPACT Conference that I’m chairing in Houston on April 3 in his recent piece entitled “Getting Beyond the Health IT Cheerleaders, BS, and Hype Machine“. While the article was great, Beth Friedman’s comment was priceless: What are the criteria to be considered part of […]

0 comments Read the full article →