Tuesday, October 10, 2017

Granularity of FormatCode

A Question was asked regarding FormatCode granularity, especially given that the IHE defined FormatCode vocabulary seem to be defining much smaller concept relative to HL7 defined FormatCode for C-CDA. Where the combined list is available in FHIR as a ValueSet of FormatCodes (updated in current build)

Important background :: Eating an Elephant -- How to approach IHE documentation on Health Information Exchange (HIE) and Healthcare Metadata

The FormatCode is there to differentiate 'technical format'. It is a further technical distinction more refined than the mime-type. So it is related to mime-type.

FormatCode is not a replacement for class or type. In fact it is very possible to have the exact same type of content available in Multiple-Formats. Including FHIR Documents in XDS

It is true that IHE defined FormatCodes tend to be one-per-Profile, where as all of C-CDA R2.1 is one FormatCode. This difference in scope seems like a very big difference, but is at the technical level not different. That is to say that the IHE XPHR profile defines a unique set of constraints on the format of the content, where as C-CDA R2.1 similarly defines a unique set of constrains on the format of the content.

This is a good time to explain that what IHE calls a "Profile" is commonly what HL7 would publish as an "Implementation Guide". Thus they are often very similar in purpose.

While it is true that XPHR has only one type (34133-9 Summary of Episode Note), where as there are a set of unique use-cases that are each unique clinical 'type' of document in C-CDA R2.1. This is a good example of why formatCode is not the same thing as 'type'. Type expresses the kind of clinical content, where as FormatCode expresses the technical encoding used.

So the FormatCode focuses on the technical distinction as a sub type on mime-type; and should be as specific as necessary to understand the Profile (or Implementation Guide) set of constraints.

HL7 could have defined a set of FormatCodes for the second-level deep technical format within their C-CDA. They didn't, I was not there to explain why they didn't. However this should, in theory, not be a problem. It simply means that at the technical encoding level there is only one FormatCode, rather than a set for each sub-format. I don't know how useful this would be, but I would be glad to help the committee understand the benefit.

I am the one that maintains these vocabulary. Not because I am a party to the creation of the vocabulary values, but simply because I am willing. If there are problems with any of these locations or values; please let me know. I hear rumor that there are problems, but until the problem is pointed out in specific detail, I can't fix it. This is especially true in FHIR where a Change Request (CR) must be filed.

Wednesday, September 27, 2017

#FHIR and Bulk De-Identification

Might be time to dust off a concept that hasn't been discussed for a while. But first let me explain two factors that bring me to that conclusion.

Bulk Data Access

The addition of a Bulk Data Access in #FHIR was a hot topic at the San Diego workgroup meeting. Grahame has explained it on his blog. What is not well explained is the use-cases that drive this API request. Without the use-cases, we have simply a "Solution" looking or a "Problem". When that happens one either has a useless solution, or one ends up with a solution that is used in appropriately. The only hint at what the Problem is a fragment of a sentence in the first paragraph of Grahame's blog article.
"... in support of provider-based exchange, analytics and other value-based services."
Which is not a definition of a use-case...  But one can imagine from this that one use-case is Public Health reporting, or Clinical Research data mining, or Insurance Fraud detection... All kinds of things that Privacy advocates get really worried about, with good reason.

De-Identification

There have been few, possibly unrelated, discussions of De-Identification (which is the high level term that is inclusive of pseudonymization and anonymization). These are also only presented as a "Solution", and when I try to uncover the "Problem" they are trying to solve I find no details. Thus again, I worry that the solution is either useless, or that the solution will get used inappropriately.

I have addressed this topic in FHIR before, FHIR does not need a deidentify=true parameter . Back then the solution was to add a parameter to any FHIR query asking that the results be deidentified. The only possible solution for this is to return an empty Bundle. As that is the only way to De-Identify when one as no use-case. 

De-Identification is a Process

De-Identification is a Process that takes a use-case 'need' (I need this data for my use-case, I want this data for my use-case, I need to re-identify targeted individuals, my use-case can handle X statistical uncertainty, etc). This De-Identification Process then determines how the data can be manipulated such that it lowers the Privacy RISK as much as possible, while satisfying the use-case need.  IHE has a handbook that walks one through the Process of De-Identification.

