In preparation for the upcoming HL7 International Working Group Meeting in Paris, we have been working on upgrading Forge, the FHIR profile editor, to conform to the current FHIR DSTU 2 specifications. In this post I’d like to provide an overview of the upcoming changes.
An earlier blog post by my colleague Marten Smits discusses the changes in DSTU-2 with respect to profiling: The evolution of Profile to “conformance package”. A fundamental change is the introduction of the new StructureDefinition resource, as a replacement for the (now obsolete) DSTU-1 Profile resource. The DSTU-1 Profile resource represents a set of related profiled resource and/or extension definitions, combined into a single resource. The new StructureDefinition resource represents a single resource or extension definition. A profile author can define and publish a set of related conformance resources – called a “Conformance Package” – by means of the Composition resource, containing a list of references to individual (stand-alone) resource profiles. The referenced profiles can be served from the same location as the composition. But it is also entirely possible for a composition resource to include references to external profiles defined elsewhere. This new approach facilitates the reuse of shared resource definitions. A common published resource profile can be referenced by multiple conformance packages.
The new DSTU-2 profiling approach based on distributed resources requires a redesign of the Forge user interface. The original UI was based on the premise that the profiling resource definitions are contained in a single Profile resource that represents the unit of storage. For DSTU-2, Forge must now provide support to manage a distributed set of conformance resources, possibly originating from multiple locations. This requirement inspired the implementation of a proper Project Explorer:
The project explorer displays all open projects and project items. The author can create/open multiple projects simultaneously. Conceptually, a project represents a “Conformance Package”.
The term “project” is Forge-specific and might change in the future. The FHIR specification does not define such a thing as a profiling “project”. The notion of a Forge project closely resembles a similar concept in popular development environments. By using a generic term, the application is not limited to support only conformance packages; a future release could provide additional support for other types of projects, e.g. a set of concrete (non-conformance) resources.
A Forge project also defines a local “resource scope” in the application, similar to the old DSTU-1 Profile container resource. Resources can reference other resources that exist in the same project via a simple local reference (e.g. #MyExtension). The resource selection popup dialog provides a list of available resources that exist within the current project.
Storage and Publication
Off course the application allows a profile author to open and save individual profiling (StructureDefinition) resources. Forge supports both local storage (on disk) and remote storage (FHIR server). A Forge project is not a FHIR resource and cannot be persisted as such. Forge will provide import/export commands that allow the author to open / save a project from / to a Bundle container resource. The Bundle resource is only used as an ephemeral transport and storage container and is not represented within Forge. When the author uploads a bundle to a FHIR server, the server will unpack the bundle and store the individual contained resources. Forge will provide support to define and manage Conformance Packages based on a Composition resource. When a package is finished, the author can publish the final version of a package to a FHIR registry server.
We are planning to publish a new alpha release this week. Stay tuned!