Pages

▼

Monday, December 31, 2012

Most Interesting Posts of 2012

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

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

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

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

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

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

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

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

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

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

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

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

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


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

Big year. I wish there had been more interest in 
But that is okay, I got these concepts baked into my chapter in the Book published on Healthcare Information Technology

No comments:

Sunday, December 30, 2012

IHE - Privacy and Security Profiles - Document Encryption

IHE Document Encryption supplement includes two more ways to encrypt documents. 
  • There is a method included for encrypting just a single Document that can be used to encrypt any document type, and thus be carried on any transport. This Encrypted Document can be carried using XDS/XCA/XDR/XDM, but may also be carried by any other means (e.g. HL7 MDM). 
  • The second method is applied to XDM physical media. With the XDM encrypted media the whole XDM content and structure is encapsulated in an encryption envelop thus fully enveloping all the content that would be transferred on USB-Memory, CD-ROM, or any other media type.
These new methods of encryption are complementary to IHE-ATNA, XDM e-mail, and IHE-Radiology PDI Privacy option. The additional new use-cases are
  • Media to media transfer
  • Patient carried media for medical records clerk import
  • Unanticipated work-flows where media is used without knowing where it might be needed
  • Clinical trial where transportation of the content may be by many different transport mechanisms over time
  • Multiple recipients of secure document
  • Sharing with receivers only partially known apriory, a group or a role
  • Encryption of some documents in a submission set
Encrypted Document Content
The Content Profile in the DEN supplement defines how to encrypt a Document in a way that is independent of transport. There are defined ways to handle the XDS metadata when XDS metadata is used.

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

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

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

XD* Metadata ramifications of Encrypted Document

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

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

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

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

Encrypted XDM Media

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



Encryption Key Management

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

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

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

Standards Used

  • Key Properties
    • Encryption at Document or Media (XDM)
    • Flexible Key Management (PKI, Shared-Key, Password)
    • Complementary with other (ATNA, XDM, and Document)
  • Standards
    • Cryptographic Message Syntax (CMS) [RFC5652]
    • MIME [RFC2045]
    • bulk encryption: AES 128, 196, 256 in CBC mode
    • digest: SHA256
    • signature: RSA
    • key encryption: RSA (certificate),AES (shared key),AES + PBKDF2 (password)
References
  • Status: Trial Implementation
  • IHE ITI Technical Framework
    • Vol 1: Section 32 – Document Encryption
    • Vol 3: Section 5.3 – Encrypted Document Content
  • Options added to other transactions
    • Vol 1: Section 16.2 - Add Encrypted XDM option
    • Vol 2b: Section 3.32 – Add encrypted XDM
No comments:

Friday, December 28, 2012

Help for your challenges with XDS-related Tech Framework documentation

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

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

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

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

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

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

Wednesday, December 26, 2012

Book published on Healthcare Information Technology

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

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

I am very pleased with my chapter in the HIT book, 31 pages. I cover quite a bit of ground on Privacy and Security related to EHR and HIE. Much of the material comes from my blog, but even that had to be rewritten to fit the editorial style of a book. The chapter covers everything from identity, identity proofing, access control, authentication, and role based access control. I cover the various perspectives one must take in healthcare to protect data appropriately; including the patient perspective, provider perspective, and organizational perspective. I cover this topic as an exercise in a local EHR, but also how this model needs to be extended across an HIE to continue to protect the sensitive healthcare information. This requires the expansion out into Metadata and Federated Identity. 

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

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

Friday, December 7, 2012

Enabling Security/Privacy on Modular EHR certification

ONC in the US issued a Request for Comments on potential Meaningful Use Stage 3 objectives, measures, and some certification criteria. The link to the RFC is: http://www.healthit.gov/sites/default/files/hitpc_stage3_rfc_final.pdf

Specifically to my attention is the question of Security and Privacy relative to the new MU2 method of Modular Certification. This 'problem' has been identified very well by Dixie Baker on the HIT blog

The biggest problem here is that there is no definition of what a Module is. Thus there are some Modules that are nothing but reporting packages that make output look pretty for printing, these kinds of Modules should not have the security imposed upon them but rather the ‘calling’ application should have already done all necessary security and privacy tasks. However many Modules are closer to a full functional specialty or departmental systems.

The solution is to have defined Modules, not a free-for-all. With defined Modules one can define the Interface between the modules. Thus defined 'standardized interfaces', that is interoperability. With the defined modules and the interfaces between the modules; then one can identify the appropriate place for security functionality and what security is needed on the interfaces. It is through this defined modules with standardized interfaces that is a precondition for having standardized security and privacy functionality including enforcement that span beyond the core certified EHR definition.

Note that MU2 already has an equivalent of this. The defined "Transports" are a exemplar of what I am talking about. The Transports include security built right in. This security is well defined and clear.

This is easy to do with some Modules, not so easy with others. But by starting with some easy Modules, such as departmental EHRs, we can narrow the gap. There are well defined standards interfaces, interoperability, between the main EHR and the departmental EHR.
  • Patient Identity -- IHE-PIX, IHE-PDQ, and IHE-PAM
  • Orders/Results -- IHE Radiology Scheduled Workflow, IHE-Laboratory Workflow, etc
  • Care coordination documentation -- HL7 v2 MDM, CDA, CCDA, IHE
  • etc...
And all of these are being transformed into RESTful services with HL7 FHIR; and available for cross-organization exchange through IHE XDS/XCA/XDR/XDM.

Once these interfaces are defined, one looks at the interface requirements. Sometimes the security need only be machine-to-machine (IHE-ATNA). But sometimes user identity is important (IHE-EUA, IHE-XUA, or IHE-IUA). A big advantage of having these modules well defined and interfaces well defined are that one can also look at deeper requirements like Encryption, Security Audit, Privacy Enforcement, Accounting of Disclosures, Amendments, and accessibility.


