Thread by @amalec

1/

A tweetstorm that will make some people mad. I apologize in advance.

There are two perspectives on the IHE SOAP-based specifications (primarily XDS, XCA and XCPD), not mutually exclusive

2)
a) They have worked in practice, so should not be ripped and replaced
b) They are legacy technology and we should work on more modern alternatives.

A 3rd perspective, enshrined in #TEFCA #QTF is:
c) We should continue to make them the core of our health infrastructure

3)

The world "legacy" makes people mad -- my perspective is that technology moves on regardless of whether we like it or not. Some standards, particularly low level networking standards, have stood the test of time, some have... not

4)

SOAP has not stood the test of time. There was a bit of a REST vs SOAP war ages ago, but the war is over, & deployed SOAP interfaces are firmly legacy. Nobody makes new ones. The world is HTTPS + OAuth2/JWT + JSON.

5)

Because it's legacy technology, the "enterprise" platform vendors (Oracle & Microsoft) continue to support it for Java/C# but try implementing XDS in Python or Go or Rust or ....

E.g., Zeep Python SOAP library is not actively developed, client only, & doesn't support XOP.

6)

The content underpinnings to XDS/XCA are a "standard" (ebXML) whose website is not actively maintained with last relevant updates in 2006. The content underpinnings for XCPD (HL7 V3) was an HL7 misfire that required a "Fresh Look" & restart with FHIR.

7)

Hiring developers to develop & maintain these things is like hiring developers to do work on COBOL, Mumps, AIX shell, or some of the other stuff we have hiding in the data center.

They work, but it's not where I'm actively hiring, training, etc.

8)

I'm training my developers on cloud, DevOps, Go/Python, serverless, etc. & they live in a world where REST/JSON/gRPC/OAuth2 are expected & required technologies.

9)

If we want health care technology to be a place where the best & the brightest work, we should *not* base national infrastructure standards on legacy technology

10)

the good news is that IHE has embraced this world & there are many perfectly good alternatives based on HTTP/Oauth2/JWT/JSON & #FHIR -- @CommonWell implemented pure FHIR-based services for all this stuff (for an EHR vendor who didn't want to be tied to the legacy world).

11)

& again we absolutely need a transition period & transition plan & don't want to rip n replace stuff that's working in production. @CommonWell already translates this stuff so we can live in the old world & new world at the same time.

12)

Anyway, go forth and hate on me & if you do, spend some time in the general technology world, or try to hire the folks who both want to change health care, & want to live in a modern technology world, but don't @ me.

END

Epilogue: no hate, much agreement!

Minor ?disagreement? on timing...