Stream: v2 to FHIR
Topic: querying
David Hay (May 29 2019 at 06:22):
Got an interesting requirement (and one that could be quite common). The customer has a PAS that can response to QRF^A19 queries, and they want to put a FHIR front end on it. It seems to me that the best design would be to use the FHIR $process-message operation (rather than REST) with a suitable MessageHeader.event and Parameters resource in the incoming message.
Does that make sense? If so, what would a suitable event coding be?
Grahame Grieve (May 29 2019 at 06:26):
why not do rest?
René Spronk (May 29 2019 at 07:39):
Indeed, why not rest? But if you're going to use FHIR Messaging, the event code would be easy: just use the v2-table 0003 as a coding system. So the event code would be "A19".
David Hay (May 29 2019 at 07:52):
What would the FHIR query look like? We can't use $everything as there isn't a Patient resource instance (best we can hope for is an identifier)... (I should have said that they want all the clinical data and there's an integration engine in the middle, so it's FHIR query to the IE, QRF to the PAS). You could issue a series of queries like GET AllergyIntolerance?patient.identifier=x for all the clinical resources, but that seems a bit inelegant...
Grahame Grieve (May 29 2019 at 12:21):
my experience with A19 was simple queries that would now map directly to the REST api. It sounds like you have something much more complex going on. What's the query, it's parameters, and the nature of the response?
David Hay (May 29 2019 at 18:26):
It's early days, so I'll find out more and get back to you. But with that advice I'll put more emphasis into the REST paradigm. Thanks for the comments...
Brendan Keeler (Jun 01 2019 at 19:21):
Yeah, I agree with @Grahame Grieve . All A19s I've ever dealt with mapped fairly cleanly to RESTful FHIR.
David Hay (Jun 02 2019 at 08:44):
Much appreciated...
Last updated: Apr 12 2022 at 19:14 UTC
