Registries and documents attain the status of being a standard of the HIS community through the process outlined below.
HIS Standards are managed by the HIS Registrar: Chris Maynard, OCI.
HIS (Harvest Information Standards) uses documents to define itself and to promote good practices. This document defines the overall standards process by which the HIS community develops and adopts those authoritative documents. After defining membership in the HIS community, this document defines the types of documents that are managed under this process. It also defines the life cycle process by which documents and their revisions attain official status within the community. A final section addresses the special case of routine updates to HIS data standards.
2. The HIS community
The HIS Registrar convenes and chairs the group of HIS Editors, facilitates the overall standards process, guards the overall integrity of HIS and facilitates the promotion and use of HIS standards in the wider mission information community. They are appointed by the HIS Editors on behalf of the HIS Stewards.
A HIS Editor is the primary curator of one or more HIS standards.
A HIS Steward is the host organization of a HIS Editor or the Registrar. The organization recognizes and supports the work its staff member is undertaking.
An interested party is a person with an interest in one or more HIS standards. Their interest is likely to be because they make use of the standard in some way, whether by embedding it into their own database or using it to join data from various sources. Or simply the existence and shape of the standard may influence their mission work in some way.
The HIS Registrar will maintain a mailing list of all these parties. HIS Editors should maintain their own mailing list(s) of people relevant to their own data area.
The HIS Editors, together with the Registrar serve as the decision-making authority on behalf of the whole community. When the HIS Editors decide on the status of a standard or document it shall be by prayerful consensus of the group.
When a new standard, or a substantial change to an existing standard is in prospect, the Registrar with the relevant Editor(s) will usually inform all Interested Parties and invite any who want to a video meeting. This is because those who are implementing the standards of the HIS community are the ones who have the biggest stake in the content of those standards. Thus they will be given opportunity to review every major proposal that comes before the HIS Editors. Interested Parties are encouraged to forward communications from the Registrar to others for whom they are relevant.
3. The document life cycle
This standards process defines how documents get endorsed and published by the HIS community. This involves the document moving through a life cycle that has six possible status categories. Each status is defined in terms of the activities that are required for advancing it to the next status.
A document has draft status as soon as it is written. Any individual or group may draft a document that they intend to submit to the HIS Editors for consideration to be adopted as a community document. When the creators of the document feel it is ready for consideration by the HIS Editors, they submit it to the HIS Registrar. The document achieves Proposed status when the HIS Registrar agrees that it is ready for consideration by the HIS Editors.
When a document achieves Proposed status, the HIS Registrar circulates it to the HIS Editors with a specific deadline for review. During that review period any Editor may solicit feedback from particular users they know to be significant stakeholders and enter their responses into the discussion. At the end of the review period, the HIS Editors may determine that the document should be either (a) withdrawn from the process, (b) revised and submitted again for review as a Proposed document, or (c) advanced to Candidate status (possibly with minor revision).
When the HIS Editors deem that a document is suitable for adoption it achieves Candidate status. The HIS Registrar now submits the document to the entire group of Interested Parties with a call for review. A specific deadline for submitting feedback should be communicated in the call for review. The review period may range from one to three months. A reminder will be sent out one week prior to the close of the review period. In the case of a review period longer than one month, a monthly reminder will be sent as well. In processing feedback, the HIS Editors may determine either (a) that the document is ready (possibly with minor revision) to be advanced to Adopted status, (b) that it should be revised and reviewed again in Candidate status, or (c) that it should be thoroughly revised and submitted again for review as a Proposed document.
A document may remain in the Adopted status indefinitely. It may be revised without changing status if the updates are simply editorial. Substantive changes should be handled as a new version of the document, which is submitted to the review process described here. An Adopted document’s status remains as Adopted until the HIS Editors decide to move it to Superseded or Retired status.
A document is automatically Superseded by the adoption of a newer version of the same document.
The status of a document changes to Retired when the HIS Editors determine that it is no longer relevant for the community. The proposal to move a document from Adopted to Retired status should first be submitted for review by the Interested Parties. As described for the transition from Candidate status to Adopted status, the HIS Registrar will send out a call for review on the proposal that the document be retired.
4. The data life cycle
The content of a standard – the codes, names and descriptions of each thing – are typically in some sort of data file.
The current version of content should typically accompany the definition and description on its way from “Draft” through to “Adopted” status. By the time it is presented to Interested Parties as “Candidate”, the content should be complete. Later content versions may not need to go through such a long process if the overall definition, description, and structures remains the same.
Each Editor has considerable discretion about the process for data updates but should make it easy for users to discover changes probably either by pushing out changes to a distribution list or by following a regular schedule of updates. They also have a role to play encouraging users to implement changes in a timely manner. Providing a change guide with each release can be helpful.