Handling the obligation to prohibit Re-disclosure

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

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

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

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

 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

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:

1. 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.
2. 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. 
3. 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.
4. 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.
5. 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.
6. 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

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

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

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