Three distinct methods exists for automating processes within the Epic EMR, specifically, automation of personnel operations related to EMP & SER, they are web services, HL7, and SQL + Imports. Each has it’s strengths, my focus is on leveraging SQL for lights out automation of all things maintenance. Similar results could be had leveraging interface engines with HL7 messages or Web Services but I have opted to stick primarily with SQL/SSIS for the lights out processes.
This post is in follow up to Automating the Epic EHR with SQL/SSIS and is a quick overview of some of the Pros/Cons of the various integration methods available. The focus of this is automation/maintenance tasks that would fall under operations (personnel management that typically involve the EMP/SER Masterfiles.
I considered a side by side comparison but it’s not that simple, what you are trying to accomplish will drive the solution. Much of what I work on comes from database extracts, I can be handed the information, as is the case with PeopleSoft – HR (new hires, terminations, transfers) or I capture it by leveraging SQL Server to look for changes to a database extracts day-over-day and capture updates to things like provider privileges from the Medical Staff Office or address/phone/fax updates from directories.
If you are looking for a web application and real-time updates then you will be leaning towards Web Services, if everything happens behind the scenes and you want lights out, then SQL + scheduled imports will probably fulfill the requirements and likely without the need for big project teams and kick offs. HL7 is, in my opinion losing footing in this space, I can’t think of a new deployments in this space operations/maintenance/auditing that would use HL7 over Web Services so I’m going to pass on discussing it.
We do lose “realtime” updates when relying on SSIS generated flat files, then scheduled import jobs to pick them up. This can be mitigated if required, by scheduling jobs to recur at set intervals (hourly?) but for the most part, operations tasks do not require this and it’s unnecessary to have more than one sweep a day. Case in point, terminations and/or provisioning, you take a list of employees that were processed the previous day and run them all as soon as you pickup your file, process them in SQL Server, drop a flat file to an ftp site, and schedule a job to import that file. Web Services would not lend itself well to this type of operation.
I’ve seen a demonstration of a web application used for account provisioning, allowing analyst to make updates to templates/subtemplates/user groups, etc… directly from a web form in real time, this would not lend itself as well to a SQL/import process unless that file was scheduled to be picked up and imported at say, 15 minute intervals… Probably not realistic and web services would outperform on many levels, but this comes back around again to real-time with an analyst interacting with a web app vs behind the scenes automation.
Another criteria which varies from organization to organization is the availability of talent, how many Epic Analyst have SQL backgrounds… probably a higher percentage than those with XML backgrounds, this can way heavily on deployment time for new projects, when you rely on web app teams you have…..relied on web app teams. Depending on the organization, this can go both ways, and depending on how much experience they have it could be a prolonged process, there’s a good chance it has been used for MyChart so this shouldn’t be new and Epic has a lot of sample code for web services via the Interconnet framework that cover a lot of common (EMP) tasks.
There are other issues to consider when relying on imports and some caveats that need to be considered as well as the impact of your environment strategy (i.e if you provision in POC/BUILD you need a process to move your changes up to production, but this is not solved by one method of automation over another, that is to say, whether you use web services or imports, if you do not maintain EMP & SER in production you are still faced with the data courier issue.
