Building more Software Architects

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 pinnacle.

I ask, because I think there are far too few true architects today.  This more true as we enter the system-of-system-of-system world of Internet-of-Things (IoT). Being able to think short-term, long-term, horizontal-scale, depth-scale, modular, privacy, security, safety, reliability, continuous deployment, etc. All while being able to pivot when new information appears...

What are your top characteristics of a real software architect?
How did they get that way?

New Administration --> Fix Healthcare Problems

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 heads in the sand and hope our ass survives, or we do what we can to make the best of the situation.

My three things that are broken and need radical fix:

1. Patient Identifier -- We need a national patient identifier. It won't be perfect, but it is badly needed. I have tried to make the point that this patient identifier can be opaque, and thus it can enhance Privacy. Today we share highly valuable demographics as that is the only way we can make a cross-reference. This is NUTS. Lets fix it. There are technologies today to allow us to have opaque identifiers while also assuring that the identifier can be validated. There are technologies today that would allow purpose-specific queries for cases where the patient didn't bring in their identifier but there is an health critical reason we need to look it up by demographics. There are technologies that can keep private the use of that identifier. Technology can scale today. This technology might be Block-Chain, but I don't think so due to the second need.
   
2. Universal Privacy -- The patchwork of privacy regulations is getting in the way of progress. Declare that all humans have a right of Privacy. Define what that Right means. Be reasonable (right to be forgotten is not reasonable, useful but not reasonable). Override the patchwork of federal privacy, healthcare privacy, state privacy, etc. Privacy is not an option, or something someone can sell. Violations of these Privacy principles must result in punishment regardless of who or how the violation happened. ONE set of rules, even hard rules, will be easier to deal with than the patchwork. This will result in less privacy failure, and less privacy denial. THIS should not be specific to healthcare. ONE right of Privacy. Note it should not include in the regulation any technology specific requirement, as technology changes and thus the regulation will break.
     
3. Incident Response Community -- Way too much something bad happens and knowledge of it is suppressed. I am not asking for public disclosure of everything. BUT the community should be enabled to learn lessons from others failures. This is true of at least Safety, Privacy, and Security.  There needs to be a way that authorized individuals representing every organization in healthcare can participate confidentially. That is they can expose a failure within their organization without adverse reaction (they must still meet regulated requirements). What I mean is that this is a peer group that will not use the information against their peers. What should happen is that their peers help diagnose what happened, come up with an action plan, and update the lessons-learned so that all the peers can implement that lesson. The result is a community that only gets stronger. This does NOT inhibit competition, as competition should be on health and experience outcomes.  This does happen in some circles, but needs government endorsement an encouragement.

I am sure there are others. I just don't have knowledge of them. I suspect there is HUGE gains to be made in supply-chain, payment-chain, and malpractice. These are broad areas that seem to me to be sucking far more money out of the system than they are providing value to the system. 

FHIR is not the solution to any of these broken things... but FHIR will be part of the healthcare solution.

IHE IT Infrastructure - 2017 work items

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.

1. 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
2. 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 additional layer of Provenance. Orchestrating: XDS, MHD, PDQm, QEDm, and various Document Content Profiles.
3. Sharing platform for non-patient documents -- Support for documents like configuration-files, style-sheets, templates, instructions, etc. These have some metadata needs, driven by search use-cases, but will not contain patient specific information. 
4. Remove Documents from XDS Repository -- Today the Metadata Update supplement has a method for removing a DocumentEntry, but that leaves disconnected the Document in the Repository. This work item will address all Remove use-cases, including the metadata and the document. 

In addition to these the committee also recognizes significant work needs to be done to 

• Upgrade existing FHIR profiles to STU3. This work likely won't happen until late in the cycle as STU3 seems delayed. Most of these changes (MHD, PDQm, ATNA) will be mostly administrative changes. The changes to mACM, and PIXm might be simple update too, or might require significant consideration of best way to solve them given STU3 content. 
• Maintenance task. The CP backlog is better than last year, but not much better. Therefore ITI will continue to focus on resolving this backlog. Meeting more often, weekly. Targeted meetings, so as to draw in the appropriate specialists.

I think ITI is maturing, with little net new big items. This could be because it is not being approached with the new work, but I suspect it is more a recognition that the existing infrastructure is supporting significant domain specific work.

War against TLS 1.0

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:

1. SSL is fully forbidden. 
2. TLS 1.2 is best
3. TLS 1.0 and 1.1 are not as good as 1.2
4. 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 specific and important practical case... that is wen the higher protocol is not available.

It is this last clause that seems to be escaping recognition.

The 'standard' being pointed at is IETF (the writers of the TLS protocol) RFC7525.  This isn't just an IETF specification, it is a "Best Current Practice" -- aka BCP195 -- May, 2015

Recommendations for Secure Use of Transport Layer Security (TLS) 

and Datagram Transport Layer Security (DTLS) 

Let me excerpt the important part of that standard from section 3.1.1: Bold and highlight added for emphasis. 

