Caristix Connect Is Now Caristix Conformance (Thank You, Beta Users)

First of all, a big thank-you goes out to all the folks who signed up for our beta. Because of your input, our products are a lot more useful and a whole lot more compelling than a few months back.

Betas Are Good For Branding and Messaging, Too

Our beta users provided great feedback on user workflows and functionality, which we incorporated into this release. They also delivered a healthy pipeline of enhancement requests. Plus we identified (and fixed) bugs.

We also got more than we were expecting. We weren’t expecting to change the product name. But then we kept having this conversation over the “Connect” name…

Customer: “Are you guys building an interface engine?”

Caristix: “Uh, no.”

Customer: “Then what are you connecting?”

Caristix: “You know, the conformance profile gaps you need to bridge when you’re spec-ing an interface?”

Customer: “So… why exactly is it called ‘Connect’?”

The upshot: we changed the name. We wanted you to immediately get that Caristix Conformance is not an interface engine. It’s software that gets you to the interface engine setup stage a lot faster by automating conformance profile creation.

So, to clear up any confusion, Caristix Connect, which just came out of beta, is now officially Caristix™ Conformance software.

Thanks, Caristix beta users!

Caristix Conformance and Test Launch

Caristix Launches HL7 Integration Management Software for Healthcare Vendors and Hospital IT Teams

HL7 Interface analysts and engineers eliminate time-consuming manual work to leave more time to bridge healthcare data gaps through interface engines, HIEs, and more.

Quebec City, Canada, November 5, 2010 — Caristix, an HL7 integration software company serving healthcare vendors and providers, today announced the release of new software designed for interface analysts and engineers. Caristix™ Conformance and Caristix™ Test software help close information gaps before work begins on configuring an interface within an integration platform.

Time Savings on HL7 Requirements, Scoping, and Documentation Work

“Before you can consider using integration technology such as an interface engine, there is a lot of upfront analysis and documentation work involved with scoping an interface, gathering requirements, and then testing the interface,” said Netspective CEO Shahid Shah and popular blogger at HealthcareGuy.com. “Caristix software enabled us to automate this work, especially the document generation and conformance verification. Netspective was able to create definitions for connecting hospital systems to our customer’s cloud-based system in a few days rather than a few weeks. We couldn’t have done this cost-effectively without Caristix and I encourage everyone to give it a try.”

While interface engines and other integration platforms help vendors and providers address the connectivity and transactional issues associated with interoperability and integration, Caristix software addresses the time-consuming scoping and requirements-gathering stage of determining what and how to connect as well as the oft-forgotten documentation task.

LIS-EHR Interface Example

“Until now, there hasn’t been a way to electronically manage or automate interface requirements and scoping,” said Stéphane Vigot, president of Caristix. “For instance, if you’re implementing an ONC-certified EHR for Meaningful Use purposes, one key component to consider would be an interface to the lab you do business with. Without this interface, it would be impossible to order lab tests and view lab results within the EHR. A physician would have to log out of the EHR, then log in to the lab system to order labs and view results, and finally switch back to the EHR to copy and paste the order and results associated with a patient. However, keep in mind that LIS-EHR interfaces are some of the most complex in the business. This complexity can be controlled by accurately assessing the gaps between the two systems. That’s where Caristix software comes in.”

“We’re aiming to be the solution for the time-consuming, spaghetti-junction part of HL7 integration.”

Caristix Conformance and Test Software

Caristix Conformance (beta name: Connect) is a conformance profile management application designed for interface analysts. It automates conformance profile creation, gap analysis, and documentation. Caristix Test software is a test automation application designed specifically for HL7 integration. It enables analysts to create test messages with real-world data and test plans that reflect customer-specific workflows. More information is available at caristix.com/products.

About Netspective

Netspective provides high-value healthcare IT technology strategy analysis and consulting services as well as deep technical implementation expertise to providers and technology vendors. Netspective has recently announced a new “HL7 as a Service” offering, which is the world’s first HL7 and X.12 cloud-based messaging service for instant healthcare connectivity. To learn more, please visit netspective.com.

About Caristix

