[Openid-specs-heart] What is Health Data?

Mon Jan 23 13:05:48 UTC 2017

I agree with Adrian as well. Medical Devices tend to be given excuse out of
security, when they should not. When security and Privacy are designed into
the product, they fold in seamlessly.  I add my dozen years of experience
with medical device to Adrian in support of being inclusive.

The only exception, which can be addressed in designed, is robustness in
the face of degraded infrastructure. Think about a mega natural disaster
that takes out  major infrastructure in a region (e.g. Katrina). Medical
devices sometimes include in their scope the claim to continue to provide
their medical device claimed benefit even when the network (e.g.,  AS) are
missing. Such as a bedside lifesign monitor, or ventilator breathing for
the patient.  It is possible for non-medical device to do this as well, but
is less likely that a non-medical device would determine that the
functionality it brings is more important than security.  This trade-off is
(should be) careful risk management. This kind of trade-off should only be
seen as acceptable when the functionality is life-sustaining or
life-critical. Yes, it applies to many things used in the Emergency Room,
but is not a normal Emergency Room situation as that is... normal for an
emergency room... This is a small fragment of the market. Too often this
kind of use-case is used as excuse for poor design.

John

John Moehrke
Principal Engineering Architect: Standards - Interoperability, Privacy, and
Security
CyberPrivacy – Enabling authorized communications while respecting Privacy
M +1 920-564-2067
JohnMoehrke at gmail.com
https://www.linkedin.com/in/johnmoehrke
https://healthcaresecprivacy.blogspot.com
"Quis custodiet ipsos custodes?" ("Who watches the watchers?")

On Fri, Jan 20, 2017 at 3:04 PM, Adrian Gropper <agropper at healthurl.com>
wrote:

