clair054

I just became aware of a Whitepaper published by IHE Europe in January on " IHE perspective on EU GDPR ". I did not have a hand in writing this whitepaper. It looks good to me. My evaluation only on the Security & Privacy capabilities IHE offers, not on GDPR interpretation. All of the IHE profiles available to support security and privacy are outlined on this IHE page . Their whitepaper does not mention the Document Digital Signature (DSG) profile, or the Document Encryption (DEN). Both would only have a supporting role in GDPR compliance. I mention them only for completeness. Other IHE Europe publications Their Conclusion The examples discussed [above] highlight the complexity of applying the GDPR to processes in health care and how the requirements are interwoven with IHE Profiles. The good news is that even today IHE Profiles provide solutions by combining security and privacy specific IHE Profiles such as ATNA, IUA, XUA, BPPC and APPC with the Profiles focused on in...

Everyone is frustrated by duplicate data. In Healthcare space there is a fresh cry from Clinicians around their frustration at seeing duplicate data. On the bright side, this means that they are now getting data. So we in the Interoperability space MUST be succeeding with all the efforts to create Health Information Exchanges, and to enable Patient to access their data. We standards geeks are quickly put in our chair because we failed to prevent this duplicate data problem... Well, yes and no. Each standard we created included mechanisms that are there specifically prevent duplication. However when those standards are used, shortcuts are taken. It might be a shortcut in the software development. It might be shortcuts in deploying a network. It might be shortcuts in deploying a network of networks. It might be a shortcut when the data was created. It might be a shortcut when the data was exported. It might be a shortcut when the data was 'Used'... But it is shortcuts, that is wh...

I will be giving a face-to-face tutorial on the topic of "IHE on FHIR" at both HL7 Workgroup meeting in Cologne, May 12-18 FHIR Dev Days in Boston, June 19-21   So, if you are in Europe, sign up for the tutorial at HL7 workgroup meeting .  If you are in the USA, sign up for the tutorial at FHIR Dev Days.   There is a difference in time available to me. At the FHIR Dev Days I will need to focus only on the IHE Profiles available from IHE that leverage FHIR . Where as at the HL7 meeting I will also be able to discuss the overall relationship between HL7 and IHE  and the IHE Profiles available from IHE that leverage FHIR . Here are the IHE profiles that leverage FHIR today... IT Infrastructure Add RESTful Query to ATNA  - where a query on FHIR AuditEvent interrogates all of the audit log recorded in  Audit Trail and Node Authentication  Audit Repository Internet User Authorization  - defines a plugable basic OAuth interaction to enable app and user a...

The Patient is NOT the center of existing Health Information Exchange. Yet, the Health Information Exchange exists for the sole purpose of treating that Patient. These two factual statements are completely opposite. How can they both be facts? The patient does not feel like the center. It is all about Experience. In agile terms "User Experience". If the user does not feel the experience they want, then they are NOT happy. Does not matter how hard the product is trying to make the user happy. If hey are not feeling it, then they are not happy. The Health Information Exchanges today have an existing Architecture. This architecture is a good architecture. Yes I am speaking about ALL of the various architectures of Health Information Exchanges. Centralized, Distributed, Federated, and discombobulated. They all are good architectures. The architecture is not the problem. Yet, our healthcare leadership keeps looking for a new technical architecture to solve this problem.  I assert ...

IHE is currently working on a "Handbook" intended to instruct an XDS Affinity Domain, or Community (XCA), or MHD community on how to structure their requirements on metadata . This effort is long overdue, as IHE has relied on the communities to figure this out themselves. More communities have failed than have succeeded. I am just very grateful that they keep trying. Mostly they keep trying because the most basic query is just asking for all documents available for a given Patient. This is necessary, but not sufficient. Let me explain the next level of Document Sharing (XDS, XCA, MHD) Query As part of the metadata handbook discussion, Charles has clarified in a very elegant way a " Best Practice " for leveraging the XDS/XCA/MHD Query, vs local processing of the resulting document entry/reference Metadata, to achieve the best results. This "Best Practice" should be used, but I know it is not used. The main reason it is not used is because it was never expl...