#I14YNow is trending at HIMSS and an absurdly vague interoperability pledge has been signed by a bunch of vendors. I thought this an appropriate time to reflect on just how much your developers are going to need to learn to interoperate tomorrow. This article is going to focus on how you would get a CDA document from a network like Commonwell, Healtheway, or just straight from Epic themselves.
Aside #1 Information blocking
I hope this post demonstrates the cognitive dissonance ONC has with their interoperability pledge. Epic is no harder to interoperate with any other vendor – they all use the same specs! It’s ludicrous. The real challenge we are fighting are 10-15 year old technologies that today’s developers shouldn’t need to learn.
Step 1: Read specs
Step 2: Read the specs referenced in those specs
Both of those networks point back to HealthIT.gov docs good luck trying to find a quick-start guide.
Step 3: Read the third layer of documentation
You finally start getting to specs that don’t reference other specs. For example, your developers will revel in such classics as:
- Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0
- TP 13 – HITSP Manage Sharing of Documents Transaction Package
- ITI TF Supplement XCA TI
Yes, there is exactly one word in the title of the last one.
Step 4: Develop?
I put a question mark here because this may or may not be very challenging. Most of the specs you just read were published during the second Bush administration. That means that Node.js, Ruby, Go, etc. will take a lot of work to get you to up and running. Part of our mission at Redox is to democratize this mess so you only need to worry about inputs and outputs, not the long ugly path in between.
Step 5: Test
Assuming you have enough grasp of the documentation, you can start developing. Every good developer needs something to test with. Sadly, the options are lacking and not provided by vendors directly.
Here is one I found:
Both can get you ready to go.
Aside #2 Shoutouts
AEGIS and NIST did some really great work with these testing tools. I’m really grateful they were there for me to do my development, and I don’t sense that policy makers realize how important a good testing tool is to developers.
Step 6: Understand C-CDA
Did you think that pile of specs was all you needed to read? Not even close – that just gets you an XML document that you need a whole other set of specs to deciper. Check out my Interoperability Primer to start making sense of that.
All of the work I outlined to interoperate really only has two inputs: a patient ID and some way of authenticating yourself. The output is an arcane XML document. At Redox we just ask you for the patient ID, handle the authentication for you, and send you an easy-to-grok JSON Clincal Summary back.
I’ve ranted about it before, but developers are key to solving interoperability challenges. The specs I outlined above suggest that the ONC has too many architects and not enough do-ers. Redox is all about doing – come talk to us to start getting data!