clair054

Today the IHE ITI Technical and Planning committees approved the Document Digital Signature (DSG) Profile be moved into Final Text. This Document Profile defines a way to support Digital Signatures, including when those Documents are managed in a Document Sharing infrastructure. This DSG Profile is referenced in many places where adding a Digital Signature to a document would be beneficial, such as Consent, Legal Evidence, etc. There is more interest in digital signatures driven by some Anti-Fraud use-cases . I think there will be more interest driven by Patient Authored content. The main problem with Digital Signatures is NOT the standards, it is the Policies and overhead in issuing proper Digital Identity (PKI). Once there are Digital Certificates issued for the purpose of Digital Signatures, then there are many use-cases that can be enabled. However that first justification of the costs is very hard to do, and somehow combining justifications just never seems to happen. The Documen...

IHE is creating many Profiles using FHIR . Given that FHIR is still "Standard for Trial Use" (STU), and thus there is a "Maturity" concern. This maturity concern is communicated in FHIR STU3 through a "FHIR Maturity Model" (FMM) evaluation number on each Resource and other parts. These FMM number indicate to the FHIR audience a stability and readiness for use. This is an important communication tool. I am proposing within IHE that they reflect these FMM to the cover page of the IHE Profile so that the reader of the IHE Profile supplement understands the stability and readiness for use evaluation. These FMM evaluations are only a construct for the STU and "Trial Implementation" phases. The FHIR Resources used must go to Normative, before the IHE Profile can go "Final Text". So for example PDQm is based on Bundle , OperationOutcome , and Patient . All of which are at FMM level 5. So the title page of PDQm looks like: Where as MHD is base...

NO! This is a false understanding. FHIR has no security model . And this is a good thing . FHIR is designed first and most important as a data model with a few expected interaction models (REST, Messaging, Document). There is expectation that many security models exist , and application of those security models does not impact the most important priority of getting the data model correct. This is especially exercised with REST, but is not limited to REST. REST is just used as a most likely first interaction model, and one that is understood to drive for a good transport agnostic data model. There are many workgroups working on specifications for how to apply OAuth to FHIR REST, but these are not fundamental to FHIR, they are alternatives. There are various variations of OAuth as well, those that might be more Patient centric , those that might be more enterprise centric, and those that might be cross-enterprise centric . There are work on OAuth scopes . There are others that are worki...

In various conversations on Consent , including #FHIR Consent, discussions often get mixed-up because we use the terms "OPT-IN" and "OPT-OUT". These terms are trouble. We need to stop using “OPT-IN” and “OPT-OUT”. I want to propose a set of terms. I will never get everyone to stop using opt-in and opt-out, but where better terms can be used, I propose better terms. Better, as in, more descriptive and accurate communications. The reason is that these terms can mean very different things based on what the person listening is thinking. They can mean a consent ‘model’ or they can mean a consent ‘state’ or they can mean an 'action' by the patient. Especially confusing because there is a possibility for all thee to be the same and not the same . State Model -- In this model we look to consent as a state-diagram , also called a  finite-state-machine , or a directed-graph . In a state-diagram is made up of a finite number of ' states ' diagrammed as circles,...