Healthcare Security/Privacy

Security Tutorials on mHealth Security and Auditing - #FHIR

noreply@blogger.com (John Moehrke) — Wed, 15 May 2013 01:31:00 +0000

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

This presentation is made up of current viewpoint of Security/Privacy Audit logging using IHE-ATNA and the FHIR-SecurityEvent resource. Much of the material I cover is also covered on my blog at the following:

De-Identification - Data Chemistry

noreply@blogger.com (John Moehrke) — Wed, 01 May 2013 13:34:00 +0000

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.:

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.
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.
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.
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.
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.

Privacy Consent State of Mind

noreply@blogger.com (John Moehrke) — Fri, 26 Apr 2013 11:45:00 +0000

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)

Defining Privacy
Universal Health ID -- Enable Privacy
Texas HIE Consent Management System Design
Simple and Effective HIE Consent
Advanced Access Controls to support sensitive health topics – a simple solution to sensitive health.
IHE - Privacy and Security Profiles - Basic Patient Privacy Consents

Access Control (Consent enforcement)

mHealth Solution

noreply@blogger.com (John Moehrke) — Wed, 24 Apr 2013 14:24:00 +0000

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

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.

data that are mobile -- HIE -- Direct and/or Exchange
mobile devices accessing data -- IHE-MHD and HL7-FHIR
patient access and carry data -- PHR, or ABBI
sensors carried by patient -- Continua, IHE-PCD
consent moves to data -- BPPC, HL7-Consent Directive, oAuth

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

Security Considerations: Healthcare RESTful Resource specifications
IHE mHealth Hackathon
The Magic of FHIR – The HL7 movement toward REST resources, away from v3 and v2
IHE Mobile access to Health Documents - Trial Implementation
What is the benefit of an HIE
HIE using IHE
One Metadata Model - Many Deployment Architectures
Simplifying Security Audit Standards
Advanced Access Controls to support sensitive health topics
Defining Privacy
Simple and Effective HIE Consent
IHE-IUA - Internet User Authentication for HTTP profiles

Direct incompatibility with off-the-shelf e-mail

noreply@blogger.com (John Moehrke) — Fri, 19 Apr 2013 18:28:00 +0000

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.

Safety vs Privacy

noreply@blogger.com (John Moehrke) — Thu, 18 Apr 2013 15:14:00 +0000

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.

Google creepy is not the same as Facebook creepy

noreply@blogger.com (John Moehrke) — Thu, 11 Apr 2013 12:37:00 +0000

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.

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

HIE Patient Identity problem

noreply@blogger.com (John Moehrke) — Mon, 01 Apr 2013 15:20:00 +0000

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)

Foundational ASTM healthcare standards re-approved

noreply@blogger.com (John Moehrke) — Mon, 25 Mar 2013 20:28:00 +0000

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:

E2147, which lays the foundation on which IHE-ATNA is built, and also referenced in the Meaningful Use regulation.
E1762 is the foundation of Digital Signature standards such as the IHE-DSG profile.

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.

XDS Notifications

noreply@blogger.com (John Moehrke) — Thu, 21 Mar 2013 16:13:00 +0000

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)

IHE Security and Privacy in an HIE/RHIO

noreply@blogger.com (John Moehrke) — Wed, 20 Mar 2013 12:58:00 +0000

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

The 30 minute slides are available here

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

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

Healthcare: Fail Open vs Fail Closed

noreply@blogger.com (John Moehrke) — Tue, 19 Mar 2013 11:35:00 +0000

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

Guidance on Deploying MU2 Secure Transport

noreply@blogger.com (John Moehrke) — Tue, 05 Mar 2013 21:39:00 +0000

The Meaningful Use Transport has been a struggle for many. Not just technology, which I cover. But also operationally, and administratively. The EHR Association has released a white paper that I would recommend. I worked this paper as the deployment of Direct is full of buzzwords, including my most hated buzzword 'HISP'. Please give this paper a chance to help explain how to deploy Direct in a way that is a positive stepping stone, not a terminal disease.

The EHR Association’s Standards & Interoperability Workgroup has just published the Practical Guidance to Implement Meaningful Use Stage 2 Secure Health Transport for Certification and Meaningful Use document .

This guidance document analyzes the regulation and explains the flexibility offered both to EHR vendors in achieving certification, but more importantly to our customers in leveraging this flexibility while successfully attesting to this component of the meaningful use criteria. This useful guide is being made available to all industry stakeholders, and can be found here.

Privacy and Security in Designing an mHealth Application

noreply@blogger.com (John Moehrke) — Fri, 01 Mar 2013 16:23:00 +0000

Security and Privacy are design criteria that need to be included at many levels of design. I have covered in what way Security and Privacy are considered during the writing of an Interoperability Standard Security Considerations: Healthcare RESTful Resource specifications. In the case of designing interoperability standards there is is little that can be done at that time, but the impact that can be done is important. Small tweaks in the design of an Interoperability Standard will have big impacts in practice.

Privacy and Security considerations in Deployment of Mobile Software

The next design layer after the one done at Interoperability Standards is the ones done in designing software. However I think it is useful to think next about how that resulting software would be deployed. This software might be a very small application, some javaScript applet, or might be a data analytics possibly 'big data', or might be a massively distributed computing like Folding@Home. The point is that including Privacy and Security into the design will allow the design to more naturally address Privacy and Security.

At the time of developing an Application you need to re-assess. The good news is that there are some fantastic analysis done on this topic as well. I like to point at NIST, simply because they provide very readable and free guidance: NIST Mobile Security Report This information is not specific to the USA, but I understand resistance to using it outside the USA. I encourage you to look at it anyway as it is very approachable. More engineering specific is the NIST Guidelines for Managing and Securing Mobile Devices in the Enterprise (Draft). In both of these documents is a focus on deploying mobile devices, not specifically in how to develop applications for mobile devices.

Using Risk Assessment during Application Design

Much of what I did say in the Security Considerations: Healthcare RESTful Resource specifications is usable at Application Development time. However at Application Development time you will be making some Design decisions. I would encourage being as open as possible, meaning being as configurable as possible. This openness and configurability is important to allow your application to be usable in many deployment configurations. The idea of this openness and configurability is to allow the individual or organization that takes your application to have flexibility in how they use it. But recognize that the clause “… as possible” is an indication that it is almost never possible to be perfectly open and perfectly configurable. Thus one makes decisions that affect just how flexible the application will be.

The closer the application development is to the deployment choices the less flexibility needs to be built into the application. For example when a Hospital has their internal IT develop a mobile application, they already know the deployment architecture and organizational policies. Thus they can hard-code some of these choices and policies. For example: These developers can know they will be using normal HTTPS, users will be authenticated to one directory (not federated), and the clients will always be devices that internal IT has endorsed as meeting their mobile-device-policy which includes mobile-device-storage-encryption. One can see how knowing this makes the Application development easier. I however do caution even these developers, as things change far too often and when they do there is usually little time to ‘fix’ the application.

Application being designed to be distributed broadly; such as in the Apple App Store, or Android Play Store; clearly need to be more configurable, robust, and defensive. They don’t know if users are going to use HTTP Authentication, oAuth, or SAML; and clearly don’t have any idea which resources will be authorized.

It might be a very good idea for a Healthcare Application to force the use of HTTPS. It surely is a good idea that this Application design do everything possible to prevent data from being stored onto the mobile-device. Any data that does need to be stored onto the device should be somehow protected, might be through encryption but might not.
Some good resources, again NIST based are:

Note that Healthcare is working on Functional Controls for Security and Privacy in EHR technology. This is being done with ISO-14441 and HL7 Functional Model. These are mostly well aligned with general-purpose security and privacy functionality specifications like NIST 800-53, with sometimes some healthcare specifics.

Balancing Security Controls with Operational Deployment Choices.

Ultimately Security Risks need to be addressed as soon as they can, but not sooner than they should be addressed. Any Security/Privacy Risk not addressed fully need to flow down to the next design level. That is any risk that can be addressed in software design should be addressed there, but many risks tend to need operational choices and possibly physical controls. Transparency is important: Describing the assumptions that were included in the design, what controls does the design enable, and what residual risk must the next design handle.

FW: HHS is expanding its health information privacy enforcement team

noreply@blogger.com (John Moehrke) — Fri, 01 Mar 2013 15:47:00 +0000

Great opportunity to get on the 'inside'.Of course it has the down side of being on the 'inside.

From: OCR HIPAA Privacy Rule information distribution [mailto:OCR-PRIVACY-LIST@LIST.NIH.GOV] On Behalf Of OS OCR PrivacyList, OCR (HHS/OS)
Sent: Thursday, February 28, 2013 8:59 AM
To: OCR-PRIVACY-LIST@LIST.NIH.GOV
Subject: HHS is expanding its health information privacy enforcement team

February 27, 2013

Several Health Information Privacy Specialist positions are available in the Department of Health and Human Services (DHHS), Office of the Secretary, Office for Civil Rights (OCR), Office of the Deputy Director Health Information Privacy (ODDHIP) in Washington, DC. OCR provides the oversight, leadership, and coordination necessary to ensure that individuals have nondiscriminatory access to HHS services or programs and that the privacy and security of their health information is protected. The Division of Health Information Privacy enforces the HIPAA Privacy and Security Rules and the confidentiality provisions of the Patient Safety and Quality Improvement Act. OCR is seeking experience in privacy and security compliance and enforcement as well as in the areas of policy, outreach, and health information technology systems.

For more information on these positions, go to http://www.usajobs.gov/ and enter the corresponding job announcement number.

Titles and job announcement numbers:

Health Information Privacy Specialist, GS-0301-13/14 HHS-OS-MP-13-846340

Health Information Privacy Specialist, GS-0301-13/14 HHS-OS-DE-13-846235

The open period for these positions is Wednesday, February 27, 2013 to Tuesday, March 12, 2013.

NOTE: Applicants must apply separately to each announcement in order to be considered.

For more information about OCR's health information privacy activities, visit our web site at http://www.hhs.gov/ocr/privacy/index.html.

Fake it properly

noreply@blogger.com (John Moehrke) — Sun, 10 Feb 2013 20:29:00 +0000

The article "Are You Faking It?" is an interesting read for anyone dealing with De-Identification, specifically Pseudonymization. I cover Pseudonymization in a few articles, it is the art of modifying identifiers on data in a way that preserves linkage over time of data about the same subject, but breaks the ability to figure out who that subject is. The process of Pseudonymization is to create pseudonym for the subject, or an alias. The process of Anonymization simply removes identifiers outright. Both are forms of De-Identification. There are special cases of De-Identification that meet specific government requirements, such as HIPAA.

The really useful part of 'Are You Faking It' that there is guidance on the creation of pseudonyms. Specifically guidance on what NOT to do as well as what to do. Interesting result of poorly done database shuffling. The article starts by explaining some actual negatives of poorly executed faked databases. It then explains that even faked identities need to be carefully crafted. Finishing with an explanation of the USA SSN format, and how to fake identities that can’t possibly be real SSN values.

It is interesting that SSN starting with 666 have been reserved and will never be issued. Given the religious sensitivity of 666 it is not too surprising. I wonder how many other identity systems do this same reservation. It does open up a really great pattern for pseudonyms. Since the pseudonym is not associated with an actual human, there should be no problem using it as a fake identity. Further since it is rather easy to see, it will be a quick way to identify data that are pseudonymized.

De-Identification and Pseudonymization of Healthcare Information

Defining Privacy

noreply@blogger.com (John Moehrke) — Mon, 28 Jan 2013 17:26:00 +0000

Privacy is a very important Human Right, yet very hard to define. I am very encouraged by all the efforts in Healthcare on Privacy. These efforts are caused by the interest, yet made complex by the lack of a simple definition for Privacy. The problem with defining Privacy, even in Healthcare, is that there really isn't a single definition of Privacy. The reason is that Privacy has multiple dimensions. Controllership, Confidentiality, Accountability, Accounting, Correctness, Transparency, Disclosure, Consent/Authorization, etc. This is why Privacy is often described in terms of Privacy Principles. As the concept of Privacy is made up of all these various dimensions.

There are some standards that have definitions for Privacy

ISO/IEC 2382-8:1998 -- Freedom from intrusion into the private life or affairs of an individual when that intrusion results from undue or illegal gathering and use of data about that individual.
ISO 7482-2:1989 -- The right of individuals to control or influence what information related to them may be collected and stored and by whom and to whom that information may be disclosed.
AHIMA -- The quality or state of being hidden from, or undisturbed by, the observation or activities of other persons, or freedom from unauthorized intrusion; in healthcare-related contexts, the right of a patient to control disclosure of protected health information.
Countries like Canada -- (1) The claim of individuals, groups or institutions to determine for themselves when, how, and to what extent information about them is communicated to others. [Defined by uses this definition from A.F. Westin, Privacy and Freedom (1968). Basis for Privacy Act of 1974 (P.L. 93579; 5 U.S.C. § 552a).] (2) The right of an individual to live free of intrusive monitoring of their personal affairs by third parties not of their choosing.

I find that it is better to understand the Privacy Principles in order to understand what the term Privacy really means. See some of the foundational Privacy Principles.

The OECD (Organization for Economic Co-operation and Development) Privacy Principles are considered an utmost set of High-Level Privacy Principles because they are widely accepted, and they are the foundation of the European Union privacy regulations.
The “Privacy by Design” by Ann Cavoukian, Information & Privacy Commissioner of Ontario, Canada; Design principles are more targeted at task of systems design.
International Safe Harbor Privacy Principles
The USA Whitehouse consumer principles have been published just last year and therefore carry more modern wording and readability while still maintaining the same goals.
The philosophy highly influencing the Whitehouse that the consumer understands the context of their interaction Privacy As Contextual Integrity, Helen Nissenbaum
USA FTC – Fair Information Practice Principles
Etc – EC/EU, Canada, UK, AU, etc…

