Friday, August 11, 2017

The Privacy Advisor Podcast: Kirk Nahra on the complications of healthcare privacy

I listen to podcasts. I have recently come across "The Privacy Advisor Podcast". From the perspective of Privacy, this podcast does a fantastic job. Further Angelique  is fun to listen to. I suspect each podcast we learn a bit more about her, very unusual for a Privacy Advisor. But then again Privacy Principles do enable the subject to expose their data as they wish, a form of control.

To my blog audience, that tends to focus on Healthcare Privacy, the podcast with Kirk Nahra is fantastic. Kirk has a deep and thorough grasp of "Healthcare Privacy" in the USA, from a reality perspective. Not from a ideology perspective. Thus for those that want to understand WHY is Healthcare Privacy like it is, in the USA, this podcast hits every topic. I will warn that none of the points are fully explained, but all the points are spoken. So if you listen to this, and don't understand a point Kirk is making, then you need to do some research. I fully agree with Kirk's point of view and assessment of why and how we got here. He speaks of many of the struggles that I have participated in over the past 25 years. A he points out, if we were to write Privacy regulations today, it would not look this way.

The Privacy Advisor Podcast: Kirk Nahra on the complications of healthcare privacy
6/30/17 by IAPP Publications Team
Web player
In this episode of The Privacy Advisor Podcast, Kirk Nahra of Wiley Rein talks about the challenges of working in the healthcare space these days, particularly, the challenges healthcare entities have in managing the multitude of third-party vendors and the "ongoing element of risk" involved in trying to ensure not only your organization is in compliance with regulations, but vendors are too. He also discusses the explosion of available data not covered under current healthcare laws, like the data from your wearable devices, and whether that data is regulated by any body of law at all. "We've got this enormous gap right now," and the new administration isn't particularly interested in figuring that out, Nahra says, but he's hopeful U.S. state Attorneys General are going to pick up the slack.Want to keep up with new episodes? Be sure to subscribe to our feed.

Thursday, August 10, 2017

Order Word Understand Not Is

Keith has written a humorous yet very informative article "Order Word Import Not Is". This article points out that although there is a right order for words in a sentence, we tend to understand even when the words are in awful painful order.

So, I very much agree with Keith that people can handle it when words are in diffeent order, and even when they are the wrong word but spelled close. I would argue that all software should also handle the case were elements are not in the defined order. I would assert that this is mostly the case today.

I commonly declare that Postel's Law is absolutely necessary in Interoperability. This is the principle that is given much credit for the success of the Internet. It is that when one sends messages to another system, great care should be taken to follow the specification. While it also tells recipients of messages to be very robust and generous in how it processes messages from others. This bi-directional principle addresses Interoperability two ways. It does not only address Interoperability by declaring that the specification is LAW. It also addresses Interoperability by requiring robust input processing with the intent that the recipient tries really hard to understand what the sender wants to say.

However right now there is an emergence of CDA scorecards, and CDA test tools. These are being very strict regarding the specification, including the order of elements. Thus they throw warnings, sometimes errors, when the elements are out-of-order. These tools then give a POOR score to the CDA document. This poor score is justified, as it is not a quality document.

The problem is, that these poor scores are not an indication of the quality of the data. That is there is no evaluation by these tools of the medical fitness of the medical data. This is not their intent, nor is this possible in a test tool. I am only pointing out that it is a perception that someone that doesn't fully understand the purpose of the tool might improperly come to.

More important these poor scores are not really an indication of how well the data could be processed. That is to say that the CDA document might be well processed with no failures, because recipients are using Postel's Law, and are able to process the XML even with the elements not in perfect order.

Should the tools be changed? No, we just need better tools to explain the output of the tools. For example, the test tool can notice that the failure is because of an out-of-order element. It somewhat does this today. But they complain that the NEXT element is not the one expected. The failure is actually caused by the PREVIOUS element having been inserted too soon.

Indeed, as Keith points out  "Order Word Import Not Is". Thus don't complain that you can't figure out what the "Is" word is... Look earlier and see that "Is" could have been valid had it been inserted sooner.

Wednesday, August 2, 2017

MHD (FHIR DocumentReference) support for Repositories and Communities

The MHD profile is a RESTful API for Document exchange. One use is to use it as a more simple API for discovery and use of Document in a Document Sharing environment such as XDS or XCA. The MHD profile shows this in abstract terms, but abstract diagram does not show a complexity that implementers will be faced with. I have taken those diagrams, and cut them to show only the Document Consumer side. I have also augmented them to show the reality.

XDS and XCA Reality is multiple

The reality is, that within an XDS Affinity Domain, there will be many Document Repositories, each will have their own "repositoryUniqueId". The XDS model allows for multiple Repositories to support environments where each authoring system wants to hold onto their documents until they are Retrieved for use. In XDS, a Document Consumer must know both the documentUniqueID and the repositoryUniqueId in order to do a ITI-43 Retrieve Document Set-b transaction.

Similarly XCA is a "Federation" of "Communities", and thus there are many Communities. Therefore reality in XCA, is that the documentUniqueId, repositoryUniqueId, and homeCommunityId is needed in order to do a ITI-39 Cross Gateway Retrieve. Note that ITI-39 has a degenerate form that s ITI-43, which can also carry the homeCommunityId. This all recognizes that in XCA one must know which community holds the document, and possibly what repository within that community (Another deployment model where a Community is an XDS Affinity Domain).

