Version: 1.0.3

Last edited:  

Purpose

HL7-Denmark develops DK Core, a Fast Healthcare Interoperability Resources (FHIR) implementation guide (IG) containing core profiles for use in a Danish context. HL7-Denmark and MedCom has made a collaboration agreement, stating that MedCom is the steward and therefore responsible for gathering consultation responses for DK Core. Further, as steward, MedCom is responsible for the approach to decision of DK Core for the so-called “Rådgivende Udvalg for Standarder og Arkitektur” (RUSA), that among other things govern the Danish national standard catalogue within the healthcare domain. For the presentation for RUSA, a HL7-Denmark representative is invited to join the presentation.

The purpose of this document is to ensure transparency and quality of DK Core, both internally and externally, by defining and explaining the release process for DK Core.

Scope

Twice a year a new version of DK Core will be released, following the frequency of HL7-Denmark meetings. Hence a new release will be presented at every HL7-Denmark meeting. This process is chosen, as it ensures ongoing development and improvement of DK Core.  The responsible working group is called FHIR Special Interest Group (FHIR SIG).

DK Core is versioned according to the rules of semantic versioning (https://semver.org/), meaning that a version number e.g. 2.4.3 consist of major [2], minor [4] and [3] patch. In case of a major or minor release, DK Core is always presented to HL7-Denmark to get approval before a new version is published. The working group shall strive to keep the frequency of backward-incompatible changes (major version changes) at a minimum. The working group may publish patch releases whenever they are necessary, without discussion with HL7-Denmark. HL7-Denmark recommends to the steward which releases shall be subject for recommendation for decision of RUSA with the aim of including those releases of DK Core in the Danish national standard catalogue. Before a release is subject of recommendation, it is sent in for consultation.

This document concerns the release process of DK Core and handling of consultation responses from relevant parties. It describes the flow of events, roles, and responsibilities together with a checklist for each role.

Roles

The organization/person(s) responsible for a role may be changed, as both HL7-Denmark and FHIR SIG are dynamic groups with changing members.

Role

Responsibility

Who?

Owner

The overall responsibility concerning DK Core and what is released.

HL7-Denmark

Steward

Handles the consultation process with external parties and is responsible for presenting DK Core to RUSA. Further responsibilities are described in the collaboration agreement.

MedCom

Working group

The group responsible for the profiling and documentation of DK Core in accordance with best practise and clinical guidelines in Danish healthcare.

FHIR SIG

Author

Issue handler, develops new profiles, revises existing profiles, and tests the implemented changes. The author has the overall responsibility of implementing changes.

One or more members of FHIR SIG

Co-author

Contributes with content e.g. examples, text, profiling etc. to the author’s work.  

One or more members of FHIR SIG

Reviewer

Review changes before presenting changes for HL7-Denmark.

One or more members of FHIR SIG – other than the authors.

Contact person for DK Core

Handles incoming questions and requests.

MedCom*  

Release responsible

Handles release of DK Core.

One member of FHIR SIG

*Please contact on: hl7dkcore@medcom.dk 

Process

As mentioned above, does this document concerns two processes represented on: Figure 1 Process for change management of DK Core and Figure 2 Process for consultation responses of DK Core. After every HL7-Denmark meeting the process for change management in DK Core will be initiated and the work will continue until the following HL7-Denmark meeting. If the owner and the steward decide to go through a consultation of a new version of DK Core, the process for consultation responses of DK Core will be initiated.

Process for change management of DK Core

On Figure 1 is an illustration of the process for change management of DK Core. These steps are further elaborated below the figure. Between step 2 and 3 is repetition arrow, which is indicates that the working group discussions and the author implementing changes is a continuous iterative process before review.

Figure 1 Process for change management of DK Core

 

  1. Release planning between owner and working group.
    • The working group will suggest the content of the next release of DK Core to the owner at an HL7-Denmark meeting.
    • At the meeting, the owner and working group will agree on a prioritized list (backlog) of overall topics for the next release of DK Core. All topics will be created as issues in GitHub, to keep track of the working group’s work.
  2. Working group discussions
    • On regular meetings in the working group, relevant subjects concerning the next release of DK Core will be discussed. Members in the working group participate from different stakeholders, which mean that they all have different points of view and knowledge. All members can be found on Dansk Standards webpage. Discussions are both on a strategic and detailed level.
    • On the last meeting before the review, the working group agree on a proposed version number.
  3. Author and co-author implement changes:
    • Author and co-author implement changes and submit them for review. To implement changes involves profiling, creating instances of and documenting the IG. When committing changes to the IG, issues should be referenced if relevant.
    • The author is responsible for conformance testing the IG.
    • The author is also responsible for keeping track of changes and based on this formulating a description of what should be reviewed, which will be given to the reviewers.
  4. Reviewer performs a review of the changes:
    • The reviewer will review the changes, with focus on abovementioned description.
  5. Working group discusses the comments from the review
    • At a working group meeting, the working group will discuss the comments from the review.
  6. Does the review result in extensive changes in DK Core?
    • In case the comments from the review result in extensive changes in DK Core, the process goes back to the working group for handling. Extensive changes could be principial changes, changes in elements of a profile or considerable additions to the documentation, the working group needs to discuss and plan the appropriate actions to take.
    • If the comments from the review results in no or insignificant changes only in the documentation, DK Core is approved after updates. Insignificant changes could be to clarify the documentation and correct obvious errors.
  7. Does changes result in a patch change?
    • If the changes only result in a raise of the patch number, the working group is allowed to publish DK Core after review, as described in step 10.
    • If the changes result in a raise in the minor or major version number the changes must be presented to the owner as described in step 8.
  8. Presentation of DK Core to Owner:
    • The approach to decision is made by the working group to the owner. It should contain:
      • A description of the changes, so the owners can review the content of the release.
      • A subtract of the principal discussions the working group has had since the last HL7-Denmark meeting.
    • The changes made in DK Core is presented to the owner at the semi-annual meeting.
  9. Are changes in DK Core approved or conditionally approved?
    • Approved: The owner approves the changes. DK Core can now be released.
    • Conditionally approved: The owner may agree that certain changes should be made before release. A proposal cannot be conditionally approved if the condition results in a breaking change. In this case the proposal is rejected.
    • Rejected: The owner rejects DK Core meaning that the changes must be revisited and edited by the working group. The changes will then be a part of the following release.
  10. Release of DK Core.
    • Release responsible publishes the new version of DK Core Implementation Guide.
    • The issues that have been handled in the release, will be closed by the author.
    • DK Core is published in a new version, the history-note is updated with a description of the changes and the HL7-Denmark landing page is updated if necessary.




Process for consultation responses of DK Core

Figure 2 illustrates the process for consultation responses of DK Core. These steps are further elaborated below the figure. On the first three boxes is a * instead of a number. This indicates that the steward invites stakeholders to consult DK Core. The process will be initiated when the owner and the steward decide to go through a consultation of a new version of DK Core.

Figure 2 Process for consultation responses of DK Core

Figure 2 Process for consultation responses of DK Core

  1. Possible solutions and recommendations are presented by steward to the owner
    • The steward will present the consultation response together with a recommendation of the following action to the owner.
  2. Owner prioritises the feedback
    • Based on the recommendations and consultation responses the owner will decide what changes should be applied to DK Core, if any. In case of extensive changes such as principial changes, changes in elements of a profile or considerable additions of the documentation, the owner shall decide whether they shall be a part of the next release, hence starting at step 3 on Figure 1. In case it is only a patch release, this may be published after implementation as described on step 10 Figure 1.
  3. Working group and author implements the prioritised feedback for an agreed version of DK Core.
    • Working group, author and co-author implements the prioritised feedback following the process described in Figure 1 starting from step 2 and 3. 

Responsibilities

Below are the responsibilities of the roles involved in development, quality assurance and release described.

Working group (FHIR SIG):

  1. Point out author, co-author, reviewer, contact person and release responsible.
  2. Hold working group meetings regularly. Decisions will be documented in minutes on Confluence.
  3. Create issues[1] and keep track of the issue list on GitHub
  4. Make decisions about the implementation of GitHub
  5. Seek information in the FHIR community and the Danish Health Care domain.

Author and co-author:

  1. Implement changes involves profiling of specific FHIR resources, creating invariants, instances, and documentation.
  2. Conformance testing the changes by building temporary IG using the publisher tools.
  3. Checking QA-report (Quality assurance report). If adding errors, these shall be handled. If adding warnings or information, these shall be handled or included in the ignoreWarnings-file.
  4. Committing the changes to the current branch or creating pull-request to another author with a description of the changes. The minimum requirement of the description is a reference to the GitHub issue, by tagging the issue, and a short description of the changes.
  5. Create a history-note of the changes.
  6. Create a description of the changes for the reviewer. This should at least include:
    1. Which changes and where they are made.
    2. Elaborating questions like, does the examples match the description, is the profiling aligned with the description or is specific parts clearly described.
  7. Create a description of the changes for the owner. This should at least include:
    1. Which changes and where they are made.
    2. A short description of the major discussion points and principal decisions.
  8. Closing GitHub issues after they have been handled and Dk Core has been published.
  9. Create a prioritized list of topics that the working group would like to work with in the following release period. Each topic should be supported with a short background describing why it is relevant.

Reviewer:

  1. Review the changes described by the author
    • Check wording and grammar
    • Is something unclear?
    • Missing information
    • Are the examples covering and meaningful?

 Release responsible:

  1. Release DK Core to hl7.dk as described on HL7-publication site.
  2. Handle eventual errors that occur in the QA-report.
  3. Check that the IG, including the history-page are correctly updated.

Documentation

Issues and changes planned for the coming release are documented as separate issues on GitHub under the issue-page. The issues with a milestone corresponding to the next release will be discussed on the working group meetings. Meeting minutes from these meetings are documented on Confluence. When an issue is discussed by the working group and implemented by the authors it will be closed on GitHub, but it is still possible to find under closed issues.  

When committing valid changes to a branch in the GitHub-repository, these will be published on https://build.fhir.org/ig/hl7dk/dk-core/ for 90 days. Further, a GitHub-action has been created, to ensure that the changes are always available on https://hl7dk.github.io/dk-core/. All published versions of DK Core can be found on https://hl7.dk/fhir/core/history.html.

Webpages

Who?

What?

Where?

Dansk standard

Introduction to HL7-Denmark and application for membership

https://www.ds.dk/da/udvalg/kategorier/sundhed/hl7-denmark

Owner

HL7-Denmark landing page

https://hl7.dk/

Working group

DK Core IG

https://hl7.dk/fhir/core/index.html

Working group

FHIR SIG meeting minutes

https://confluence.hl7.org/display/HD/HL7+Denmark+Home

Working group

GitHub repository including code for generating the IG.

https://github.com/hl7dk/dk-core

[1] No closed issues should be reopened. In this case, a new issue should be created.

  • No labels