Wednesday, July 3, 2013

NIST Releases Draft Outline of Cybersecurity Framework for Critical Infrastructure

I like what NIST does regarding Security guidance. I know that they are a USA government body, thus those outside the USA have some reservation. I however find that they hit all the right buttons on their Security specifications. They are catching up a bit on their understanding of Privacy.

I have high hopes, but not too high, for their new Cybersecurity Framework. First, I am dissapointed that NIST would be dragged into a buzzword and forced to say "cybersecurity" as if it is a term that everyone knows totally. But, sometimes one must do the buzzword bingo
As part of its efforts to develop a voluntary framework to improve cybersecurity in the nation's critical infrastructure, the National Institute of Standards and Technology (NIST) has posted a draft outline of the document to invite public review and gather comments.
The Executive Order calling for NIST to develop the framework directs the agency to collaborate with the public and private sectors. The draft outline reflects input received in response to a February 2013 Request for Information, discussions at two workshops and other forms of stakeholder engagement.
 The framework so far is useless, but their approach is good. It will be Risk based, and leverage existing standards. This is music to my ears.
The draft outline and other documents related to the Cybersecurity Framework are available at http://www.nist.gov/itl/cyberframework.cfm.
The most informative part of this announcement is their presentations:
Posted by at No comments:

Sunday, June 30, 2013

Technology Trends in Healthcare IT

Summer is a good time to assess the existing trends and project which ones will continue through the year. I would define the technology trends I see in Healthcare IT as “Mobile”, “Privacy”, and “Services”.

Within them I do include specific technologies that are today’s buzzwords.
  • Mobile – portable Data, portable Applications, portable Profiles, portable Devices, portable Sensors, portable Sessions, portable Security-- mobile as a user experience – mHealth is the most used buzzword so far this year. 
  • Privacy – Respect the individual, be Transparent with the individual, and Security of systems and data – privacy as a user experience – The Patient and Provider MUST trust that what they offer to Health IT will be maintained properly. Trust is easy to get the first time, very quick to lose, and almost impossible to recover from.
  • Services – Not necessarily as formal as SOA, but much like the SOA religion. Mostly services that enable HIE. Anything that could be a reusable service is "designed as" a service. Any service can be a local or remote or cloud hosted service. I think the concept of “Services” is more descriptive than “Cloud”, although to get best buzzword points "Cloud" mostly gets the point. 
Note that these three technology areas are overlapping and highly related. However they are on different tracks and require different development and maturing.

As always I have an indexed list of my articles by topic areas
Posted by at No comments:

Saturday, June 29, 2013

Redaction fail - Lessons healthcare must learn from

Interesting article on the problem with redaction, possibly exacerbated by human redaction. The article focuses on Military/Political based classification systems and the de-classification system we have. This system is based on humans that are trained experts. Their training, expertise, and guidelines tend to be highly variable. The article even includes explicit examples where two different people came to exactly the opposite conclusions on redaction, thus their combination gave everything.

The best part of the article is the paragraph:
"The idea that you can slot all knowledge into neat little categories that perfectly overlap with our security concerns is already a problematic one, as Peter Galison has argued. Galison’s argument is that security classification systems assume that knowledge is “atomic,” which is to say, comes in discrete bundles that can be disconnected from other knowledge (read “atomic” like “atomic theory” and not “atomic bomb”). The study of knowledge (either from first principles or historically) shows exactly the opposite— knowledge is constituted by sending out lots of little tendrils to other bits of knowledge, and knowledge of the natural world is necessarily interconnected. If you know a little bit about one thing you often know a little bit about everything similar to it."
De-Identification focuses on the removal of identifiers. This is hard enough, but nowhere near as hard as removing intelligence. That is not to say that healthcare has it easy, we do have sensitive health topics that are just as hard to handle. We should just not equate government redaction systems with the systems we need in healthcare to support clinical trials, clinical research, public health reporting, etc.

See also: De-Identification

Posted by at No comments:

Monday, June 24, 2013

Internet User Authorization: why and where

User identity, authentication, and the user’s authorization given to applications; are a hot topic in security and privacy. The latest darling on the block is oAuth, championed by Google, Facebook, Twitter, LinkedIn, Salesforce.com, and Amazon.

This technology has just been profiled by IHE in the Internet User Authorization (IUA) profile that is out for public comment right now. http://www.ihe.net/Technical_Framework/public_comment.cfm#IT

oAuth is good for:

This technology specification has some advantages over others, but mostly in the space of:
  1. Internet facing web services
  2. Web services available to the public
  3. Applications that are installed on mobile devices using internet facing web services
  4. Functionality that interact with social networking
  5. Functionality that can utilize identity and authentication managed elsewhere
  6. Web Browser or RESTful API
This does not mean that it is good for everything, nor that it is limited to these functionality. It is just good to understand where a technology fits best.

Both SAML and oAuth act rather similarly from a browser experience, although oAuth has a functionality that doesn't exist in SAML. I oAuth the authenticated user can endorse an application (mobile app or web-service) as having the authority of the user. That is the user can delegate their identity to an application, that can use that identity transparently in the background. This also comes with the ability of the user to revoke that authority. It is this functionality that differentiates oAuth.

