clair054

Might be time to dust off a concept that hasn't been discussed for a while. But first let me explain two factors that bring me to that conclusion. Bulk Data Access The addition of a Bulk Data Access in #FHIR was a hot topic at the San Diego workgroup meeting. Grahame has explained it on his blog . What is not well explained is the use-cases that drive this API request. Without the use-cases, we have simply a "Solution" looking or a "Problem". When that happens one either has a useless solution, or one ends up with a solution that is used in appropriately. The only hint at what the Problem is a fragment of a sentence in the first paragraph of Grahame's blog article. "... in support of provider-based exchange, analytics and other value-based services." Which is not a definition of a use-case...  But one can imagine from this that one use-case is Public Health reporting, or Clinical Research data mining, or Insurance Fraud detection... All kinds of t...

There were three brave soles willing to try IHE-MHD Profile here at the FHIR Connectathon. Diego Kaminker (ALMADOC project / Argentina) Fernando Campos (ALMADOC project / Argentina) Simon Knee (NHS Digital / UK) They did all the hard work. I just answered questions and such... They had a specific goal: They wanted to test the IHE-MHD Profile against general purpose FHIR Servers. Specifically FHIR Servers that have not declared IHE-MHD Profile, but which do declare support for the fundamentals that IHE-MHD needs. This task is important as it is a way of testing how well I did at writing the IHE-MHD profile. How well did I stick close to FHIR (STU3), and how well did I inform the audience of the deviations. I tried really hard to write IHE-MHD in away that a general purpose FHIR Server would work. However this was not the intended scope for IHE-MHD. The intended scope or IHE-MHD was as an API to an XDS, XDR, or XCA environment. Thus when I wrote IHE-MHD, I did have to constrain it in wa...

I have been working with some of the teams wanting to do something with Privacy Consent and are coming to the FHIR Connectathon in San Diego. Here is a few stepping stones that I think are educational to move from zero to a reasonable set of Consent possibilities. Basic Consent is a necessary and powerful step : Pre-conditions: Some form of Business Access Control are already in place to support basics of separating the kinds of things that various users (roles) are allowed to do; like Clinicians, or administrative staff, or billing staff, or cleaning staff, or dietary staff, etc. For example: Role Based Access Control (RBAC), or Attribute Based Access Control (ABAC) . This layer is responsible for separating those users that are allowed to Order drugs or procedures, vs those that are allowed to update clinical information, vs those that are given access to billing information, vs etc... An example of this is -- SMART-on-FHIR.  There is some Privacy Policy written: I will give ...

Updated: They moved the deadline for signup to September 15th, 2017 I have been involved in the original creation of the MDS2 (Manufacture Disclosure Statement for Medical Device Security).  This was back in 2004, before I was blogging...  The first revision was a major change to align with  IEC 80001 - Risk Assessment to be used when putting a Medical Device onto a Network  in 2010. The second revision to improve usability  Major upgrade to MDS2 to align with IEC-80001  in 2013 It is being revised again, and there is a call for participation. Hurry, there is only a week to signup -- September 8th deadline. This is intended to be a Security Disclosure statement from a Medical Device (any health software too) to someone purchasing. It is intended to explain the security capability, environmental expectations, and residual risk that would need to be managed by the purchasing organization. Security is a critical collaboration between the manufacture and the us...