This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

FHIR Tooling Eco-system

From HL7Wiki
Revision as of 15:32, 10 September 2017 by Lmckenzi (talk | contribs)
Jump to navigation Jump to search

This page is a draft. Once complete, review and consensus will be sought by current FHIR tooling participants


This page describes the FHIR tooling eco-system and the vision for its future development, including the FHIR community's collective view of what types of tooling are needed, how those tools might best interact with each other and how the tooling community itself will interact and collaborate to maximize the benefit of its collective investment. It also serves as an entry point for those who are new to the FHIR tooling community and are interested in what tooling is available and/or how they might best contribute to the community.

We recognize that developers of tools will do so for their own reasons and to meet their own needs. This document has no binding force on anyone who wishes to go forth and build FHIR tooling. However, by working together with the community and by adhering to the principles and processes described here, developers are more likely to create tools that work well together and provide a better experience to their user community.

This is a living document. It will evolve as the needs and vision of the community change.

Contents

The community

Who and what is the FHIR tooling ecosystem?

The FHIR tooling ecosystem is the collective set of tools that support the development and maintenance of FHIR artifacts - both FHIR specifications and FHIR implementations. I.e. It is software that supports FHIR. It does not include the systems that actually use FHIR to deliver healthcare services (registries, decision support, clinical systems, etc.). Principally, the ecosystem will be those tools that make use of the Conformance resources. Many of the tools will be FHIR-specific, but some will support a variety of standards including non-HL7 standards.

It's entirely possible for FHIR tooling to be developed that provides re-usable plug-and-play components for other features such as document authoring, order set creation, etc. Such tools are not covered here.

The set of tools within this ecosystem are and will continue to be developed by a variety of stakeholders including HL7 international and its volunteers, HL7 affiliates, other standards development organizations (SDOs), researchers and the implementer community. HL7 does not place restrictions on who can develop FHIR-related tooling, beyond the [licensing constraints on the use of the FHIR name and logo]. Similarly, the concepts expressed here are not an exhaustive list of what tools might potentially exist. New contributions and ideas are welcome.


How do I engage with the FHIR tooling community?

The FHIR tooling community, like the FHIR implementer community, is global. It lives both within the standards space (principally under HL7, though also under other SDOs) as well as within the FHIR implementer community as represented by the FHIR Foundation.

Within HL7 tooling issues are primarily dealt with by the [FHIR Infrastructure] (FHIR-I) work group. Oversight of tooling related to the development and publication process is provided by the [FHIR Management Group] with the support of the HL7 Publishing work group and overall oversight by the Technical Steering Committee and HL7 CIO. Work happens both at [HL7 Working Group Meetings] as well as on [FHIR-I conference calls].

Within the implementation community, discussion and coordination primarily happens on the [chat.fhir.org] discussion space. Discussions about general FHIR tooling issues, tooling integration issues and even updates to this page, happen on the [tooling] stream. However, conversations about more specific types of tooling also happen on other streams including:

New participants are welcome, but are encouraged to read the [community expectations]. Participants do not need to be HL7 members, though membership is encouraged to better support the FHIR community as a whole.

Being a committer