SAML is still a better solution for:

  1. Backend communications that need a user identity
  2. Business-to-Business communications
  3. Federation of Identity
  4. Federation of Access Control decision points
  5. When the Identity Provider is Active Directory – Active Directory Federation Services
  6. SOAP web-services, although supported on Web Browser and RESTful API
It is more likely that an organization will host a Active Directory for their users and enable Active Directory Federation Services exposing SAML Assertions; than they will use oAuth. This might be a maturity thing that changes over time, or it might be a long term reality. SAML Assertions are generally seen as more business focused, where oAuth is more consumer focused.

I have covered this a bit more in What User Authentication to use?

IUA --> SAML + oAuth

The IHE IUA profile profiled a join between these two worlds. An Option in the IUA profile utilizes an IETF draft rfc that defines how to carry SAML Assertions within the oAuth infrastructure. Thus bringing together the benefits of both, although bringing along baggage that might be seen as the combination of the negatives.

The IUA profile is truly just an IHE profile. It only strives to profile the underlying standard to meet Heathcare needs. It is NOT a tutorial on how to use oAuth, or how to write your code, or how to configure a directory. These are all well documented today, and/or are opportunities for others to fill in. The IHE profile is simply taking the needs of healthcare and showing how to utilize oAuth to achieve that.

It recognizes the default oAuth use of bearer tokens, which are really only useful in the case where the oAuth token issuer is the same organization as the web resource being approached. This is because a bearer token is opaque and thus means the web resource gets no information about the user, the access control decision must be made totally at the oAuth token issuing. This is an okay solution, but didn't really enable much in the way of Interoperability. So IHE acknowledged this mode and allows it, but doesn't really utilize it in the profile.

The IUA profile primarily used JWT token types. These token types are readable, as they are encoded using JSON attribute encoding. The IUA profile shows how to carry the typical healthcare specific information within this package: User Role, Purpose Of Use, etc.

And Lastly the IUA profile added an option that uses an IETF draft for carrying a SAML assertion. In the case of IUA, this SAML assertion is profiled by XUA. Thus this is an encapsulation of a SAML assertion inside oAuth : IUA(XUA). 

Public comment is open until July 3rd. Please get your comments in.
Posted by at No comments:

Tuesday, May 14, 2013

Security Tutorials on mHealth Security and Auditing - #FHIR

The two presentations that I gave at the HL7 meeting Wednesday afternoon “Free Security Tutorial”, and again at the Joint Security/EHR/FHIR/SOA meeting on Thursday; are posted on the HL7.org web site. They are:

Security Education: mHealth Security and FHIR

This presentation is made up of current viewpoint
on mHealth security basics, risk-assessment models, network communications security, and user identity and access management. This information is on the HL7 FHIR site, and will improve over the coming month. Front and center is the IHE-Internet User Authorization (IUA) profile, a profiling of oAuth 2.0. Much of the material I cover is also covered on my blog at the following:

Security Education: Security/Privacy Audit Logging and Reporting

Posted by at No comments:

Wednesday, May 1, 2013

De-Identification - Data Chemistry

The concept of de-identification is a reoccurring theme in my circles. The use of the term de-identification that I use is the broader term well beyond the constraints of HIPAA. I use the term de-identification to refer to the process of reducing risk of privacy or identity exposure through modifying the data. This includes using pseudonyms, known as pseudonymization; and also includes removing data elements, known as anonymization. Therefore De-Identification is made up of both Pseudonymization and Anonymization.

I am involved in much of the standards work in this space, actively working in IHE on a handbook and ISO on updates to the core standard on the subject. In all of these cases we are trying to make the 'art' of de-identification more measurable, repeatable, and approachable. Too often it is seen as too hard, more often it is seen as simple and thus mistakes are made. The goal I have is to make it clear.

Why De-Identify?

First, one must understand that de-identification is just a method of lowering risk. The only way to get risk to zero is to have zero data. Even one data-element that one might consider to be purely clinical data does narrow down the population. Just to indicate that the weight of the subject is 203lbs will tell you much about the subject, if that value is 3lbs and you know the subject is a premature-baby, and if it is 403lbs it is clear you have limited the population. The first point is that all data are potentially identifiable, some data are less so.

Second, one must recognize that some data are outright Direct Identifiers. These data are in no uncertain terms identifiers. Full-Name is the most obvious. A Direct Identifier is something that is publicly known (knowable), therefore full-addresses, phone numbers, credit-card-numbers, and drivers-license-numbers. These items clearly can't be included in the de-identified data set. So they each need to be identified as a risk to be mitigated.

There are also a class of data that can be used in combination with other data in the data-set to identify a subject. Such as postal-codes, sex, date-of-birth, hospital identifier, or date-of-procedure. These are risky to be left in, so they need to be identified as potential to be mitigated.

