Healthcare Security/Privacy

HIE using IHE

2012-01-27T14:00:00.000-06:00

An Introduction to building a Health Information Exchange using various IHE Profiles. I was one of the contributors to this white paper, so I like it. I wanted to add more and more detail, but we wanted to keep it short. At 35 pages it is as small as we could get it. The things one needs to think about when building an HIE is quite large. We did not re-write the good work found in the IHE Affinity Domain planning kit. This is still a fantastic resource for building your governance, code-sets, and policies; like seen from Connecticut.

The paper includes discussion of the principles that IHE has considered in their Profile development. Including Governance, Document characteristics, Longitudinal issues, Metadata, Document Relationships, Document Life-cycle, Patient Identity, Discovery, Security, and Privacy. IHE Supports Health Information Exchanges that use Push, Publish and Discovery, and Federated Discovery. Each of these architectures have their own section describing the profile use. Each profile leverages the same document life-cycle, packaging, and metadata model.

Extended discussion is included on the topics of the architectures behind the XD* profiles. For example the XDS profile that supports a centralized registry model with distributed repositories. This model is shown with a slide from an upcoming webinar on the topic.

Although XDS is the 'grand-daddy' of the XD* profiles; the other profiles are just as important given different patterns. When a Push model is desired the XDM and XDR profiles are best suited. When there is a need to federate communities is needed, XCA fills the need.

Patient Identity is one of the topics that receives extended discussion, as is Provider Directories, Privacy and Security. Patient Identity is complex in a Health Information Exchange, even in the most simple models.

The white paper covers a high level of Privacy and Security. My webinar covers more detail.

In all cases, the details are not included in the white paper. There is heavy use of the IHE webinars for additional overview, and the profile text for the details.

Update: For those wondering if or where these IHE profiles are used to build HIEs, see http://tinyurl.com/wwxds

As a White Paper, it is expected to be updated based on feedback. So if you have a question that is not answered, please log it as a comment (see below).

------------------------------------------------------------------------------------------------------------

IHE IT Infrastructure White Paper Published

The IHE IT Infrastructure Technical Committee published the following white paper on January 24, 2012:

· Health Information Exchange: Enabling Document Sharing Using IHE Profiles

The document is available for download at http://www.ihe.net/Technical_Framework/index.cfm. Comments can be submitted at http://www.ihe.net/iti/iticomments.cfm.

Distributed Active Backup of Health Record

2012-01-27T07:52:00.000-06:00

Lesson learned from large scale natural disasters in the USA from Hurricane Katrina, and in Japan by 2011 Tōhoku earthquake and tsunami; is that a system backup is not sufficient in healthcare. A system backup is one where the data and/or system is backed up to something like backup-tape. It hopefully is stored off-site, specifically in a different region to keep it far enough away from any large scale disaster such as Katrina and Tōhoku. It might be that the backup is done directly into the cloud, that is that rather than using physical tape the backup is streamed to cloud based storage (I do this at home with Carbonite).

But this is not good enough in Healthcare. In healthcare the people directly affected by the large scale natural disaster will need healthcare urgently and long term. The disaster, especially in these large scale cases, destroyed the local healthcare infrastructure (clinics, hospitals, etc). Thus these operational environments are not available to 'restore the backup'. It is possible to provision totally new, yet identical systems elsewhere; then restore the backup onto those systems. But this takes time; and is logistically very difficult to do.

The problem is that the directly affected community needs healthcare right away, and in a way that is sustaining. This is not to focus on the emergency need, as emergency treatment works well in the absence of historical information (although would be enhanced if it was there). But rather to recognize that urgent care, emergent care, and sustaining care are still necessary. Some examples that are not obvious to many people are the need to put treatment plans in place that will need to be continued for months or years; picking up on past long-term treatment plans; re-issuing prescriptions that were in place (urgent to replace dispensed drugs that were destroyed). The threat (Risk assessment) to these healthcare workflows must be considered.

The Patient Centric Health Record needs to be available regardless of this large scale natural disaster. One possibility is to distribute the active health information across regions far enough away from any large scale disaster. Others might use A Health Information Exchange; or whole datacenter replicated on a truck. It is possible that a PHR might also be a solution, but only works if the patient takes the initiative; so it can't really be an organizations or communities solution. So risk assessment is clearly the right approach to produce the best solution for your environment and the likelihood and impact of disasters in your area.

In Japan, they filled the short term need with their distributed prescription system. Fortunately for them they did have all the prescriptions available through this. This clearly allows for re-dispensing, and new prescriptions. What is truly creative is that Japan used this system to re-create the patients likely problems. I find this wonderfully creative; yet tragic that this had to be done. Japan now has rules that require that all patient records must be duplicated at more than one facility. This is done through message routing in real-time.

Healthcare is about providing Care to the Health of the Patient. This is not a local-business problem, but much wider. The community needs are important. Please consider these risks, made so clear by these large scale natural disasters.

FW: Privacy and Security Mobile Device Good Practices Project Launched

2012-01-25T13:50:00.002-06:00

This just crossed my desk. I think that Mobile Devices do present a Risk that is higher than most people think about. But I don't think that Mobile Devices are special. Risk based approaches are the right answer.

--------------------------------------------------------------------------------------------

From: ONC Health IT [mailto:onchealthit.@service.govdelivery.com]
Sent: Wednesday, January 25, 2012 12:46 PM
To: Moehrke, John (GE Healthcare)
Subject: Privacy and Security Mobile Device Good Practices Project Launched

Privacy and Security Mobile Device Good Practices Project Launched

ONC's Office of the Chief Privacy Officer (OCPO), in working with the HHS Office for Civil Rights (OCR), recently launched a Privacy & Security Mobile Device project.

The project goal is to develop an effective and practical way to bring awareness and understanding to those in the clinical sector to help them better secure and protect health information while using mobile devices (e.g., laptops, tablets, and smartphones). Building on the existing HHS HIPAA Security Rule - Remote Use Guidance, the project is designed to identify privacy and security good practices for mobile devices. Identified good practices and use cases will be communicated in plain, practical, and easy to understand language for health care providers, professionals, and other entities.

HHS will be looking for your input. Stay tuned for a public roundtable this Spring.

For information about other HHS mHealth activities, please visit the mHealth Initiative website: http://www.hhs.gov/open/initiatives/mhealth/index.html.

Data Segmentation Use Case Ready for Review

2012-01-21T09:53:00.001-06:00

This just crossed my desk. Please help review these use-cases. I think we need to constrain the scope, not because the scope isn't appropriate, but rather because it is only with a constrained scope that we will make the next step in progress. This is a multi-step journey, taking too big of a step will result in failure.

A little background, this is a USA effort driven by the government body HHS/ONC and others. The focus is to determine for these use-cases what is necessary and/or how to support. The use-cases are focused on the highly sensitive medical topics like HIV, Drug-Abuse, etc. Keeping them sequestered (segmented) when there is not authorization yet available when they are authorized is the scope. I have written about this more when the project was kicked off.

From: S&I Framework Admin [mailto:admin@siframework.org]
Subject: Data Segmentation Use Case Ready for Review
Sent: Friday, January 20, 2012 8:51 AM

Hi Work Group Members,
As a reminder the Data Segmentation Use Case document is posted and ready for review. You can find the Data Segmentation Use case attached to the Comment Form page: http://wiki.siframework.org/Data+Segmentation+Use+Case+Comment+Form. Please take a moment to review the document and to provide detailed, actionable comments where applicable. If you prefer to email your comments you can send them to Jamie.Parker@esacinc.com. The consensus process schedule is as follows:
1/23 - Comment Process Closes - (all Comments on the Data Segmentation Use Case document must be submitted by COB 1/23)
1/25 - Final Review of Consensus Comments and Approval of the Use Case for Consensus Voting
1/26 - Consensus Voting Begins
1/30 - Consensus Voting Closes (all consensus votes must be received by COB 1/30)
2/1 - Review of the Consensus Vote

We look forward to your comments as we reach one of the Data Segmentation For Privacy Initiative milestones.
Thank you
Jamie on behalf of the Data Segmentation Support Team

HIE/HIO Governance, Policies, and Consents

2012-01-19T08:27:00.001-06:00

I wrote about Connecticut HIE Policies that were out for public comment. Connecticut is now moving forward to moving real patient data for real patient treatments. This is fantastic, but what is really wonderful for the rest of us is that Connecticut is being very open and transparent. They have published their whole stack of governance, policies, and consents.

This is a really great example of the administrative work that must be done before one can really be evaluating the security and privacy needs of an HIE. These policies were written using many ISO standards and the IHE Affinity Domain planning kit. Please go to the site as they have a beautiful breakdown of the various many policies that are needed. Many people don't believe me when I say that there are many layers of policy.

These are a really good example of how an HIO can take a look at what is out there and pull what they understand while doing what is necessary to get what they need done. For example on ConfidentialityCode, Connecticut was confused by the vocabulary offered by HL7, and thus wrote their own vocabulary. They actually pulled more from ISO 13606, but didn't use that vocabulary either. We were lucky enough to be able to discuss this in detail this summer. HL7 has revised their documentation and vocabulary so that we can have a vocabulary that could be understood beyond one HIE.

The establishment of policies and procedures are a key component for an effective HIE and sets the boundaries for data sharing between the health information exchange and its participating partners.

These policies are now posted on the HITE-CT website and are available for public comment. The direct link to the Policies and Procedures page is http://1.usa.gov/hitectpolicies. The policies may also be accessed by going to the DPH website at www.ct.gov/dph under featured links: Health Information Technology Exchange of Connecticut”, then click on “Policies and Procedures” located on the left hand bar menu.

I would love to see more of this. It is always very important to see how a standard is understood or misunderstood so that we can make it better. I have pointed many people toward this site, and everyone has come back to me the next day and thanked me and asked for an introduction to the brains of this. I know her well, so ask and I will gladly introduce you too.

For a Webinar on this

Workflow Automation Among Multiple Care-Providing Institutions

2012-01-16T22:36:00.001-06:00

IHE IT Technical committee has released the Cross-Enterprise Document Workflow (XDW) profile. This is a key foundational profile that will enable use-case specific workflows to be managed across organizational boundaries. It sets forward a basic workflow 'token' by defining a workflow document which is profiled by combining OASIS WS-HumanTask, and HL7 CDA. The XDW profile does not define any workflows, but rather sets a framework that others will use to support Health Information Exchange (HIE) based workflows like Patient Transfer, Remote Imaging Diagnosis Referral, Prescription workflows, and many Home Care plans. By re-using the XDS infrastructure, XDW leverages the clinical documentation also managed there. XDW provides context and focus to the documentation.

XDW is targeted to facilitate the development of interoperable workflow management applications where workflow-specific customization is minimized. XDW does NOT replace departmental workflows, although it might leverage a departmental workflow as one of the larger steps that are managed by XDW. XDW does NOT replace centrally managed workflows such as those controlled by BPEL, but might leverage a BPEL controlled workflow as one of the larger steps that are managed by XDW. The XDW workflow may refer to an externally defined and possibly not computable workflow definition, but is designed to support evolution to completely enclosed and/or computable workflows.

In the development of the XDW Profile, much attention has been applied to making XDW deployment easy, without the need for dedicated centralized workflow infrastructure. The profile recognizes that the patient is centric to their healthcare workflow, and thus uses the patient centric Health Information Exchange provided by XDS. XDW is foundational both to support care-setting specific workflows, but also to expand with future evolution.

Health Systems in developed countries are receiving much attention, it is now well accepted that interoperable IT systems and EHRs are a critical technology. Much progress has been made in standards-based interoperability in health information exchange (HIE) and early deployments are encouraging. Integrating the Health Enterprise (IHE) profiles such as Cross-Enterprise Document Sharing (XDS) and Cross-Community Access (XCA) are playing a key role in large scale projects such as the European cross-border epSOS and the US NwHIN-Exchange. Many are satisfied that they can now share Clinical Documents (CCD/CDA), Diagnostic Imaging (DICOM) or even unstructured (PDF) content is accepted as foundational.

We now look to manage workflow among the various institutions that are coordinating a patient’s care delivery. These workflows are community wide and involve different tasks at different specialty facilities that are not part of the same organization, to leverage the HIE infrastructure that has been proven as a good longitudinal document exchange. This is the problem that is addressed by the Cross-Enterprise Document Workflow (XDW) profile.

A novel approach to multi-organization workflow management
The Cross-Enterprise Document Workflow (XDW) profile was released by IHE in October 2011 for trial implementation. XDW enables participants in a multi-organizational environment to manage and track the tasks related to patient-centric workflows as they coordinate their activities:

It does not rely on a central controller, or a central scheduler, thus it may scale from exchanges, to communities to nations.
Decisions are made by the “edge” IT systems supporting the providers, doctors, nurses, etc. Note an edge system can be a departmental workflow automation system.
It is flexible to support a wide range of workflow, from the simplest e-Referral, to dynamic and adjustable workflows.
It minimizes implementation impact on IT systems that manage workflows within each organization
Basic framework today that can be enhanced by specific workflows and advanced as multi-organizational workflow standards emerge and mature

XDW a Framework for multi-organizational workflows
XDW is an interoperability framework operating in a document sharing context (e.g. based on the XDS profile) which supports the management of clinical process. Its a workflow-generic profile which needs to be specialized through specific Workflow Definitions (IHE specified Profiles or project specific) to address specific clinical processes. As a framework, it Increases the consistency across workflows, and enables the easy deployment of interoperable workflow management applications where workflow-specific customization is minimized. As a result, XDW facilitates the integration of multi-organizational workflows with the variety of existing workflow management systems used within the participating organizations.

It federates the workflows managed by each institution in a peer-to-peer approach. This is quite different from the classical intra-hospital approach to support a workflow by exchanging messages (orders, acknowledgments, results, notifications, etc.) between predefined IT systems.

How does XDW Work?
XDW operates around the sharing of a Workflow document for each workflow instance associated with a patient. A workflow document:

Tracks the current/past tasks of the workflow and engaged health care entities
Tracks the workflow specific tasks status with relationship and references to input/output documents

The execution of each instance of a workflow is driven/enforced by the participating IT systems (XDW actors), while the document sharing infrastructure provides transparent access to any authorized participating system.

The Workflow Document format and structure is specified by XDW and is generic across any specific workflow definition.

What are the workflows supported by XDW ?

The XDW profile is designed to be used in conjunction with any Workflow Definition. It makes the task of defining such workflows quite easy, as it provides a clear and user friendly framework to develop such definitions. They include:

· A human readable definition of a specific healthcare process

· A set of rules and task definition which characterize the process

· The definition of the participants involved in the workflow and their roles

The XDW profile contains an annex that includes the informal definition of a simple e-Referral workflow, sufficient to implement and use XDW. IHE expects that clinical IHE domains will develop reusable Workflow Definitions as IHE Profiles for the most common workflows, but that more specific workflows may be also defined by e-Health projects around the world. IHE anticipates provider organizations and national bodies (HHS/ONC) to define workflows that can be directly automated using XDW.

IHE Patient Care Coordination (PCC), IHE Radiology and IHE Pharmacy have already started to build upon XDW with profiles due by the summer of 2012 such as:

XBeR-WD Cross Enterprise Basic e-Referral Workflow Definition Profile
XSM Cross Enterprise Screening Mammography Workflow Definition Profile (White Paper)
XTHM-WD Cross Enterprise Tele Home Monitoring Workflow Definition Profile
XTB-WD Cross Enterprise Tumor Board Workflow Definition Profile
CMPD Community Medication Prescription and Dispense

Selected Standards
XDW Supplement introduces a new content profile type - for a workflow management document - based on the following standards:

OASIS Human Task for task structure and encoding (part of the BPEL suite of standards)
HL7 CDA for provider description
HL7 R-MIM for patient and author description

In XDW, no new transactions are introduced. WDW leverages existing ITI IHE Profiles:

XDS, PIX, PDQ, DSUB, BPPC, ATNA, XUA, CT
No XDS Metadata extension, but specific rules about XDS Metadata content for the registry entry associated to the XDW Workflow Document

Is XDW ready for prime time?

With the trial implementation profile specification available, the first IHE Connectathon testing is scheduled for Bern (Switzerland) in May 2012 with at least an e-Referral workflow. The profile is ready for implementation in products towards the end of 2012, early 2013.

Conclusion
The integration of multi-organizational workflows with the variety of existing workflow management systems used within the participating organizations has been waiting for such a common, workflow-independent approach to interoperability.

XDW provides a platform upon which a wide range of specific workflows can be defined with minimal specification and implementation efforts (e.g., Medical Referrals Workflow, Remote Imaging Diagnosis, Prescriptions Workflow, Home Care Workflow). As it increases the consistency of workflow interoperability, it is targeted to facilitate the development of interoperable workflow management applications where workflow-specific customization is minimized.

Much attention has been applied to making its deployment easy, without the needs dedicated centralized infrastructure beyond a secured sharing of health documents infrastructure provided by an XDS Registry/repository.

ATNA + SYSLOG is good enough

2012-01-02T20:48:00.001-06:00

There has been a renewed discussion on the IHE ITI Technical around the topic of syslog and application level acknowledgement. There are calls for Healthcare to go away from SYSLOG and invent their own protocol with an application level acknowledgement. Rob has provided his analysis and proposed one solution, then followed it with more analysis. I simply don't think that the problem is worth fixing: there is a very small likelihood of it happening, and it is detectable. With good design, once the failure has been detected it can be completely recovered from. This being the months leading up to Connectathon, the topic of design vs interoperability specification comes up quite often. For example the ATNA audit log recording of Query transactions

The concern is that there are cases where one can cause audit events to be lost by killing the network inbetween the audit sender and the Audit Record Repository. If you do this as a link in the middle, then neither side notices until re-transmission timeouts. In this time the sending side may nolonger have the messages to retransmit at the application level. The core concern is for integrity of Patient Privacy reports such as the Accounting of Disclosures.

