Blog

99 Reasons Why Interfacing is Challenging

By sovita.chander@caristix.com | Published: September 17th, 2013

Biggest challengesWhat is Your Biggest Interfacing Challenge?

To gain insight into the issues our users are facing, there is one key question we ask when a reader downloads a Caristix software trial, white paper, or article: what is your biggest interfacing challenge?

Here are 99 of them.

1. Working as a third party to large health systems and independent physician practices.
2. Communication.
3. Health information management.
4. Custom work.
5. Ask on Entry (AOE) prompt question validation at the ordering facility.
6. Compatibility between several different platforms; convince customers to standardize.
7. Understand the whole process.
8. Communications, expectations (requirements).
9. Educating others as to process.
10. The new XML standards.
11. Surgical/anesthesia record components.
12. Multiple versions of clients’ HL7.
13. The complexities of interfacing [EHR vendor’s name removed] with all of our third-party vendors, and the difficulty of working with [said vendor’s] code.
14. Scalability.
15. Coordinating Pharmacy and Lab interfaces between systems.
16. Having customers understand the challenges behind interfacing.
17. Working towards standardization.
18. Supporting multiple versions of HL7.
19. Interfacing with [EHR vendor’s name - different than #13].
20. New PACS/VNA systems.
21. Upgrades, standards migration, lifecycle, vendor stability, message routing/distribution only vs intelligent messaging.
22. Disparate systems.
23. The biggest was developing the interface which involved the transformations of 2 or 3 messages in one channel.
24. Testing.
25. Visit data doesn’t seem like it belongs in PID-18.
26. Maintenance.
27. Vendor interoperability.
28. Defining workflows that drive interface requirements.
29. Cross EHR integration.
30. Vendors taking responsibility for their product.
31. Lack of documentation.
32. Cooperation from PMS/EMR software vendors to continue to support their existing doctors and medical practices.
33. Facilities cooperation.
34. Different EMRs.
35. Communication.
36. Knowledge.
37. Time spent on development.
38. Constant uptime and beacon signals to make sure that the interface is staying active.
39. Test data management and automation.
40. Testing (yes, more than once).
41. Defining a process.
42. Lack of MDM.
43. Troubleshooting tools and automated monitoring.
44. Managing a team of analysts.
45. Interface implementations.
46. I am new to the environment and just trying to get up to speed.
47. Specification issue.
48. Standardization.
49. Time.
50. Other healthcare providers with HL7 capabilities.
51. Other vendors.
52. First time.
53. Unsure. New implementation.
54. Understanding HL7.
55. Documentation and testing.
56. Multiple disparate systems.
57. Bi-directional interfaces.
58. Vendors who write their own specs loosely based on the HL7 standards.
59. HIE implementation.
60. Understanding it all.
61. Getting the specifications accurate.
62. Common HL7 v2.x challenges with the integration of clinical interfaces.
63. HL7.
64. Resources.
65. Vendors.
66. Documenting everything.
67. Multivendor support.
68. ADT, LAB and RAD orders, LAB & RAD results, transcription reports.
69. Old technology.
70. Testing, customer communications, mapping codes.
71. Incompatible software.
72. Supporting a variety of customers.
73. So many legacy apps…
74. Upgrades.
75. Cost.
76. Message management.
77. Each hospital facility uses a different version of the HL7 standards and there does not appear to be a standard version in the field.
78. I need a super solution.
79. Consolidation, testing, specs.
80. Trying to interface between two “black box” interfaces -  pharmacy software interface and a vendor’s eMAR interface. We don’t have control over what and when orders are sent from the pharmacy to the eMAR, or what data the eMAR vendor extracts to use in their system.
81. Support, specifically deciphering HL7 messaging from multiple sources.
82. New technology, porting the old interfaces.
83. Matching the schema.
84. Too many differentials.
85. Mapping and gap analysis for many to many relationships.
86. Discrete CCD exchange.
87. Lock down by vendor’s interface engine.
88. HL7 message analysis.
89. Developers.
90. Specification documentation.
91. Number of custom requirements after gap analysis is complete. Ambiguity during gap analysis.
92. Getting all the different messages mapped to go in to our database.
93. Organization and process.
94. Workflows.
95. Not having a test server.
96. User friendly interfacing is my main issue with interface engines.
97. Speed.
98. Reading interfaces.
99. Consistency.

What resonates the most with you? Tell us in the comments.

Categories : HL7 Interfacing
  1. 2 Comment(s)

    Posted September 19th, 2013 | By sovita.chander@caristix.com

    Carl, you're absolutely right about the duplicates. We chose to leave them in since the repetition speaks to how common the issues are. So many readers come back to the same set of issues but with slightly different language. That's a great question about how users actually fared -- we'll be sure to include it when we do follow-ups.

    Posted September 19th, 2013 | By Carl Bergman

    This is an interesting list. There are some duplicates, such as 2 and 35 for communication. Also, HL7 gets listed more than once as a general problem. Those small things aside, it would be interesting to know how users actually fared. Did their anticipated biggest challenge work out that way or were there other larger issues?