All De-Identification use-cases have different needs. This is mostly true, but some patterns can be determined once a well defined set of use-cases have been defined. DICOM (See Part 15, Chapter E) has done a good job taking their very mature data-model (FHIR is no where near mature enough for this pattern recognition). These patterns, even in DICOM, are only minimally re-usable. 

Most detailed use-cases need slightly different algorithm, with different variability acceptable.  For example IHE applied their De-Identification handbook to a Family Planning use-case and defined an Algorithm. Another example is Apple's use of Differential Privacy (a form of fuzzing). These are algorithms, but they are not general purpose algorithms. These examples show that each De-Identification algorithm is customized to enable a use-case needs, while limiting Privacy Risk. 

Lastly, Privacy Risk is never brought to zero... unless you have eliminated all data (the null set).

De-Identification as a Service

What I propose is that a Service (http RESTful like) could be defined. This service would be defined to be composable, thus it would be usable in a pipeline. That is the output of a #FHIR query (Normal, or Bulk) is a Bundle of FHIR Resources. This would be the input to the De-Identification Service, along with a de-identificationAlgorithm identifier. The result would be a Bundle of data that has been de-identified to that algorithm, which may be an empty Bundle where the algorithm can't be satisfied. One reason it can't be satisfied is that the algorithm requires that the output meet a de-identification quality measure. Such as K-Anonymity

The De-IdentificationAlgorithm would be defied using a De-Identification Process. The resulting Algorithm would be registered with this service (RESTful POST). Therefore the now registered algorithm can then be activated on a De-Identification request.

De-Identification Algorithm Consideration

So, what kind of Algorithms would need to be definable? Best is to look at the IHE Handbook which defines many data types, and algorithms that are logical.

For #FHIR. We would first need to an assessment of each FHIR Resource, element by element. Identify if this element is a Direct Identifier, Indirect Identifier (Quasi Identifier), Free Text, or Data.  This effort would best be done as the FHIR resources approach maturity. It could be represented within the FHIR specification, much like the _summary flag is represented...

Direct Identifiers -- Remove, Replace with fixed values, Replace with faked and random data, Replace with pseudonym replica, Replace with project specified identifiers, Replace with reversible pseudonym, etc...

Indirect Identifiers -- Remove, Fuzz, Replace, Generalize, Unmodify

Free Text -- Remove, Unmodify, interpret into codes removing unknown text

Quality Output -- Analysis of output to determine if it meets quality such as K-Anonymity

Just a hint of what it will take...

Conclusion

Plenty of good work to do, but the basis is well known.

Bulk Data -- De-Identification can be much more reliability (lowering Risk reliability) when the De-Identification process is executed on a Data-Set. Meaning the larger the number of Patients in the data-set, the more likely that one can protect Privacy. As this data-set approaches ONE, the risk approaches 100%.  This fact is usually the downfall of a de-identification result, they overlook how easy re-identification can be, especially where there is motivation and skill.





Monday, September 11, 2017

FHIR Connectathon of the IHE-MHD Profile

There were three brave soles willing to try IHE-MHD Profile here at the FHIR Connectathon.
  • Diego Kaminker (ALMADOC project / Argentina)
  • Fernando Campos (ALMADOC project / Argentina)
  • Simon Knee (NHS Digital / UK)
They did all the hard work. I just answered questions and such...

They had a specific goal: They wanted to test the IHE-MHD Profile against general purpose FHIR Servers. Specifically FHIR Servers that have not declared IHE-MHD Profile, but which do declare support for the fundamentals that IHE-MHD needs. This task is important as it is a way of testing how well I did at writing the IHE-MHD profile. How well did I stick close to FHIR (STU3), and how well did I inform the audience of the deviations.

I tried really hard to write IHE-MHD in away that a general purpose FHIR Server would work. However this was not the intended scope for IHE-MHD. The intended scope or IHE-MHD was as an API to an XDS, XDR, or XCA environment. Thus when I wrote IHE-MHD, I did have to constrain it in ways that a general purpose FHIR Server might not support.

This said, there was some big surprises.

