Below is an overview of the templates (excludes supporting templates) and how they are used.

Header
Defines the type of document being created, who the document is regarding (patient, physician, author) and how the document relates to other existing documents (if applicable).

Purpose
States the reason the document was generated, but only if a specific purpose is known (i.e., a referral, transfer, or by request of the patient).

Problems
Provides a list of relevant clinical problems, both current and historical, that are present for the patient at the time the document was created.

Procedures
Provides a list of all relevant and notable procedures or treatments, both current and historical, for the patient.

Family history
Gives relevant family health information that may have an impact on the patient’s healthcare risk profile.

Social history
Describes the patient’s lifestyle, occupation, and environmental health risks plus patient demographics such as marital status, ethnicity and religion.

Payers
Provides payment and insurance data pertinent to billing and collection, plus any authorization information that might be required.

Advance directives
Includes information about wills, healthcare proxies and resuscitation wishes, including both patient instructions and references to external documents.

Alerts
Provides a list of allergies and adverse reactions that are relevant for current medical treatment.

Medications
Provides a list of current medications and relevant historical medication usage.

Immunizations
Gives information the patient’s current immunization status plus pertinent historical information about past immunizations.

Medical equipment
Provides a list of medical equipment and any implanted or external devices relevant to patient treatment.

Vital signs
Details information about vital signs for the time period including at a minimum the most recent vital signs, trends over time, and a baseline.

Functional stats
Details information about what is normal for the patient, deviations from the norm (both positive and negative) and extensive examples.

Results
Lists lab and procedure results, and at a minimum lists abnormal results or trends for the time period.

Encounters
Details relevant past healthcare encounters including the activity and location.

Plan of care
Lists active, incomplete or pending activities for the patient that are relevant for ongoing care - including orders, appointments, procedures, referrals and services.

For additional information on getting started with CCD, please read the post on the quick start guide provided by EHRVA.

ADT stand for “admissions, discharges, and transfers”. It basically means demographics; anytime you think of ADTs, think demographics: the patient’s name, the patient’s location in the hospital, his or her address, phone number, gender, etc.

There are many different types of ADT message types, such as:

• Registering a patient
• Discharging a patient
• Merging patient files to avoid duplication

An ADT feed is one way an application or a provider can get all that information from a clinic or hospital information system (HIS). With the constant updating of a client, customer or patient’s data, ADTs comprise the most HL7 messaging traffic. Change of address, addition of a middle name, and addition of next of kin are all examples of the type of data updates that make up ADT messages. Upon updating, this clinical data will then flow out to different places such as outpatient clinics or laboratories, dependent on who needs that information in their database.

Typically, a hospital registration database will have the master of the patient data and information. Each time patient information is updated, the updates will be pushed out in the form of an ADT message to the appropriate applications in facilities such as labs or clinics.

ADT feeds are usually received through either an interface engine or direct (point-to-point) interface.

In the case of an interface engine, clinical data can be provided to a variety of places. An export can be set up so there can be a one-on-one connection where, for example, a hospital registration system can establish a connection to a lab outside of the hospital. “Data dumps” are also possible, where one end of the application has all the files and the other doesn’t and through the connection, the patient data can all be transferred.

In summary, ADT feeds are the most common and high volume feed used. The updating of patient information eclipses the volume of order and result feeds. Having up-to-date patient information, though, is a critical component in streamlining and improving the continuity of patient care.

The Center for Business Innovation hosts the conference, and they describe Healthcare Unbound in the following manner:

Innovative technologies are driving opportunities to serve consumers in new ways and in new settings. Forrester Research coined the term “Healthcare Unbound” to encompass the trends toward technology-aided self-care, mobile care and home care. More specifically, Forrester describes “Healthcare Unbound” as “technology in, on and around the body that frees care from formal institutions.”

As healthcare IT evolves and changes, it is interesting to read the thoughts and activities happening at the consumer level.

The motivation behind Peter’s article is that, like many areas of the US, Wisconsin has been talking about building a RHIO (or two) for a long time. The current challenge is architecting the system and ultimately paying for it. The state has issued an RFP asking for help designing the architecture. Costs for the total deployment are estimated at $1.2B and are, presumably, to be funded by the providers.

Peter makes some great points about:

1. The fact that we’ve been at this “regional interoperability game” for a long time.
2. RHIOs are the latest name for an old idea
3. Peer-to-peer communication (rather than centralized “control”) has a better chance of success
4. Good discussion of political v. economic v. quality of care motivations for interoperability
5. Providers must be using electronic records before they can be exchanged, well, electronically
6. On-going work to firm up standards will help with interoperability

Two counter points I would make to Peter’s thoughts:

1. I do not think that the banking analogy Peter uses is a good one. The banking world has (effectively) centralized control over the SWIFT and related networks. A better analogy would be peer-to-peer file sharing networks — heck, if we can share MP3s in an ad-hoc-yet-organized-way, surely we can share healthcare records.
2. IMO, the CCHIT is not the total driver for peer-to-peer interoperability. HL7 (among others) has been working on this problem for a long time and, again IMO, CCHIT is effectively profiling existing standards rather than creating new standards.

Selected quotations from Peter’s article:

[In November 2005 Wisconsin’s Governor] called for “a statewide eHealth infrastructure […]. [P]resident Bush’s State of the Union Address [in January 2004] stated that “By computerizing health records, we can avoid dangerous medical mistakes, reduce costs, and improve care.”
…
The statements were both politically appropriate at the time, but as of June, 2008, little has been achieved in Wisconsin.

We have been at this for a long time. The CHINs (community health information networks) of the mid-1990s were an idea that had merit but was not adequately supported by the technology of the day. The RHIOs (regional health information organizations) of later times were also a great attempt at interoperability but suffered from lack of community acceptance and viable business plans to sustain them. It is telling that only a handful of RHIOs continue in business from the several hundred that were founded on initial seed money only to fail when those funds became exhausted. The poor support from the healthcare providers and the payer community, and the absence of inspirational insight into the opportunity being presented to us by the technology, contributed to the lack of success of what I will call the second generation of this approach at interoperability.