Where does the repositoryUniqueId, and homeCommunityId go in the DocumentReference Resource?

I have been asked this question multiple times. There is no place in DocumentReference for these two values. This is intended, and there is no need to add an extension.

The MHD Document Consumer never needs to know these two values. They are not helpful to evaluating the metadata. All the metadata that is necessary is in DocumentReference.

However when a MHD Document Consumer requests a document, the MHD Document Responder must know these values in order to appropriately execute the ITI-43 or ITI-39. So where does the Document Responder get these values?????

Parameter Solution

One possible solution is that the MHD Document Responder encoded them into the URL used for the document Retrieve transaction.....   Let me explain...

The Document Responder is in complete control of the DocumentReference.content.attachment.url. It can put any valid URL into this element. The MHD Document Consumer is told it must simply execute a GET using that URL.

So, one could use a "?" Query String


Long Identifier Solution

Elliot suggests a different solution that might fit better a 100% MHD solution, that has better round-trip consistency between the MHD Provide Document Bundle [ITI-65] transaction and the Retrieve Document Set [ITI-43]. This solution does keep with using "Binary" for the document bits. This solution just strings along the various unique identifiers in sequence.

[base-url]/Binary/<documentUniqueId> + "_" + <repositoryUniqueId> [+ "_" + <homeCommunityId>]

During the Provide transaction there would be no homeCommunityId, or it would be very unusual. 

Other Solutions

Other solutions are possible. With this solution everything that a Document Responder needs is handy, thus the DocumentResponder does not need to reference internal data. Holding internal data in a server is an alternative, but requires the DocumentResponder be stateful.

Security Considerations

The URL should not be interpreted as authorization. That is the Document Responder, and any services behind the Document Responder, needs to do authorization checks on every access request. One must be robust to a client manipulating the URL to point at different documentUniqueId, repositoryUniqueId, and homeCommunityId.


There is no need for extensions, no need for these values to be in the DocumentReference for MHD to work properly. However some software/system design is needed to make a working DocumentResponder. The solution I offer is just one possibility. One that I think is elegant.

Questions, Comments, and Criticism welcome.

UPDATES Since original post:

  • Thanks to Elliot for pointing out my failure on "#" fragment.... I changed it to "?"
  • Thanks to David for recommending against use of "Binary" as unnecessary and possibly confusing
  • Thanks to Elliot who convinced me to formally recognize his "_" solution given that it is likely more consistent with FHIR RESTful model.

Friday, July 21, 2017

IHE IT Infrastructure Technical Framework Supplements and Technical Framework Volumes Published.

edited July 25 to add MHD

IHE IT Infrastructure Technical Framework Supplements Published

The IHE IT Infrastructure Technical Committee has published the following supplements for Trial Implementation as of July 21, 2017:

New Supplement
  • Remove Metadata and Document (RMD) - The RMD Profile provides a means to request document removal from an XDS Repository, and metadata removal from a Registry. It builds on concepts presented in the XDS Metadata Update supplement, but is not dependent on those capabilities.
Updated Supplements
  • Add RESTful Query to ATNA
  • Cross-Community Document Reliable Interchange (XCDR)
  • Cross-Community Fetch (XCF)
  • IHE Appendix on HL7® FHIR®
  • Extensions to the Document Metadata Subscription Profile
  • Mobile Alert Communication Management (mACM)
  • Mobile Access to Health Documents (MHD) 
  • Patient Demographics Query for Mobile (PDQm)
  • Patient Identifier Cross-reference for Mobile (PIXm)
  • XAD-PID Change Management (XPID)
  • XDS Metadata Update

IHE IT Infrastructure Technical Framework Volumes Published

The IHE IT Infrastructure Technical Committee has published the following updated Technical Framework Volumes (Rev. 14) as of July 21, 2017:
  • Volume 1 (ITI TF-1): Integration Profiles
  • Volume 2a (ITI TF-2a): Transactions
  • Volume 2b (ITI TF-2b): Transactions (cont.)
  • Volume 2x (ITI TF-2x): Appendices
  • Volume 3 (ITI TF-3): Contains Section 4 (Cross-Transaction Specifications) and Section 5 (IHE Content Specifications)
  • Volume 4 (ITI TF-4): National Extensions
Note: The Document Digital Signature Profile (DSG) has been incorporated into this revision of the IT Infrastructure Technical Framework Volumes.

The profiles contained within the above documents may be available for testing at subsequent IHE Connectathons. The documents are available for download at Comments on these and all IT Infrastructure documents are welcome at any time and can be submitted at IT Infrastructure Public Comments.

Friday, July 14, 2017

E-mail addresses -- Remedial and realistic

The difference between reality and theory for an e-mail address is huge. I want to drive a bit of open discussion as implementation of e-mail software, directories, and operational environments; fall somewhere along that gap. That is to say that there is much software and services that support e-mail that don't quite implement everything that the standards allow. There are also really good reasons to not support everything that the standards allow

e-mail address according to standards

I am not going to replicate the full definition of what can be in an email address from a standards perspective as there are fantastic write-up that is very readable on the wikipedia, and a nice graphic available from Jochen Topf . I will just pull some examples of just how ugly an email address can be. I am sure you all didn't know these are possible:
  • ""
  • "very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"
  • #!$%&'*+-/=?^_`{}|
  • "()<>[]:,;@\\\"!#$%&'-/=?^_`{}| ~.a"
  • user@[IPv6:2001:DB8::1]
