IHE FHIR Profile Publication/Overview and Concepts

From IHE Wiki
Jump to: navigation, search

IHE FHIR Profile Publication/Overview and Concepts

This page is targeted at an IHE author who wants to write a new supplement that will be published using web based tools and not a PDF document. There are separate forces at work, and you need to understand those.

  1. There is general work designed to allow a profile author to write a supplement that will be web based.
  2. There is a second level of work intended to support profiles that are based on the HL7 FHIR specification.

There are also other forces such as the use of Github to control files during the publication process. That will be addressed separately.

Supplement Model Background

We need a way to describe supplements with differing levels of complexity. It would be wonderful if we had the perfect solution at the beginning. I suspect it will take a few iterations. I describe a few different models we would have for supplements. We can provide a template for each model.

I decided to not use numeric values for the different models that will be described below. With the exception of the first model (alpha), I am not convinced that one will be able to draw a clear line from one to the next that is monotonically increasing using some measure. I expect you will see more of a connected graph relationship between the various models rather than a series of types where each type has exactly all of the features of the previous type plus one or more new feature. To put it another way, do not take the labels assigned to the models to mean that one supplement model is better than another.

Supplement Models

Each model below has a description and a link to example output. We need a second link to the input files used to create the example output.

alpha

This alpha supplement consists of the following:

  • One main HTML page
  • One index HTML page
  • No other pages
  • No other related artifacts other than icons, figures, etc.
  • The main HTML page may have web links to other web resources outside of this environment

Note that we make no comment about the level of detail on the main HTML page. It would have to contain enough information to satisfy what is currently in an IHE supplement.

The alpha supplement is intended for a profile author to get started with the documentation process. You will quickly add more files/content once you have an outline.

Example: http://ihe.wustl.edu/fhir/alpha

theta

The theta supplement consists of the following:

  • One main HTML page
  • One index HTML page
  • At least one other HTML page
  • No other related artifacts other than icons, figures, etc.
  • The HTML pages may have web links to other web resources outside of this environment

This is slightly more realistic than the alpha model. We make no comment on the content of the main and other HTML pages. There will be other models that are more prescriptive. For this version, you could consider a main page with overview, a volume one page and zero or more transaction pages for volume 2 material.

Example: http://ihe.wustl.edu/fhir/theta

rho

The rho model includes

  • The HTML pages described for the theta model (main, index, one or more other pages)
  • At least one non-FHIR, non-HTML artifact that is included. An example is a zip file with sample files.
  • The HTML pages may have web links to other web resources outside of this environment
  • The structure/content of the HTML pages is not constrained

Example: http://ihe.wustl.edu/fhir/rho

sigma

The sigma model is the rho model with further constraints.

  • The constraints document the content that go in the various HTML files for consistency.

Example: http://ihe.wustl.edu/fhir/sigma

gamma

The gamma model is a FHIR specific version. This supplement consists of:

  • One main HTML page
  • One index HTML page
  • At least one other HTML page
  • One FHIR Implementation Guide XML resource file.
  • Zero or more FHIR Capability Statement triplets (xml, json, ttl files)
  • Zero or more FHIR Structure Definition triplets (xml, json, ttl files)

No comment is made about the structure/content of the HTML pages

Example: http://ihe.wustl.edu/fhir/gamma

delta

The delta model is a FHIR specific template that has the same baseline requirements as the gamma model. The delta model adds further requirements:

  • The constraints document the content that go in the various HTML files for consistency.

Example: http://ihe.wustl.edu/fhir/delta

Supplement Model Recap

The sigma and delta models are likely the end game for publication, but it may take some time to get there. I could imagine a set of requirements for either model that will get implemented. As we learn, we will discover a better way to lay out the documents. The sigma and delta models would likely be deprecated and replaced by other models (zeta, tau, ...).

Author Requirements

A profile author will have to pick one of the models to write the documentation. We believe the same software tool can be used to publish any of the models. Listing the various types with a hint towards complexity is intended to serve as guidance. The section below details what a profile author will need to provide.

For each of the requirements listed below, you can assume there is a template you can follow.

Author Requirements: alpha

  • One XML file that is the index for this supplement.
  • One XML file that contains the HTML content for the supplement

Author Requirements: theta

  • One XML file that is the index for this supplement.
  • One XML file that contains HTML content for the supplement
  • A second XML file that contains other HTML content for the supplement
  • Optional additional XML files with additional HTML content

No FHIR artifacts or other files are included.

Author Requirements: rho

  • One XML file that is the index for this supplement.
  • One XML file that contains HTML content for the supplement
  • A second XML file that contains other HTML content for the supplement
  • At least one non-FHIR, non-HTML file such as a zip of example data/files
  • Optional additional XML files with additional HTML content

No FHIR artifacts are included.

Author Requirements: sigma

The author produces the same set of files as for the rho model. The difference is that the format of the XML files is constrained by committee design. No design has been formalized at this time.

Author Requirements: gamma

This is a FHIR-based supplement.

  • One XML file that is the index for this supplement.
  • One XML file that contains HTML content for the supplement
  • A second XML file that contains other HTML content for the supplement
  • Optional non-FHIR, non-HTML files such as a zip of example data/files
  • Optional additional XML files with additional HTML content
  • One FHIR Implementation Guide XML resource file.
  • Zero or more FHIR Capability Statement triplets (xml, json, ttl files)
  • Zero or more FHIR Structure Definition triplets (xml, json, ttl files)

Author Requirements: delta

The author produces the same set of files as for the delta model. The difference is that the format of the XML files is constrained by committee design. No design has been formalized at this time.

Open Issues

  • In the Rho model, could not determine how to get example xml files into the output. This is likely not something done by the IG but might better be controlled by ant and framework/build.xml
  • The menu file needs to be moved into the content folder. It changes.
  • Sigma model: Calls for specific page content/layout, but we do not have that yet.
  • Gamma model: Cannot determine how to get FHIR artifacts listed in artifacts.html. If I create artifacts.xml, the build software reports a conflict on building artifacts.html. There must be some place to list the artifacts.
  • Need to put files for all models in github to serve as examples.
  • Need to understand better the difference (if any) between an IHE supplement and an IG. Specifically, do we intend the software as it exists today to produce a supplement in HTML form. Is it just a matter of tweaking XML and CSS files, or are there software changes needed?
  • Jose had given us sample content and publish folders. I had assumed that the files in publish would be controlled by Jose (or other management) while authors would provide the files in content when t was tie to write a new supplement. I found some errors in that assumption. Some of the files in the publish folder need to be modified depending on the supplement and should be moved to the content folder. I will get these documented.