Founded in July 2009, Caristix develops software tailored to the needs of healthcare technology vendors and hospital IT teams. Caristix gives busy interfacing experts the power to assess gaps between siloed information systems without the investment in time and resources required by current manual work. Through Caristix technology, interfacing teams are positioned to drive complexity out of the implementation and delivery of the essential software and systems used in healthcare. To learn more, please visit caristix.com. Follow Caristix on Twitter, LinkedIn, and the company’s blog.

Avoiding the #1 Interface Validation Mistake

When provider organizations are on a tight deadline to implement or upgrade an EHR, EMR, HIS or other clinical system, setting up a test or staging system can seem like just another procedural hurdle. So it couldn’t hurt to just do the final testing in the live, production system, right?

Wrong.

Why It’s Tempting

It might seem quicker to simply tag test data as “Test Patient1” in “Bed #1-T” and get it into the production EMR or HIS. You skip duplicate server (or virtualization) costs, maintenance overhead, connectivity issues, and the whole headache involved with mirroring data, settings, and configurations between the test and production installations.

But this is a tradeoff you don’t want to make.

Why It’s Dangerous

1. You can’t be sure that you’ve canceled all your test transactions. After all, the purpose of interface validation is to check that the interface is working as expected. If it isn’t, you’ll end up with faulty transactions in your production system.

2. Whenever you’re in the production system, you run the risk of impacting ePHI or protected health information in HIPAA terms.

3. Audits. CMS audits include HL7 billing data. You don’t want phantom test data turning up in a CMS audit.

We all know testing in a live system is a bad idea, but it sounds like people are still going down this road. Any further thoughts as to why?

Customer Success: Cardinal Health Canada

Here’s what Barry Holleman, Vice President, Clinical Technologies, at Cardinal Health Canada had to say recently about Caristix:

“Cardinal Health Canada was seeking ways to cut HL7 interface validation time on our product deployments, without sacrificing quality processes. We were aiming to cut 20 to 25% off our troubleshooting time. Instead, Caristix software enabled our interface engineers to streamline troubleshooting much more significantly. In one case, what was a 2 hour task now takes just 10 minutes.

“I would also like to mention how responsive the team is at Caristix. Training and follow-ups have been personalized and results-focused.

“If you are looking to develop, test and troubleshoot HL7 interfaces more efficiently, Caristix deserves to be on your short list.”

We’re thrilled!

If you’d like learn how to cut your HL7 troubleshooting time, feel free to get in touch for a 15-minute demo. My email is at the top of this post.

8 Stages in an HL7 Interface Lifecycle

While clinical end-users count on interfaces to deliver the functionality and interoperability they need, IT stakeholders need to be sure everyone involved gets the steps and costs involved. Especially since interfacing takes up 20 to 40% of an implementation project timeline. Here’s a quick overview to get everyone on the same page.

HL7 Interface Lifecycle
HL7 Interface Lifecycle

Scoping

  • An interface analyst scopes the interfacing project.
  • The analyst performs a gap analysis based on the client’s current information system environment and the new system to be implemented. The gap analysis guides the conformance profile that defines the interface.
  • Once the gap analysis is complete, the client, the vendor, and potential third parties sign off on who does what.
  • When handled manually, scoping can be a major bottleneck in an implementation project. Vendors seeking to eliminate process waste need to seek out automation avenues. Gap analysis software can cut 30 to 50% off the scoping timeline.

Coding and Configuration

  • An interface programmer uses the conformance profile and other documentation (such as database mapping) to code and/or configure the interface.
  • Interfaces used to take weeks and months to code. With today’s tools, you can get it done in a few days or weeks, so this stage is rarely a bottleneck in the lifecycle of an HL7 interface.

Simulation Testing

  • The programmer or analyst validates the interface against sample — read simulated — messages. Once the interface can successfully send and/or receive simulated messages under test conditions, it is shipped to the client site for integration testing.
  • The Simulation Testing step represents industry best practice. Providers should ensure that vendors put the interface through its paces before integration testing. Ask to see sample test documentation before signing off on the implementation project approval. Good simulation testing can avoid a whole lot of headaches during go-live and after.