Internationalization examples
  • Latin alphabet (with diacritics): Pelé
  • Greek alphabet: δοκιμή@παράδειγμα.δοκιμή
  • Traditional Chinese characters: 我買@屋企.香港
  • Japanese characters: 甲斐@黒川.日本
  • Cyrillic characters: чебурашка@ящик-с-апельсинами.рф
  • Hindi email address: संपर्क@डाटामेल.भारत

Little bobby drop tables is possible

Direct impact

I have been working with developers on an implementation of "Direct". For those that don't know about "Direct", it is simply a profile of e-mail for use within USA healthcare. I was one of those that was involved in "The Direct Project", and wrote the security section and risk assessments. I am sorry that FHIR didn't exist at that time, as it would have been quickly selected over this e-mail solution. The e-mail solution is sub-optimal at best. 

The diagram shows the various parts. It is just the sending side, but it shows various parts that all will be impacted by the e-mail address. Most can just process the e-mail address as a string. But some need to do more with it than that.

Direct uses secure email (S/MIME), uses X.500 certificates to protect endpoints authentication, authorization, and confidentiality of communication. It has two mechanisms for discovering a certificate given an email address. And there are trust organizations, like, that provide governance and certificate services.

Hidden Practice - Remedial e-mail address

Most would not fully support all the capability of an e-mail address as defined in the standard. But most would also not tell others of their self-imposed restrictions. These restrictions might be because of their technology, but might be because of some organizational policy. Such as email systems that use a file-system architecture would limit the email address to what can be represented 'safely' in an file-system directory. 

Most likely today email address are restricted to alpha, number, period, underscore, and hyphen. 

Thus not allowed are ampersand, asterisk, plus, slash, equal, question, carrot, curly-brackets, or tilde. This restriction is not too worrisome. 


The Direct Project has not endorsed RFC 6530, which extended e-mail addressing to International Characters. So, they don't need to worry (or support) the international characters

Some worry about the International characters because of the fact that there are some characters in that set that 'look' exactly like ASCII characters, thus easy to fool a human. This is less of a concern with Direct as all addresses are looked-up to find their Certificate, and that Certificate must chain to a Trusted Certificate Authority. Thus this attack would not work unless a Certificate Authority has accepted a deviant email address and issued a Certificate. And if a CA did this, then that CA should not be trusted. So within Direct there is protection against this attack.

Directory vs e-mail address

Also, we are speaking specifically about the technical part of an email address, not what gets displayed to a user. It is this 'displayed to a user' that is a important separation. What gets displayed to the user might be far more relaxed, especially if a Directory is available to fully represent in full feature, the name the individual wants to be called.

In fact this is where I get specifically worried that some are demanding deviation from reasonable specification because of user-experience expectations. Specifically, most users expect that email addresses are NOT specific to the case of the characters typed, but technically at the e-mail protocol they are allowed to be case-sensitive. Thus the protocols are all defined as "case preserving" while allowing a server side determination if the server-side wants to treat e-mail addresses as case-sensitive or not.  

More specifically it is easy to give a user the experience of case insensitivity, while being case specific at the technical level. One can look through a Directory in a case-insensitive way, when only one entry is found then use that entry, but use the case of the e-mail address one found in that Directory (or certificate) at the protocol level. This is case-preserving, and thus does not require a deviation from the e-mail standards.

First step beyond remedial

The first challenge to remedial address is the need to include a single-quote such as is needed for "Fred O’Donnell".  The single-quote character is not often supported by email technology, as it can cause encoding issues in various technologies like file-systems, directories (LDAP), databases, and APIs. These are not impossibilities, but where a single-quote exists, it must be handled special. Where as all the other characters in the remedial list require no special handling.

This single-quote problem is what brought me to this whole topic. As someone with a single-quote in their email couldn't use Direct. There was a bug that was fixed. But as discussed above if all partners within a Direct trust domain don't also support single-quote equally, than this individual will only be able to send-to or receive-from those that do support single-quote. So is fixing this bug really helpful? Is the single-quote needed in the e-mail address, or just what gets displayed (Directory)?

Controlled Advancement

So I have addressed the DirectTrust community with this topic. From what I could tell, this issue is as big as I predict. Remedial email addresses are okay, but beyond that and major 'interoperability' issues would happen. Inducing O'Donnell, single-quote. 

I did hear some interest in adding the plus character. Plus is a special case, not just a character. Especially in light of the way that Direct supports individual addresses vs domain addresses.

I would very much recommend DirectTrust come up with a policy. They are an operational environment, an as such can make operational decisions that can't be made in an Interoperability specification like Direct. Thus any operational policy that DirectTrust comes up with does not need to be represented in the Direct specification. This policy might not be a ‘forever forbidden’ policy, but rather a ‘not allowed at this time’. This keeps open to future needs that are use-case and demand driven. This policy should be very clear about the fact that International characters are not required, and thus DirectTrust does not allow them.

I would recommend against the really special processing such as comments (), and quoted strings. These serve very little value, and are a place where trouble can hide.


It is likely that remedial e-mail address is sufficient, so this might actually not be a big issue. But it does require a Policy so that everyone can appropriately TEST to assure Interoperability.

Wednesday, July 5, 2017

Beyond Basic Privacy – The IHE APPC Profile

New IHE profile allows patients more flexibility in expressing their privacy preferences. 

