-
Notifications
You must be signed in to change notification settings - Fork 15
Methodology
Profiling is the process of creating FHIR resources including:
- StructureDefinitions (profiles AND data dictionary items)
- ValueSets (standard lists)
- Conformance statements (client-server interaction patterns)
Profiling also creates documentation (e.g. patterns of use). Assets are held by the HL7-UK organisation on GitHub [https://github.com/HL7-UK]. Assets are licensed under Apache 2 license [http://www.apache.org/licenses/LICENSE-2.0]. Assets are managed by an editorial team representing stakeholders.
The repository uses the gitflow pattern [http://nvie.com/posts/a-successful-git-branching-model/], adapted for Care-Connect. Balloted versions of assets are published on the master branch. Latest versions of assets are available on develop branch.
Contributors are responsible for the customisation of resources to suit the requirements of the domain. The mechanism for contribution depends on the type of change:
New features are a set of changes that adapt and extend CareConnect to support a new functionality. For example, medications reconciliation or appointment booking.
- Contributors contact the CareConnect editors with details of the new functionality.
- Editors create a feature branch to hold the new functionality.
- Contributors create a GitHub account and fork the feature branch of the repository, editing as they wish. When a contributor has a change to propose they make changes to the feature branch by submitting pull requests. There are no restrictions on how a repository can be forked - individual contributors may fork a repository or an organisation may create their own fork to channel contributions.
- When the set of changes is complete the editors will promote the feature branch to the develop branch.
Small changes aren't adding new functionality, but are improving the quality of CareConnect. For example spelling corrections and clarifications.
Contributors create a GitHub account and fork the develop branch of the repository, editing as they wish. When a contributor has a change to propose they make changes to the develop branch by submitting pull requests.
Editors are responsible for coordinating the publishing of resources created by the community of contributors.
Editors review pull requests for consistency prior to merging into develop. Periodically, editors create a release candidate. Where appropriate, editors seek wider review of assets within release candidate including clinical review, connectathon testing. Following successful review, assets are marked as active and published to master branch.
Profiles should follow the HL7 FHIR standard so that standard tooling can be used.
These principles broadly adopt the established Code4Health interoperability community design principles [https://code4health.org/communities/interoperability/groups/design]
When sharing resources, enable information repositories to share freely i.e. provide flexibility to include whatever information that they are willing and able to share.
This means that:
- common profiles should rarely (if ever?) constrain out properties in the core profiles. As part of this, we need to carefully consider modifierExtension as this places constraints on the information consumers.
- common profiles should set minimum constraints necessary for interoperability within England (? UK), especially where we have an agreed national standard. For example, Patient.identifier should include an NHS Number, a CodeableConcept should include a SNOMED CT code etc.
- Where common elements can be identified, provide guidance on how to share them in a consistent way. For example, it's far more important to profile Address to provide a common definition than to require use of Address within every Patient resource (initially emphasise the data dictionary rather than the data model?).
When accepting resources, enable information repositories to constrain freely i.e. they must have flexibility to constrain the information they accept to reflect internal constraints and policies.
This means that:
common profiles should set only the minimum constraints necessary for interoperability within the UK. information repositories are responsible for publishing profiles describing the resources they accept. These profiles extend the common profiles and constrain out data items that can't be accepted. I would expect these profiles to be aggressive in how they constrain! There is nothing to preclude a special interest group defining a common profile that they use by mutual agreement.
Names will be informative to implementers and consistent across the profiles.
The scheme for profile naming is:
{{base}}-CareConnect-{{profile.name}}-{{major}}.xml The scheme for file naming is:
{{base}}-CareConnect-{{profile.name}}-{{major}}.xml The scheme for urls is:
https://fhir.hl7.org.uk/{{type}}/{{base}}-CareConnect-{{profile.name}}-{{major}}.xml
Resource versioning follows Semantic Versioning [http://semver.org/]. Resources carry major version in name (e.g. Extension-CareConnect-Foo-2) and major/minor version within StructureDefinition/Conformance.
Major versions will be maintained in parallel for a period of time before deprecation (period to be confirmed, but anticipated to be at least 12 months).
Contributions to this repository are encouraged.
Please submit your contributions as pull requests to the develop branch. It will be appreciated if the pull request description includes the rationale for the change!