Blog

Extracting Maximum Value from Your Artifacts

By margo.ellis@caristix.com | Published: September 9th, 2014

Tip 25 in the Interoperability Tip Series

This is our last tip in the Interoperability Tip Series. Read the entire series here.

The fact is that the value of your interface-related artifacts increases over time. While they’re useful for development and go-live, they are essential down the road, in a year or two or more. Follow the 4 best practices for extracting maximum value from your artifacts and get the most from them.

1. Work with real-world messages.

When you’re developing deliverables such [...]

Read More

Why Document HL7 Profiles (or Specs)? Part 2

By margo.ellis@caristix.com | Published: August 27th, 2014

Tip 24 in the Interoperability Tip Series

Read Part 1 here

In our previous tip we asked: why document HL7 profiles and specs. In beginning to answer that question, we explained that profile documentation is critical for troubleshooting and maintenance.

Another benefit to documenting profiles is that it streamlines processes when you are performing a system upgrade. Let’s say you’re changing or upgrading your pharmacy system – that change affects the interface of any other system that communicates with the pharmacy system. Imagine [...]

Read More

Why Document Your HL7 Profiles and Specs? Part 1

By margo.ellis@caristix.com | Published: August 18th, 2014

Tip 23 in the Interoperability Tip Series

The last few tips have been about what to document and how to document. This one and the next explain why documenting your HL7 profiles and specs is so important.

When you document your HL7 profiles and specs, you can much more easily troubleshoot issues and tweak configuration once your interface is live. Plus, if you created electronic – i.e., machine readable – versions of your profiles, you can use them in your monitoring. For [...]

Read More

Managing Interoperability and Interfacing Assets

By jeanluc.morin@caristix.com | Published: August 7th, 2014

Tip 22 in the Interoperability Tip Series

In the previous tip, we talked about documenting your interfaces and workflows – especially important for HIE organizations. This tip is all about our recommendations for what to look for when you’re planning out how to organize your assets – documentation, requirements, test scenarios, and the rest.

4 Capabilities to Seek Out

Visualize all of your interoperability assets, from multiple interface engines to the interfaces themselves.
Cover the entire interface lifecycle.
Access a library of interfacing assets and [...]

Read More

Documenting Interfaces and Workflows for HIEs

By jeanluc.morin@caristix.com | Published: July 30th, 2014

Tip 21 in the Interoperability Tip Series

This tip is especially relevant for Healthcare Information Exchanges (HIEs), regardless of whether your exchange is internal to an IDN or if it connects multiple regional stakeholders from community hospitals to physician practices.

Some interface engines let you view workflow within the engine. But what happens with external systems, such as an HIE transmitting to an internal engine, or multiple systems from different providers connecting across a region? Keeping track of workflow is a [...]

Read More

Interfacing Workflows: Start with a Spreadsheet?

By jeanluc.morin@caristix.com | Published: July 24th, 2014

Tip 20 in the Interoperability Tip Series

In our previous tip, we explained why you need to map processes and workflows. Many developers list their interfaces and workflows in a spreadsheet. You’ll find examples of what to track in the HL7 Interface Asset Template here.

While a spreadsheet provides a good start, you need to go beyond to capture the details and interconnections to capture a complete picture of your interfacing workflows. After all, in most hospital and HIE environments, you’ll be [...]

Read More

Why You Need to Map Processes and Workflows

By jeanluc.morin@caristix.com | Published: July 22nd, 2014

Tip 19 in the Interoperability Tip Series

Throughout the Interoperability Tip Series, we’ve stressed the need to complement the message structure and and content details from HL7 profiles with good process and workflow maps for future interfacing asset management. Earlier in the Interoperability Tip Series, Tip 4 emphasized the importance of mapping out the message process and workflow from the very beginning to kick off the planning of an interoperability project.

If you’ve documented your systems and taken the time to map [...]

Read More

HL7 Messages – Don’t Fall into the Beginner’s Trap

By sovita.chander@caristix.com | Published: July 18th, 2014

Tip 18 in the Interoperability Series

What’s The Big Deal?

If you’re just getting your feet wet with clinical and medical applications, you might think: “What’s the big deal? I’ll just hit Google for some sample HL7 messages and get started that way.” 

Don’t do that! If you do, you’ll get some basic structures right – like pipes and carets. But you won’t have any information about the interface you’re trying to build: the message types it uses, the segments and fields, positions, [...]

Read More

Creating HL7 Test Messages? Consider De-identification

By sovita.chander@caristix.com | Published: July 10th, 2014

Tip 17 in the Interoperability Tip Series

HL7 Data for Testing

In last week’s tip on HL7 test reporting, we suggested that you use production data for your testing. That said, you obviously can’t use real production data. You need to find a way to remove protected health information (PHI).

That’s where a technique known as de-identification can help. You keep the clinical workflow in the messages, but you remove patient identifiers and replace them with fake values. You can also replace [...]

Read More

HL7 Test Reporting

By sovita.chander@caristix.com | Published: July 3rd, 2014

Tip 16 in the Interoperability Tip Series

The past few tips have covered HL7 testing and test automation. This one covers what you should do with HL7 test reporting.

Creating Test Reports    

As part of the testing process, you’ll want to run reports. The reports should document the following: 

The number of times the test was run, as well as test duration – if you’re sending messages, this helps you understand performance.
Test results, including positive validations and failures.
The messages that were used; note [...]

Read More
All posts