The task of De-Identification is much like chemistry, bio-chemistry sometimes. One must understand the elements and how they interact. One must use various tools to separate or modify the elements. Each chemical process results in something useful for the purpose it was created. Some combinations of chemicals are very volitile, others benign, but all must be given respect.

De-Identification Procedure

The procedure is simple. Ill include only the high-level, each step is more involved than I indicate here.:
  1. Identify what it is you want to do with data. This is your use-case. What are critical data attributes, and what are acceptable tolerances for each data attribute. You need to justify each element you want. You must also identify the acceptable level of risk, which includes assessment of the authorizations you have.
  2. Identify ALL of the data elements that you have. This is the data set that has not been de-identified. It might be a database, it might be a stream. You must identify all of the data, not just the data you are worried about. You then classify each attribute: Direct, Indirect, or simple data. Note that any unstructured data, otherwise known as free-text, must be considered Direct Identifier. 
  3. Apply Mitigations, in theory. Given the use-case details you created in (1) and the data-element inventory you created in (2); apply the de-identification tools. (a) Redact - delete element, (b) Fuzz - modify within tolerance, (c) generalize - broader terms, or (d) replace - pseudonym. These are clearly not all the tools but the large categories of tools.
  4. Assess risk, in theory. How correlated are the data to a subject? Is this level of risk acceptable to the policy identified in (1)? Don't change your policy, that is the easy way out. Continue to apply mitigations. If further mitigations results in data that are not useful to your use-case, then you might need to change something else. 
  5. Apply Mitigations to data-set and validate the results. As with any design-of-experiments one must be able to prove your theory. Is the resulting data just as de-identified as you expected? Is the resulting data useful for your use-case?
However well you have de-identified, recognize that there is residual risk that needs to be managed. This risk is often significant  thus requiring good security practices. Just because you think your data are de-identified, does not mean you don't need to protect it. Attacks against de-identified data only get better, they never get worse.

De-Identification is Contextual

I have said exactly this (De-Identification is highly contextual) before. the de-identification algorithm you  come up with will not be useful to a different use-case, or a different data-set. It might be, but the assessment needs to be made. The context behind the needs of the use-case are critical. Take only the data, and the fidelity of the data that you need. 

Gross De-identification

There are use-cases for doing a gross de-identification into a large data set, followed by secondary use-cases with their own further de-identification analysis. This is often done in population-health analysis, using gross de-identification to fill the population database. While re-assessing results of any sub-analysis of a specific population health epidemic. Clearly the large database needs to be protected quite strongly, I might say it needs to be protected just as well as a full fidelity database.

Summary

De-Identification is a technical tool. It is not a get-out-of-jail card. The resulting data set likely still requires some protection and safe handling.

Posted by at No comments:

Friday, April 26, 2013

Privacy Consent State of Mind

The space of Privacy Consent is full of trepidation. I would like to show that although there are complexity, there is also simplicity. The complexity comes in fine-details. The fundamentals, and the technology, are simple.

Privacy Consent can be viewed as a "State Diagram", that is by showing what the current state of a patients consent, we can show the changes in state. This is the modeling tool I will use here.

I will focus on how Privacy Consent relates to the access to Health Information, that is shared through some form of Health Information Exchange (HIE). The architecture of this HIE doesn't matter, it could be PUSH or PULL or anything else. The concepts I show can apply anywhere,  but for simplicity think only about the broad use of healthcare information sharing across organizations.

There are two primary models for Privacy Consent, referred to as "OPT-IN" and "OPT-OUT".

Privacy Consent of OPT-IN

At the  left is the diagram for an OPT-OUT environment. One where the patient has the choice to OPT-OUT, that  is to stop the use of their data. This means that there is a presumption that when there is no evidence of a choice by the patient, that the data can be used.

This model is also referred to as "Implicit Consent". The USA HIPAA Privacy Regulation is utalizes this model for Privacy Consent within an organization. It is not clear to me that this HIPAA Privacy Regulation 'Implicit Consent' is expected to be used outside the original Covered Entity. It is a model used by many states in the USA.

The advantages typically pointed to with this model is that many individuals don't want to be bothered with the choice, these individuals trust their healthcare providers. Another factor often brought up is that when health treatment is needed, the patient is often not in good health therefore not well capable of making decisions; this however focuses on legitimate uses and ignores improper uses. Privacy worries about both proper and improper access.

Privacy Consent of OPT-IN

At the right is the diagram for an OPT-IN environment. In an OPT-IN environment the patient is is given the opportunity to ALLOW sharing of their information. This means that there is a presumption that the patient does not want their health information shared. I would view it more as a respect for the patient to make the decision.

This model is used in many regions, even within the USA. With an HIE this  model will work for many use-cases quite nicely. Contrasted with the HIPAA Privacy use of Implicit Consent, which is likely a better model for within an organization. The two models are not in conflict, one could use Implicit Consent within an organization, and OPT-IN (Explicit Consent) within the HIE.

Privacy Consent Policy

The above models seem simple with the word "YES" and "NO"; but this is not as clear as it seems. Indeed the meaning of "YES" and the meaning of "NO" are the hardest thing to figure out. It includes questions of "who" has access to "what" data for "which" purposes. It includes questions of break-glass, re-disclosure, and required-government reporting. The "YES" and the "NO" are indicators of which set of rules apply.

The important thing is that there are different rules. The state of "YES" doesn't mean that no rules apply, there are usually very tight restrictions.  The state of "NO" often doesn't truly mean no use at all. There is usually some required government reporting, such as for the purposes of protecting public health.

Privacy Consent: YES vs NO

The reality of privacy consent is that there will be a number of patients that will change their mind. This is just human nature, and there are many really good reasons they might change their mind. A patient that has given OPT-IN authorization might revoke their authorization. A patient that has indicated they don't want their data to be shared might decide that they now do want to share their data. For example as a patient ages they recognize that they can be best treated if all their doctors can see all the other doctors information.

Thus what seems like a very simple state diagram for OPT-IN or OPT-OUT; one must recognize that they need to support transition between "YES" and "NO".

Privacy Consent of Maybe

Lastly, we all recognize that the world is not made up of 'normal' people. There are those that have special circumstances that really require special handling. This I am going to show as another state "MAYBE". This state is an indicator, just like "YES" or "NO", but in this case the indicator indicates that there are patient-specific rules. These patient-specific rules likely start with a "YES" or a "NO" and then apply additional rules. These additional rules might be to block a specific time-period, block a specific report, block a specific person from access, allow a specific person access, etc. These special rules are applied against each access.
Note that the state diagram shows transitions between all three states. It is possible that one goes into the "MAYBE" state forever, or just a while.

Privacy Consent is a Simple State Diagram

I hope that I showed that Privacy Consent is simply state transitions. I really hope that I explained that each state has rules to be applied when a patient is in that state. Implicit (OPT-OUT) and Explicit (OPT-IN) are simply an indicator of which state does one start in, which state is presumed when there is an absence of a patient specific decision. The rules within each state are the hard part. The state diagram is simple.

Other Resources


Patient Privacy controls (aka Consent, Authorization, Data Segmentation)

Access Control (Consent enforcement)



Posted by at No comments:

Wednesday, April 24, 2013

mHealth Solution

I have been involved in many efforts targeting the mHealth use-case. I have not been involved in all of them. I am sure no-one has been involved in all of them. Specifically I have been involved in the efforts in IHE, HL7, and DICOM. I have mostly spent my time on Security and Privacy; but also had my hand in some of the interoperability aspects. This means that I have a perspective, and know that it is only my perspective. This means I know that I don't know it all. This is my blog however, so you should already know that.

What is mHealth? 

mHealth is a highly over used term now days. The reason it is over used is because it is a term that is cool. How it gets abused is because the term is not defined. Because it is undefined, it gets to multiply the excitement that anyone has around the term, without focusing any progress. This means that 10 people who have 10 different perceptions of what the term feed off of the excitement of the other 9, while getting none of the benefits of collaborative design. Thus this term is burning lots of excitement without making as much progress as it should. To show just how divergent these perceptions, here are some I have heard:
  • mHealth means that the healthcare-data is highly movable and thus can flow to where ever it is needed
  • mHealth means that the way I access my health-data is through a mobile device
  • mHealth means that I as a patient can pull copies of my data a move it wherever I want 
  • mHealth refers to sensors that I carry on my body all the time, such as fitbit
  • mHealth means that my consent automatically applies to where ever my data is accessed
Added June 2013
  • mHealth refers to the mobile medical devices that move between facilities on trucks (e.g. CT)
  • mHealth refers to the use of barcode and such to track healthcare technology movements

The mHealth Solution

You can see from these 5 that in some cases the data are 'mobile', others the device used to access the data are 'mobile', others the patient is 'mobile', and others the sensors are 'mobile'. These are just four different view points. YES, they could all be the same. BUT the solution space for these are not working on all of them, or even more than one of them at at time. Just some examples of the solution spaces that are working on these issues, but not necessarily the same.
These are not all the efforts, nor all the perspectives on mHealth. None of these perspectives are wrong, and all of them are proper things to be doing.

Consent portability

I do have to caution that the consent moving to the data is the least mature. Mostly because there are far too many moving parts being worked on. That is that the architectures for how data are moved and accessed are not yet stabilized. Some are moving data in e-mail, others using REST, others using SOAP, others using USB/CD-ROM,  and others using proprietary means. Trying to come up with a single way to control access is hard to, and trying to control those is futile at this point. This doesn't mean there is nothing going on, there is much going on. 

mHealth is anything you want

This is not a fundamental problem. This is not a problem that will cause failure to meet mHealth expectations. I want to urge understanding that the term is not well defined, and thus the one you are talking to might be thinking something totally different. What they are thinking is not wrong. It is just important to be sure that you understand their perspective. Thus the mHealth solution is many, not one.

See also
Posted by at No comments:

Friday, April 19, 2013

Direct incompatibility with off-the-shelf e-mail

Why choose a popular underlying standard if you are not going to leverage it? Surely you should not make explicit changes that break it.