Presumably, the healthcare provider and payer will bear the cost of this process. […] Importantly, to be viable, the plan further assumes that all healthcare providers in the State of Wisconsin will maintain patient records electronically. This is not the current or the foreseeable situation, as many small hospitals and physician practices do not have the available funding to achieve this goal with only their own resources.
…
Application (systems) vendors in healthcare are working together under the auspices of the Certification Commission for Healthcare Information Technology (CCHIT) to develop standards for interoperability. By working together it is planned that their output will become accepted as was the HL7 interface standard. A peer-to-peer network with communications between healthcare providers using software from the same or different software vendors and based on the CCHIT standards could follow a model based on the Banking system model.
…
This peer-to-peer network lends itself to progressive growth and expansion, as warranted as additional providers implement electronic medical records systems. Importantly, a sustainable business plan at the operations level is not needed to finance the exchange of key clinical information in a time of need.

This article consolidates some of the recent negative articles or perspectives on EMRs, including:

• Privacy - exposing patient data to outsiders.
• Savings - insurers gain more than physicians
• Copy-and-paste - copying notes from one patient record to another, because it helps with billing
• Too much information - no human selection of relevant information
• Physician insensitivity - “Dr. Computer”
• “Cookie-cutter” medicine - just using the template

These points may be valid, but is the status quo better? Continuing with a paper-based system does not seem to be the better answer. Having the right sense of responsibility to deliver the right approach in using EMRs seems to address many of the potential issues.

Although some EMR costs are covered (e.g., software purchase, order and results integration), there are other costs that will be required. For example:

• Hardware costs
• Technical support costs
• Ongoing application support costs
• Hosting costs (if SaaS or ASP model is used)

The article points out the obvious point:  With Stark and other “free” options, the overall costs of an implemented EMR are still lower than if the physician practice implemented it on their own. Implementing the EMR application still creates benefits such as potentially higher pay-for-performance payments, possible payer subsidies and, of course, more accuracy in patient care. “Free” may not be completely free, but it is a reasonable starting point.

A few past posts and insights that you may want to explore:

• What is the CCD?
• EMR Interfacing Best Practices
• Get the Workflow Right First
• Comparing HL7 Messages to HL7 Documents

Please post any experiences that you have in implementing the CCD or using this Quick Start Guide.

Specifically, a hospital system can pay for the creation of an electronic interface between unique electronic health record (EHR) systems of individual physician practices and the hospital network’s EHR system. The interface would allow physicians, from their practices, to order and communicate the results of tests and procedures performed.

The CMS news was delivered in “Advisory Opinion No. CMS-AO-2008-01″. There are many words used in the advisory; here is a quote that is the meat of the opinion:

The Requestor … owns and operates … hospitals … [and] contracted with a third-party … Vendor … to install a proprietary health care software information …System …, customized to the Requestor’s specific requirements, including a software interface engine that facilitates access by the custom Physician Practice Interface(s).

Pursuant to the contract between the Requestor and the Vendor, the Vendor provided software licenses to the Requestor that permit the Requestor and its controlled affiliates to use the System.

Currently, the medical staffs of Requestor’s … hospitals have the option to view laboratory reports for the Requestor’s patients over a protected internet connection to the System. The Proposed Arrangement would permit also the ordering or communicating of laboratory tests or procedures performed by the Requestor using the Physician Practice Interface(s).

Numerous physicians on the Requestor’s medical staffs have begun to purchase and use electronic health records (“EHR”) systems for their private practices. Requestor would like to integrate its System with individual information systems maintained by the Affiliated Physician Practices to promote the secure transfer of patient data between the parties. Integrating the System with each Affiliated Physician Practice requires the custom development of an interface that can extract data from the System and transfer it to the Affiliated Physician Practices’ EHR systems. The Requestor may need to develop several versions of the Physician Practice Interface to accommodate the various EHR systems. The Requestor would limit the functionality of the Physician Practice Interface to the ordering or communicating the results of laboratory tests or procedures furnished by the Requestor.

Under the Proposed Arrangement, the Vendor would develop, and the Requestor would pay the development cost of, a Physician Practice Interface customized to the Affiliated Physician Practice’s existing EHR software. … Physician Practice Interface would be used only to order or communicate the results of tests and procedures furnished by the Requestor and could not be used for any purpose other than the ordering or communicating of the results of tests or procedures furnished by the Requestor.

…

Therefore, we have determined that the Proposed Arrangement does not meet the definition of “compensation arrangement” for purposes of the statute’s prohibition on physician self-referral
…

The National Alliance for Health Information Technology (NAHIT) recently released new definitions of certain healthcare IT terms. This project was completed for the Office of the National Coordinator of Health Information Technology; this office was created by the President on April 27, 2004 to promote the adoption of electronic health records by most Americans by 2014.

Outlined below are the definitions published by NAHIT. These healthcare IT definitions were published in the report entitled Defining Key Health Information Technology Terms (PDF).

• Electronic Medical Record: An electronic record of health-related information on an individual that can be created, gathered, managed, and consulted by authorized clinicians and staff within one healthcare organization.
• Electronic Health Record: An electronic record of health-related information on an individual that conforms to nationally recognized interoperability standards and that can be created, managed, and consulted by authorized clinicians and staff across more than one healthcare organization.
• Personal Health Record: An electronic record of health-related information on an individual that conforms to nationally recognized interoperability standards and that can be drawn from multiple sources while being managed, shared, and controlled by the individual.
• Health Information Exchange: The electronic movement of health-related information among organizations according to nationally recognized standards.
• Health Information Organization: An organization that oversees and governs the exchange of health-related information among organizations according to nationally recognized standards.
• Regional Health Information Organization: A health information organization that brings together health care stakeholders within a defined geographic area and governs health information exchange among them for the purpose of improving health and care in that community.