I will summarize the reportout, It is available, with the actual XML examples and evidence.  

Test Procedure

1. Document Source: New Document (1 binary attachment included in the bundle)
2. Document Source: No binary attachment in the bundle – binary file referenced from external server
3. Document Consumer: Search by Filter Combination
1. Subject  by identifier
2. Document Class / Type
3. Document Creation Date Range
4. Document Consumer: Direct Binary Document Retrieval 
Notes: For this connectathon, we had not specified security / authentication requirements, like token / RBAC / etc.
Testing: Servers: with HAPI, Vonk, Grahame's server
Clients: plain REST with Chrome Restlet Client (Almadoc), Postman/Eclipse (LDP)

 Results

1 - During a ITI-65 "Provide Document Bundle", that carries both a Binary and a DocumentReference that points at that Binary, MHD expects that the DocumentReference.content.attachment.url would be "fixed up" by the server. That is when the server persists the Binary, and thus fixes up the Binary id from a URI (GUID) to a URL on the server, that new URL would be placed into the DocumentReference.content.attachment.url, which previously held the same URI (GUID) from the Bundle. This behavior does work when the FHIR Reference datatype is used, and did work in prior versions of FHIR (Prior to the Reference becoming a complex datatype vs just a flavor of URL), and the example in the FHIR specification shows this fixup behavior.
  • I created a CP to fix this See GF#13823
  • Recommend that in a Transaction, that URL fixup is done just like it is with Reference.
  • some zulip chat recommended that DocumentReference.content.attachment.data be used, but there are many problems with that. Most of all that it is very counter to the IHE XD* use-case need.
  • If this isn't resolvable, then the next revision of MHD might need to define ITI-65 as a FHIR Operation, rather than using the Transaction. I don't think this should be done until FHIR STU4. But I would entertain someone wanting to define this as an option. However I would remind everyone that IHE-MHD is not trying to use general purpose FHIR Servers, it is as an API to XD*.
  • One cold just do two transactions. One to create the Binary, then create the DocumentReference with a client fixedup URL. This can be done with general purpose FHIR Servers, but would be counter to the target for IHE-MHD being an API to XD*.
  • I will write a CP to MHD to make this more clear as an MHD imposed requirement of MHD servers.
2 - Already known issue #MHD_048 -- This was not a new issue, since we knew of it. But this issue was not obvious in the MHD text, so it caused issues. The default behavior for a general purpose FHIR Server is that one can't search against "contained" resources. In IHE-MHD we just left this as an open issue, we didn't try to solve it completely.
  • Turns out that one CAN query on contained resources
  • The bad news is that one can't tell if this will work from a servers conformance resource. 
  • I will write a CP that uses this feature that I didn't notice.
3 - Search on Patient.identifier -- An issue I simply didn't expose as much as I could have. This is a chained search, and will only work when the server you are querying against also hosts the Patient resources. For example: Imagine a FHIR Server that holds all of the DocumentReferences (the MHD server), and a different FHIR Server that holds the Patient resources (likely available via PDQm or PIXm). You can do a PIXm or PDQm query against this second server, and use the resulting URL in your MHD queries against the first server. This is just URL matching. But if you try to query the MHD server using Patient.identifier, that server will not know how to find the Patient.identifier.
  • This might be an important problem, or might not. It depends on deployment needs and capabilities.
  • I will likely write a CP to make this more clear in MHD

Conclusion

Overall this was really cool to do this kind of testing of the MHD specification. Especially since it resulted in some CR to FHIR, and likely a CP to IHE.

Friday, September 8, 2017

Remedial FHIR Consent Enforcement

I have been working with some of the teams wanting to do something with Privacy Consent and are coming to the FHIR Connectathon in San Diego. Here is a few stepping stones that I think are educational to move from zero to a reasonable set of Consent possibilities. Basic Consent is a necessary and powerful step:

Pre-conditions:

  1. Some form of Business Access Control are already in place to support basics of separating the kinds of things that various users (roles) are allowed to do; like Clinicians, or administrative staff, or billing staff, or cleaning staff, or dietary staff, etc. For example: Role Based Access Control (RBAC), or Attribute Based Access Control (ABAC) . This layer is responsible for separating those users that are allowed to Order drugs or procedures, vs those that are allowed to update clinical information, vs those that are given access to billing information, vs etc... An example of this is -- SMART-on-FHIR. 
  2. There is some Privacy Policy written: I will give a few for example purposes only. These are not complete, or comprehensive. They are defined well enough to illuminate the various stepping stones that I will outline below.
    * Explicit Consent -- if no consent is on file, then no data is shared outside the organization.
    * OPT-IN -- Patient has positively given consent to share without restrictions
    * OPT-IN with named organizations allowed access
    * OPT-IN with identified time/date range within which no data authored can be shared
    So, any Consent in the system must be from one of these patterns. Mixing of patterns, or going beyond these patterns is simply not allowed by the consent gathering application.
    **** Sorry, I have to use "OPT-IN" and "OPT-OUT", against my rule... but I do have them explained.
  3.  There is some consent gathering application that presents these Privacy Policies to Patients, and records the Consent ceremony as a FHIR Consent resource. I am not going to try to describe this ceremony. The user experience is very critical. The Patient must be well educated on the ramifications of their choices. I like the idea in GDPR where the consent rules presented to the Individual must be in human language terms that are specific to that person's language abilities. I am not short-circuiting this, but rather wanting to focus on the enforcement side.
    *** Note that if the patient changes their mind, this application handles this. Leaving only ONE active Consent resource. Thus there is no conflicts to resolve in real-time. If the patient wants to OPT-OUT after being OPT-IN; then a few solutions could happen. The existing record be updated to become Consent.status=rejected. Better for record keeping if a new Consent record is created with an OPT-OUT policy...

YES, I know that we all want more complex consents, we will get there. But for now we must get started. Stepping stones are important to the journey. Stepping stones are useful, but one does not stand on them for very long.

Some past articles to this point

Consent Enforcement Models

There are two major models today, very different.

Privacy Access Control decision engine

Privacy Access Control decision engine using OAuth. In this model, one offloads the Access Control decision to an OAuth authorization service. This is the model that HEART is focused on. Another example has been shown as "Cascading OAuth". The idea is that there is some OAuth authority (or a set of them) that focus on giving Access Control decisions purely along Privacy Consent lines. If this is 'cascaded' with the business OAuth Access Control decisions; then one has the combination of both.. I am not going to further explain this model in this blog article.

One could have an Access Control engine that is based on XACML...

In both of these solutions, the rules of the Patient specific Consent are not in any FHIR 'Consent' resource form. These solutions take care of steps 1-4. They only expose a 'decision' endpoint.

As such, their decision endpoint must be able to return complex obligations. PERMIT, but not to organization ABC, not the data authored during XYZ, etc... These in OAuth would be done with "Scopes", in XACML would be done with 'Obligations'. Which ever one uses, this is complex... and I would argue this is the same complexity one sees in the FHIR Consent resource today.

Interaction between FHIR Consent resource and Privacy Access Control decision engine

In both of these solutions, there might be a FHIR Consent that is simply there to indicate the endpoint of the Privacy Access Control service. This might be quite empowering. The Consent would not indicate anything other than the specific service to use. Thus enabling the Patient to choose from various Privacy Access Control services to use. The FHIR Consent resource would not indicate in any way what their Privacy rules might be.

I should model this.. and I might do it this week... but I want to focus on a solution that leverages the Consent resource... and this Privacy Access Control decision service solution hardly uses the Consent resource at all.

The FHIR Consent way:

Reminder we are working on Stepping Stones, and starting simple
* Explicit Consent -- if no consent is on file, then no data is shared outside the organization.
* OPT-IN -- Patient has positively given consent to share without restrictions
* OPT-IN with named organizations allowed access
* OPT-IN with identified time/date range within which no data authored can be shared

Lets first just work out the first two: No active consent on file, vs opt-in.

In the FHIR specification we already have examples of these:

A system can using FHIR query (RESTful) to determine if there is any Consent on file for a given patient. For the example below we look for if there is a OPT-IN consent for patient 'f001'

