clair054

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

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

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

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

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

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

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