Getting EHR Satisfaction Through a Successful Adoption Process [eBook series 6 of 6]
Finally, we are at the last step to getting EHR satisfaction. In order to get there, we need to decide who will be implementing the EHR requirements to ensure a successful adoption process.
Off-the-Shelf or Custom-Built
To start, one needs to compare the advantages of building an in-house solution or using an off-the-shelf solution. Relevant staff and IT management need to understand the technical requirements involved with either type of solution.
There are quite a number of professional off-the-shelf EHR options on the market to serve the needs of health care practices of all sizes. Most commercial EHR systems are designed for a broad base of practitioners and may not suit the specific needs of all health care providers.
For this reason, one may consider developing their own image capture solution – to tailor it to specific requirements for that practice.
If you decide to choose an off-the-shelf EHR solution, there are several things to consider.
The first thing is how easy it is to customize for your needs. Remember that most EHR solutions are designed for generic purposes. So, it’s important for you to confirm whether it’s possible to customize the solution to meet your unique requirements.
It’s equally important to evaluate the work/costs involved in such customizations.
While not as time-consuming as coding everything from scratch, implementing an EHR is still a rather big project. You are likely to encounter unexpected obstacles before, during and after the implementation. So, it is vital that you choose a vendor with good technical support for all phases of the EHR’s lifecycle.
While an in-house option allows full customization, the time spent, and the research and development costs might be too high.
It’s important to evaluate the man-hours and manpower needed to implement a full in-house solution.
Remember this includes throughout the lifecycle of the application:
- Changes, and support during use
If you’re planning to do it in-house, take advantage of online forums such as www.twain.org. The TWAIN forum, Stack Overflow, and MSDN provide a plethora of online technical information.
3. Building or Buying Relevant Components
Once you understand such requirements you can proceed with considering building or buying the relevant components.
For example, with barcodes, there are some open source barcode libraries available. A popular one is ZXing, also known as “Zebra Crossing”.
You might instead opt for a third-party barcode software development kit (SDK). Commercial SDKs typically provide:
- Better barcode processing results
- Wider barcode type support
- Better customer service
Obviously, they can also save on development time and costs versus researching, understanding, identifying, creating and supporting an API you built in-house.
It can really defocus an organization short term and long term when developing a barcode reader as part of a complete system.
There are immense short-term development efforts and costs that can come with it.
Long term, there are technical support staff, time and costs issues that can mount.
If you want to take advantage of third-party SDKs for the scan, barcode, and OCR components, be sure to do your online research. These pre-built solutions can turn months or year-long projects into days. An SDK has some up-front costs, but they do significantly save on time and other costs that usually amount to more than an SDK costs, particularly in the long run.
We’ve touched upon the many technical considerations, including the device types to be used.
- You’ll need to start with a feature list for an in-house EHR solution
- Assemble a team from the different departments that will be core users
- In doing so, you’ll come up with a feature and capabilities list
- Thus, various technical requirements will come forward
In your research of an EHR solution or SDKs ensure they deliver the features, customization and technical support levels you require.
Getting EHR Satisfaction
As is the case with almost any software development or adoption, analysis and testing of the application are also important.
You want to try to uncover potential problems.
It helps to get different departments involved such as doctors, pharmacists, nurses, and IT during pre and post development of the solution. Their involvement should include pre and post-development or adoption of the solution.
One basic testing point is to ensure platform compatibility, which means properly determining that the application supports all the required user platforms and devices.
This might include:
- Flatbed scanners
For other hardware, you obviously want to ensure barcode scanner compatibility.
This means you want to ensure your barcode scanner devices are able to read the barcode images and properly pass the data to your EHR system.
Finally, you must test data transfer workflows.
This includes making sure the data from barcodes can be successfully added/updated to an EHR database.
If you’re planning to build a solution in-house or if you’re an EHR system provider, consider taking advantage of as many SDKs as possible.
They will help reduce costs, save you time, and save you headaches.
- Imaging SDKs can help with just about any document capture requirements.
- Barcode reader SDK can fulfill barcode reader technology needs.
- OCR SDK can help ensure information on paper-based assets are fully leveraged.
Each SDK can turn months or year-long projects into just days. Up-front costs are nominal compared to building a solution yourself. Long-term cost savings are even more beneficial. Also, often, SDKs will be loaded with features beyond your scope of needs allowing you room to expand as needed.
Don’t forget too that a good SDK provider supports their solution expeditiously and for the long run.
To ensure this, you must research SDKs and their providers to confirm they deliver the features, customization and technical support levels you require.