The problem that MU has with this is that I don’t think HHS/ONC/CMS want to get into the internal workings of a healthcare provider operation. Inside the healthcare provider operational IT is a mess. Most of the healthcare provider organizations that have complex internal operational IT, also have plenty of knowledge and power to change it themselves. Thus I don’t think there is really a desire in HHS to mess with the problem of internal organizational affairs. I also don’t think that the large organizations want HHS messing around in their internal affairs.

I think a logical move for MU3 is to head a little bit back toward MU1 method of modularity without going all the way back. Thus I think there is a need to have some defined types of specialty EHR that are required to meet all security/privacy requirements, and have defined interfaces. These defined types should be rather identifiable and their interactions also rather clear.
More
1 comment:

Wednesday, December 5, 2012

IHE ITI slate for 2013-2014 development

The IHE ITI Technical Committee met this week and accepted all received work items. We spent the majority of the time doing scope narrowing and shifting schedules. This because there is strong interest from many different stake holders, and we couldn't do all the work proposed. After much ‘constructive discussion’ we think we have a plan for how to make progress on all of the work items. This decision is a very hopeful decision given that last year we all got highly distracted by outside factors (e.g. Meaningful Use) and thus hardly delivered anything more than one profile (MHD).

The following is the output of the ITI Technical committee. The first three rows are to finish up last year’s white papers, which is viewed as top priority. The rest of the items are the new work proposals and thus the biggest amount of work. The creative scoping has trimmed most profiles from their original proposal. The creative scheduling has one being prepared before we even meet at the first face-to-face.



Findings Notification – this is a white paper that explores the use-cases of clinical findings notification. This paper is close to being made public.

Document Sharing Re-documentation – this is an effort to fix the Technical Framework Volume 3 where it describes the Document Sharing metadata (XDS, XCA, XDR, and XDM). IHE is trying to present the metadata model in a more comprehensive way that also sets up the various transport types, including MHD in the future.

De-Identification – this is a handbook that will assist IHE domain committees and others to assess any De-Identification needs and help build the appropriate algorithms for an analyzed use-case. This handbook will leverage pseudonym and anonymization mechanisms. This will be inclusive and in harmony with the latest guidance from both the UK and USA

Internet User Authentication – this profile proposal looks to fill the authentication gap that exists with the MHD profile, yet will produce a general purpose HTTP authentication for typical Mobile use-cases and RESTful. It likely will leverage oAuth 2.0, but the actual choice is a technical committee decision. This effort will look at existing efforts such as the USA RHEx effort.

Extend XDW to XCA – The XDW (Cross-Enterprise Document centric Workflow) profile was originally scoped to use with XDS. This profile proposal extends that to XCA environments. This recognizes that many cross-enterprise workflows will take place across the boundaries of XDS.

Care Service Discovery – This is likely to be an augmentation of HPD to support discoverability of clinical-services and possibly network-services to support those clinical services. It will likely also have a white paper that will explore how to leverage these and other IHE profiles to satisfy social use-cases.

IntendedRecipient and Folder subscription – This profile recognizes that the current Document Subscription (DSUB) profile is too constrained. This profile will bring in additional use-cases and thus subscription types. The prime use-cases are those where a system desires to simply subscribe for any document with a specific IntendedRecipient value; and where a system desires to subscribe for updates to an identified folder.

Pull-style Notification – this profile brings the use-case where a subscriber to a Document Subscription (DSUB) can’t support the current call-back pattern. This profile suggests that there be a way to queue up the notifications and have the subscriber poll for any outstanding notifications. This is a functionality that comes from our underlying WS-Notification and thus should be a very small supplement to add this new pattern.

What is Next?
The Technical Committee meeting now is scheduling sub-committee meetings to develop the materials, full committee meetings to review the materials, and will target the Face-to-Face meeting March 18-22 in Treviso, Italy.

No comments:

Tuesday, November 27, 2012

Effective (Cybersecurity) Regulations - focus on What, not How.

There is many indications that in the USA, President Obama, may promulgate an Executive Order on CyberSecurity. This executive order due to the lack of law maker movement on the same topic. There is a strong feeling that there is a needed to keep digital information and systems 'safe'.

White House moves on cybersecurity

I hope they learn from Healthcare. The focus on Privacy and the use of the Breach Notification system has had measurable effect. Clear requirements of ‘what’ to do, not ‘how’ to do it; with clear and executed ramifications for failure. It is amazing what a little ‘sunlight’ will do.

Largescale Health Data Breaches Declined in 2012 OCR Data Show

Healthcare used HIPAA and HITECH, two regulations that defined the outcome expected. As well as the OCR 'wall of shame' for breach notifications. These are good examples of regulating to the outcome, not the means. This is a general pattern not specific to healthcare or to security. But applicable to all things that can be regulated.

To be effective and to be long standing a law needs to be independent of technology. This is why I point out that the regulation should be about 'what' needs to be done, or what the good outcome should look like. When it is goal oriented a law/regulation can be met by an ever evolving set of technology and policy. Technology that can adjust with time to incorporate new technology and new policy as needed. 

When regulation over-extends and explains 'how' to achieve the solution, we end up with a law that will not be as effective and will not age well. It will not be as effective, as many will try to figure out how to get around the specifics. They have some reason to not agree with the 'how' indicated. This is often simply, Not-Invented-Here. A prescriptive regulation or law will also not be as effective as soon as the landscape changes. As the attackers learn new vulnerabilities  As technology changes. As new use-cases come about, such as mobile applications.

