Difference between revisions of "IHE FHIR Profile Publication/Creating new Profiles"

From IHE Wiki
Jump to navigation Jump to search
Line 97: Line 97:
 
e.g. if our “base” profile has 2 pages (toc and index) and index has one picture saved as “image1.jpeg”, the files in our “base” profile shall be:
 
e.g. if our “base” profile has 2 pages (toc and index) and index has one picture saved as “image1.jpeg”, the files in our “base” profile shall be:
  
[[File:media/folderstruct.png|182x218px]]
+
[[File:folderstruct.png|182x218px]]
  
 
=== CapabilityStatement  ===
 
=== CapabilityStatement  ===

Revision as of 23:54, 11 September 2018

Creating and publishing an ImplementationGuide

This short documentation is meant to help editors or designers get started with FHIR Profile Publishing, and will progress towards an official IHE FHIR Profile Publishing mechanism. This is a wiki page - it is intended to change rapidly.

This page contains MUCH MORE details than will typically be needed. The IHE and HL7 communities, the IHE FHIR Workgroup and IHE Documentation Workgroup are looking at providing solutions so that editors do not need to understand all these details but can focus on editing content, leaving most of complexity behind. These details are here while IHE works towards those solutions.


Concepts

To publish a profile, we need:

  1. The definition or source of the profile – what it is, what is the content.
  2. The ImplementationGuide Publisher or IG Publisher, maintained by HL7®.
  3. The IHE IG template, which tells the IG Publisher how to generate and render the content. With this template, IHE defines:
    1. A standard look-and-feel
    2. Mandatory content
    3. Naming conventions
  4. A toolset to enable or accelerate preparing or editing the content

To enable the IHE editor community, IHE will also provide:

  • Publication space or platform – currently http://ihe.net/fhir/baseprofile
  • Ownership and governance – starting with a folder structure for different profiles
  • Collaboration and version management for the profile content – e.g. github or bitbucket. This will require defining branching policy, etc.

Source of the profile

The profile is defined by:

  • The FHIR® resources that will contain the computable part of the specification, and will be published in a standard, consistent way across all profiles:
    • ImplementationGuide – the “binding” resource that points to the remainder of the content
    • CapabilityStatement – A computable definition of the features of an IHE actor
    • StructureDefinition – Representing a set of constraints on specific FHIR® resources.
    • ValueSet – an official value set or glossary.
    • PlanDefinition – A formal definition of a workflow profile – including steps and constraints.
    • ExampleScenario – An implementation of the profile in one concrete case with real values.
    • Any resource can be used as part of an example
    • TestScenario – test content that implementers may use in a first validation of their implementations.
  • Rich text pages, for any other content.

We describe the basics of manual editing the content, but we aim at editing solutions. Existing solutions for editing the resources:

  • FHIR® Toolkit.
  • Firely Forge®

ImplementationGuide

An ImplementationGuide resource has the following structure:

  • ImplementationGuide – definitions of the ImplementationGuide itself, such as title, authors,...
    • Global (Not supported) – a pointer to global content reused in this profile
    • DependsOn (Not supported) – a pointer to a profile that this profile builds upon
    • Definition – a placeholder for the profile-specific content
      • Package(s) – a Package is a “grouping” element. For now, see it as “tag”.
      • Resource(s) – the FHIR Resources that are defined in this profile.
      • Page – The index page of the profile (the Table of Contents)
        • Page(s) – A profile will have a tree-like structure of pages, nested under each other.

The attributes in the ImplementationGuide resource are:

  • ImplementationGuide
    • id: Mandatory, should be the IHE profile acronym
    • name: A human-readable name
    • url: the authoritative url where this profile is going to be accessible.
    • status: the status (draft, active, retired, unknown)
    • experimental: true or false. For now, true.
    • date - the date of the last official editing of the profile.
    • jurisdiction - For now, due to template constraints, it must be US. This will change.
    • packageId - npm package name in the form ihe.fhir.dmn.prfl, wher dmn is the domain acronym and prfl is the profile acronym. Example: ihe.fhir.pharm.mma
    • Definition
      • Package
      • Resource - The resource file name must be:
      • Template

The implementationGuide shall be saved in the root folder for the ig.

Example: if the profile is called “base”, the root folder should be called “base” and in it there shall be a file “base.xml”.

Pages

Pages contain free content that users can add. Note that there will be fixed, mandatory pages for all IHE profiles. They will be provided with the base profile and IHE template.

A page will consist of:

  • an html file per page (saved with .xml extension). All pages will be saved in the folder <root>/content/pagecontent
  • the images or other media in the page will be saved in the folder <root>/content/images

e.g. if our “base” profile has 2 pages (toc and index) and index has one picture saved as “image1.jpeg”, the files in our “base” profile shall be:

Folderstruct.png

CapabilityStatement

StructureDefinition

ValueSet

PlanDefinition

ExampleScenario

Any resource

TestScenario