The OECD Privacy Principles are as good as any to review

Collection Limitation Principle -- There should be limits to the collection of personal data and any such data should be obtained by lawful and fair means and, where appropriate, with the knowledge or consent of the data subject.
Data Quality Principle -- Personal data should be relevant to the purposes for which they are to be used, and, to the extent necessary for those purposes, should be accurate, complete and kept up-to-date.
Purpose Specification Principle -- The purposes for which personal data are collected should be specified not later than at the time of data collection and the subsequent use limited to the fulfilment of those purposes or such others as are not incompatible with those purposes and as are specified on each occasion of change of purpose.
Use Limitation Principle -- Personal data should not be disclosed, made available or otherwise used for purposes other than those specified in accordance with Paragraph 9 except: a) with the consent of the data subject; or b) by the authority of law.
Security Safeguards Principle -- Personal data should be protected by reasonable security safeguards against such risks as loss or unauthorised access, destruction, use, modification or disclosure of data.
Openness Principle -- There should be a general policy of openness about developments, practices and policies with respect to personal data. Means should be readily available of establishing the existence and nature of personal data, and the main purposes of their use, as well as the identity and usual residence of the data controller.
Individual Participation Principle -- An individual should have the right:a) to obtain from a data controller, or otherwise, confirmation of whether or not the data controller has data relating to him; b) to have communicated to him, data relating to him within a reasonable time; at a charge, if any, that is not excessive; in a reasonable manner; and in a form that is readily intelligible to him; c) to be given reasons if a request made under subparagraphs(a) and (b) is denied, and to be able to challenge such denial; and d) to challenge data relating to him and, if the challenge is successful to have the data erased, rectified, completed or amended.
Accountability Principle -- A data controller should be accountable for complying with measures which give effect to the principles stated above.

It isn't even as simple as these 8 Privacy Principles. There are regional nuances, personal decisions, concerns for safety/health, etc. Often times there is complaints that these Privacy Principles get in the way of Medical Ethics the actual cases of conflict are few and usually well understood by those affected.

So, you can see there isn’t one concept that makes up “Privacy”. Even Wikipedia has trouble simplifying it http://en.wikipedia.org/wiki/Privacy

Security Considerations: Healthcare RESTful Resource specifications

noreply@blogger.com (John Moehrke) — Fri, 25 Jan 2013 13:30:00 +0000

This topic came up last week at the HL7 meeting, that is, just how much should FHIR say about security. Those of us that have thought about this quite a bit, including many who have actually coded the RESTful services; come down on the side of : There is very little that the RESTful Resource specifications (FHIR, DICOM-WADO-RS, IHE-MHD, etc) should say, but they should recommend robust implementations that have wide potential use of the security layer built into the transport, specifically HTTP(S).

I recommend everyone that wants to help develop this to get involved in the IHE-IUA profiling effort. There is actually much to be said, but it can be said in one place and re-used by all those that are working hard on making good Healthcare RESTful Resource definitions.

Shown pictorially as the RED layer

The Medium Length answer is…

There is good stuff already available, use it

a) Use HTTPS to protect against most network risks (encryption, hashing, server authentication), with proper certificate validation including revocation checking
b) Have the ability to use Client Certificates on HTTPS to close the client side risks and identify the client system to the server, with proper certificate validation including revocation checking
c) Have the ability to leverage HTTP authentication mechanisms.
c.1) Internal to an organization the use of Kerberos (Microsoft Active Directory) is common. This is profiled in IHE as EUA
c.2) Between large organizations the use of SAML is a mature Identity Federation. This is mostly profiled in IHE as XUA, but needs to leverage the SAML-SSO-PROFILE from OASIS for browsers.
c.3) In cases where the user is more mobile, or less associated with a large organization, or simply using more lightweight systems, or where using third-party services/applications, or etc… This is the space that the IHE IUA profile is looking to fill. This profile likely will leverage oAuth 2.0; but it is in development now. (The subject of the e-mail that started this thread)
d) Audit Logging through either the FHIR SecurityEvent, or IHE-ATNA should be encouraged.

There are various other things that will come together after we get this far. Much of this advanced stuff is actually inside client or server and thus not needing to be exposed in a RESTful Resource specification (like FHIR). But some of the work we are doing now in the HL7 Security WG will impact user identities, data tagging, and obligations on release of data.

The longer answer, which is really the start of the security project:
The HL7 Security WG has a handbook published for HL7 Standards development that directs the standards developers on how to consider Security (and Privacy). http://wiki.hl7.org/index.php?title=Cookbook_for_Security_Considerations I will be using this process for FHIR, while at the same time doing it for IHE, DICOM, and others. Thus I intend on addressing many use-cases as I can.

I suggest we apply security/privacy in phases. Generally speaking there is little impact on FHIR in the first few phases, where applying Security in the Transport layer. For the vast majority of use-cases one simply plugs in common HTTP based security. Further the choices in HTTP based security can be done very late in the implementation phases with little impact on applications, provided they use mature HTTP stacks. Just like FHIR is leveraging as much as possible from common toolkits, we should do the same for Security.

But as we mature our use of RESTful Resources and fine-grained security we will need to get more involved. This because the more fine-grained security is not commonly used in non-healthcare REST use-cases. It isn't a total void either, so we will use existing standards. We just will eventually need to get more detailed. Much of this more detailed work is being modeled now in the HL7 Security WG. Ultimately we will need to define security-tags that could be carried on every resource, content encryption, partial encryption, non-repudiation, etc.

Consent Management
On a related note, but not completely off base, I would like to see a “Consent” resource, modeled off of a combination of the HL7 SOA Access Control Service, and the HL7 CDA Consent Directive. We should start basic. Not because it is hard, but because there are far more impactful risks to worry about first. Using risk assessment to guide our priorities.

Simple to Start
First, let’s focus on HTTP based REST. For most of the RESTful work going on now it is using HTTP, FHIR has visions of going beyond HTTP. I am not trying to exclude the other models, just trying to have a coordinate analysis. The other transports that are envisioned for FHIR will be able to leverage much, but will also have some differences.

Initially one just deals with the high-impact risks to security, that is risks to “Confidentiality”, “Integrity”, and “Availability”. The high-impacting risks are easy to deal with in HTTP, one just applies HTTPS. Normal HTTPS doesn't deal with all of the high-impact risks, but is a foundational starting point. There are alternatives, but those alternatives usually come into a system when dealing with fine-grained risks and rights. For the sake of our efforts, lets start simple.

