Open hhund opened 2 years ago
Thanks for filing this issue and sorry for the late reply.
You are most certainly right about this. However, for the record, please let me try to explain what made us go that route:
Creating resources within the system that are not primarily part of the executed task (running a query) can safely be referred to as configuration. When it comes to configuration, it should be easy to get a grasp of what the deployed state's going to be. To achieve this it would be best to have these configuration files (a bundle.xml
in our case) being present and under version control. Kind of like "infrastructure as code", but for the initial setup. Using this approach could come in handy in case of a disaster recovery.
This is where your valid point comes into play and invalidates the intentions mentioned above.
Yes, we don't have a single bundle.xml
, simply because we are just providing a plugin and need to factor in already deployed solutions. They will have their own configurations, no matter how they get provisioned. Thus, having a single file is just not possible. Furthermore, we can agree on that the previously mentioned initial setup is always present since it is backed up by non-ephemeral storage.
All in all, I would follow your proposal and provide some kind of utility allowing for easy creation of a transaction bundle (maybe based off of a template of some sort).
@EmteZogaf - is this still relevant?
In the Wiki Page DSF Middleware Setup a procedure to modify the
bundle.xml
file located at/opt/fhir/conf/bundle.xml
is described. Since the file provided by the linked install guides is synchronized to the DSF release and NUM-CODEX systems, modifying this file is not recommended. It actually has a comment in it saying:Please provide a stand-alone FHIR transaction Bundle to your users with conditional update commands for adding the necessary MII/FDPG allowlist entries to an existing DSF installation.
Since you would need to establish some kind of on-boarding process anyway (the linked form does not exists), in which you would need to ask organizations for their current client certificate thumbprint, endpoint URL and so forth, you would be able to send a stand-alone, organization specific Bundle to your users in return.
Transaction Bundles can be executed against the DSF FHIR Server at runtime, for example using a
curl
command. Note: Since all references between allow-list resources (Organization, Endpoint, OrganizationAffiliation) need to be literal references, you will need to use conditional references when referencing the local organization and endpoint inside the transaction Bundle.A general MII/FDPG allowlist bundle could look like this, although I would recommend providing users with a customized file: