Hacker News Reader

Comment by nradov | Hacker News Reader

From a purely technical standpoint the HL7 Continuity of Care Document (CCD) is intended to address this issue by allowing a provider to put a summary of a patient's entire chart (including a plan for future care) in a single XML file and then give that to another provider when transferring care. It works well when properly implemented, but unfortunately many healthcare providers haven't done so completely yet. There are also practical problems in just moving the file from one provider to another.

http://www.hl7.org/implement/standards/product_brief.cfm?pro...

View on HN

The CCD, though a standard, is far from a univeral bridge. You can represent the same things in different ways, use different vocabularies. Even if you standardize on the "blessed vocabularies" you still have many ways to code the same thing.

So a CCD produced by Nextgen won't always come into Epic the way it's intended (not picking on those 2, just an example).

I've come to realize that even though the CCD tries to be all things to all people, it suffes from the same issue as many of the vocabularies themselves: data precision is an afterthough. Clinical informatics lives in a utopia where everything is precisely represented and perfectly documented. Actual clinicals deal with partially-known information, imprecise or unrefined representation of diagnosises, procedures, meds, etc; and just have to make the best with what they have.

That's true to an extent, but in practice the problems aren't too serious if everyone follows the C-CDA 2.1 CCD specification. It standardizes the vocabularies in each section so, for example at least you can be sure that prescriptions were coded with RxNorm.

But certainly testing is needed to ensure proper end-to-end interoperability. And of course if the users don't enter the data correctly in the first place then no interchange format can fix that.

The problems with the CCD (having so many different ways to represent the same thing, having a different flavor for each system) are unfortunately passed down to new iterations of healthcare standards. New standards (like FHIR) are designed to fix problems with older standards, but then when it comes to implementation they are built to be backward compatible with the older standards, and so inherit some of the same problems (in this case, the ambiguity of representation).

HL7 FHIR makes implementation slightly easier, but it doesn't do anything to solve the data modeling and coding problem. There are multiple ways to represent the same patient chart entries in FHIR just as with HL7 CDA R2. Take a look at the C-CDA on FHIR implementation guide.

http://www.hl7.org/fhir/us/ccda/

Healthcare data is fundamentally complex. It is impossible to come up with a single canonical way of representing everything we might want to record about a patient. The standards reflect that essential complexity.

It's a standards of many standards. Each system (radiology, laboratory, scheduling, etc.) has their own system with it's own flavor of HL7. It then communicates with the larger hospital-wide system (Epic, Meditech, etc.) through interfaces that translate form the system specific to the flavor required by the hospital-wide system. Each interface implementation tends to make their own decisions about what certain pieces of information should look like, decisions that are specific to the healthcare organization and systems that they use.

The irony here is that most clinicians would be happy with something that is simply searchable: even a large PDF would go a long way towards meeting their needs. Instead they are provided nothing at all, or stacks and stacks of physical paperwork.

Reply on news.ycombinator.com