How to convert a FHIR Patient resource in XML format into a Cache object
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
Comments
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.c…
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.
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.
You can also just use incoming XML as a steam and extract data you need using parser into a custom defined ensemble message, if you only need parts of the incoming data
Hi Mike,
Could you use an XLST to parse the XML and pass the value fields by reference into COS variables?
I've done something similar on a smaller scale for some IHE transactions (Albeit in HealthShare), but I've used XLST in IRIS as well.
I can't get to the Caché 2018.1 docs to check.
Just to tidy this one up, we eventually were told that the other end was supplying HL7 v2 messages, so the input became a single string with a v2 message in it.
And it's still not finished. We eventually found out the source could actually do soap calls direct, before converting to HL7, so it might even end up as we define a simple class with some properties and they pull in the WSDL to use it. That's development for you. :-)