The greatest understatement in the report is: “Interoperability is the common thread running through health IT terms. Interoperability is the essential factor in building the infrastructure to create, transmit, store and manage health-related information.”

For more definitions, check out our healthcare interoperability glossary.

Creating a competitive advantage for your radiology practice is critical in today’s market. Healthcare IT is a critical strategic element that can automate, streamline, enable, etc. radiology workflow. Having the CIO present at the business level can only help your radiology practice meet the growth and operational goals.

Many of the radiology practices we work with have a CIO who has a strong involvement in the operational discussions, and they have produced impressive results. The results can include improved turn around times (TAT), improved billing cycle times, or other elements of the radiology workflow.

The Radinformaticsarticle highlights some important insights about radiology CIOs, including the valuable role they can play and the skills they can bring to the management table.

It seems as though implementation of the larger standard is still seen as a herculean task, requiring not just a rework of HL7 2.X import/export modules but also a potential overhaul of applications’ underlying database schema and object model. But the Structured Documents committee (SDTC) has done a nice job of achieving one of its primary design principles concerning HL7 CDA – minimizing technical barriers to implementation. That mantra has no doubt helped the SDTC create a standard that comprises the ‘piece’ of HL7 V3 that American vendors are willing to incorporate in the not-so-distant future.

Given the lack of a national mandate to move to HL7 Standard V3 that exists in other countries, as well as the lack of demand for V3 in the US marketplace, CDA could be the much needed beachhead for the standard in this country.  As more and more vendors implement CDA and get a small taste of the V3 methodology and associated benefits, the more adventurous (and deep-pocketed) software providers will tip-toe further into the newer HL7 standard.

Until then, the burning question remains:  which comes first – provider demand for or vendor support of V3?

NeoTool will be hosting our Tuesday Night Party (TNP) at Gallagher’s, a sports themed bar. If you are at the WGM or in the area, please stop by Tuesday. More details over at our TNP page.

The WGM details page is really hard (ok, impossible) to find on the HL7.org web site so I thought I would put as link here on the NeoTool blog.

A few interesting points in the article:

• Different approaches are being taken by hospitals. In the article, one hospital is offering just a single EMR offering to their physicians, and another hospital is offering 3 to 4 EMR application options. The primary reason for the multiple EMR offerings is that “We realized that one size doesn’t fit all.”
•  Integration is essential. The reason for the one hospital to offer single (hosted) EMR offering to their physicians is so that the patient has one medical record in their system. In the other hospital’s case, clinical integration is still essential. As they stated, “You have to have clinical integration between multiple entities. If you are not sharing data, you are losing the real benefit of EMR.”
• EMR certification also plays a role in the selection process by the hospital. In one case, only CCHIT certified EMR vendors are considered.
• The amount of the hospital subsidy varies. One hospital is covering 60% of the EMR services while the other seems to be taking advantage of the full allowable amount of 85% of the covered services.
• Trust is a factor with physicians. If a physician practice is going to take advantage of a hospital supported EMR, they will need to trust that hospital.

Forward progress? Time will tell which approach will work the best, or it may be that the approaches do vary… select the approach that best fit the needs of the connected healthcare objectives being pursued. As long as everyone involved trusts the objectives, it may work.

“While hospitals with basic implementation are utilizing about 0.1 IT staff per bed, this rises to around 0.2 IT staff per bed as hospitals advance from Stage 1 to Stage 4 implementation based on the HIMSS EMR Adoption Model. If our data represent a correct sampling of the entire US, then the current IT staff workforce is about 108,390 FTE. However, if the US HIT agenda is fulfilled and hospitals move to higher levels of adoption, an additional 40,784 FTE will be required.”

Characterizing the Health Information Technology Workforce: Analysis from the HIMSS Analytics Database, April 2008.

In the EMR adoption model as defined by HIMSS, the various stages are succinctly defined. Stage 1 includes basic systems in place - radiology, laboratory, pharmacy - while moving to Stage 4 includes implementation of a Computerized Practitioner/Physician Order Entry (CPOE) system.

The key point of the paper and discussion: Adopting new technologies in hospitals require additional IT personnel to support and ensure success. In selecting new technologies, it is important for hospitals to evaluate the type of IT skills required to support the required new applications. Balancing the type of skills required with the associated costs is essential.

Rather than making a big deal out of the messages and insisting that we get them prior to interface construction, I dove right in to perform a gap analysis based on the specifications that we were furnished in order to determine the incompatibilities between the systems involved. After carefully identifying the mappings required to transform the HL7 messaging such that it would satisfy each system’s specs, the interfaces were configured.

It was time to test, and out came the disappointingly small (in some cases just 1 or 2 messages per application) sampling of test messages that had slowly trickled in but had been shelved until the ‘real’ work of building the interfaces could be completed. Those messages were loaded, the interfaces were turned on, and voila!

Errors.

The sample data didn’t align with the specs, rendering my beautiful side-by-side comparison spreadsheets useless. The mapping tables I developed from those specs to translate representations of common fields such as gender, race, and relation? Worthless as well.

How could I have so quickly forgotten that the proof is almost always in the sample message pudding?

Specification documents are often hailed as the keys to unlocking the secrets of the import/export modules of healthcare applications and successfully brokering communication between disparate systems. Good specs do just that. The only problem is that you stand a better chance of finding a few needles in a hay mountain. They’re out there; they’re just not very plentiful.

The shortcomings of specs are attributable to a variety of factors:

• They’re rarely updated at the pace of development. While correct at a particular moment in time, changes are often times made to the interface that either never make it into the document or do so after those changes have been introduced to the marketplace.
• They’re often out of sync with upgraded software versions. Even if a vendor takes extreme care in updating both the interface and the specifications simultaneously, healthcare facilities may have upgraded their software since receiving their specification document and therefore unknowingly hand an outdated version to trading partners/interface analysts.
• Variances in installed modules/features are difficult to document. Many applications offer a wide array of software modules and features that can be alternatively installed depending on the customer’s budgets or workflow that make the production of a “one size fits all” specification difficult.

But the messages don’t lie. Having them takes the guesswork out of determining exactly what is coming out of or readily received by a healthcare application. Today’s most sophisticated interface engines will even go so far as to take those messages and build an HL7 derivative to which they’ll conform at the click of a button! There’s not much left to the imagination, and thus interfaces can be built with a much greater level of confidence.

So if you’re a vendor, be sure to stamp out a good sampling (at least 50) of anonymous messages for each message type supported through your application interfaces each time a change to the interface is introduced. Doing so will not only be appreciated by interface analysts trying to connect your systems to others in a hospital, clinic, imaging center, etc. It will also ease your own interfacing burden by reducing the number of calls and questions you field related to interfacing.

And if you’re an interface analyst, stranded on a deserted integration island and given the choice between sample messages and specifications to ensure your survival, always opt for the messages. They represent much more than a means to validate interfaces - they can be vital to successfully building them. Just make sure you don’t settle for 1 or 2 like I did.

The hospital worked with Georgia Tech’s Enterprise Innovation Institute and focused on improving the Emergency Department (ED) workflow.

In healthcare IT, it is great to read about how workflow projects are undertaken in a straightforward way and achieve significant results in a short time period. As the article states:

“The lean team at Meadow’s developed 44 action items for reducing lead time to admit, treat and discharge a non-critical ED patient, 18 of which were determined to be low cost and high impact.”

The results, according to the Georgia Tech press release:

“… a 44 percent reduction in average length of stay per patient, a 10 percent boost in patients served and a 92 percent patient satisfaction rate.”

Great work!

In my opinion, the important point is keep it simple. For your radiology workflow:

1. Document your current workflow
2. Document what you would like your workflow to look like
3. Identify the gaps
4. Adjust the workflow to close the gaps
5. Enable the flow

A little more detail on each:

Document your current workflow. Talk to the people involved in the key steps - from schedulers, physicians, radiologists, technologists, billing professionals, etc. Get the current workflow first-hand, from the people doing the work.

Document what you would like your workflow to look like. As you talk to people, ask for ideas on how to improve. Meet with key leaders in your organization to determine objectives. Most importantly, talk to the physicians who receive the results that you deliver. Get the customer feedback!

Identify the gaps. What are the key differences between the way you do it today and the way you would like it done? Again, more importantly, what is the way your customers want it done - both patients and physicians?

Adjust the workflow to close the gaps. Not all of the gaps can be closed simply. Identify the high impact - low implementation effort items and do those first. For the others, develop a plan of how to close the gaps and continue to implement to the defined goals. Communicate your results along the way!

Enable the flow. Some activities in the workflow will require no technology. Others will require technology investments. Look for ways to automate the radiology workflow, simplify the steps, and deliver value to the people doing the work throughout the process. Look for ways to leverage technology for the improvements that enhance patient quality, enhance radiologist productivity, and deliver real service to the referring physician community.

There are many ways to improve your workflow, but the best way is to get started… with the basics.

In so doing IHE has developed a plethora of integration profiles across a dozen or so clinical and operational domains, from Cardiology and Radiology to Patient Care Devices and IT Infrastructure.  These profiles take a lot of the interpretation and guesswork out of the implementation of the underlying standards and thus make the messages transmitted between clinical information systems much more consistent and predictable, at least amongst supporting systems.

Sounds great – so what’s the problem?

In the most recent North America Connectathon only 70 organizations tested just 130 systems for IHE profile compliance. Don’t get me wrong – that’s a really nice turnout that marks continued growth in support for the initiative. But when compared to the thousands and thousands of clinical information systems impacting patient care delivery in this country today, that total represents a disappointingly low percentage.

Why don’t more vendors participate? Quite simply, because doing so is difficult, and there’s been no surge in customer demands for IHE compliance in the marketplace to date to prompt most vendors to tackle that difficulty.

To be clear, the difficulty associated with participation isn’t attributable to any overly complex technical challenges to which vendors are subjected. On the contrary, the profiles, though imposing at first glance due to their length and exhaustive nature, spell implementation details out quite clearly. Nor is the difficulty attributable to the committee meetings, conference calls, and face-to-face meetings required to stay engaged with the ongoing developments of a particular domain, although that investment in time and energy certainly isn’t trivial.

Rather, the difficulty in participating stems from a fundamental flaw in the way vendors have historically addressed interface challenges. That flaw continues to plague their ongoing integration efforts today.

For most vendors, the world class system cart came long before the integration horse. When interfacing requests first began to surface, code was hastily added to the existing application code base in an effort to provide a solution as quickly as possible.

As connectivity demands have grown at an ever-increasing clip, that interfacing code not only grows with them but also undergoes innumerable changes to accommodate the customization required by so many interface partners. And each time a change is introduced the entire code base is recompiled and regression tested to ensure that customization did not have a deleterious effect on the core application.

As a result, growing software companies see deployment cycle times balloon and valuable development resources diverted from core technology to high tech plumbing.

Sounds a lot like initiatives to adopt IHE profiles and participate in Connectathon events, doesn’t it? Profile changed? Code, recompile, test. New profile? Code, recompile, test. Vendor X needs the message you’re communicating tweaked? Code, recompile, test.

The path to IHE compliance need not be so difficult!

Thankfully, healthcare middleware can go a long way toward remedying the difficulty felt by the vast majority of healthcare vendors today. Amongst many other things, middleware technology can:

1. Eliminate the need to alter existing import/export modules.Middleware can receive the existing feeds an application supports and transform those messages into an IHE compliant data stream.
2. Move interfacing logic outside the core application. In so doing supporting changes becomes a matter of reconfiguring, typically in a graphical user interface, rather than recoding.
3. Provide greater interfacing flexibility. Supporting IHE profiles is a great idea, but as mentioned above the number of non-IHE compliant systems far exceeds that of compliant systems.
4. Support IHE profile variability.Despite best intentions, much of the code written to conform to IHE tests ends up being thrown away, introducing variability outside of Connectathon events.
5. Free up development resources.Configuration of interfaces utilizing middleware requires analyst level skills, allowing development talent to refocus on the core application.