This is a re-publication of an article that Tarik Idris from InterComponentWare and I co-authored. Originally posted on the ICW blog at 20.04.2017
The average size of electronic medical records grows each year. Some of the drivers of this growth are the increased utilization of EMR systems, scanning of paper records, and improved access to health information exchanges. As a consequence, patients need more sophisticated tools to adequately express their privacy preferences. When your medical record contains only a few x-rays and is only ever shared between your family doctor and your radiologist, a simple “yes” or “no” to data sharing may be sufficient to express your privacy preferences. But if your record contains family and social history, photos of skin conditions, STD panels, genetic information, and psychiatric evaluations and different parts of that record need to be accessed by a small army of physicians, surgeons, therapists and dental hygienists, you might need a more detailed method of defining your privacy preferences than “yes” or “no”.

Privacy preferences are commonly documented in a patient privacy consent document. The IHE profile BPPC (“Basic Patient Privacy Consents”) defined a common format for these consent documents. It is widely used, especially in projects sharing medical documents between different healthcare enterprises. BPPC was designed to cover cases where the patient has a simple choice between a handful of possible privacy policies. For example, the patient might choose between allowing all data sharing, only allowing sharing of summaries or only allowing sharing in case of emergency. The BPPC profile doesn’t determine what the choices are, it only requires that each choice that a patient is given has a unique identifier (“Privacy Policy Identifier”) and that there is some kind of access control system that knows what to do for each of those identifiers. The consent document only references the privacy policies (they are not expressed in a machine readable format as part of the consent document) and are just assumed to be understood by the recipient. BPPC was not designed for expressing fine-grained access rules, e.g. that a specific lab panel might only be viewed by a specific healthcare provider.

In light of this growing need for more sophisticated consent documents, the IHE IT Infrastructure Domain decided to define a new profile, IHE APPC (Advanced Patient Privacy Consents), that compliments BPPC by addressing additional use cases. Development of this profile started in late 2015 and was supported by an international group of stakeholders. The profile was published as a new “Supplement for Trial Implementation” in August 2016.

APPC’s focus is to enable automatic enforcement of consent documents. If a patient’s consent document states that facility X may not access his longitudinal record in an HIE, then the HIE should automatically deny access requests for this patient’s records coming from facility X. To enable this automatic enforcement, APPC includes a detailed, machine-readable, structured representation of the privacy policy. Whereas BPPC only included a reference to the privacy policy, APPC uses OASIS XACML (eXtensible Access Control Markup Language) to fully spell out the access control rules implied by the privacy policy. XACML is an XML-based domain specific language to unambiguously define access rules. This allows systems to implement an enforcement mechanism for these privacy policies by using one of several commercial or open source rules engines that can interpret XACML access rules.

We hope to empower both healthcare providers AND patients with the IHE APPC profile. Without a flexible language for defining access control rules for each project, vendors will force the same one-size-fits-all access control approach onto all healthcare providers, regardless of their specific needs. Using the IHE APPC profile, healthcare providers will be able to define an access control approach that fits their processes and their patient collective. E.g. pediatric oncology patients need their data available for regular follow-ups for a long time, whereas a surgery ER patient’s data could potentially be more ephemeral.

Patients will benefit by having a less monolithic approach to privacy preferences. While it is unrealistic that there will be completely different rules for each patient, there is a finite list of common customizations that can easily be implemented in an enforcement system based on IHE APPC. A common type of patient-specific customization is to blacklist specific providers (colleagues, relatives, former lovers, …) to deny them access to your patient record. Another common customization is hiding specific documents (e.g. drug testing results, psychiatric evaluations).

“The advantage for patients is the greater consideration of their individual needs.”

Of course in the grand scheme of things, technology, standards and products are just minor elements in arriving at a patient-friendly and efficient privacy scheme. Privacy laws and regulations, healthcare provider’s competitive landscape and association politics, liability laws, etc. usually have a greater impact on what the actual privacy choices for patients are. But when it is time to establish an agreed upon set of privacy policies in real world IT systems, it is important to have specifications like IHE APPC ready to enable an easy and cost-efficient implementation.

Monday, June 26, 2017

GDPR Privacy about more than just confidentiality

Rene Spronk published an excellent and very detailed article on a unique perspective drawn from the new General Data Protection Regulation (GDPR) -- aka: European Privacy Regulation. That it requires that Patients be given access to data about themselves, in a standardized, and usable form. Thus the regulation makes Interoperability Standards a requirement. Please see his article: Impact of GDPR on the use of Interoperability Standards

This perspective is driven by Privacy Principles, which are more than just Confidentiality.

The GDPR also requires that any Consent given must be understood by the subject regardless of their age, education, or human language issues. Thus any organization gathering data must provide various forms of their consent language that can be proven to be understood by that patient. The FHIR Consent supports this by having a place to record the actual text presented to the patient. Clearly deriving that text originally is not a FHIR issue. It is a very difficult task, and I feel for small organizations. Similar capability to record the actual text presented to the patient is also available in IHE BPPC which supports APPC for this purpose.

As with any Privacy regulation one must have good Provenance proof of where all data came from, including when it was imported from the Patient themselves. One must also have good AuditEvent records to show where and why the data was used.

See my Privacy Consent topic table of contents
And my FHIR topic table of contents

Tuesday, June 20, 2017

Human Names - remedial testing

