New post
Question
· Mar 15, 2023

How to convert a FHIR Patient resource in XML format into a Cache object

#FHIR #XML #Caché

Hi.

We are going to have basic patient demographic data coming in to Cache via a webservice. I thought that I should define the input as XML something like the FHIR format (with UK extensions).

In the past we've input XML streams and used the  %XML.Reader to convert them to matching classes successfully, so I thought it would be easy. However, I've found that the FHIR format stores everything in attributes like:

  <gender value="male"/>
  <birthDate value="1982-01-23"/>

Looking in the Cache documentation here there seems no easy way to make a property match to an attribute of "value" without defining another class for each item with a single property called "value" and  XMLPROJECTION = "ATTRIBUTE" . Is that correct or have I missed something? I could invest in Ensemble or IRIS (though I can see nothing different in the IRIS documentation), but seems overkill for one small inbound message. Or should I forget FHIR and stick to a simple XML structure.

Thanks / Mike

Product version: Caché 2018.1
Discussion (5)2
Log in or sign up to continue
Sergei Shutov · Mar 15, 2023

Well first of all there is a first-class support for FHIR data in IRIS for Health and I would definitely recommend to use it instead of rolling out your own class-based solution. See documentation here https://docs.intersystems.com/irisforhealth20221/csp/docbook/Doc.View.cl...

If you want to work with projections, given that even basic data fields in FHIR are quite complex https://www.hl7.org/fhir/datatypes.html#primitive you'll need to define separate embedded classes for each data type; it doesn't have to be a separate class for each field.

0 0
Mike Wragg · Mar 15, 2023

Thanks for the response. I'd love to move them to IRIS, but at the moment we are struggling to even get them from v 2007 to 2018, so we are stuck on cache for now.

It looks like you are confirming my thoughts. The FHIR data is complex and unpacking will be hard. Good point though about only needing classes for each data type.

I'll have to take it to the supplier of the other end of our link. This is a one-off custom feed that will only ever be used once, so we can define it in whatever way is easiest to both ends. My end is "legacy" but maybe the other end will want to use the FHIR standard as it could need it for other links.

0 0