clair054

In close to 30 years as a professional engineer, I find that some people are natural software architects, while others expert software engineers struggle with architecture. There seems to be a characteristic of those people that can take a step back and 'architect'.  Is this learned? I suspect anything can be learned. If so, what is the critical catalyst that triggers and feeds that learning? I seem to run into people given the role of software architect, when they are more a subject-matter-expert on a specific project.  On that project they are superior to all else, but they are not an architect. I seem to run into people who really want to become a software architect, but can't seem to hack it. I also see some excellent Architects get pulled into Management where they waste away. Or worse they end up Program Managers, simply because they are the only ones that know all the moving parts. I am not saying everyone should strive to be a software architect, or that it is the p...

I am comforted to hear from many Healthcare leaders that their advice to the new USA administration is to continue the progress we have. Including continued support for Exchange, Direct, and CDA; while encouraging FHIR. I am VERY MUCH agreeing with these. Changing from these directions would kill much momentum and disrupt healthcare in a bad way.  There are others encouraging him to not kill Obama Care. I suspect he won't kill it but re-brand it. Or to create a single payer system . There are some things in Healthcare that are broken in ways that are just nuts. Given that the new Trump administration is likely to be willing to do things that are against the norm for politics, I think we should recommend that these broken things be fixed. Because fixing them means radical change, and it appears that radical change is what we are in for over the next four years. I will note that this was not my vote, and I am scared as hell. But it is a forgone conclusion, so we either stick our head...

The IT Infrastructure workgroup has selected their work items for next year. It consists of 4 new work items, only one of which is a brand new concept. That is, the other three are re-casting of old use-case needs into a http RESTful world. There is only one of these new work items that is not FHIR based. Healthcare Provider Directory -- IHE has two standards: Care Services Discovery (CSD), which has been adopted in several countries as a way to manage health worker and health facility data and Healthcare Provider Directory (HPD) which has limited adoption. CSD and HPD are SOAP-based web services and are not compatible with systems deploying RESTful clients and servers Patient-Centric Data-Element Location Services -- This is a profile of profiles, addressing the use-case need for a element level perspective (i.e. FHIR) of the data held within Documents in a Document Sharing infrastructure (i.e. XDS). This profile of profiles will show how to bring various profiles together to add an ...

I have gotten into multiple discussions  on the  topic of TLS 1.0. The result always seems to end up in no change of anyone position. There are a few agreed to points: SSL is fully forbidden.  TLS 1.2 is best TLS 1.0 and 1.1 are not as good as 1.2 Bad crypto algorithms must not be used (e.g. NULL, DES, MD5, etc) However some people are taking a policy decision that TLS 1.2 is the ONLY protocol. They are allowed to make this policy change, as long as it doesn't impact others that can't support that policy I have no problem with a war on SSL. I simply have a realist view on available implementations of TLS 1.2 on platforms where software is available to run. I would love for everyone to have the latest protocols, and for those protocols to be perfectly implemented. Reality sucks! Standards Recommendation on TLS What is expressly frustrating is that they point at standards as their justification. YET those standards explicitly allow use of TLS 1.1 and TLS 1.0 in a very speci...

I have changed employer. From GE Healthcare to By Light. Both companies offer their employees Health Insurance through United Healthcare I 'figured' that I could continue to use my existing United Healthcare web login account to access both the old and new insurance account. Turns out this is not the way they do it. They want me to create a new web login for the new insurance account. I guess this is logical, and clean for them. It is inconvenient for me to have two accounts at the same web site, but it is also possible. Chat session with UnitedHealthcare Paula B. has entered the session. JOHN MOEHRKE: Hi Paula. Paula B.: Thank you for being a loyal member with UnitedHealthcare. How can I help you today? Paula B.: How are you? JOHN MOEHRKE: I have changed employer JOHN MOEHRKE: My new Employer also uses UHC JOHN MOEHRKE: so, how do I get my web login to recognize this new account? Paula B.: I understand. For the website to recognize your new account through your new employer...

This is a use of the IHE published De-Identification Handbook against a use-case. The conclusion we came to is an important lesson, that sometimes the use-case needs can't be met with de-identification to a a level of 'public access'.  That is that the 'needs' of the 'use-case' required so much data to be left in the resulting-dataset, that the resulting-dataset could not be considered publicly accessible. This conclusion was not much of a problem in this case as the resulting-dataset was not anticipated to be publicly accessible. The de-identification recommended was still useful as it did reduce risk, just not fully. That is that the data was rather close to fully de-identified; just not quite. The reduced risk is still helpful. Alternative use-case segmentation could have been done. That is we could have created two sets of use-cases, that each targeted different elements while also not enabling linking between the two resulting-datasets. However this wa...