I wanted to propose some additional workflows for the SHR based on how we’ve been seeing people implement HIEs in production. I propose that we introduce two new workflows for the ‘save patient level clinical data’ and ‘query patient level clinical data’ that are more FHIR native. Currently the are both defined using a document-based approach which is more complex and I haven’t seen much uptake in implementations.
I propose that we keep the old workflows but add two new ones which are conceptually the same but the technical details are more aligned to how FHIR is currently used. I’ve made some initial changes to the source code of the architecture specification and I’d love some comments or feedback on these. (There is a rich diff option on github for each file to make these more readable and it will also allow the diagrams to be displayed).
Hi @ryan – this is terrific and I completely agree, it would be a useful evolution of our blueprint workflow definitions. There has been work done by Canada Health Infoway – leveraging the IHE Methodology – on this exact topic. Information about the Canadian FHIR eXchange format (CA:FeX) is found, here: CA:FeX Release Information - Pan Canadian Interoperability - InfoScribe.
The CA:FeX format is conformance-testable and is regularly tested at Canada’s Projectathon events. The plan is for Infoway to bring this to IHE’s ITI technical committee for international ballot as an IHE global public good, but I don’t know the timeframe for this. Happily, all of the CA:FeX work is completely transparent and freely available on the Infoway website.
This is an FYI only; it may be helpful to know about this already mature work that seems to be pointed at addressing the same issue. Canada wanted a FHIR-native way to exchange patient summary documents… and this is an important use case for our OpenHIE community, too.
Warm regards,
Derek
Thanks so much Derek. I will take a look to see the direction Canada is going, I’m sure it would be useful to borrow some ideas from that work (as we have always done ).
I listened to an interesting webinar on the AEHIN network about the Australian National Shared Health Record system and it seems they are hoping to move away from documents and towards a FHIR native approach as well. So, their seems to be push in that direction at the moment.
I also saw that presentation, Ryan. Yes, it was super interesting. I must admit, however, I’m personally less enamoured with the RESTful retrieval of onesy-twosy FHIR resources than I am with FHIR document exchange. In my experience, clinical document exchange maps well to existing care workflows – and for that reason, I think digital processes that follow this pattern have a lower hurdle to overcome when it comes to implementation and broad uptake.
Canada’s go-forward plan, with PS-CA documents exchanged via CA:FeX, will generally follow a pattern that I’m very fond of. It is the repeating 1-2-3-4 “dance” of…
Unambiguously identify which Derek I am;
Retrieve Derek’s health story;
Provide appropriate (ideally guideline-based) care to Derek; and finally
Update Derek’s health story (including any forward-looking orders).
This pattern repeats at every encounter, throughout the care delivery network. It’s simple… but it’s powerful. I think we can and should look at pure-FHIR document exchange as an immediately beneficial update to our OpenHIE SHR workflows. Of course… once we can exchange a FHIR bundle resource (a document) we can exchange every other kind of resource, too!
I think this is a great idea. I do think document based is helpful in a lot of cases, but we can also leverage more direct access. There are 2 related IHE profiles we can possibly reference.
These are just on the query (or extraction) side though. As Derek mentions, create/update of individual resources may be more complicated because you could lose the context. But I know it does seem easier when you’re just trying to sync from an EMR to the SHR. I think the complicated part is the governance and management of the data and who is validating it when it could be a one-off resource.
I think this would also be a good topic for the OpenHIE community meeting in November, but also would be a good topic on the architecture or SHR calls.
Thanks, and I agree document-based exchange is useful in many cases. However, it seems that there is no real go to specification that is defacto or even developed enough for us to specify.
I think we should rather be more open as an architecture specification to state the general workflows under which FHIR data is shared and then only recommend particular IGs and IHE profiles that implementer may choose to use in their implementations.
I don’t think we can specify anything specific right now given the state of the current profile landscape.
Hi Ryan – I live in hope that we are (now, and only recently) in a position to be able to name implementable, conformance-testable specs. For exchange of an IPS document, we can look to the CA:FeX spec (which has a conformance-test suite) and IHE’s sIPS spec (also conformance-testable). The first one is FHIR-only… the latter will work with either/both FHIR or CDA-based IPS documents.
To Luke’s point – there are different opportunities (and perhaps different rules) related to exchanging clinical documents vs. just getting bits of data (separate FHIR resources). It’s not an either/or proposition – but the legal basis may be different (IPS documents might be digitally signed, for example). What I do hope for, though, is that we can have a complete enough OpenHIE spec that it “works right out of the box”. That would be a mercy for our country partners, I think.
I worry that if we’re just a bin of Lego blocks, our MOH teammates must always figure out their own assembly. Just like source code examples are super-helpful for devs, having pre-built example spec-assemblies that work will be a useful, and likely a welcome, accelerator. An OpenHIE reference infrastructure spec that operationalizes IPS exchange could be a game-changing exemplar.
My $0.02…
-Derek
Chiming in late - AeHIN was invited to the Taipei connectathon last Sept 2-5 and was able to observe IPS testing (there were other profiles being tested but IPS was our focus).
Our community is on the lookout for tests/routines/etc that we can adopt as each of our interoperability labs (now numbering 10) conduct their own. Some upcoming connectathons are Manila in October and Colombo this November at OHIE24. It would be good if these IPS tests are run, improved, and reported back to the community everytime there is a connectathon.
).
I think we can and should look at pure-FHIR document exchange as an immediately beneficial update to our OpenHIE SHR workflows. Of course… once we can exchange a FHIR bundle resource (a document) we can exchange every other kind of resource, too! 