There’s an old saying that the great thing about standards is that there are so many to choose from. This is clearly evident in the Health Care IT arena. The standards landscape is getting a little crowded, despite the fact that the push to actually integrate and support these standards seems to take a back seat to refining and creating more and more of them. Right now, I’m dealing with several of these standards at once – SAFE, XAdES and CDISC ODM to be specific. And, this is just a tiny fraction of the health care IT standards collection – there are more than 200 entries on the so-called “short list” of standards that apply to electronic records in the industry.

As standards go, the SAFE specification is relatively simple, as it is mainly a set of guidelines for how signatures must be created and validated as opposed to a format specification. The XAdES standard, in contrast, is a more formal XML-based digital signature specification that can provide timestamping and embedded revocation information. A few forms of XAdES signatures may
be made SAFE compliant, but the SAFE specification does not entirely overlap the XAdES standard; not all XAdES signature forms are SAFE compliant.

XAdES, specifically XAdES-X-L and XAdES-A, seems well suited for use in various CDISC [Clinical Data Interchange Standards Consortium] standards, including the Operational Data Modeling standard. The ODM standard provides an XML schema for maintaining clinical trial results.

I don’t really have a problem with the proliferation of standards in the health care IT space so long as these standards aren’t redundant, and in this particular case they aren’t. However, the more standards that are devised, the more expensive it’s going to become for applications to be compliant, especially when there are standards that are tangentially related, and then more standards have to be created to formally correlate them.

This week brought with it the exciting news that Exostar is launching a federated identity service for the aerospace industry.

Next week, however, Exostar will launch a new capability, the Federated Identity Service, that does the process of “credentialing” on behalf of Exostar’s members, ensuring that individuals that attempt to use the systems of the community or its members are who they say they are — and are authorized to use the systems they are trying to access.

The concept behind federated identity is a simple one. Leverage existing investments providing identification / authentication of users, and build an authorization structure that works across multiple applications, systems, companies, and vertical markets. The U.S. Government has their E-Authentication initiative, there are also the Shibboleth, Liberty Alliance, and WS-Federation standards. Tons of companies have interests and products in this area including Oracle, Microsoft, Novell, Sun, Symlabs, Ping Identity, CA, Siemens, IBM, etc. Other industry groups are looking to stand up their own federated identity infrastructures, similar to that performed by the aerospace industry.

The fortunate thing is that the SAML 2.0 standard seems to be the standard that most products, standards, and organizations are moving toward. However, just because everyone settles on SAML doesn’t mean that everyone will interoperate. I suspect there still needs to be some federating of the federation standards before more universal adoption is achieved.

And now let’s look forward 5-10 years toward a future where the entire Internet shares a federated identity infrastructure; where you can use one single CardSpace card and/or OpenID login to get into your email, bank accounts, paypal, social security benefits, buy things from Amazon, and forward your mail. Now, an identity thief needs to steal just one username and password and everything goes up in smoke.

I was at the Microsoft Health and Life Sciences Developer Conference last week in Atlantic City, where I got the chance to listen to a good presentation from Les Jordan of Microsoft about 21 CFR Part 11 compliance. The talk centered around how Microsoft is trying to make dealing with the V Model more manageable for validated application as it pertains to applying security patches.

One interesting point that was made was that if there is a security patch available for a validated system, and that patch has not been applied to that system, then the system is not considered by the FDA to be compliant. However, full qualification tests must be run and documented while applying the patch, which takes time. The issue that this creates is that security patches are released frequently enough and validation testing takes long enough such that validated systems become a bit of a mess to manage.

So, what can be done about this? One important step that was discussed is this: since the part 11 requirements only cover patches that affect the validated part of the system, any security updates released for non-validated portions of the platform should be pushed immediately. For example, a printer driver update for a printer that will never be used by a web server machine can be applied without testing, since it does not affect the validated functionality of the system. However, this just makes the problem a little more manageable; it doesn’t eliminate it completely.

If a validated system is out of compliance in an unpatched state but also out of compliance when a patch is applied without formal testing, I’m of the opinion that a “patch first, test second” approach should be taken. True, this may break some application functionality, but I would much rather have a broken application than an insecure one handling my personal data. [This assumes that compliance is taken as a binary data point: compliant or not-compliant. If there are degrees of non-compliance, I may change my mind about this.]

Aside from that, the only other option I can think of is to throw more resources at patch validation so security updates can be rolled out quickly. But, as we all know, security is not a value-add, so the goal is typically to throw as little money at security services as possible so as not to lose customers or run afoul of the law.

ISO 17090:2008 Parts 1-3 were released on February 14. But is this a new standard or just a rehash of existing standards? ISO 17090 is not new (previously released in 2002), but there’s no clear indication on how it has changed.

ISO 17090 sets out PKI standards and interoperability requirements for the healthcare industry – including certificate profiles, CPs, etc. I’d love to be able to read those standards (they’re about $125 each) to see how they compare to already existing standards such as SAFE and the Federal Bridge PKI. SAFE’s bridge is explicitly for the healthcare industry, but complies with the Federal Bridge certificate policies which spans multiple industries.

Has the new updated version taken into account these existing standards? Does the ISO standard include encryption certificates? Neither SAFE nor the Federal Bridge focus on encryption (it’s allowed in certificate profiles, but not for identity).

Either way, published standards for PKI interoperability (and not just technical standards) are good for the industry because it allows more PKIs to interoperate and “trust” each other. This gets more certificates in to the hands of healthcare professionals and providers and allows them to protect electronic health records – whether that’s a doctor sending a signed e-mail to a pharmacist containing a scrip for a patient, or pharmaceutical companies submitting electronic information to the FDA for approval.

No offense to the post office, but bits on a wire move a heck of a lot faster than they do.

The IESG secretary has announced a proposed recharter of the IETF PKIX working group.

The PKIX Working Group was established in the fall of 1995 with the goal of developing Internet standards to support X.509-based Public Key Infrastructures (PKIs). Initially PKIX pursued this goal by profiling X.509 standards… most PKIX-generated RFCs are no longer profiles of ITU-T X.509 documents.

PKIX is now seeking to redefine itself not solely by its profiling of ITU-T standards, but also developing standards that are useful for PKI and related systems.

An example of this type of RFC is the informational RFC 4158, Internet X.509 Public Key Infrastructure: Certification Path Building, which I co-authored and edited. It fills a need not expressed by any ITU standard document—providing useful information to the developers of a certification path building system. The IESG’s recommendation to change the PKIX working group charter is welcome, perhaps a little overdue.