Analysis
This is the reason why ATNA has all systems involved, recording auditable events. Although one system might have lost an audit event, the other party involved in a transaction will likely have succeeded in recording the event. That is the client of a transaction (e.g., XDS Document Consumer) fails to get their auditable event recorded, but the server of that transaction (e.g., XDS Registry) does get their auditable event recorded. Further, each access to the data once it is inside the receiving system (e.g., XDS Document Consumer) must also be recorded. Among all of these audit records will be sufficient information, even if a few events are lost. This protocol was designed back when SYSLOG was completely UDP based, favoring the model of no-delay, possibly out of order, and no-queues to reliable transport (TCP) now with security (TLS).

The security officer can see that there is a missing audit event, as all transactional events should be double, and can investigate the failure that caused the event. If the failure continues to happen, then they have knowledge to make the system that failed more robust. Like possibly putting an ARR closer to that system (such as the Distributed Accountability diagrammed), possibly inside on loopback with a filter auto-forwarding robustly. Using a standard like SYSLOG allows for using off-the-shelf building blocks.

I will point out that TCP protocol is a reliable transport (I wrote a complete commercial stack back in the 80s for Frontier Technologies Corp - throw stones if you wish). The TCP problem that people are pointing at is totally detectable, but requires that the application wait for the confirmation that the connection was closed gracefully (SO_LINGER, or shutdown). I am assuming that the observed problems of lost audit events are due to some implementations that are not doing graceful shutdown of the socket, so they can't notice if the connection closed abnormally. Applications have responsibility too. It is very true if you don't wait for a graceful shutdown to complete normally then you can't know if all the data you have sent has been received, or if you have received all the data the other side sent.

Going deeper
There is one case where the 'wait' can be very long and leave things indeterminate. The case is well documented by one of the leading thought leaders inside the SYSLOG community Rainer Gerhards

The case is where a network failure happens during communications. Normally the Audit Record Repository is only receiving, and thus there is no outbound TCP traffic from the Audit Record Repository to trigger a failure event. To protect these cases, the TCP protocol implementations have added a SO_KEEPALIVE, that would have the TCP on the ARR side sending negative traffic just to get a positive TCP-ACK or reset. So, I would suggest that ARRs should be using SO_KEEPALIVE. The ARR would know all the data that was received and that the connection terminated non-gracefully. So the ARR side is detectable and deterministic.

The sending side would have data in the outbound queue (at least in the documented case), so this data in the outbound queue will be retransmitted until the TCP on the sending side gives up (yes, lots of retransmits later, with dynamic backoff). The sending side can also notice that it's outbound wants to block, and based on application logic (queue+time configurations) presume failure. So, the sending side will know that failure has happened, just not 'when in the data stream'. Yes the sending side is very blind to the TCP outbound queue inside the stack. Thus for full record (which I argue above is not critical) the sending side would need to re-send all un-recorded audit events, which it doesn't know how far back to go. The sending side could also use SO_KEEPALIVE, it would help to detect failure when it happens, which might be while the outbound queue is empty.

Note that both the sending and ARR should really be recording this connection anomaly as an auditable event, thus flagging it for inspection by the security officer.

Detect and Mitigate
If you want to make sure you have all your audit events recorded, you could always gracefully close the SYSLOG connection (ShutdownOutput, SO_LINGER). Open up a new one for new events, while awaiting the graceful close notification on the old connection. This will have additional overhead, and no idea how well Audit Record Repositories would like this. Note more auditable events might be recorded on open and close of the SYSLOG socket.

I could imagine a robust design that has some outbound queue size or inactivity timeout that might be used to cause this confirmation flush shutdown. In this case, the sending side can know exactly all that should be re-sent if a network failure happens, possibly delivering duplicates to the ARR (an easy thing to detect at the ARR). This seems like a high level of logic to handle an event that doesn't happen often, is detectable, and duplicate events protects against. As Rob points out, retransmitting an ATNA audit event will mostly be detected at the Audit Record Repository although Rob suggests we could make the protocol more robust.

Note that we did originally specify the "Reliable SYSLOG" protocol, which does include these application level controls. This protocol was rejected by the IHE developers, and also by the general SYSLOG community. It was considered too complex, and too hard to implement. The SYSLOG community may continue to mature and head back to this more robust approach, but I don't see that happening very fast. The reality is that the problem does exist, but there are other ways to solve the problem without changing the protocol completely.

Updated: Rob has posted an article on their experience with network failures. This is more proof that one needs good design, design that has considered risks (including security risks).

ATNA audit log recording of Query transactions

2012-01-02T20:48:00.000-06:00

A common question that comes up when people are implementing ATNA audit logging is what to do when they are recording that a "Query" has happened. This might be the Queries that IHE defines in Profiles like PIX, PDQ, XDS; or it might be a database query of some kind. This topic is not fully covered in the IHE Technical Framework, but is covered better than people recognize.

According to the IHE ITI Technical Framework, Volume 2a, section 3.20 (Record Audit Event), table 3.20.6-1, the "Query Information" event note says

Notes: The general guidance is to log the query event with
the query parameters and not the result of the query. The
result of a query may be very large and is likely to be of
limited value vs. the overhead. The query parameters can be
used effectively to detect bad behavior and the expectation is
that given the query parameters the result could be
regenerated if necessary.

This philosophy is why the PIX, PDQ, and XDS 'query' transactions, such as XDS "Registry Stored Query", security considerations only shows the query (parameters, and outcome indicator) being captured and not the query results. IHE did not duplicate this note in all the places where it shows query like transactions being profiled. A familiarization with section 3.20 is essential, and table 3.20.6-1 is critical as it contains a listing of the other security relevant events that are expected to capture if your "Secure".. "node/application" controls them.

It is important to note that the "Query Information" audit event does include the "EventOutcomeIndicator", which will show that the query succeeded or failed. It is not an indicator of how many results were returned, so a successful query that returned zero results looks just like a successful query that returned 1 billion results. This means that the ATNA audit event can't be recorded until the results are known, or at least if the query is going to be successful or failure. Note that it is expected that an Access Control decision to deny a Query (resulting in zero results returned) would also be an auditable event, and thus an Access Control denied event would be recorded that would explain why.

The second sentence in the note is the 'reason' why we want only the Query to be recorded and not the results. The results would seem to be very useful, especially to a Privacy officer. But the results would likely be high-quality PHI; and we want to keep as much PHI out of the ATNA audit log as possible. This is why ATNA asks for identifiers and discourages descriptions. This is simply good design, to limit unnecessary risk. This greater phlosophy

The information that is not recorded can be discovered through other means. The ATNA Audit Record Repository is an abstract actor, it is fully expected that a valuable system/product would take many actors and functionality together. That is a good Audit Service would include an ATNA Audit Record Repository, but would also include a PIX Consumer, PDQ Consumer, PWP Consumer, XDS Consumer, and any other actors/functionality necessary to de-reference identifiers. This act of de-referencing the identifiers would be, Security Relevant and thus auditable. In this way there is built-in watching of the watchers.

Specifically in the case of XDS queries, that the Audit Service can tell simply by the Query parameters that are encoded into the ATNA Audit Message record of the XDS Query; which queries were against a specific patient. This is because all XDS queries are patient specific, and include the patient ID in the query parameters. Yes there are a few exceptions that are recognizable and handled independently.

If the security office or privacy office wants to know what the results of the query were, they can re-execute the query. With specialized (not IHE profiled) tools the query can even be with the same security context. Simplistically one would say that the state of the database has changed since the original query, this might be true; but good database design would also have a change-tracking-log that would tell you what has changed since the date/time stamp of the original query.

Note that this philosophy is consistent with the other transactions, it just needs to be spelled out somewhere for Queries. For example, on XDS Retrieve Document Set transaction, we don't tell you not to duplicate the bytes of the document retrieved into the ATNA audit message. This seems logical that one doesn't copy the retrieved document into the audit log. It just doesn't feel as logical when the transaction is a query.

All of this is 'systems design', and not necessary to include in the 'Interoperability Profiles'. This is because this systems design knowledge doesn't change the interoperability characteristics. IHE also doesn't include this systems design knowledge because there are likely many ways to design a system. IHE technical committees do consider systems design during profile writing, specifically we make sure that there is at least one way to design a system.

See:

Introduction to IHE profiles

2011-12-30T11:58:00.000-06:00

I got my first real "Ask me a Question":

"Do you know of any good introductory training resources for HealthCare IT workers to better understand IHE profiles/transactions in general? Beyond the documentation on IHE.net. "

The formal specifications are all on the IHE web site known as the "Technical Frameworks", "Supplements", and "White Papers". This site is not very helpful, it is simply a list of the documents that could be downloaded. These are the formal specifications, so ultimately you must understand them.

There is a more helpful listing by profile available on the IHE Wiki. Each of these are linked to a short description of the profile which includes specific pointers into the formal specification. I tend to point at these more often than the formal specifications simply as one can point at a profile, rather than a volume fragment of a profile in a library (aka Technical Framework).

The most useful 'training' is the many overview webinars of the profiles. Most of these webinars were recorded and the recording is available. All of them have the PDF version of the slides listed. Unfortunately they are listed by the date that the webinar was given.

For the ITI committee, which I am a member, they have these webinars further documented on the wiki. On this site is the Powerpoint version of the slides.

For the Privacy and Security webinar, I have further expanded this on my blog as a bloginar.

All of these are available from IHE. I must say that I am not aware of training beyond this. I would guess that there is some out there. I just simply have pushed all my efforts to create training into IHE for global and free publication.

Predicting Meaningful Use Stage 2 Security

2011-12-21T14:06:00.000-06:00

As a member of the HIT Standards ‘Privacy & Security' workgroup I do have first-hand experience with the discussions and potential. The workgroup met earlier this year to discuss the proposed Meaningful Use stage 2 security and privacy criteria. The workgroup was given a set of criteria to comment on, so was not given a clean slate to add criteria of its own. Generally the workgroup softened yet focused the criteria (See detailed table output). There was clear recognition that Meaningful Use stage 1 criteria were not well understood. Here is a list of some of my articles, which are still in the top 10 popular articles:

The HIT Standards 'Privacy & Security' workgroup added to the criteria pointers to existing standards that explains the criteria in general IT language. Most of the time it pointed at NIST 800-53. The recommendations were presented to the full HIT Standards committee in October.

Six adjustments:
The first criteria is for secure messaging with patients. Specific to the security functionality: the message must be encrypted, authenticable, and audited. The Privacy & Security workgroup tried really hard to stick purely to the security functions without getting tied into implementation specifications. It indicated that both NwHIN-Exchange and Direct were acceptable (Regulatory coexistence of Direct and Exchange). It is not known if HHS/ONC will keep this criteria general, or get more specific. Something that came up later in side conversations was to address how an EHR could be so sure that an endpoint it was communicating with was a specific Patient. Thus the need for further analysis on authenticating patient identities outside of direct treatment scenarios (Patient Identity Matching).

The second criteria is to assure that documents that are created include data-provenance information. This is a direct response to concerns that when importing documents, that the patient provides, that there is a need to identify the original author. Unfortunately the security criteria is not a strong non-repudiation (IHE - Privacy and Security Profiles - Document Digital Signature, Signing CDA Documents), but rather simple functional criteria that typical clinical documents (CDA, CCD, Blue-Button) already support. This criteria is linked to re-enforcement of the need for patients to be ‘able' to download a copy of their health information. The Privacy and Security committee didn't try to define the content, but rather simply the functionality of being capable of downloading their health information. In the short term simple data-provenance might be good, but eventually we need strong non-repudiation.

The third criteria is a rather small one that surely everyone already supports. This criteria is commonly known as ‘inactivity timeout' or ‘auto logoff'. The idea that the system will detect an idle system and somehow prevent the system from further displaying or allowing access to PHI. This is a typical functionality, but is a difficult thing to describe in words in such a way that doesn't specify a specific method.

The fourth criteria is to more fully define security audit logging. This one mostly resurrected the wording that I created as a co-chair in CCHIT back in 2005. That is to define a set of auditable events (right from ATNA), a set of audit attributes (right from ATNA), and a set of audit log management functionality (also right from ATNA and other sources). Thus the criteria should end up looking very much like what CCHIT was testing before. I tried to get IHE ATNA listed as ‘super-compliant', but this was removed by the larger committee. I am confident that IHE ATNA is viewed as compliant, but I don't think that the stage 2 criteria will say this. (How granular does an EHR Security Audit Log need to be?, IHE - Privacy and Security Profiles - Audit Trail and Node Authentication, Accountability using ATNA Audit Controls, and ATNA and Accounting of Disclosures)

The fifth criteria is that systems need to authenticate themselves to other systems on the network. This is the typical system-to-system authentication found in IHE ATNA (e.g. Mutually-Authenticated-TLS). The workgroup tried to focus this criteria to only communications that go across organizational boundaries, so that it would not be applied to internal communications. I am not sure which way HHS/ONC will go on this. (IHE - Privacy and Security Profiles - Audit Trail and Node Authentication, S/MIME vs TLS -- Two great solutions for different architectures)

The last criteria is to clear up the most confused security criteria from Stage 1. That is to define exactly what is required of encryption of data-at-rest. Many members on the Privacy and Security workgroup expressed that the Stage 1 criteria was hard to understand (Meaningful Use Encryption - passing the tests), and we all expressed that the criteria needs to be very specific about the risk that it is trying to solve. Specifically the EHR vendors on the call were strongly advocating for wording that would encourage software good design. Specifically an EHR design where the end-user system doesn't save PHI onto the hard-drive, whether this is a desktop, laptop, tablet, or other mobile device. We were very unified that this is a good system design that doesn't put PHI at risk of exposure if the system is lost or stolen. Yet if the EHR system does utilize the hard-drive on the end-user system then the EHR system must support encryption of that PHI. Clearly HHS/ONC is very worried about perceptions of the HHS Breach Notification ‘wall of shame', and thus want to provide politically-correct message that tells the general public that they are addressing these breaches. I thus would recommend both: make sure system design avoids risks of exposure, and allows workstations to use transparent hard-drive encryption.

The workgroup did recognize that the functionality of an EHR to export documents (e.g. to give a copy of health information to the patient), is excepted from the workstation encryption criteria; while also recognizing that there is a need for encryption of this exported information. We recognized that IHE has just released the Document Encryption profile which would be a future possibility, likely for Stage 3. Prior to that approach, the Provider Organization is expected to protect this exported PHI through other means, such as transparent encrypting USB memory devices and transparent hard-drive encryption.