Tooling projects sponsored by HL7 will typically have their source managed under HL7's SVN () or GIT () environments. Read-only access is available to everyone. Committer access can be received by emailing lmckenzie@gevityinc.com. To gain committer privileges, send an email to lmckenzie@gevityinc.com stating the following:

  • That you've read and agree to abide by chapter 16 of HL7's Governance and Operations Manual (GOM)
    • The chapter deals with IP rights, patents, etc.
  • That you are signed up for and agree to actively monitor the [Committer's stream] on chat.fhir.org
    • Specifically that you will abide by freezes or other constraints on committed content and that you'll monitor commits to ensure they don't break anything
  • What SVN or Git user id should be granted the access


The architecture

Key requirements

The following represent ideals we encourage FHIR tools to meet. Aligning with these requirements will maximize community benefit for the tool

  • Modular: Tools should be designed in such a manner that their features can be leveraged by tools developed by others and also to be able to leverage tools created by others. Ideally, the user of the tool should be able to configure which of the available implementations of a particular piece of functionality will be used.
  • Standardized interfaces: To allow tools to integrate, standard interfaces and integration points are needed. One of the main purposes of this document is to identify and define such interfaces.
  • FHIR artifacts as interface: Tools should consume and/or produce artifacts that are conformant with the FHIR specifications. Tooling should work with the XML and JSON version of FHIR artifacts or with the .zip and .pack files produced by FHIR publishing processes. Any additional custom files or configuration files should be kept to a minimum - and ideally discussed within the tooling community to see if the needs might be met in an interoperable way through FHIR resources.
  • Extensible: It should be possible (and ideally easy) to extend the tool to accomodate extensions that may be defined to add capability to Con artifacts being produced or manipulated.
  • Version independent: While tools are expected to be dependent on specific versions of conformance resources, they should be able to work with other versions of the FHIR specification (including draft versions with new resources and complex data types) so long as the conformance resources defining the content is available.
  • Multiple OS support: At a minimum, FHIR tools should run on Windows and on Macs within common Windows emulators. Ideally, tools should run on Windows, Mac and Linux without emulation.
  • Free for use: Essential functions should not require payment. HL7 tries hard to ensure that there are minimal financial barriers to using the FHIR specification. While open-source is encouraged, other financial models such as freemium, "pay what you can", "paid support" are welcome as well.
  • Escrowed source: Non-open source tooling implementers are encouraged to keep source in escrow to be made available to the FHIR foundation should the authoring organization no longer be able/willing to maintain the tooling going forward
  • Multi-language: Tools should be written in such a way that their user interfaces can support labels and instructions in a variety of languages if the FHIR community chooses to provide the needed translations.

Integration Mechanisms

There are a number of ways to allow different tools to interact together:

Shared files

Tools can operate on a shared repository of conformance instances, either in a local persistance structure or in a #registry_tooling registry. Files containing individual resources or resource bundles can also be passed as an argument when invoking a tool and/or returned as the result when invoking a tool.

RESTful operation invocation

Server-hosted tools can have their behaviors invoked by calling operations defined on those servers.

Library integration

One tool can be packaged inside of another tool and have its functions directly invoked by library calls

CDS Hooks

todo: Grahame or Josh to explain how this would work


Tooling Environments

FHIR tooling requirements (those identified to date at least) can be organized into a set of sub-ecosystems:

Design Tooling

These tools support the creation and editing of the various conformance artifacts used to define both the FHIR specification itself as well as implementation guides and other packages of conformance artifacts. Without this tooling, artifacts must be hand-edited using one of the FHIR syntaxes which requires a much steeper learning curve and is more error prone. It is unlikely that a single tool will support all resources.

Relevant Specification References

All of these artifacts should (eventually) have authoring and editing tools. They are grouped into related areas:

Implementation Guides:

Terminology:

Others:

In addition, the [Binary] resource may be used to convey images, page text and other content for inclusion in the publication.

Other areas of interest include:

operations.html messaging.html profiling.html Profiling FHIR


For comparing resources, the following operations may be helpful:

  • capabilitystatement-operations.html#conforms

Features

Must have:

  • load resources for editing and serialize resources once created/updated
  • render resources for the users doing editing/creation

Nice to have:

  • enforce design rules (both those in the core specification as well as in referenced/enforced conformance artifacts)
  • look up other artifacts for reference
  • provide general editing capabilities such as undo/redo; copy & paste, etc.
  • use WYSIWYG editing of markdown elements
  • show changes between two different artifacts or versions of an artifact

Potential Tool Relationships

Existing Implementations

todo - links

  • Forge - .NET (mac emulator friendly) tool that supports creation and editing of StructureDefinition (profile, logical model) and ImplementationGuide
  • Trifolia - supports creation and editing of StructureDefinition (profile), ??? others?
  • todo (what's the name?) Grahame's vocab tool - creation and editing of CodeSystems and Value Sets
  • todo mapping tool


Wish List

Eventually, we need good quality editors for all of the Conformance artifacts. However, CapabilityStatement, OperationDefinition, SearchParameter and TestScript are probably the most urgent.


Conformance Publication Tooling

This tooling takes a packaged set of conformance artifacts and renders them into a form suitable for implementers, analysts and others to navigate, read and understand the expectations of a particular implementation environment. Typically this is done as HTML, but PDF, wiki and other representations are also possible. In theory, this can include both tooling used to define the core FHIR specification as well as implementation guides. However, the core spec tooling is highly specialized a

Relevant Specification References

The most important resource is the [ImplementationGuide] as it defines the organization of all the content to be published.

Terminology:

Others:

In addition, the [Binary] resource may be used to convey images, page text and other content for inclusion in the publication.

Features

Must have:

  • Be able to interpret the ImplementationGuide resource to find the resources to package and publish - as per the organization defined by the ImplementationGuide
  • Generate a human-readable view of the package of resources
  • Package up the generated publication for sharing

Nice to have:

  • Support to publish all types of conformance resources
  • Include link navigation between specification elements and from specification elements to the relevant portions of the FHIR specification.
  • Validate that content is valid (valid examples, profiles, no broken links, etc.)
  • Support automatic publication as content is edited
  • Support publishing in alternative languages (if the necessary "translation" extensions are present)
  • Support searching of the content from within the specification interface

Potential Tool Relationships

Existing Implementations

  • Forge
  • Trifolia?
  • HL7 IG publisher

Wish List

  • Improved renderings for CapabilityStatement, OperationDefinition, CodeSystem, etc.
  • Renderings of any kind for MessageDefinition, GraphDefinition, NamingSystem
  • Additional rendering widgits that make artifacts easier to understand/navigate


Open Issues

  • It would be nice to be able to share code that renders artifacts across publication tools - how could we do this?
  • Need to agree on how much configuration should live inside the ImplementationGuide, how much should be external (but possibly shareable?) and how much should be tool-specific.


Reference Implementations

Reference implementations are sets of generated code that support implementation of FHIR instances in a particular programming language. These reference implementations provide a starting point for developers that allows them to avoid deciding how to represent FHIR objects within their environment.

Relevant Specification References

The key concepts needed to produce object or other language-specific representations of resources are found here:

The syntaxes to parse and serialize are found here:

Most reference implementations also provide build in support for "fixed" terminology bindings, leveraging information found here:

Reference implementations may also provide assistance with dynamic behavior, in which case, these links are also relevant:

Features

Must have:

  • Provide a language-appropriate representation of all resource elements
  • Can parse and serialize instances in at least XML and JSON

Nice to have:

  • Support parsing and serializing RDF
  • Provide helper support for REST, operations, messaging and/or documents
  • Provide helper support for search
  • Be available under an open source license

Potential Tool Relationships

Existing Implementations

Wish List

  • Additional languages of interest to a decent percentage of implementers?
  • Support for additional runtime dynamic behavior configuration based on the message definition, graph definition, operation definition and similar resources


Validation Tooling

This tooling allows instances of FHIR resources (including conformance resources) to be checked for validity against the FHIR resources that define them or against which they claim conformance.

Relevant Specification References

The two primary sources for validation information are:

In addition these resources can also provide information that is relevant to the validation process

The [Validating Resources] page covers the expectations of the validation process.

The [Resource/$validate] operation defines how validation is invoked as a service. It will return validation issues as [OperationOutcome] instances.

Features

Must have:

  • Ability to validate both XML and JSON resources of any type
  • Check structural and syntax validity of the instance

Nice to have:

  • Perform validation of terminology against specified bindings
  • Check FHIRPath constraints
  • Check references to external artifacts

Potential Tool Relationships

Existing Implementations

Wish List

  • Continue to build the test case library of both valid and invalid cases
  • Create validation libraries in additional languages
  • Refactor validator to provide multi-lingual support

Registry Tooling

Registries host conformance resources as publicly accessible websites that can be searched and navigated to find relevant resources. Registries allow implementers to leverage existing artifacts rather than creating their own. They also provide a means of ensuring that implementers get the most "current" version of a particular artifact.

Relevant Specification References

The most critical resources to

Terminology:

Others:

Features

Must have:

Nice to have:

Potential Tool Relationships

Existing Implementations

Wish List

  • Conformance Registry
    • curated publication
    • voting/comment/review
    • candidates: Furore


Terminology Tooling

description

Relevant Specification References

terminologies.html Terminology terminology-service.html Terminology Services codesystem-operations.html#lookup codesystem-operations.html#subsumes conceptmap-operations.html#translate conceptmap-operations.html#closure valueset-operations.html#expand valueset-operations.html#validate-code

Features

Must have:

Nice to have:

Potential Tool Relationships

Existing Implementations

todo: Tooling names

  • Health Intersections
  • Apelon
  • Art-Decor
  • VSAC


Wish List

???

Instance Maintenance Tooling

description

Relevant Specification References

Features

Must have:

Nice to have:

Potential Tool Relationships

Existing Implementations

Wish List

Implementation Test Tooling

description

Relevant Specification References

testing.html

Features

Must have:

Nice to have:

Potential Tool Relationships

Existing Implementations

    • Test servers
    • test clients
    • Candidates: TouchStone, Crucible


Wish List

  • Testing Service


Conversion Tooling

description

Relevant Specification References

mapping-language.html structuremap-operations.html#transform

Features

Must have:

Nice to have:

Potential Tool Relationships

Existing Implementations

Wish List

Collaborative Review Tooling

description

Relevant Specification References

Features

Must have:

Nice to have:

Potential Tool Relationships

Existing Implementations

Wish List

Support Services

XPath evaluation FHIRPath validation and evaluation Narrative generation Snapshot generation Narrative Generation

narrative.html http://hl7.org/fhirpath

description

Relevant Specification References

Features

Must have:

Nice to have:

Potential Tool Relationships

Existing Implementations

Wish List

Conformance / Design Tooling Ecosystem

A set of tools that support the process of working with resources and profiles on resources, and by extension, implementation guides. This includes content design tooling, code generation, publishing, and testing tooling

  • Conformance Service
    • CRUD on StructureDefinition, Conformance, OperationDefinition, SearchParameter, CompartmentDefinition, ImplementationGuide, TestScript
    • Operations: $generate-snapshot, $publish (for ImplementationGuide), $compare (StructureDefinition, OperationDefinition, Conformance)
    • cds-hook catalogue: reference StructureDefinition
    • candidates: Health Intersections, Furore?
    • Conformance Servers are recommended to implement the Server Actor in the FHIR Colloborative Review Implementation Guide

Open issues

  • Will need a good way to manage external files too - Basic resources with ad-hoc narrative for security, use-cases, etc; ability to manage Binaries for images, etc.

Terminology Tooling Ecosystem

A set of services that support operational use of terminologies. Todo: should this cover knowledge resources too (Medication, DataElement)?

Parts of the Terminology tooling eco-system

    • cds-hook catalogue: reference value set, reference display code
  • Terminology registry (does this need to be a terminology service too?)
  • Code System / Value Set / Concept Map Editor
    • find resource(file / registry)
    • display / edit them / preview outcomes (speculative evaluation)
    • import / export from other formats - excel, csv, ?...
    • save resource (file / registry - e.g. publish)
    • implementations: Health Intersections, Apelon, VSAC, Art-Decor, PenRad

Open Issues:

  • Do we want to add support for patch updates to better integrate with the whole notion of harmonization proposals? (Even if we don't use that process, we're going to want to allow submission of requests for addition of codes, changing individual definitions, etc. )

Collaborative Review Eco-system

The collaborative review system allows one user to invite a set of other users to make comments on a set of resources. Initially the application of this is to a review conformance resources, to help with distributed development, but it is anticipated to be suitable for use in clinical review processes.

Retrieved from "https://wiki.hl7.org/w/index.php?title=FHIR_Tooling_Eco-system&oldid=145417"