Humans around the world have very difficult to deal with names. But even the most simplistic names can be problematic. Here is a specific case I have run into lately. We have had a problem where a person had a apostrophe in their name, and it caused failures. This because in the API (string based API), a person name is quoted using single quote... yet if it includes a quote, that terminates the string early... oops.

So I poked around, and don't find a test bench that does much of a good job at testing string elements that are intended to be human names. I did find a fantastic QA article from W3C. But I would consider what they have outlined as "advanced". 

Remedial would be a far more basic set... The closest I find is the definition in LDAP. That definition for PrintableString.

      PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
                           PLUS / COMMA / HYPHEN / DOT / EQUALS /
                           SLASH / COLON / QUESTION / SPACE
      PrintableString    = 1*PrintableCharacter
      IA5String          = *(%x00-7F)
      SLASH              = %x2F  ; forward slash ("/")
      COLON              = %x3A  ; colon (":")
      QUESTION           = %x3F  ; question mark ("?")

   <HYPHEN>, <DOT>, <EQUALS>, and <SPACE> rules are defined in

PrintableString has a few characters in it that are uncommon in a human name (never say never). But it does clearly indicate the 7-bit ASCII alpha, number, hyphen, space, period, and apostrophe. This set would work fine for many countries, okay it would only work for USA... But that is why I call it remedial.

      RemedialCharacter = ALPHA / DIGIT / SQUOTE / HYPHEN / DOT / SPACE
      RemedialName    = 1*RemedialCharacter

Beyond this one mostly needs all the alpha from unicode...See the W3C QA specification. but I haven't quite figured that one out.

Mostly, I am thinking that for Provider Directory, and Patient Directory.... that testing should have test script that test for this remedial, and optionally for the full unicode...  And, they need to deal with searching, and sorting... topics well beyond advanced, but very very important.

Again... I don't think remedial is enough, but if one can't get past remedial they are clearly not ready for real person names

Friday, May 26, 2017

Privacy toolkit - W3C Privacy Assessment

This is a short article simply to point toward W3C "Specification Privacy Assessment". I watch many standards bodies, and interact with a few. W3C is most mature "Standards" organization with regards to considering privacy impact that their standards have. Others are working toward having some process for considering privacy while writing a standard specification. But the others are more aspirational, where W3C is 'doing it'.

The best introduction is a presentation. This is fantastic presentation, very detailed. I would love to present these slides as there is so much depth on each page.

They have a set of Questions that each W3C specification writing team must consider. These questions are not intended to short-circuit a real Privacy Impact, but rather to focus on some of the obvious top issues. Here is an excerpt:
  • can the information be used (alone or in combination with other APIs / sources of information) to fingerprint a device or user?
  • may I access to the information I created?
  • may I record it myself (locally)?
  • am I able to have actions on this personal record?
  • may I block partly or totally the record of the information?
  • may I fake it? (think about fuzzy geolocation or voluntary fake location)
  • Is the data personally-derived, i.e. derived from the interaction of a single person, or their device or address? (If so, even if anonymous, it might be re-correlated)
  • Does the data record contain elements that would enable such re-correlation? (examples include an IP address, and so on)
  • What other data could this record be correlated with? (e.g. the ISP)
  • If you had large amounts of this data about one person, what conclusions would it enable you to draw? (e.g. maybe you could estimate location from many ambient light events by estimating latitude and longitude from the times of sunrise and sunset)
  • Am I likely to know if information is being collected?
  • How visible is its collection and or use?
  • Do I get feedback on the patterns that the information could reveal (at any instant, over time) so I can adjust behaviors?
  • if a background event about the device is fired in all browsing contexts, does it allow correlation of a user across contexts?
  • can code on a page send signals that can be received by device sensors on nearby devices?
You can see that W3C considers all of the Privacy Principles, not just confidentiality.

They also have defined some re-usable Privacy Considerations. Such as the "Web Applications Privacy Best Practices"
  • Best Practice 1: Follow "Privacy By Design" principles
  • Best Practice 2: Enable the user to make informed decisions about sharing their personal information with a service.
  • Best Practice 3: Enable the user to make decisions at the appropriate time with the correct contextual information.
  • Best Practice 4: When learning user privacy decisions and providing defaults, allow the user to easily view and change their previous decisions.
  • Best Practice 5: Focus on usability and avoid needless prompting.
  • Best Practice 6: Active consent should be freely given, for specific data, and be informed.
  • Best Practice 7: Be clear and transparent to users regarding potential privacy concerns.
  • Best Practice 8: Be clear as to whether information is needed on a one-time basis or is necessary for a period of time and for how long.
  • Best Practice 9: Request the minimum number of data items at the minimum level of detail needed to provide a service.
  • Best Practice 10: Retain the minimum amount of data at the minimum level of detail for the minimum amount of time needed. Consider potential misuses of retained data and possible countermeasures.
  • Best Practice 11: Maintain the confidentiality of user data in transmission, for example using HTTPS for transport rather than HTTP.
  • Best Practice 12: Maintain the confidentiality of user data in storage.
  • Best Practice 13: Control and log access to data.

The "Device API Privacy Considerations". Which includes a nice breakdown of the Privacy Principles to those that impact Device design.

The "Mobile Web Application Best Practices". Which not just itemizes a fantastic set of Best Practices (cookie use, client storage, robustness, informing user, avoid redirects, etc...). But goes into detail on these best practices
    3.1 Application Data 
    3.2 Security and privacy 
    3.5 User Experience 