Regulate the 'what to do' or 'what is the result desired'. Don't regulate 'how to do it'.



No comments:

Monday, November 26, 2012

Guidance Regarding Methods for De-identification of Health Information

I have been working on De-Identification for many years, including being one of the major contributors to ISO 25237 on the subject, and DICOM Supplement 55 and 142. I think that the algorithm for De-Identification is rather simple, but it is contextual. Start with the presumption that you can't have ANY data, and provide your arguments for each and every attribute. Start with the most important attributes to your use-case, the context of the de-identification. If you want something that falls into the identity or close to identity space; then how badly can I mangle (actually well understood algorithms) the values before they become useless to you. When you take the attitude that you don't deserve any of the information you tend to end up with the minimal information that you need to fulfill your use-case.

I have placed these concepts into ISO and DICOM standards, IHE Handbooks, and my blog... But it is so much more powerful when a government says the same thing. It is not more powerful because they are so much smarter, but because by following their advice, even if it is the same advice, you get a 'pass'. One might say a 'get out of jail free' card. Which is a fallacy, but perception is as important as reality sometimes. This month both the USA and UK have released their advice on De-Identification. I haven't compared them, but will be doing that while harmonizing them into the IHE Handbook. I suspect that there is nothing truly new. I can say that my quick look indicates that they are truly useful. So although I might see these as purely politics, I do see that they have put very useful thought into their guidance.

The USA has provided us:
From: OCR HIPAA Privacy Rule information distribution [...] On Behalf Of OS OCR PrivacyList, OCR (HHS/OS)
Subject: Guidance Regarding Methods for De-identification of PHI in Accordance with HIPAA 
November 26, 2012
Today, OCR released guidance regarding methods for de-identification of protected health information in accordance with the HIPAA Privacy Rule. This guidance fulfills the American Recovery and Reinvestment Act of 2009 (ARRA) mandate that HHS issue such guidance. In response to this mandate, OCR collected research and views regarding de-identification approaches, best practices for implementation and management of the current de-identification standard and potential changes to address policy concerns. OCR solicited stakeholder input from experts with practical technical and policy experience to inform the creation of guidance materials by organizing an in-person workshop consisting of multiple panel sessions, each addressing a specific topic related to de-identification methodologies and policies. The workshop was open to the public and was held March 8-9, 2010 in Washington, DC. The guidance synthesizes these diverse perspectives. It can be found at http://www.hhs.gov/ocr/privacy/hipaa/understanding/coveredentities/De-identification/guidance.html.

The UK last week provided
News release: 20 November 2012
The Information Commissioner’s Office (ICO) has today published its data protection code of practice on managing the risks related to anonymisation. The code explains how to protect the privacy rights of individuals while providing rich sources of data. 
The code comes at a time when the UK is putting more and more anonymised data into the public domain, with the government’s open data agenda allowing us to find out more than ever about the performance of public services and holding public bodies to account.
Announcing the publication of today’s code of practice Christopher Graham, UK Information Commissioner, said:
  • “We have published our code of practice on managing the data protection risks related to anonymisation to provide a framework for practitioners to use when considering whether to produce anonymised information. The code also aims to bring a greater consistency of approach and to show what we expect of organisations using this data.
  • “Failure to anonymise personal data correctly can result in enforcement action from the ICO. However we recognise that anonymised data can have important benefits, increasing the transparency of government and aiding the UK’s widely regarded research community.
  • “We hope today’s guidance helps practitioners to protect privacy and enable the use of data in exciting and innovative ways. We would also like to thank those people who took part in our recent consultation and helped today’s code of practice become a reality.”
The ICO has also announced that a consortium led by the University of Manchester, with the University of Southampton, Office for National Statistics and the government’s new Open Data Institute (ODI), will run a new UK Anonymisation Network (UKAN). The Network will receive £15,000 worth of funding from the ICO over the next two years to enable sharing of good practice related to anonymisation, across the public and private sector. The network will include a website, case studies, clinics and seminars. 
Today’s code contains a framework to enable practitioners to assess the risks of anonymisation related to data protection and identification of individuals. It also includes examples of how successful anonymisation can be achieved. This includes an explanation of how personal data can be anonymised for medical research purposes, how individuals’ information can be anonymised when responding to Freedom of Information requests, and how customers’ data can be anonymised to help market researchers analyse people’s purchasing habits.
Download the new data protection code of practice Read our anonymisation topic guide

See also:
No comments:

Thursday, November 22, 2012

Thankful and Hopeful for Healthcare progress

There is so many good things that happen when data is allowed to move. I have dedicated my career to enabling healthcare data to move when appropriate. I follow the guiding principles of Privacy (OECD, USA, EU, Safe Harbor, Privacy by Design) . These are expressed in multiple forms but generally all well align. The appropriate movement of healthcare data can enable so many wonderful things to happen, things well beyond our wildest dreams today. This is what drives me, this is my mission.

I am Thankful for some efforts that I was a part of this year. I can’t say that they all turned out exactly as I wished, but they did meet my overall mission, to get data moving when authorized.
  • Healthcare around the globe is aligning on standards based Document centric Transports with reasonable security models. In the USA this is being pushed by Meaningful Use. Document centric transport is not the ultimate goal, but it is an example of ‘good enough’. I think it is very much the sweet spot between many forces: Privacy, Clinical Accuracy, Provenance, and Medical Records. Advanced security and privacy are being worked on using realistic use-cases and mostly a realistic viewpoint on timeline. In the USA this is being pushed by the Data Segmentation for Privacy. It is unfortunate that much re-invention is happening, but sometimes one must allow others to do this.
  • Security/Privacy Audit logging is making progress and visibility but still not a forefront item, it likely never will as it isn’t sexy and can only show bad things have happened. But this year we saw enhancements in this space. We are nowhere near good-enough. A privacy office still must do so much work to pull together a simple accounting of disclosures. If it is hard to do this on-demand, I am sure there is not daily reviews of the audit logs.
  • Patient access and correction are starting to make progress. I am not one that says that there should be some patient centric database in the cloud. I am however one that indicates that we must enable patients to have access to their data. Access and manipulation of data, my mission, is not going to be the dominated by professionals as it has in the past. Once the patient gains access to their data they can do wonderful things with it as well. Along these lines I am excited about RESTful interfaces for healthcare. Not just willy-nilly RESTful interfaces, but reasoned interfaces that are purpose driven and harmonized with backend and more mature infrastructures. REST is not a magic thing, it is one of the appropriate tools to use. Fitting that tool in with the others is just as important as using it.