Client Validation

  • An analyst at the client site validates the interface in a test system against specific clinical scenarios using pre-configured test data.
  • Important: you want to avoid using production systems and protected patient information during the validation stage.
  • The scope of client validation can vary greatly, depending on the project and on provider IT culture. Organizations that invest in thorough validation see payoffs with smoother go-lives, less downtime, and fewer calls to their vendor tech support teams down the road.

Go-Live

  • The new system then goes live.
  • Vendors and providers monitor the interface intensely at this point, in order to fix issues as they arise.
  • Some interface engines come with built-in monitoring tools with real-time alerts, so staff on call (on both provider and vendor teams) can proactively fix issues before they impact clinician end-users.

Monitoring

  • After go-live, provider IT teams need to ensure the interface continues working as expected.
  • Monitoring tools (some come built in to interface engines) help ensure issues are flagged.

Support and Maintenance

  • The interface needs to be supported, just like the information systems they link.
  • Vendors rely on HL7 troubleshooting tools for parsing messages and looking for problem segments. The problem is, most of these tools are built for interface programmers and engineers, not front-line tech support. An emerging industry best practice is to ensure that front-line support teams have troubleshooting tools that don’t require extensive HL7 knowledge. This can avoid expensive issue escalation and decrease customer response time.

Upgrade

  • When a system that receives or sends data through the interface is changed, the interface needs changing as well. This triggers a new scoping stage.

Have you uncovered practices that enable faster time to go-live or more efficient support? Let us know in the comments.

Meaningful Use Stage 1: Certification is Just the First Step

Yesterday, CCHIT launched their ONC-mandated test and certification program and delivered a one-hour webcast on their process. Slides and a recording are available on the CCHIT site.

One thing is clear. Certification is just the first step. Certification means that the EHR system or module meets NIST testing criteria for functionality and security related to Stage 1 Meaningful Use measures. But implementation and related integration issues still loom in the background.

At least three objectives in the core and menu sets require some form of data exchange between an EHR and another system:

  • reporting clinical quality measures to CMS or a state agency
  • incorporating clinical lab-test results into certified EHR technology as structured data
  • submitting electronic data to immunization registries or immunization information systems

The NIST test scripts cover the ability of EHRs to send and receive data. The scripts aren’t meant to cover the system on the other end. While the Meaningful Use documentation specifies standards, systems aren’t automatically set up to exchange data. Even if all systems in this exchange are on the same HL7 version, we’re still going to see different interpretations of the standard.

Multiple interface analysts are going to be faced with the monumental task of assessing and bridging these gaps. In other words, even if a system is certified, no one is talking plug and play. Providers and vendors still face a significant implementation hurdle related to interoperability.

Are you involved with EHR implementation? How are you and your customers dealing with interoperability issues? Please let us know in the comments.

HL7 Interface Conformance Profile Template

I recently had a discussion with some of our partners around conformance profiles and templates. Collectively, we haven’t come across an industry-standard template. Some organizations build their own. Others decide to go without because templates can take time and effort to set up. We think a conformance profile should help you clearly and concisely communicate what your system expects in terms of data exchange. In healthcare, this isn’t a trivial task. Learn more about conformance profiles in healthcare, which we covered in a previous blog post.

We’re sharing our template for HL7 conformance profiles.

Here are Word and PDF versions of the HL7 interface conformance profile template that will come standard with Caristix Connect software (launching Fall 2010). Caristix Connect software is designed to automatically output a conformance profile based on this template.

Template Download

Download the Word template here.
Download the PDF template here.

Template Instructions

First, download the template and save it to your computer. (You’ll need Microsoft Word 2007 or higher for the Word version.) To get you started, the template contains several examples of data elements to cover:

  • HL7 version. Examples in the template are based on HL7 v2.6.
  • HL7 trigger event or message. ADT-A01 patient admission message included. The message structure lists typical segments. Add more messages or trigger events as needed.
  • AL1 Patient Allergy segment, with segment attributes listed in a table. Below the table are comments on each field. Modify by adding segments as needed, along with your comments. Typically, comments document customer-specific information, customization notes, and potential deviations from the HL7 standard.
  • ST and XPN data types. Attributes and comments are listed. Change out and add more as needed.
  • User table for patient gender. Change out with the table data you’ll be using, and add other table types.
  • Note that the internal document links are not active in this sample template. When we launch Caristix Connect software, the links generated by the software will enable users to click to navigate sections.

