Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
161
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
2
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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. What we have today Document schemas Message schemas GUI definitions + terminology … technically and organisationally disconnected… Standards for particular media Service interface schemas Terminologies SDO SDO SDO ??? ???
  • 14. .... and there are a lot of them... 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 v2 messages v3 messages Data types CCOW Other
  • 15. What we need… Document schemas Message schemas GUI definitions Standards for particular media Service interface schemas Terminologies Language of models of content & process Ontologies Models of content Models of interfaces Models of workflow A coherent semantic foundation Generation of concrete implementation specifications Models of information
  • 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. The platform architecture Service interface User interface Application Knowledge Repository other Service Data Repository Application documents models, ref data messages xxx
  • 19. What standards specify Document schemas Message schemas GUI definitions Application Knowledge Repository other Service Data Repository Application documents models, ref data messages xxx Service interface schemas
  • 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. So how should we make ‘standards’? Document schemas Message schemas GUI definitions Create a library of semantic definitions and tools + transformation tools … i.e. a ‘machine’ for generating ‘standards’… Service interface schemas Inside an open development and testing organisation
  • 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. 3GPP IMS ). - 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. What role in e-health for official SDOs? XXX.org Document schemas Message schemas GUI definitions Service interface schemas 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. 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