Don’t believe me? Just ask the vendors who have used healthcare middleware with their products in an IHE Connectathon. They’re the ones taking coffee and snack breaks…

As the title implies, the article is about how EPIC Imaging implemented an electronic means to connect with various referring physician practices and send patient reports quickly, efficiently, and accurately. John Griffith is the CIO at EPIC Imaging, and he and his team have taken the initiative to solve the radiology workflow and operational challenge.

A few highlights from the article:

• Addressing Physician Requirements:  “The physicians wanted the reports to show up automatically in each patient’s electronic medical record (EMR). They wanted to open the patient’s EMR and have the report right there waiting for them, with no staff time spent clicking links or handling paper.”
• Maintaining High Service Levels:  “We have been held as the gold standard for providing service… but Epic administrators knew that if they were to retain that gold-standard mark in the face of increasing competition, they would have to answer the demand for electronic report delivery.”
• Delivering to the Physician - Choices:  “We could not have used a Web-based system because the physician would still have had to log in, look up the patient, and move the report into the chart… The demand was to get that report seamlessly into the chart with very little human interaction.”
• Leveraging Healthcare Interfaces:  “We had an existing interface that was sending results from our RIS to our PACS. We redirected that results feed to the NeoTool engine, and then NeoTool forwarded the report from there onto the PACS… Then, Epic constructed a rules base to tell NeoTool how to route the report to the referring physician’s EMR and directly into the patient’s electronic folder.”
• Achieving Positive Impact: 
  • “Clients, once interfaces are complete, will find report delivery much more convenient. That means that Epic will probably retain their business, or get more of it.”
  • “Quicker, more direct reports mean that patient care can be expedited. From the standpoint of eliminating human intervention and becoming more solidly electronic, we improve patient care.”

Since the above bullets are just clips from the article, take a few minutes and read the article. It provides great insights into how EPIC Imaging (case study PDF) understood their physician requirements and addressed them in a creative and operationally-sound way while also - and importantly - improving the way patient care is delivered. 

Congratulations to John and his team!

René Spronk wrote an interesting reply that I did not want to get lost:

From the blog it isn’t clear whether you’d like HL7 to address the formatting of documents or not. The fact that the FT datatype is rarely implemented seems to suggest that there is no underlying requirement. Otherwise, implementers would use it and request enhancement of those features (maybe even to make them mandatory) as part of the development standard of the v2.x standard.

The CDA standard (HL7 v3) contains markup with a functionality akin to FT. It focuses on medical content, not on font-size. CDA is usually displayed using a style-sheet - albeit one that the receiver chooses, which may be a different one than was used by the document creator.

In case of CDA HL7 leaves it up to the communicating parties to “contractually” agree to use a specific style-sheet. Whether or not such agreements are in place depends on the jurisdiction where CDA is used.

Are there uses cases and jurisdictions where it makes sense to give more control to the sender of how the receiver should view the data? Yes.

One of the enhancement requests for the next release of CDA (CDA R3) is to support a much larger set of XHTML tags for formatting. This is however a balancing act - I wouldn’t want to support all of XHTML (including scripting stuff) in a CDA. The more formatting we introduce in a CDA, the more we’ll be moving away from the actual content, and the more things will be focused on formatting. I’m not sure if we should go there…

As always, René made some great points; thanks for your comments. I think that users of HL7 (either 2.X or 3.0 family) wish for many things — mostly they wish that the standard will make their lives easier. Often they look to HL7 to “force” an application to do something that “seems obvious” to them and their world. In terms of document formats from the perspective of a sending application, they wish that their “pretty report” would be displayed correctly by the receiver.

Once a week I hear someone wish they could force that mainframe or mumps application (which was coded in the early 1980s) to take an HTML or PDF document.

“Why can’t it display bold text? Our paragraphs are not wrapping correctly! The reason people use our service is that we produce these great reports. It is one of our key selling features! We just hate to fax or email them. Can’t HL7 deliver the same thing? Can’t I force that receiving HIS/CDR/EMR at my customer site to take this document via an interface? What does HL7 say about that? Can’t HL7 make the receiver display this correctly? I wish this was easier!”

To answer the questions above, read my posting. In short, HL7 does not force a receiver to format a document in a particular manner.

As noted in René’s comment, HL7’s CDA standard is mostly focused on the content and coding of the information — the display or rendering was, IMO, a secondary aspect. In fact, one of the key points of CDA is that the same document can be rendered on many devices — cell phone, printer, HTML, thick client, thin client, PDF, etc. As noted by René, the receiver’s style-sheet controls the final display.

IMO, the major display advantage of CDA is that it provides a much more structured starting point. In theory, we no longer have to worry about boring stuff like word wrapping or section headers — these display features “come for free” with the style-sheet used by the receiver.

Hopefully as a community we will not lose track of the fact that what CDA is really about is coded documents — the “easier display” is just a bonus.

It is interesting, however, to note that often what real world users of either HL7 2.X or CDA want is a mechanism to get a document “nicely displayed” on the receiving system. Sure, the informatics geeks can talk about the coding/format of the document and how many places we have clever OIDS, but ultimately it seems that much of healthcare is still about paper documents. Kudos to the CDA visionaries who seemed to get this up front — allow for lots of coding but also allow for simple blobs of text split into sections.

Typically this question comes up when someone is trying to ensure that text documents they send (such as a radiology report) will be displayed a specific way on a remote application. Asked another way, the sending HL7 user want to know if the receiving (remote) application will display the report in a given size font or a fixed-width font. The question revolves around the desire to put “low tech text formatting” in place to build things like tables, indented paragraphs, or even nicely word-wrapped paragraphs.