Feedback

If you have any tweaks or suggestions for making this template better, please post a comment or drop me a line. And if you’re already using a template you like, we’d be interested in learning more in the comments.

Sharing

If you find the Caristix conformance profile template helpful, please share with your friends and colleagues. To make this easier, there’s a handy Share widget at the top of this post. Or just copy the link in your browser bar to send by email.

What is an HL7 Conformance Profile?

Definition

Let’s start with the formal definition, introduced by the HL7 organization in the v2.5 specification. Here is an excerpt from section 2.12:

Definition: An HL7 message profile is an unambiguous specification of one or more standard HL7 messages that have been analyzed for a particular use case. It prescribes a set of precise constraints upon one or more standard HL7 messages.

In other words, this is a description of the data and messages that an interface sends and/or receives. The description covers the data format, data semantics and acknowledgment responsibilities. The description must be clear and precise enough so that it can act as a set of requirements for data exchange.

Benefits: Why Create a Conformance Profile

First and foremost, you can easily derive your HL7 interface specification, documentation, and validation from the conformance profile. You can use the profile before the servers, the network connectivity, the database configuration, etc. are set up.

You can also derive at least 4 implementation artifacts from your HL7 interface conformance profile.

HL7 conformance profile artifacts

Interface Documentation

HL7.org uses the term “Conformance Statement” to cover conformance requirements. Personally, I prefer “Interface Documentation” because it doesn’t refer to a specific template or content. Whatever the term, this artifact should be flexible enough to contain whatever relevant information you may need (and just that relevant information…) so the documentation can adapt to any integration project.

Gap Analysis Report

Using a conformance profile, you’ll be able to map the differences between the profile of the product you’re deploying and the current HL7 messaging environment. The Gap Analysis Report helps you document each difference or gap, providing a list of items the interface will have to address. These might include the data format, location or another requirement. For more on gap analysis, read the Caristix blog on gap types and how you go about performing a gap analysis.

Test Plan and Validation Report

Use the conformance profile to generate valid (and known invalid) HL7 messages so your newly configured interface can be tested. When needed, the profile can help to test the data mapping defined in an interface engine. The conformance profile can also help to validate that data semantics are applied consistently across an interfaced hospital information system.

Do you use conformance profiles for other purposes? Let us know in the comments.

4 Tips for Smoother HL7 Interface Validation

What can you do to improve the HL7 interface validation process on your next implementation project?

I was on-site at a hospital where a vendor was doing a product upgrade. The vendor and the hospital IT team were both committed to getting it done right, so the 2-week interface validation was thorough. That investment pays off. The upfront work pays off down the line in reduced help desk wait time and service calls.

Based on this experience, here are 4 tips to help with your next implementation.

1. Create a Connectivity Checklist
Before getting started with interface validation, the test equipment and systems need to be up and running — and connected — on both the vendor and hospital ends. Sound trivial? It isn’t. Every facility is different, right down to network configurations. Some examples:

  • Are IPs static or dynamic?
  • Are they using dedicated MAC addresses?
  • Which ports need to be open?

The takeaway: create a checklist, and get it to the hospital IT team at kickoff. Make sure the checklist is double-checked (really… don’t settle here) by the time you’re turning on the test equipment and connecting to the test information systems. You need the network connectivity out of the way, so that validation activities get the time and attention they need. And so that project managers aren’t spending extra travel time scrambling to finish up HL7 interface validation tasks.

2. Review Test Workflows in Advance
Vendors usually provide a validation or test guide listing clinical workflows that need to be reviewed and checked off during interface validation. Ensure that the hospital’s clinical informatics team reviews test workflows in advance. Take the time to identify:

  • standard workflows that apply to the hospital or health system
  • workflows that don’t apply (you can take these off the hospital-specific list)
  • additional hospital-specific workflows that aren’t in the guide

