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 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.