The crisis in ‘standards’ in e-health

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

2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Serviceinterfaceschemas Terminologies SDO SDO SDO ??? ??? What we have today Standards for particular media Documentschemas Messageschemas GUIdefinitions + terminology …technically and organisationally disconnected…

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

15. Serviceinterfaceschemas Generation of concreteimplementation specifications Models of interfaces Models of content Terminologies Models ofinformation Models of workflow A coherentsemantic foundation Language of modelsof content & process Ontologies What we need… Standards for particular media Documentschemas Messageschemas GUIdefinitions

16. + 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. + 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. Application Application messages DataRepository KnowledgeRepository otherService documents models, ref data xxx User interface Service interface The platform architecture

19. Application Application Serviceinterfaceschemas messages DataRepository KnowledgeRepository otherService documents models, ref data xxx What standards specify Documentschemas Messageschemas GUIdefinitions

20. 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. Serviceinterfaceschemas Inside an open development and testing organisation So how should we make ‘standards’? Documentschemas Messageschemas GUIdefinitions + transformation tools Create a library of semanticdefinitions and tools …i.e. a ‘machine’ for generating ‘standards’…

22. 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. 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. 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. 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. 3GPPIMS). - wikipedia IETF article, 2009

26. 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. 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. ISO SDOs could approve particular releasesrequired by industry Serviceinterfaceschemas Documentschemas Messageschemas GUIdefinitions CEN HL7 ASTM And should consider transferring most existingactivities and resources into the .org What role in e-health for official SDOs? XXX.org

29. 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. 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. 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. 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. 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. 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