Stream: terminology
Topic: EHR Server implementing $expand
Michael Lawley (Mar 15 2019 at 23:01):
@Colby Seyferth I'm very interested in what the drivers are for implementing terminology services inside the EHR. Or, put another way, why not use an externalised terminology service?
Grahame Grieve (Mar 16 2019 at 01:09):
because any existing EHR already has lots of value sets and code systems and extensive internal terminology services.
Grahame Grieve (Mar 16 2019 at 01:10):
If you were designing from scratch.... maybe you would use an external terminology service
Peter Jordan (Mar 16 2019 at 08:54):
It would be insightful to know how many EHR vendors have switched, or plan to switch, their internal terminology 'services' to FHIR. I would expect that the biggest reason for such a major re-factoring of this application layer would be to move to an external service (hopefully FHIR).
Grahame Grieve (Mar 16 2019 at 20:33):
aprroximately none, so far as I know. A far more likely thing is to make parts of your internal services that already exist available via an external interface
Grahame Grieve (Mar 16 2019 at 20:34):
and parts of your internal new development leverage an external server
Peter Jordan (Mar 16 2019 at 21:55):
My guess is that the later scenario is more likely here in NZ to facilitate the implementation of SNOMED CT in EHRs.
Grahame Grieve (Mar 16 2019 at 22:07):
I think it's a good idea
Michael Lawley (Mar 18 2019 at 02:40):
It would be interesting if layering a FHIR layer over the (often multiple) internal terminology systems were a path to integrating and providing consistent and better functionality, with or without external terminology services.
It should also offer great benefits to the EHR vendors in terms of maintenance costs for importing and massaging all the external code lists
Brian Postlethwaite (Mar 18 2019 at 08:46):
@Michael Lawley, that's essentially what we're starting to do.
Cooper Thompson (Mar 18 2019 at 20:53):
In many ways, providing terminology services is an essential feature of an EHR. @Peter Jordan I'm not quite sure that I know what "switching" to FHIR means. We may implement a set of FHIR APIs on top of our existing terminology services, and implement integration with external terminology services (and probably both at the same time).
Peter Jordan (Mar 18 2019 at 21:16):
@Cooper Thompson you're describing the same kind of adapter approach described by @Michael Lawley above which relates to more mature EHR products. Not all EHRs (in this part of the world anyway) have a cohesive approach to terminology and changing their architecture to consume external terminology services exposed by a FHIR API would represent quite a major change, maybe akin to flicking a switch?
Brian Postlethwaite (Mar 18 2019 at 21:20):
They will have lots of more simple terminologies though, and in some areas may not require the more complex terminology capabilities.
Peter Jordan (Mar 18 2019 at 21:26):
Sure. In NZ, SNOMED CT and NZMT implementations are the major concern and most vendors have very little experience of a providing or consuming a terminology services API. In fact, as I type, this I'm in a meeting with the Ministry and a group of GP and Pharmacy vendors discussing this very topic.
Last updated: Apr 12 2022 at 19:14 UTC
