There are no plans to integrate latest FHIR features into EM (Extended Maintenance) releases at this time, but we will be sure to let everyone know should our release plans change in the future. 


Hi Pravin,

Unfortunately the "Class does not exist" error is expected if you are trying to perform the FHIR Lab exercise using an existing IRIS for Health version such as 2019.1, 2019.2 or 2019.3 (community edition).

FHIR DataLoad is a brand new functionality that is included in the 2019.4 release of IRIS for Health, which has not yet been officially released. IRIS for Health 2019.4 is expected in Q4 of 2019, with a preview kit becoming available weeks prior. Also, we are now working to turn the entire GS2019 FHIR Experience Lab into an online course accessible through Learning Services, so please stay tuned. In the meantime, if you need to load your FHIR repository with sample FHIR data, my suggestion would be to do that by directly posting FHIR bundles from a REST client like Postman. Thanks.

Hi Bachhar.

Are you running InterSystems IRIS for Health? And are you interested in mappings for FHIR STU3 or DSTU2?

The level of support for FHIR is different for each product (and version), so please provide information about the product and version you are running (InterSystems IRIS for Health, HealthShare Health Connect, or HS Information Exchange).

No additional documentation currently exists for mappings between FHIR DSTU2 and SDA, but for STU3, depending on what product/version you are running, there is a  page/utility in the Management Portal called FHIR Annotations where you can search and view data mappings for different FHIR STU3 resources (in a table format). 

Hi Stephen,

To confirm, does the clinical system expect the response data to be a FHIR resource (Patient resource in this case)?

I ask because the HTTP GET request format you specified (http://server/getpatientbyid?pid=M1234567) does not conform to FHIR's RESTful Search specification; it appears to be a custom REST call, which may have a different set of expectations in terms what response data/format is required, etc. Based on your description, it sounds like you are seeking to implement a message transformation interface that enables a PDQ (Patient Demographics Query)-type transaction.

For message conversion and processing, I think you should take a look at our existing support for IHE PDQ (v2) and PDQm (FHIR-based) profiles and see what existing components and internal calls may be used to achieve the data transformation required by your specific scenario. If the client system could be made to conform to the FHIR RESTful Search standard, then it may be easier to make direct use of our existing PDQm capabilities.