clair054

There is a general misunderstanding that the BPPC (profile of CDA for capturing patient privacy consent) profile is only useful for XDS (document based Health Information Exchange) and XCA (Federation of document based Health Information Exchanges of various types) environments. The reality is that it is most valuable when used in XDS and XCA; but it has an important role to play in push models like XDR profile and XDM (publication on removable media and zip based packages) profile. It is a different value... BPPC could apply to any topology of exchange. The reality is that BPPC is only ever needed when ONE organization captures consent that applies to ANOTHER organization. When no need to expose Privacy Consent Most Privacy Consents, by number of Privacy Consents captured,  are an authorization to release within that Enterprise. This is completely local issue that doesn't need to be made visible beyond those systems involved in the capture and enforcement of that P...

Security is a Risk domain, with the sub-domains of risk being risks to Confidentiality, Integrity, and Availability. Lately the failures have been in the sub-domain of Availability. First it was the Hollywood Presbyterian Medical Center in LA. Their data got encrypted by malware and held hostage to a $17,000 ransom. Now it is Lukas Hospital in Germany . Many people focus their security efforts on the “Confidentiality” aspect of Security. I don’t know if either the LA or German hospital failed to protect the Confidentiality, but the attack they fell victim to could easily have happened to a database that was perfectly protected against Confidentiality risks. The database might have been encrypted by the database software with very good management of that encryption key. This protection would not have prevented the database from being Encrypted AGAIN. Yes, an encrypted system can be encrypted again. It is possible that the databases were fully readable in the form that the malware enc...

Two independent projects this week sent to the FHIR mailing list their diagrams of how they are using FHIR as an API to classic XDS environments. I thought both diagrams were fantastic illustrations of the power of the MHD, PIXm, and PDQm profiles . The power of using FHIR as a simplifying API to classic environments. These diagrams are not only technically wonderful, but also beautiful. I have asked for permission to republish these diagrams. They are not my diagrams. From the Jose Maria Olmo Millan working on the prevvy project, writes: We are using a similar approach for our patient centric platform ( prevvy.co ). We have developed a FHIR/IHE server and we store CDA and FHIR documents in the same IHE infrastructure using IHE metadata capabilities.  .. FYI, this is our FHIR/IHE/DIRECT architecture From Ioana Singureanu working on SAMHS BHITS project writes: I'm supporting the SAMHS BHITS project to create a standard-based, open-source patient portal application (My Health Compas...

This is the notice of Ballot on the updated Profiles from IHE on MHD, PDQm, and PIXm. This ballot to review and approve the updates so that they can be formally tested at EU Connectathon. Please review, and provide constructive comments. In general these profiles are thinner than previous as the FHIR specification in DSTU2 is far more readable and complete. Thus there is less description and 'profiling' that IHE needs to do. As such these IHE profiles rely more on the good readability of the FHIR specification in DSTU2. Other Blog articles on FHIR Topic John Updated at 9:37am Central time... Timeline:   Ballot is open from today through  Wednesday, March 15, 2016 Submitting Comments:   Please use the attached spreadsheet to compile your comments.  Submit the completed spreadsheet to ITI Comments mailing list ( iticomments@googlegroups.com ). Voting Rights Reminder:  Providing comments on CP ballots is a great way to obtain/retain your organ...

A web-server , especially hosting FHIR , must choose the response carefully when an Access Denied condition exists. Returning too much information may expose details that should not be communicated. The Access Denied condition might be because of missing but required Authentication, the user is not authorized to access the endpoint, the user is not authorized to access specific data, or other policy reasons. To balance usability of the returned result vs appropriate protection, the actual result method used needs to be controlled by policy and context. Typical methods of handling  Access Denied used are: Return a Success with Bundle containing zero results – This result is indistinguishable from the case where no data is known. When consistently returned on Access Denied, this will not expose which patients exist, or what data might be blinded. This method is also consistent with cases where some results are authorized while other results are blinded.  Return a 404 “Not Fou...

The current practice is ‘in person proofing’… as the first encounter with the patient is as a … patient… Now many patients are not at their ‘best’ when they first appear, so the understanding of their identity evolves over the first hours and days and weeks. Thus in healthcare practice we often know the patient by many identifiers that we have either merged or linked. And there are cases where a merged or linked patient needs to be unmerged or unlinked. Very messy business. Ultimately the patient gets billed for the services they have received, and the identity gets confirmation that they paid, thus stronger. This is just a discussion of the patient id, not the patient as a user.  See my topics on Patient Identities. Patient as User The patient as a User usually starts with this in-person relationship. Most often the healthcare organization uses the identity they know, and the billing address to send them postal-mail (covered by strong fraud laws). This kickstarts an online confir...