see also my articles 

Friday, May 19, 2017

Clarification of Affinity Domains

The Question: I've worked with the XDS.b and XCA profiles for a few years now, but am no means an expert. I've never understood exactly what an affinity domain is. Could someone give an explanation of an affinity domain?

XDS Affinity Domain

Affinity Domain is more properly an "XDS Affinity Domain". The term is specific to XDS. It does not apply to XCA, as XCA uses the term "Community" in a rather similar but more expansive.

an XDS Affinity Domain -- derived from the word "affinity". Which among the many definitions has these -- These from Merriam-Webster definition for "affinity"
  • sympathy marked by community of interest : 
  • an attraction to or liking for something 
    • people with an affinity to darkness — Mark Twain 
    • pork and fennel have a natural affinity for each other — Abby Mandel
  • an attractive force between substances or particles that causes them to enter into and remain in chemical combination
  • a person especially of the opposite sex having a particular attraction for one
In the IHE Glossary
  • A group of healthcare enterprises that have agreed to work together using a common set of policies and which share a common infrastructure of repositories and a registry.
Essentially it is a term we use in XDS to encompass all the actors, systems, technology, policy, procedure, people, and ether. A set of XDS Metadata codes that the Registry will enforce. A set of document types that are considered acceptable by the Affinity Domain. Agreement on how Authorization will be done, including Consent, Role-Based-Access-Control, and Break-Glass.

See section 10.4.8 of volume 1 "Concept of an XDS Affinity Domain"

An XDS Affinity Domain is an administrative structure made of a well-defined set of Document Source Actors, set of Document Repositories, set of Document Consumers organized around a single Document Registry Actor that have agreed to share clinical documents.

Note: Document Sources, Repositories and Consumers may belong to more than one XDS Affinity Domain and share the same or different documents. This is an implementation strategy and will not be further described.

Note: The XDS Profile does not support the federation of XDS Affinity Domains directly, but the Cross-Community Access (XCA) Profile addresses the cooperation of multiple Document Registry Actors serving different XDS Affinity Domains.

A number of policies will need to be established in an XDS Affinity Domain in order to ensure effective interoperability between Document Sources and Consumers. Some of the key technical policies include (A more extensive list of policy agreements that need to be made by XDS Affinity Domains is discussed in ITI TF-1: Appendix L):

1. The document formats that will be accepted for registration

2. The various vocabulary value sets and coding schemes to be used for the submission of metadata of document, submission set and folders registration.

3. The Patient Identification Domain (Assigning Authority) used by the Document Registry.

See ITI TF-1: Appendix K for a detailed discussion of the concepts of XDS Affinity Domain.

For which the Handbook on XDS Affinity Domain planning is important.

XCA Community

The difference between "XDS Affinity Domain" and the XCA "Community" is that IHE has much less to say about the requirements of a Community. There are cases where a Community is an XDS Affinity Domain; but XCA allows for many other forms of Community. Common variant of a Community is a large hospital system (like the VA where I now work). In those cases the Community is understood only as the stuff behind the XCA gateways. There is no mandate about code validation by a Registry, no mandate about use of ATNA, no mandate about use of CT, etc. There is no defined way to create registry entries. There is no requirement to support folders, associations, and extensions.

The additional difference is that a Community can contain other Communities. IHE is rather silent on this. This silence was driven more by the desire to get experience with nested communities, routing communities, proxy communities, etc. We have heard of some interest in resolving this, and I would encourage a new work item.

In the IHE Glossary
  • A community is defined as a group of facilities/enterprises that have agreed to work together using a common set of policies for the purpose of sharing health information via an established mechanism. Membership of a facility/enterprise in one community does not preclude it from being a member in another community

Some more background articles

Thursday, May 18, 2017

Consent to deny Sharing for Treatment and Emergency Break-Glass

We have discussed in years past that Australia had a Privacy Consent where break-glass was not allowed. We understand that has changed to allow break-glass. Thus we didn't know of a case where a Consent forbid break-glass... I have been made aware of Utah HIE that has a checkbox on their Consent to forbid break-glass. This is a consent only for HIE, not for within a hospital environment; but it is relevant to our FHIR consent (and CDA consent) work. Thus I think it is useful for us to provide it as an example, and work through how it might be expressed.

The Utah HIE Consent Form is

Note, that in the context of a FHIR consent; this URL could be used as the Policy URI...  It is a general form that the Patient has some check boxes they can choose.

So given that we have an example that forbids Treatment but allows Break-Glass  (Note spell check needed)

We should likely create an example that forbids both Treatment and Emergency (Break-Glass). Something like this:

<Consent xmlns="">  <id value="consent-example-No-Emergency"/> 
<status value="generated"/>
<div xmlns="">
<p>   Withhold Authorization for Treatment and for Emergency Treatment  </p> <p>     
Patient &quot;P. van de Heuvel&quot; wishes to have no data shared for Treatment or Emergency treatment use.   
An overall consent Directive, with an exception 
&quot;Deny&quot; of purposeOfUse &quot;TREAT&quot; sharing use and
&quot;Deny&quot; of purposeOfUse &quot;ETREAT&quot; sharing use
at &quot;Infoway&quot; HIE.   </p>
<status value="active"/>
   <system value=""/>
