clair054

Gathering Privacy Consent is never easy. A Patient, when they are healthy, has no interest in giving Consent for future actions. Mostly because they don't want to admit they might get sick in the future. Secondarily because they don't want to do unnecessary paperwork. Realistically, they just want healthcare to work, and not get in the way of them getting the best treatment. This is why many exchanges are moving toward an 'implied consent' that allows a patient to explicitly withdraw their authorization, but in the absence of any action by the Patient the data would be shared for "Treatment" purposes. This default behavior is only applied to "Treatment", not "Research" or other. That said, Consent is still sometimes needed. It might be needed because the organization uses a Default of not sharing. It might be because the patient has sensitive health topics that require explicit consent to release. It might be because the patient has With...

I have been unable to attend HL7 WGM for a year, a problem that is now better .  This means that when I attended the FHIR Connectathon 14, prior to the HL7 Workgroup Meeting in San Antonio TX , I was shocked to experience the new FHIR Connectathon. This is good change on many levels. The others from the FHIR core-team have seen the changes over-time, so the transition is not as shocking as it was for me. In past years, FHIR connectathon was more focused on people trying to use the core FHIR specification. This resulted in discussions to help understand the core concepts, core interaction models, core vocabulary, core data-types, and core Resources. This also resulted in corrections to the FHIR specification, so that future people would understand right from the specification. Other discussions were on toolkits, and how to make the toolkit better. There were discussions on how to implement a general purpose FHIR server. There were discussions on how to implement clients, starting ...

IHE is still relevant in a FHIR world. But FHIR has changed the world, and IHE needs to adjust to this new world. Profiling is still needed The concept of profiling FHIR is still needed. The difference today is that FHIR is ready and instrumented to be Profiled. It even has a set of Profiles coming from HL7. This is not a threat, this is an opportunity for IHE. IHE has a set of 10 profiles today  (MHD, PDQm, PIXm, mACM, (m)ATNA, CMAP, GAO, RECON, DCP, MHD-I). These mostly are basic profiles, where a basic profile is not a complex profile, one that simply points to a FHIR Resource as the solution for a defined problem. This is helpful to the audience, but not adding much value. It is this lack of value-add that makes what IHE has done today with FHIR Profiling to seem to conflict with core FHIR. Given that FHIR needs to be Profiled is a fact. A Profile is fundamentally a set of constraints and interactions applied to a Standard, to achieve a specific purpose. This is just as true wi...

How does one put a FHIR Document into XDS? How does one find a FHIR Document in XDS? Both questions are asking very similar things. The key is the XDS fundamental metadata element mimeType . Let me explain... XDS, more broadly the whole Document Sharing family, including XDS , XCA , XDR , XDM , and MHD . With a set of more narrow IHE Profiles in DSUB , MPQ , SeR , and MU . To learn more on Document Sharing, start here:   Eating an Elephant -- How to approach IHE documentation on Health Information Exchange (HIE) So the Document Sharing family is a Content Agnostic mechanism for sharing Patient specific Documents. Where the only thing that fixed is that this is an exchange for  Patient Specific content -- so all the documents must be about a specified patient Document format -- so it is not a REST server. Metadata -- all the other metadata in XDS is there to help with searching or navigating through the documents than have been shared to find the right one to retrieve. Initiall...

It is so good to see NIST bring Privacy out of the closet . I promoted the "hints of Privacy" that are deep within NIST 800-53, but always needed to enhance with a harmonized set of   Privacy Principles as a Framework , Privacy Impact Assessment, and Privacy Risk Management. For example my article on  Privacy and Security in Designing an mHealth Application  and How to apply Risk Assessment to get your Security and Privacy and Security requirements .  I lead my previous employer to create a "Design Engineering Privacy and Security Framework". This leveraged the NIST frameworks, especially SP 800-53, but we added an overall framework to bring in Privacy as equal goal to Security and Safety. Then added Privacy Impact Assessment to discover and manage risks to Privacy. Bringing in Safety is important in Healthcare, especially Medical Devices, as balancing the Risk Management plans between the three is important to get all three optimally reduced with all as low as poss...