Stream: implementers
Topic: Use of FHIR for transfer/ extraction from EHR to quality reg
Øyvind Aassve (May 19 2019 at 10:36):
In connection with a large EHR-implementation in Norway a pilot is set up with the goal to establish more efficient ways to report information to quality registries. The pilot is for the national stroke quality registry. The tradtional challenges with different data structures in EHRs and QRs (quality registries are often question-oriented with yes/no/dont know answer alternatives) and information that have been captured in a different context in the EHR than asked for in the quality registry do of course apply. Some information elements which are similar in EHR and quality registries can be quite easy to extract automatically or into prepopulated fields in a questionnaire. Some quality variables (complex questions) will always be too complicated for automatic retrieval and will need questionnaires with questions that clinicians must fill manually.
For some types of variables do we however have some doubts on the best approach. Do anyone have experiences or opinions on whether the following kind of variables can/ should be extracted automatically through an API (ex to prepopulate a form) or rather manually filled out in a questionnaire?
Medication treatment for high blood pressure? Yes, no, dont know
Any diagnostic imaging of the stroke available? None, CT, MRI, MRI and CT, Ultrasound, Other, Unknown
Grahame Grieve (May 19 2019 at 10:37):
as asked, I would expect that those will be manual data entry
Øyvind Aassve (May 19 2019 at 14:01):
OK, so for the diagnostic imaging case it seems possible to run a query on for example Procedure or ImagingStudy to get the relevent information. Is the main challenge the rule set for organizing the results of the query into the response alternatives in the questionnaire? Would it then be easier if the response options was limited to yes/no - so rule could be depending on the query returning a set of resources or not?
Lloyd McKenzie (May 19 2019 at 15:30):
You might look at the quality reporting stuff in the FHIR spec. It focuses on evaluating measures based on the raw data rather than submitted questionnaires. For any queries you do, you'll still have the challenge of consistent ability to query information. Querying to find diagnostic imaging results is pretty straight-forward, but filtering to those that are stroke-related is going to be the tricky part.
Grahame Grieve (May 19 2019 at 20:29):
Any diagnostic imaging of the stroke available?
There's an implicit judgment call there - what would make any imaging that is available an image 'of the stroke'?
Øyvind Aassve (May 19 2019 at 22:03):
My translation here of the quality register expression is not super sharp, but it is as you say about connecting imaging/ procedures with clinical findings connected to stroke. In my simple head I am seeing that the resources ex have reasonsCodes and reasonReference attributes that could be query candidates. Is some of the problem that this information is not well enough documented in such a structure to sufficiently identify and pair the appropriate conditions and images - at least not consistently?
Lloyd McKenzie (May 20 2019 at 01:14):
It depends on your environment. If all of the systems involved are complying with profiles that constrain the set of possible reasons/conditions to something you can consistently search on, you're fine. If you're in a wild-wild west where systems capture whatever codes they like with a good smattering of free text, then you can find some percentage of likely candidates, but you can't guarantee that you've got all of them and, excepting exact match on free text, can't be positive that matches there are what you actually want.
Øyvind Aassve (May 20 2019 at 17:20):
Thank you guys for advice. We'll keep coding and clinical practice high on the agenda when considering our ambitions for automatic retrieval. Cheers
Last updated: Apr 12 2022 at 19:14 UTC