<code value="57016-8"/>
<display value="Privacy policy acknowledgement Document"/>
<reference value="Patient/f001"/>
<display value="P. van de Heuvel"/>
<dateTime value="2017-05-08"/>
<!--   not bound by a timeframe - Consent.period   -->
<!--   I assume the example given is Canada Infoway wide???  AND I assume it is desired to   state that in the Consent.authority element   -->
<reference value="Organization/Infoway"/>
<display value="Canada Infoway"/>
<!--   the text terms of the consent in lawyer speak   -->
<title value="The terms of the consent in lawyer speak."/>
<!--   likely use url pointer to common text   -->
<!--       this is opt-out - e.g. nothing approved unless otherwise stated.    -->
<policyRule value=""/> 
<!-- this policyRule is a multiple use policy. The Patient has expressed       both deny Treatment and deny Emergency  -->
<type value="deny"/>
<system value=""/>
<code value="TREAT"/>
<type value="deny"/>
<system value=""/>
<code value="ETREAT"/>
I have filed a FHIR Change Request 13420

Other Privacy Consent topics 

Corrected the example to make more clear it is a "Privacy Consent" by specifying the Consent.category.

Wednesday, May 17, 2017

Two new IHE Profiles on #FHIR - Provider Directory and File Management

Public Comment opens for Provider Directory and File Manager --- both using FHIR STU3

IHE IT Infrastructure Technical Framework Supplements Published for Public Comment

The IHE IT Infrastructure Technical Committee has published the following supplements to the IHE IT Infrastructure Technical Framework for public comment in the period from May 17 through June 16, 2017:
  • Mobile Care Services Discovery (mCSD)
  • Non-patient File Sharing (NPFS)
The documents are available for download at Comments submitted by June 16, 2017 will be considered by the IHE IT Infrastructure Technical Committee in developing the trial implementation version of the supplements. Comments can be submitted at IT Infrastructure Public Comments.

Wednesday, May 10, 2017

FHIR OAuth scope proposal using FHIR query parameters

In FHIR STU3 there are now some common query parameters. I propose that these common query parameters can be used to advance the OAuth scopes that are defined today. The current SMART scopes are based on simple vectors:

  1. Patient vs 'user' -- 
    1. Where a scope of 'patient' means all results must be from that one patient
    2. Where scope of 'user' means all results are relative to that user rights to data
  2. fhir-resource --
    1. Where a FHIR Resource named will limit results to only that Resource type
    2. This is a valueset of fixed strings (e.g. "Observation", etc)
  3. REST operation

Expressed in EBNF notation, the clinical scope syntax is:

clinical-scope ::= ( 'patient' | 'user' ) '/' ( fhir-resource | '*' ) '.' ( 'read' | 'write' | '*' )

To understand the current OAuth scope see a few other articles:
So, if the OAuth authority authorizes the user to access the patient requested, as defined in the launch context, for only Observations, and only read operations. This would be a scope of
A problem with this is that the actual identifier of the "Patient" is undefined. For SMART this is handled by the 'launch context'.

Propose using common "patient" query parameter for patient scope

With the new FHIR STU3 common shared query parameters, we could identify the specific patient within the Scope. There is a common query parameter for "patient" against 35 different Resources. This has an advantage to be specific, but has a disadvantage that the scopes are not made up of static strings. I would like to suggest that this use of shared query parameters would be a replacement form the first part of the SMART scopes.

So, rather than relying on the SMART launch context to hold the patient identifier. The example with a patient of 'http://myserver.example/fhir/Patient/f5c7395'

or, we could add it to the end.  I think this more powerful."http://myserver.example/fhir/Patient/f5c7395"
Which is 

clinical-scope ::= ( fhir-resource | '*' ) '.' ( 'read' | 'write' | '*' ) '#' ( query | '*')

I a proposing this without working out all the issues. I just want the scope to include the patient. 

Scope is Not Query parameters
This is NOT a proposal to force these query parameters and trust server search capability. This might be one thing done to make it efficient, but won't work perfectly as not all. The use of search parameters will just help with positive matches; but will not be perfect against false-positives or false-negatives. It will also fail when the other parts of the query are creatively authored to cause the wrong thing to happen.

The scope does need to be ENFORCED. The Resource server is expected to enforce the scope without fail. This is what I mean by more than just query. Most important is inspecting the resulting Bundle to assure that no content is contained in the Bundle that doesn't fit within the Scope.

More common query parameters

Some of the other common search parameters that might be useful:
  • _id -- when the scope is restricted to exactly ONE resource
  • _tag -- when the scope is restricted generally to some tag
  • _profile -- when the scope is restricted to some specific _profile tag
  • _security -- when the scope is restricted to some vocabulary from the HCS (e.g. confidentiality of "N" normal)
  • encounter -- when the scope is restricted to a specified encounter

Clearly missing but needed

There are some important vectors in Privacy space that are missing:
  • Timeframe for when the data was created - used to hide timeframe or enable a timeframe
  • Authored by - used when policy allows only data authored by some org or user
Note, scope is not everything. Where the user is forbidden, they get no authorization at all.

Also, I don't propose how to use negative scopes. Such as this user (Provider) can see any data but not patient Mary.

Not Done Yet

This is not a final solution. I am just putting this out there for discussion. Simply to bring up options for discussion on how to make improvements to Scope. The unfortunate facts of healthcare is that the needs for scope is a complex of multiple vectors; and failure is severe when not appropriately protected or when not appropriately available. Both false positive and false negative can have severe effects.