The Patient is being recognized as having Privacy rights. Privacy rights not only allow a patient to control their data, and to understand how their data is used; but it also enables them to access their data and get it corrected when it is wrong. These are fundamental Privacy Principles; it is quite exciting to see them all progressing. Getting the data to move is what is important, the creative ways to add value through access to the data is what will revolutionize healthcare.

I will continue to work on my mission. There is still technology that is needed, I just think that we have good technology today. What we don’t have is the political and organizational will to leverage it.

With the continued Obama Administration I am Hopeful for some key Political movements in Healthcare
  • User Identity needs to be fixed. This is not a technical problem, we have the technical standards. This is a political problem. We have hundreds of individual user accounts because all services historically had to do this, and none of them would trust anyone else. We need a system where by the user chooses when to have a different account, and when to leverage one they already have. In the USA NSTIC is working on user identity in the internet space. This will not address organizational users, specifically how one organization needs/should trust the users in another organization. Federation technology is clear and easy. We need movement, it is great to see Google, Facebook, Twitter, and others leveraging these technologies and making them available. The business of identity-providers will be a tough business to be in over the next 5 years. But we will all be better off.
  • Patients need an identity, not this mess which is cross referencing. Cross-referencing will work, but is the worst of all possibilities. Cross-Referencing will make mistakes, a mistake in healthcare at best is a privacy violation at worse a leads to a treatment error. Cross-Referencing exposes MORE of the patient identity to more organizations and thus more potential misuse. This problem is being addressed more outside the USA. I am excited at what is going on in Europe and beyond. The USA must reexamine the historic attitude on a patient identity, and examine the problem in context of today and the future.
  • Privacy enhancement through simplification and unification. This too is not a technical problem. We need in the USA to focus on having a unified privacy policy that is good-enough. The technology will continue to change, but it is very difficult to work on advances when the sands shift underfoot. We need simple patient choice to be put forward as good-enough. It is true that simple opt-in will not work for some, but they will work for most. Let’s get this system in place so that we can then focus attention on how to advance it. We don’t have a simple opt-in because we have multiple layers of conflicting privacy regulations. Privacy Principles give the patient choice, simple as that. I know some states want to use implicit consent, but it is time to reexamine this. There is plenty of proof that when patients are given choice, informed choice, that they choose to share.
  • Roll out of Exchange, and put to bed Direct. We need to get data available, not continue to do one-by-one interactions that somehow need to predict where the data needs to go. Direct is a great replacement of the FAX, it is not a good solution for anything else. I am glad that we have aligned on Documents, this was my goal when I conceded and helped create Direct. Document is the most important advancement. But we must encourage eHealth Exchange to make data universally available. This is far more important that being able to universally discover doctors. Movement of data is the key.
  • Please fix the Patent system. Patents are essential, but the use by trolls is clearly not what the Patent system was intended to enable. Our courts are spending far too much time determining if patents are valid or not. This is the job of the Patent Office, prior to issuing a stupid patent. The court system is a hugely expensive way to deal with this problem. Our courts should be doing what the courts were designed to do, things like prosecuting inappropriate violations and invasions of Privacy. 
Privacy does not get in the way of progress. When you ignore privacy, it will come back to hurt when consumers find out about the violation and invasion of their privacy. Design Privacy into your system from the start, and be transparent with consumers. Consumers will reward openness and transparency.

I have many articles on these topics
No comments:

Monday, November 19, 2012

IHE-IUA - Internet User Authentication for HTTP profiles

Profile Proposal for 2013 development in IHE ITI
This is a profile proposal that the IHE ITI committee will most likely take up in the 2013 timeframe. This is just a proposal so input is important as well as support from those interested and those with experience. Note I took liberties with the name, the author has called this "OAuth for HTTPS access". I simply think that this new title puts this new profile in the family of Enterprise User Authentication, and Cross-Enterprise User Assertion. Plus I don't like putting technologies into the title of a profile, actually don't like the solution to lead as the problem should be the point of the profile. This will next be discussed at the IHE ITI Technical Committee meeting in December at the Mitre offices in DC. The rest of this blog post is the  Detailed Profile Proposal unedited (note, I think OAuth 2.0 [RFC 6749]) is now released, See the IETF OAuth status page

Summary
The HTTP based transactions, like those in MHD, need authorization services as part of their security environment. OAuth and Kerberos are examples of such services. Kerberos is used within enterprise, but is not accepted for cross enterprise use. OAuth is being used and extended for such use.

The authorization process must allow a healthcare service provider to support multiple authorization services.

The customer/client/patient must be able to select a preferred authorization provider independently of their selection of a healthcare service provider. The authorization provider assures the healthcare service provider that the client software application is authorized to request and use the services of the healthcare service provider.

