Achieving Healthcare Information Interoperability: A Wiki-like - - PowerPoint PPT Presentation

▶
achieving healthcare information interoperability a wiki
SMART_READER_LITE
LIVE PREVIEW

Achieving Healthcare Information Interoperability: A Wiki-like - - PowerPoint PPT Presentation

Dec 07, 2023 258 likes •1.43k views

Achieving Healthcare Information Interoperability: A Wiki-like Approach for Cutting the Gordian Knot David Booth, Ph.D. KnowMED, Inc. Latest version of these slides: @@@@ Associated paper: @@@@ Imagine a world 2 Imagine a world in which

slide-1
SLIDE 1

Achieving Healthcare Information Interoperability: A Wiki-like Approach for Cutting the Gordian Knot

David Booth, Ph.D. KnowMED, Inc.

Latest version of these slides: @@@@ Associated paper: @@@@

slide-2
SLIDE 2

2

Imagine a world

slide-3
SLIDE 3

3

Imagine a world

in which all healthcare systems speak the same language with the same meanings covering all healthcare.

slide-4
SLIDE 4

4

Healthcare today

Tower of Babel, Abel Grimmer (1570-1619)

slide-5
SLIDE 5

5

Different formats: Syntax

OBX|1|CE|3727-0^BPsystolic, sitting||120||mmHg| <Observation xmlns="http://hl7.org/fhir"> <system value="http://loinc.org"/> <code value="8580-6"/> <display value="Systolic BP"/> <value value="120"/> <units value="mm[Hg]"/> </Observation>

HL7 v2.x FHIR

slide-6
SLIDE 6

6

Different vocabularies & data models: Semantics

slide-7
SLIDE 7

7

Data transformation

Sender

HL7 v2.x

Receiver

FHIR Transform

OBX|1|CE|3727-0^BPsystolic, sitting||120||mmHg| <Observation xmlns="http://hl7.org/fhir"> <system value="http://loinc.org"/> <code value="8580-6"/> <display value="Systolic BP"/> <value value="120"/> <units value="mm[Hg]"/> </Observation>

slide-8
SLIDE 8

8

Syntactic and Semantic Transformations

  • RDF acts as a common substrate

language

  • Based on URIs as universal identifiers

Sender

HL7 v2.x

To RDF From RDF

Receiver

FHIR

Syntactic Syntactic RDF to RDF m1 m1 Semantic m2

slide-9
SLIDE 9

9

Why RDF?

Schema promiscuous

  • Blue App has model

Country Address FirstName LastName Email City ZipCode Blue Model

slide-10
SLIDE 10

10

Why RDF?

Schema promiscuous

  • Red App has model

HomePhone Town ZipPlus4 FullName Country Red Model

slide-11
SLIDE 11

11

Why RDF?

Schema promiscuous

  • Merge RDF data
  • Same nodes (URIs) join automatically

HomePhone Town ZipPlus4 FullName Country Address FirstName LastName Email City ZipCode Red Model Blue Model Country

slide-12
SLIDE 12

12

Why RDF?

Schema promiscuous

  • Add relationships and rules
  • (Relationships are also RDF)

HomePhone Town ZipPlus4 FullName Country Address FirstName LastName Email City ZipCode Red Model Blue Model Country subClassOf sameAs hasLast hasFirst

slide-13
SLIDE 13

13

Why RDF?

Schema promiscuous

  • Later add Green model

(Using Red & Blue models)

HomePhone Town ZipPlus4 FullName Country Address FirstName LastName Email City ZipCode Red Model Blue Model Green Model Country subClassOf sameAs hasLast hasFirst

Multiple models peacefully coexist

slide-14
SLIDE 14

14

Why RDF?

Schema promiscuous

  • What the Blue app sees:

– No difference!

HomePhone Town ZipPlus4 FullName Country Address FirstName LastName Email City ZipCode Red Model Blue Model Green Model Country Country Address FirstName LastName Email City ZipCode Blue Model Country

slide-15
SLIDE 15

15

Why RDF?

Schema promiscuous

  • What the Red app sees

– No difference!

HomePhone Town ZipPlus4 FullName Country Address FirstName LastName Email City ZipCode Red Model Blue Model Green Model Country HomePhone Town ZipPlus4 FullName Country Red Model

slide-16
SLIDE 16

16

Why RDF?

