Four EHR Technical Requirements [eBook series 3 of 6]

Feb 13, 2020

Technical Considerations

There are clear time and cost savings benefits in using scanning, barcodes, and OCR. There is also the benefit of familiarity – they are technologies that users know and are comfortable with. But, there are various things to consider when choosing a solution for each.

As always, there are technical hurdles your team must overcome. Start with drafting the detailed platform requirements of the EHR system you use or plan to use. This includes any desktop, web or mobile application, or a combination of any of these.

Download your eBook

Desktop vs. Web

When scanning documents, a distributed capture, and scanner setup can accelerate image acquisition. A common setup involves a client/server architecture.

Users capture data from different terminals and save the data to the database on a central server. On the client side, a desktop-based EHR application can work.

However, a web-based EHR application provides different flexibility, such as more seamless mobile captures. Done correctly, and using common industry standards, developers can ensure users accomplish document captures from common web browsers on almost any device.

Support for Mobile

A web-based EHR approach can more easily allow for mobile captures from devices such as smartphones and tablets. It’s ideal for EHR application designers to start with support for at least iOS 9 and Android 4.4 as basic system requirements. This is primarily because, according to Apteligent DATA, 98.5% of devices are using iOS 9.3 or above. For Android, 95% of devices are using Android 4.4 and above. Thus, you stand to have the greatest support for most devices from this starting point.

Support for Multi-Type Documents

As mentioned, medical documents nowadays are often a mix of digital and paper. For example, dictation, lab, and x-ray results might be available electronically. But, progress notes, provider information, graphic sheets, and doctor’s order might be on paper. Thus, it’s important to utilize a document capture solution that can integrate both.

There are common digital document formats that are must to cover. These include PDF, TIFF, and JPEG so users can seamlessly load image files or be able to view the images in standardized viewers, such as a browser.

Support for Webcam and Scanner

Webcams can be important too. For example, a patient at home could snap a picture of their ID with a webcam to process into your application. Then the types of application programming interfaces (API) to be supported can be sorted out. An API is necessary to enable software component interactions with each other. This includes how it accesses a database or specific hardware.

For example, you could use the TWAIN standard to interact with scanners and capture documents like patient records, prescriptions, etc. It is supported in operating systems such as Microsoft Windows, Mac OS X, and Linux. TWAIN is designed primarily for C/C++ development.

You might instead opt for the WIA standard. WIA is a Microsoft driver model and API for Microsoft Windows, which has been around since the days of Windows Me. In Windows Me, it enabled graphics software to communicate with imaging hardware such as scanners, digital cameras, and digital video equipment. Since that release in 2000, Microsoft has steadily added features, including OLE integration. However, since the release of Windows Vista, WIA has been more targeted towards scanners.

Another option is DirectShow to interact with webcams to capture photos and store in your central database. DirectShow is a multimedia framework and API produced by Microsoft. It can be used to perform various operations with media files or media streams. DirectShow is a replacement for Video for Windows (VFW), also known as Video Compressions Manager (VCM). Most webcams, including FireWire cameras, support the main interfaces of DirectShow. But, you should note that USB Video Class (UVC) cameras have the most market share.

After determining the APIs to use, you then have to choose whether to create the application from scratch – to create all the code yourself.

Or, you could instead take advantage of third-party pre-built components offered in software development kits (SDK) which save a lot of time since you don’t need to learn the intricacies of coding from scratch, related standards, and APIs to implement.