There is already a market for authorization services in the commercial environments on the Internet. Early versions of OAuth 1.x are in use by Google, LinkedIn, Facebook, and other well known providers. Experience with this has driven creation of a new version of the OAuth standard that can be profiled for different use environments. OAuth 2.0 is not complete in itself; it must be profiled to meet the needs of specific market segments.

IHE has the expertise in the needs of the healthcare market, and is structured to create profiles of existing standards. This should mesh well with the structure and methodology of the OAuth 2.0 standard. By using the same standards as the commercial sector, we increase the acceptance of the healthcare profiling by commercial authorization providers.

There are already prototyping efforts by ONC and others to develop implementations and confirm usability of OAuth in a healthcare setting. The regulatory and legal requirement for authorization services is clear. The market demand that authorization services be independent of healthcare provider services is also clear.

The Problem
HTTP-based transactions, like the RESTful transactions in the MHD Profile, lack a standard authentication and authorization mechanism. Many RESTful activities have no need for such mechanisms. The RESTful activities used in MHD and other profiles take place in a healthcare environments, and an authorization mechanism is needed for some kinds of healthcare access.

An authorization mechanism is needed for MHD for patient access by tablets and smartphones, and in expected uses for provider access by tablets and smartphones. Smart devices, such as blood pressure monitors, delivering their results to providers need authorization mechanisms.

Providing an authorization mechanism as a profile that can be grouped with MHD and other RESTful profiles will enable their use in the anticipated deployment environments.

Target EnvironmentThe devices are restricted in function and capability, typically tablet and smartphone devices. Their network and storage capabilities are constrained to those provided as part of the device environment.
  • Ownership and control varies, the device may be
    • Patient owned and controlled.
    • Provider owned and controlled.
    • Third party owned and controlled.
    • Combinations of ownership and control.
  • The authorization service must be usable over HTTPS. It is assumed that TLS will be available and used to protect and authenticate the communications. (Bi-directional authentication may be an issue. This needs to be resolved.)
  • Use over HTTP is desirable, but the lack of protection within HTTP means that it would only be acceptable in controlled environments. Use within a single facility over protected networks like VLANs is an example of appropriate use.
  • Only HTTP headers can be extended and used. It is too difficult to modify some of these devices to use completely new protocol stacks.
There will be multiple authentication and authorization servers in the environment. It is expected that a provider will negotiate with and accept at least several different authentication servers for use with that provider. It is expected that the person or organization controlling a device will select one of those authentication servers.
The authentication server and authorization servers may be provided by the healthcare provider or may be an independent third party. The system chosen must accommodate reasonable combinations of these.
The devices may have multiple applications and may chose to use different authorization servers for different purposes.

Use Cases
The following five use cases will be considered initially for profile purposes. This is not an exhaustive list and one of the early tasks of this project will be re-examination of the use cases to combine those that are duplicative and add those that are considered appropriate. (Appropriate additions will motivate and explain additional requirements on the protocol beyond those already driven by these use cases. There are far too many different potential use cases to accept any further use cases unless they reveal new requirements for authorization services.)

  • A patient with a mobile device wishes to retrieve a medical document to which they have authorized access. 
  • A provider with a mobile device wishes to retrieve a medical document to which they have authorized access.
  • A patient with a mobile device wishes to provide a new medical document to their provider.
  • A provider with a mobile device wishes to add a new medical document to a patient record.
  • A smart device wishes to add a new medical document (containing a device report) to a patient record.
All of these need authorization steps, and the authorization transactions follow the same pattern. The use cases may differ in terms of details about the individual transactions, etc. The use cases also are likely to have different threat environments that need to be analyzed.

All of the existing standards follow a very similar transaction pattern. The diagram below uses the terms from the OAuth standard, but the other standards fit this diagram with only the names of the transactions and actors changed.



The Client will make a request of the Authorization Server. There is may be other HTTP traffic involved as part of the authorization process. This traffic might not be specified in detail by the authorization profile because they are provider specific. The result is an authorization response providing a ticket of some sort that can then be used in communications with the Service Provider.

The client will use that ticket, and perhaps other related information, in the HTTP request headers to inform the Service Provider that it is authorized to make this transaction.

Standards & Systems
The most likely candidate standard is OAuth 2.0 http://datatracker.ietf.org/wg/oauth.

Other standards candidates exist, but none of these has gathered significant acceptance in the cross enterprise environment:
  • HTTP Kerberos, which has moderate acceptance within enterprise but none across enterprises http://datatracker.ietf.org/wg/krb-wg.
  • HTTP LDAP authentication
  • HTTP Password
  • HTTP SAML
  • Other developing standards (To be explored)
  • Proprietary systems
The OAuth 2.0 standard is a framework that is not in itself complete. It is expected to be profiled to meet particular use case needs.
Technical Approach
All of the candidate standards take a similar approach. They match the transaction flow shown above. The ITI effort will not invent new methods. It will profile an existing standard for authorization. We do not expect widespread acceptance if we invent a new method.

New actors
  • HTTP Authorization Client – the client device
  • HTTP Authorization Server – the system providing authorization services
  • HTTP Server – the system providing the HTTP service.
Existing actors
These new clients will group with existing and other new actors. For MHD, it is expect that the HTTP Authorization Client would be grouped with Document Source and Document Consumer. The HTTP Server would be grouped with the Document Recipient and Document Responder.

(It may be that after review we will decide to use options rather than grouping to accomplish this function. For now, we will proceed assuming that the grouping function will be used to document the behavior.)

New transactions (standards used)
The two new transaction will be:
  • Authorization Request. This is likely to be an OAuth authorization request. It is between the client and the authorization server.
  • Authorization Service Ticket: This is likely to be modifications to the HTTP headers in a RESTful transaction. 