GET [base]/Consent?patient=f001&status=active&category=http://hl7.org/fhir/v3/ActCode#OPTIN
(((Note that one can't query on policyRule, so I propose either that be added, or that the OPTIN code goes into category. I seem to recall committee discussions that put it into category)))

If this above query returns ZERO result, then there is no OPTIN consent on file. Thus no access is granted. DONE
If there is a Consent, then we need to look to see if there are any Consent.provisions. If there are none, then we grant Privacy PERMIT access. DONE

The second stepping stone is to enforce the provisions.

Each provision will have a provision.type of either PERMIT or DENY. This means that if the constraints in the provision are matched, then the provision.type (PERMIT vs DENY) is to be enforced.

We have an example which is an OPTIN but denying access to a named organization.

Well, looking at this example, I see it is missing some critical parts that I just said would be there. The one provision this example has in it is that it is specific to an Organization named 'f001'. From the name of the example, it is clear this provision should have a .type="deny".

This kind of a provision can be enforced on the REQUEST, as that organisation is denied any access because of a Privacy Consent directive.

Date Range:

The Date Range provision is something that is much harder to enforce, as it really must look at the results that are about to be returned, and filter out any data that was authored within the given date range. I am not going to go deeper right now, but am pointing out that sometimes provisions can be enforced on the REQUEST side, denying a request or allowing a request with no further action. Some provisions require further work be done on the RESPONSE side.

Other articles:

Friday, September 1, 2017

MDS2 -- Revision Comment Opportunity

Updated: They moved the deadline for signup to September 15th, 2017

I have been involved in the original creation of the MDS2 (Manufacture Disclosure Statement for Medical Device Security).  This was back in 2004, before I was blogging...  The first revision was a major change to align with IEC 80001 - Risk Assessment to be used when putting a Medical Device onto a Network in 2010. The second revision to improve usability Major upgrade to MDS2 to align with IEC-80001 in 2013

It is being revised again, and there is a call for participation. Hurry, there is only a week to signup -- September 8th deadline.



This is intended to be a Security Disclosure statement from a Medical Device (any health software too) to someone purchasing. It is intended to explain the security capability, environmental expectations, and residual risk that would need to be managed by the purchasing organization. Security is a critical collaboration between the manufacture and the user of any system. This form is intended to enable this collaboration.

The Medical Imaging & Technology Alliance (MITA) is announcing an effort to revise the existing HIMSS/NEMA Standard HN1-2013 and develop it as an American National Standard. This standard consists of the Manufacturer Disclosure Statement for Medical Device Security (MDS2) form and related instructions how to complete the form. The intent of the MDS2 form is to supply healthcare providers with important information to assist them in assessing the vulnerability and risks associated with protecting private data transmitted or maintained by medical devices and systems.

If you are interested in participating in the development of this standard, please fill out the information requested below and return to Peter Weems (pweems@medicalimaging.org) no later than August 31, 2017 September 8, 2017.
  • Name
  • Organization Represented
  • Brief Description of Organization
  • Email Address
  • Telephone Number
  • Interest Category
  • Interest Category Descriptions

General Interest—Organization or individual that has an interest in the use of equipment included in the scope of this Standard, but neither produces nor uses it directly.

Government—Government agency or department that has an interest in the use of equipment included in the scope of this Standard. Please note that a government agency or department that uses this equipment should select the USER category.

Insurance--Insurance agency or department that has an interest in the use of equipment included in the scope of this Standard. Please note that an insurance agency or department that uses this equipment should select the USER category.

Producer—Manufacturer of equipment included in the scope of this Standard.

Testing Laboratory—Organization that tests equipment included in the scope of this Standard to established specifications.

Trade Association—Trade Association or society that represents the interests of manufacturers or users of equipment included in the scope of this Standard.

User—Organization (company, association, government agency, individual) that uses equipment included in the scope of this Standard.

User-consumer—Where the standards activity in question deals with a consumer product, such as lawn mowers or aerosol sprays, an appropriate consumer participant’s view is considered to be synonymous with that of the individual user – a person using goods and services rather than producing or selling them.

User-industrial—Where the standards activity in question deals with an industrial product, such as steel or insulation used in transformers, an appropriate user participant is the industrial user of the product.

User-government—Where the standards activity in question is likely to result in a standard that may become the basis for government agency procurement, an appropriate user participant is the representative of that government agency.

User-labor—Where the standards activity in question deals with subjects of special interest to the American worker, such as products used in the workplace, an appropriate user participant is a representative of labor.

Thursday, August 31, 2017

IHE IT Infrastructure Planning co-chair

I finally got caught... I have been elected co-chair of the IHE IT Infrastructure - Planning Committee.

I have been 'co-chair from behind' for too long, I knew I would eventually get caught. I tried to be elected co-chair in IHE once before, but had a campaign against me... by my peers at my employer at the time (GE Healthcare)...

First test will be the face-to-face meeting for New Work Item proposals October 16-17....

YOU have submitted your new work item proposal, right? Better hurry, the deadline is just 22 days away.


This is a friendly reminder that the IHE annual planning cycle has begun! The IT Infrastructure (ITI) and Patient Care Coordination (PCC) Domains are soliciting work item proposals for the 2017 Publication Cycle. The Call for Proposals  concludes September 22, 2017. This e-mail provides a brief overview the Call for Proposal process. For detailed information visit the IHE Call for Proposals Wiki site Are you new to the IHE International Call for Proposal Process?·       Watch the online webinar to learn more about submitting a proposal and the evaluation process. Ready to participate in the Call for Proposals?
Interested parties are invited to submit a brief proposal (form attached) for new IHE Profiles and/or White Papers to be considered for development in the new Publication Cycle. Proposals should be entered using the attached Brief Profile Proposal template.  They should address the following:
  1. What is the problem and how does it look in practice?  (Describe the use case)
  1. How should things look in practice if it were fixed?
  1. What specific standards could be used to solve the problem, if known?
  1. If possible, give some indication of the business case for solving the problem (e.g., quantify the cost).
It is strongly recommended that the proposal include the name of an editor for the proposal should it be selected for development.
Email your completed brief IHE Proposal template to the corresponding email address listed below before September 22, 2017 at 11:59pm CDT. Proposal templates can also be found online at: ftp://ftp.ihe.net/DocumentPublication/DocumentTemplates/Profile%20Proposal-Brief%20and%20Detailed/IHE_Profile_Proposal_Template-Brief.docx·       ITI Domain Proposals: Daniel Berezeanu at: daniel.b...@readycomputing.com, ITI Planning Chair·       PCC Domain Proposals: Amit Popat at: Am...@epic.com, PCC Planning Chair What happens if my proposal is selected?The IHE ITI and PCC Planning Committee will review each Brief Proposal and select a "short list" of proposals for further consideration.  Detailed Profile Proposals are sent to the IHE ITI or PCC Technical Committee for evaluation and returned to the Planning Committee for a final vote.  Please visit the Wiki for detailed information about the IHE Call for Proposals.    Questions or Comments? 

Tuesday, August 29, 2017

IHE on FHIR ... STU3

Integrating the Healthcare Enterprise (IHE) has been busy creating Profiles that leverage the new and exciting FHIR specification. The concept of Profiling in IHE has been around for just about 20 years. The concept of Profiling is not IHE invention, I first encountered it back in the 1980s with the original set of Internet Protocols. See the IHE FAQ for some nice description of what/who IHE is.

IHE publishes their profiles on http://www.ihe.net

IHE subset of Profile on FHIR can be found on the IHE wiki FHIR list

An IHE Profile is equivalent to a FHIR Implementation Guide. They take a specific use-case, define Actors, define Transactions, and define Options; From this a set of interoperability constraints are defined for each Actor within that Profile.

These constraints can be coded as a FHIR set of conformance resources. For now, if a FHIR Conformance resource is available it will be published on the IHE FTP site in the Implementation Material. There are efforts within IHE to modernize beyond an FTP site, and to provide more complete FHIR conformance publication on a FHIR Profile Registry.

IT Infrastructure (ITI) domain

The IT Infrastructure profiles are published on the IHE Technical Framework web site and described on the IHE Wiki

Companion

Patient Care Coordination (PCC) domain


Patient Care Coordination profiles are published on the IHE Technical Framework, and described on the IHE wiki.

Radiology Imaging (RAD) domain

Radiology Imaging profiles are published on the IHE Technical Framework, and described on the IHE wiki.

Quality, Research, and Public Health (QRPH) domain

  • Mobile Retrieve Form for Data Capture (mRFD) describes the exchange of context data to allow a seamless form launch with supporting clinical context
  • Vital Records Death Reporting (VRDR) defines a Retrieve Form for Data Capture (RFD) content profile that will specify derivation of source content from a medical summary document. by defining requirements for form filler content and form manager handling of the content

Pharmacy

The Pharmacy group is working toward a Profile, but it is not yet fully developed. 

Saturday, August 26, 2017

Book: Healthcare Information Technology - 2nd Edition

I received my copy of the book to which I contributed a chapter.  Healthcare Information Technology Exam Guide for CHTS and CAHIMS Certifications 2nd Edition. I also contributed to the First edition back in 2012. I needed only to do some minor fixup in my chapter. The list of contributors is long and very exclusive. I am honored to be among them.  

I am very pleased with my chapter in the book, 32 pages: "Interoperability Within and Across Healthcare Systems". 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.

Gila also has chapter on Risk Assessment and Management. She didn't have as smooth of an editorial experience as I did.

I expect an update in a year to add chapters on FHIR. There is a very small mention of FHIR in this book, as it was written back during DSTU2. Excitement around FHIR, but not much was clear; and FHIR is not yet the topic in the exams.

Friday, August 25, 2017

Malicious e-mail addresses

Last month I blogged about E-mail addresses -- Remedial and realistic

My point for that post was that it is important to have a agreed subset of the full character encoding allowed by the e-mail address specification. This subset helps to enable Interoperability, by having everyone make sure that they can send-to, and receive-from, an address fully encoded. This problem came up when some systems had trouble with the apostrophe, such as is needed (desired) for people names like "Fred O’Donnell". That is, a sending HISP didn't allow the user to send to a valid email address because it contained an apostrophe.

The subset of characters I give in  E-mail addresses -- Remedial and realistic, is a first line of defense. As the email standard allows a very nasty set of characters, especially if one just puts double-quote around the malicious string. So, I start with the sub-set I defined in the above article.

Unfortunately apostrophe is within that sub-set...

Security Considerations

So as helpful as apostrophe is for people names like "Fred O’Donnell", it is problematic as it can be used in malicious ways. This because the apostrophe is the single-quote. Here are some general email address attack articles:
More likely a javascript injection, like explained https://security.stackexchange.com/questions/106972/javascript-injection-in-email-address-as-username  Where an example that is not all that malicious, but is illuminating (okay, it includes character '=' which is not in the subset).
foo'onclick='alert'foo='@example.com

Direct Threat Analysis

There is a Threat Model within the Direct Project. I lead the sub-group that wrote this Threat Model.  The email address as a vector of attack is a situation where you are a Recipient, and the sender is malicious. The sender is trying to tell you that the sender email address is X, where that email address has malicious content.

The good news for Direct Project, is that the sender (you are the recipient) must have signed the email from certificates chaining to YOUR trust store. Thus for this to work, you must be trusting someone who is being malicious. As long as you carefully process up to signature validation, this eliminates the greater Internet attackers. 

Thus from the Treat Model, we are most worried about Arch 8, 9, and 10.

It still leaves a Trusted partner as the attacker, but they will get away with this only once before they are found-out and their trust revoked. Thus it better be really valuable attack for them to be motivated to try. So, the likelihood that they would try is very low.

Conclusion

Thus the use of apostrophe (single-quote) does add more risk, over the remedial set, that risk is low because of some mitigating factors (S/MIME, and Trust-Store).

However it is important to have a constrained email address character set, that everyone can FIRST check incoming (or outgoing) addresses against. This because it is far more simple to do simple string validation, before one starts to do operations on that string. Thus a simple string validation would reject a malicious inbound email, and there would be no opportunity to go deeper.

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
Episode
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

[base-url]/MHD_RetrieveDocument/<documentUniqueId>?repository=<repositoryUniqueId>&community=<homeCommunityId>


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.

Conclusion

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 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.