What skills make for a good CDA developer?
The key skill that a CDA engineer will have is a great deal of familiarity with structured documentation. That doesn't necessarily mean "clinical documentation". My own background includes experience with SGML, XML and HTML well before I ever encountered the healthcare domain and CDA.
Expert use of CDA requires expert skills in structured documentation and some knowledge of the healthcare space. In my own experience, the former is harder to impart to an engineer than the latter. If I were to rank the importance of familiarity with certain technologies, I'd make HTML the least important, XML in the middle, and SGML the most important indications of experience with structured documentation.
Engineers with SGML experience will usually have a pretty good understanding with "transformational" and validation technologies which are essential for effective generation and use of CDA. Those with XML experience will be pretty familiar with XSLT and schema's [W3C, RelaxNG, or Schematron], which are specific examples of those technologies. I use a great deal of XSLT in CDA development (in fact, you might call it my preferred programming language).
Most people familiar with the disciplines behind structured documents will also have a good grounding in information retrieval and terminology (controlled vocabularies). These are two other key technologies that are associated with the use of the CDA standard.
I know one CDA consultancy that has hired a number of people with this background and that has been quite successful.
Does knowledge of troff and nroff qualify me?
ReplyDeleteAgree. If you can hack SGML, then you can hack pretty much any XML vocabulary in any domain. With the emergence of native XML storage (Oracle XMLDB and IBM DB2 PureXML), we'll see applications (including in healtcare) make more use of declarative programming with XForms, XSLT, and XQuery.
ReplyDeleteThe typical design pattern here is XRX (XForms, REST, and XQuery) where user inputs are captured with an XForm front end (itself potentially auto-generated from an XML schema) and data is RESTfully submitted to a native XML database, then queried and manipulated with XQuery. The advantages of this approach are:
*It is more resilient to schema changes. In fact the data can be stored without a schema.
*It does not require handling the impedance mismatch between XML documents, Java objects, and relational tables which can introduce design complexity, performance, and maintainability issues even when using code generation.