The Direct Project choose to use e-mail, and the security layer S/MIME. This choice was due to the wide spread use of e-mail. Wide spread use in the case of e-mail can be proven by the very fact that today e-mail is still the most used protocol on the internet. This in the face of those that would like to consider "the Web" as pseudonymous with "the Internet". The statistics say that it is closer to "e-mail" is pseudonymous with "the Internet". Actually they both combined make up most of the internet.

The Direct Project expectation was that healthcare should only need to specify the trust framework -- see DirectTrust.org for one organization trying really hard to make this factor a reality. This trust framework would allow a sender to be sure that what they are sending can only be seen by the one they are sending it to, and no-one in between This trust framework would allow a receiver to know that the content absolutely came from the one indicated as the sender, and no-one in-between This trust framework is critical to success. But this trust framework is 99% policy. The technology portion of this trust framework is all standards based and embodied in the common use of S/MIME and the PKI that supports it.

Direct Specification is NOT leveraging commonly implementations of S/MIME e-mail!

I have written on this topic before. At that time it was about the specific rules on how one must DISCOVER the certificate of the recipient you are sending e-mail to: MU2 - Why must healthcare use custom software when Thunderbird and Outlook would do? In that article I explain that this requirement was overly restrictive. It forces specific certificate distribution model that that is unique to healthcare. It doesn't support the Trust Framework. It just gets in the way of using off-the-shelf software. Thus forcing healthcare to use custom software.

Direct Specification forces case-sensitivity when none is necessary!

Now there is an effort to force case-sensitivity to Direct Project address. This technically is specified in the underlying standard, but it is not always implemented this way. Let me explain. The underlying e-mail specifications do indicate that the first part of the destination address shall be case-sensitive. This was because some destination systems are indeed case-sensitive. However not all destination systems want to be case-sensitive.

It is true that case-insensitivity is ambiguous once you leave the classical ASCII character set.  Therefore case-sensitivity is indeed more easily proven, and thus interoperable. However 'allowing' case-insensitivity when the destination system wants to allow it, should be allowed. 

What is happening is that there are test-tools being developed to test implementations of Direct. These test tools are being written strictly. This strict interpretation of the standards is a good thing for test tools to do. But in some cases systems need to be allowed to be more liberal in what they accept. Destination systems should not be forced to be so restrictive. This is an application of the Robustness Principle, also known as Postel's law, after Internet pioneer Jon Postel - "be conservative in what you do, be liberal in what you accept from others" .

We MUST be reasonable. The case requirement is more focused on being case-preserving, so that an endpoint ‘can’ be case-sensitive. That is to say that senders and intermediaries must preserve the case. To require that the endpoint MUST be case-sensitive is overly restrictive. This would cause many common email infrastructures to be declared non-compliant. Most off-the-shelf e-mail treats the whole address as case insensitive. This declaration of non-compliance would come at no benefit, and would limit the market space available for healthcare use.

Direct Continues to require custom software for healthcare.

This is absolutely against the values that the Direct Project included during the development. The reason to choose common e-mail transport was to leverage the large body of infrastructure and software already available. Using custom software increases costs, and makes healthcare re-develop tools that have been developed over decades of advancements in e-mail, and at no added value.

Posted by at No comments:

Thursday, April 18, 2013

Safety vs Privacy


What do you conclude when looking at this picture?

The solution is:
a) Make the wall shorter
b) Make the wall taller

Those with a strong privacy background recognize this as a Privacy violation. Very clearly the wall is not tall enough. Clearly the female is to be protected against the male actor. Clearly the wall is defective and needs to be taller.

Those with a strong safety background recognize this as a safety concern. Very clearly the wall is not short enough to enable safe conversation between these two. Indeed the safety assessment doesn't apply ethical characteristics to the female or male image.

My viewpoint is to understand the use-case. What are these two trying to do? Is this a case of (a) or (b). Just because the image is made up of the images used for bathrooms does not mean that the image is of a bathroom use-case. Knowing the use-case is the only way to understand if this is a privacy violation or if this is a legitimate discussion over a wall that is too high.

Indeed the solution might be BOTH. The wall is indeed there for privacy purposes, and it is failing. There is also a safety concern as the wall is not tall enough to prevent someone from putting themselves and others at risk of harm. This shows that not always are privacy and security risks at odds. Sometimes they can be solved harmoniously.

Posted by at No comments:

Thursday, April 11, 2013

Google creepy is not the same as Facebook creepy

Google NOW has brought a totally new form of data analytics to my fingertips, and I like it. I am actually handing more information to Google than I would have, just to get this capability. I like that driving routes are suggested, with start times that match my appointments. I like that it knows just the right sports to inform me about, even when that sport is Hockey which the news media seems to know nothing about. This level of leveraging all the information that Google can find on me to bring me value is fantastic. This is what differentiates Google creepy from Facebook creepy.

When Facebook indicates that they are going to start to pull some new form of information, I don’t get the feeling that they are going to do this for my benefit. It is very clear that Facebook is gathering more information for their own benefit. Even their insistent plea to harvest my address-book. I am not going to expose my friends to more advertising through Facebook.