In the case of MHD, it would be modifications to the HTTP headers in the Put Document Dossier [ITI-65], Get Document Dossier [ITI-66], Find Document Dossiers [ITI-67] and Get Document [ITI-68] transactions.

Impact on existing integration profiles
HTTP based transactions like MHD may need to have options added so that implementations can indicate the ability to perform and use authorizations.

New integration profiles needed
A new profile will be created to describe the new actors that request, provide, and use authorization services, to describe the new authorization transaction, and to describe the HTTP header modifications needed to use the authorization results.

Breakdown of tasks that need to be accomplished
The major work items to be performed are:
  • Identify the threat environment models for the use cases. One important issue will be the extent to which we attempt to deal with the problem of hostile platforms. The likelihood that patient owned and controlled devices are penetrated by malware is high. There is a near certainty that at least some of the devices involved should be considered hostile platforms. OAuth 2.0 has a threat document that may contribute to this effort. http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel
  • Evaluate the available standards in terms of how well they protect against the expected threats.
  • Select a standard
  • Profile the standard for the expected threat environment and use cases
  • Clearly identify the limits of applicability for this profile. One of the greatest risks for security profiles is their use in environments where they do not provide adequate protection.
Risks
None of the long existing standards has reached widespread acceptance in the cross enterprise environment.

The OAuth standard is still in draft form. Publication as a draft standard is expected in mid 2013. The previous version of OAuth had a number of different problems, although these did not prevent adoption. They did result in different vendors making choices that substantially reduced interoperability between different authorization servers. This made it difficult to support multiple authorization servers for a single service provider.

Working with a draft standard poses risks, but in this case also provides advantages. Since the intention is that the OAuth 2.0 be profiled, feedback from our profiling effort can be used to improve the OAuth 2.0 finished result.

We do not know whether the OAuth 2.0 approach will work and meet with widespread acceptance. The proposal is already the subject of considerable controversy.

There are other less mature standards development activities that claim to be addressing this same problem. They are all significantly behind the OAuth effort in terms of readiness.
3 comments:

Tuesday, November 13, 2012

IHE mHealth Hackathon

Updated: Official IHE announcement of the mHealth Hackathon

The Mobile access to Health Documents (MHD) profile offers access to the Document Sharing environment from platforms that prefer to use more simple interface technologies. The MHD profile takes the approach of REpresentational State Transfer (REST), a resource centric view; and leverages the technologies readily found on Mobile Devices (HTTP, Atom, JSON). This new interface to the Document Sharing environments is expected to extend the reach to devices and workflows. This new interface is not a replacement for XDS, XDR, or XCA; but rather provides a new programming interface to these Document Sharing infrastructures.

Mobile access to Health Documents (MHD) profile defines a simple HTTP interface to an XDS like environment. It defines transactions to a) submit a new document and metadata from the mobile device to a document receiver, b) get the metadata for an identified document, c) find document entries containing metadata based on query parameters, and d) retrieve a copy of a specific document. These transactions leverage the document content and format agnostic metadata concepts from XDS, but simplify them for access by constrained environments such as mobile devices. The MHD profile does not replace XDS. It can be used to allow mobile devices constrained access to an XDS health information exchange.

The Hackathon to be held at the IHE Connectathon on Wednesday afternoon and evening will provide the attendees insight into this profile and provide an opportunity to play around with it. The Hackathon will bring together implementers of the profile and those that might be interested in using it. The goal is twofold: First to provide a social environment to share experiences with implementations of the profile, and Second to help improve the profile. The profile use of languages that are implemented broadly in many devices and toolkits should offer a chance to develop rapid prototypes of applications. The goal of the rapid prototyping is to play around with the MHD profile interface. The environment will be an extension of the normal IHE Connectathon atmosphere to encourage creativity and problem solving.

Agenda:
  • Presentation of MHD profile goal and content.
  • Presentation of mobile authentication profile development in 2013 IHE ITI Planning for 2013
  • Presentation of a few implementations of the server side of this profile
  • Presentation of a few implementations of mobile applications?
  • Examination of HL7 FHIR advancement of the concept of MHD. 
  • Hacking: given the programming tools of today we expect to see some quick prototyping of applications that could go onto mobile devices and leverage the MHD profile.
  • Discussion and Summary
An Implementation Guide is being maintained at mHealth Dossier Guide. We expect to continue to share practices using this wiki, and will publish the results of the hackathon as appropriate.


Updated: Official IHE announcement of the mHealth Hackathon

3 comments:

Tuesday, November 6, 2012

IHE ITI Planning for 2013

The IHE ITI Planning Committee met last week and prioritized all received proposals. Given the number of proposals we recommend that all proposals be reviewed by the Technical Committee and, after assessment of work load and technical feasibility, our priority be considered when making your recommendation.

The following is the output of the ITI Planning committee. The right side shows the Ballot-based Ranking. This is the priority that the ITI Planning committee is asking the ITI Technical committee to view these work items as. The first three rows are already accepted work items, because these are work items from this year that simply need to be finished off.



The profile proposals and final spreadsheet from the meeting can be found on the Planning Committee folder for next year: ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr11-2013-2014/Planning_Cmte/

Findings Notification – this is a white paper that explores the use-cases of clinical findings notification. This paper is close to being made public.

Document Sharing Re-documentation – this is an effort to fix the Technical Framework Volume 3 where it describes the Document Sharing metadata (XDS, XCA, XDR, and XDM). IHE is trying to present the metadata model in a more comprehensive way that also sets up the various transport types, including MHD in the future.

De-Identification – this is a handbook that will assist IHE domain committees and others to assess any De-Identification needs and help build the appropriate algorithms for an analyzed use-case. This handbook will leverage pseudonym and anonymization mechanisms.

