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 http://ihe.net/Technical_Frameworks. 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:
  • prettyandsimple@example.com
  • very.common@example.com
  • disposable.style.email.with+symbol@example.com
  • "very.unusual.@.unusual.com"@example.com
  • "very.(),:;<>[]\".VERY.\"very@\\ \"very\".unusual"@strange.example.com
  • #!$%&'*+-/=?^_`{}|~@example.org
  • "()<>[]:,;@\\\"!#$%&'-/=?^_`{}| ~.a"@example.org
  • user@[IPv6:2001:DB8::1]
Internationalization examples
  • Latin alphabet (with diacritics): Pelé@example.com
  • 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 DirectTrust.org, 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. 
  • simple@example.com
  • very.common@example.com
  • also-common@example.com
  • remedial-combinations_with.all@example.com

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

Internationalization

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.

Conclusion

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 ("?")

   The <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, <COMMA>,
   <HYPHEN>, <DOT>, <EQUALS>, and <SPACE> rules are defined in
   [RFC4512].

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