The first evidence that I as a user get from the gathering of data is valuable in the case of Google, and punitive in the case of Facebook. I know that Google is using my data to make money, I am a strong believer that if you are not paying for something, then you are the product and not the customer. The fact that Google makes money with my data is less creepy because Google gives me value. In fact Google gives me so much value that I go out of my way to give it more data. Whereas Facebook creeps me out so much that I avoid telling it many things.

Perception is more powerful than reality. The perception of value, even if it is not truly valuable, is what is important. The fact that Google Now gives me driving directions automatically rather than me doing a Google Search is a small step, so the actual value is small. The actual spend by Google is small. The perception of value is big.

Goldilocks Governance

Healthcare can learn from this. The value of a Health Information Exchange is great (What is the benefit of an HIE), the perception of creepy can also be great. Trust and doing what the consumer ‘expects’ is the bridging factors. The patient wants their data to be available to those that can provide the patient value. The patient wants their data to be protected against those that provide the patient no value. I coined the term “Goldilocks Governance” for this. Not too tight, not too loose, but just right.

This is also a consistent Privacy approach as outlined by the USA Whitehouse consumer privacy principles that was published just last year. This privacy philosophy recognizes that the consumer understands the context of their interaction as defined in "Privacy As Contextual Integrity" by Helen Nissenbaum. Which indicates that consumers do understand that their data will be used in specific ways, clearly in healthcare for treatment and billing, but also in healthcare they understand their data is used for public health benefits and other normal operational ways. This is otherwise described as the "Consumer Should Not Be Surprised." Meaning they should not be surprised that their data is used in some specific ways; yet also that it is right for them to be outraged at inappropriate uses of their data.

Posted by at No comments:

Monday, April 1, 2013

HIE Patient Identity problem

I will assert, yet again, that the Patient Identity problem that HIEs are having is not technical. The technical standards are clear and used quite a bit (PIX, PDQ, XCPD). The problem is in policy, where there are many different policies in use today. These policies define what a source organization is allowed to divulge, and when they can divulge something. These policies define the parameters of the matching algorithms regarding false-positive, false-negative, and risk tolerance to keeping readable attributes vs hashes. Often times the policy problem is rooted in misunderstandings of the regulation.

The biggest disconnect I have seen is simply that all the organizations involved don’t have the same set of attributes to the same level. For example one of the big problems seen is that the SSN matching is made almost useless because the some organizations only knows the last 4 digits. One of the other factors that we will see emerge even more is that the organizations today never worried about external matching so they don’t have the ability to now ask for, or record, more information. Some have suggested that the patient could/should provide a voluntary ID such as the patient’s ‘direct’ address. The existing systems don’t know where to save this, and they don’t know how to include it in a matching request. The Interop standards (PIX, PDQ, XCPD) handle these just fine, they are simply 'other' external identifiers.

These items are very much what the security world would view as ‘provisioning level of assurance’. That is how sure is the cross-reference. In this way this overlaps very well with the greater NSTIC effort.

The hardest policy to get agreement on is to what extent is a request for location of records (just the indication that a location has records, not an indication of what kind of records), is a ‘disclosure’ that is ‘acceptable or not’ especially when the request is made under the workflow of ‘treatment’. This is an important policy to allow, as one must first get a positive cross-reference before one can ever know if the consents have been granted. Surely if there is no positive consent then no match should be made, but if there is any fraction of a positive consent (including emergency override allowed) then a match needs to be allowed. Of course all matches need to be recorded and reported on an accounting of disclosure (something always forgotten).

This is one of the main reason why PIX/PDQ/XCPD are totally different steps than Query for information (XCA, XDS, MHD). This is not to say that a cross-reference match should not be considered a privacy concern, but rather to recognize that for specific PurposeOfUse (Treatment) might justify some risk. Where this risk is managed, not totally unmanaged. Where the impact of this risk is controlled to just cross-reference. The hard part is that some viewpoints of policy totally forbid even this level of disclosure. Some negotiation seems to be logical.

And, yes I totally agree that patients that want nothing to do with this should not have even this level of exposure happen. As I indicated above a ‘opt-out-completely’ is indeed an exclusion. Sensitive topics, also well segmented. I only look to this first step cross-referencing to be appropriate when there is some form of possible positive communication possible.

I do think that this is a reasonable thing for NSTIC to look at. However it is a somewhat of a very different problem from the original intention of NSTIC. This is likely why you see organizations solving this problem behind closed doors.


Patient Privacy controls (aka Consent, Authorization, Data Segmentation)

Posted by at No comments:

Monday, March 25, 2013

Foundational ASTM healthcare standards re-approved

This is notice of some re-approvals of ASTM standards that are seen and used as foundational standards in healthcare. Re-Approval is a regular thing that ASTM standards must go through in order for them to stay approved, so this is likely just a mechanical re-approval. I was not involved in this re-approval, but suspect that these are re-approved without changes. If I hear otherwise I will let you know.