OAuth option for mHealth – this profile proposal looks to fill the authentication gap that exists with the MHD profile. It likely will leverage OAuth, but the actual choice is a technical committee decision. This effort will look at existing efforts such as the USA RHEx effort.

Extend XDW to XCA – The XDW (Cross-Enterprise Document centric Workflow) profile was originally scoped to use with XDS. This profile proposal extends that to XCA environments. This recognizes that many cross-enterprise workflows will take place across the boundaries of XDS.

eReferral Search Services – This profile brings forward some use-cases around the problem of discovering an appropriate place to send a patient for specific referral types. This is likely to be an augmentation of HPD to support discoverability of clinical-services and possibly network-services to support those clinical services.

Full metadata subscription – This profile recognizes that the current Document Subscription (DSUB) profile is too constrained. This profile will bring in additional use-cases and thus subscription types.

Pull-style Notification – this profile brings the use-case where a subscriber to a Document Subscription (DSUB) can’t support the current call-back pattern. This profile suggests that there be a way to queue up the notifications and have the subscriber poll for any outstanding notifications.

What is Next?
Note that the Technical Committee will now assess the technical feasibility of these proposals. Ultimately they will only accept 2 maybe 3 of the non-grey items. The committee really needs participation by those that will benefit from this profiling effort as well as those that have experience in these areas. IHE is a very open group.

Kudos

Kudos to Karen, who even though her house was hit by hurricane Sandy and without power or network and having her flight to Chicago canceled .. continued to chair the meeting from her car sitting outside a public Wi-Fi access point in her neighborhood. 
No comments:

Wednesday, October 31, 2012

Testing your ATNA Audit Log implementation

Updated August 2016 New test tools for ATNA Audit Log messages in Gazelle

I am asked often for examples of ATNA Audit Log messages. IHE has far better than simple examples of ATNA audit messages.

First this information is part of a fantastic set of tools and infrastructure that the Connectathon team puts together. Their announcement to those that have registered has fantastic information around ALL profiles and how to test, prepare for connectathon and make the most out of the experience. PLEASE start with this information as it is critical to set the framework and background.

IHE has created an ATNA test tools, both client and server. The test tool for testing an ATNA Secure Node, that would be sending ATNA audit log messages, will catch and validate the message. It has an interface that shows you the messages that you have sent.

Syslog Collector info page: http://ihewiki.wustl.edu/wiki/index.php/Syslog_Collector

If your product is an ATNA Audit Record Repository then you can use their test tool to send various audit log messages to you. It has a web interface where you pick the message that you want to receive. Easy as pie.
Syslog Sender info page: http://ihewiki.wustl.edu/wiki/index.php/Syslog_Sender

The syslog sender tool itself has a drop down list of audit messages it can send: http://gazelle-gold.wustl.edu/SyslogSender/Sender.jsf

