[HN Gopher] Show HN: OpenDataCapture an electronic data capture ...
___________________________________________________________________
Show HN: OpenDataCapture an electronic data capture platform for
data collection
Hi 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 [4]
https://playground.opendatacapture.org [5]
https://demo.opendatacapture.org
Author : gdevenyi
Score : 39 points
Date : 2024-07-22 17:43 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| flyinchicken wrote:
| 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.
| taro549 wrote:
| The instrument playground is really cool, though I'm not sure who
| the audience for that is
| gdevenyi wrote:
| 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.
| joshunrau wrote:
| 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).
| mxschll wrote:
| 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?
| gdevenyi wrote:
| > 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.
| adolph wrote:
| 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/
| ronyba wrote:
| its slow to load, also considering this is hospital data is this
| HIPPA and GDPR compliant?
| joshunrau wrote:
| 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).
___________________________________________________________________
(page generated 2024-07-22 23:05 UTC)