Encryption, Hashing, and Server Authentication
HTTPS is not without controversy, we should warn the users of FHIR that they should be careful about validating the server certificate. Normal browser behavior, and some HTTP toolkits, don’t do a good enough job here. Such as they don’t check revocation lists, they accept a far too wide list of Certificate Authorities, etc. This is a RISK that we identify, but don’t mandate any solution, as the solution would be a policy decision. But we do identify it as a risk and we do flow that risk down to the next level of design. This is a great example of what the Security WG recommends in the Security Considerations Cookbook.

Client Authentication
I would like to also recognize the risk that the service side doesn't know what system is requesting the resource when simply using HTTPS (as HTTPS only authenticates the service, not the client). There are some alternatives. These alternatives are part of the IHE Internet User Authorization (IUA). Many of these alternatives are again totally transparent to FHIR as a specification, the more transparent we can make IUA the better. IUA is not trying to replace the most basic solutions.

High level alternatives (various combinations and effectivity)

Authenticate the system
Authenticate the software
Authenticate the user

Ultimately we are trying to figure out

If the transaction should happen, that is to test Access Controls
to record that the transaction was allowed or denied and why, that is to record Audit Log

Client System Authentication
Some will find the most easy solution is to use Client side Certificate Authentication. Called Mutual-Authentication, and the core protocol in the IHE-ATNA profile. This is technically easy, but administratively hard. If you are making a fixed number of connections to clients, this is likely a good choice. For example a corporate issued device that has controls on the device to assure it is secure, like persistent-memory encryption and the like. Easy to issue a certificate to these and be done. And when the device is lost/stolen the certificate gets revoked and magically it no longer has access.

Client Certificate Authentication is sometimes sufficient, sometimes too hard, sometimes unnecessary. Hence why it should not necessarily be mandated, although it would be highly recommended to be compatible and thus any implementation should have the capability.

Use-Cases
At this point we need to get more use-case specific. This is because dealing with the next level of granularity requires different pathways. From a high level we are speaking of two basic patterns. PUSH and PULL. Specifically these break down into the Client side Access Control and Audit Logging; vs the Service side Access Control and Audit Logging. At the modeling level you always presume these are happening at both sides. One models each side at a time. If either side is not satisfied that access should be given, then it stops the disclosure. Sometimes, like in the case of browser based applets, the client access control modeling is set to NULL.

Client Access Controls
Generally the client must make the access control decision sufficient for the client’s purposes, and record the audit log sufficient for the client’s purposes. Yes this can sometimes be NULL. I would simply point out that a Client that is doing a Create operation is choosing to expose the content of a Resource to a Server. This is usually the use-case that one focuses the client access control decision on. However this client side access control decision is totally within the client, and thus not exposed on the FHIR modeling. yes the server should also have a say in if it will keep it our not, but the disclosure has already happened by the time the Resource gets to the server.

Further down the line, we will look at how the Client can handle the case where the Access Control decision comes with ‘okay, with strings’, otherwise known in security circles as “Obligations”. For example, where the client Pushes content (message, publication of a document, RESTful Create), but the content has restrictions on use. Such as no-re-disclosure, for-treatment-purpose-only, no-persistence, etc. Same is true about a Server returning a Resource. The HL7 Security WG is currently modeling this in abstraction right now for future standards availability.

Server Access Controls
The Server will also do an Access Control decision, and record Audit Log events. This is where most of the attention is focused, and with good reason. Because most data accesses are in Request/Response pattern, and the Server is the typical place to restrict access. It isn't the only model, some systems trust their clients to do access control decisions and thus don’t make any at the server side. Some do access control decisions in various forms in both places (or more).

What the IHE IUA (oAuth?), XUA (SAML), EUA (Kerberos), and ATNA (Client TLS) do is try to explain how a client can encode claims about identity and context such that the server can interpret them. Interoperability is focused on both sides being able to use the information. In this case it is the system, application, and/or user identity that is being communicated in a security token. The server uses as much as it needs to use to come to a decision to release the information requested. The security system does need to understand sufficiently the content of the RESTful Resource so that it understands the information requested, but the Resource specification doesn't really need to understand the security system. The security system, when faced with not enough information to allow the data to flow, denies the transaction, usually by claiming the requested information doesn't exist (so as to not allow a malicious probing to determine existence vs non-existence of information)

Impact on RESTful Resources (FHIR, DICOM-WADO, IHE-MHD, etc)
The hope for IUA is to make it as transparent to the Resource definition as possible. I have heard this need. I understand the desire to not have any URL parameter modification, sometimes this can be done. There is already rather transparent solutions in IHE-ATNA (Client TLS), EUA (Kerberos), and XUA (SAML). The IUA use-cases are different, and useful.

There is definitely an impact on application architecture and programming. Leveraging a mature programming infrastructure helps, but clearly there will be responsibilities. These responsibilities and behaviors are out-side-the-scope of the RESTful Resource specification. For example in properly maintaining cookies, or maintaining an application-secret. The least impact is that the client must support HTTP redirects, and allow the redirects to interact with the user in some cases.

Conclusion
Any RESTful Resource specification should have minimal specification for Security or Privacy. Not because it isn't important, but because Security and Privacy are layers that are built into tools and layers that are designed to do their work transparent to the RESTful Resource specification. Very clearly impacting an operational environment, and having some impact on application development.

What I would like to do is see how much of the above we can get agreement on. Once that list of capabilities is decided on, however small or large, we can start a Security/Privacy Risk Assessment. This will then show us what more we might need to do. Most of the time the additional risks are best handled in some design layer beyond the standards specification, so we simply document the risk in “Security Considerations” so that our reader is informed. But there are potential for risks that we need to hand over to further standards development.

See:

IHE efforts in RESTful security
Securing RESTful services
SSL is not broken, Browser based PKI is
How to Write Secure Interoperability Standards
Identity Proofing and Authentication -- Patient vs Provider
IHE mHealth Hackathon
The Magic of FHIR – The HL7 movement toward REST resources, away from v3 and v2
IHE Mobile access to Health Documents - Trial Implementation

Simplifying Security Audit Standards

noreply@blogger.com (John Moehrke) — Wed, 16 Jan 2013 17:32:00 +0000

There ARE Security Audit and Accounting of Disclosure Standards. I am constantly explaining why this is true. I blame History. Yes we used many standards organizations but we have coordinated the efforts so that they are already all in harmony

ASTM E2147 – Setup the concept of security audit logs for healthcare including accounting of disclosures
IETF RFC 3881 – Defined the Information Model (IETF rule forced this to be informative)
DICOM Audit Log Message – Made the information model Normative, defined Vocabulary, Transport Binding, and Schema
IHE ATNA – defines the grouping with secure transport and access controls; and defined specific audit log records for specific IHE transactions.
NIST SP800-92 – shows how to do audit log management and reporting – consistent with our model
HL7 PASS – Defined an Audit Service with responsibilities and a query interface for reporting use
HL7 FHIR - Defined a RESTful binding for the Security Audit Event, and thus provide a Query/Retrieve also
ISO 27789 – is defining the subset of audit events that an EHR would need

