Friday, September 8, 2017

Remedial FHIR Consent Enforcement

I have been working with some of the teams wanting to do something with Privacy Consent and are coming to the FHIR Connectathon in San Diego. Here is a few stepping stones that I think are educational to move from zero to a reasonable set of Consent possibilities. Basic Consent is a necessary and powerful step:

Pre-conditions:

  1. Some form of Business Access Control are already in place to support basics of separating the kinds of things that various users (roles) are allowed to do; like Clinicians, or administrative staff, or billing staff, or cleaning staff, or dietary staff, etc. For example: Role Based Access Control (RBAC), or Attribute Based Access Control (ABAC) . This layer is responsible for separating those users that are allowed to Order drugs or procedures, vs those that are allowed to update clinical information, vs those that are given access to billing information, vs etc... An example of this is -- SMART-on-FHIR. 
  2. There is some Privacy Policy written: I will give a few for example purposes only. These are not complete, or comprehensive. They are defined well enough to illuminate the various stepping stones that I will outline below.
    * Explicit Consent -- if no consent is on file, then no data is shared outside the organization.
    * OPT-IN -- Patient has positively given consent to share without restrictions
    * OPT-IN with named organizations allowed access
    * OPT-IN with identified time/date range within which no data authored can be shared
    So, any Consent in the system must be from one of these patterns. Mixing of patterns, or going beyond these patterns is simply not allowed by the consent gathering application.
    **** Sorry, I have to use "OPT-IN" and "OPT-OUT", against my rule... but I do have them explained.
  3.  There is some consent gathering application that presents these Privacy Policies to Patients, and records the Consent ceremony as a FHIR Consent resource. I am not going to try to describe this ceremony. The user experience is very critical. The Patient must be well educated on the ramifications of their choices. I like the idea in GDPR where the consent rules presented to the Individual must be in human language terms that are specific to that person's language abilities. I am not short-circuiting this, but rather wanting to focus on the enforcement side.
    *** Note that if the patient changes their mind, this application handles this. Leaving only ONE active Consent resource. Thus there is no conflicts to resolve in real-time. If the patient wants to OPT-OUT after being OPT-IN; then a few solutions could happen. The existing record be updated to become Consent.status=rejected. Better for record keeping if a new Consent record is created with an OPT-OUT policy...

YES, I know that we all want more complex consents, we will get there. But for now we must get started. Stepping stones are important to the journey. Stepping stones are useful, but one does not stand on them for very long.

Some past articles to this point

Consent Enforcement Models

There are two major models today, very different.

Privacy Access Control decision engine

Privacy Access Control decision engine using OAuth. In this model, one offloads the Access Control decision to an OAuth authorization service. This is the model that HEART is focused on. Another example has been shown as "Cascading OAuth". The idea is that there is some OAuth authority (or a set of them) that focus on giving Access Control decisions purely along Privacy Consent lines. If this is 'cascaded' with the business OAuth Access Control decisions; then one has the combination of both.. I am not going to further explain this model in this blog article.

One could have an Access Control engine that is based on XACML...

In both of these solutions, the rules of the Patient specific Consent are not in any FHIR 'Consent' resource form. These solutions take care of steps 1-4. They only expose a 'decision' endpoint.

As such, their decision endpoint must be able to return complex obligations. PERMIT, but not to organization ABC, not the data authored during XYZ, etc... These in OAuth would be done with "Scopes", in XACML would be done with 'Obligations'. Which ever one uses, this is complex... and I would argue this is the same complexity one sees in the FHIR Consent resource today.

Interaction between FHIR Consent resource and Privacy Access Control decision engine

In both of these solutions, there might be a FHIR Consent that is simply there to indicate the endpoint of the Privacy Access Control service. This might be quite empowering. The Consent would not indicate anything other than the specific service to use. Thus enabling the Patient to choose from various Privacy Access Control services to use. The FHIR Consent resource would not indicate in any way what their Privacy rules might be.

