1. The crisis in ‘standards’ in e-health Thomas Beale September 2009

2. © Thomas Beale 2009 The Industry Need Healthcare is an information-intensive business. Healthcare data is captured piecemeal during clinical work processes but used in different ways by other processes. Clinical care of patients is shared among multiple provider enterprises (exacerbated by increasingly mobile citizens), requiring information sharing.

3. © Thomas Beale 2009 The Industry Need Healthcare is an information-intensive business. Information needs to be aggregated per- patient to be computable – to allow personalised healthcare & decision support and then across populations, for public health analysis and medical research. Healthcare information is complex and changing and therefore challenging to manage over time.

4. © Thomas Beale 2009 Semantic interoperability :== Meaning preservation – from the user interface to the back-end. Sharing – getting the data together. Aggregation – merging data from different sources and computing on it. Evolution – preserving and adding meaning over time.

5. © Thomas Beale 2009 What kind of solution do we need? Is it a message standard? Might be useful…. But what messages? We need hundreds! Ok… in that case, we need some kind of MODEL or LANGUAGE for expressing messages Maybe we can standardise on that… and define a method for creating individual message specifications… That would take care of the data moving between systems…

6. © Thomas Beale 2009 What kind of solution do we need? Is it a document standard? If a document is something we want to store in a system, then such a standard might be useful… But what kinds of documents? There are thousands of possibilities! Perhaps we also need some kind of MODEL or LANGUAGE for expressing documents… and a method for defining different types of documents and variations… That would take care of some data in systems…

7. © Thomas Beale 2009 What kind of solution do we need? Is it a SOA standard? Hm….if we could standardise on the INTERFACEs exposed by data repositories, then anyone could write software to talk to them! But interfaces contain functions that return data in the form of documents, or messages…. So we need those document and message standards…

8. © Thomas Beale 2009 What kind of solution do we need? Is it a User Interface standard? If we want to make sure human users interact consistently with the software – especially the WORKFLOW, we had better do something about screen layout, widgets etc But these need to be connected in a known way to the underlying data Do we need a MODEL of the user interface layout and workflow?

9. © Thomas Beale 2009 What kind of solution do we need? Is it a standard terminology? Well, we have standardised terms for some things, like diseases, lab concepts…. Agreeing to use these would help wouldn’t it? Yes, but they don’t do anything on their own, they need to be included in documents, messages…and we nearly forgot – the user interface!

10. © Thomas Beale 2009 What kind of solution do we need? Is it ontologies? That’s a deep question. What is an ontology? A: some kind of descriptive model of reality. We usually distinguish ‘upper level ontologies’ which are generic, and domain-specific ontologies We can think of ontologies as ‘statements of truth’ about things in the domain… so anything the data says should not violate the ontology So they could underlie the models of data, messages, documents and so on? Yes: ideally those MODELs need to be informed by ontologies

11. © Thomas Beale 2009 What kind of solution do we need? But wait, there are other dimensions to this problem….we also need: rules for ACCESS CONTROL IDENTIFICATION of artefacts SIGNING and AUDIT TRAILing of artefacts GOVERNANCE rules, defining development and dissemination processes, so that QUALITY can be assured

12. © Thomas Beale 2009 So all this means….? Firstly, it’s all connected…just like the systems in our requirements…which means the specifications need to be DESIGNED TOGETHER in a single framework Secondly, there is a difference between ‘standards’ for PARTICULAR MEDIA (e.g. a relational DB, an HL7v2 XML message) and technologies (.Net Winforms, Java Swing), and underlying SEMANTIC MODELS

13. © Thomas Beale 2009 What we have today Document schemas Message schemas GUI definitions Service interface schemas + terminology …technically and organisationally disconnected… Terminologies SDO ??? Standards for particular media

14. © Thomas Beale 2009 IHE HL7 IHTSDO ISO WHO CEN ASTM PDQ PMAC EN13606-4 RBAC Security SNOMED CT ICDx Terminology Services HSSP PIX HISA RID XDS EN13606-5 Content models EN13606-3 EN13606-2 Templates Documents CDA r2 EN13606-1 CCR CDA r1.... and there are a lot of them... v2 messages v3 messages Data types CCOW Other

15. © Thomas Beale 2009 What we need… Document schemas Message schemas GUI definitions Service interface schemas Terminologies Language of models of content & process Ontologies Models of content Models of interfaces Models of workflow A coherent semantic foundation Standards for particular media Generation of concrete implementation specifications Models of information

16. © Thomas Beale 2009 + a maintenance mechanism Historically, official standards organisations have had limited ability to maintain standards Yet no technical artefact is perfect in its first version - it must have a maintenance path! In the software world, maintenance means: Users being able to report issues & observe progress Obtain new releases or fixes The developers reacting and applying changes Issuing new releases

17. © Thomas Beale 2009 + an architectural notion The platform paradigm: Separation of back-end ‘services’ and front-end ‘applications’ Allows flexible composition of system Allows incremental deployment Avoids vendor lock-in Also known as ‘SOA’, services-oriented architecture (But note that many SOA advocates forget to specify the information…)

18. © Thomas Beale 2009 The platform architecture Service interface User interface Application Knowledge Repository other Service Data Repository Application documents models, ref data messages xxx

