Not all ePCRs are created equal, and the same is true for ALS monitors in terms of how their data can be used by ePCR systems. The three major ALS monitor/defibrillator vendors in the North American EMS market each have a data integration kit, sometimes called a Software Developers Kit (SDK) or an Application Programming Interface (API). Even if you’re not a programmer, you should take a close look at these data integration kits because your ePCR developer is going to have to work with it and the company that made it.

Openness: How open is the monitor company with their data? It’s one thing to have an SDK, but does the company promote third-party solutions or does it push you to use its software offerings? Companies that are more open with their data are more likely to fit your individual workflow and organizational needs.

Data transfer: How easy is it to wirelessly move data from the monitor to the ePCR tablet? Monitor/defibrillator vendors have Bluetooth options, but ask around to see whose is fastest and most reliable. What about pairing devices? Even in the rare cases when tablets and ALS defibs are kept with the same apparatus, sometimes they need to talk to new devices. This should be quick and painless and not require giving out the configuration password. How many devices can be paired? What if a new device needs to be added and the list is already full?

Downloads: How long does an average case (20 minutes of patient interaction) take to move via Bluetooth? Is it a minute or less? Some vendors provide IP-based (Ethernet) connections for fast individual or bulk file downloading. This is noteworthy because if you’re recording CPR data or audio—as many of the Resuscitation Outcomes Consortium sites do—then you’re collecting a large amount of data and will need faster download methods.

True Open Data Integration: Some monitors let you download data to your ePCR, but to look at clinical data, the ePCR has to launch the monitor vendor’s proprietary application to view the data. With modern SDKs, the clinical data can be viewed and printed from within the ePCR. This way, users don’t have to deal with two applications running and there’s less finger pointing if something goes wrong.

Latest development tools: Most applications are now developed using the latest Microsoft development tools, such as C# and .NET Framework. This reduces development time with plug-and-play integration code and also makes it easier to troubleshoot problems. How old is the code in your ALS monitor vendor’s SDK? Is it written using these tools? Does it provide sample code and test data to facilitate modeling?

Proof’s in the pudding: Does the monitor vendor use its own SDK for its own data access? Some vendors will put out an SDK, but it won’t have the same level of data they themselves have access to with their own data management offerings. This means that the SDK partners aren’t really partners; they’re only getting some of the data some of the time.

The connection between a medical device and an ePCR is like any other relationship. You have to be committed to making it work and continually invest in it. Next time you’re in the market for ALS monitors, look at the data integration kit and philosophy and you’ll get a glimpse of the future of that relationship.

Disclosure: The author has reported no conflicts of interest with the sponsors of this supplement.