There is very little about IHE-ATNA specification. These other standards are where the real stuff is. I am however happy to use IHE-ATNA as the marketing tag.

Community of Experts
I have been involved in developing Security Audit Standards for Healthcare since I started working on Healthcare Standards. Back then there were a handful of people working on Security and Privacy standards for healthcare. We tried to get more people involved, but the reality is that Security and Privacy is simply not an exciting space. I get it, i am a security geek, and we are few. I still only need two hands to count the people working on Security and Privacy standards in Healthcare. They are retiring about as fast as they arrive.

The Standards that we do have in Healthcare for Security Audit all are well harmonized, because of the fact there are few people working on the domain. Even though we did the work in very different standards organizations It is the very fact that we did this work in many standards organizations that makes it hard to determine if we have Security Audit standards in Healthcare.

Abstract Model
The core standard that sets up the conceptual model comes from ASTM E2147. This defines the purpose of a security Audit Log, the uses of this audit log information, including how it is used to provide patients with accounting of disclosures.

This specification has been leveraged by many regional initiatives including in the USA the Meaningful Use Stage 2.

Data Model

We then needed to produce a schema that would meet ASTM E2147, and provide more specific guidance on how to describe that an event has happened. At the time there was much harsh competition between the various Healthcare Standards organizations. Again, not within Security/Privacy community. So we decided that ASTM was not the right organization to do this Data Modeling, and neither was HL7 or DICOM the right organization. IHE couldn't be used as they only profiled existing standards. So we chose a non-healthcare organization. IETF was at the time a very open organization, so we chose to go there. Unfortunately for us, IETF changed their rules of publication while we were developing. Thus by the time we finished RFC-3881 we could only get it published as Informative. Thus it couldn't be used for conformance claims, it wasn't normative.

Normative Data ModelWe then needed somehow to get the data model and schema that we developed in IETF RFC-3881 to be normative. By this time the Healthcare standards organizations were behaving better. More importantly is that Radiology was using RFC-3881, so the Imaging world needed the Normative schema more than other parts of Healthcare. So, we simply imported the RFC-3881 into DICOM and stamped it Normative.

Note that this did not produce a Audit Log Standard that was any different than RFC-3881, and this has nothing in common with any other part of DICOM. So, implementing the Audit Log Standard from DICOM does not require you to implement anything else in DICOM. It is completely independent.

Now days DICOM isn't exactly the same as the original vision in RFC-3881, because mistakes were found and because functionality needed to be added. So, now days if someone starts with RFC-3881 they will end up with not the same thing. I just this week noticed two more things that need to be fixed.

The normative specification is ISO 12052 --- aka DICOM. It is freely available. Specifically you want Part 15 - Security and Systems Management. Specifically you want in that text Annex A.5 AUDIT TRAIL MESSAGE FORMAT PROFILE

Transport binding to SYSLOG
Both DICOM and IHE chose to leverage the SYSLOG standard. This is the standard that is used in general purpose IT to collect audit logs from various devices (Firewalls, IDS, Databases, Web-Servers). The SYSLOG protocol comes in two flavors. The general problem of event transport suffers from various risks for which there is no perfect solution. The UDP version of SYSLOG does fail from the risk that it will loose events when the number of transactions per second become very large, but it is far more simple and doesn't fail in other ways. The TCP version of SYSLOG assures that all events will get recorded, but does need to have buffer management handled and even here the buffers can get overflowed. The TCP version also supports security through TLS, so does address some confidentiality and integrity risks.

So essentially this gives us a SYSLOG binding using XML payload. I will point out that IHE-ATNA is really nothing more than bringing forward the DICOM specification into a Profile for visibility.

Query Function
Up to this point there is the expectation that the Audit Record Repository is simply receiving all these events from various systems that are detecting and logging security relevant events. The expectation is that this system can have functionality to address Reporting, Alerting, Alarms, and such. This is product functionality. This functionality can be accomplished given the audit schema and the cooperation of all the systems logging events. The access control to this Audit Record Repository is also a very sensitive resource. This system has records retention requirements that are very hard to accomplish. The audit log record must be protected against many unintended and malicious risks. This is why there has been little developed in the space of Query on the Audit Log.

Query Service
HL7 PASS has produced a Service definition -- for what a Query might look like. This Draft Standard for Trial Use leveraged the very same Standards identified above. It simply added a Query and Retrieve transaction. This is now being looked at in HL7 to determine if there is really interest in further developing it. So far there has been little interest.

Security Audit Log on FHIR
The coolest thing to happen lately is that the HL7 FHIR project has take the same standards as above and created a RESTful resource out of them. This simple effort produces significant capability.

First, it is another way for an application to record that a security relevant event happened. HTTP is not a great protocol for this very chatty eventing (yes there are speedy solutions). Sometimes an application has easy access to RESTful technology and the effort to get more complex tooling will result in avoiding doing the audit logging completely. Thus we can accept that there is now an HTTP binding for recording an audit log event. I am not sure how this will be received at IHE, since IHE purpose is to reduce the number of ways to do one thing in order to converge on one method that everyone can implement with confidence. Adding HTTP binding could only be confidently used if all Audit Record Repositories implemented the service side.

Second, and more exciting, is that through the magic of REST there are now Query and Retrieve transactions on this same resource space. Yes this opens up a huge question of Access Control to these transactions. More risky is that REST also magically adds Update and Delete; operations that should never be allowed on an Audit Log. These risks are identified in the FHIR specification. The security layer that IHE is working on with IUA should support these use-case needs.

Application Level Functionality
ISO TC215 is balloting right now ISO 27789 - Health Informatics - Audit Trails for electronic health records. This goes up another layer and explains how one would apply the very same standards above to an EHR. This includes a set of use-cases that are supported. This is simply an application of the same standards to EHR technology.

The HL7 EHR-Functional Model has some of this, but not quite to the same level of detail. The expectation, I hope, is that they will leverage ISO 27789, thus carrying on the tradition of harmony.

Conclusion
Yes we used many standards organizations but we have coordinated the efforts so that they are already all in harmony

ASTM E2147 – Setup the concept of audit logs for healthcare including accounting of disclosures
IETF RFC 3881 – Defined the Information Model (IETF rule forced this to be informative)
DICOM Audit Log Message – Made the information model Normative, defined Vocabulary, Transport Binding, and Schema
IHE ATNA – defines the grouping with secure transport and access controls; and defined specific audit log records for specific IHE transactions.
NIST SP800-92 – shows how to do audit log management and reporting – consistent with our model
HL7 PASS – Defined an Audit Service with responsibilities and a query interface for reporting use
HL7 FHIR - Defined a RESTful binding for the Security Audit Event, and thus provide a Query/Retrieve also
ISO 27789 – is defining the subset of audit events that an EHR would need

Note there is very little in the IHE-ATNA specification. These other standards are where the real stuff is.

For More information

IHE efforts in RESTful security

