[License-review] Request for approval by license steward: Tidepool Open Access to Health Data Software License
Tzeng, Nigel H.
Nigel.Tzeng at jhuapl.edu
Mon Oct 7 16:38:33 UTC 2013
Regarding UCFS concerns I would suggest that you consider the patent
clause in ECL v2. It was written specifically to address the patent
concerns of large research universities.
There isn't provision for not releasing data in the middle of a
trial/study. You seem to have a very device centric focus but there are
many forms of medical (or scientific) software that would benefit from an
Open Data requirement so long as you could still conduct research. I can
imagine various scenarios where you wouldn't want the test subject to have
access to the experimental/device data until after the study is complete.
Also an anonymous data provision for reasearch would also be useful or
your protocol may not get IRB approval. You cannot make data anonymous by
stripping identifiers from the data after the fact. The data must have no
identifiers at every (visible) point in time (at least for our IRB).
It is reasonable to require that the data owner be able to download their
data with or without any identifiers from the device in an anonymous study
during the session it is collected. But then you cannot ever provide the
data again because you (as the researcher) don't know who's data is who's.
That fails your three year data access requirement.
You could reasonably require that all collected data for that participant
be provided to the participant when the study is complete (i.e.
published/distributed, when the grant runs out, when the longitudinal
study period is complete, etc) or the participant withdraws from the
study. This also fails your three year data access requirement.
Frankly, the open data requirement should be considered fully fulfilled
the moment you hand the data over to the "data owner" just like it does
for open source. If I create a GPL program and I hand over the source at
the same time as the binary I don't need to be able to ever do that again.
The last time I had a MRI I think they handed me both films and a DVD.
>From my perspective as a "data owner" that's fully compliant from an Open
Data perspective. I'm sure they keep copies but I don't know for how
long. It also strikes me as reasonable if they charge me for another copy
after the first one if I lose my copy.
Also with respect to your faq it states:
"This license applies to anyone who wishes to incorporate Tidepool
software or UI designs in any way, for example in a device, in a mobile
app, or in a web-based service or a PC/Mac/Linux desktop application."
I do not believe that your UI design (i.e. look and feel) is protected.
Your implementation is protected via copyright.
Your license does not allow the device/system to delete the data before
the three year period even if the data owner requests this and there is no
other prohibition from deletion. The "data owner" should be able to waive
their rights if desired.
While disk space may be "cheap" (depending on the volume of data being
generated) the costs of handling large amounts of HIPPA data is not
necessarily "cheap" for a smaller office. Also who has the archival
requirement? The doctor? The testing facility? Both? A MRI image is
only 5-6 MB but a large series could contain many images. Do you also
need to provide/store both the raw k-space data or just the final image?
Is all the raw data required to meet "data specific to understanding the
operation, safety or efficacy of a device or service that accompanies, is
assistive in understanding, or generates such data"? If I oversample is
every sample required or only the computed mean? What if my device isn't
capable of storing every sample but only the running mean or final
averaged result for a collection?
Also downloadable ascii, CSV or Excel file is very much machine readable
as long as it is documented. I do this all the time. It is when there is
undocumented and/or deliberately obsfuscated proprietary binary files that
I cannot pull data off a device in an automated fashion.
Obligatory Disclaimer: I am NOT speaking for JHU but as an individual OSI
More information about the License-review