See my other FHIR articles

Monday, May 1, 2017


IHE ITI has a set of profiles on FHIR existing in Trial Implementation today. These were written against FHIR DSTU2. These have been updated to STU3, now in ballot for members of the ITI Technical Committee to comment and vote on.  Details and access to the ballot drafts of these documents is available from the ballot.
The IHE ITI Technical Committee is also working on new profiles using FHIR. These will be further discussed in later articles.
  • Mobile Care Services Discovery (mCSD)
  • Non-Patient File Sharing (NPFS)
  • Access to Document-extracted Data-elements (ADD) 
    • Formerly: Patient Centric Element Location
    • This is a profile that combines XDS/MHD and QEDm to describe how a Document Sharing environment can provide more fine grain access (Resource) to data shared as documents. 
    • This profile does rely on creative systems engineering to decompose the documents into the FHIR resources. This might leverage CDA-on-FHIR, or some other methodology. This methodology is not specified.
    • What is specified is that the fine grain details must have Provenance pointing at the Documents from which the data came. This enables a consumer to retrieve using XDS or MHD the document from which the fine grain details came from.
The IHE ITI and PCC are working jointly on one as well:
IHE ITI is also working on one non FHIR Profile
  • Remove Metadata and Document (RMD)
    • This is a profile on XDS for administrative ability to remove metadata entries and remove documents
Lastly IHE Document Digital Signature (DSG) Profile approved for Final Text

Thursday, April 27, 2017

IHE Document Digital Signature (DSG) Profile approved for Final Text

Today the IHE ITI Technical and Planning committees approved the Document Digital Signature (DSG) Profile be moved into Final Text. This Document Profile defines a way to support Digital Signatures, including when those Documents are managed in a Document Sharing infrastructure. This DSG Profile is referenced in many places where adding a Digital Signature to a document would be beneficial, such as Consent, Legal Evidence, etc.

There is more interest in digital signatures driven by some Anti-Fraud use-cases. I think there will be more interest driven by Patient Authored content.

The main problem with Digital Signatures is NOT the standards, it is the Policies and overhead in issuing proper Digital Identity (PKI). Once there are Digital Certificates issued for the purpose of Digital Signatures, then there are many use-cases that can be enabled. However that first justification of the costs is very hard to do, and somehow combining justifications just never seems to happen.

The Document Digital Signature (DSG) profile is a Document Content profile that provides general purpose methods of digitally signing of documents for communication and persistence. This method can be used within a Document Sharing infrastructure (e.g., XDS, XCA, XDM, XDR, and MHD).

Electronic documents are being increasingly relied upon in healthcare. Signatures have been a part of the electronic documentation process in health care and have traditionally been indicators of accountability. Reliable exchange of data between disparate systems requires a standard that implements non-repudiation to prevent document creators from denying authorship and rejecting responsibility.

DSG supports:
  1. An Enveloping Signature is a Digital Signature Document that contains both the signature block and the content that is signed. Access to the contained content is through removing the Enveloping - Digital Signature. Among other uses, this method should not be used with Document Sharing infrastructure.
  2. A Detached Signature is a Digital Signature Document that contains a manifest that points at independently managed content. Detached signatures leave the signed document or documents in the original form. Among other uses, this method is recommended for use with a Document Sharing infrastructure to support Digital Signatures, as this method does not modify the original Document Content. This method uses the Document Sharing “SIGNS” relationship provide linkage.
  3. A SubmissionSet Signature is a Detached Signature Document that attests to the content in a SubmissionSet by: containing a manifest of all the other Documents included in the SubmissionSet, and a reference to the SubmissionSet. The Document Sharing “SIGNS” relationship may be used but is not required.
The digital signature standard is XML-Signature using XAdES-L-T profile, which brings inside the certificate and a timestamp; and we utilize the CommitmentTypeIndication for Purpose Of Signature. Thus we just bind in a vocabulary specific to Healthcare needs.

We did not include the new CDA digital signature. This is not because it isn't useful or interesting, but more because that would have been a very different technology. Those that want this profiled by IHE, should bring a New Work Item Proposal to profile it.

Reflecting FHIR FMM in IHE Profiles

IHE is creating many Profiles using FHIR. Given that FHIR is still "Standard for Trial Use" (STU), and thus there is a "Maturity" concern. This maturity concern is communicated in FHIR STU3 through a "FHIR Maturity Model" (FMM) evaluation number on each Resource and other parts. These FMM number indicate to the FHIR audience a stability and readiness for use. This is an important communication tool.

I am proposing within IHE that they reflect these FMM to the cover page of the IHE Profile so that the reader of the IHE Profile supplement understands the stability and readiness for use evaluation.

These FMM evaluations are only a construct for the STU and "Trial Implementation" phases. The FHIR Resources used must go to Normative, before the IHE Profile can go "Final Text".

So for example PDQm is based on Bundle, OperationOutcome, and Patient. All of which are at FMM level 5. So the title page of PDQm looks like:

Where as MHD is based on a broader set of  FHIR STU3 defined resources --  DocumentReference 3, DocumentManifest 2, List 1, Patient 5, Practitioner 3, OperationOutcome 5, and Bundle 5. FHIR Maturity Level (FMM) range 1-5

These updates to the IHE profiles will soon be seen in a CP ballot, and then published on the IHE web site. Right now they are being worked by the ITI workgroup.