Conclusion
There really is not much new this year, mostly providing clarity to previously known security functionality. I see more interest in leveraging existing general purpose IT security functionality standards, such as NIST 800-53. There is also a recognition that the IHE profiles are a proper solution for interoperability (they don't cover functional or operational security), but there is HHS/ONC hesitancy to specify them out of fear that they drive a specific architecture or specific organizational infrastructure. The workgroup and my interactions with HHS/ONC show that there is a reasonable approach to security functionality as foundational to a high quality EHR.

Direct: Security risk of PHISHING and SPAM

2011-12-21T11:45:00.001-06:00

I am trying to find people who have experience with encrypted e-mail and using Directories to publish certificates. Standards are wonderful, but experience is equally important. While talking to people about their experience with publishing digital certificates in LDAP directories, I have to explain the Direct project use. I am explaining this to IT people who run directories or run mail servers. It goes a little like this:

My use-case is for encrypted e-mail. More specifically it is for using encrypted e-mail between hospitals/clinics by doctors. In order to make this happen, one doctor must be able to ‘discover’ the certificate of the other doctor. So I am on a workgroup trying to define how the USA would do this. Specifically we are recommending each hospital would have a limited LDAP directory exposed for this purpose. It only need contain the email address and certificate for each individual they allow to receive encrypted e-mail.

For which my security conscious peer responds:

Nice. Publish everyone’s email address and their public cert. phishing encrypted style. Good luck detecting the phish till it’s *way* too late.

The implied message here is that if the e-mail is encrypted to a certificate owned by an end-user; then the IT at the organization can’t look at the content and reject it because they see PHISHING or SPAM patterns. This is what many mature email servers have been doing to limit the amount of SPAM or PHISHING that end-users see. I know that I receive little spam or phishing email, yet my email address is well known and published in lots of places. I compare with others, and am very happy with the IT support given to me at GE. This is impossible if the IT department can’t look at the message because it is encrypted.

Note that both the DNS-Cert and the LDAP model of publishing Certs would present this problem.

I do have a good answer:

Yup, the risk is known; and managed: The sender must sign the message too, and it must be signed with a certificate that chains to a trusted root (trust root that are managed, NOT like browsers). So, unsigned messages are discarded, or the phish-er will be highly identified by their e-mail signature

This is indeed the solution that we put into the Direct Project risk assessment. The following is from this risk item in the risk assessment as the comments:

the judgment of the receiving user can determine if the information should be trusted or not.
Many will choose to simply discard all non-secured as potentially SPAM.

I am worried that some will forget this risk, and not treat un-signed email special. If you forget this risk, and you publish your email address in a directory or in DNS; then you will be discovered and targeted by SPAM and PHISHING attacks. If your certificate is there; then the attacker can further encrypt the SPAM or PHISHING attack so that your IT department can’t protect you.

The inbound signature MUST be validated.
See:

IHE Profile grouping

2011-12-19T12:56:00.000-06:00

Should Document Content profiles mandate IHE ATNA? The short answer is "No". The long answer is a lesson in understanding IHE 'grouping'.

I am generally against mandatory grouping, they cause more unnecessary discussion than they help. IHE did mandatory grouping for XDS simply because we needed to drive security/privacy, as there would not be trust of an HIE system that is ignorant of security/privacy. In hindsight we might have done this through some other means, but we used the tools that we had at the time. Therefore all XDS actors must be grouped with ATNA secure node/application actor.

However we need to recognize when there is a need to define specific behaviors when grouping happens; regardless of if the grouping was mandated (ala XDS mandating ATNA grouping), or by system design (EHR chooses to implement both XPHR and XDS).

Document Content profiles have recognized that the likelihood of Document Content profiles to be grouped "by system design" with one of the XD* transports (XDS, XCA, XDR, XDM); and therefore the Document Content profile do define how one would derive the XDS Metadata values from the Document Content profile specification of the content. This is an example of a not-mandated grouping, but one that is fully defined.

The Document Content profiles should equally recognize that a likely systems design grouping would be with ATNA. Thus the Document Content profile should define the Security Audit Log Message derivation. This should not be duplicate of the audit log definitions in the export/import transport, but clearly the Document Content profile is being 'created' or 'consumed'; both are security relevant events. This is really not unlike what is done for XDS Metadata. If this is not defined by the Document Content profile, then the system implementer must figure it out themselves (which I would argue they should be able to do).

Some other examples I can think of for Document Content profile likely grouping with SVS, PWP, PIX, PDQ, etc… I am not saying these must be documented, but surely if PCC felt that the grouping was likely (or to be encouraged) that behaviors would be defined as ‘grouping behaviors’. For example specific use of SVS to retrieve a value-set that is used a defined way.

In this way, if someone chooses to make an application that does nothing but create the Document Content as specified, but doesn't choose to design with any IHE defined transport or IHE ATNA; then there is no XDS metadata or ATNA message that is testable; as they are not mandated. The defined things to be tested are driven by the systems design as documented in the system “IHE Integration Statement”.

Regulatory coexistence of Direct and Exchange

2011-12-14T18:47:00.000-06:00

This would be a fantastic outcome, but making regulation is a messy process. In the blog post "Standards are not Optional" Doug Fridsma talks about "Optionality" in standards including that data standards for HIE building blocks "need to be unambiguous and have very limited (or no) optionality." This seems to tip the hat toward continued mandate for Direct and no recognition for Exchange.

In Fridsma's blog the use of "no optionality" is being applied in a very specific way. John Halamka likes to point out that when alternatives are part of a regulation, the result is that the vendor community must support all alternatives. Thus a this-or-that is actually a this-and-that. Thus an "or" is actually an "and". This is a good lesson to learn, as it really should get policy makers to think about what they are asking for. If they include optionality in regulation, they are actually mandating both. Meaning they are really not providing optional paths.

However optionality is a word that can be used in a different way, that should not be seen as a negative. Such as the "Consolidated CDA" is the basics of a document that must be fully specified a specific way without question; but if (optionality) you have Y or Z information you may (more optionality words) put them in the same document in this specific (not optional encoding) way. This extra information (Y or Z) is optional, but it isn't optional in the same way as is being reference with the OR-means-AND phrase. This extra information (Y or Z) is optional because it may or may-not have been captured or be relevant to the current context. It is optional because it is not minimally necessary for the broad use of the document; but if you have it then it is not optional on how to encode it. This is understood by most who are involved with standards daily, but confusing to those that look at it only once a month.

Note there is this kind of optionality built into the Direct specification. Inside the Direct specification (see 2.1 Health Content Containers) it indicates that if you can send the Document content inside an XDM zipped formatted package, then you SHALL. Meaning that sending the document without the XDM zipped package is minimally required, but if you can send it with the packaging and metadata defined by IHE XDM then you must do it that way.

I believe that ONC is struggling with how to handle Direct vs Exchange. They had the big struggle between the Powerteam and the community pushback. They really want to push 'either', but know that the OR-means-AND rule; forces even the littlest vendor or organization to implement both. They are not worried about the big guys (big vendors or big organizations). The big guys have money, resources, and IT knowhow. So they struggle with how to mandate ONE, while making sure that the other is operationally acceptable. Given their focus on helping the little guy vs not caring about the big guy; they are more likely to continue to only mandate Direct. There is little question that for the little guy that Direct is the best stepping stone. But as Doug Fridsma points out in his blog:

The Modular Specifications project has identified two ways to transport information and has created more modular, substitutable specifications. Utilizing Direct specifications as the foundation, the project has created a Secure Transport specification based on SMTP and S/MIME and XDR and XDM Conversions. A second approach leverages Exchange specifications as a basis, and a Web services approach has been specified as SOAP over HTTP. From the multiple transport standards, two building blocks are now part of our standards portfolio.

I might point out that they have more in-common that not One Metadata Model - Many Deployment Architectures

I think a reasonable outcome of Stage 2 Meaningful Use is that Exchange be considered as an acceptable standard to receive endorsement and funding. I don't think Exchange will receive anything more than that. ONC does understand that regional health information exchanges did miss-understand their old directive to use "Direct" means "Not Exchange". So to get this message converted to "Direct is minimal, Exchange is acceptable" would be a good outcome. To get Exchange listed as 'preferable' would be extraordinary.

In the mean time, there are plenty of regional Health Information Exchanges, and consortium of very large organizations, going forward with the Exchange specifications. They are doing this because it is the right thing for them to do, and being one of the 'big guys' just proving that they don't need father ONC to tell them what to do. In doing this they are proving the technology, and developing the policies.

Patient Identity Matching

2011-12-07T08:02:00.000-06:00

IHE has Patient Identity Matching profiles like PIX for inside and across a health information exchange (HIE), and XCPD for across communities (e.g. NwHIN-Exchange). Patient Matching is also known as Multi-Patient-ID (eMPI), which is a system that matches many different patient identities (PID) in a cross-reference. This is where the name comes for the IHE Profile: “Patient Identity cross-reference” (PIX). This is not to be confused with a Master-Patient-Identify, which is a concept where there is a master patient ID that everyone uses. The Cross-Community Patient Demographics (XCPD) Profile is more suited to support of multi-community duty.

The slide at the right is from an upcoming IHE educational webinar on Patient Identity. It shows ALL of the IHE profiles that are relevant as combined into a 'system'. This system happens to combine all the Actors simply for educational purposes, but very reasonable products could do sub-selections of this for specific purposes.

IHE does not define the internal workings of the eMPI system which might implement the IHE PIX manager and/or XCPD responder actors. There is much left not specifically defined by the PIX or XCPD profile. There are several items of interest in the requirements of a PIX manager, specifically demographic matching and the value of globally unique identifiers.

These concepts are often used in combination, such as the XDS concept of an Affinity Domain, which requires a Master Patient identity that is used in XDS as the patient ID. When other entities using a local patient identifier wish to communicate using XDS, a Cross-Reference system is used to map to this Master Patient identity. XCPD operates in environments where no eMPI system or Master Patient Identity exists. Entities use demographic matching to correlate patients with selected partners, as necessary. No central, or authoritative eMPI system enables this process so, to keep correlations up-to-date, repeated matching requests are needed.

Demographics Matching
Usually an eMPI operating environment tries to define the minimal attributes necessary to make a fuzzy-match algorithm function good-enough. Good-enough is a subjective assessment but includes that most of the time a positive match is found, and only very few times does it produce a false match or a false non-match. This tuning of the matching algorithm is the primary function of an eMPI. The downside of using a centralized eMPI service is that it has a database of all of these demographics, and is thus a point of security/privacy threat.

The minimal attributes are often things like First-Name, Last-Name, Date-of-Birth, and Sex. These values are delivered to the Patient ID Manager in the Patient Identity Feed transaction (essentially a basic ADT message). They are then ‘normalized’ to handle things like uppercase vs lowercase; like initials; like spelling differences (e.g. Rich, Richard, Dick). These 4 attributes have been used well beyond the healthcare industry. For example they are used in the gambling world by the ‘house’ to detect repeat offenders. In-fact they use a system that doesn’t store the individuals demographics, but rather a cryptographic value, lowering the risk of disclosure if their database was exposed. This is the trick that John Halamka referred to in #8 of his post on Freeing the Data. It is also used to keep one casino’s clientele list from the other casinos, so there is a strong business requirement.

Change over Time
Recognize that these values, and other values such as their phone number or address, change overtime. This is shown by the figure at the right, which comes from The HIT Standards Summer Camp Patient Matching report in August, 2011. This change overtime can be detected, and when it is detected both the new and old are remembered as equivalence. In this way one can match data that is submitted under the old or new demographics. This does require that the eMPI hold many generations of entries. Identities and demographics changing over time do add complexity, but reality must be recognized.

Because this information changes over time we need to recognize that as well. There should also be a place where the most current set of demographics are. It might not be the 'authoritative' set, but it sure would be good to be using the First or Last name that the patient wants to be addressed by. Which brings up the topic of the longitudinal record. The HIE and Community Exchange are longitudinal, meaning they ultimately will contain many decades of records on any one patient. Throughout this longitudinal record many of the factors will change, even those that are shown above way off the chart to the lower right (meaning they are highly stable). This means that when pulling a record from an HIE of any kind, one must not necessarily expect that the demographics inside that document represent the current or even local understanding of the patients demographics. This doesn't mean the Document should not be interrogated, but when discrepancies are found they should be somewhat expected with possibly only a warning message to the user.

Additional Identifiers
There are many different types of identifiers that a patient can use to uniquely identify themselves. If these identifiers are provided as input to the eMPI they help produce a better positive match. If these identifiers are treated as opaque and fully specified identifiers they don’t require special handling. This is to say that both the identifier and the identifier of the assigning authority are submitted. With a generic system like this the solution supports endless types of identifiers.

For instance, if the patient has a SSN, one enters the SSN with an ‘assigning authority’ for the SSN admin (i.e., 2.16.840.1.113883.4.1). If the patient has their insurance card, you enter that with the insurance admin as the assigning authority. If the patient carries a patient id from another facility, you enter that. It is always a <ID value> + <assigning authority value>; this is just another patient-ID in the context of an eMPI (even when the ID isn’t healthcare specific). It is very important that everyone uses the same values for ‘assigning authority’, so one does not need a ‘value-set’. This is especially true when the assigning authority doesn’t have its own globally unique assigning authority value, or the value is hard to discover.

Universal Health ID
What would be best is if there was some form of universal health ID. This is currently used in other countries such as across Europe in the epSOS multi-country exchange. There is regulations forbidding the USA government from funding an effort to create a universal health ID. A unique approach to get around this is a neffort to create a digital identity for Medicare beneficiaries. Interesting how they get around the ‘can’t fund a universal ID’ problem by scoping it to Medicare beneficiaries.

A very visible example of a universal ID (that comes with a unique string encoding) is an e-mail address: John.Moehrke@med.ge.com. One can see how this will work with PHRs to create a globally unique patient ID, for example my HealthVault id can be viewed as John_Moehrke@direct.healthvault.com. This is entered simply as another patient-ID, and if it has ever been submitted in the past, it will be there for a positive match. E-mail addresses come with a built in globally unique assigning authority, the second part of the address (e.g. “direct.healthvault.com”). These are globally unique simply because of the internet domain name system.

Another approach to using identifiers to improve patient matching is the Voluntary Universal Healthcare Identifier (http://gpii.info/) which supports creation and management of patient identifiers that are independent of a particular healthcare provider entity so can be used to match patients in an eMPI.

Note that with any ID the biggest concern is to be sure you have an authoritative ID. We are used to looking at Drivers Licenses or Passports to get an authoritative identifier. We somehow trust that a patient can tell us their SSN (really bad practice due to the well known fraud and identity theft). When it comes to a patient presenting something like an e-mail address, there is a reasonable concern that this information is not authoritative. But clearly, it should be seen as just as authoritative as the SSN. Likely with an e-mail address we can work up mechanisms to prove they are authoritative before we use them, very much like the banking industry and e-mail distribution lists.

Security Considerations
Clearly Security is important for any system that holds sensitive information. The eMPI is a form of a directory, a specific form. When queried using PDQ it looks more like a directory. One must recognize that the patient demographics and identifiers are sensitive (valuable). So the eMPI system must be protect against security risks: Risks to Confidentiality, Risks to Integrity, and Risks to Availability.

Clearly when accepting query requests or information, the eMPI needs to make sure the query request or information is authentic and authorative. This is typically done, and profiled in IHE with ATNA, with a mutual-authentication of the communications. That is that the requesting system can authenticate that they have connected to the correct and authentic eMPI, but also that the eMPI can be assured that the system that has connected to it is authentic and authorized. This system level authentication is usually enough for an eMPI, especially PIX/PDQ in a HIE. The XCPD profile also supports user assertions using the XUA profile. This allows the XCPD interface to an eMPI to make more fine grain decisions, but more importantly to record in the audit log more fully. This said, recognize that data returned to a system like an EHR is usually totally available to everyone in that EHR.

The eMPI should also be able to protect the different types of attributes that it holds. That is it might consider some attributes more sensitive than others. For example as I showed above the eMPI can authenticate the system that is sending a Query. For some of these systems might be more highly trusted with all the attributes, where other systems would be allowed only access to the healthcare identifiers.

Consent enforcement
There are use-cases where the very knowledge that a consumer has information at a healthcare providing location is considered controlled by privacy policy. This is true of the highly sensitive health topics (e.g. 42 CFR Part 2), but is also true in some states. In these cases there is a need to have the eMPI recognize the current state of patient consent to disclose. That is that the eMPI must not let others know that the patient has an identifier (or data) when the patient has not authorized it. In this case the eMPI acts as if the patient simply doesn't exist.

Resources
The HIT Standards Summer Camp covered Patient Matching and produced their report in August, 2011. This report leverages the more detailed report from ONC on Privacy and Security Solutions for Interoperable Health Information Exchange - Perspectives on Patient Matching: Approaches, Findings, and Challenges.

I thank Karen Witting (IBM) for helping produce this article. Karen has extensive knowledge of the Patient Matching domain, acquired during her extensive research to produce the Cross-Community Patient Discovery (XCPD) profile.

How granular does an EHR Security Audit Log need to be?

2011-12-06T10:38:00.000-06:00

The EHR needs to be capable to be as granular as possible on any 'security relevant' event that it controls, but be configurable so that local policy can choose how much logging they desire.

I got this question from one of the IHE mailing lists. - The answer is not as simple as the above summary, and brings up some gaps in our understanding of security audit log use regarding: academic pure answer, realistic answer, and operational reality.

------------------------------------------

Initial Question

I'd like some clarification on the auditing requirements for Content Consumer for XPHR.
PCC TF-1(Rev 7), section 4.8.2 says the following:

9. All activity initiated by the application implementing the Content Consumer shall generate the appropriate audit trail messages as specified by the ATNA Profile. The bare minimum requirements of a Content Consumer are that it be able to log views or imports of clinical content.
10. A Content Consumer shall log events for any views of stored clinical content.

Are these statements intended to mandate the auditing of each individual document that is viewed, each time that it is viewed, or is it adequate for the application to log that the user accessed functionality where clinical content can be viewed, without providing specifics?

-------------------------------------------

Answer:
Once a 'system' takes on the responsibility of the ATNA 'Secure Node' or 'Secure Application' the responsibilities of the IHE ATNA actor is system wide. This means that the system is responsible for creating audit messages for ANY of the security auditable events identified in ATNA (See Table 3.20.6-1. Audit Record trigger events) that it-self mediates. (It is not responsible for events that it is not in control of). This means that the system must be capable of recording, as a ATNA audit message, all the times a user accesses patient data within the control of that system. Not just the accesses to XPHR data. Not just the accesses to XDS. All accesses.

Yes, we know this is a big burden. But once a system is 'trusted' to communicate with other systems, especially in an HIE, it becomes part of a bigger system. If the system can't be trusted to record all security relevant events, then it should not be trusted to communicate at all. The HIE is a massive web of trust. Each system is responsible for controlling and monitoring their own domain, but each system is connected into a larger domain (e.g. XDS Affinity Domain).See my bloginar of the IHE - Privacy and Security Profiles - Introduction .
---------------------------------------

This created more questions

Thank you for your response John. I do understand the overall objective and goal for auditing via ATNA, however I am still trying to get a better understanding of how granular we need to get to with auditing events in an EHR system, particularly when an event is viewed. The explanation/examples below may seem very detailed but it would help me and our team get a better sense of what is required/your thoughts. Thank you.

In this example the following is true: The system is an EHR, not a PACS/Radiology system; The Radiologist has the proper security and privileges to access any/all x-rays in a patient record that he is assigned to.; and The Radiologist has the proper security and privileges to document findings on any x-ray in a patient record that he is assigned to.

The Radiologist 1) accesses a patient record via the Radiology Application to review a chest x-ray study. Then the radiologist 2) documents his findings. During his dictation he looks at two prior x-ray studies, 3) and 4). Then he actually looks at the first x-ray study a second time.

Does the system have to log like this:
1) “Patient Record Accessed – Chest X-ray study from 9 Nov 2011 @ 09:15 viewed”
2) “Patient Record Updated – Chest X-ray study from 9 Nov 2011 @ 09:15 updated”
3) “Patient Record Accessed - Chest X-ray study from 12 Dec 2010 @ 09:15 viewed”
4) “Patient Record Accessed - Chest X-ray study from 5 Oct 2010 @ 09:15 viewed”
5) “Patient Record Accessed – Chest X-ray study from 9 Nov 2011 @ 09:15 viewed” (2nd time)

Or can it look like this:
1) “Patient Record Accessed – Radiology Application”
2) “Patient Record Updated – Chest X-ray study from 9 Nov 2011 @ 09:15 updated”

Would it be sufficient for the system to log “Patient Record Accessed from Radiology Application” when the Radiologist first accesses the patient record to see the Chest x-ray(s)? The scope of what the radiologist has security and privileges to see in that application is known, and any/all radiology studies are available for him. Is it the intent of the standards to log “eyes on the screen” for each and every radiology study that is viewed?

There are an enormous number of health care events that are seen by clinicians on a daily basis. Just opening the “Medication Administration Record” application in an EHR can let a clinician see dozens of med admin events simultaneously. These med admin events are ATNA auditable “medication” events when they are prescribed, perfected, and delivered. But is it the intent of the standard to literally log each and every med admin event that a clinician viewed? Or does an Audit Log Record such as: “Patient Record Accessed – Medication Administration Record” meet the intent of the standard?

Opening the “Patient Schedule” application in an EHR can let a clinician see dozens of orders and scheduled health care events simultaneously for a patient, everything from an order for discharge, the completion of a bed bath, or a scheduled surgical procedure. Is it the intent of the standard to log each and every view of a health-care-service event that the clinician reviewed from the schedule?

The ATNA auditable “study-used” event may suggest a different audit logging level for a radiology study than for a bed bath or patient teaching episode. But does that event apply to an EHR or to the PACS/Radiology System that owns the study? There are also specific audit record requirements for some special events such as a CCD import (PHI-import), but once the CCD is in the system, there is nothing in the standard that suggests a different level of audit logging for each view of the CCD.

If it is necessary to specifically log every view of every specific radiology study or CCD, then is it also necessary to log every specific view of every administration of a medication, every bed bath, every bedside teaching episode, etc. Each of those events would be considered an ATNA auditable “health-service-event” when it was documented. But there is no specific “health-service-event-used” ATNA trigger event in the standard.
------------------------------

