Stream: implementers
Topic: Transfer to Hospital
Holly Gillett (May 17 2019 at 00:15):
Hi, I'm in the aged care sector and we are looking at how we can provide the 'transfer pack' that we typically compile when one of our residents needs to be transferred to hospital in the FHIR format. The 'transfer pack' is a paper envelope and series of reports and forms with information about the health of the resident and how they should be cared for.
I haven't been able to find any examples of others implementing use cases like this. I am looking for someone to sense check how we are thinking of using FHIR, as we're pretty new to this. I've attached a diagram below. Appreciate any feedback!
Thanks!
FHIR-resources-for-transfer-pack.pdf
Lloyd McKenzie (May 17 2019 at 01:35):
Why do you have 3 sub-Compositions instead of one root level Composition for everything? Simplest would be to do that and call the entire package a FHIR document.
Holly Gillett (May 19 2019 at 21:08):
I had 3 doc compositions because we already capture GP notes as a single composition when we receive them, so I figured it would be easier to keep that package together and then the other two compositions come from different sources and mimic two separate documents, so again I thought it would be easier to keep them separate... but thanks for your feedback... makes sense - guess it looks more confusing to someone who doesn't have the current context of a transfer pack if there are 3 compositions
Holly Gillett (May 20 2019 at 23:03):
I've proposed a new transfer pack below.... a couple of questions have popped up:
-
Where we would probably only be interested in the narrative associated with a FHIR resource, is there any point in even having a resource? Or would it be sufficient/ acceptable practice to capture the narrative in a section on a composition, especially where a suitable LOINC code can be used to classify it?
-
At the moment, I have lots of sections (as indicated on the diagram with x 31, x2 etc)... each section only has a short text response e.g a comment on mobility, mobility aides, feeding etc)... is there any value in grouping up these sections, so there are less high-level sections? or would that just be adding unnecessary complexity?
-
Regarding use of LOINC codes.. I've tried to align with the codes from the example CDA for a 'transfer summary note' (https://details.loinc.org/LOINC/18761-7.html) ...it seems like across the board there a heaps of codes that are very similar, so I thought this could be a way to limit down my options... is this a good way to go about selection of appropriate LOINC codes? or would I be better to search the full list?
Appreciate any feedback!
FHIR-map-for-transfer-pack-v2.pdf
Lloyd McKenzie (May 21 2019 at 01:42):
It's now permitted to have a narrative-only section. However, that means that the data can't be subsequently exchanged. For example, a narrative-only CarePlan (that presumably still populates patient, author date and author) is useful and shareable via REST, messaging, etc. However, content sitting in Composition.section.text can't ever be retrieved on its own or passed around independently. As a result, best practice is usually to put information into resources if there's any potential use for downstream sharing, even if it's currently mostly narrative.
Holly Gillett (May 21 2019 at 21:05):
Awesome, thanks @Lloyd McKenzie , that's very useful. Any comments on the other questions?
Lloyd McKenzie (May 21 2019 at 21:08):
Don't really have a strong opinion on the second question. The number of sections and depth of sections is really a question of preference unless you're trying to align with an IG that sets specific expectations.
In terms of LOINC codes, trying to align with what's typically done in Consolidated CDA is probably your best bet for maximum interoperability. If there's going to be any consistency at all, it'll probably resolve around that.
Last updated: Apr 12 2022 at 19:14 UTC