I should model this.. and I might do it this week... but I want to focus on a solution that leverages the Consent resource... and this Privacy Access Control decision service solution hardly uses the Consent resource at all.

The FHIR Consent way:

Reminder we are working on Stepping Stones, and starting simple
* Explicit Consent -- if no consent is on file, then no data is shared outside the organization.
* OPT-IN -- Patient has positively given consent to share without restrictions
* OPT-IN with named organizations allowed access
* OPT-IN with identified time/date range within which no data authored can be shared

Lets first just work out the first two: No active consent on file, vs opt-in.

In the FHIR specification we already have examples of these:

A system can using FHIR query (RESTful) to determine if there is any Consent on file for a given patient. For the example below we look for if there is a OPT-IN consent for patient 'f001'

GET [base]/Consent?patient=f001&status=active&category=http://hl7.org/fhir/v3/ActCode#OPTIN
(((Note that one can't query on policyRule, so I propose either that be added, or that the OPTIN code goes into category. I seem to recall committee discussions that put it into category)))

If this above query returns ZERO result, then there is no OPTIN consent on file. Thus no access is granted. DONE
If there is a Consent, then we need to look to see if there are any Consent.provisions. If there are none, then we grant Privacy PERMIT access. DONE

The second stepping stone is to enforce the provisions.

Each provision will have a provision.type of either PERMIT or DENY. This means that if the constraints in the provision are matched, then the provision.type (PERMIT vs DENY) is to be enforced.

We have an example which is an OPTIN but denying access to a named organization.

Well, looking at this example, I see it is missing some critical parts that I just said would be there. The one provision this example has in it is that it is specific to an Organization named 'f001'. From the name of the example, it is clear this provision should have a .type="deny".

This kind of a provision can be enforced on the REQUEST, as that organisation is denied any access because of a Privacy Consent directive.

Date Range:

The Date Range provision is something that is much harder to enforce, as it really must look at the results that are about to be returned, and filter out any data that was authored within the given date range. I am not going to go deeper right now, but am pointing out that sometimes provisions can be enforced on the REQUEST side, denying a request or allowing a request with no further action. Some provisions require further work be done on the RESPONSE side.

Other articles:
No comments:

Friday, September 1, 2017

MDS2 -- Revision Comment Opportunity

Updated: They moved the deadline for signup to September 15th, 2017

I have been involved in the original creation of the MDS2 (Manufacture Disclosure Statement for Medical Device Security).  This was back in 2004, before I was blogging...  The first revision was a major change to align with IEC 80001 - Risk Assessment to be used when putting a Medical Device onto a Network in 2010. The second revision to improve usability Major upgrade to MDS2 to align with IEC-80001 in 2013

It is being revised again, and there is a call for participation. Hurry, there is only a week to signup -- September 8th deadline.



This is intended to be a Security Disclosure statement from a Medical Device (any health software too) to someone purchasing. It is intended to explain the security capability, environmental expectations, and residual risk that would need to be managed by the purchasing organization. Security is a critical collaboration between the manufacture and the user of any system. This form is intended to enable this collaboration.

The Medical Imaging & Technology Alliance (MITA) is announcing an effort to revise the existing HIMSS/NEMA Standard HN1-2013 and develop it as an American National Standard. This standard consists of the Manufacturer Disclosure Statement for Medical Device Security (MDS2) form and related instructions how to complete the form. The intent of the MDS2 form is to supply healthcare providers with important information to assist them in assessing the vulnerability and risks associated with protecting private data transmitted or maintained by medical devices and systems.

If you are interested in participating in the development of this standard, please fill out the information requested below and return to Peter Weems (pweems@medicalimaging.org) no later than August 31, 2017 September 8, 2017.
  • Name
  • Organization Represented
  • Brief Description of Organization
  • Email Address
  • Telephone Number
  • Interest Category
  • Interest Category Descriptions

General Interest—Organization or individual that has an interest in the use of equipment included in the scope of this Standard, but neither produces nor uses it directly.

Government—Government agency or department that has an interest in the use of equipment included in the scope of this Standard. Please note that a government agency or department that uses this equipment should select the USER category.

Insurance--Insurance agency or department that has an interest in the use of equipment included in the scope of this Standard. Please note that an insurance agency or department that uses this equipment should select the USER category.

Producer—Manufacturer of equipment included in the scope of this Standard.

Testing Laboratory—Organization that tests equipment included in the scope of this Standard to established specifications.

Trade Association—Trade Association or society that represents the interests of manufacturers or users of equipment included in the scope of this Standard.

User—Organization (company, association, government agency, individual) that uses equipment included in the scope of this Standard.

User-consumer—Where the standards activity in question deals with a consumer product, such as lawn mowers or aerosol sprays, an appropriate consumer participant’s view is considered to be synonymous with that of the individual user – a person using goods and services rather than producing or selling them.

User-industrial—Where the standards activity in question deals with an industrial product, such as steel or insulation used in transformers, an appropriate user participant is the industrial user of the product.

User-government—Where the standards activity in question is likely to result in a standard that may become the basis for government agency procurement, an appropriate user participant is the representative of that government agency.

User-labor—Where the standards activity in question deals with subjects of special interest to the American worker, such as products used in the workplace, an appropriate user participant is a representative of labor.
1 comment:

Thursday, August 31, 2017

IHE IT Infrastructure Planning co-chair

I finally got caught... I have been elected co-chair of the IHE IT Infrastructure - Planning Committee.

I have been 'co-chair from behind' for too long, I knew I would eventually get caught. I tried to be elected co-chair in IHE once before, but had a campaign against me... by my peers at my employer at the time (GE Healthcare)...

First test will be the face-to-face meeting for New Work Item proposals October 16-17....

YOU have submitted your new work item proposal, right? Better hurry, the deadline is just 22 days away.


This is a friendly reminder that the IHE annual planning cycle has begun! The IT Infrastructure (ITI) and Patient Care Coordination (PCC) Domains are soliciting work item proposals for the 2017 Publication Cycle. The Call for Proposals  concludes September 22, 2017. This e-mail provides a brief overview the Call for Proposal process. For detailed information visit the IHE Call for Proposals Wiki site.  Are you new to the IHE International Call for Proposal Process?·       Watch the online webinar to learn more about submitting a proposal and the evaluation process. Ready to participate in the Call for Proposals?
Interested parties are invited to submit a brief proposal (form attached) for new IHE Profiles and/or White Papers to be considered for development in the new Publication Cycle. Proposals should be entered using the attached Brief Profile Proposal template.  They should address the following:
  1. What is the problem and how does it look in practice?  (Describe the use case)
  1. How should things look in practice if it were fixed?
  1. What specific standards could be used to solve the problem, if known?
  1. If possible, give some indication of the business case for solving the problem (e.g., quantify the cost).
It is strongly recommended that the proposal include the name of an editor for the proposal should it be selected for development.
Email your completed brief IHE Proposal template to the corresponding email address listed below before September 22, 2017 at 11:59pm CDT. Proposal templates can also be found online at: ftp://ftp.ihe.net/DocumentPublication/DocumentTemplates/Profile%20Proposal-Brief%20and%20Detailed/IHE_Profile_Proposal_Template-Brief.docx·       ITI Domain Proposals: Daniel Berezeanu at: daniel.b...@readycomputing.com, ITI Planning Chair·       PCC Domain Proposals: Amit Popat at: Am...@epic.com, PCC Planning Chair What happens if my proposal is selected?The IHE ITI and PCC Planning Committee will review each Brief Proposal and select a "short list" of proposals for further consideration.  Detailed Profile Proposals are sent to the IHE ITI or PCC Technical Committee for evaluation and returned to the Planning Committee for a final vote.  Please visit the Wiki for detailed information about the IHE Call for Proposals.    Questions or Comments? 

No comments:

Tuesday, August 29, 2017

IHE on FHIR ... STU3

Integrating the Healthcare Enterprise (IHE) has been busy creating Profiles that leverage the new and exciting FHIR specification. The concept of Profiling in IHE has been around for just about 20 years. The concept of Profiling is not IHE invention, I first encountered it back in the 1980s with the original set of Internet Protocols. See the IHE FAQ for some nice description of what/who IHE is.

IHE publishes their profiles on http://www.ihe.net

IHE subset of Profile on FHIR can be found on the IHE wiki FHIR list

An IHE Profile is equivalent to a FHIR Implementation Guide. They take a specific use-case, define Actors, define Transactions, and define Options; From this a set of interoperability constraints are defined for each Actor within that Profile.

These constraints can be coded as a FHIR set of conformance resources. For now, if a FHIR Conformance resource is available it will be published on the IHE FTP site in the Implementation Material. There are efforts within IHE to modernize beyond an FTP site, and to provide more complete FHIR conformance publication on a FHIR Profile Registry.

IT Infrastructure (ITI) domain

The IT Infrastructure profiles are published on the IHE Technical Framework web site and described on the IHE Wiki

Companion

Patient Care Coordination (PCC) domain


Patient Care Coordination profiles are published on the IHE Technical Framework, and described on the IHE wiki.

Radiology Imaging (RAD) domain

Radiology Imaging profiles are published on the IHE Technical Framework, and described on the IHE wiki.

Quality, Research, and Public Health (QRPH) domain

  • Mobile Retrieve Form for Data Capture (mRFD) describes the exchange of context data to allow a seamless form launch with supporting clinical context
  • Vital Records Death Reporting (VRDR) defines a Retrieve Form for Data Capture (RFD) content profile that will specify derivation of source content from a medical summary document. by defining requirements for form filler content and form manager handling of the content

Pharmacy

The Pharmacy group is working toward a Profile, but it is not yet fully developed. 
No comments:

Saturday, August 26, 2017

Book: Healthcare Information Technology - 2nd Edition

I received my copy of the book to which I contributed a chapter.  Healthcare Information Technology Exam Guide for CHTS and CAHIMS Certifications 2nd Edition. I also contributed to the First edition back in 2012. I needed only to do some minor fixup in my chapter. The list of contributors is long and very exclusive. I am honored to be among them.  

I am very pleased with my chapter in the book, 32 pages: "Interoperability Within and Across Healthcare Systems". I cover quite a bit of ground on Privacy and Security related to EHR and HIE. Much of the material comes from my blog, but even that had to be rewritten to fit the editorial style of a book. The chapter covers everything from identity, identity proofing, access control, authentication, and role based access control. I cover the various perspectives one must take in healthcare to protect data appropriately; including the patient perspective, provider perspective, and organizational perspective. I cover this topic as an exercise in a local EHR, but also how this model needs to be extended across an HIE to continue to protect the sensitive healthcare information. This requires the expansion out into Metadata and Federated Identity.

Gila also has chapter on Risk Assessment and Management. She didn't have as smooth of an editorial experience as I did.

I expect an update in a year to add chapters on FHIR. There is a very small mention of FHIR in this book, as it was written back during DSTU2. Excitement around FHIR, but not much was clear; and FHIR is not yet the topic in the exams.

No comments:

Friday, August 25, 2017

Malicious e-mail addresses

Last month I blogged about E-mail addresses -- Remedial and realistic

My point for that post was that it is important to have a agreed subset of the full character encoding allowed by the e-mail address specification. This subset helps to enable Interoperability, by having everyone make sure that they can send-to, and receive-from, an address fully encoded. This problem came up when some systems had trouble with the apostrophe, such as is needed (desired) for people names like "Fred O’Donnell". That is, a sending HISP didn't allow the user to send to a valid email address because it contained an apostrophe.

The subset of characters I give in  E-mail addresses -- Remedial and realistic, is a first line of defense. As the email standard allows a very nasty set of characters, especially if one just puts double-quote around the malicious string. So, I start with the sub-set I defined in the above article.

Unfortunately apostrophe is within that sub-set...

Security Considerations

So as helpful as apostrophe is for people names like "Fred O’Donnell", it is problematic as it can be used in malicious ways. This because the apostrophe is the single-quote. Here are some general email address attack articles:
More likely a javascript injection, like explained https://security.stackexchange.com/questions/106972/javascript-injection-in-email-address-as-username  Where an example that is not all that malicious, but is illuminating (okay, it includes character '=' which is not in the subset).
foo'onclick='alert'foo='@example.com

Direct Threat Analysis

There is a Threat Model within the Direct Project. I lead the sub-group that wrote this Threat Model.  The email address as a vector of attack is a situation where you are a Recipient, and the sender is malicious. The sender is trying to tell you that the sender email address is X, where that email address has malicious content.

The good news for Direct Project, is that the sender (you are the recipient) must have signed the email from certificates chaining to YOUR trust store. Thus for this to work, you must be trusting someone who is being malicious. As long as you carefully process up to signature validation, this eliminates the greater Internet attackers. 

Thus from the Treat Model, we are most worried about Arch 8, 9, and 10.

It still leaves a Trusted partner as the attacker, but they will get away with this only once before they are found-out and their trust revoked. Thus it better be really valuable attack for them to be motivated to try. So, the likelihood that they would try is very low.

Conclusion

Thus the use of apostrophe (single-quote) does add more risk, over the remedial set, that risk is low because of some mitigating factors (S/MIME, and Trust-Store).

However it is important to have a constrained email address character set, that everyone can FIRST check incoming (or outgoing) addresses against. This because it is far more simple to do simple string validation, before one starts to do operations on that string. Thus a simple string validation would reject a malicious inbound email, and there would be no opportunity to go deeper.

No comments:

Friday, August 11, 2017

The Privacy Advisor Podcast: Kirk Nahra on the complications of healthcare privacy

I listen to podcasts. I have recently come across "The Privacy Advisor Podcast". From the perspective of Privacy, this podcast does a fantastic job. Further Angelique  is fun to listen to. I suspect each podcast we learn a bit more about her, very unusual for a Privacy Advisor. But then again Privacy Principles do enable the subject to expose their data as they wish, a form of control.

To my blog audience, that tends to focus on Healthcare Privacy, the podcast with Kirk Nahra is fantastic. Kirk has a deep and thorough grasp of "Healthcare Privacy" in the USA, from a reality perspective. Not from a ideology perspective. Thus for those that want to understand WHY is Healthcare Privacy like it is, in the USA, this podcast hits every topic. I will warn that none of the points are fully explained, but all the points are spoken. So if you listen to this, and don't understand a point Kirk is making, then you need to do some research. I fully agree with Kirk's point of view and assessment of why and how we got here. He speaks of many of the struggles that I have participated in over the past 25 years. A he points out, if we were to write Privacy regulations today, it would not look this way.

The Privacy Advisor Podcast: Kirk Nahra on the complications of healthcare privacy
6/30/17 by IAPP Publications Team
Web player
Episode
In this episode of The Privacy Advisor Podcast, Kirk Nahra of Wiley Rein talks about the challenges of working in the healthcare space these days, particularly, the challenges healthcare entities have in managing the multitude of third-party vendors and the "ongoing element of risk" involved in trying to ensure not only your organization is in compliance with regulations, but vendors are too. He also discusses the explosion of available data not covered under current healthcare laws, like the data from your wearable devices, and whether that data is regulated by any body of law at all. "We've got this enormous gap right now," and the new administration isn't particularly interested in figuring that out, Nahra says, but he's hopeful U.S. state Attorneys General are going to pick up the slack.Want to keep up with new episodes? Be sure to subscribe to our feed.
No comments:
Subscribe to: Posts (Atom)