The reality is that HL7 messaging does not imply or demand that an application display a text report in any specific manner. If there is a need to ensure that the receiving application displays data in a specific way, the interface analyst must review the display mechanisms in the receiving application to see what is possible. The analyst must then change the message (text) format to work within those provided by the receiver’s display mechanisms. Typically the sender can not force the receiver to take a “pretty text document.”

The problems most frequently encountered when moving text reports are related to the size of the text, how long the lines can be, indenting text, the desire to make headers “stand out”, and how word wrapping is accomplished. All of these items are under the control the receiving application. In the real world, HL7 has no opinion on these issues.

Often applications support moving rich text documents via either an ED or RP data type. This means that the sender can deliver a PDF, Word document, RTF document, HTML document, etc — but only if the receiver supports the format. More details on rich documents are provided in this blog posting.

 The FDA report summary states:

SUMMARY: The Food and Drug Administration (FDA) is proposing to
reclassify, on its own initiative, the Medical Device Data System
(MDDS) from class III (premarket approval) to class I (general
controls). This action does not include medical device data systems
with new diagnostic or alarm functions. FDA is also proposing that the
MDDS be exempt from the premarket notification requirements when it is
indicated for use only by a healthcare professional and does not
perform irreversible data compression.

The entire report can be found as document ID fr08fe08P, Devices: General Hospital and Personal Use Devices.

Just as there are factions the political candidates are trying to pull together to win, they probably have not seen as many factions as there are in healthcare standards. There is a major faction called the HL7 Standards, but emerging factions are getting noticed which are XML related - from Continuity of Care Record (CCR) to a faction-within-a faction, that is, HL7 V2, HL7 V3, HL7 Clinical Document Architecture (CDA), and HL7 Continuity of Care Document (CCD).

We don’t need new healthcare standards. We just need to enforce the ones we have.

What about the X12, DICOM, NCPDP, ASTM, LOINC, and SNOMED factions? And, let us not forget the common person’s healthcare standard - plain ol’ CSV file formats.

If the United States was going to eventually elect a healthcare standard to lead us in the 21st century, which one would win? All we need is a little harmony.

Harmony may be over-rated. How could someone from SNOMED endorse the LOINC? What do you mean CCR is campaigning with CCD? If these events happened, some people may just sit out the healthcare standards election.

What about the special interests? Each healthcare vendor has their own standard. Let’s hope that someone doesn’t “swift boat” one of the healthcare standard candidates.

The campaign slogans:  Healthcare standards are broken. We just don’t need to move the same standards to different chairs. We need to stand for change. We need hope! We need a healthcare standard ready to solve all of our problems Day 1!

Or, maybe what we need is another healthcare standard - a “third party” candidate - that can just end all of the “politics” and work for the people in health care. A “uniter” of healthcare standards. Some standard that can “reach across the aisle” and reach consensus.

Can’t we all just get along in the healthcare integration world?

Yes, this is a parody of sorts on healthcare standards, but it is the practical world that we live in. There are many standards, and we do all need to get along in order to deliver the best possible care for patients. Each healthcare standard faction delivers an essential piece in the healthcare puzzle, but putting the puzzle together can be challenging at times.

Maybe the final rallying cry should be:  “Read my lips. No new healthcare standards!”

A recent article in Government Health IT entitled Picking Up the Check for EMRs does a good job of outlining the differing perspectives:  hospital, physician practice, and vendor. Outlined below is a brief summary of each perspective.

Hospital Perspective.  Although some hospitals may implement strategies and programs to offer EMRs to physician practices, there is skepticism that it will work. Hospitals like Partners Healthcare System do not have plans to start paying for local systems. Other hospitals note that they would have to offer physician practices more than one EMR option in order to meet the differing requirements. The bottom line, though, is that many hospitals are not in the financial position to fund EMR adoption in physician practices.

Physician Practice Perspective.  Doctors are independent and do not want to take hospital incentives which may compromise their independence. Also, what if a physician practices at more than one hospital and each hospital has a different supported EMR application? There is also some concern about patient data security.

EMR Vendor Perspective.  Essentially, the vendors like the possibility of additional funding to support EMR adoption. However, there are concerns this would benefit the larger EMR vendors more than the mid-to-small sized ones.

A recent HIS Review blog post also provides a good overview of recent updates to the Stark Law and what hospitals need to be considering.

The most detailed outline of what a hospital will need to do around the Stark Law changes comes from a hospital CIO blog post. In Life as a Healthcare CIO, John Halamka describes the top ten planning items for hospitals to consider as they implement a strategy and program that leverages the Stark Law changes.

Obviously, how this all plays out is still up for debate. There are many elements to consider, not the least of these being how to integrate the patient data flow together between the different EMR applications, physician practices, and hospitals. In many respects, the debate is happening at the right level – the local level.

If healthcare IT is to be adopted by physician practices, the issues and plans will need to be resolved between the players in the communities.

Or, as is being done in some instances, the connections are being made between the different healthcare providers and their applications by leveraging interface engine technology.

The driving forces in these electronic transaction interactions are streamlined workflow, increased referrals, and faster turn around times to support quality patient care. There are several case studies that highlight specific providers connecting to various EMRs successfully and exchanging patient information. Business or operational drivers, not the Stark Law, are moving “connected healthcare” forward in these examples.

One question that arises is:  what is the difference between HL7 messages and HL7 documents? Outlined below is quick review of differences.

HL7 Messages:  HL7 messaging is usually a real-time flow of patient and clinical information. They convey current information about a patient, including updates to admissions or discharges (ADT), orders for tests (ORM), and test results (ORU). The more current the data, the more relevant it is in the delivery of patient care. HL7 messaging impacts the ongoing process of delivering care by delivering the most current, updated patient information available.

HL7 Documents:  HL7 documents are static - accurate given the point-in-time in which the information was captured. HL7 documents contain important information, but it is a snapshot. The documents are useful in providing relevant information in referrals to other physicians or healthcare organizations. Accordingly, it provides a starting point for the next step in patient care.