noreply@blogger.com (John Moehrke) — Wed, 09 Jan 2013 18:41:00 +0000

This is a simple update at the beginning of the year and IHE development cycle.

First, the slate of things that IHE IT Infrastructure (ITI) committee is working on this year is large. Here is a summary of the work items for the ITI committee. I state this because last year ITI got one profile completed, the Mobile Health Documents profile that I wrote. So I want to encourage extra support from people who don't usually get involved.

The specific work item of interest is one that I am calling “Internet User Authentication/Authorization” (IUA). Yes, I am being cute with the acronym since there is already EUA and XUA. They are all very functionally similar, just focused on different technology stacks.

IHE ITI is right now in the stage of gathering use-cases and thus the 'interoperability needs’. In the coming months these needs will be evaluated against available standards. The most likely standard at this point is oAuth 2.0. Due to the scope and expected standard, this is more than just user authentication as it also includes application authorization. Much like the scope of oAuth. We are not purely driven by oAuth capability, but like oAuth the need is based on the use-case problems. The problems of Internet based Authentication and the problems of mobile devices and mobile applications.

This profile is expected to be used widely and not just include IHE use-case. IHE is gathering usecases from HL7-FHIR, DICOM-WADO, and Continua. This profile is also expecting to leverage work that has already gone on. For example the RHEx work done in the USA under the S&I Framework. This profile is also expecting to be in harmony with the efforts of the USA NSTIC effort.

The development work will be done through a Google+ community. This is an open community due to the interest from many organizations. The workspace for the development will be on the IHE FTP site

There are two formal telephone conferences prior to the next face-to face. On 2/13 and 3/13 at 8am central. These are the more formal workitem focused with the whole ITI committee. Right now we have a weekly meeting Wednesday mornings at 8am central. However this is going to change. There will be some form of survey out to discover the best time. This survey will utilize the Google+ community so sign up. The IHE calendar is published at http://www.ihe.net/calendar/

The next face-to-face meeting for the IHE ITI committee is March 18-22, in Treviso Italy. This meeting is where we focus on finishing the Vol 1 material, and doing the standards analysis. The result of this meeting should be the selection of a standard to develop.

IHE is an open and transparent organization, but in order to have voting privileges one must be a member in good standing. http://www.ihe.net/governance/index.cfm

IHE Encryption choices

noreply@blogger.com (John Moehrke) — Tue, 01 Jan 2013 16:17:00 +0000

IHE now has full coverage on how to Encrypt sensitive data.

The following table comes from the IHE-Document Encryption (DEN) profile. It was created in that supplement as a way to verify the need for the parts of the DEN profile. This table recognizes that IHE-ATNA already covers most of the encryption needs, especially network transactions. However there is a need for encrypting a single Document at a time, and for encrypting XDM removable media. These needs are covered in the DEN profile.

The following table uses a large “X” to indicate the best solution, the solution that is recommended and optimal for that use-case. The use of “(x)” is an indication of where there is support in a sub-optimal way; usually this choice is more complex and doesn't fully handle key management. Multiple solutions can be used as well. For example one can use Document Encryption, and also XDM media encryption.

Use-Case	Doc Enc (CMS)	XDM Media Enc (CMS)	ATNA (TLS)	ATNA (WS-Sec)	XDM Email option (s/mime)	PDI privacy option (CMS)
Point-to-point network exchange between machines	(x)		X	(x)
Network exchange between machines in different trust domains	(x)		X	(x)
Online exchange of documents where partially trusted intermediaries are necessary	X			X
Exchange of medical documents using person-to-person Email	(x)				X
Media data (DICOM) exchange between healthcare enterprises using physical media	(x)	(x)				X
Exchange health records using media	X	X				(x)
Media to media transfer	X	(x)
Patient Carried or Medical Records File clerk import	X	X
Unanticipated work-flows	X	(x)
Clinical trial	X	X
Multiple recipients of secure document	X	X
Sharing with receivers only partially known a priori, a group or a role	X	X				(x)
Partial encrypted XDM submission set	X

Note that there are other uses of encryption, but they fall outside the scope of Interoperability. For example there is Whole-Hard-Drive-Encryption, but in that case the same software that is encrypting is decrypting and thus there isn't an Interoperability need. Yes there still is a need to use good quality encryption algorithms, but this need is based on staying away from bad encryption algorithms, which is a standards issue but not an interoperability standards issue. Any whole-hard-drive-encryption solution will work just fine as long as it uses quality encryption algorithms. This is different than the need to have an interoperable solution for removable media, which the new DEN profile provides.

Additional Information

Most Interesting Posts of 2012

noreply@blogger.com (John Moehrke) — Mon, 31 Dec 2012 21:29:00 +0000

Simply here are my top posts from 2012 (combination of Google Analytics and Blogger stats)

1. Meaningful Use Stage 2 -- 170.202 Transport (Note critical clarifications later)

2. IHE ITI mHealth Profile - Public Comment (hackathon soon)

3. Universal Health ID -- Enable Privacy
4. IHE - Privacy and Security Profiles - Audit Trail and Node Authentication
5. Patient Identity Matching
6. The Basics of Cross-Community Patient Discovery (XCPD) - Guest blog by Karen Witting
7. How to apply Risk Assessment to get your Security and Privacy and Security requirements

It gets less clear after these, but the Topics page is next most popular.

January I explained how to build an HIE using IHE, reminded Healthcare that backup needs to be distributed, kicked off Data Segmentation for Privacy Initial Review, Pointed out more real HIE/HIO policies, Introduced the IHE Cross-Enterprise Workflow profile, explained why although SYSLOG is a lossy protocol it is not only good enough but the best solution for Security Audit Logging, and explained how to properly Audit Log a Query transaction

February I explained ATNA auditing of CCOW context changes, asked for Simple and Effective HIE Consent while showing there is more complex ones in the future, helped some understand that Encryption is not a wonder drug and thus Encryption is like Penicillin, took pride in participation in NwHIN Exchange -- Impressive success even if my company isn't directly involved, more reminders that security is hard by explaining that A Bad Random Number Generator will produce Bad Security, and one of my strongest positions is that a Universal Health ID is necessary to Enable Privacy.

March was my most prolific by far with 20 articles: reacting to political statements of Complexity only to explain that Complexity is clearly in the eye of the beholder, Meaningful Use Stage 2 :: SHA-1 vs SHA-2, I breakdown and build up a Published White Paper from the Health IT Symposium, advertize availability of IHE ITI Educational Materials available, have Karen Witting (IBM) guest blog NwHIN-Exchange use of XCPD for Patient Discovery and also The Basics of Cross-Community Patient Discovery (XCPD). A short tutorial on How to apply Risk Assessment to get your Security and Privacy Requirements, Explain how an HIE can Enforce Security and Privacy Policy in a XDS Registry, Finally see Meaningful Use Stage 2 means Secure and Privacy Protecting, Again explain the the benefit of an HIE, Stepping stone off of FAX to Secure-Email, Meaningful Use Stage 2 -- 170.202 Transport, Meaningful Use Stage 2 seems to support Security, Huge HIE -- the Care Continuity Consortium, Healthcare is not secure - trust suffers, and announce more IHE - ITI NEW Educational Webinar Series