Schema promiscuous

  • What the Green app sees

– No difference!

HomePhone Town ZipPlus4 FullName Country Address FirstName LastName Email City ZipCode Red Model Blue Model Green Model Country HomePhone Town ZipPlus4 Country FirstName LastName Email Green Model Country

slide-17
SLIDE 17

17

Syntactic and Semantic Transformations

  • RDF acts as a common substrate

language

  • Based on URIs as universal identifiers

Sender

HL7 v2.x

To RDF From RDF

Receiver

FHIR

Syntactic Syntactic RDF to RDF m1 m1 Semantic m2

slide-18
SLIDE 18

18

Syntactic transformation to RDF

d1:obs042 a m1:PatientObservation ; m1:code "3727-0" ; m1:description "BPsystolic, sitting" ; m1:value 120 ; m1:units "mmHg" . OBX|1|CE|3727-0^BPsystolic, sitting||120||mmHg|

RDF

Sender

HL7 v2.x

To RDF m1 m1

slide-19
SLIDE 19

19

Semantic transformation RDF-to-RDF

CONSTRUCT { ?observation a m2:Observation ; a m2:BP_systolic ; m2:value ?value ; m2:units m3:mmHg ; m2:position m3:sitting . } WHERE { ?observation a m1:PatientObservation ; m1:code "3727-0" ; m1:value ?value ; m1:units "mmHg" . }

RDF to RDF m1 m1 m2

slide-20
SLIDE 20

20

Syntactic transformation from RDF

RDF

d2:obs-091 a m2:Observation ; m2:system "http://loinc.org/" ; m2:code "8580-6" ; m2:display "Systolic BP" ; m2:value 107 ; m2:units "mm[Hg]" . <Observation xmlns="http://hl7.org/fhir"> <system value="http://loinc.org/"/> <code value="8580-6"/> <display value="Systolic BP"/> <value value="107"/> <units value="mm[Hg]"/> </Observation>

Receiver

FHIR

From RDF m2

slide-21
SLIDE 21

21

Recipe for semantic interoperability

  • 1. Machine processable information
  • 2. RDF enabled
  • 3. Use standard vocabularies whenever possible
  • 4. Continually expand and update the set of acceptable standards
  • 5. All requested information should be RDF-enabled – not only standard

concepts

  • 6. Existing and new healthcare standards should have mappings to RDF
  • 7. Information should be self-describing
  • 8. Exchanged information should use free and open vocabularies
  • 9. Enact incentives for semantic interoperability
slide-22
SLIDE 22

22

How can we represent these transformations?

slide-23
SLIDE 23

23

Many ways . . .

  • Declarative style

– Ontologies v:Patient rdfs:subClassOf v:Person .

  • Procedural style

– Rules { ?p a v:Patient . } => { ?p a v:Person . } – Programs, e.g., Python, Java, C, etc.

  • Most important: Each transformation is identified

by a URI

slide-24
SLIDE 24

24

Where can we get these transformations?

slide-25
SLIDE 25

25

Data Transformation Wiki

  • Well, maybe not a wiki exactly, but wiki-like
  • Stores data transformation definitions

– Machine processable – Identified by URI

  • Allows automated lookup / download
  • Agnostic about what is included

Upload Upload Lookup / Download Lookup / Download

slide-26
SLIDE 26

26

Example scenario

  • Sender:

– Transforms internal format to RDF – Provides instance data in RDF – Class and property URIs indicate the vocabularies/data models used – Class and property URIs MUST be dereferenceable to definitions, i.e., as Linked Data

  • Receiver:

– Receives RDF data, and uses the wiki to lookup transformations for vocabularies / data models it does not understand – Downloads the desired transformations – Applies the transformations to the instance data

  • Instance data is now semantically aligned with receiver's ontology

– Transforms from RDF to internal format

slide-27
SLIDE 27

27

slide-28
SLIDE 28

28

Data Transformation Wiki

  • Wiki only sees metadata and transformation

definitions

  • Instance data is transmitted directly between

parties

  • Metadata /

Definitions Metadata / Definitions Instance Data

slide-29
SLIDE 29

29

Transformation metadata

  • Transformation identified by URIs
  • Indicates:

– Source vocabulary/data model – Target vocabulary/data model

  • Includes usage measure/ratings, e.g.:

– Objective: Number of downloads, Author, Date, etc. – Subjective: Who/how many like it, reviews, etc.

  • License information? – TBD

– E.g., allow commercial transformations?

slide-30
SLIDE 30

30

Centralization? Decentralized?

  • Need both standards and innovation
  • Wikipedia:

– Centralized place to go – Decentralized contribution

slide-31
SLIDE 31

31

Data Transformation Wiki

  • Everything identified by URIs – any granularity:

– Vocabularies – Data models – Terms – Transformations

  • Supports both standards and evolution of new terms

Upload Upload Lookup / Download Lookup / Download

slide-32
SLIDE 32

32

Issues

  • How to incent contributions of

transformations?

  • How to provide objective measures of

quality? E.g., number of downloads, who is using which transforms, etc.

  • Licensing: Allow commercial

transformations too?

slide-33
SLIDE 33

Questions?

slide-34
SLIDE 34

34

BACKUP SLIDES

slide-35
SLIDE 35

35

slide-36
SLIDE 36

36

slide-37
SLIDE 37

37

Negotiating natural language

I speak:

  • English
  • French
  • German

I understand:

  • English
  • French
  • German
  • Mandarin
slide-38
SLIDE 38

38

Negotiating healthcare language

I speak:

  • http://...SNOMED
  • http://...LOINC
  • http://...ICD9
  • http://...3MHDD
  • http://...ACME7

I understand:

  • http://...SNOMED
  • http://...ACME7
  • Identified by URI
  • Represented in RDF
slide-39
SLIDE 39

39

Standardization

Standard

  • PROS: Most efficient; desirable whenever possible

– Only need n transformations instead of (n-1)*(n-1)

  • CONS: Infeasible when committee/standard gets too big
slide-40
SLIDE 40

40

Standards and diversity

Std 1

  • Cannot stop the world to wait for

standardization!

Std 2 Std 3

slide-41
SLIDE 41

41

Key requirements

  • Continually incorporate new vocabularies

and data models

  • Support existing and future healthcare

standards

  • Support decentralized innovation
slide-42
SLIDE 42

42

Why include non-standard concepts?

  • Important to send all requested

information in machine-processable form

  • Receiver may be able to use it
  • Helps bootstrap standardization
slide-43
SLIDE 43

43

Additional requirements for graceful adoption of new concepts

  • Enable new concepts to be semantically

linked to existing ones

  • Enable authoritative definitions of new

concepts to be obtained automatically Best available candidate: RDF

slide-44
SLIDE 44

44

Why RDF?

slide-45
SLIDE 45

45

Why RDF?

1.Semantics, not syntax

slide-46
SLIDE 46

46

Why RDF?

1.Semantics, not syntax 2.Self describing – derefenceable URIs

slide-47
SLIDE 47

47

Why RDF?

1.Semantics, not syntax 2.Self describing 3.Schema promiscuous

slide-48
SLIDE 48

48

Why RDF?

Schema promiscuous

  • Blue App has model

Country Address FirstName LastName Email City ZipCode Blue Model

slide-49
SLIDE 49

49

Why RDF?

Schema promiscuous

  • Red App has model

HomePhone Town ZipPlus4 FullName Country Red Model

slide-50
SLIDE 50

50

Why RDF?

Schema promiscuous

  • Merge RDF data
  • Same nodes (URIs) join automatically

HomePhone Town ZipPlus4 FullName Country Address FirstName LastName Email City ZipCode Red Model Blue Model Country

slide-51
SLIDE 51

51

Why RDF?

Schema promiscuous

  • Add relationships and rules
  • (Relationships are also RDF)

HomePhone Town ZipPlus4 FullName Country Address FirstName LastName Email City ZipCode Red Model Blue Model Country subClassOf sameAs hasLast hasFirst

slide-52
SLIDE 52

52

Why RDF?

Schema promiscuous

  • Later add Green model

(Using Red & Blue models)

HomePhone Town ZipPlus4 FullName Country Address FirstName LastName Email City ZipCode Red Model Blue Model Green Model Country subClassOf sameAs hasLast hasFirst

Multiple models peacefully coexist

slide-53
SLIDE 53

53

Why RDF?

Schema promiscuous

  • What the Blue app sees:

– No difference!

HomePhone Town ZipPlus4 FullName Country Address FirstName LastName Email City ZipCode Red Model Blue Model Green Model Country Country Address FirstName LastName Email City ZipCode Blue Model Country

slide-54
SLIDE 54

54

Why RDF?

Schema promiscuous

  • What the Red app sees

– No difference!

HomePhone Town ZipPlus4 FullName Country Address FirstName LastName Email City ZipCode Red Model Blue Model Green Model Country HomePhone Town ZipPlus4 FullName Country Red Model

slide-55
SLIDE 55

55

Why RDF?

Schema promiscuous

  • What the Green app sees

– No difference!

HomePhone Town ZipPlus4 FullName Country Address FirstName LastName Email City ZipCode Red Model Blue Model Green Model Country HomePhone Town ZipPlus4 Country FirstName LastName Email Green Model Country

slide-56
SLIDE 56

56

Why RDF?

1.Semantics, not syntax 2.Self describing 3.Schema promiscuous 4.Neutral, mature, international standard

slide-57
SLIDE 57

57

Why RDF?

1.Semantics, not syntax 2.Self describing 3.Schema promiscuous 4.Neutral, mature, international standard Best available candidate for a universal healthcare exchange language!

slide-58
SLIDE 58

58

How?

slide-59
SLIDE 59

59

Semantic interoperability involves data transformations

How?

Sender1 Sender2

HL7 v2.x FHIR

Receiver

CSV Universal Healthcare Exchange Language

slide-60
SLIDE 60

60

Syntactic and Semantic Transformations

Sender1 Sender2

HL7 v2.x FHIR

To RDF To RDF To CSV

Receiver

CSV

Syntactic Syntactic RDF to RDF RDF to RDF m1 m2 m1 m3 Semantic

RDF

slide-61
SLIDE 61

61 Sender1 Sender2

HL7 v2.x FHIR

To RDF To RDF To CSV

Receiver

CSV

RDF to RDF RDF to RDF m1 m2 m1 m3

Sender1 data: HL7 v2.x

(Fictitious examples for illustration) OBX|1|CE|3727-0^BPsystolic, sitting||120||mmHg|

Sender1

HL7 v2.x

slide-62
SLIDE 62

62 Sender1 Sender2

HL7 v2.x FHIR

To RDF To RDF To CSV

Receiver

CSV

RDF to RDF RDF to RDF m1 m2 m1 m3

Sender2 data: FHIR

(Fictitious example for illustration)

Sender2

FHIR

<Observation xmlns="http://hl7.org/fhir"> <system value="http://loinc.org"/> <code value="8580-6"/> <display value="Systolic BP"/> <value value="107"/> <units value="mm[Hg]"/> </Observation>

slide-63
SLIDE 63

63 Sender1 Sender2

HL7 v2.x FHIR

To RDF To RDF To CSV

Receiver

CSV

RDF to RDF RDF to RDF m1 m2 m1 m3

Receiver data expected: RDF

d1:obs042 a m3:Observation ; a m3:BP_systolic ; m3:value 120 ; m3:units m3:mmHg ; m3:position m3:sitting . d2:obs-091 a m3:Observation ; a m3:BP_systolic ; m3:value 107 ; m3:units m3:mmHg .

Receiver

CSV

slide-64
SLIDE 64

64 Sender1 Sender2

HL7 v2.x FHIR

To RDF To RDF To CSV

Receiver

CSV

RDF to RDF RDF to RDF m1 m2 m1 m3

Step 1: Syntactic transformation

  • Transform from source format to substrate model (RDF)
  • Allows data to be merged
  • Data may not join semantically due to differing vocabularies

Sender1 Sender2

HL7 v2.x FHIR

To RDF To RDF Syntactic m1 m2

RDF

slide-65
SLIDE 65

65 Sender1 Sender2

HL7 v2.x FHIR

To RDF To RDF To CSV

Receiver

CSV

RDF to RDF RDF to RDF m1 m2 m1 m3

Sender1 syntactic transformation

d1:obs042 a m1:PatientObservation ; m1:code "3727-0" ; m1:description "BPsystolic, sitting" ; m1:value 120 ; m1:units "mmHg" . OBX|1|CE|3727-0^BPsystolic, sitting||120||mmHg|

RDF

Sender1

HL7 v2.x

To RDF Syntactic m1 m1

slide-66
SLIDE 66

66 Sender1 Sender2

HL7 v2.x FHIR

To RDF To RDF To CSV

Receiver

CSV

RDF to RDF RDF to RDF m1 m2 m1 m3

Sender2 syntactic transformation

RDF

d2:obs-091 a m2:Observation ; m2:system "http://loinc.org/" ; m2:code "8580-6" ; m2:display "Systolic BP" ; m2:value 107 ; m2:units "mm[Hg]" . <Observation xmlns="http://hl7.org/fhir"> <system value="http://loinc.org/"/> <code value="8580-6"/> <display value="Systolic BP"/> <value value="107"/> <units value="mm[Hg]"/> </Observation>

Sender2

FHIR

To RDF m2

slide-67
SLIDE 67

67

Step 2: Semantic Transformations

Sender1 Sender2

HL7 v2.x FHIR

To RDF To RDF To CSV

Receiver

CSV

Syntactic Syntactic RDF to RDF RDF to RDF m1 m2 m1 m3 Semantic

RDF

slide-68
SLIDE 68

68 Sender1 Sender2

HL7 v2.x FHIR

To RDF To RDF To CSV

Receiver

CSV

RDF to RDF RDF to RDF m1 m2 m1 m3

Sender1 semantic transformation

CONSTRUCT { ?observation a m3:Observation ; a m3:BP_systolic ; m3:value ?value ; m3:units m3:mmHg ; m3:position m3:sitting . } WHERE { ?observation a m1:PatientObservation ; m1:code "3727-0" ; m1:value ?value ; m1:units "mmHg" . }

RDF to RDF m1 m1 m3

slide-69
SLIDE 69

69 Sender1 Sender2

HL7 v2.x FHIR

To RDF To RDF To CSV

Receiver

CSV

RDF to RDF RDF to RDF m1 m2 m1 m3

Sender2 semantic transformation

CONSTRUCT { ?observation a m3:Observation ; a m3:BP_systolic ; m3:value ?value ; m3:units m3:mmHg . } WHERE { ?observation a m2:Observation ; m2:system "http://loinc.org/" ; m2:code "8580-6" ; m2:value ?value ; m2:units "mm[Hg]" . }

RDF to RDF m2 m3

slide-70
SLIDE 70

70 Sender1 Sender2

HL7 v2.x FHIR

To RDF To RDF To CSV

Receiver

CSV

RDF to RDF RDF to RDF m1 m2 m1 m3

Merged RDF

d1:obs042 a m3:Observation ; a m3:BP_systolic ; m3:value 120 ; m3:units m3:mmHg ; m3:position m3:sitting . d2:obs-091 a m3:Observation ; a m3:BP_systolic ; m3:value 107 ; m3:units m3:mmHg .

  • m3 can be understood by Receiver
  • Ready for syntactic transform to CSV

To CSV

Receiver

CSV

Syntactic m3

slide-71
SLIDE 71

71

Summary of transformations

Sender1 Sender2

HL7 v2.x FHIR

To RDF To RDF To CSV

Receiver

CSV

Syntactic Syntactic RDF to RDF RDF to RDF m1 m2 m1 m3 Semantic

RDF Ideally, transformations should be standardized

slide-72
SLIDE 72

72

Proprietary vocabularies

  • Impede semantic interoperability
  • Exchanged healthcare information should

be based on free and open vocabularies

– But proprietary can be used internally

slide-73
SLIDE 73

73

Yosemite Manifesto

  • n RDF as a Universal Healthcare Exchange Language
  • 1. RDF is the best available candidate for a universal healthcare exchange

language.

  • 2. Electronic healthcare information should be exchanged in a format that

either: (a) is an RDF format directly; or (b) has a standard mapping to RDF.

  • 3. Existing standard healthcare vocabularies, data models and exchange

languages should be leveraged by defining standard mappings to RDF, and any new standards should have RDF representations.

  • 4. Government agencies should mandate or incentivize the use of RDF as a

universal healthcare exchange language.

  • 5. Exchanged healthcare information should be self-describing, using Linked

Data principles, so that each concept URI is de-referenceable to its free and

  • pen definition.

Sign at http://YosemiteManifesto.org/

slide-74
SLIDE 74

74

Research needed to prove feasibility

  • Build and demonstrate a reference implementation

– At least two senders and one receiver

  • Demonstrate all important features:

– Syntactic & semantic transformations – Selecting and applying transformations – Incorporate new vocabularies & deprecate old – Privacy & security – Hosting concept definitions

  • Run stress tests to simulate scaling to nationwide adoption
  • Recommend conventions
slide-75
SLIDE 75

75

Data Transformation Wiki

WIKITRANSFORMIA

For Health Data Languages Upload Upload Lookup / Download Lookup / Download

slide-76
SLIDE 76

76

What would it be like?

  • Better treatment
  • Better research
  • Lower cost

Goal: True semantic interoperability

slide-77
SLIDE 77

77

What does semantic interoperability involve?

  • Machine processable information
  • Common vocabularies
  • Unambiguous concepts
slide-78
SLIDE 78

78

Why is this so difficult to standardize?

  • Healthcare is complex: thousands of

interrelated concepts, many domains

  • Standardization progress diminishes

toward zero as committee size grows

  • Moving target: medical science and

technology continually changing

slide-79
SLIDE 79

79

Unambiguous concepts

slide-80
SLIDE 80

80

Semantic interoperability

  • Requires standardization

Sender1 Sender2 Receiver

slide-81
SLIDE 81

81

Assumption: Not standardizing internal systems

  • Not politically feasible
  • Too costly
  • Unwise: would inhibit innovation
slide-82
SLIDE 82

82

slide-83
SLIDE 83

83

"PCAST has also concluded that to achieve these objectives it is crucial that the Federal Government facilitate the nationwide adoption of a

universal exchange language

for healthcare information"

slide-84
SLIDE 84

84

Semantic interoperability

Sender1 Sender2 Receiver

slide-85
SLIDE 85

85

Semantic interoperability-2

Sender1 Sender2

HL7 v2.x FHIR

Receiver

CSV Universal Healthcare Exchange Language

slide-86
SLIDE 86

86

Step 2: Semantic transformation

Sender1 Sender2

HL7 v2.x FHIR

m1 to m3 m2 to m3 HL7 v2.x to RDF FHIR to RDF RDF to CSV

RDF

Receiver

CSV

slide-87
SLIDE 87

87

Data transformations

Sender1 Receiver Sender2

HL7 v2.x FHIR CSV

RDF to RDF RDF to CSV

Semantic Transformations Syntactic Transformations Syntactic Transformations

RDF

slide-88
SLIDE 88

88

Data transformations

RDF to RDF

Semantic Transformations Syntactic Transformations Syntactic Transformations

RDF

slide-89
SLIDE 89

89

Step 2: Semantic transformation

RDF

Semantic Transformations Semantic Transformations Semantic Transformations

slide-90
SLIDE 90

90

Syntactic and Semantic Transforms

Sender1 Sender2

HL7 v2.x FHIR

HL7 v2.x to RDF FHIR to RDF RDF to CSV

Receiver

CSV

Syntactic Semantic (RDF) Syntactic RDF to RDF RDF to RDF

slide-91
SLIDE 91

91

Syntactic and Semantic Transforms

Sender1 Sender2

HL7 v2.x FHIR

To RDF To RDF To CSV

Receiver

CSV

Syntactic Syntactic RDF to RDF RDF to RDF m1 m2 m1 m3 Semantic

slide-92
SLIDE 92

92

Syntactic and Semantic Transforms

Sender1 Sender2

HL7 v2.x FHIR

To RDF To RDF To CSV

Receiver

CSV

RDF to RDF RDF to RDF m1 m2 m1 m3

slide-93
SLIDE 93

93

Step 2: Semantic transformation

Sender1 Sender2

HL7 v2.x FHIR

RDF to RDF RDF to RDF HL7 v2.x to RDF FHIR to RDF RDF to CSV Receiver

CSV Semantic Transformations Syntactic Transformations Syntactic Transformations

slide-94
SLIDE 94

94

Why RDF?

Schema promiscuous

HomePhone Town ZipPlus4 FullName Country Address FirstName LastName Email City ZipCode Red Model Blue Model Green Model Country subClassOf sameAs hasLast hasFirst

slide-95
SLIDE 95

95

HomePhone Town ZipPlus4 FullName Country Address FirstName LastName Email City ZipCode Red Model Blue Model Country subClassOf sameAs hasLast hasFirst

slide-96
SLIDE 96

96

HomePhone Town ZipPlus4 FullName Country Address FirstName LastName Email City ZipCode Red Model Blue Model Green Model Country

slide-97
SLIDE 97

97

HomePhone Town ZipPlus4 FullName Country Address FirstName LastName Email City ZipCode Red Model Blue Model Green Model Country

slide-98
SLIDE 98

98

HomePhone Town ZipPlus4 FullName Country Address FirstName LastName Email City ZipCode Red Model Blue Model Green Model Country

slide-99
SLIDE 99

99

Green model

HomePhone Town ZipPlus4 Country FirstName LastName Email Green Model

slide-100
SLIDE 100

100

Blue view

Country Address FirstName LastName Email City ZipCode Blue Model

slide-101
SLIDE 101

101

Blue view

HomePhone Town ZipPlus4 FullName Country Address FirstName LastName Email City ZipCode Red Model Blue Model Green Model Country Country Address FirstName LastName Email City ZipCode Blue Model Country

slide-102
SLIDE 102

102

Red view

HomePhone Town ZipPlus4 FullName Country Address FirstName LastName Email City ZipCode Red Model Blue Model Green Model Country HomePhone Town ZipPlus4 FullName Country Red Model

slide-103
SLIDE 103

103

Green view

HomePhone Town ZipPlus4 FullName Country Address FirstName LastName Email City ZipCode Red Model Blue Model Green Model Country HomePhone Town ZipPlus4 Country FirstName LastName Email Green Model Country

slide-104
SLIDE 104

104

HomePhone Town ZipPlus4 FullName Country Red Model

slide-105
SLIDE 105

105

Why RDF?

Schema promiscuous

HomePhone Town ZipPlus4 FullName Country Address FirstName LastName Email City ZipCode Red Model Blue Model Green Model Country subClassOf sameAs hasLast hasFirst

slide-106
SLIDE 106

106

Role of a common language

Universal Healthcare Exchange Language

slide-107
SLIDE 107

107

Role of a common language

Universal Healthcare Exchange Language Sender1 Sender2 Receiver

slide-108
SLIDE 108

108

Semantic relevance is relative

  • Blood Pressure measurement:

– Sitting versus Standing

  • Is the difference semantically relevant?
  • Depends on the application!
  • v:BP_Machine rdfs:subClassOf v:BP .
  • v:BP_Manual rdfs:subClassOf v:BP .
  • { ?bp a v:BP_Machine . }

=> { ?bp a v:BP . } .

slide-109
SLIDE 109

109 Sender1 Receiver Sender2

HL7 v2.x FHIR

RDF to RDF RDF to RDF HL7 v2.x to RDF FHIR to RDF

Merged RDF

slide-110
SLIDE 110

110 Sender1 Receiver Sender2

HL7 v2.x FHIR

HL7 v2.x to RDF FHIR to RDF

?

Step 1: Syntactic transformation

  • Transform from source format to substrate model
  • Allows data to be merged
  • Data may not link semantically due to differing vocabularies
slide-111
SLIDE 111

111 Sender1 Receiver Sender2

HL7 v2.x FHIR

?

Sender1 data: HL7 v2.x

(Fictitious examples for illustration)

slide-112
SLIDE 112

112

Yosemite Manifesto

  • n RDF as a Universal Healthcare Exchange Language
  • 1. RDF is the best available

candidate for a universal healthcare exchange language.

slide-113
SLIDE 113

113

Yosemite Manifesto

  • n RDF as a Universal Healthcare Exchange Language
  • 2. Electronic healthcare information

should be exchanged in a format that either: (a) is an RDF format directly; or (b) has a standard mapping to RDF.

slide-114
SLIDE 114

114

Yosemite Manifesto

  • n RDF as a Universal Healthcare Exchange Language
  • 3. Existing standard healthcare

vocabularies, data models and exchange languages should be leveraged by defining standard mappings to RDF, and any new standards should have RDF representations.

slide-115
SLIDE 115

115

Yosemite Manifesto

  • n RDF as a Universal Healthcare Exchange Language
  • 4. Government agencies should

mandate or incentivize the use of RDF as a universal healthcare exchange language.

slide-116
SLIDE 116

116

Yosemite Manifesto

  • n RDF as a Universal Healthcare Exchange Language
  • 5. Exchanged healthcare

information should be self- describing, using Linked Data principles, so that each concept URI is de-referenceable to its free and

  • pen definition.