The differences in HL7 messages and HL7 documents can be summarized as active vs. passive information. HL7 messages are continuously delivered as status changes or new information is obtained. HL7 documents contain information at one specific point in time. Both are critical, however, especially when delivering connectivity or integration to Electronic Medical Record (EMR) applications in various healthcare provider offices.

How do the healthcare standards apply? In HL7 messaging, HL7 V2.X and HL7 V3 apply. In HL7 documents, HL7 Clinical Document Architecture (CDA) and ASTM Continuity of Care Record (CCR) standards apply. Both approaches deliver value to healthcare integration initiatives.

Most users of HL7 2.X don’t pay attention to the newer releases of HL7 (both HL7 2.X and 3.X) because these current users are building interfaces between existing applications. These applications typically have “more-or-less 2.3″ interfaces and, broadly, those interfaces are “good enough” for most users. There is a comparatively small group that helps create new releases of HL7 or that has an opportunity to improve a vendor’s interface by upgrading to a new release of the HL7 Standard.

It is always interesting to see how the HL7 community continues to push HL7 2.X forward. It is fair to say that HL7 2.6 and, soon, HL7 2.7 are better standards than prior releases. They both have more functionality, better descriptions, and fewer errors.

In a free market, buyers choose (directly or indirectly) the version of HL7 they ask their vendor to create. With time, I hope that many vendors will move to the more-complete standards. In the United States, we must rely on market (buyer’s) pressure to ask purveyors of software to improve the functionality of their interfaces.

This blog post was entered in NEOTOOL’s HL7 Blogging Contest.

Healthcare billing departments are dependent on getting accurate information in a timely manner to meet their goals, such as increasing cash flow and decreasing operational costs. Getting the needed patient information and charge capture data can be accomplished using HL7 interfaces.

Automating your environment with HL7 interfaces leads to many tangible and intangible benefits for your billing facility including:

• Increased accuracy with reduced manual entry
• Increased Turn Around Time (TAT) with data flowing to billing in near real time
• Decreased paper records storage and office space with electronic data (digital archive)
• Fewer denied claims due to timely and complete information
• Increased cash flow with lower DSO (Days Sales Outstanding)
• Improved data retrieval - faster, searchable, simultaneous access by multiple users
• Increased patient satisfaction with more accurate billing
• Increase efficiency

As a result, your operations will be more competitive, profitable, and streamlined. To learn more, read another blog post on how to streamline your billing workflow.

When transferring patient’s billing information through HL7 messaging, it is helpful to know some of the key segments in which to find the data.

PID: Patient Information
PV1: Visit Information (DOS)
FT1: Financial Transaction
IN1: Insurance Information
IN2: Additional Insurance Information
IN3: Additional Insurance Info, Certification
GT1: Guarantor
AUT: Authorization Information

A better understanding of the HL7 messages used in various billing environments may help demonstrate the possible automation and healthcare integration capabilities.

1) In acute care hospitals, the billing department is typically in-house. As a patient is treated, the clinical data is transferred to the appropriate departments throughout the hospital, including billing. The main HL7 messages transferred to billing are:

ADT = Patient demographics
DFT = Detailed financial transaction
ORU = Observation result unsolicited

Below is an example DFT message that shows the addition of a test, Lipid Panel, to a patient’s bill:

MSH|^~\&|FrapLab|StJohn|HIS|StJohn|20071217094822||DFT^P03|MSGIDv|P|2.3
PID||3|82828||Simpson^Margaret^^^Mrs.||19650525|F|||12 Maple St.^^Springfield^OH^21003^USA
PV1|4||^22^1||||2360^England^Mikey|||IP|||||||||4|||||||||||||||||||||||||20071217094755|20071217094813
FT1|1|6|4|20071217094821||Credit|303756^Lipid Panel^L|||2|115

2) For reference laboratories or independent commercial labs, the billing department handles two types of billing: client and patient. Client billing is where the lab bills the services back to its client, the doctor’s office, clinic, etc. Patient billing involves third party billing based on patient coverage or direct bills to the patient. If the lab receives orders electronically via an HL7 interface, then the order message (ORM) may contain the needed billing information. Below is an example order for a serum Vitamin C test for a patient with a primary insurance carrier being Medicare:

MSH|^~\&|SNDAPP|SNDFAC|RCVAPP|RCVFAC|200710021226||ORM^O01|DCGTORD.2.79
|P|2.4|
PID|1|89300043|||MOUSE^MICKEY||19600505|M||||||||||1259801|999-00-888|||
IN1|1|UNK.|MR1|MEDICARE/COMMERICAL|P.O. BOX C32086^^RICHMOND^VA^23261||-0000000000|499032980||||00001231|00001231||MC|O
DONNELL^RICHARD^W^^|1|-19221027|7982 WELLINGTON DR^^WARRENTON^VA^22186^USA||||||||||||N||||-|499032980-A|||||||M||
GT1||ODONNELL,RICHARD w||7982 WELLINGTON DR^WARRENTON^VA^22186|-7033492732|||
ORC|NW|L2435^LAB|^LAB||||1^^^^^R|||||23462^ALVAN^^^||
OBR|1|L2435^LAB|010700^VITAMIN C (ASCORBIC ACID), SERUM^L||||20071002122600||||N||SICK|||23462^ALVAN^^^||||REQ#5468|||||||1^^^^^R|

3) Finally, an independent imaging center takes on the task of billing the technical and professional components of its services. The professional reads they do for hospitals or referring physicians require the patient’s billing information and the final reports for coding. The patient information can be sent via paper (e.g., faxing), sent electronically through an HL7 interface (ADT, BAR, or DFT messages), or sent via a file batch with a proprietary format. The reports used for coding can be transmitted using HL7 ORU messages.

An example BAR message that creates a new account with needed billing information follows:

MSH|^~\&|BRACK|CHA|FIN|5|040112043835||BAR^P01|0000000001|T|2.3|
PID|||3000222452||JONES^SAM^A||19931114|M||||||||||1546740|666381774|
PV1||I|BRACKENRIDGE|||||023434|||||||||023434|||||||||||||||||||||||||||20031121||
GT1|0||JONES^ANN^M||756 E FANNIN ST^^LAGRANGE^TX^789450000|9799660489|||||M|||||CARE INN|457 NMAIN^^LAGRANGE^TX^78945|
IN1|1|T71|||MEDICAID

For additional information, watch a 15-minute web seminar on the role HL7 messages play in different healthcare billing environments.

The focus of this blog is the IT back-end radiology workflow changes. The goal of healthcare IT is to make all the systems work smoothly together or interoperate for organized, seamless data flow. The first step to achieving such goals is to understand your current workflow.

In an example imaging center, the workflow might be:

• Schedulers enter orders manually on the radiology information system (RIS) or orders move into the RIS electronically from external referring physicians or hospital systems.
• Those orders flow to various internal systems such as the picture archiving and communication systems (PACS) and Voice Recognition (VR).
• The images are acquired:
  • Modalities query the modality worklist manager (PACS).
  • Once the procedure is completed, images are returned to PACS.
• A radiologist reads the images and dictates the results into VR.
• A radiologist self-corrects and approves the reports.
• The reports are distributed to RIS, PACS, Billing and the applicable referring locations.

As is possible to observe in the example radiology workflow, in an imaging center, clinical data must move to and from multiple systems. Even though the workflow is unique for each imaging center, the need to transfer clinical data is not. The moving of data is where HL7 interfaces can make the most headway towards bridging the gap for interoperability and creating that organized, seamless data flow.

Using an HL7 integration approach to move clinical data between applications helps:

• Optimize information systems
• Reduce errors in multiple, manual entries
• Maximize radiology workflow
• Facilitate growth through an efficient workflow

Whatever applications and systems are used to perform the tasks necessary in your imaging center, there is still a need to make the data flow to the right place at the right time based on the capabilities of those systems. With greater requirements for RIS-driven workflow and data exchanges with referring physicians, the HL7 Standard plays a prominent role in automating the radiology workflow.

For addition information, read an interview with the CIO at Radiology Consultants of Iowa and watch a 15-minute web seminar on what role HL7 messaging can play in radiology workflows.

LOINC facilitates the exchange of results data by providing a universal standard for identifying laboratory observations. The LOINC database and its supporting documentation are maintained by the Regenstrief Institute, Inc.

Why was LOINC established and what are the benefits?

LOINC was initiated in 1994 by the Regenstrief Institute to identify observations in HL7 messages (OBX segment). Prior to its establishment, no universal standard for laboratory test names existed. Therefore, laboratories would send varying values in the OBX-3 (observation identifier) and OBX-5 (observation value) segments. When working with multiple laboratories that used different codes for different test observations, a lack of standardization hindered the development of clinical repositories and research databases.

LOINC provides a standard way of identifying observations using approximately 41,000 observation terms. Nearly 31,000 of these terms are used for laboratory testing. LOINC codes allow you to merge clinical results from multiple sources into a single database, allowing results to be automatically sent to the appropriate place and improving patient care and clinical research.

Who uses LOINC?

LOINC is endorsed by the American Clinical Laboratory Association and the College of American Pathologists. It has been adopted by some large commercial laboratories for use in HL7 result messages and is used by some US federal agencies with healthcare interests. While initially created specifically for HL7 messaging, its use has expanded to Digital Imaging and Communication in Medicine (DICOM) ultrasound messages and Clinical Data Interchange Standards Consortium (CDISC) pharmaceutical industry messages.

Where can I get a copy?

The LOINC database and REMLA - a program for browsing the database, and mapping local files to LOINC - are available at no cost from the Regenstrief Institute. It can be downloaded here. More information about LOINC is available from the Regenstrief Institute.

Final thoughts on LOINC.

• In general, LOINC is a work-in-progress rather than a final standard.
• There is no US government mandate to move labs to LOINC. Movement will be gradual.
• ELINCS uses LOINC for the top 100 tests, not the results. More information on ELINCS can be found in a previous post.

HL7 V2

• Not “Plug and Play” - it provides 80 percent of the interface and a framework to negotiate the remaining 20 percent on an interface-by-interface basis
• Historically built in an ad hoc way because no other standard existed at the time
• Generally provides compatibility between 2.X versions
• Messaging-based standard built upon pipe and hat encoding
• In the U.S., V2 is what most people think of when people say “HL7″

HL7 V3

• Approaching “Plug and Play” - less of a “framework for negotiation”
• Many decades of effort over ten year period reflecting “best and brightest” thinking
• NOT backward compatible with V2
• Model-based standard built upon Reference Information Model (RIM) provides consistency across entire standard
• In the U.S., when Clinical Document Architecture (CDA) is what most people in the U.S. think of when people say “HL7 V3″

Learn more about preparing for HL7 V3 or more about the HL7 standards, including HL7 V3, through an in-depth white paper entitled The Evolution of HL7 (PDF).

For a 15-minute recorded presentation on HL7 V3, please click here.

In the imagingBiz.com article, ARA discussed the old process and stated “We would touch each radiology report approximately six times to manually key demographics and charge transactions into the billing system.” They went on to describe the completely manual nature of their billing workflow that involved lots of people, pens, and paper.

By focusing on the workflow and determining best practice approach on how to automate it, ARA implemented a new way to deal with the billing process that has delivered big benefits. The primary benefits center around reduction of errors, expedited posting of revenues, and a leaner approach to getting the work done.

The technology applied to the workflow included a document scanning and storage application and an HL7 integration engine. Once the information is in a database, ARA will “push it through our interface engine, convert it to an HL-7 message, and upload it into our billing system.”

ARA is one of our customers. The article highlights, nonetheless, how a radiology workflow can be automated to drive real results. For additional information, please read a customer case study (PDF).