In the last chapter, we explained what to aim for in test messages and message samples. Next you need to map out your processes and workflows to understand how your interface can support them.
For example, your clinical workflow may look like this: a patient is admitted in the Emergency Department via the departmental ADT system. The doctor on duty orders lab work and the patient is admitted to the hospital. The admission is now recorded as an in-patient in the standard ADT system. The attending doctor orders medications via the hospital’s pharmacy system. The night nurse administers medications, and records this via the barcode medication administration. Not satisfied with the patient’s progress, the attending doctor orders new labs and after receiving the results, decides to perform a procedure, which requires that the patient be transferred to another location. The doctor’s orders and the transfer are recorded in the in-patient ADT. The patient improves and is discharged – this event is captured in the same ADT. Finally, thanks to Meaningful Use, the patient’s family doctor receives a discharge summary via the local HIE.
All of these events comprise a workflow representing a patient stay or visit. While some workflows are optional, some always happen in a certain way. What’s important is knowing where the data is going and how it’s going to be used.
Why You Need to Map Processes and Workflows
If you’ve documented your workflows and systems, it’ll be easier to connect the next system because you won’t need to start from scratch. Workflows also impact your test plan. For instance, all your destination systems might require different inputs from a single source system. As part of your scoping and requirements planning, you’ll need to understand the workflow – for instance, who does what: a physician, a nurse, or a pharmacist? Capturing workflow is also critical for network monitoring down the road so, for example, your IT team will know right away when a system goes down what workflows and processes are affected. (We’ll discuss network monitoring in Chapter 11 .)
Start with a Spreadsheet?
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. After all, in most hospital environments, you’ll be dealing with multiple workflows and systems, meaning your systems will be exchanging different sets of data. To efficiently and accurately test and manage all of this over the interface lifecycle, you need a clear mapping of workflows and processes – something that’s nearly impossible to capture in a spreadsheet.
Here’s what you should capture when documenting your interfaces and workflows:
- Interface names
- Systems that are linked
- Connection information (IP address, credentials, port, connection type, location (location may be by unit or by data center)
- Security: SSL, VPN, firewalls, and any required certificates .
- Trigger events: List all trigger events and note which ones are used by which systems based on your spec.
- Connection types: could include database, web service, TCP, HTTP, file, FTP .
Note: here’s why it may make sense to note the data center location. Let’s say you run systems out of two data centers for redundancy, one in Skokie, IL and the other in Hyde Park, IL. If your Skokie, IL data center experiences failures, but your Hyde Park data center is still operating, you’ll know it makes sense to start your troubleshooting in Skokie.
Consider one workflow in which data entered through an interface is first pushed to a database, then to an external system through a web service, and finally to archives or an enterprise warehouse. Without a diagram of this workflow, it’s difficult – if not impossible – to track the data flow. Four months after deploying your interface, you may find that no data has been pushed to the archives.
Monitoring Beyond the Interface Engine
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? Monitoring workflow is a major issue in interoperability – even bigger than interfacing. You need a way to monitor beyond the engine.
While you can track interfaces and workflow to some extent with spreadsheets, and can use a tool like Visio to diagram it all out, you ultimately need a tool that maps process and workflow. Such a tool lets you truly grasp your data and interfaces – not just your interface engine plumbing.
4 Capabilities to Seek Out for Monitoring
- 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 manage assets so you can take an instant inventory.
- And it should provide all this regardless of the interface engine you’re using.
Tips for Artifact Management
Interfacing artifacts can grow over time. You maintain two profiles for your source and destination system. You conduct a gap analysis and your engine handles message transformation. But message transformation is part of workflow. You need test plans and test data. Keep all these artifacts together and include workflow. As you develop and implement interfaces, these can grow.
Interface Asset Template: What to Capture
We can’t emphasize it enough: profiles and spreadsheets are just a start; in order to fully cover workflow, you need software to map process and workflow. Nonetheless, we’d like to help you get started with a baseline spreadsheet. Our Interface Asset Template is a handy download that will show you what you need to track.
Read More in the HL7® Survival Guide
Introduction
Chapter 1: How to Integrate and Exchange Healthcare Data
Chapter 2: Pros and Cons of Interfacing Capabilities
Chapter 3: The Heart of the Matter: Data Formats, Workflows, and Meaning
Chapter 4: How to Work with Vendors and Developing Your EHR Strategy
Chapter 5: Vendors, Consultants, and HL7® Interface Specifications
Chapter 6: Interfacing Artifacts: HL7® Conformance Profiles or Interface Specifications
Chapter 7: Interfacing Artifacts: Gap Analysis
Chapter 8: Interfacing Artifacts: Test Scenarios and Test Systems
Chapter 9: Interfacing Artifacts: Message Samples and Test Messages
Chapter 10: Process and Workflow
Chapter 11: Maintenance, Troubleshooting, and Monitoring
Chapter 12: Definitions
Chapter 13: Contributors and Resources
