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

The crisis in ‘standards’ in e-health

Thomas BealeSeptember 2009

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


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.


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.


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…



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…



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…



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?



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!



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



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


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


What we have today

Documentschemas

Messageschemas

GUIdefinitions

Serviceinterfaceschemas

+ terminology

…technically and organisationally disconnected…

Terminologies

SDO SDO SDO ???

???

Standards for particular media


IHE

HL7

IHTSDO

ISO

WHO

CEN

ASTM

PDQ

PMACE

N13606-4

RB

AC

Security

SNOMED CTICDx

Terminology

Services

HSSP

PIX

HISA

RID

XD

S

EN13606-5

Content models EN

13606-3

EN

13606-2

Tem

plat

es

Documents

CDA r2

EN13606-1

CCR

CDA r1

.... and there are a lot of them...

v2 m

essa

ges

v3 messages

Data

types

CCOW

Other


What we need…

Documentschemas

Messageschemas

GUIdefinitions


TerminologiesLanguage of modelsof content & process

Ontologies

Models of content

Models of interfaces

Models of workflow

A coherentsemantic foundation

Standards for particular media

Generationof concreteimplementationspecifications

Models ofinformation


+ 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


+ 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…)


The platform architecture

Service interface

User interface

Application

KnowledgeRepository

otherService

DataRepository

Application

documentsmodels, ref data

messages

xxx


What standards specify

Application

KnowledgeRepository

otherService

DataRepository

Application

documentsmodels, ref data

messages

xxx

Documentschemas

Messageschemas

GUIdefinitions



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…


So how should we make ‘standards’?

Documentschemas

Messageschemas

GUIdefinitions


Create alibrary of semanticdefinitions and tools

Inside an opendevelopmentand testingorganisation

+ transformation tools

…i.e. a ‘machine’ for generating ‘standards’…


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


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


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


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, 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


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


What role in e-health for official SDOs?

Documentschemas

Messageschemas

GUIdefinitions


XXX.org

ISO

CEN

ASTM

HL7

SDOs could approve particular releasesrequired by industry

And should considertransferring most existingactivities and resources into the .org


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


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


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


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


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!


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

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

Documents

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