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

FHIR Methodology Process

From HL7Wiki
Revision as of 11:06, 10 December 2012 by Hugh Glover (talk | contribs) (→‎FHIR Meta-model)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

This page describes the process and considerations used when developing HL7 methodology. It covers where methodology is maintained, who develops it, how it is approved and how rigorously (if at all) various aspects of it get enforced.

Methodology Locations

FHIR Methodology is presently documented and maintained 3 ways:

FHIR Meta-model

The meta model used for FHIR resources is the [| Profile] resource. While designed to convey what resource profiles are intended to look like, it actually does a good job of defining what a resource itself looks like. It defines what data elements can be captured, what they mean, any constraints, what code lists are used and the definitions of the individual codes. This part of the methodology is maintained via the ballot process, both for defining the core resource and, eventually, through the vetting and approval of FHIR extensions to the Profile resource.

<HG>The FHIR ballot process is managed by the FHIR Management Group although content will be prepared by the FHIR Core team or the relevant Work Group</HG>

Technical Methodology

This part of the methodology explains the technical aspects of creating and maintaining resources. Essentially it explains how the current suite of tooling is used to create content reflecting the various elements of the FHIR meta-model. It also reflects constraints and extensions necessary to either work within the tool suite or to meet publishing objectives. This content can be found in the FHIR Guide to Authoring Resources.

This aspect of the methodology is primarily driven by tooling as maintained by the FHIR core team. Changes may be proposed to the FHIR Management Group. These will be evaluated on several criteria:

  • How much will the change benefit implementers attempting to use the specification?
  • Is the change aligned with the FHIR meta-model (some changes may require changes to tools and to meta-model)
  • How much impact will the change have on committees preparing resource content?
  • How hard will it be to incorporate the desired change in the tools

Content Methodology

This final part of the methodology covers the "quality" aspects of FHIR not directly enforced by the tooling. It provides the guidelines, best practice and quality checks to be followed when creating and maintaining resources. It is maintained in two places:

Both are maintained by the Modelling and Methodology Work Group, though submissions and minor edits to the wiki are welcomed from anyone.

Criteria for content methodology items include:

  • How and how much will adherence to the guideline or pattern be of benefit to the majority of implementers?
  • How much impact will adhering to the guideline have to the workload of Work Groups developing and maintaining the resource?
  • How broadly does the guideline apply (all resources, a large number of resources or only one or two)?
  • How subjective is the guideline - i.e. how easy will it be to evaluate whether the guideline is being adhered to in a given circumstance?

In cases where MnM determines that a particular guideline or pattern will make a significant difference to implementers, adherence may be made mandatory. This process will be initiated by a vote within the MnM working group and followed by a 2-week (or sometimes longer) discussion period on the FHIR list server, followed by a confirmation vote within the FHIR Management Group. The same process will be followed for making changes to an existing "mandatory" methodology element.