The Syslog Collector currently has complete ATNA validations (using Schematron) for the following messages. Note this is just a list I copied today from the wiki, go there for more details. Double-NOTE that this even points you directly to where the specification is for that audit log message.
  • User Authenticated (Login) audit message ITI-2 (110123/1101140) TF-2a 3.2.6
  • User Authenticated (Logout) audit message ITI-2 (110123/1101140) TF-2a 3.2.6
  • Patient Identity Source Actor Audit Msg (Adm/Reg/Upd) (ITI-8/110110) TF-2a 3.8.5.1.1
  • PIX Manager or Document Registry Actor Audit Msg (Adm/Reg/Upt) (ITI-8/110110) TF-2a 3.8.5.1.2
  • Patient Identity Source Actor Audit Msg (Merge) (ITI-8/110110) TF-2a 3.8.5.2.1
  • PIX Manager or Document Registry Actor Audit Msg (Merge) (ITI-8/110110) TF-2a 3.8.5.2.2
  • PIX Consumer Audit Msg (ITI-9/110112) TF-2a 3.9.5.1.1
  • PIX Manager Audit Msg (ITI-9/110112) TF-2a 3.9.5.1.2
  • PIX Manager Update Notification Audit Msg (ITI-10/110110) TF-2a 3.10.5.1.1
  • PIX Consumer Update Notification Audit Msg (ITI-10/110110) TF-2a 3.10.5.1.2
  • Registry Stored Query Document Registry Audit Msg (ITI-18/110112) TF-2a 3.18.5.1.1
  • Registry Stored Query Document Consumer Audit Msg (ITI-18/110112) TF-2a 3.18.5.1.1
  • PDQ Consumer Audit Msg (ITI-21/110112) TF-2a 3.21.5.1.1
  • PDQ Source Audit Msg (ITI-21/110112) TF-2a 3.21.5.1.2
  • Patient Demographics and Visit Query Consumer Audit Msg (ITI-22/110112) TF-2a 3.21.5.1.1
  • Patient Demographics and Visit Query Source Audit Msg (ITI-22/110112) TF-2a 3.21.5.2.1
  • Provide and Reg Doc Set-b Document Source audit Msg (ITI-41/110106) TF-2b 3.41.7.1.1
  • Provide and Reg Doc Set-b Document Repository or Document Recipient audit Msg (ITI-41/110107) TF-2b 3.41.7.1.2
  • Register Document Set-b Document Registry Audit Msg (ITI-42/110107) TF-2b 3.42.7.1.1
  • Register Document Set-b Repository or Src/Rep Audit Msg (ITI-42/110106) TF-2b 3.42.7.1.1
  • Retrieve Doc Set Doc Consumer Audit Msg (ITI-43/110107) TF-2b 3.43.6.1.1
  • Retrieve Doc Set Doc Repository Audit Msg (ITI-43/110106) TF-2b 3.43.6.1.2
  • PID V3 PID Source Audit Msg (ITI-44/110110) TF-2b 3.44.5.1.1
  • PID V3 PIX Mgr / Doc Registry Audit Msg (ITI-44/110110) TF-2b 3.44.5.1.2
  • PIX V3 Consumer Audit Msg (ITI-45/110112) TF-2b 3.45.5.1.1
  • PIX V3 Manager Audit Msg (ITI-45/110112) TF-2b 3.45.5.1.2
  • PIX V3 Manager Update Notification Audit Msg (ITI-46/110110) TF-2b 3.46.5.1.1
  • PIX V3 Consumer Update Notification Audit Msg (ITI-46/110110) TF-2b 3.46.5.1.2
  • PDQ V3 Source Audit Msg (ITI-47/110112) TF-2b 3.47.5.1.2PDQ V3 Consumer Audit Msg (ITI-47/110112) TF-2b 3.47.5.1.1
  • Value Set Consumer Audit Msg (ITI-48/110107) ITI_Suppl_SVS_Rev2-1_TI_2010-08-10 3.48.6.1.1
  • Value Set Repository Audit Msg (ITI-48/110106) ITI_Suppl_SVS_Rev2-1_TI_2010-08-10 3.48.6.1.2
  • Multi-Patient Stored Query Document Consumer Audit Msg (ITI-51/110112) TF-2b 3.51.5.1.1
  • Multi-Patient Stored Query Document Registry Audit Msg (ITI-51/110112) TF-2b 3.51.5.1.2
  • Document Metadata Subscriber Audit Msg (ITI-52/110112) ITI_Suppl_DSUB_Rev1-1_TI_2011-08-19 3.52.6.1.1
  • Document Metadata Notification Broker Audit Msg (ITI-52/110112) IHE_ITI_Suppl_DSUB_Rev1-1_TI_2011-08-19 3.52.6.1.2
  • Document Metadata Notification Recipient Audit Msg (ITI-53/110107) ITI_Suppl_DSUB_Rev1-1_TI_2011-08-19 3.53.5.1.1
  • Document Metadata Notification Broker Audit Msg (ITI-53/110106) ITI_Suppl_DSUB_Rev1-1_TI_2011-08-19 3.53.5.1.2
  • Document Metadata Notification Recipient Audit Msg (ITI-54/110107) IHE_ITI_Suppl_DSUB_Rev1-1_TI_2011-08-19 3.54.5.1.1
  • Document Metadata Notification Broker Audit Msg (ITI-54/110106) ITI_Suppl_DSUB_Rev1-1_TI_2011-08-19 3.54.5.1.2
  • XCPD Initiating Gateway Audit Msg (ITI-55/110112) ITI_Suppl_XCPD_Rev2-3_TI_2011-08_19 3.55.5.1.1
  • XCPD Responding Gateway Audit Msg (ITI-55/110112) ITI_Suppl_XCPD_Rev2-3_TI_2011-08_19 3.55.5.1.2
  • XCPl Initiating Gateway Audit Msg (ITI-56/110112) ITI_Suppl_XCPD_Rev2-3_TI_2011-08_19 3.56.5.1.1
  • XCPL Responding Gateway Audit Msg (ITI-56/110112) ITI_Suppl_XCPD_Rev2-3_TI_2011-08_19 3.56.5.1.2
  • Update Document Administrator Audit Msg (ITI-57/110106) ITI_Suppl_XDS_Metadata_Update_Rev1-2_TI_2011-08-19 3.57.4.1.4.1.1
  • Update Document Registry/Recipient Audit Msg (ITI-57/110107) ITI_Suppl_XDS_Metadata_Update_Rev1-2_TI_2011-08-19 3.57.4.1.4.1.2
  • Provider Information Source Audit Msg (ITI-59/110106) ITI_Suppl_HPD_Rev1-2_TI_2011-08-19 3.59.5.1.
  • Provider Information Directory Audit Msg (ITI-59/110107) IHE_ITI_Suppl_HPD_Rev1-2_TI_2011-08-19 3.59.5.1.2
  • Value Set Consumer Audit Msg (ITI-60/110107) ITI_Suppl_SVS_Rev2-1_TI_2010-08-10 3.48.6.1.2
  • Multiple Value Set Repository Audit Msg (ITI-60/110106) ITI_Suppl_SVS_Rev2-1_TI_2010-08-10 3.48.6.1.2
  • On-Demand Document Source Audit Msg (ITI-61/110106) ITI_Suppl_On_Demand_Documents_Rev1-2_TI_2011-08-19 3.61.7.1.1
  • On-Demand Document Registry Audit Msg (ITI-61/110107) ITI_Suppl_On_Demand_Documents_Rev1-2_TI_2011-08-19 3.61.7.1.2
  • XCF Responding Gateway Audit Msg (ITI-63/110106) ITI_Suppl_XCF_Rev1-1_TI_2011-08-19 3.63.6.1, see also TF-2b 3.41.7.1.1
  • XCF Responding Gateway Audit Msg (ITI-63/110112) ITI_Suppl_XCF_Rev1-1_TI_2011-08-19 3.63.6.1, see also TF-2a 3.18.5.1.1
  • XCF Initiating Gateway Audit Msg (ITI-63/110112) ITI_Suppl_XCF_Rev1-1_TI_2011-08-19 3.63.6.1, see also TF-2a 3.18.5.1.1
  • Notify XAD-PID Link Change PIX Manager Audit Msg ITI-64/110110 ITI_Suppl_XPID_Rev1-1_TI_2011-08_19 3.64.5.1.1
  • Notify XAD-PID Link Change Document Registry Audit Msg ITI-64/110110 ITI_Suppl_XPID_Rev1-1_TI_2011-08_19 3.64.5.1.2
No comments: