Metadata Requirements for Health Portals

Tim BensonAbies Ltd, R-Outcomes Ltd, UCL

tim.benson@abies.co.ukMIE 2015 Madrid, 28 May 2015

Outline

• Why metadata matters• XDS Cross Enterprise Document Sharing• Clinical documents and clinical

statements• Specific requirements and items needed• Stringent standards that are fit for

purpose

Background

• Wellcome Trust Sintero Project project leader Dr E Conleyhttp://sintero.vargula.co.uk/

• IHE UK Affinity Domainhttp://wiki.ihe-uk.org/XDS_Metadata_specifications

• Principles of health interoperability HL7 and SNOMED Springer 2012http://www.springer.com/gb/book/9781447128007

What is Metadata?

• Metadata describes other data • Used for indexing, discovery and

search• Provides information about what

sort of things an item contains– Metadata is not an abstract– It says an entry contains a diagnosis,

but does not say what the diagnosis is– This helps in information governance

Dublin Core Metadata Element Set

• All elements are optional and repeatable

• Mostly free text• Designed by

librarians for librarians

• Mainly for paper archives

1. Title2. Creator3. Subject4. Description5. Publisher6. Contributor7. Date8. Type9. Format10. Identifier11. Source12. Language13. Relation14. Coverage15. Rights

6

Acute Care (Inpatient)

GPs and Clinics (Ambulatory)

Long Term Care

Other Specialized Care(incl. Diagnostics Services)

Patient Longitudinal Record

Typically, a patient goes through a sequence of encounters in different Care Settings

Source: IHE

XDS

• IHE XDS Cross-enterprise Document Sharing

• Based on ebXML Registry Standard (ISO 15000-4, 2004)

1. Sources post document packages to the Repository

3. Consumers search for documents with specific information

2. Repository registers the documents metadata and pointer with the Registry

4. Consumers retrieve documents from Repository (-ies)

XDS Document (Metadata):

TypePatientAuthorFacilityAuthenticator…

Repository

Origin of Documents Package

Registry

How XDS WorksConsum

er

Source: IHE

XDS Metadata handling

Patient Identity Source

Document Registry

Document Repository

Document Source

Document Consumer

Patient Identity Feed

Query Documents

Retrieve Document

Provide and Register

Document Set

Register Document Set

Generates

Stores

Interprets

Adds

Source: IHE

Documents and Statements 1/2

• Clinical Document is discrete electronic composition about one patient, intended to be read or used by a human.

• Clinical Statement is the smallest meaningful category of stand-alone medical information. A single data entry.– Statement is a very small structured

document

Documents and Statements 2/2

• Different uses and granularity• Both share properties of

– Persistence, wholeness, coherence, human readability, stewardship and authentication

– CDA, XDS and FHIR share these ideas• Both require search, sort and display

by type, date, author, source

Clinical Document

• Traditional document metaphor• Human-to-human communication of

discrete documents • e.g. pdf report or letter, image, video

• Sharing across organisation boundaries• Computer-processable data is hard to

extract – e.g. HL7 CDA Level 3 does not work as

well as expected

Clinical Statement

• Computer-processable data entries– Data that can be counted, analysed and

charted• Content is unambiguously coded and

tightly specified– e.g. diagnosis, medication entry, test

result– select and sort statements from multiple

sources on the fly for lists, charts and graphs

Health Metadata

• IHE XDS– Affinity domain– Based on ebXML Registry

• HL7 CDA header– Templates

Basic Requirements

• What• Who by• Who about• When• Where• Form

I keep six honest serving-men (They taught me all I knew);Their names are What and Why and When And How and Where and Who.

Rudyard Kipling. The Elephant’s Child. Just So Stories. 1902

Optionality

• Completeness • If search fails to find something, big safety

risk• Mandatory elements

– One patient– One creator– One creation time– One purpose

• In metadata optionality and repeats are bad

We need Standards

• Every source feed must provide exactly the same metadata– Else data won’t be found

• Stringent computer-processable data– Unique identifiers for things, people and

places– Codes for concepts + content (SNOMED CT)– Date/time formats

What 1

• Title (free text)• Class – general category, course

granularity – Note: HL7 CDA does not have a slot for this– Equivalent to HL7 RIM classCode +

moodCode• Type – specific category, fine granularity

– Equivalent to HL7 RIM code• Specialty – clinical service • CareType – care setting

Examples

Example Document Statement

Title Urology discharge

summary Weight entry

Class Correspondence Finding

Type Discharge summary Weight

Specialty Urology General Practice

CareType Inpatient Primary care

What 2

• UUID• OriginalID• Confidentiality• Language• Format

• Class, Type, Specialty, CareType, Confidentiality, Language and Format use SNOMED CT RefSets

Other

• When– CreationTime– EventTime

• Who– PatientId– CreatorId

• Where– LocationId

• Extensions– Tag (optional, repeatable) using SNOMED CT RefSet

Discussion

• Every source system must provide standard metadata– Allow default when not known

• All items (except Title) are structured and computer-processable– Codes use SNOMED CT RefSets

• Same structure for documents and statements• Lack of metadata standards means that portal

projects are – (1) expensive – (2) incompatible

Summary

• Why metadata is crucial in portals• Documents and statements have

similarities• XDS and CDA• Specific requirements• Need stringent metadata

standards• Low hanging fruit

Questions

tim.benson@abies.co.uk