1. Published Name of the Standard for which request is being made (if previously published)

FHIR Shorthand, Release 1

2. Standards Material/Document


3. Date of Request

Aug 24, 2020

4. Use Period

2 years

5. Reason for extension, timeline, and actions

6. Original Publication Date

7. End date of the current STU period

8. Length of the requested extension

9. Review Process

10. HL7 Work Group making this request and date

FHIR Infrastructure

10a. Requesting WG Date

Aug 24, 2020

11. URL of approval minutes


12. HL7 Product Management Group

FHIR Management Group

12a. Management Group Date of Approval

Aug 26, 2020

13. URL of approval minutes


14. Is the artifact ready for final publication?


15. If not ready, please describe remaining steps.

16. Tool name used to produce the machine processable artifacts in the IG

HL7 IG Publisher

17. The name of the “IG artifact” within the context of the above mentioned tool.

FHIR Shorthand

18. Balloted Name of the standard for which request is being made

FHIR Shorthand

19. Requested name for published standard. See Naming Examples

FHIR Shorthand

19a. Specification Feedback Name (For Search in Jira)

20. If CMET, list IDs balloted

21. Project Insight Number


22. Document Realm


23. Ballot cycle in which the document was successfully balloted


25. Affirmative


26. Negative


27. Abstentions


28. Not Returned


29. Total in ballot pool


30. Date on which final document/standards material was supplied to HQ

Aug 26, 2020

31. URL of publication material/ SVN repository


32. Publishing Facilitator

Mark Kramer

33. Special Publication Instructions

34. URL of ballot reconciliation document


35. Has the Work Group posted its consideration of all comments received in its reconciliation document on the ballot desktop?


36. Substantive Changes Since Last Ballot?


37. Product Brief Reviewed By


38. Date Product Brief Reviewed

Aug 24, 2020

39. Has the Product Brief changed?

40. Family


41. Section

Implementation Guides

42. Topic

43. Please Describe the Topic

A language for defining FHIR Artifacts (profiles, value sets, extensions, instances, and more), used to create implementation guides.

44. Product Type

Implementation Guide Tools

45. Parent standard


46. Parent Standard Status


47. Update/replace standard


48. Common name/search keyword

FSH, Shorthand, SUSHI, GoFSH, FSH Online, FSHing Trip

49. Description

FHIR Shorthand (FSH) is a domain-specific language (DSL) for defining the contents of FHIR Implementation Guides (IG). The language is specifically designed for this purpose, simple and compact, and allows the author to express their intent with fewer concerns about underlying FHIR mechanics. FSH can be created and updated using any text editor, and because it is text, it enables distributed, team-based development using source code control tools such as Github.

50. Stakeholders

Standards Development Organizations (SDOs)

51. Vendors

52. Providers

53. Benefits

FHIR Shorthand (FSH) simplifies the task of creating FHIR profiles, extensions, value sets, extensions and other artifacts needed for a FHIR IG. FSH provides a grammar is designed to express exactly what you want to do when profiling. It is a declarative language in which you specify what is to be done rather than how to do it. FSH language is readable and easily understandable. FSH is designed to be used with source code control-systems that support distributed development and meaningful version-to-version change tracking. FSH substantially speeds up IG projects.

54. Implementations/Case Studies

There are currently over 40 profiling projects using FHIR Shorthand. Examples include Logica COVID-19 FHIR Profile Library IG and the SANER (Situational Awareness for Novel Epidemic Response) IG.

55. Development Background

There are already several existing methods for IG creation: hand editing definitions, using Excel spreadsheets, Simplifier/Forge, and Trifolia-on-FHIR. Each of these methods have certain advantages as well as drawbacks:

* Hand-editing StructureDefinitions (SDs) is unwieldy, but authors get full control over every aspect of the resulting profiles and extensions.
* The spreadsheet method has existed since before FHIR 1.0 and has been used to produce sophisticated IGs such as US Core. A downside is that version management is difficult; either the files are saved in binary form (.xslx) or as XML files, with the content mixed with formatting directives.
* Simplifier/Forge and Trifolia-on-FHIR provide graphical interfaces that help guide users through common tasks. The potential downside is the need to navigate multiple screens visit different items and make cross-cutting changes.

Experience across many domains has shown that complex software projects are best approached with textual languages. As a language designed for the job of profiling and IG creation, FSH is concise, understandable, and aligned to user intentions. Users may find that the FSH language representation is the best way to understand a set of profiles. Because it is text-based, FSH brings a degree of editing agility not found in graphical tools (cutting and pasting, global search and replace, spell checking, etc.) FSH is ideal for distributed development under source code control, providing meaningful version-to-version differentials, support for merging and conflict resolution, and nimble refactoring. These features allow FSH to scale in ways that other approaches cannot. Any text editor can be used to create or modify FSH, but advanced text editor plugins may also be used to further aid authoring.

A reference implementation, SUSHI, has been created that compiles FSH into FHIR artifacts, ready for the HL7 FHIR IG Publisher.