FHIR defines a resource called Document. It describes a way to assemble a set of resources to act as a “Clinical Document” – an set of resources that have an attested content, and carry their own context. Kind of like CDA – in fact, a lot like CDA.
Technically, the Document resource is actually a bunch of pointers to other resources, and some glue attributes around attestation and presentation. The resources correspond to the CDA header (patient, author, attester, encounter, etc) and the body ( a tree of sections , each with a code and a resource that provides the content). You can see an example here: http://hl7connect.healthintersections.com.au/svc/fhir/document/@1/history/@1.
When you’re dealing in a pure RESTful environment, you can treat the clinical document as a bunch of disparate resources, each accessed separately. Kind of a virtual document, in a way. But while that’s pretty convenient for processing data atomically across documents, it presents a set of challenges:
- How can you be sure these things don’t change?
- How can you reassemble exactly what was attested?
- How can you move the whole document in one go?
- How can you ensure that the whole document is available?
These issues are especially obvious if you’re used to the CDA paradigm, and not to REST. But they’re all valid issues. So to make document handling possible, FHIR defines a way to stitch all those disparate resources into a single “bundle” (which is an atom feed in XML) with a tag (feed.category) of “http://hl7.org/fhir/tag/document” that marks it as a “Clinical Document”. You can see the same document as the previous example in a fully assembled document here: http://hl7.org/implement/standards/fhir/document-examples.html
There’s a duality here – a Document resource, that describes a logical clinical document, that can be assembled into a “Document” – that is, a Document Bundle that is an actual clinical document.
The Naming Problem
As that previous sentence makes clear, we’ve got a naming problem – naming the resource “Document” creates potential for confusion between the Document Resource and a Document Bundle. I kind of hoped that it wouldn’t be a problem, that we’d use “Document Bundle” for the whole thing – but I haven’t even done that in the specification. So we’ve decided to rename the resource to something else to reduce the confusion.
The trouble is, what? So the project team and the implementers skype channel have been casting around for a name, and we’ve considered a lot of candidates. But we don’t really like any of them enough to get consensus. So this is a straw poll: which of these do you like, and why?
- “DocumentHeader” – It’s the thing that stands at the head of the document. But in CDA terms, it’s not just the header, it’s the sections as well. So potentially misleading for CDA people.
- “DocumentOutline’ – it’s the outline of the sections, and the outline of the header information (all references) – but we think most people would think it didn’t include the header part
- “DocumentSpine” – same comments as document outline
- “DocumentBackbone” – same comments as document outline
- “DocumentBase” – it’s the base of the document – whatever “base” means. Very obscure
- “DocumentRoot” – same comments as DocumentBase
- “DocumentGlue” – well, it holds it all together, but it’s more than that
- AttestedCollection – because that’s part of what it is – this was an attempt to get away from document altogether – but it’s narrower than an attested collection – it’s specifically got document aspects
- DocumentStub – this might be my favourite at this point, because it sounds painful
Someone suggested “DocumentWithLeavesOutsideInAFeedSomewhere_MaybeHereMaybeNotBut DefinitelyAccessibleUnlessItsDownSoYa” – but perhaps we can do better than that?
So, vote in the comments please (or the FHIR mailing list, or email me privately if you aren’t allowed to do either of those) – thanks