Does anyone actually understand what terminology is for?


I really wonder sometimes. A few months ago, an international organisation that has been looking at how to solve the requirement for scalable, sustainable content modelling (research data sets) did some trialling on the use of archetypes. This worked fine as far as it went. I subsequently received an email to do with what they would do, that contained the line

“There has also been talk in our senior management about using SNOMED for this type of requirement”.

More recently, a colleague from Norway posted on the openEHR list various quotes from a Gartner report that was commissioned by the Norwegian government. The one most relevant here is (this comes from a Norwegian report):

“National ICT has chosen archetypes as a method for structuring EHR data. It is unclear whether other options have been considered, for example SNOMED-CT in combination with ICD-10 as used in many of the leading systems internationally.”

Where to start with this? It appears that the authors don’t know the difference between terminology and information models.

Read the rest of this entry »

What is a ‘standard': legislation or utilisation?



Bert Verhees, a colleague from the openEHR community made this post recently to the openehr-technical mailing list:

OpenEHR is not a standard, it is a formal specification.
 ISO, What is a standard: 
 "A standard is a document that provides requirements, specifications, guidelines or characteristics that can be used consistently to ensure that materials, products, processes and services are fit for their purpose."

I’ve grappled with this question many times over the last 20 years. My current thinking is as follows.

Read the rest of this entry »

Health interoperability standards are a pre-platform concept. Discuss.


There is a growing recognition that we need an open platform concept to solve e-health interoperability and reuse problems. Some evidence of this I noted in my recent post ‘What is an open platform’, including various US-based cross vendor platform alliances. The great value of a well-designed open platform is that it enables two things:

  • a growing platform-based economy of producers to collaborate technically while operating commercially and/or in an open source mode
  • adaptation to the constant stream of new requirements.

This is in contrast to the typical de jure standard based on a particular use case: it solves a locked down definition of the problem in a locked down way. Read the rest of this entry »

openEHR 2014 Roadmap Meeting, Sep 16/17, Oslo


Last week saw the first major face-to-face international openEHR community meeting, which took place in Lilletstrom, near Oslo, at premises kindly organised by DIPS asa, openEHR Industry Partner and major EHR supplier in Norway.


The remaining hard core at end of day 2 (photo: Dr Shinji Kobayashi)

Read the rest of this entry »

Evaluating e-health standards II – governance and commercial aspects


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?

Beyond the hype: evaluating e-health standards


A new e-health standard comes along every couple of years. In Gartner hype cycle terms, it starts out on the rise toward the ‘peak of inflated expectations’, then falls into the ‘trough of disillusionment’, before either dying or rising again over the ‘slope of enlightenment’ to a ‘plateau of productivity’. Most standards and e-health technologies (standards + their tools and artefacts) die before getting to this plateau. But why? What’s wrong with them? How can we pick a winner?

(Gartner Hype Cycle, from wikipedia)

The latest hyped e-health technology is of course HL7 FHIR – Fast Healthcare Interoperability Resources.

Read the rest of this entry »

ONC Hearing on the JASON Report – openEHR perspective


Recently I was asked to provide testimony to the ONC hearings on the JASON report, from an openEHR point of view. I did so on 31 July 2014. The JASON report is entitled “A Robust Health Data Infrastructure”. It surveys the problems of health data interoperability, and proposes the adoption of a unifying ‘software architecture’ as the solution. It also seems to imply a federated health record database. It’s primary assumption appears to be that APIs are the key element of the solution, and that their standardisation will fix the problem. Read the rest of this entry »


Get every new post delivered to your Inbox.

Join 165 other followers