Foundational ASTM healthcare standards re-approved

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

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

• 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

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)

• Healthcare Metadata
• Minimal Metadata
• What is the benefit of an HIE
• Karen's Cross or just Minimal Metadata
• HIE using IHE
• Texas HIE Consent Management System Design
• The French Health Information Systems Interoperability Framework -- Now available in English
• One Metadata Model - Many Deployment Architectures
• Critical aspects of Documents vs Messages or Elements
• Using both Document Encryption and Document Signature
• Document Encryption
• XDS/XCA testing of Vocabulary Enforcement
• Where in the World is CDA and XDS?
• Universal Health ID -- Enable Privacy
• HIE/HIO Governance, Policies, and Consents
• IHE - Privacy and Security Profiles - Document Encryption

IHE Security and Privacy in an HIE/RHIO

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

In the 30 minutes I had I covered

• Overall Security and Privacy controls
• Audit Trails and Node Authentication (ATNA)
• Cross-Enterprise User Assertion (XUA)
• Basic Patient Privacy Consents (BPPC)
• Controlling Access

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

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

• IHE efforts in RESTful security
• Identity Proofing and Authentication -- Patient vs Provider
• Level setting on Level of Assurance
• What User Authentication to use?
• Authentication and Level of Assurance

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

• Defining Privacy
• Simple and Effective HIE Consent
• IHE - Privacy and Security Profiles - Basic Patient Privacy Consents

Access Control (Consent enforcement)

• Advanced Access Controls to support sensitive health topics
• Policy Enforcing XDS Registry
• IHE - Privacy and Security Profiles - Access Control
• Data Classification - a key vector enabling rich Security and Privacy controls
• Handling the obligation to prohibit Re-disclosure
• Access Controls: Policies --> Attributes --> Implementation

Audit Control

• Simplifying Security Audit Standards
• IHE - Privacy and Security Profiles - Audit Trail and Node Authentication
• Accountability using ATNA Audit Controls
• ATNA and Accounting of Disclosures
• ATNA audit log recording of Query transactions
• ATNA + SYSLOG is good enough

Guidance on Deploying MU2 Secure Transport

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.

See also

• MU Patient Engagement - Activity History Log
• MU2 - Why must healthcare use custom software when Thunderbird and Outlook would do?
• 2014 Draft Test Methods: Wave Four Released for Public Review and Comment
• MU2 - Encryption and Hashing
• Patient Portal - view, download, TRANSMIT
• Meaningful Use Stage 2 - Transports Clarified -- 
• MU2 Wave 1 of Draft Test Procedures -- Integrity Problem
• On The Meaningful Use Stage 2 Rules
• Meaningful Use Stage 2 : Transports
• Meaningful Use Stage 2 - Audit Logging - Privacy and Security
• Minimal Metadata
• Karen's Cross or just Minimal Metadata

Privacy and Security in Designing an mHealth Application

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:

• SP 800-53 - Catalog of Security and Privacy controls - technical, operational, physical, and management
• SP 800-30 - Security Risk Assessment
• SP 800-144 - Guidelines on Security and Privacy in Public Cloud Computing
• IR-7497 - Security Architecture Design Process for Health Information Exchanges (HIEs)
• The rest of the NIST 800 Special Publications

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.

See Also: Security/Privacy Risk Assessment/Management

• IEC 80001 - Risk Assessment to be used when putting a Medical Device onto a Network
• More Webinars on Basics of IEC 80001
• IEC 80001 - Security Technical Report presentation
• How to Write Secure Interoperability Standards 
• How to apply Risk Assessment to get your Security and Privacy and Security requirements

FW: HHS is expanding its health information privacy enforcement team

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.