Many of these re-approvals are very foundational, such as: 


ASTM Standards Tracker Alert. New Approved ASTM Standards

E1714 - Standard Guide for Properties of a Universal Healthcare Identifier (UHID) has been reapproved, available as E1714-07(2013) developed by Committee E31.25, ASTM BOS Volume 14.01. 
E1715 - Standard Practice for An Object-Oriented Model for Registration, Admitting, Discharge, and Transfer (RADT) Functions in Computer-Based Patient Record Systems has been reapproved, available as E1715-01(2013) developed by Committee E31.25, ASTM BOS Volume 14.01.

E1762 - Standard Guide for Electronic Authentication of Health Care Information has been reapproved, available as E1762-95(2013) developed by Committee E31.25, ASTM BOS Volume 14.01.

E1985 - Standard Guide for User Authentication and Authorization has been reapproved, available as E1985-98(2013) developed by Committee E31.25, ASTM BOS Volume 14.01.

E1986 - Standard Guide for Information Access Privileges to Health Information has been reapproved, available as E1986-09(2013) developed by Committee E31.25, ASTM BOS Volume 14.01.

E2145 - Standard Practice for Information Modeling has been reapproved, available as E2145-07(2013) developed by Committee E31.25, ASTM BOS Volume 14.01.

E2147 - Standard Specification for Audit and Disclosure Logs for Use in Health Information Systems has been reapproved, available as E2147-01(2013) developed by Committee E31.25, ASTM BOS Volume 14.01.

E2171 - Standard Practice for Rating-Scale Measures Relevant to the Electronic Health Record has been reapproved, available as E2171-02(2013) developed by Committee E31.25, ASTM BOS Volume 14.01.

E2457 - Standard Terminology for Healthcare Informatics has been reapproved, available as E2457-07(2013) developed by Committee E31.35, ASTM BOS Volume 14.01.

E2522 - Standard Guide for Quality Indicators for Health Classifications has been reapproved, available as E2522-07(2013) developed by Committee E31.35, ASTM BOS Volume 14.01.

E2553 - Standard Guide for Implementation of a Voluntary Universal Healthcare Identification System has been reapproved, available as E2553-07(2013) developed by Committee E31.35, ASTM BOS Volume 14.01.

E2595 - Standard Guide for Privilege Management Infrastructure has been reapproved, available as E2595-07(2013) developed by Committee E31.25, ASTM BOS Volume 14.01.
Posted by at No comments:

Thursday, March 21, 2013

XDS Notifications

A highly passionate discussion happened today regarding the use of XDS and the case of ‘how does an individual know that they have documents of interest they should look at’. One specific example is when the individual is a key individual of a workflow step. It could be as well that the individual should be simply interested in new content.

The discussion got heated because there is interest in getting a very targeted notification. As elaborated there is indeed no specific IHE profile capability to do this notification. There is however many ways that the functionality can be implemented. No single functionality is universal, there are really good reasons for each method.

The XDS notification functionality methods are:

Poll: An individual (system) can poll XDS. That is to use Queries one for each patient that system has individuals that are interested in. How often should it poll is left as a configurable parameter as there are good reasons to have this configurable. ** Note this is very much what e-mail uses at the technical level with POP. Clearly as users we are not polling, nor do we know our machines (cellular phones) are polling. This is the most basic, and most robust mechanism. But this is also cumbersome and causes unnecessary traffic and query processing. *** Note that doing date specific queries are not easy to do, but can be done; and there is a Change Proposal to enhance the query.

 Notification: The Notification of Document Availability (NAV) Profile is a little known supplement. It defines a simple XML encoded manifest of document references, and indicates to send this in an e-mail message. This is just a list of document ID values, so it is not exposing patient privacy in any direct way. This e-mail could surely be sent using encrypted email if you have that capability. The drawback is that it does require that someone knows that you need to be notified, and that you would like to be notified in this way. *Note that the profile does have a specification of how to encode this on paper as well. ** Note a degenerate form is simply an e-mail with no information, just a ‘ping’ that you might recognize, however this isn’t interoperability. *** Of course you could also just pick up the phone as well.

 PUSH: That is to Push the content using XDR or XDM. This could be a copy of the documents, because they are globally uniquely identified there is no problem that they get duplicated. ** Clearly again the publisher must know who to next notify *** Because this is full content one must secure the communications.
Subscription: There is the Document Subscription (DSUB) profile that allows a system to ‘subscribe’ to be notified. This subscription contains a filter criteria that would constrain why a notification would happen. Although this is a rather technically easy profile, it is not implemented often. It is not clear how big does a notification system need to be to satisfy a growing population of systems that want notification. This profile is also tied to SOAP webservices, and really only works within a single XDS domain.


Atom Feed: This is really a polling query, but the results often is seen as a form of notification. The Atom feed is a part of the Mobile Health Documents (MHD) profile.

Is there a pattern that we don’t have? I know of some creative ways to use TCP sessions that are left in a closing state, where the one that knows who to notify closes the connection when there is something useful to pull, thus causing the system to poll only when this session close event happens. This is a very low overhead, but does require the systems handle many failure-modes robustly. This is what happens in some mobile APIs to help limit the polling traffic.