19. © Thomas Beale 2009 What standards specify Application Knowledge Repository other Service Data Repository Application documents models, ref data messages xxx Document schemas Message schemas GUI definitions Service interface schemas

20. © Thomas Beale 2009 Today’s situation… Amazingly, many countries entrust the creation of critical e-health standards to delegations attending committee meetings at organisations where: Development is done by ad hoc discussion and voting Unstated or non-existent technical paradigms No design process The ‘developers’ are people with limited or no technical competence and are self-chosen There is no software validation basis There is no maintenance path There are no reliable delivery timelines This is paralysing e-health programmes today…

21. © Thomas Beale 2009 So how should we make ‘standards’? Document schemas Message schemas GUI definitions Service interface schemas Create a library of semantic definitions and tools Inside an open development and testing organisation + transformation tools …i.e. a ‘machine’ for generating ‘standards’…

22. © Thomas Beale 2009 What about official standards? We have to ask the question: are they really needed in e-health? Let’s look at some existing standards that work: ‘small’ - ISO 8601:2004 – date/time string standard; widely implemented and used; ‘medium’ – W3C XML-schema – massive use in industry ‘large’ – IETF standards for the internet; foundational for modern society

23. © Thomas Beale 2009 ISO 8601:2004 This standard is needed because: Addresses a fundamental need – to communicate times & dates Needed within and between all domains, e.g. billing / defence / e-gov systems It is successful because: Spec is short, low complexity  implementable Very generic, used across many domains Very stable But… even this simple standard contains errors through not having been implemented and tested properly first Being an ISO standard, no agile means of maintenance

24. © Thomas Beale 2009 W3C XML schema 1.0 This standard is needed because: Addresses need for technology-independent representation of shareable data Very generic, used across many domains It is successful because: High perceived business value Massive $$ by companies spent over last 10y to create tools  disseminated via use of a few well-known tools, rather than re-implementation of paper specification It has a maintenance mechanism and path

25. © Thomas Beale 2009 IETF internet standards These standards are needed because: Collectively provide basis for information environment of modern civilisation They are successful because: Long gestation by engineers / universities Each spec only published when implemented in 2 places Each spec limited in scope, low coupling with others About 70 full standard RFCs Every addition was compatible with existing specs – principle of COHERENCE The details of its operations have changed considerably as it has grown, but the basic mechanism remains publication of draft specifications, review and independent testing by participants, and republication. Interoperability is the chief test for IETF specifications becoming standards. Most of its specifications are focused on single protocols rather than tightly-interlocked systems. This has allowed its protocols to be used in many different systems, and its standards are routinely re-used by bodies which create full-fledged architectures (e.g. 3GPP IMS). - wikipedia IETF article, 20093GPPIMS

26. © Thomas Beale 2009 What works? With large numbers of individual specifications that need to work together, the model that has worked in the past is exemplified by W3C and IETF… Individual membership by experts, not national ‘delegations’ Online community – mailing lists, wikis, online (free) specifications Work done mainly via open source & other implementations, i.e. by technical developers, not committees

27. © Thomas Beale 2009 The e-health domain What does e-health look like as a standards problem? Many parts, but all related – an ecosystem Multiple terminologies Information models Workflow / process definitions Clinical / domain models Numerous concrete representations – messages, documents, application screens This is a similar profile to IETF or the W3C family of standards

28. © Thomas Beale 2009 What role in e-health for official SDOs? Document schemas Message schemas GUI definitions Service interface schemas XXX.org ISO CEN ASTM HL7 SDOs could approve particular releases required by industry And should consider transferring most existing activities and resources into the.org

29. © Thomas Beale 2009 Key Principles Coherence: all models and specifications are developed in a SINGLE FRAMEWORK Filtering: any de jure standard that is to be used is re-engineered to a form 100% consistent with existing specifications Development paradigm: engineering analysis, design, implementation and validation process is used Maintenance: the mechanisms and organisational commitment for ongoing maintenance of the framework

30. © Thomas Beale 2009 Key Principles Openness: the organisation’s requirements and outputs are always open to inspection Computable dissemination: use in industry should be via small number of solid implementations and/or formal expressions, not continual re-implementation of paper specifications

31. © Thomas Beale 2009 Key lessons for governments ‘Choosing standards’ as a way of governments solving semantic interoperability is a fallacy – official standards in e-health are incoherent The official standards ‘development process’ cannot generate the required outputs because of the committee approach

32. © Thomas Beale 2009 Key lessons Instead, an open source.org approach is needed to create meaningful ‘standards’ Official standards bodies should be restricted to approving particular releases of particular specifications as having been quality- assured for use for a defined scope or purpose

33. © Thomas Beale 2009 Standards Reform in e-health …means building the.org(s): Only standing committees should exist, for defining requirements, and for review purposes All other work should be done by technical project groups All IP should be developed in a single coherent technical framework, consisting of: A published corpus of formal specifications Software implementations Other formal artefacts, e.g. schemas, models Open source tools should be available for parsing, viewing and editing formal artefacts If it is not formal, it does not compute!

34. © Thomas Beale 2009 Standards Reform in e-health Development environment including: Version and release management tools Online issue tracking Wiki Community environment including: Website, mailing lists, wiki Development done by recognised experts from industry & academia, organised into structured projects on the basis of capability Funded by beneficiaries, i.e. governments and industry