April clearly I was exhausted with just 4 articles. The explanation this month goes only to explaining that Patient Data should not appear in the Security Audit Log. Otherwise I was just frustrated that S&I Framework Data Segmentation for Privacy seems to want to do nothing but go Around and Around in circles, while over seas The French Health Information Systems documentation is now in english, and that Meaningful Use only wants Transmission into Oblivion which fortunately later got resolved.

May starts with another Guest blog by Karen Witting (IBM) Technology Churn as a distraction. I provide some practical viewpoints that Security is not just technical but more so Operational concern, I introduce and make standalone from XDS a description of Healthcare Metadata, Quick review of ONCs New Guide on Health Information, Privacy ans Security and Meaningful Use, and point out that IHE Connectathon has a fantastic FREE and Internet facing tool for Testing your XDM implementation.

June finds a security problem where many would not have found it in the Leap Second, yes it has security and privacy relevance, I provide Constructive comments on Data Segmentation for Privacy although not all were eagerly received, Help people understand that User Authentication is not a one-size-fits-all, and Introduce for the first time the IHE ITI mHealth Profile - Public Comment.

July I have some constructive comments on the Implementation Guidelines for State HIE Grantees on Direct..., help people understand that yes Direct messages can and will be "delegated/forwarded", gave a presentation on IHE Document Digital Signature - Non-Repudiation, and asked for comments on the mHealth profile that is a RESTful interface to XDS.

August I introduce the concept of Identity - - Proofing, more MU2 questions about Minimal Metadata or Karen's Cross or just Minimal Metadata which turned out to be neither but rather XDM over s/mime or XDR over SOAP. Another Karen Witting guest blog on Effective Standards Evaluation. Frustrated that perceptions are taking over with The Emperor has no clothes - De-Identification and User Provisioning, and two more external events HL7 WGM - Introduction to Security and Privacy, Texas HIE Consent Management System Design

September included Level setting on Level of Assurance, Advanced Access Controls to support sensitive health topics, The Magic of FHIR, IHE Mobile access to Health Documents - Trial Implementation, Meaningful Use Stage 2 - Transports Clarified, MU2 Wave 1 of Draft Test Procedures -- Integrity P...

On The Meaningful Use Stage 2 Rules, Meaningful Use Stage 2 : Transports Meaningful Use Stage 2 - Audit Logging - Privacy a..., and Direct addresses- Trusted vs Trustable

October I point out more free and open Testing for your ATNA Audit Log implementation, explain that there really are differences between Identity Proofing and Authentication -- Patient vs Providers, muse complaints that Direct has difficult requirements for no good reason, wish for MU Patient Engagement - Activity History Log, Look at the security requirements in 2014 Draft Test Methods: Wave Four, parse what MU2 - Encryption and Hashing mean, and help the reader understand Patient Portal - view, download, TRANSMIT.

November has some politics in Effective (Cybersecurity) Regulations - focus on What not How, Thankful and Hopeful for Healthcare progress, introduce a new work item in IHE-IUA - Internet User Authentication for REST, kickoff IHE mHealth Hackathon, and summarize IHE ITI Planning for 2013

December I add one more profile to the IHE - Privacy and Security Profiles - Document Encryption, finished my chapter in a Book published on Healthcare Information Technology, express some way to get security considered in even Modular EHR certification, and now IHE ITI slate for 2013-2014 development is fixed.

Big year. I wish there had been more interest in

But that is okay, I got these concepts baked into my chapter in the Book published on Healthcare Information Technology

IHE - Privacy and Security Profiles - Document Encryption

noreply@blogger.com (John Moehrke) — Mon, 31 Dec 2012 03:48:00 +0000

IHE Document Encryption supplement includes two more ways to encrypt documents.

There is a method included for encrypting just a single Document that can be used to encrypt any document type, and thus be carried on any transport. This Encrypted Document can be carried using XDS/XCA/XDR/XDM, but may also be carried by any other means (e.g. HL7 MDM).
The second method is applied to XDM physical media. With the XDM encrypted media the whole XDM content and structure is encapsulated in an encryption envelop thus fully enveloping all the content that would be transferred on USB-Memory, CD-ROM, or any other media type.

These new methods of encryption are complementary to IHE-ATNA, XDM e-mail, and IHE-Radiology PDI Privacy option. The additional new use-cases are

Media to media transfer
Patient carried media for medical records clerk import
Unanticipated work-flows where media is used without knowing where it might be needed
Clinical trial where transportation of the content may be by many different transport mechanisms over time
Multiple recipients of secure document
Sharing with receivers only partially known apriory, a group or a role
Encryption of some documents in a submission set

Encrypted Document Content
The Content Profile in the DEN supplement defines how to encrypt a Document in a way that is independent of transport. There are defined ways to handle the XDS metadata when XDS metadata is used.

There are multiple key management methods to support a wide number of use-cases. The choice of key system used is defined by the Content Creator (the creator of the encrypted content). The movement of the key from the Content Creator to the Content Consumer is not defined, there are many ways that this can be done. The movement of the key should be done with care.

The Original document is encapsulated inside the encryption envelope, thus fully subsumed by the Encrypted Document object.

