Show HN: OpenDataCapture an electronic data capture platform for data collection
github.comHi HN,
We're the Douglas Neuroinformatics Platform[1], and we've been working on Open Data Capture, a web-based electronic data capture (EDC) platform for continuous clinical and research data collection. You can use it to administer instruments (like forms and interactive tasks) either in-person or remotely.
The platform is based on a fundamentally longitudinal data model. Unlike other EDC platforms, which are centered around the concept of a study with rigid timepoints, Open Data Capture is designed for continuous data capture. Data is associated with a given session, which includes metadata such as date, time, and mode (i.e., in-person or remote).
We've designed the system around the core restriction that many hospital institutions demand that data remain on-premise, while clinician-researchers often want to evaluate clients outside the institution with research questions. This has resulted in our innovative gateway concept, where assigned remote assessments are pushed onto an internet accessible service, and responses are encrypted in-place with HPKE[2] until the backend pulls them into the backend database. This makes the deployment firewall-friendly provided you can launch a minimal VPS or VM host somewhere globally accessible.
We're also a big fan of making things easy to deploy, so we supply a docker-compose stack which can bring up a demo instance easily to run locally.
The platform is free, open source, and written in TypeScript, with a NoSQL database underneath. Users can write instruments in TypeScript using a type-safe declarative form system (with native i18n support built in) or wrap and integrate completely arbitrary interactive tasks written in JavaScript (with optional support for TypeScript and JSX). Under the hood, this is based on dynamic imports and native ESM. There’s a browser-based IDE (the Instrument Playground) with live reloading and full Intellisense where you can try creating your own instruments.
We have a local deployment going live at our institution and appropriately-licensed (free) instruments we're deploying here will be integrated directly into the codebase.
Our future plans include expanding our instrument types to allow for binary data storage with an s3-like backend, and with abstractions for data types, like actigraphy, and MRI.
Check it out on GitHub[3], try the Instrument Playground[4], or see the Live Demo[5].
Would love to hear everybody’s thoughts!
Links:
[1] https://github.com/DouglasNeuroInformatics/
@gdevenyi @joshunrau
[2] https://datatracker.ietf.org/doc/rfc9180/
[3] https://github.com/DouglasNeuroInformatics/OpenDataCapture
Hi! We are interested in similar problems.
I worked on a new idea for EMR at UH Cancer Center called Pau (https://github.com/breck7/pau). It's now encompassed as a tiny part of a larger effort called Scroll (https://scroll.pub/). You might be interested in learning about ScrollSets (https://breckyunits.com/scrollsets.html)
Happy to chat if you want some feedback (email is breck7@gmail.com)
P.S. I love your focus on the concept of "instruments". Great word choice. Bullseye concept--well done!
I like the gateway concept as an alternative to opening the firewall. Are there any plans to add FHIR compatibility, for integrating with other FHIR systems?
> I like the gateway concept as an alternative to opening the firewall.
Cheers, it was a real revelation when we worked out how to do it!
> Are there any plans to add FHIR compatibility, for integrating with other FHIR systems?
We've definitely looked at such standards and systems but they seem to be targeted towards EHR data exchange and we are explicitly not an EHR. Our target is structuring research and research clinical data. The summary tool at the end of each instrument is designed to produce reports which can be fed into classic digital paper style EHRs where real clinical record keeping is required.
Not utilizing FHIR b/c you think EHRs will (a) consume your proprietary reports, and (b) be a downstream data system seems a big footgun. Additionally, while FHIR isn’t quite right for many research use cases, there are ongoing efforts such as mCODE [0], that use FHIR as a base because it is not proprietary and highly specified.
Maybe your EDC has other awesome characteristics. Based on the interest I’ve seen the FHIR ingestion of REDCap [1] is a winner for research nurse efficiency.
0. https://build.fhir.org/ig/HL7/fhir-mCODE-ig/
1. https://www.project-redcap.org/
Right now, we're building first to address the needs of our institution, there's no FHIR enabled software there, and the clinicians make a direct request to generate reports for ingestion into their existing EHR system, so we oblige.
Interoperability is on our roadmap.
Meanwhile, we don't consider RedCap a competitor, the old-school LAMP stack is showing its age, and its "closed source" by most interpretations, including a hostile position on external developers.
We welcome contributions to accelerate FHIR support.
Oh, I forgot another aspect of FHIR, SMART on FHIR EHR integrations so the clinical research folks can optionally go straight in from the EHR.
I can’t say I disagree with your assessment of REDCap’s base tech except that it works sufficiently well to have pretty broad adoption, which can be approximated by the number of local endpoints exposed in their EHR-internal client record. A single institution project is certainly not a competitor and I wish y’all good fortune in ever getting beyond your patrons.
very nice work! at Malmo University we maintain an open source mobile platform for data capture in clinical research: https://mobistudy.org/
Our focus is more on sensors data rather than questionnaires, although we include those too.
Get in touch if you want to collaborate: dario.salvi at mau.se !
The instrument playground is really cool, though I’m not sure who the audience for that is
Thanks! I had a lot of fun building it.
Basically, the target audience is people who have some experience programming, but who are not actual developers and have no experience in JavaScript land. There are a lot of graduate students at our institution that fit this description (e.g., some experience hacking together scripts in Python). The goal is for semi-technical users to be able to create forms in a JSON-like way, and for more experienced users to be able to implement whatever they can think of.
Also, I wanted to extract our build tooling into something that people can use without understanding anything about module bundling or needing to use a CLI (which the target users often find scary).
Right now, our team to build and test instruments before importing them into the platform or committing them to the main source.
In general the admin team who would be supporting the deployment of the software.
its slow to load, also considering this is hospital data is this HIPPA and GDPR compliant?
> its slow to load
We're using free cloud resources which also host our internal collaboration infra, its definitely underpowered.
> considering this is hospital data
To be clear, our first target audience is research data collection, which is consented, so that's not immediately an issue, however we don't store Personally Identifying Data (PID) in the current design, instead hashing all ID data. Our institution and local laws are very happy with that. We aim for compliance with other statutes going forward.
We are a research-funded group in Canada, so GDPR and HIPPA compliance was not something we initially considered. Going forward, this is something that we will be prioritizing, since we are looking at potentially offering this as a cloud service (separate from our research team).
The Open Data Capture platform has a nice and modern interface. Its longitudinal data model is a useful feature for continuous clinical and research data collection, offering more flexibility compared to other EDC platforms tied to rigid study time points. I also found the instrument playground easy to use.