The answer to this question is complex.

I will address an easy one first. In your example it is not clear if the radiology viewing application is considered part of your EHR 'security boundary', or is outside. I bring up the term security boundary to describe the logical extent of your ATNA "Secure Node" or "Secure Application". Any security relevant event happening inside this boundary needs to be auditable, but any communications outside of this boundary needs to be strongly authenticated. So drawing your boundary is important. If the radiology viewing application is outside this boundary then you are not responsible for the auditible events that happen in that radiology viewing application.

A Security/Privacy office will take what they can get. So, the more you can record in the audit log the better. But there does become a point where the detail becomes noise and the goal of Surveillance is not aided. Remember that the goal of the Security Audit Log is to provide enough information that the Security/Privacy office(s) can determine that the users are following the Policies, thus detecting abuse by legitimate users and malicious factors. Yes part of this is the privacy office producing an Accounting of Disclosures and Access Report. What you are struggling with is a common problem that there is really few good answers available.

In DICOM they have answered this question by saying that the DICOM "Study" is the object of interest. When a Study is accessed, an audit event should be recorded. But for all the information within a study, audit events are unnecessary. It is assumed that if you accessed any part of the Study, you have accessed all of it (from a security perspective, from a medical responsibility we don't look to the security audit log.)

For the use-case you outline, either answer is likely right. You didn’t include the ‘study’ definition, so I can’t tell if they are different studies. Also, looking at something and switching away to something else only to come back to the first; seems more like you never left the first. From a Security/Privacy perspective they want to know what was viewed, not how many times it was viewed (although some might care. And surely efficiency studies might find it useful, but this is not a legitimate use of the security audit log).

A CDA document is an equivalent ‘nice’ sized object. But as you point out a CDA document is often decomposed into the EHR and not really accessed as a document after that. I would view a decomposed CDA as encapsulated into the EHR and now the proper control of the EHR and no-longer in CDA form.

An EHR as a standalone system (aka EMR in terms of ONC) is a very complext problem. One viewpoint that I have heard is that the EHR is seen as one patient centric object. That is one security object per patient uniquely identified. When a doctor selects a patient in the context of the EHR, one event is generated. Thus from the security/privacy perspective one must assume that the user viewed ‘everything’ in the EHR. This is likely bigger than desired, but trying to define a hard boundary smaller than that is simply not possible with the way we understand EHR today.

I will say that even within the context of an EHR; any events to create data, export data, or import data should be considered security events worthy of recording. An import or export event is when data is passed into or out-of the control of the security/privacy system. Assuming that the EHR boundary is defined by the Access Control system; which may not be the logical or physical boundary. This is also involved with your use-case, given that it seems you are calling upon an external viewer, which I assume is another control environment. Much in ATNA is very specific to how one draws the boundary of their ‘system’.

In my opinion, the export event is the most important to be detailed. Again, the level of detail is not clear; but identifiable objects such as CDA documents clearly are individually identifiable.

Another exception to this rule would be when someone (e.g. patient or doctor) puts specific policy limitations on a specific object inside the EHR (or sub-object given the above discussion). That then defines that object as something of interest and thus makes all accesses to that object auditable.

The last point is that you must satisfy the needs of the customer (using organization). So your customers will ultimately define the satisfaction criteria. This is typically done by providing sufficiently many auditable events and configuration controls that allow authorized administrators (security/privacy office) to turn-off some of them (better to have them turn on events, but that is a different issue).

Great question for profession societies like HIMSS to look at…

Document Submission: Audit requirements under error conditions

2011-12-05T09:08:00.000-06:00

I got this question through NwHIN-Exchange: When a receiver of a Document Submission request encounters an error, the entire submission is required to be backed out (i.e. the operation is atomic). Is the receiver still required to log audit data in this case? Required not to? Permitted but not required?

Recognize that this is a specific question about the transaction to submit a document. The XDS and XDR transaction: "Provide and Register". In this transaction it defines that the whole transaction must succeed or fail totally. Meaning if any reason causes part of the transaction to fail, the whole transaction must fail. Thus no changes are made if a failure happens.

There are two very different views that could be taken on this question:

a) Since everything is backed out, no changes were made. Thus why log anything.

b) Someone tried to do something, and any attempt to do something needs to be logged.

On (a), this is not a 'security or privacy' view. This would be a view of a "Medical Records" perspective. This doesn't make it wrong, but it does move the motivation. The ATNA audit logging is not for medical records retention reasons, it is for security/privacy surveillance. That is to say that the reason ATNA records events is to have an audit log that can prove that the security/privacy controls are working properly.

On (b), a system needs to have the capability to record the audit log event. The fact that the security-relevant-event is a transaction being rejected vs the same transaction being accepted is simply an attribute values in the audit log message. In the case of the transaction being rejected this is simply setting the fact that it was rejected (EventOutcomeIndicator), and why (EventOutcomeDescription).

Some will wonder if it is useful to record all of these events. This is a different factor totally. The event must be "record-able", what is being questioned is if it always needs to be "recorded". This is a question of "configure-ability" of the audit system. Classes of audit events might be disabled at the direction of some organizational and operational policy. They might be disabled at the generating system, or might be disabled at the Audit Record Repository (meaning not recorded). But this is a configuration. The system must still be able to generate the audit event.

Handling the obligation to prohibit Re-disclosure

2011-11-30T11:43:00.001-06:00

There is much discussion lately on a need to communicate along with Patient Data that the Patient Data can’t be re-disclosed. This very specific ‘obligation’ comes up often. This is just one of a set of ‘policies’ or ‘policy fragments’ that need to be discussed when putting together an Organization, HIE, Community, National system (NwHIN-Exchange and Direct Project), or Multi-National System (epSOS).

I think if people were to think through all of the use-cases, there is almost always a need for the obligation to not re-disclose the data that was communicated. It is actually simple data governance regardless of Privacy Policy. One should only publish, or more generically disclose, data that they themselves created. That is not to say that you should not include in your documents fragments or knowledge from previous documents. You should always include relevant evidence, with attribution. This is the topic of ‘Data Provenance’ discussions. This is typically a topic of Medical Records Retention.

So back to the specific obligation to not re-disclose. I would assert that this obligation simply becomes part of the rules-of-the-road, or data-use-and-reciprocal-support-agreement (See NwHIN Exchange DURSA – section 16). That is that this policy simply is elevated to an overarching policy. Thus it doesn’t not need to be encoded in the transaction level. It is already implied through the fact that there is a communications pathway that is acceptable, acceptable because of out-of-band agreements. By not trying to include it at the transaction level, we have a more simple transaction.

We do this for any ‘rule’ that we can. The more we can move into high level policy or governance the better. We are always trying to have simple transactions. This simplicity drive is not because we want to ignore Privacy, Security, Data Governance, or anything else. We strive for simplicity because it is more ‘simple’ to implement and thus more likely to be implemented. Simplicity also a prime factor in robustness.

Update: Based on some conversations... It might be better to think about having a way to let the receiver of data to know that they are explicitly allowed to re-disclose. hmm. That is not quite an obligation. That would be an allowance-beyond-baseline-rules.

Access Controls: Policies --> Attributes --> Implementation

2011-11-21T10:41:00.001-06:00

The IHE Access Control white paper describes through a diagram that how Policies affect the different resource domains (Users, Patients, Data, etc), and ultimately where the Policy Decision Point gets that information when it needs to make a decision. This simple concept is important to understand in order to determine any gaps in implementation or standards. The following is Figure 14, found on Page 35. This diagram does not propose to show all policies, all domains, or all attribute sources. But it does show many.

The paper goes on to analyze this deeper and Figure 17 (shown below) shows a different view of the attribute domains. In this diagram we can see the different attributes (little red boxes), grouped into the domains (big grey boxes).

The paper then shows in Figure 24, the classic XACML engine diagram with annotation on where these issues could possibly be satisfied. Clearly this is just one possible solution, but it is useful to view concrete models sometimes in order to understand the abstractions.

This just touches upon a few concepts from the Access Control Whitepaper. The paper is far more comprehensive than this.

Calendar of Healthcare Standards Activities

2011-11-19T17:59:00.001-06:00

Keith started this Calendar. I am just re-publishing it. I updated it with the dates that I know of. I added HL7, IHE, and ISO TC215. I don't know the DICOM dates. Seems it would be good for all these dates to be known so feel free to offer up more key dates. If you don't have access, you will need to ask Keith. Or just let us know.

Non-Repudiation is a very old art

2011-11-18T07:08:00.001-06:00

Updated: The video recording is available here.

During the ONC Annual Meeting I absolutely enjoyed Jay Walker Keynote: “Achieving Big Changes”. A wonderful history of technology starting with a clay device from 2000 BC that was used as a receipt.

I think it is the white cone on the far right in this picture from the Wired article on Jay Walker. This is a cone of pottery with markings on it. The exerpt for this picture identifies it "a truly ancient storage device, a Sumerian clay cone used to record surplus grain."

I really hope that this webinar is available for replay as it is fantastic lesson in where we get much of what we have today. In fact I think that he outlines very well many of the requirements that we still struggle to achieve with modern technology. Jay went on to explain much ancient artifacts role in advancements, artifacts from his own collection.

The clay device that Jay showed is not unlike the ‘Cuneiform tablet’ shown at the Metropolitian Museum of Art. The ‘technology’ at the time allowed for the creation of a receipt that was not possible for the holder to modify, or at least any changes would be obvious. The use-case, as Jay explains, was to record the amount of surplus grain that a farmer had deposited so that later the farmer could get back the grain or money it was worth. The receipt writer would make marks on clay, fire the clay to make it permanent, and give the receipt holder the hardened-pottery. Later the farmer could present the pottery and the merchant would be able to tell that it is legitimate and not changed.

So these 4000 year old devices are ‘the’ earliest samples of non-repudiation, the key characteristic that people look to for electronic signatures (Digital Signatures). Jay pointed out that not only are these some of the oldest examples of writing, but also non-repudiation. This shows how 'need' and 'value' drove the invention of these pottery based receipts. This same concept we look for in electronic signatures; of being something hard to create, hard to falsify, and verifiable. It also shows that the technology scales with the value it is protecting.

IHE N.A. Connectathon Conference - January 11, 2012

2011-11-17T15:13:00.001-06:00

This just crossed my desk:

Subject: IHE N.A. Connectathon Conference | Save the date! January 11, 2012

IHE North American Connectathon Conference 2012

Save the Date: January 11, 2012 in Chicago, IL.
Registration will open soon.

Joining a preeminent cadre of interoperability, information standards, IHE and health information exchange experts for a one-day educational and networking event at the IHE North American Connectathon Conference, January 11, 2012 at the Hyatt Regency in downtown Chicago, IL.

The IHE Connectathon Conference is a cornerstone of the annual IHE North American Connectathon and has will hit record breaking participation this year! Over 120 organizations are participating this year that will test 150+ systems. Attendees at the Connectathon Conference will be given special access to the testing floor and a guided tour of the event.

IHE USA is proud to announce an exciting and dynamic array of speakers and educational sessions for this year’s Conference. Please join us for this important event. Additional information regarding IHE N.A. Connectathon, plus the Conference dates and location are listed below. If you have other questions or need more information please contact us at Connectathon@ihe.net.

· Opening Keynote - Delivering High-value Health Care through Regional Health Information Exchange

Eric Heflin, Chief Technology Officer, Texas Health Services Authority

· Leveraging IHE XDS to Achieve Health Information Exchange - Real World Implementations

Holly Miller MD, MBA, FHIMSS, CMO, Med Allies

Jim Younkin, IT Program Director, Geisinger Health System, KeyHIE

· Current Advancements in Medical Device Integration

Elliot B. Sloane, PhD, CCE, FHIMSS
Professor and Director of Health Systems Engineering
Drexel University School of Biomedical Engineering

· Exploring Open Source Tools to Achieve Interoperability - Panel Discussion

James St. Clair, CISM, PMP, SSGB, Senior Director, Interoperability and Standards, HIMSS

Rob Kolodner MD, EVP, CIO, Open Health Tools

Ken Rubin, Object Management Group

· The Next Revolution in Standards-Based Image Sharing

David Mendelson MD, FACR, Chief of Clinical Informatics, Mount Sinai Medical Center

· IHE North American Connectathon Introduction and Guided Tours

Conference Dates & Logistics

The IHE N.A. Connectathon Conference is open to the public and we encourage IHE members to invite interested organizations and individuals that want to learn more about IHE.

Date: Tuesday, January 18, 2011

Educational Sessions: 9:00 – 4:30pm CT

Cocktail Reception: 4:30 – 6:00pm CT

Meeting Location & Hotel Accommodations:
Hyatt Regency - Chicago, IL.
151 East Wacker Drive
Chicago, IL 60601

Hotel Reservations: Click here.

Registration fee: $195.00

IHE Connectathons

IHE Connectathons are held in locations worldwide. This year at the IHE North American Connectathon 2012 there are over 120 healthcare IT organizations registered to test 150+ systems at this year's event. Conference attendees will learn about the IHE testing process, the IHE Profiles that are its foundation and IHE's support for critical improvements in healthcare.

Visit the official IHE Connectathon webpage for more information >>

If you have additional questions, please contact Connectathon@ihe.net.

IHE work items for 2012

2011-11-17T12:59:00.001-06:00

The IHE IT Infrastructure Technical Committee met this week to determine the work items that they will work on over the 2012 development season. They started with the output of the IHE IT Infrastructure Planning Committee selection of work item proposals. The short answer is that they agreed to take on all of the work item proposals, with a few scope reductions.

The work items for 2012 are:

Completion of the De-Identification cookbook – This is instructions to other IHE domains on how to create profiles that use anonymization and pseudonymization tools. I am co-editor so, I will be very busy working on this, hopeful that we complete it early next year.
Critical and Important Results – This is a white paper proposal to expand on the need to notify someone when something critical or important is uncovered. The idea is that when something critical or important is discovered, one needs to discover who should be told about this information and how should they be told. This seems to me to be something similar to how we expect PWP or HPD to be used, but with more deterministic results.
Configuration Management for Small Devices – This is a white paper effort to explore the area of configuration management in a very broad way. The expectation is that this white paper could point at common solutions from general IT (like LDAP, DHCP, DNS) for some problems that are not healthcare specific, while identifying gaps that are specific to Healthcare. These gaps could then be proposed as work items next year. This work needs to be further broken up into two phases so that we can focus on phase 1 to assure we don't have too much work to do, and yet can produce something useful to the community.
Fix XD* Technical Framework – This a project to fixup the current documentation around the XD* family of profiles. There are a well-known list of things that people who come at IHE for the first time can’t find. These things tend to be things that the long standing members simply assume are documented. This realization comes through Bill’s experience with the Connectathon test tools development and assisting individuals with their development efforts. This item seems to always be outstanding, but we must take it on as a top priority and get it done, well better. The result MUST not change any normative meaning. This is simply reforming the documentation so that it is more readable and understandable.
Document Access for mHealth – This is the project that Keith (and I) submitted. The proposal today is mostly identifying the constrained environment that is most prevalent on mobile devices (phones, tablets, etc) but which exists in other places. This constrained environment has troubles with the SOAP stack used in the XDS/XCA environment, and also find the ebRIM encoded metadata harder to manipulate. The proposal is thus to come up with an interface (SOA like) that an organization can offer to their users that is more attractive to these developers and thus will drive for Apps that might be more reusable across organizations.
Patient Encounter Tracking Query – This is a profile proposal to address the need to have a system where actors that know where a patient is can record the location, so that others that want to find the patient can discover their location. This might be automated with things like RFID, might be automated through registration desk activities, or might be manual. The profile proposal looks to leverage the PAM and PDQ profiles. This one really needs a english speaking editor and mentor. If we don't find one by December, this work item needs to be suspended.

Feel free to "Ask me a Question" if you want to know more.

XDS/XCA testing of Vocabulary Enforcement

2011-11-11T10:23:00.001-06:00

I was asked what vocabulary should be used to test to determine if system that has implemented XDS and/or XCA actors are compliant. The problem with the question is that it focuses on the technical specifications and ignores reality of how these standards are to be used over time. The technical specification does require a Registry to reject new document submissions with metadata entries having values not on the Affinity Domain approved list. So it seems logical to test that a Registry will enforce this code-set behavioral.

In general I point to the Robustness Principle is 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" . I would add to this Robustness Principle that you must apply the rules to the context of the situation/transaction. Let me explain:

In an XDS operational environment, such as a state RHIO like Conneticut, there will be a code-set that defines the acceptable vocabulary values for any of the metadata entries. Today this is logically the vocabularies found in HITSP-C80. But the operational code-set is a living list, it will change over time. This is already happening in S&I Framework (the new HITSP). This will happen in any implementation as there is always new documents being defined, and thus new vocabulary being needed. It is this change over time that is potentially not obvious when focused on the specifications and the here-and-now. More important is that a change overtime can't invalidate historically approved documents.

Publication of New Documents
In the case of an XDS Registry, there is a usefulness of the Registry warning a publisher that they are publishing a new data entry with metadata entries that have not-approved vocabulary. This is helpful as it allows the publisher to change the metadata values to acceptable values and try again. This typically involves using a different document template, an updated document template. Publication does need to be specific to the currently accepted list of documents that should be allowed to be published.

Interesting twist is that the publication may want to be more restrictive than the overall acceptable. For example a document that was acceptable in the past may be found as unacceptable in the future. This doesn't mean that the old documents are bad, but that there is a better new way to document the same information. This has not been discussed in IHE, as it is really a sample of a policy statement that an operational environment can make. A decision that doesn't affect the interoperability specification.

Query into the longitudinal Record
XDS Query likely needs to be more generous as this is a probe into the longitudinal record. A probe back in time, to a time when a different set of documents were considered acceptable, documents that would be considered today to be incomplete. So, it seems to me that a XDS query should be allowed to ask for anything; and an XDS Query results needs to be allowed to respond with anything in the longitudinal record. If a new Document Consumer can't understand the old documents, then it needs to be robust to this possibility. The Document Consumer likely does need to notify the user that there are documents that it can't process. This because there might be a safety concern if data is transparently dropped. Hopefully all Document Consumers would try really hard to support anything that could possibly be in the longitudinal record.

HIE merge
A disjointed version of this is the use-case where a system publishes a document into their local HIE in a way that is fully compliant with that HIE; then later that HIE joining a larger HIE. Should those historic documents be not available across the larger HIE? Surely they should not be forced to be republished under the new HIE rules. This similar situation will also happen over time, as 20 years from now we will have a very different view of what is logical for publication, while we must accept all 20 years of data as legitimate.

XCA (e.g. epSOS, NwHIN-Exchange)
An XCA (NwHIN-Exchange) environment is just the Query and Retrieve side, so it should be treated according to the XDS Query comment above.

IEC 80001 Step-by-Step Webinar

2011-11-09T13:38:00.002-06:00

Update: The recording is now available

Join us for an informative Step by Step Risk Management Webinar designed to provide additional guidance for Responsible Organizations just beginning to implement the risk management process, as part of IEC 80001-1.

This session will provide step-by-step information for organizations just beginning to implement the risk management process required by IEC 80001-1. It will provide guidance in the form of a study of risk management terms, risk management steps, an explanation of each step, step-by-step examples, templates, and lists of hazards and causes to consider.

IEC 80001 - Step by Step Risk Management
Wednesday, November 16th
2:00 p.m. (EST)Presented by Karen Delvecchio

Karen Delvecchio manages the Networks Engineering team for Patient Care Solutions in GE Healthcare, developing network infrastructure and networked-client capabilities with emphasis on risk management. As a member of JWG7, the committee responsible for IEC 80001-1, Karen was very involved in the development of the standard and related Technical Reports.

OCR Launches Privacy and Security Audits

2011-11-08T19:40:00.002-06:00

This just crossed my desk

From: OCR HIPAA Privacy Rule information distribution [mailto:OCR-PRIVACY-LIST@LIST.NIH.GOV] On Behalf Of OS OCR PrivacyList, OCR (HHS/OS)
Sent: Tuesday, November 08, 2011 8:39 AM
To: OCR-PRIVACY-LIST@LIST.NIH.GOV
Subject: OCR Launches Privacy and Security Audits

November 8, 2011

The American Recovery and Reinvestment Act of 2009, in Section 13411 of the HITECH Act, requires HHS to provide for periodic audits to ensure covered entities and business associates are complying with the HIPAA Privacy and Security Rules and Breach Notification standards. To implement this mandate, OCR is piloting a program to perform up to 150 audits of covered entities to assess privacy and security compliance. Audits conducted during the pilot phase will begin in November 2011 and conclude by December 2012.

More information regarding OCR’s Pilot Audit Program is available on the OCR website at http://www.hhs.gov/ocr/privacy/hipaa/enforcement/audit/index.html

Those Darn Error Messages

2011-10-31T11:04:00.003-05:00

I received this email from a senior systems engineer:

Reading about this exploit http://gcn.com/articles/2011/10/24/researchers-crack-xml-encryption.aspx reminded me about our discussion a long time ago about the perils of returning useful error messages from a privacy perspective. In this case, it’s not privacy that’s compromised, the hackers can use their knowledge of the typical boilerplate error messages returned by a SOAP transport layer when malformed XML is sent to help them to crack the encryption. Sounds like the fix is to avoid cipher block chaining. Article says it’s a pretty easy change. Hmmm.

I love it when the message sinks in and an engineer can see the message in something new.

Cipher Block Chaining has been the topic of other problems lately too, such as the 'BEAST' SSL problem. In both cases these are attacks on a, now understood, poorly constructed crypto mechanism – Cypher Block Chaining. This problem has been known for many years, the real problem is the slow upgrading of systems.

In the case of this new exploit, XML-Encryption is not the problem, but rather Web-Services Security way of using XML-Encryption. This is what some consider ‘end-to-end’ security for Web-Services. Something that I have resisted for many years, but did eventually end up in IHE ATNA as an alternative (See: IHE ITI TF:3:3.19.6.4 Web-Services carrying Protected Information(PI)). Fortunately this is not often used, as it presents the same operational administrative problems as Direct has, that the sender must know the receivers Digital Certificate. For Web-Services this presents more trouble than it is worth.

My suggestion all along, also the main part of the IHE-ATNA profile, has been to use Mutually-Authenticated-TLS. It is a well mature technology. Yes it has the 'BEAST' problem, but this is mitigated by the Client Authentication. Using TLS gets away from the newest XML-Encryption problem too. Note that the IHE ATNA approach to using Mutually-Authenticated-TLS does set the bar at Cipher Block Chaining (i.e. TLS_RSA_WITH_AES_128_CBC_SHA); but IHE does not in any way forbid other algorithms in operational use. The IHE profile is simply there to assure that there is one algorithm set that will function (interoperability). The TLS protocol does the negotiation of the ‘best’.

To return an error message or not is a tricky problem. I do recommend that for authentication and authorization failures that we carefully consider if a security specific error code should be returned – Using Risk Assessment. The reality is that the answer to this question is not straight forward. In fact, the answer is 'it depends'. It depends on if you know the security context of the network and requester. If you don't know better, then the answer is 'do not return a security related code, just return general-failure'. But if you do know something about the requester, then you can return a security specific error code.

A specific example of this comes up in discussions around Health Information Exchanges regarding authorization. Should an HIE Access Control service be able to tell the requesting system that consent to disclose or authorization for access is needed? If this was a non-authenticated request, my answer would be NO. But when using Mutually-Authenticated-TLS, that does successfully authenticate (meaning you have a secure communications to a known and trusted requesting system), then it is ok to return a code that would indicate that 'I could give you data if consent was to be captured or break-glass was to be declared. '

This specific error code can then be used by the requesting system to indicate to the user that more information is available but that authorization does need to be elevated (or different security context exits). A user that is authorized to break-glass could then indicate that they want to break-glass. A user that has the patient's specific authorization to access could indicate that they have authorization for access. Thus the error code is used to enable dynamic workflows, helping the patient get the treatment they need.

This kind of detail is hard to ‘profile’ in IHE as the profiles in IHE are intended to be re-used in many context. Thus there is a need to be as context independent as possible. It is only when a system is designed that the context is known. This is a good example of using Risk Assessment in the design at many levels including deployment.

National Council for Prescription Drug Programs and SAFE-BioPharma to Collaborate on Life

2011-10-31T09:30:00.001-05:00

This just crossed my desk. It is good to see a valuable use-case "ePrescription of controlled substances" moving into the electronic prescription environment using Digital Signatures. This use-case is valuable enough to overcome the expense and difficulty of using Digital Certificate identities.

NCPDP AND SAFE-BIOPHARMA TO COLLABORATE ON LIFE SCIENCE STANDARDS Scottsdale, AZ and Fort Lee, NJ (October 24, 2011) -- The National Council for Prescription Drug Programs (NCPDP) and SAFE-BioPharma Association announced today a strategic alliance to advance use of their respective standards within the life sciences.
NCPDP is an ANSI-accredited standards development organization which has led transformation in the pharmacy services sector by creating and promoting standards for electronic healthcare transactions. Working closely with its 1600+ members, NCPDP has produced operational efficiencies that save more than $30 billion annually in healthcare costs, while increasing the safety and quality of patient care. NCPDP standards, such as the Telecommunication Standard for billing and reporting claims and services, and the SCRIPT Standard for electronic prescribing, have been named in federal legislation, including HIPAA, MMA, and HITECH.SAFE-BioPharma Association created and manages the SAFE-BioPharma® digital identity and signature standard for the pharmaceutical and healthcare industries. The SAFE-BioPharma standard provides a secure, legally enforceable, and regulatory compliant way to verify the identities of parties involved in business-to-business and business-to-regulator electronic transactions. The standard is compliant with HIPAA regulations and is recognized by the Drug Enforcement Agency (DEA) as compliant with its rules for ePrescribing of controlled substances.
The two organizations will collaborate in meetings, working groups, and a variety of other forums.
"We are dedicated to transforming the healthcare system by collaborating on business solutions. Collaborating with SAFE-BioPharma will benefit the advancement of standardized solutions throughout the pharmacy services industry," said Lee Ann Stember, president NCPDP. NCPDP members represent every segment of the pharmacy services sector, as well as other healthcare stakeholder groups.
SAFE-BioPharma facilitates interoperability and integration among researchers, vendors, regulators, clinicians, prescribers, healthcare providers and other pharmaceutical and healthcare stakeholders. SAFE-BioPharma digital signatures are widely accepted by global regulatory agencies.

"Our collaboration with NCPDP will lead to even greater process and cost improvements for healthcare and other sectors of the life sciences. The SAFE-BioPharma standard helps assure the secure transmission of confidential and regulated health-related information. We believe that both of our organizations will benefit," said Mollie Shields-Uehling, president and CEO, SAFE-BioPharma Association. The association's members include Abbott, Amgen, AstraZeneca, Forest Laboratories, GlaxoSmithKline, Johnson & Johnson, Lilly, Merck, Pfizer, Roche, and sanofi- aventis. ### About NCPDPFounded in 1977, NCPDP is a not-for-profit, ANSI-accredited, Standards Development Organization with over 1600 members representing virtually every sector of the pharmacy services industry. Our diverse membership provides leadership and healthcare business solutions through education and standards, created using the consensus building process. NCPDP has been named in federal legislation, including HIPAA, MMA, and HITECH. NCPDP members have created standards such as the Telecommunication Standard and Batch Standard, the SCRIPT Standard for e-Prescribing, the Manufacturers Rebate Standard and more to improve communication within the pharmacy industry. Our data services include the NCPDP Provider Identification Number, a unique identifier of over 75,000 pharmacies, and HCIdea, "The Prescriber Identity Solution." For more information about NCPDP Standards, Data Services, Educational Programs and Work Group meetings, go online at http://www.ncpdp.org or call (480) 477-1000. About SAFE-BioPharmaSAFE-BioPharma is the global industry standard for digital trust. It was developed by a non-profit consortium of biopharmaceutical and related companies to transition the biopharmaceutical and health care communities to paperless environments. For more information visit: http://www.safe-biopharma.orgSAFE-BioPharma® is a trademark of SAFE-BioPharma Association. Any use of this trademark requires approval from SAFE-BioPharma Association

Critical aspects of Documents vs Messages or Elements

2011-10-25T06:30:00.004-05:00

When IHE first was looking at the Cross-Enterprise space, the idea of building an exchange between organizations we looked at many different factors. These factors are not well documented, this is clearly something that we failed to notice. One of the critical decisions we made was around the object that would be managed in this Cross-Enterprise space. At the time it was not clear what would be the best approach.

We needed to pick an object size that was big enough to be manageable, without being so big so as to be cumbersome. One possibility was to take the approach of the HL7 V3 RIM, that is break down everything into the element level. This has some real advantages when it comes to ‘use’, but it presents great challenges when it comes to input, security, privacy, and provenance. The most hard to handle is the provenance question. For every element must be traceable back to who submitted it and when. This quickly becomes a case of more metadata than data. This could easily be 10 times more data about the data than the underlying data it-self. The other big concern is the context of the data. A lab value may be understood by the doctor that ordered it, because that doctor remembers the context of the lab order. But 20 years later it will not be clear that there were extenuating circumstances around the order.

At the time there was the CDA vs CCR wars. Even though there was strong support for CDA within IHE, we didn’t want to lock ourselves to CDA. Another way to look at this was to recognize that there are clearly needs to manage DICOM reports and a recognition that much of the paper would simply be scanned into PDF documents. Thus we knew we had to be very content agnostic. We did however need to pick an object size, and the one represented by CDA, CCR, DICOM SR, PDF, and others seemed better than the element level. The XDS infrastructure ultimately put one condition, that the object is defined by a MIME-TYPE. There is a small set of other metadata, and it is true we derived much of that metadata from the CDA header.

Specifically there are some well-defined attributes of a CDA Document that become really useful when we look at Cross-Enterprise HIE, especially when we recognize that this is not just Cross-Enterprise but also longitudinal. We needed an object size that could stand up to the test of time. Surely CDA will come and go, but the concept of a Document as a sustainable object will continue.

Some good discussions of the CDA Document characteristics can be found in the HL7 CDA standard (shown here in the 2008 ballot), or in the CDA Release 2:

What is the CDA

The HL7 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of "clinical documents" for the purpose of exchange. A clinical document is a documentation of clinical observations and services, with the following characteristics:

· Persistence – A clinical document continues to exist in an unaltered state, for a time period defined by local and regulatory requirements (NOTE: There is a distinct scope of persistence for a clinical document, independent of the persistence of any XML-encoded CDA document instance).

· Stewardship – A clinical document is maintained by an organization entrusted with its care.

· Potential for authentication - A clinical document is an assemblage of information that is intended to be legally authenticated.

· Context - A clinical document establishes the default context for its contents.

· Wholeness - Authentication of a clinical document applies to the whole and does not apply to portions of the document without the full context of the document.

· Human readability – A clinical document is human readable.

It is very true that these are not guaranteed as part of an instance of CDA, an implementation can always produce garbage. But these characteristics are used as guiding principles in the design of CDA.

I think these same characteristics are generally available in all document formats. At least they should be if you are going to put that document into a longitudinal exchange. The way that DICOM SR does this is different than CDA, but the differences are not important. The fact that PDF is just a blob doesn't prevent these characteristics from being true. They usually are true of paper documents (aka Reports), that might be scanned into a PDF. Thus although CDA was a guiding document type, it is not core to XDS. Any document can be exchanged using XDS. For example IHE is profiling a new document that is based on OASIS specifications and didn't exist before, and XDS will work just fine.

The fact that we start with Document as the size of an object today does not forbid us from going smaller. It does give us an object size that is reasonable and achievable. The fact that we use Documents also does not forbid us from decomposing them for use in a Clinical Decision Support system. A patient could authorize a CDS service to import all registered documents, decompose them, and create a clinical information database. I think it is more reasonable that these decomposed databases would be authorized by the patient to a service the patient uses regularly. This might be their PHR or it might be the EHR or their GP. As this service becomes more defined and mature the PHR and EHR might share an instance. See: Access Controls on Clinical Decision Support

See:

Using both Document Encryption and Document Signature

2011-10-24T08:25:00.001-05:00

Sometimes one needs to have both a Digital Signature and protect the content with Document Encryption. The Digital Signature (DSG) content profile from IHE provides the Digital Signature. The Document Encryption (DEN) content profile from IHE provides encryption of the document in a transport agnostic way.

Which should I do first, encrypt or sign?

I would recommend signing first, as the signature is more likely to be a long-term signature; whereas the DEN encryption is more for a specific communication purpose (even though it is transport agnostic). The other reason is that logically one will unwrap the encryption protection then need to verify the authenticity of the content. One might also hang on to the signature within a protected system to prove authenticity long into the future.

How can the consumer tell which was done first?

The fact that DEN produces a new document object, will make it obvious which document is being signed. Said another way the DSG signature identifies the document object that was signed. Thus the DSG signature could be across the original, unencrypted, document; or it could be across the encrypted document. The DSG would identify which of these objects was signed. If the signature is across the encrypted document then the DSG signature points at the new document object which is the encrypted document. If the signature is accross the original document, then the DSG signature points at the original document object, that is not encrypted.

But the DEN profile includes "Content Integrity"?

The DEN profile is providing ONLY for encryption. It is not proposing to take the place of DSG. The DEN profile does include an integrity check on the original document. This integrity check (Content Integrity) is there to assure that the decryption produced the document that was encrypted. The integrity check is not intended to replace a digital signature. For example this integrity check does not include a 'purpose' for the signature. This content integrity is there only to prove that the decryption 'worked ok'. It doesn't prove that the decrypted file is the one that you think the originator intended to send to you. It is likely that the decrypted document is the one intended, but the point I am trying to make is that DEN does not take the place of DSG.

Why keep these two functions so totally independent?

If you want both Authentication of the content and Encryption of the content then you should use both profiles. The main reason to keep these independent functions is to recognize the long-term needs of both are very different. Specifically the impact on long-term key management. In the case of a digital signature, one must maintain knowledge of certificate validity, but one does not need to maintain the private key. In the case of encryption, if one wants to keep things encrypted for a long time, one must maintain the private key. Organizations will also want access to encrypted content of their individuals and often will archive the encryption keys (aka Key Escrow). Surely getting the key back must be a protected action, but there are legitimate needs. This is the reason why Keys are created typically for one or the other purpose and rarely for both purposes. Usually if they are created for both, the use is for communications (e.g., TLS, SSL, S/MIME).

Edited: Note there are many other reasons to have an independent signature such as to have multiple signatures, signatures at different times, counter signatures, co-signatures, signature just for source authenticity, signatures just to indicate the content was reviewed. See Digital Signature for more on this.

For more information:

IHE - Privacy and Security Profiles - Document Digital Signature
IHE - Privacy and Security Profiles - Miscellaneous
Federated Identity.

ISO work on Privacy and Security

2011-10-23T12:50:00.003-05:00

This week was the workgroup meeting for ISO TC215 – Health Informatics. I have recently re-established contact with this body, having missed most of the years’ work. The advantage I have is that everything seemed fresh and new. There is no question that there is some useful work going on in ISO TC 215.

Here is my report on the work done in WG4 (Security/Privacy)

ISO 14441: Security & privacy requirements of EHR systems

This is a new work item. The initial reaction by both Bernd and I, both co-chairs of the HL7 Security WG, was to question why this work was being done when HL7 was already working on this as a sub-component of the EHR Functional Model.
The members then showed us the work, and it is very impressive. They have incorporated input from many sources including EHR Functional Model, CCHIT, and elsewhere. They have done a complete cross-walk with regulations in 5 countries including USA, Russia, Brazil, and Europe.
They have a cross walk with the major IT Security standard, ISO 15408 Common Criteria.
The result is a set of 18 categories of security and privacy functionality with less than 60 total requirements. Many of these carrying the original wording from the source material.
The work item plan was to have a second part that focused on the needs of small EHR. The members concluded that on the scope of privacy and security functionality there was no difference between large or small. Thus the second part will not be worked on.
I then observed that this work is more mature than the EHR Functional Model, and that we need to harmonize the two works together. The EHR Functional Model will ultimately be dual balloted with ISO, so the harmonization is critical. I worked with the co-chairs of the EHR Functional model that were also present at the meeting. The hard part is that both works are undergoing ballot at the same time. The plan that I worked out is to pull all of the ISO 14441 into the EHR Functional Model, replacing the criteria in the EHR Functional Model today. Make sure that the comments already registered with the EHR Functional Model are still handled. As part of this the criteria in ISO 14441 will need to be reworded as the format of the EHR Functional Model is specific to enable their profiling. Ballots on both works will be resolved in harmony, resulting in a single set of criteria. Where the EHR Functional Model points at the ISO 14441 for details and cross-walk.