Specific to workflows, in the Cross-Enterprise Document Workflow (XDW) profile we did document that a workflow does need to have a system watching to make sure workflows do progress normally. This system could notice a workflow document that seems to have stalled, and give notice via a mechanism like NAV.

It seems we have plenty of ways to achieve the functionality. This technical solution should not be confused with what the user sees or feels.


Document Management (Health Information Exchange - HIE)

Posted by at No comments:

Wednesday, March 20, 2013

IHE Security and Privacy in an HIE/RHIO

I was asked to present at an event in Treviso Italy on IHE Security and Privacy as applied to IHE based HIE/RHIO. The room had about 100 participants from the area healthcare organizations. The presentation started with a long presentation by the organizers of Italy Regional Health Information Organization, all done in fast Italian. I had no idea what they were saying as the only words I could recognize was food words, likely they were talking cities but when it is the only word you recognize it sounds like they are talking about food.

In the 30 minutes I had I covered
  • Overall Security and Privacy controls
  • Audit Trails and Node Authentication (ATNA)
  • Cross-Enterprise User Assertion (XUA)
  • Basic Patient Privacy Consents (BPPC)
  • Controlling Access

It is a subset of the larger webinars that I have committed to my bloginar. 

Security/Privacy Bloginar: IHE - Privacy and Security Profiles - Introduction


Posted by at No comments:

Tuesday, March 19, 2013

Healthcare: Fail Open vs Fail Closed

One of the specific sensitivities we have in healthcare when thinking through Privacy and Security is the issue of what happens during failures of the “access control infrastructure”. For example when a natural disaster takes out some component of the security layer, such as User-Authentication.

In industries like Banking, this is very simple, they ‘fail-closed’. That is they tell you that the computers are not working, so come back tomorrow. The delay in providing you banking services is acceptable relative to the unacceptable potential that providing inappropriate services would have. They view this as an overall risk assessment harmonizing various business risks.

There is a different model of ‘fail-open’, that is to allow access when there is a failure. An example is that emergency-exit doors will open in an emergency, and there is ramifications to using these doors when there is no emergency. This is a weak example of fail-open, but I use it as illustrative. The idea in fail-open is to allow something that under normal conditions would not be allowed. Another example is the ‘break-glass’ functionality that protects a fire-alarm button, or fire-extinguisher. One must ‘break-glass’ to get to these tools, but normally one can’t use them. Note that these use-cases are also related to human safety. Not all fail-open are related to human safety, but human safety is a large body of the use-cases that call for fail-open.

Many healthcare use-cases should fail-closed as well. In fact I think there are far MORE use-cases in healthcare that should fail-closed than people think there are. That is that too many times I hear people saying that in healthcare all ‘treatment’ use-cases should be considered to be overwhelmingly safety over privacy. This generalization is incorrect. The generalization in healthcare should start with the same presumption of fail-closed without overwhelming justification to fail-open.

The cases where healthcare should use fail-open are few, but important. These use-cases are those related to safety of the provider and patient. That is to say when the failure to provide services will cause more damage to the provider or to the patient than the possible security or privacy breach. This is not a trivial decision. What is important is that there needs to be overwhelming evidence that a fail-open decision is the right decision, otherwise the default action should always be to fail-closed.

Some examples where overwhelming evidence is available: For example where a wide scale disaster causes a facility wide emergency-mode. An example is a natural disaster. Where there is an administrative decision that the needs of the local population care are overwhelmingly in favor of any possible abuse that might happen without control. These are cases where the health information might be broadly viewable, these are cases where creation of specific orders are allowed broadly, such as simple prescriptions; yet other orders, such as reconstructive surgery might be forbidden.

Another example that is often used is when the healthcare provider has some professional judgment reason that they feel is overwhelmingly important to their treatment. This is often seen as a “break-glass” workflow. Or seen as this is a case where a doctor can override a patient privacy restriction. Often times this comes with required justification text to be written by the doctor. This often is constrained to view for a short period of time. Note that patient opt-out needs to consider if overrides should be allowed or not, there are indeed some patients that would rather die than have information exposed, when they are well informed this might be acceptable.

A similar example is when the system making the query is unable to provide a user-assertion that is good-enough. For example the user can’t be 2-factor authenticated because the fingerprint reader is broken, but is authenticated using lesser means. The system querying is highly authenticated using system-level-authentication (ATNA). This system level authentication could be evidence that the conditions are good enough. This is a judgment, not a general rule.

In all of these fail-open cases, an audit log covers recording details so that after things settle down and normal mode is returned that someone can be sure that the overwhelming evidence was indeed in place. If the overwhelming evidence was not in place, then the individual should be punished according to the organizations policy.

Other Information

User Identity and Authentication

Patient Privacy controls (aka Consent, Authorization, Data Segmentation)

Access Control (Consent enforcement)

Audit Control


Posted by at No comments:
Subscribe to: Comments (Atom)