Later this month I hope to initiate a number of community “work packages” to assist the community in building interoperable FHIR based assets. We are still working out the details but current thoughts include:
Guidance for FHIR Naming schemes
Guidance for naming FHIR Profiles, ValueSets, Identifiers etc - how to avoid unintended collision between projects.
Guidance for versioning of FHIR assets (and identifying a version)
Community FHIR Profiles
To test the water in creating community FHIR assets then potentially we could start with the core building blocks of a system PATIENT, PRACTITIONER, ORGANIZATION, LOCATION etc
How do we profile these for community use? Too loose and they will inhibit innovation and supplier flexibility, too tight and they will inhibit adoption and innovation - discuss !
Ensure we have properly defined valueSets with cross-mappings if required
Where to the assets go - GitHub?
Whereas I will throw these out into the community as there is a benefit to “the centre” in the community working together to deliver these assets, there does need to be people who stand up and join the team to develop these.
I’m confident that more communication will follow via the Code4Health community but in the meantime if you think this is an area where you can provide input register your interest here and I’ll make sure you are “in the loop” when we initiate this work.
I think this would be appreciated and would like to be involved.
I suggest that assets are published on github, especially whilst in draft, as this provides for easy feedback. Follow the gitflow pattern so that drafts sit on a develop branch to which pull requests are submitted
Versioned (even if 0.0.1) assets are periodically published to the master branch.
I understand that git webhooks can be easily configured to automatically publish from github to Furore’s simplifier registry [https://www.simplifier.net/] which would provide an easy way to share the assets until such time as a UK-specific registry is available.
WRT how to profile resources, I propose supporting the following principles:
Share freely
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 the UK, especially where we have an agreed national standard. For example, Patient.identifier should include an NHS Number, a CodeableConcept should include a SNOMED 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?).
Accept grudgingly
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 (archetypes anyone? )
Naming schemes is the big one for me, I’ve not had a requirement to profile yet as most of my work has been internal but we’re now talking with neighboring trusts about document exchanges. So we’re likely to want to have a profile for DocumentReference and Patient (Practitioner and Organization) including code systems.
What I mean by core is something that says NHS Number should use this system, document class should be this NHS Specialty code, document type should be this set of ITK SNOMED codes. GPSoc and other schemes can constrain this as required and add extension - they would still be valid against the core profile.
In our TIE I’d want to use a loose NHS profile as a canonical model in the same way we use the NHS ITK HL7v2 schema (and DSTU2 FHIR). It’s relatively easy to modIfy systems and valuesets at the moment but the NHS (UK) ones are they worry as we don’t have control of them.
)