Potential new work item on Patient Consent

There was discussion of a new proposal to address Patient Consent.
Bernd and I both commented regarding the good and existing work in HL7 on consent including the Privacy/Security DAM, CDA Consent Directive, confidentialityCode vocabulary, and the work on Ontology.
There was much discussion of the role of IHE BPPC, the HL7 CDA Consent Directive, and future work. Many people don't understand that the HL7 work starts from the IHE BPPC and enhances it. I need to blog about this.
The work item will focus mostly on the high level guidance and point at HL7 for the normative aspects. Although it is not clear that this is fully agreed to. This will require much monitoring to prevent overlap.
The workgroup was significantly out of date regarding the concepts that have been learned regarding this space. It is not clear to me that the group contains subject matter expertise to support this item.
I think this NWIP proposal will go forward. If it can be kept in harmony with HL7, then it can be a good thing

ISO 17090 new work item proposal Part 4: Digital signature

There is a new work item proposed to address Healthcare needs for Digital Signature. The work is being added as a new part on the Digital Certificates family. The work needs to be kept specific to the healthcare needs. It should be focused on pointing at ETSI for the Digital Signature specifics (XaDES is the XML profile).
I recommended that they look to harmonize with the IHE Digital Signature Profile. This profile recognized that there is only a few things that need to be profiled given the underlying standards of XML-Signature and XaDES; the format of the date/time and a mechanism to hold the signature purpose. With the signature purpose vocabulary being specific to healthcare.

Standards for safe health software

The work is now sourced out of Canada, where they are still struggling to get their regulators to recognize software as a medical device. This is in direct contrast to the FDA that has come out with specific guidance on software and even mobile applications.
The work is trying to be more open to discussion and input. They do now recognize the problems that vendors would have if they were forced to use two different processes for developing health software.
There is formal requests to make this a joint work with IEC 62A. Which is the group that normally deals with Safety.
I would like this work to be risk based and recognize risks to Safety as well as Security and Effectivity. This is the scope that IEC 80001 took, and it works out good for things that need to be integrated at the operational level.

ISO 16864: Data protection in trans-border flows of personal health information

There was not much discussion of this work item. It is attempting to take a high level view of the needs and the available standards to support those needs.
The work item has failed ballot due to lack of subject matter experts. I think the problem is that the work item is simply too grandiose.

ISO 21549-Patient healthcard data – 2, 3, 4, 7

The USA has and continues to ignore this work. We, at best, look to WEDI for a standard format for printed and magnetic stripe.
Common is a desire to keep these health cards to mostly identifiers
There continues to be some that think it would be useful to put data on these cards. The committee members are very much against this as it presents security and privacy concerns, and also raises the question of freshness of the data. As evidence of this, they are looking for experts to work on a new part that would define the data. No experts are coming forward.

ISO 16114 Security Aspects of EHR Migration

This work items started a long time ago, and has been moving very slowly. Presented this week was the struggle with defining what an EHR is. This struggle must recognize the various deployment models including classic client/server, n-tier, software as a service, etc.
I have strong concerns with this work item. I don’t see there being a possible thing to abstract enough for ISO to write a good Technical Report on. The aspects of ‘migration’ are simply too specific to the instance.
There is no clear defining line where something goes from a software upgrade to a ‘migration’. They have put out of scope the case of backup with recovery.
Unfortunately this work is already underway so it now must conclude in something.

ISO 22600 PMAC Update

This is the regular review of this existing specification. There have been significant updates that are considered positive changes. The essence of the specification is not changed. Most of the changes are editorial or to update the text to modern terminology.

ISO 27799 ISM in Health Using ISO / IEC 27002

This is the regular review of this existing specification. The problem the committee has is that this work was originally written before IEC 27001 was final. Healthcare received a number in the 27000 family expecting this move. Now the work item needs to be reformatted and changed to reference the IEC 27000 family rather than the 17799.
No significant changes beyond reformatting are expected.

ISO 21091: Directory services ballot results

This work was up for review, and received very little requests to change it. There was indicated much support for it globally. This is also included in the IHE HPD, although not completely.

ISO 17090-1, -2, -3: PKI Comment resolution

This work was up for review, and received very little requests to change it. The main things were some issues around mandatory fields. Experience has shown that there is resistance to some of the items that were considered mandatory. The changes are all reasonable.

Potential new work item on Privacy Officer Education

This proposal was hard to understand what was being proposed as a work item. I think that it is well beyond the scope of a standards organization. There is plenty of this kind of education available. I think the request is to put together one set of training.
I don’t see how this can be done on an international level and be successful.

DIS 27789 Audit trails for electronic health records

This is the work to formalize the ATNA use within EHR.
It is awaiting going out for second DIS ballot
The work item was not discussed.

I was very happy with the results of the 2 days I participated. This was far more productive than ISO meetings in the past. I would still like to see more participation from subject matter experts, the membership tends to be the same people from academia. This is mostly an effect of the way that ISO operates. It is so frustrating to have this country focused model, where all of the USA gets one vote equal to even the smallest and undeveloped country.

Patient access to Radiology

2011-10-21T10:40:00.001-05:00

e-Patient Dave asks Is “Gimme my damn data” coming to radiology at last??

Radiology (all modalities of Imaging) have had many ways to provide patients with their Damn data. The CD that e-Patient Dave refer to is an example that is heavily used. It is not clear from e-Patient Dave's post if the CD he is given is "DICOM Compliant", if it was then the viewer on the CD is not the only viewer available. There are many DICOM viewers you could use. Further these are full DICOM objects so they can be imported into a PACS or even HealthVault. Where they can be fully manipulated by those tools.

IHE has profile of this Portable Data for Imaging (PDI) This profile is compatible for the wider profile for any Documents on media Cross-Enterprise Document Media Interchange (XDM)

Which is the profile recommended to be used to carry content by the Direct Project.

Thus, the whole space of Healthcare Information can be put on interoperable media and provided to the patient on removable media or e-Mail.

Note that there are equivilant and compatible solutions for a local Health Information Exchange (XDS), and NationWide Health Information Exchange (XCA).

All using the same document, and same metadata, and fully specified for Privacy and Security. What is lacking is the Mandate -- the "Damn" part of the story.

Nominations Sought for First SAFE-Biopharma Digital Identity Awards

2011-10-14T18:06:00.004-05:00

This just crossed my desk

NOMINATIONS SOUGHT FOR FIRST

SAFE-BIOPHARMA DIGITAL IDENTITY AWARDS

Ft. Lee, NJ (October 13, 2011) -- Nominations are now being accepted for the first SAFE-BioPharma Digital Identity Awards recognizing innovative uses of the global SAFE-BioPharma® digital identity and digital signature standard and the institutions and individuals contributing to broader understanding of its benefits.

SAFE-BioPharma, the global industry standard for digital trust, was developed to transition the biopharmaceutical and healthcare communities to paperless environments. The standard is managed by SAFE-BioPharma Association, a non-profit consortium of biopharmaceutical and related companies. The US Food and Drug Administration and the European Medicines Agency participated in the standard's development.

Organizations and individuals are invited to submit brief nominations in any of the following award categories:

Innovative implementation of the SAFE-BioPharma standard

Biopharmaceuticals

Pilots
Implementations

Healthcare

Pilots
Implementations

Innovative product compliance

For a vendor partner compliant product

Individual who has contributed to standard's use and advancement

Regulatory advances

New advances in regulatory acceptance

Global expansion

Use of standard globally or regionally

Journalistic reporting

For advancing understanding and use of the standard

The deadline for nominations is December 15, 2011. Nominations will be judged by the SAFE-BioPharma Board of Directors, representing many of the association's member companies. Winners will be announced in February. The award will be presented annually.

The nomination form is available by linking to www.safe-biopharma.org/nominationform.htm .

###

About SAFE-BioPharma
SAFE-BioPharma is the global industry standard for digital trust. It was developed by a non-profit consortium of biopharmaceutical and related companies to transition the biopharmaceutical and health care communities to paperless environments. For more information visit: http://www.safe-biopharma.org

SAFE-BioPharma® is a trademark of SAFE-BioPharma Association. Any use of this trademark requires approval from SAFE-BioPharma Association

More Webinars on Basics of IEC 80001

2011-10-14T08:53:00.001-05:00

I am still surprised at how popular my webinar was on the soon to be released IEC 80001 Technical Report on Security. The webinar didn't record well, so there is no recording of my webinar. I have posted the slides.

The background on the core IEC 80001 was the topic of two webinars about a year ago. These webinars were recorded and are still very good today. I highly recommend that you review them.

Help is Just Around the Corner: Guidance on implementing IEC 80001

Learn how to prepare for risk management of medical devices on an IT network, including where to find the standard and its supporting technical reports, what is in the 4 technical reports and how to use them. Learn also how to perform a risk assessment for a medical device using the technical reports as a guide.

A World of Increasing Challenges: ISO 80001 and Medical Device Networking integration into Electronic Medical Records.

Overview of the pending ISO/IEC 80001 standard requirements from one of the IEC committee members. Considerations for Medical Device Networking integration into Electronic Medical Records.

This month and next month are two more webinars on two soon to be published Technical Reports:

IEC 80001 Guidance for Wireless Medical IT Networks - October 19, 2011 2pm-3pm EST

This session will provide guidance regarding wireless networks for organizations just beginning to implement the risk management process required by IEC 80001-1. It will provide guidance on Planning & Design, Deployment & Configuration, Management & Support, and Risk Mitigation techniques.

Step by Step Risk Management of Medical IT-Networks; Practical Applications and Examples - November 16, 2011 2pm-3pm EST

This session will will provide step-by-step information for organizations just beginning to implement the risk management process required by IEC 80001-1. It will provide guidance in the form of a study of risk management terms, risk management steps, an explanation of each step, step-by-step examples, templates, and lists of hazards and causes to consider.

IHE ITI New work items for 2012

2011-10-13T10:56:00.001-05:00

The IHE IT Infrastructure (ITI) Planning committee met this week to assess the new work item proposals. There are 6 new work items this year, only 2 of them propose new profiles. There is also some unfinished business from last year to cover.

The unfinished business is

Completion of the De-Identification cookbook – This is instructions to other IHE domains on how to create profiles that use anonymization and pseudonymization tools.
Create a Cross-Enterprise Workflow (XDW) training package and assist other domains with the creation of their specific workflow that uses this infrastructure profile.
And the normal documentation maintenance including change proposals, wiki, and profile lifecycle management.

The new work items were presented and discussed (the FTP site has some of the presentations but not all of them)

Critical and Important Results – This is a white paper proposal to expand on the need to notify someone when something critical or important is uncovered. The idea is that when something critical or important is discovered, one needs to discover who should be told about this information and how should they be told. This seems to me to be something similar to how we expect PWP or HPD to be used, but with more deterministic results.
Patient Encounter Tracking Query – This is a profile proposal to address the need to have a system where actors that know where a patient is can record the location, so that others that want to find the patient can discover their location. This might be automated with things like RFID, might be automated through registration desk activities, or might be manual. The profile proposal looks to leverage the PAM and PDQ profiles.
Configuration Management for Small Devices – This is a white paper effort to explore the area of configuration management in a very broad way. The expectation is that this white paper could point at common solutions from general IT (like LDAP, DHCP, DNS) for some problems that are not healthcare specific, while identifying gaps that are specific to Healthcare. These gaps could then be proposed as work items next year.
Fix XD* Technical Framework – This a project to fixup the current documentation around the XD* family of profiles. There are a well-known list of things that people who come at IHE for the first time can’t find. These things tend to be things that the long standing members simply assume are documented. This realization comes through Bill’s experience with the Connectathon test tools development and assisting individuals with their development efforts. This item seems to always be outstanding, but we must take it on as a top priority and get it done, well better. The result MUST not change any normative meaning. This is simply reforming the documentation so that it is more readable and understandable.
Document Access for mHealth – This is the project that Keith (and I) submitted. The proposal today is mostly identifying the constrained environment that is most prevalent on mobile devices (phones, tablets, etc) but which exists in other places. This constrained environment has troubles with the SOAP stack used in the XDS/XCA environment, and also find the ebRIM encoded metadata harder to manipulate. The proposal is thus to come up with an interface (SOA like) that an organization can offer to their users that is more attractive to these developers and thus will drive for Apps that might be more reusable across organizations.

The new work items were discussed, evaluated, and prioritized. Given the few number of items, they are all being handed over to the Technical Committee for evaluation.

Proposal title	Critical & Important Results	Patient Encounter Tracking Query	Config Mgmt for Small Devices	*Fix XD Technical Framework**	Document Access for mHealth
Proposal type	White Paper	Profile	White Paper	Refactor Doc	Profile
Workload Size Estimate	Medium	Medium	Large	Medium	Large
The significance and urgency of the interoperability problem in the business of healthcare? low 1 - 5 high	4	3	3	4	4
Benefit to global community low 1 - 5 high	5	4	3	5	4
Degree of expected adoption (for WP relates to use of the content) low 1 - 5 high	3	3	2	5	5
Alignment with IHE development domains outside of ITI low 1 - 5 high	4	3	4	4	3
Alignment with internal responsibilities of ITI low 1 - 5 high	5	4	4	5	5
Total Score 5-25	21	17	16	23	21
Criteria-based Ranking	2.5	4	5	1	2.5

There was a priortization step, but it resulted in mostly the same outcome as the above evaluation.

The Technical Committee meets next month. Their task at that time is to determine the feasibility of these work items, dig deeper on the available standards, assess more strongly the size estimates, and make sure that resources are lined up and ready to execute. The result is a joint meeting of the Technical and Planning committee to decide on what actually will be worked on next year. The capacity estimate we guessed at during the start of the meeting seems like it might fit all this content. I worry about that as we always increase scope on work items, and then end up with poor quality and missed deadlines.

Between now and the next meeting, Keith and I must do a better job of explaining the scope of our mHealth proposal. For example does it support both query/retrieve and Create? Is it a Cross-Enterprise profile, or one that we only assess as a last-mile API that an organization hosts for their users? Of the XDS queries, which ones are needed and how constrained can those be? How much can we off-load to the Service as the Client really doesn't need to be bothered? What might the metadata encoding simplification look like? What technologies are in scope? What deployment scopes can be placed on profile? How will privacy and security be handled? Keith got a good start on this in an email.

Other business

The planning committee is responsible for other things, such as education and outreach. In this space there is some really good progress. The first white paper is critical, there isn't much to look at today but we are working hard to make it highly useful.

White Paper on how to use the IHE Profiles to share documents
Educational presentation content and webinars
Wiki profile descriptions
Preparation for meeting at HIMSS
Assess other opportunities for communicating about ITI work

Data Segmentation - now I know where the term comes from

2011-10-11T13:41:00.001-05:00

During the kick off meeting for the new S&I Framework project on "Data Segmentation" I found out why this concept of Patient Privacy Policy and Controls keeps being called "Data Segmentation". The key is a project funded by HHS a year ago that resulted in a white paper on September 29, 2010 titled "DATA SEGMENTATION IN ELECTRONIC HEALTH INFORMATION EXCHANGE: POLICY CONSIDERATIONS AND ANALYSIS" (Sorry for the shouting, they actually used all uppercase). This white paper was authored and presented at the S&I Framework "Data Segmentation" kickoff meeting by Melissa M. Goldstein, JD. Melissa did a fantastic job of explaining the content, and I now understand why the scope is what it is. I simply wish that the simplification of the subject would have been from later in the title "Policy Considerations".

Note that these resources are on the HHS site on Privacy and Security

The executive summary indicates

This discussion raises the issue of data segmentation, which we define for the purposes of
this paper as the process of sequestering from capture, access or view certain data
elements that are perceived by a legal entity, institution, organization, or individual as
being undesirable to share. This whitepaper explores key components of data
segmentation, circumstances for its use, associated benefits and challenges, various
applied approaches, and the current legal environment shaping these endeavors.

Data segmentation in the health care context can support granularity of choice with
respect to the following:
What specific data are eligible for exchange (from individual data elements to defined categories of data, such as all behavioral health records);
Who has access to the information (from individual providers to other health care entities);
Under what circumstances access is granted (e.g., emergency access, treatment, etc.); and
For what period of time access is granted (e.g., unlimited, one-time access, etc.)

The executive summary concludes

As such, it will be important for policy makers to consider various approaches to moving
not only the discussion, but also the meaningful realization of data segmentation,
forward. Data segmentation efforts to date have explored a variety of approaches that
show some early, but limited, success. To accelerate this forward momentum, we would
suggest, among other pursuits, the following:

Build a Bridge to Greater Autonomy: Rely on policy levers that will move us closer to the goal of supporting individual, subjective preferences for information management;
Provide Direct Financial and Other Support to Stimulate Change: Consider various means of supporting the development of segmentation-enabling processes and technologies; and
Generate Evidence: Given the significance of the transformation from paper to electronic means of data capture and sharing, establish and execute on a set of updated research priorities.
We support the idea of casting a wide net in search of appropriate means of providing
patients more granular control over the exchange and use of their identifiable health
information, and point to the efforts underway in other countries as evidence that this is a
worthwhile endeavor. While still a challenge, data segmentation holds promise for
accomplishing the ultimate goal of accommodating the needs and desires of the multiple
stakeholders engaged in the electronic exchange of health information.

The report is very extensive.

IEC 80001 - Security Technical Report presentation

2011-10-10T15:16:00.002-05:00

I presented the soon to be published Security Technical Report IEC 80001-2-2 "Guidance for the disclosure and communication of medical device security needs, risks and controls". There is an assumption that the audience has an understanding of the basics of IEC 80001-1 "Application of Risk Management for IT-Networks Incorporating Medical Devices". I have been involved in the creation of this set of specifications from the beginning and provided some background here on my blog.

This webinar was well attended for a security webinar with close to 150 participants. My blog has also been very actively referenced since then. So I can tell there is strong interest. Unfortunately the audio recording of the webinar failed, so the best I can do is offer up the slides. The full slide deck is available on Google Documents

ONC Announcement of E-Consent Trial Project Contract Award

2011-10-05T09:24:00.002-05:00

This is a really great project by ONC to address the soft side of HealthIT and HIE. That being the interface with the human patient, specific here to educating and getting the consumers preferences.

C.2. PURPOSE
The Office of the Chief Privacy Officer (OCPO) within ONC proposes to award a contract to

a. Use innovative ways to
i. Educate and inform individuals of their option to give individual choice (e.g., automate informed consent process, patient-centered decision making process) in a clinical setting to share their health information electronically; and
ii. Ensure that individuals are knowledgeable participants in decisions about the sharing their electronic health information in a clinical environment.
b. Explore and evaluate ways of electronically obtaining and recording meaningful and informed choice from individuals in a clinical setting, regarding sharing their electronic health information.

The project is designed to help identify some innovative best practices in ensuring that any choices patients make with respect to sharing their health information are indeed, meaningful: i.e., patients are adequately educated about issues that are important to them, and that they understand the choices they make as well as the consequences of those choices.

I looked deeper in the document and was happy to see recognition of the existing works of IHE.

My biggest concern is that there doesn't seem to be enough guidance to the contractors to (a) look globally for how this is handled in other environments, and (b) to gather a set of reasonable privacy policies and their variability. In the case of (a) there are other environments that are ahead of USA on presenting Healthcare Information Exchanges, and thus there is some lead there on how they interact with the patients.

In the case of (b) I worry that this project will focus only on what the patient wants to control, and will forget that the healthcare provider organization has the right to not accept all the controls that the patient desires. Typically this is due to real patient safety or provider safety concerns, sometimes it is because the provider organization knows they simply can't protect the data in that way. Sometimes it is because the provider organization does indeed use the data in secondary ways that do conflict with the patients preferences. This specific issue took much time to discuss in HITSP. It turned out to be a core part of TP30, that recognized that there is a need to record patient preferences that are not actionable directly but are there for a healthcare providing organization to utilize when they formulate the policy choices that they offer to the patient. It is only the binding of a patients accepted preferences to the providing organization that creates an actionable privacy policy that the organization is held to. (note I use organization here inclusive of Health Information exchange Organizations).

I look forward to any opportunity to get involved with this project.

From: ONC Health IT [mailto:onchealthit.@service.govdelivery.com]

Sent: Monday, October 03, 2011 9:01 AM
Subject: Announcement of E-Consent Trial Project Contract Award


	Announcement of E-Consent Trial Project Contract Award ONC's Office of the Chief Privacy Officer recently awarded a contract to APP Design, Inc. to find an efficient, effective, and innovative way to help patients better understand their choices regarding whether and when their health care provider can share their health information electronically, including sharing it with a health information exchange organization. The project team will design, develop, and pilot innovative ways to electronically implement existing patient choice policies, while improving business processes for health care providers. To learn more about the E-Consent Trial project, please see the Statement of Work. ONC's formal launch of the E-Consent Trial Project will be in October.

	Questions? Contact Us STAY CONNECTED: SUBSCRIBER SERVICES: Manage Preferences \| Unsubscribe \| Help This service is provided to you by The Office of the National Coordinator for Health Information Technology.

IHE IT Infrastructure Cross-Enterprise Workflow Supplement ready for Trial Implementation

2011-10-05T06:51:00.005-05:00

This is a going to be a highly re-used fundamental profile. As it is published by the ITI committee it doesn’t do much, but when other committees put it together with a clinical workflow it becomes a powerful tool to drive workflows across enterprise boundaries. For example, enabling the kind of workflow that Keith discusses in A Patient's Viewpoint of Provider Workflow

IHE Community, IHE IT Infrastructure Technical Framework supplement published for Trial Implementation
The IHE IT Infrastructure Technical Committee has published the following Technical Framework supplement as of October 3, 2011:· Cross-Enterprise Document Workflow (XDW)
Note: This supplement will be tested for the first time at the IHE Europe Connectathon in May 2012

The document is available for download at http://www.ihe.net/Technical_Framework. Comments on this document can be submitted at http://www.ihe.net/iti/iticomments.cfm. We use this email distribution channel for periodic updates on IHE activities. If you wish to respond to this message or to be unsubscribed from this distribution list, please send a message to secretary@ihe.net.

a New S&I Initiative: esMD Call for Participation

2011-10-03T07:40:00.002-05:00

The S&I Framework is kicking off yet another project. I exhausted with the number of projects that I need to participate in today, and I only participate in a few (Keith is our lead this year). This new project seems like 3 totally different use-cases rolled into one. So it is actually three new initiatives. I can’t quite understand what use-case 2 and 3 are. They are so broadly written that they could be almost anything. But use-case 1 is one I can help with.

Digital Signatures are a topic I have covered multiple times. I don’t know of anything new being asked for, so I will just point at the existing work on the topic. This work includes use-cases, standards assessment, vocabulary identification, and profiling of standards.

HITSP covered this space and created C26 - Nonrepudiation of Origin

Note, the technology is easy; the hard part is getting over the administrative costs, infrastructure, and processes that are necessary to support Digital Signatures. In order to have digital signatures of any value one must have a strong certificate management infrastructure in place. One that issues Certificates to individuals, who are very careful with them. Certificate management infrastructure that can hold certificates for 100 years. This is expensive. This is the reason why few actually roll out Digital Signatures, and this is why IHE has not seen enough adoption of DSG to move it to final text.

The other hidden complexity is timestamps, one must be able to trust the timestamp inside a digital signature. This is not the same thing as having synchronized time. This has to do with protections against malicious 'back dating' of signatures. There are technology solutions, usually implemented as a timestamp-service. This timestamp-service does nothing but apply a Digital-Signature of it's own. By agreement everyone trusts the timestamp applied by the timestamp-service. More technology, more certificate management and more trust.

I'm not going to be at the Face-to-Face, so let me know how it goes.

From: S&I Framework Admin [mailto:admin@siframework.org]
Sent: Friday, September 30, 2011 4:18 PM
Cc: Mohammed.Elias1@cms.hhs.gov; melanie.combs-dyer@cms.hhs.gov; Mera.Choi@hhs.gov
Subject: Announcing a New S&I Initiative: esMD Call for Participation Current S&I Framework Members,
ONC is pleased to announce the launch of a new S&I Framework Initiative – Electronic Submission of Medical Documentation (esMD).

You are invited to attend the esMD KickOff Meeting and subsequent discussions at the S&I Face to Face on Oct 18-19. The esMD initiative will require inputs from several other S&I Initiatives, such as Provider Directories and TOC/CDA, so we encourage and request your participation and input to this important initiative. For those of you who have not yet registered for the F2F Meeting, you can do so on this link: http://wiki.siframework.org/October+F2F+Meeting
Note: Registration for the Face to Face meeting has been extended through Oct 7th. The Hyatt has also extended their discounted hotel room rates through Oct 7th.
The Kick-off call for the esMD Initiative will occur October 18, 2011 at 9:30am EDT. Please stay tuned for additional agenda details for the esMD sessions on Oct 18-19th, or monitor the esMD wikispace for updates: http://wiki.siframework.org/esMD+Workgroup. On this page, you can also sign up as a Committed Member or Other Interested Party for the esMD Initiative.

Please note the attached esMD DRAFT charter. Below is a summary of the Initiative and expected Use Cases.

esMD Initiative: The Electronic Submission of Medical Documentation (esMD) pilot intends to give providers a new mechanism for submitting medical documentation to Medicare Review Contractors. The S&I Framework esMD Initiative will focus on Interoperability and Nationwide Standards needed to support esMD requirements. The objective for the initiative is to setup workgroups to develop the use cases listed below:
Use Case 1: Define technical issues and relevant standards associated with author level digital signatures and develop a list of recommended Standards and associated Reference Implementation Guide(s)
Use Case 2: Define Standards for Structured Data submission capability using esMD
Use Case 3: Define standards for electronic communication with Providers to request for Medical Documentation (Structured Outbound)
Based on current discussions among members of the HIT Standards Committee and feedback from members of the community, the following core outcomes have been identified for the esMD Initiative:
Identify gaps in CDA Structured Document to support Progress Notes and Orders, and other documents as required for Medicare Review and similar activities
Leverage work of Provider Directories, Certificate Interoperability, Transitions of Care, and Data Segmentation Initiatives as they apply to esMD
Define technical issues and relevant standards associated with Author Level Digital Signatures
Identify and address business process and infrastructure issues associated with Author Level Digital Signatures
Identify and forward policy issues, if any, to appropriate policy bodies
Develop a list of recommended Standards, potentially including new work by SDOs, to be incorporated in a Reference Implementation for esMD
Thank you,Melanie Combs-Dyer, esMD Initiative Coordinator;Mohammad ‘Sam’ Elias, esMD Project Manager;and the S&I Framework Support Team

Securing RESTful services

2011-09-29T08:17:00.000-05:00

What is meant by RESTful? Ok, that is an old one; given that there is no such standard as REST. My understanding, RESTful is simply the philosophy of using HTTP built in command set PUT/GET/POST/DELETE (aka Create, Read, Update, Delete – or by others RLUS - Read, Locate, and Update Service). Thus the transport, encoding and command set are fixed. The theory is that you as a programmer then just focus on the special encoding above this command set, for example what is your query parameters and what is the result to look like. Thus freeing you from worrying about transport or command set, and ... security.

As far as securing RESTful services; IHE-ATNA already says how to do that – Mutually Authenticated TLS. I talk at length about this in Securing mHealth - the role of IHE profiles, specifically about the operational reality of using ATNA. IHE ATNA takes care of many risks, and does provide system authentication. Sometimes knowing the requesting system, is enough to know that you can trust that system would only ask for information that it knows the user is authorized to get. Surely using ATNA the service can trust that the client will include the user and purpose in the audit message recorded at the client side, because ATNA requires security audit logging.

What I want to address is deeper than simple HTTPS -- or even full Mutually-Authenticated-TLS. I want to address user and patient based access controls to very sensitive health information. Today RESTful is used mostly to access non-sensitive information. It might be important information, or simply might be maps, earthquakes, weather, etc. Most uses of RESTful are not trying to access as sensitive of information as healthcare information, certainly not information that can have privacy policies (Consents) that rule so finely over the data. Many are asking for RESTful to be used to access fully identified clinical information, and some are even asking that it be used to create or change this clinical information - such as the IHE Profile Proposal for a RESTful interface to XDS. These are the issues that I am trying to figure out how to equally secure RESTful vs SOAP.

In SOAP we have well defined ways to communicate the security context. IHE profiled the use of SAML assertion (XUA): who the user is, what their roles are, what they intend to use the data for, and any authorizations they hold. I cover this in the Bloginar on XUA. With SOAP based web-services this all comes along in the security layer built into SOAP, the WS-Security layer. RESTful doesn't have this layer, or at least not this well defined.

As to providing user identity, there is some hope, but no clear hope. Yes there is a Kerberos for HTTP (documented in EUA). Kerberos has issues when being used beyond a constrained environment, so it is not as suitable for HIE use.

Yes you can use SAML over HTTP. This is not documented in IHE as it is not implemented consistently in toolkits --- but this is used today for browser interactions. For example inside of GE all user authentication uses SAML identities mostly through the SAML "Browser SSO Profile", thus making it easy to work with external parties such as travel reservations. This method doesn't work great for a system-to-system API. The good news here is that the OASIS committee that handles SAML is working on this very problem now.

Most RESTful people want to use OpenID now days; which is a good choice for last-mile API; It just doesn't support the necessary user context attributes (role, purpose of use, authentication type) that access to sensitive information really needs. For this the OpenID community adds OAuth, which is fast developing but not mature. OAuth 2.0 looks really good in this camp.

The worst choice for user identity is to use an inline HTML form. This might work for interacting with a human, but as a programming interface it is very hard to work with. This solution locks you into one method of authentication, and one centrally managed user database. Thus proliferating the post-it note problem.

I hope to uncover the 'right' way to specify a RESTful service API for accessing highly sensitive healthcare information. I am not sure I can provide as good a security layer as is provided today with SOAP, but I am hopeful and open to suggestion. IHE will try to figure out all the possibilities, and all the operational environments. Much of the documentation I find is specific to one platform or the other.

I suspect that we will use something like OpenID + OAuth on the RESTful side, use WS-Trust to convert these tokens in the proxy service, so that on the backend we can use SAML to interact with the XDS or XCA backbone. I think this is a reasonable solution. I do expect that a RESTful API will be deployed for a specific use. It might be for the use by a large healthcare organization, or by a PHR vendor, or by a HIE; but the point is that this is an API into XDS/XCA that is hosted for a very specific purpose. Thus the very specirfic purpose can scope the security context well enough to make it easy on the Browser side, while satisfying the needs on the backend.

We could ignore the problem, but then what would "App" developers do? Guess at what they need to have implemented? Even a bad single choice is better than no choice. Even if we tell the App developers to include HTTP Basic Authentication, we will be sure that they can at least do that. Thus only hoping that they have thought beyond the minimal necessary to be compliant with the profile.

Please help. Please provide your choice. Please provide your environmental problem. The more information we have at the start, the better choices can be made.

Document Encryption

2011-09-26T18:32:00.000-05:00

IHE has a new supplement “Document Encryption (DEN)” out for Trial Implementation that explores all the possible ways that encryption could be applied to Documents. This supplement went to great extents to define a large set of different use-cases, each with their own concerns regarding protecting documents. As such it also explored all the existing profiles capabilities to meet these use-cases, and thus identified a few gaps.

The following is a table (Table Q-2. Use cases for existing and new IHE profiles with encryption) found in the supplement (reformatted slightly to fit in the blog). For details on each of the use-cases, please see the document. In this table each use-case is shown in a row, and each solution from IHE is available in a column. Where the profile is designed to directly address the use-case an “X” appears, where the solution partially supports the use-case a “(x)” appears.

Use case	new Doc Enc	new XDM Media Enc optn	ATNA (TLS)	ATNA (WS-Sec)	XDM Email optn	PDI optn(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)
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

As such there are some use-cases that are not really fully satisfied by the existing profiles, so the supplement goes on to define how to (a) Encrypt an XDM media, and (b) Encrypt a Document alone independent of any transport.

As such it comes up with a nice table that explains when one of the IHE Profiled solutions is most useful. The following is Table Q-1, IHE Encryption Solution Overview

Profile	When to use?
IHE ATNA (point-to-point using TLS)	· environment uses networking transactions (e.g., XDS/XDR); or · to be protected data concerns (representation of) XDS/XDR transactions and packages; and · confidentiality need applies between internet hosts (point-to-point)
IHE ATNA (end-to-end using WS-Security)	· environment uses web-services (SOAP); and · to be protected data concerns (representation of) transactions and packages (e.g., XDS/XDR); and · (partial) confidentiality need applies to intermediaries between end-points (end-to-end); and · where encryption between hosts is not sufficient
IHE XDM Email Option (using S/MIME)	· environment uses XDM with exchanges based on Email (SMTP); and · to be protected data concerns (representation of) XDM media content; and · confidentiality need extends from the sender up to the final recipient’s Email system (end-to-end)
IHE Document Encryption	· environment uses any means for data exchange, in particular non-XD* means; or · to be protected data concerns (representation of) arbitrary data (documents), in particular non-XD* packages; or · confidentiality need applies between arbitrary end-points (end-to-end), in particular where intermediaries or unanticipated workflows are involved
IHE XDM Media Encryption option	· environment uses XDM; and · to be protected data concerns (representation of) XDM media content (content and metadata) on physical media; and · confidentiality need matches path from creator to receiver (importer) of media
IHE PDI privacy option (using CMS)	· environment uses PDI; and · to be protected data concerns (representation of) DICOM data on media; and · confidentiality need matches path from creator to receiver (importer) of media

Implementing the Document Encryption (DEN) profile should be very easy, as the profile is leveraging a commonly implemented standard. The standard used by the DEN profile is the same standard that the IETF profiled for use by e-Mail uses for S/MIME. The DEN profile clearly is not S/MIME, but rather a more general purpose use of this underlying standard.

To help the implementer, there is a page on the IHE wiki that points to toolkits and implementation notes. On this page an implementer can find different solutions that they can simply leverage. There are examples of files that have been encrypted so that you can test that your system can decrypt them. There is very little need to implement the details when there are so many current implementations available.

IHE expects that when others implement this profile, that they can use this information. As a wiki, the expectation is that as new information is discovered the community (that’s you) will update the page. Don’t wait for some ‘authority’ to fix something that is wrong on these wiki pages. Feel free to update them as necessary (common wiki behavior is expected).

Digital Identity for Medicare Beneficiaries

2011-09-26T08:46:00.002-05:00

Last week a bipartisan coalition of lawmakers introduced legislation that would bring digital identities to Medicare patients. This is fantastic news, and a logical extension of the VA and DoD use of their Common Access Card (CAC). This will bring another very large chunk of the population supporting one standard for Digital Identity. Those against a common identity for all patients will surely have something to say about this, but from what I have read it has broad support today.

A huge administrative burden in healthcare today, especially as we try to link all our data between all the places we have ever been treated, is the identity of the patient. Due to the very old forbiddance to fund any national patient identity, we continue to push all kinds of other demographics into ONE SYSTEM under the hope that system can link all the various identities into one. Sometimes it works, sometimes it fails. Failing to find all the places is one form of failure, usually resulting in some data not being used when it could have been. This failure is not very critical today since before HIE or NwHIN there was no sharing, so some linking is better than none.

The failure that results in linking more than your data is the one that causes worry, that is you might be treated differently than you should because data from someone else was reported as yours. If this other data is simply displayed to the clinician, they typically will catch the mistake. But we are trying to get Clinical Decision Support to automate the data analysis; thus there is little chance to detect this failure.

So I am excited that this is being done, and I like their approach