Validation guides capture a range of clinical and administration situations: patient admissions, lab orders, med orders, charge capture, and so on. But the specific steps are going to vary from one hospital to the next. So it’s important for the customer to pick the right workflows and add their own. The right test coverage means you’ll fix issues during testing, not after Go-Live.

3. Set up Test Data in Advance
Get your test data into the test system before the validation period. We observed that it took between 7 and 10 minutes just to create and admit a patient in the test ADT. This is painful during a tight validation schedule.

Setting up test data is also time-consuming if you’re manually creating patients and orders in the test system. Ideally, a hospital would have a set of test patient profiles, including HL7 messages, for use with the multiple interface validations that take place every year. Alternatively, vendors with repeatable testing scenarios might consider setting up a test data template to share with customers.

4. Document Your Validation Results and the Interface
Throughout the interface validation process, the team is going to be focused on getting the interface up and running. You’ll be marking pass/fail results, troubleshooting issues on the fly, and focusing on getting to the next clinical workflow on the validation list. Chances are, you’ll document on paper, in a file folder or a notebook. But six months down the road, will the paper documentation be usable? Chances are, no.

We recommend documenting your interface and the validation results electronically. Sometime after the Go-Live, someone’s going to be upgrading or migrating other systems that provide inbound data. Sooner or later, the provider or vendor support team is going to be troubleshooting this interface and others. Make the documentation easy to find and use, so you save time and repeatable effort.

Do you have any other tips that would help make HL7 interface validation go smoother? Share them in the comments.

Application Testing in Healthcare: Sacrifice Test Performance for Traceability?

There seems to be two conflicting needs in software testing in healthcare: traceability and test performance.

Traceability
Traceability is the ability to link your requirements to your tests:

Traceability flow: reqs to design to testing

In healthcare, regulatory compliance is on the side of traceability. Reasonably enough, regulators want to know that products actually do what they’re designed to do. Traceability provides that chain of evidence.

Test Performance
However, traceability can come at the expense of test performance — defined as how efficiently a product can be tested both for defects and for requirements conformance. Increased test performance is based on automating the right tests and also merging a number of test cases into test scenarios that focus not just on product functionality but on appropriate workflow. In many industries, the practice is to group several requirements and test them all at once through a few test scenarios. But healthcare regulators (and regulatory compliance owners in vendor organizations) tend to avoid this practice. They want to see proof of code coverage and requirements in test plans. Also, regulators are focused on making sure features are implemented as designed. In this context, there is less emphasis on bug-hunting — although as a rule, vendors and regulators both agree bug-catching is critical.

Add Agile to the Mix
Many software development organizations within healthcare are dipping their toes into Agile methodologies and hoping to gain from reduced project risk, iterative customer feedback, and more cohesive teamwork. But traceability can be more of a challenge with Agile than waterfall methodologies. In Agile, Quality Assurance (QA) tests during each sprint, as the team delivers new features. But there’s no way to get rid of the integration testing bottleneck at the end, where the whole product needs to be tested.

Is A Traceability Matrix The Answer?
One way to address the traceability-performance dilemma is a traceability matrix. Owned by QA, a traceability matrix links requirements, functionalities, workflows, and tests to ensure the entire product is being tested. If you use Word or Excel for traceability documentation, you’re guaranteed to add more documentation overhead. In these formats, traceability matrices are time-consuming and complex to create and maintain. The result is that many organizations don’t automatically include a traceability matrix in in their documentation plans. And you might even find some Agile proponents arguing against traceability matrices as non-Agile.

But there are real advantages to starting and maintaining a traceability matrix. And if you set up your requirements, functionalities, workflows, test cases, and test scenarios in a database instead of a Word document or an Excel spreadsheet, you can simplify maintenance exponentially. All you’d need to do is keep each element up to date. Then generate the matrix with a simple SQL query.

What do you think? Do you have other ideas on maintaining traceability without sacrificing test performance? Share your thoughts in the comments.