All
Accepted answers
Adam Lees · Jan 12, 2024 go to post

Is there a way to generate the file 100% programmatically, for example in an automated build pipeline?  As far as I can see the only way seems to be to write code to generate the module.xml

Adam Lees · Apr 24, 2023 go to post

Thanks.  We will be exporting as code to compile on the customers' version (in this specific instance it is 2017) but ideally we just would like to ensure it will run on any prior version (within reason) without having to maintain a bunch of prior versions and test compile on each. The exportversion qualifier may be useful, but it's any dependencies like updated APIs you mention that we are wanting to catch.

Adam Lees · Feb 28, 2022 go to post

Hi Robert, thanks for responding. The question is no longer relevant as there is a simpler solution: a SQL server database acting as a cross-org EMPI which will be kept up to date by ADT.

Adam Lees · Jun 18, 2021 go to post

André-Claude, thank you very much, that would be a great starting point.  I will message you. 

If you have code that you are willing to share with the community, it's worth considering putting it into a public repo on Github.

Adam Lees · Jun 18, 2021 go to post

MESH is just a message transport mechanism and is agnostic of payload type.  The key thing is the recipient system understands the format you're sending.  You can embed PDF files base64 encoded in a Kettering document, but whether that will work depends on whether EMIS is configured to ingest those PDFs.  

You need to configure the correct MESH Workflow ID so that EMIS understands what kind of message it is.  You can't fire random FHIR messages at another system and expect it to just understand it.  EMIS does understand standard NHSD FHIR Transfer of Care messages and Digital Medicines messages for example.

What kind of documents are these and have you checked the NHSD standard API catalogue for a suitable FHIR standard, and (assuming MESH transport) checked the list of approved MESH workflow IDs?