The legislation would require a two-step plan to develop and implement the program.

Under the first phase of the plan, the HHS secretary would set up a smartcard pilot program in specific regions to boost the quality of care and the accuracy of Medicare billing, and reduce the likelihood of identity theft and waste, fraud and abuse.

Under the second phase, officials would consider the viability of expanding the program and implementing the smartcard technology nationwide (KTVZ, 9/14). If successful, the legislation would authorize the distribution of these smartcards to all Medicare beneficiaries.

I know that some will be worried about the implications of a unified identity, but the alternative is clearly not safe or efficient. As someone who worries about Privacy and Security, the current solution is very scary. It is a huge database of highly identifiable data, some of it valuable to financial fraud others to healthcare fraud. I don’t believe that these databases are not being secured, but we do know that risk is never zero. A huge database like we are forced to build, because we are forbidden to have a common healthcare identity, is a very interesting target to those that could benefit from it.

Having a standard healthcare identity card allows all healthcare treating facilities to focus on one system, one identity. Thus there is not wasted time and effort in designing all kinds of user interfaces and system interfaces to read various identity cards - something we expect humans to do. There would also be less wasted design and implementation time put into interfacing with HIE or NwHIN.

In all cases today this is simply overhead that adds cost to healthcare. There is very little benefit to having thousands of identities independently at thousands of facilities. Let’s identify the perceived benefit and figure out if there is a different way to satisfy that benefit.

ONC Call for Participation - Data Segmentation

2011-09-23T16:19:00.002-05:00

This call went out publicly on Monday (see below) and I was already pre-signed up. I have been involved with this topic for many years. I am disappointed that the introduction to this topic treats it as a ‘persistent privacy issue’. Although it does seem to be a persistent privacy issue, the persistent aspect has more to do with unwillingness than a lack of ability to provide consumer controls. I will totally agree that the security community, including myself, don’t do enough to explain how to do this.

I have blogged on the topic in the past many times. At first the “Data Segmentation” phrase threw me off. This is a term that security community uses to describe something different. Data Segmentation is the process of carving out extremely sensitive information and keeping it physically isolated from common data. I thus wrote: Data Classification - a key vector enabling rich Security and Privacy controls. This did quite a bit of good to help the community understand “Data Classification”, and has resulted in a new understanding of ‘confidentialityCode’. Proposal for confidentialityCode vocabulary

This is only one of the problems that is included in the topic of “Data Segmentation”, embedded inside is the issue of how a patient can express their privacy policy or constraints; and how that can be enforced. To me this is a very different problem, and would never be seen by a security professional as related to “Data Segmentation”. This is not to say that Security doesn’t have a solution. It is just known as Privacy Policy. In fact the solution to this need has very little to do with the Data. I have tried to express multiple times that Privacy Policy otherwise known as Constraints are not ‘metadata’. Could an architecture consider them metadata, sure it could but it would result in a fragile and non-scalable solution. One Metadata Model - Many Deployment Architectures, Data Objects and the Policies that Control them, ConfidentialityCode can't carry Obligations

Capturing the Privacy Policy (aka Consent, Obligations, Constraints), how to encode it, communicate it, and manage it in a way that holds up to legal challenges. We have some Stepping stones for Privacy Consent, while still developing advanced consents. IHE - Privacy and Security Profiles - Basic Patient Privacy Consents, Consent Management using HITSP TP30, The meaning of Opt-Out, Opt-In, Opt-Out.... Don't publish THAT!, Consent standards are not just for consent, Consumer Preferences and the Consumer, and RHIO: 100,000 Give Consent.

We even have some actual work done by some Health Information Exchanges - Draft Affinity Domain Policies

I look forward to helping the community understand. I commit to doing a better job of explaining how this is done in a standards based way that is robust, can be implemented in multiple deployment architectures, and is scalable.

From: S&I Framework Admin [mailto:admin@siframework.org]
Sent: Monday, September 19, 2011 12:52 PM
To: undisclosed-recipients
Subject: Call for Participation - Data Segmentation

Call for Participation

Office of the National Coordinator for Health Information Technology (ONC)

Data Segmentation Initiative

The Office of the National Coordinator for Health Information Technology (ONC) Offices of the Chief Privacy Officer and Standards and Interoperability are launching an initiative to address standards for the ability to exchange parts of a medical record (often called data segmentation).

As announced by ONC in a recent post to the Health IT Buzz Blog:

“This project aims to make progress on the persistent privacy issues raised in the PCAST report. The goal of this project is to enable the implementation and management of health information disclosure policies originating from a patient’s request, statutory and regulatory authority or organizational disclosure requirements.

The project aims to examine and evaluate the standards needed for sharing individually identifiable health information (including standards recommended by the Health IT Standards Committee through the use of metadata tagging of privacy attributes in standard clinical and policy records and record segments). The initiative will develop use cases that define the current need for data protection services, such as a patient’s directive not to disclose substance abuse records in accordance with 42 CFR Part 2, and will then extend current standards-based software models to demonstrate interoperability. Testing will be based on a reference model aligned with a set of use cases and functional requirements developed by the S&I community.”

Dr. Farzad Mostashari, National Coordinator for Health Information Technology

On behalf of ONC, I am pleased to announce and invite your valued participation in the launch of the Data Segmentation Initiative. This initiative takes place under the auspices of the ONC Standards & Interoperability Framework in conjunction with the Office of the Chief Privacy Officer.

Meeting logistics and reference materials are posted on the ONC Data Segmentation wiki page: http://wiki.siframework.org/Data+Segmentation

If you would like to volunteer to participate in the Data Segmentation Initiative, please review the documentation on the S&I Framework wiki: http://wiki.siframework.org/Getting+Started+as+a+Volunteer. Once you have read through the material regarding participation, levels of commitment, guidelines for participation and voting rights, please sign up to participate in the Data Segmentation Initiative by completing the registration form at: http://wiki.siframework.org/Data+Segmentation+Sign+Up

The official launch of the Data Segmentation Initiative will be held on October 5th from 1:00 – 2:30 pm EST with opening remarks from myself and Dr. Doug Fridsma (Director of the Office of Standards and Interoperability), a brief overview by Johnathan Coleman (Data Segmentation Initiative Coordinator), and a presentation by Melissa M. Goldstein, JD on the Whitepaper released by ONC in September 2010 entitled, “Data Segmentation in Electronic Health Information Exchange: Policy Considerations and Analysis,” available at: http://healthit.hhs.gov/portal/server.pt/community/healthit_hhs_gov__privacy_and_security/1147. Details on the Data Segmentation launch including web meeting access and call in information are posted on the wiki: http://wiki.siframework.org/Data+Segmentation . In addition, we will host Data Segmentation breakout sessions at the S&I Framework Face-to-Face Meeting, October 18-19, 2011 at the Hyatt Regency-Crystal City in Arlington, Virginia.

Your perspectives, expertise and experiences are critical to the success of this initiative and we look forward to your participation on the Data Segmentation Initiative.

Joy Pritts, JD
Chief Privacy Officer
Office of the National Coordinator for Health IT

Securing mHealth - the role of IHE profiles

2011-09-23T08:58:00.000-05:00

I was notified and volun-told by Keith a few hours before he submitted his new Profile Proposal "IHE XDS for mHealth access to HIE". He and I have been bumped around constantly by mostly invisible forces pushing for both RESTful interfaces and more simple ways to access XDS (and XCA). So this profile proposal is born out of that abuse. Therefore it is really not fully developed yet, although it is more fully developed than any of the other profile proposals put before the IHE ITI committee this week.

Securing mHealth is not easy, there are so many risks that arise when one goes onto an inherently portable device. So, very quickly there are questions about how IHE will specify the "Security Considerations" of this profile that Keith presents.

Of course I will first point very quickly to the IHE process for determining exactly this, Cookbook for Security Considerations. This process has been discussed on my blog multiple times - There is No Security Pixie Dust - it is Risk based and thus very powerful, flexible, and scale-able. This process gets the profile writers to think through security/privacy risks and place reasonable requirements into the profile. The result is typically a few recommendations to include 'capabilities' such as the IHE ATNA profile.

When I mentioned this to Keith, he quickly pushed back and asked why simply HTTPS couldn't be used. I pointed out that HTTPS is HTTP over TLS, just like IHE ATNA says. Turns out he was worried about the "Mutual Authentication" aspect of IHE ATNA. It was at this point that I understood that Keith had fallen into a trap that many people fall into, and to see someone like Keith do it is to recognize that it is a huge and inviting trap.

When the IHE ATNA profile indicates that a product must be capable of using Mutually-Authenticated-TLS, we are indicting a capability. We are not indicating an operational reality. So, if a hospital chooses to use an application that uses the new "mHealth access to XDS" profile; they will do a risk assessment of their operational environment and they will determine what parts of IHE ATNA they want to use, and what parts they don't want to use. So if they determine that they have good control over their mobile devices (how, I don't know, but lets imagine for now), then they can choose to not to use the client side authentication portion of IHE ATNA. It is their choice, and this choice is enabled by the capability built into the IHE ATNA profile that is mandated be grouped with the Profile. The alternative is that the new profile doesn't say anything about security considerations, and the application developer doesn't implement any security, then the operational environment has no capabilities to attempt to use.

We could hope that the application developer thinks about security, but then what security do they include that they are sure the service will also include? Lets say that the application developer chooses to use S-HTTP, while the service provider chooses HTTPS; this results in an interoperability FAIL (Yes, I know this is contrived, but I expect you can see the point where there are so many possible miss-matched choices that can be made). This is the exact reason why IHE exists, to scope interoperability problems into a single interoperable solution - profile. This is exactly what IHE ATNA is doing for secure communications. This does not mean that S-HTTP is a bad idea, and there is nothing wrong with using S-HTTP. It simply means that no claims can be made about how that solution complies with IHE.

Another example is the Security Audit Logging that is part of IHE ATNA. Again, this is a capability not an operational mandate. If the local environment doesn't have an Audit Record Repository, then the capability is turned off. Hopefully it is simply redirected to a local file with appropriate filesize management.

All of this is simply Risk Assessment "flow down". Meaning that at each level of design one does a Risk Assessment, and manage the risks as best as they can at that level of design. Documenting your environmental assumptions, security capabilities, and residual risk. The next level of design will take prior design outputs as inputs to a Risk Assessment. This next level of design Risk Assessment will do what it can to address the risks, using the controls available to it. Eventually one gets to the operational environment where again the Risk Assessment takes as inputs all the outputs of prior Risk Assessments. This operational environment will use all the security capabilities available, possibly buying more controls, writing procedures, building walls, and eventually covering residual risk by Insurance. This is very much the model outlined by IEC 80001.

Conclusion
a) Profiles need to consider security, and make recommendations on security profiles to use and any unresolved security risks critical to be addressed in the product design.
b) Profiles are there to assure interoperability, this is true about the security profiles as well. The security profiles are there to assure that the security choices on either side of a transaction are interoperable.
c) The security profiles are not there to handle security completely, just interoperability. This is why user-identity assertions are included, but not the user interface used nor the access controls. The application design and operational environment deal with user interface and access controls in a functional way.
d) Profiles specify capabilities, not mandate that they are used in an operational environment. So IHE ATNA specifies that a product claiming IHE ATNA supports Mutually-Authenticated-TLS for all network traffic communicating protected data, but in an operational environment this might be used on no connections, some connections, or even downgraded to just server side authentication.
e) Risk Assessment at many levels assures that each level of design has done what it can to enable a secure operational use. Ultimately the operational environment risk assessment is responsible.

Preparing for IEC 80001 - Security

2011-09-19T15:49:00.000-05:00

On Wednesday I will be presenting the soon to be published Security Technical Report IEC 80001-2-2 "Guidance for the disclosure and communication of medical device security needs, risks and controls". There is an assumption that the audience has an understanding of the basics of IEC 80001-1 "Application of Risk Management for IT-Networks Incorporating Medical Devices". I have been involved in the creation of this set of specifications from the beginning and provided some background here on my blog. This is an open webinar put on by GE Healthcare.

When: Wednesday, September 21, 2011, 2:00pm-3:00pm, Eastern Time,
Where: At Your Desk!
Please scroll down to register for Session 1

Content Summary: IEC-80001 can seem like an overwhelming process. That is why GE Healthcare brings you this educational series.

This presentation is the first in a three-part series that will discuss the soon-to-be-released set of Technical Reports that support the IEC 80001-1 Application of Risk Management for IT-Networks Incorporating Medical Devices

Session 1 - Security. Technical Report for the disclosure and communication of medical device security needs, risks and controls
Session 2 - Wireless. Technical Report for Wireless Networks
Session 3 - Step-by-step Risk Management of Medical IT-Networks

This session will review the anticipated Technical Report "Technical Report for the disclosure and communication of medical device security needs, risks and controls" and provide an opportunity to ask questions. Further, this session will review an informative set of common security capabilities, review input for Medical Device Disclosure Statement, and review Disclosure Statement input for Hospital Risk Assessment.

Click HERE to Register

Problems with Registration? eMail ---> mark.grabowski@med.ge.com or call Mark Grabowski at 414.721 2805

Draft Affinity Domain Policies

2011-09-19T07:12:00.002-05:00

I was asked to comment on the Connecticut HIE Policies. This is a really great example of the administrative work that must be done before one can really be evaluating the security and privacy needs of an HIE. These policies were written using many ISO standards and the IHE Affinity Domain planning kit. Please go to the site as they have a beautiful breakdown of the various many policies that are needed. Many people don't believe me when I say that there are many layers of policy.

These are a really good example of how a HIO can take a look at what is out there and pull what they understand while doing what is necessary to get what they need done. One thing like this came up last week during the HL7 discussion on confidentialityCodes. Connecticut was confused by the vocabulary offered by HL7, and thus wrote their own vocabulary. They actually pulled more from ISO 13606, but didn't use that vocabulary either. We were lucky enough to be able to discuss this in detail last week. It is a good thing that HL7 will be revising their documentation and vocabulary so that we can have a vocabulary that could be understood beyond one HIE.

On behalf of the Health Information Technology Exchange of Connecticut (HITE-CT) Board of Directors, I am writing to inform you that HITE-CT is currently gathering public comment on the proposed policies for the implementation of a state-wide health information exchange.
The establishment of policies and procedures are a key component for an effective HIE and sets the boundaries for data sharing between the health information exchange and its participating partners. Additionally, the HITE-CT policies and procedures will contribute to the efficiency and effectiveness of the HITE-CT.
HITE-CT is currently gathering your input for the policies and procedures that will govern the practices for Connecticut’s Health Information Exchange. There are four separate opportunities for you to comment and we hope that you will make every effort to attend or submit your comments electronically on the Comments and Resolution Form located on the website.
These policies are now posted on the HITE-CT website and are available for public comment. The direct link to the Policies and Procedures page is http://1.usa.gov/hitectpolicies. The policies may also be accessed by going to the DPH website at www.ct.gov/dph under featured links: Health Information Technology Exchange of Connecticut”, then click on “Policies and Procedures” located on the left hand bar menu.
The schedule for attending a public meeting and submitting public comments on the Health Information Technology Exchange of Connecticut’s (HITE-CT) proposed policies is as follows:
September 20, 2011
8:30 AM – 10 AM
Legal & Policy Committee Meeting
BEST
(formerly known as DOIT)
101 East River Drive
East Hartford
September 22, 2011
1:00 PM – 3:00 PM
Technical Infrastructure Committee Meeting
BEST
101 East River Drive
East Hartford
October 4, 2011
8:30 AM – 10:00 AM
Legal & Policy Committee Meeting
BEST
101 East River Drive
East Hartford
October 17, 2011
4:30 PM – 6:30 PM
Board of Directors
BEST
101 East River Drive
East Hartford
Please Note: At the October 17, 2011 Board of Directors meeting a discussion and a vote to adopt the policies and procedures will take place.
We kindly ask that you distribute this information to anyone you think may be interested in commenting on the policies.

I would love to see more of this. It is always very important to see how a standard is understood or misunderstood so that we can make it better.

Standards work is motivating because it gets used and improves lives

2011-09-14T09:24:00.000-05:00

The presentation by Dan Pink on 'what really motivates us' was posted again to Google+ today. When people ask me why I participate in standards, I have always given the answer "because it is really cool to see what you do implemented and saving lives.". Dan provides me the background as to why this works.

This is exactly why I work on Standards in Healthcare. What I create is used by others, and my motivation is to see the change. To know that peoples lives are saved, made better, made less painful, made better. This is why I blog, this is why I am so passionate at educating and outreach. This is why I will help a competitor understand something. This is why I subject myself over and over again to help people 'not reinvent the wheel.'

This is also why it annoys me when the standards organization calls these 'products' and charges $$ to use them. I want my work to be used, more than I want to be paid to create the work.This is why I am more creative working for DICOM or IHE; and more satisfied when those works are used. I think HL7 should think about this, how much more creative could the HL7 standards be?

As Dan says in the presentation, in order to get to this state one must be paid enough money to get money off-the-table. This is why I unabashedly working for GE Healthcare, and I have no problem with the fact that an organization brings together people that create using one motivation, with people who do mechanical (manufacturing) work with a different motivation, to produce value. This is what a vendor does, put together the whole-package.

Yet I have the best of both worlds, as I get to see GE Healthcare create value and deploy it; but as a standards developer I also get the pleasure out of others using these same standards.

The open-source community is missing this whole-package, yes the creative part is free (somehow the participants have achieved the money off-the-table state); but there is no-one there to finish the job. Hence why open-source doesn't dominate as it should, if one looks only at the technology (the creative part). This is niche is being filled to some degree by enterprising organizations that take the free creative-part and do the rest. But they will never 'own' their own destiny.

September 20, 2011 8:30 AM – 10 AM	Legal & Policy Committee Meeting	BEST (formerly known as DOIT) 101 East River Drive East Hartford
September 22, 2011 1:00 PM – 3:00 PM	Technical Infrastructure Committee Meeting	BEST 101 East River Drive East Hartford
October 4, 2011 8:30 AM – 10:00 AM	Legal & Policy Committee Meeting	BEST 101 East River Drive East Hartford
October 17, 2011 4:30 PM – 6:30 PM	Board of Directors	BEST 101 East River Drive East Hartford