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? 

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

• Mobile access to Health Documents (MHD) a profile on DocumentReference and DocumentManifest to provide a HTTP REST and Mobile application friendly API for the usecases profiled in XDS, XDR, and XCA. The MHD profile may be used as an API to these Document Sharing infrastructures, or may be used alone.
• Patient Demographics Query for Mobile (PDQm) a profile of the FHIR Patient resource for simple lookup and reference. Following the functionality requirements profiled in PDQ (HL7 v2), and PDQv3 (HL7 v3)
• Patient Identifier Cross-reference for Mobile (PIXm) an operation profile for retrieving just cross-referenced identifiers for a given patient
• RESTful Query to ATNA a profile on AuditEvent for query and reporting.
• Mobile Alert Communication Management (mACM) a profile on Communication for alert notifications
• Mobile Care Services Discovery (mCSD) provides a RESTful interface to discover Care Services: Organization, Location, Practitioner, and Health Services
• Mobile Cross-Enterprise Document Data Element Extraction (mXDE accesses data elements extracted from shared structured documents
• Non-patient File Sharing (NPFSm) provides a RESTful interface enable sharing of non-patient files such as clinical workflow definitions, domain policies, and stylesheets

Companion

• Internet User Authorization (IUA) a profile of OAuth for use with HTTP REST access

Patient Care Coordination (PCC) domain

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

• Clinical Mapping (CMAP) supports mapping to and from clinical terminologies
• Guideline Appropriate Ordering (GAO) Supplies a mechanism by which EHR and departmental systems can evaluate orders to determine whether these orders conform to guidelines.
• Reconciliation of Clinical Content and Care Providers (RECON) Provides the ability to communicate lists of clinical data that were reconciled, when they were reconciled and who did the reconciliation using CDA® constructs and FHIR® Resource attributes
• Dynamic Care Planing (DCP) Profile provides the structures and transactions for care planning, sharing Care Plans that meet the needs of many, such as providers, patients and payers.
• Dynamic Care Team Management shares information about a patient's care teams
• Query for Existing Data for Mobile (mQED) queries for clinical data elements, including observations, allergy and intolerances, conditions, diagnostic results, medications, immunizations, procedures, encounters and provenance

Radiology Imaging (RAD) domain

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

• Standardized Operational Log of Events (SOLE) stores and retrieves logs of operational events (patient arrives, scan complete, etc)

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. 

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.

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:

•  http://www.unixwiz.net/techtips/sql-injection.html 
• https://www.quora.com/Internet-Security-Is-there-any-way-for-an-email-address-to-be-used-as-a-vector-for-a-sql-injection-or-xss-attack 

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.

My other articles on Direct

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.

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.

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.