Following on from my post yesterday, Grahame Grieve commented that I had not dealt with issues of stability and commercial acceptability. I had not originally intended to do that, but on reflection, he is right – a standard that is going to survive and be worthy of wide-scale investment can’t be separated from its governance and commercial / legal situation. To address that, I updated the main article, here, and I have also revised the short list below. The shortest form of statement is provided by the blue headings on the left.

Necessary Characteristics for e-Health Standard Longevity and Investibility (v2)

• Platform-friendly
  • Platform framework: Does the technology define overall elements of a platform into which recognisable specifics could be plugged, e.g. information models, content definitions, workflow definitions, APIs, code generation tools, etc? OR
  • Platform component: Does the technology define something that can be properly integrated into an existing platform definition?
• Semantic Scalability
  • Domain Diversity: Does the technology provide a practical method of dealing with potentially massive clinical content diversity?
  • Local Variability: Does the technology provide a practical method of dealing with potentially massive localised variability?
  • Change over Time: Does the technology provide a practical method of dealing with ongoing change in information requirements due to, new science, -omics, drugs; new clinical protocols and methods; legislative changes; changing patient / consumer needs?
• Implementability
  • Does the technology provide an automatable way for clinically complex models to be consumed by ‘normal developers’ to build ‘normal software’, including for the purpose of integrating with existing systems, data sources and sinks?
• Utility
  • Data accessibility: Is the standard designed such that all data elements are easily computationally accessible at the finest granularity?
  • Query methodology: Does the technology provide a way to query fine-grained information based on models of content, not physical representation (physical DB schemas, specific XML doc schemas etc)?
• Responsive Governance
  • Domain-led requirements: Are requirements statement and prioritisation led primarily by domain experts?
  • Industry-led roadmap: Can the roadmap of future releases, i.e. allocation of changes and timing of each release be influenced by industry implementers?
  • Release stability: Are releases over time are coherent with respect to each other in ways that enable economic upgrading of implementations (industry side) and smooth deployments of new versions (user / provider side)?
  • Responsive feedback mechanism: Does a visible and easy-to-use mechanism for reporting issues and problems with all levels of artefact, i.e. requirements, current release, reference implementation(s)?
  • Accountability: Is the governing organisation transparently accountable to key stakeholders for the outputs of the organisation?
• Commercial Acceptability
  • Free core IP: Are the standard and its core computable artefacts free to use?
  • IP openness futureproof: Are there mechanisms to prevent the IP of the standard and related artefacts from being unilaterally privatised or otherwise made commercially unacceptable over time, including to small companies and user organisations?