The Encryption Document is made up of a CMS (Cryptographic Message Syntax) [aka PKCS#7] envelope, MIME-header to define the content, and the encrypted Original document. Note that CMS is the core protocol used in S/MIME (Secure email), the core of the USA/ONC Direct Project.

XD* Metadata ramifications of Encrypted Document

When an Encrypted Document is transported using XDS/XCA/XDR/XDM, most XDS Metadata need not be changed.

There may be other logic (De-Identification) that may choose to change these metadata values: such as blinding, obfuscating, or pseudonym; but these decisions are outside of the scope of the DEN profile. (See the forthcoming IHE ITI De-Identification Handbook)

The hash, mimeType, and size values MUST be changed to reflect the actual Encrypted Document. The hash and size must represent the encrypted document, as these are defined in XDS metadata as representing the document stored in the Repository. The mimeType also must represent the encrypted document, which is now in the format of ‘application/pkcs7-mime’.

When using a non-IHE transport one might need to have a file-extension which would be “.p7m” which is recognized by many applications

Encrypted XDM Media

The DEN supplement also adds a Media Encryption option for XDM. This is a new option on the XDM profile that produces a fully encrypted XDM media. The Media directory structure is first ZIPPED, just as if preparing for the e-mail option. The zipped file is then encrypted using the same mechanism as defined for the Document Content; that is to encapsulate using CMS encryption. The result is a file that stats with XDMME, 3 digits, and ends in ‘.pk7’

Encryption Key Management

Recipients must support all key management methods to support the widest use-cases.

Digital certificates and private key utilize PKI. The IHE PWP and HPD profiles support certificate distribution and may be leveraged for some use-cases.
Shared symmetric key should be used only where there is some secure means to distribute the symmetric key. For example through some access control service that can be used to deliver the symmetric key upon authorized request for key retrieval.
Password-based key derivation must use a password based key derivation algorithm (PBKDF2 – RFC3211) to be sure to generate keys of appropriate strength. Poor password choice is still susceptible to brute force attack.

The biggest risk to presented is that the encrypted objects can be copied and brute force attacks used without monitoring and alerts. Encrypted documents and media should still be handled carefully.

Standards Used

Key Properties

Encryption at Document or Media (XDM)
Flexible Key Management (PKI, Shared-Key, Password)
Complementary with other (ATNA, XDM, and Document)

Standards

Cryptographic Message Syntax (CMS) [RFC5652]
MIME [RFC2045]
bulk encryption: AES 128, 196, 256 in CBC mode
digest: SHA256
signature: RSA
key encryption: RSA (certificate),AES (shared key),AES + PBKDF2 (password)

References

Status: Trial Implementation
IHE ITI Technical Framework

Vol 1: Section 32 – Document Encryption
Vol 3: Section 5.3 – Encrypted Document Content

Options added to other transactions

Vol 1: Section 16.2 - Add Encrypted XDM option
Vol 2b: Section 3.32 – Add encrypted XDM

Additional Information

Back links

This is part of a blog presentation of the IHE Privacy and Security Profiles Overview:

Help for your challenges with XDS-related Tech Framework documentation

noreply@blogger.com (John Moehrke) — Fri, 28 Dec 2012 15:59:00 +0000

FYI: IHE is trying hard to make their Document Sharing Metadata definitions more readable (aka XDS Metadata, or XD* Metadata, or XDS/XCA/XDR/XDM Metadata). The following is an open invite to help.

Attention XDS and Document Sharing implementers:

Many of you have identified concerns about the implementation of XDS Metadata as described in the ITI Technical Framework Volume 3, Section 4.

As a result of your feedback, the IHE IT Infrastructure Technical Committee is putting together an online focus group discussion to gain an understanding of those challenges and how they may be addressed through a revised version of ITI TF Volume 3 Section 4.

Your participation is critical to the success of any efforts to re-write or clarify volume 3, Section 4.

We ask all of those who feel they can articulate these challenges to respond with their name and their availability to attend an online focus group webinar on January 8th from 10am-11:30am CST.

Please contact Celina Roth at croth@himss.org and Gila Pyke at gila@cogna.ca as soon as possible with your availability. You will be sent a meeting invitation for the webinar.

Book published on Healthcare Information Technology

noreply@blogger.com (John Moehrke) — Wed, 26 Dec 2012 18:17:00 +0000

I wrote chapter 28 - "Unique Operational Safeguards in an Electronic Health Record and a Healthcare Information Exchange". The full title of the book is quite complex "Healthcare Information Technology Exam Guide for CompTIA Healthcare IT Technician and HIT Pro Certifications"

It isn't a full book like Keith writes; but it is my second offering toward a book. The first was a book that likely sold only 10 ceremonial copies in 1997 "Intranet Resource Kit". In neither book am I a big enough writer to make much mention on the cover.

I am very pleased with my chapter in the HIT book, 31 pages. 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.

This book has a large number of contributors, some that I know well. The set of 8 chapters that make up Part IV "Healthcare IT Security, Privacy, and Confidentiality" is coordinated by Lori Reed Fourquet. The chapters are anchored by Dixie Baker who starts off the section with "Building Trust"; Gila Pyke with "Risk Assessment and Management"; Dennis Seymour with "Physical Safeguards, Facility Security, Secure Systems and Networks, and Securing Electronic Media"; Sean Murphy with "Healthcare Information Security: Operational Safeguards"; Lisa Gallagher with "Architectural Safeguards"; Braulio Cabral with "Healthcare Cybersecurity Technology"; and Karen Bell with "Certification of HIT Products and Systems".

Others that I know well: Don Mon coordinated Part II on "Healthcare Regulatory Requirements". Floyd Eisenberg wrote "Using Healthcare IT to Measure and Improve Outcomes"; Marc Overhage "The Role of Healthcare IT in Improving Population Health"; John Glaser "Strategic Leadership and Management of Health Information Technology in Provider Organizations"; Judy Murphy "Healthcare Information Technology and Healthcare Policy"; Joyce Sensmeier "Navigating Health Data Standards and Interoperability"; Chris Apgar "Regulatory Aspects of Healthcare IT: Legal Best Practices and Requirements"; and so many more. It is shocking how many people contributed to this book.

Healthcare Security/Privacy

Security Tutorials on mHealth Security and Auditing - #FHIR

Security Education: mHealth Security and FHIR

Security Education: Security/Privacy Audit Logging and Reporting

De-Identification - Data Chemistry

Why De-Identify?

De-Identification Procedure

De-Identification is Contextual

Gross De-identification

Summary

See also: De-Identification

Privacy Consent State of Mind

Privacy Consent of OPT-IN

Privacy Consent of OPT-IN

Privacy Consent Policy

Privacy Consent: YES vs NO

Privacy Consent of Maybe

Privacy Consent is a Simple State Diagram

Other Resources

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

Access Control (Consent enforcement)

mHealth Solution

What is mHealth?

The mHealth Solution

Consent portability

mHealth is anything you want

Direct incompatibility with off-the-shelf e-mail

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

Direct Specification forces case-sensitivity when none is necessary!

Direct Continues to require custom software for healthcare.

Safety vs Privacy

Google creepy is not the same as Facebook creepy

Goldilocks Governance

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

HIE Patient Identity problem

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

Foundational ASTM healthcare standards re-approved

XDS Notifications

The XDS notification functionality methods are:

Document Management (Health Information Exchange - HIE)

IHE Security and Privacy in an HIE/RHIO

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

Healthcare: Fail Open vs Fail Closed

Other Information

User Identity and Authentication

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

Access Control (Consent enforcement)

Audit Control

Guidance on Deploying MU2 Secure Transport

Privacy and Security in Designing an mHealth Application

Privacy and Security considerations in Deployment of Mobile Software

Using Risk Assessment during Application Design

Balancing Security Controls with Operational Deployment Choices.

See Also: Security/Privacy Risk Assessment/Management

FW: HHS is expanding its health information privacy enforcement team

Fake it properly

De-Identification and Pseudonymization of Healthcare Information

Defining Privacy

Security Considerations: Healthcare RESTful Resource specifications

Simplifying Security Audit Standards

IHE efforts in RESTful security

IHE Encryption choices

Most Interesting Posts of 2012

IHE - Privacy and Security Profiles - Document Encryption

Help for your challenges with XDS-related Tech Framework documentation

Book published on Healthcare Information Technology