HL7 Clinical Document Architecture (CDA) has been around for many years, but recently it has resurfaced as part of meaningful use standards for exchanging clinical summaries. In addition, the Consolidated CDA (C-CDA) Implementation Guide from HL7 helps define best practices for structuring several clinical document types, like discharge summaries and operative reports. Recently we did some work with the SMART C-CDA Collaborative on operative reports, and it got us thinking about how we would provide a similar CDA implementation for synoptic pathology reports. To that end, we created one that you can find by going here.
In anatomic pathology, it is required that pathologists describe tumors using peer-reviewed, established protocols from the College of American Pathologists. The CAP Cancer Checklists are also published in electronic form as the CAP eCC. eCC has been instrumental in enabling organizations like NAACCR and Cancer Care Ontario to collect standardized, detailed pathologic cancer data at a large scale. This type of structured pathology reporting is often called synoptic reporting.
Currently, most transmissions of eCC uses an HL7 v2.5 format defined in NAACCR Volume V. As an exercise, we at mTuitive thought it would be productive (and fun) to explore a rendering of eCC as CDA documents, following the same fundamental rules as NAACCR Volume V. Although the C-CDA guide does not include anatomic pathology reports, the CDA standard is perfectly well suited to it. Others have created implementation guides and templates for rendering AP reports as CDA documents, though the focus is usually on the entire traditional AP report, including narrative history and gross description. Our work here only includes representing the synoptic portion of an AP report, specifically CAP eCC documents.
Again, we posted a writeup and the results to github if you want to learn more: https://github.com/peteot/pathology-cda. On that link you can also find examples of the messages sent as well as some more information about this work and how it can be implemented on site. We don't expect this to be the definitive and final word on the process - in fact we want it to be the beginning of a conversation between vendors, systems, physicians, facilities to ensure that we're creating the best standards for such implementation. Please contact us with your questions and suggestions - it's a discussion worth having and we look forward to hearing your feedback!
As an interesting aside, the CCDA samples project is hosted on github.
The way this works is that anyone can "fork" or copy a project, make their own changes. The original project owner can "pull" those changes back if they like them, or not. For example, the official repository for this project is maintained by Children's Hospital at https://github.com/chb/sample_ccdas. You will see our documents in there too. We "fork" their repository, make changes to it, and they "pull" our changes back in when they are ready. Though that is pretty much normal source control behavior, github has made this work on a massive scale in a far more user-friendly manner than ever before.
A pull request is a formal request, using software, for someone to merge your modifications into their project. Github more than anyone is refining how coders collaborate online. Their tools are really interesting, and in my opinion point the way toward how medical standards such as CAP and CPAC should be developed. In fact, I would imagine some are already being developed this way.
For non-nerdy examples, there are legal documents, US government policies, and Gregorian chants being created and edited using github.