> Thanks Glen and Aaron for bringing this up, but I think it will make no
> difference to HEART. (I have a lot of experience developing numerous
> FDA-regulated medical devices as well as unregulated health records.)
> Implants, wearables, home monitors will all need security regardless of
> whether they are regulated by FTC or FDA or prescribed by a physician.
> Off-hand, I can't think of a single instance where the regulatory
> environment will impact HEART access authorization (resource architecture,
> scope design, best practices).
>
> The one obvious place where regulatory issues come in is auditing. Some
> applications have stringent data retention requirements, possibly including
> non-repudiable signatures. There could also be mandatory reporting to state
> agencies. It's nice to keep this in mind as we do HEART because if we fail
> to support this kind of capability then the APIs we attach to will need
> separate access authorization systems for regulated cases.
>
> Simply put, I hope that HEART will presume it's being used in a regulated
> environment so that the same API is available for patient-directed exchange
> regardless of whether the resource server or the client is being used by a
> physician, a family caregiver, or a machine.
>
> Adrian
>
>
>
> On Fri, Jan 20, 2017 at 2:38 PM, Aaron Seib <aaron.seib at nate-trust.org>
> wrote:
>
>> I think 21st Century Cures established one line to consider with regards
>> to what is in scope for the FDA to regulate.
>>
>>
>>
>> TITLE III—DEVELOPMENT
>>
>> Sec. 3060. Clarifying Medical Software Regulation (pg. 257-264)
>>
>> ·        The term ‘device’ shall be excluded from regulation by the FDA
>> if the software function of the device is intended for:
>>
>> o   Such purposes as administrative support of a health care facility,
>> including the processing and maintenance of financial records, claims or
>> billing information, appointment schedules, business analytics, population
>> health management, and laboratory workflow, among others;
>>
>> o   Maintaining or encouraging a healthy lifestyle, unrelated to
>> diagnosis, cure, mitigation, prevention, or treatment of a disease or
>> condition.
>>
>> o   Electronic patient records, including patient-provided information,
>> to the extent that such records are intended to transfer, store, convert
>> formats, or display the equivalent of a paper medical chart, as long as:
>>
>> §  The records were created, stored, transferred, or reviewed by health
>> care professionals, or by individuals working under supervision of such
>> professionals
>>
>> §  Such records are certified under section 3001(c)(5) of the Public
>> Health Service Act
>>
>> §  It doesn’t include software intended to interpret or analyze patient
>> records, including medical image data
>>
>> o   Transferring, storing, converting formats, or displaying clinical
>> laboratory tests or other device data results; findings by a health care
>> professional with respect to such data and results, general information
>> about such findings, and general background information about such
>> laboratory test or other device, unless such function is intended to
>> interpret or analyze clinical laboratory test or other device data,
>> results, and findings;
>>
>> o   (Unless) the Software function is intended to acquire, process, or
>> analyze medical images or a signal from an in vitro diagnostic device or a
>> pattern or signal from a signal acquisition system for the purpose of:
>>
>> §  Displaying, analyzing, or printing medical information about a
>> patient or other medical information
>>
>> §  Supporting or providing recommendations to a health care professional
>> about prevention, diagnosis, or treatment of a disease or condition.
>>
>> §  Enabling health care professionals to independently review the basis
>> for such recommendations that software presents so that it is not the
>> intent that health care professional rely primarily on any of such
>> recommendations to make a clinical diagnosis or treatment decision
>> regarding an individual patient.
>>
>>
>>
>> You probably want to look at the section in its entirety for more details.
>>
>>
>>
>> Is there any useful criteria for your purposes that you can derive from
>> this?
>>
>>
>>
>> Aaron Seib, CEO
>>
>> @CaptBlueButton
>>
>>  (o) 301-540-2311 <(301)%20540-2311>
>>
>> (m) 301-326-6843 <(301)%20326-6843>
>>
>> <http://nate-trust.org>
>>
>>
>>
>> *From:* Openid-specs-heart [mailto:openid-specs-heart-bou
>> nces at lists.openid.net <openid-specs-heart-bounces at lists.openid.net>] *On
>> Behalf Of *Glen Marshall [SRS]
>> *Sent:* Friday, January 20, 2017 2:10 PM
>> *To:* HEART List
>> *Subject:* [Openid-specs-heart] What is Health Data?
>>
>>
>>
>> In our discussion this past week we did not drill-down on use cases about
>> sharing data from personal health data collection devices, e.g., Fitbit or
>> environmental activity monitors, or medically prescribed devices, e.g.,
>> Holter monitors.  In the case of medically prescribed monitors, the data
>> they collect is clearly health data.  On the other hand, data on personal
>> wearable devices only becomes medical data when it is shared for that
>> purpose.  Activity monitors are in-between, as they can be used in an
>> non-medical assisted living setting or in medical long term care.
>>
>>
>>
>> Where do we set the boundary between health data and other data?  What do
>> we do when that boundary shifts, as it has for wearable devices over the
>> last couple of decades?  What is the mechanism for granting permission for
>> medical use when such devices lack a UX?  Are there existing policies for
>> this, i.e., is it in scope for HEART, or should we make recommendations for
>> policy development?
>>
>>
>> ------------------------------
>>
>> Glen F. Marshall
>> Consultant
>> Security Risk Solutions, Inc.
>> 698 Fishermans Bend
>> Mount Pleasant, SC 29464
>> Tel: (610) 644-2452
>> Mobile: (610) 613-3084
>> gfm at securityrs.com
>> www.SecurityRiskSolutions.com
>>
>>
>>
>> _______________________________________________
>> Openid-specs-heart mailing list
>> Openid-specs-heart at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>>
>>
>
>
> --
>
> Adrian Gropper MD
>
> PROTECT YOUR FUTURE - RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: http://patientprivacyrights.org/donate-2/
>
> _______________________________________________
> Openid-specs-heart mailing list
> Openid-specs-heart at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-heart
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20170123/5228f4a1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 3204 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20170123/5228f4a1/attachment.jpg>