3.1.1 SSL/TLS Protocol Versions


   It is important both to stop using old, less secure versions of SSL/
   TLS and to start using modern, more secure versions; therefore, the
   following are the recommendations concerning TLS/SSL protocol
   versions:

   o  Implementations MUST NOT negotiate SSL version 2.

      Rationale: Today, SSLv2 is considered insecure [RFC6176].

   o  Implementations MUST NOT negotiate SSL version 3.

      Rationale: SSLv3 [RFC6101] was an improvement over SSLv2 and
      plugged some significant security holes but did not support strong
      cipher suites.  SSLv3 does not support TLS extensions, some of
      which (e.g., renegotiation_info [RFC5746]) are security-critical.
      In addition, with the emergence of the POODLE attack [POODLE],
      SSLv3 is now widely recognized as fundamentally insecure.  See
      [DEP-SSLv3] for further details.

   o  Implementations SHOULD NOT negotiate TLS version 1.0 [RFC2246];
      the only exception is when no higher version is available in the
      negotiation.

      Rationale: TLS 1.0 (published in 1999) does not support many
      modern, strong cipher suites.  In addition, TLS 1.0 lacks a per-
      record Initialization Vector (IV) for CBC-based cipher suites and
      does not warn against common padding errors.

   o  Implementations SHOULD NOT negotiate TLS version 1.1 [RFC4346];
      the only exception is when no higher version is available in the
      negotiation.

      Rationale: TLS 1.1 (published in 2006) is a security improvement
      over TLS 1.0 but still does not support certain stronger cipher
      suites.

   o  Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to
      negotiate TLS version 1.2 over earlier versions of TLS.

      Rationale: Several stronger cipher suites are available only with
      TLS 1.2 (published in 2008).  In fact, the cipher suites
      recommended by this document (Section 4.2 below) are only
      available in TLS 1.2.

   This BCP applies to TLS 1.2 and also to earlier versions.  It is not
   safe for readers to assume that the recommendations in this BCP apply
   to any future version of TLS.

Note the last bullet tells you that you yourself must support TLS 1.2. A good thing if your platform allows it.

Financial industry PCI standard

Doesn't PCI require that organizations stop using TLS 1.0?

(Taken from Sequoia recommendation on TLS, as I a not a PCI expert)  As of 2016-11-23, the PCI issued the following text on their public web site at: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls which states "The Payment Card Industry Security Standards Council (PCI SSC) is extending the migration completion date to 30 June 2018 for transitioning from SSL and TLS 1.0 to a secure version of TLS (currently v1.1 or higher). These dates provided by PCI SSC as of December 2015 supersede the original dates issued in both PCI Data Security Standard v3.1 (DSS 3.1) and in the //Migrating from SSL and early TLS// Information Supplement in April 2015."

Conclusion

Yes, it would be great if everyone had all the latest protocols, and that all those protocols were implemented without errors... BUT reality gets in our way. Especially so with Interoperability where reality is that we are trying to achieve Interoperability. 

UPDATE: Reader should note that RFC7525 is very readable and full of far more recommendations than just TLS version. Including detailed discussion of cypher suites, and authentication types, etc. There is no perfect solution or configuration. Security is RISK MANAGEMENT, and needs continuous care and monitoring by an expert.

User Account abandonment policy

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, you will need to re-register with your new account information.
JOHN MOEHRKE: so... I need to create a new login user? Or is there some process I can use to use the current login?
Paula B.: No, I'm sorry, you cannot use the old information. If I am not mistaken, it will continue to be associated with the old account.
JOHN MOEHRKE: okay. so how do I close the old login account? Meaning, how do I prevent it from ever being used again?
Paula B.: Once you create your new and everything has been update throughout all the databases that old account will no longer be active.

What I was worried about is that after I stop using my old login, their is risk that the account is not monitored and thus possible to be attacked. The attack would need to avoid the normal detection on accounts. But as we have seen this week with Credit-Cards; a smart attacker figures out was to avoid detection. In the case of Credit-Cards, they used many storefronts to try various codes. In the case of a user login, they might simply try a small number (1-3) attempts each day, presuming the detection resets each day. Given that I would not be logging in occasionally, as I have abandoned the account, the attacker has years and years to try.

The good news is that United Healthcare has a policy that covers this. They know that the account is explored. Their login shows me this. They allow me to login for 18 months, so that I can get to old information. Often times this old information might be needed for TAX purposes. So, 18 months is reasonable. After 18 months they totally disable the account. I tried to get details on just what this means, but given the responses I did get up to this point gives me some comfort that they did this right.

Paula B.: Once you create your new and everything has been update throughout all the databases that old account will no longer be active.
JOHN MOEHRKE: when you say... no longer be active... does that mean that it would be impossible to log-in to it? Sorry to be specific, I am a Privacy/Security expert, and don't like abandoned accounts that have healthcare information within them. If I stop using it, I can't tell if an attacker is trying to break in.
Paula B.: I understand.
Paula B.: You will have access to it for up to 18 months. After that point, the information will not longer accessible on myuhc.com.
JOHN MOEHRKE: okay, so that is a specific policy? I like that answer. It gives the user (me in this case) a chance to get old information I might need... while having a specific deadline. Thanks.
JOHN MOEHRKE: can you point to where that policy statement is written? (I trust, but... as I said, I am a Privacy/Security expert... so I like to verify)
Paula B.: You're welcome! I understand, but I am unable to point to where that is written. That is a UnitedHealthcare standard.
JOHN MOEHRKE: okay. thanks
Paula B.: If there is nothing else, thank you chatting today. I hope you have a great day!

Wish I had a policy fragment to point at... I guess I should set a reminder to try in 18 months...

IHE: Analysis of Optimal De-Identification Algorithms for Family Planning Data Elements

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 was seen as too hard to manage, vs the additional risk reduction.

Further articles on De-Identification

IHE IT Infrastructure White Paper Published The IHE IT Infrastructure Technical Committee has published the following white paper as of December 2, 2016: Analysis of Optimal De-Identification Algorithms for Family Planning Data Elements   The document is available for download at http://ihe.net/Technical_Frameworks. Comments on all documents are invited at any time and can be submitted at ITI Public Comments.