Modeling and Validating HL7 FHIR Profiles Using ShEx

AMIA
~21 March, 2016

Eric Prud'hommeaux, <eric@w3.org>
- Sanitation Engineer, W3C
Harold Solbrig,
- Mayo Clinic

Data Value

Data utility depends on whether it

Directs our actions
- diagnoses
- drug development
- research
- policy
Affects our confidence
Costs less than the value it provides

Data dimensions

Size of population
Coverage of population
Phenotypic breadth

Size/Structure (false) dichotomy

Clinical Data

clinical trial data (SDTM, ADAM, data dictionaries...)
- tabular data capturing few study features
Association Study Data (GWAS)
- tabular data capturing all possibly related features
Electronic {Medical,Health} Record (EMR/EHR)
- tree-like (if your lucky, otherwise faxes) describing patient status

FHIR Goals

Smooth out data impedence between clinical systems.
Shift integration effort to acquisition effort
- Enable more coded data
- Focus on etiology instead of insurance.
- Encourage acquisition of richer clinical history graph.
Enable pedestrian goals like single-entry.

Semantic FHIR Goals

Smooth out data impedence between clinical data and clinical knowledge.
Shift integration effort to ontology integrationeffort
- Uniform model for information model and terminology implications.
- Integration with anatomy and disease ontologies.
- Encourage collaborative model mapping, CDS rules, etc.
Repurpose for research, efficacy monitoring, bio-surveillance...

Clinical history graph

drug lists
allergies
immunizations
vitals
encounters
procedures
labs
problem statements
diagnosis
treatment plans
outcomes
genomics

TermInfo Opportunity

information model
(Concepts and Relationships)
- Observations
- AdverseEvents
- Substance Administrations
on patient Isabella Jones
terminology model
(Terms and Relationships)
- Pneumonia a Pulmonary Disease
- Serum Sodium a lab test
- Penicillin an antibiotic
value sets
- Pneumonia, SLE, CHF
- mild, medium, severe
datatypes
- dates
- times
- intervals

Terminological Resources in Medicine

SNOMED CT - Systemized Nomenclature of Medicine - Clinical Terms. SNOMED CT is a combination of an ontology, a knowledge organization system and a classification system, although it is frequently used as a simple lexicon
LOINC - Laboratory Observation Identifiers Names and Codes. LOINC is a standard for naming (identifying) medical laboratory observations and, as such, fits largely into the category of lexicon.
RxNorm is a lexicon for clinical drugs. It also provides information about drug composition, packaging, mechanism of action, physiological effect, etc. As such, RxNorm can also be viewed as an ontology
ICD-10 is a classification system for diseases and related health problems. It includes a broad set of classifications for causes of death (mortality) as well as a more refined classification system for the rates of incidence of disease (morbidity). Note: Official RDF Server
NCI Thesaurus is a combination of an ontology, a knowledge organization system and a dictionary whose primary focus is on cancer and cancer research.
UMLS and NCI MetaThesaurus are two closely related resources. While their primary function is knowledge organization, they also can serve as a primary lexicon and, to some extent, an ontology of clinical knowledge and information.

FHIR-RDF Tools

FHIR XML to RDF

XSLT script to transform XML to RDF (as Turtle).
Driven by FHIR internal schema: Structure Definitions.
Integration with FHIR definition reduces maintenance costs.
Mostly keeps up with evolving standard by typing "make".

FHIR Profiles to ShEx

Emits a schema for the RDF.
- Executable validation of RDF.
- Terse, human-readable syntax.
- Extension mechanism like parser semantic actions
Also driven by FHIR internal schema: Structure Definitions.

FHIR XML to RDF

or use a specialized form

or

download hcls-fhir-rdf git repo git@github.com:w3c/hcls-fhir-rdf.git
follow installation instructions
downoad some FHIR/XML: wget https://hl7-fhir.github.io/observation-example.xml
run the transform: xsltproc -stringparam fhirdefs ../data/definitions.xml xsl/transform.xsl observation-example.xml

Navigating profiles

go to the resources list
pick one and scroll to the resource description
note the structure, UML, XML and JSON representations
click around in the links to see how e.g. Observation uses Patient
check out the terminology bindings
and the datatypes

FHIR has a REST-based HTTP protocol
hence the Search Parameters
much more detailed that anything in LDP.

FHIR Profiles

HL7 uses Profiles to model widely-applicable core FHIR resources.
Minimally restrictive in terminologies and property cardinality.
Communities of interoperability use FHIR profiles to restrict core resources.

ShEx Schema analogous to XML Schema
- BNF for the Semantic Web
- Grammar-based language for defining languages.
- Operates over bag of triples instead of list of elements.
- Productions can reference other productions.
Captures most of the FHIR Structure Definitions.
- Captures relationships between resources and fields or other resources.
- Not permutations of permissible fields
  Available in Semantic Actions.

Observation Profile

Name	Flags	Card.	Type
Observation	I		DomainResource
identifier		0..*	Identifier
status	?! Σ	1..1	code
category		0..1	CodeableConcept
code	Σ	1..1	CodeableConcept
subject	Σ	0..1	Reference(Patient \| Group \| Device \| Location)
encounter		0..1	Reference(Encounter)
effective[x]	Σ	0..1
effectiveDateTime			dateTime
effectivePeriod			Period

<Observation> {
  a (fhir:Observation)?,
  fhir:Observation.identifier                 @<Identifier>*,
  fhir:Observation.status                     @<code>,
  fhir:Observation.code                       @<CodeableConcept>,
  fhir:Observation.subject   { fhir:reference @<Patient>
                                           OR @<Group>
                                           OR @<Device>
                                           OR @<Location> }?,
  fhir:Observation.encounter { fhir:reference @<Patient> }?
  (fhir:Observation.effectiveDateTime         @<DateTime> |
   fhir:Observation.effectivePeriod           @<Interval>)?,
  ...

  fhir:Observation.id @<LitShape>?,
  fhir:Observation.meta @<MetaShape>?,
  fhir:Observation.implicitRules @<LitShape>?,
  fhir:Observation.language @<LitShape>?,
  fhir:Observation.text @<NarrativeShape>?,
  fhir:Observation.contained @<ResourceShape>*,
  fhir:Observation.extension @<ExtensionShape>*,
  fhir:Observation.modifierExtension @<ExtensionShape>*,
  fhir:Observation.valueQuantity @<QuantityShape>?,
  fhir:Observation.valueCodeableConcept @<CodeableConceptShape>?,
  fhir:Observation.valuestring @<LitShape>?,
  fhir:Observation.valueRange @<RangeShape>?,
  fhir:Observation.valueRatio @<RatioShape>?,
  fhir:Observation.valueSampledData @<SampledDataShape>?,
  fhir:Observation.valueAttachment @<AttachmentShape>?,
  fhir:Observation.valuetime @<LitShape>?,
  fhir:Observation.valuedateTime @<LitShape>?,
  fhir:Observation.valuePeriod @<PeriodShape>?,
  fhir:Observation.dataAbsentReason @<CodeableConceptShape>?,
  fhir:Observation.interpretation @<CodeableConceptShape>?,
  fhir:Observation.comments @<LitShape>?,
  fhir:Observation.appliesdateTime @<LitShape>?,
  fhir:Observation.appliesPeriod @<PeriodShape>?,
  fhir:Observation.issued @<LitShape>?,
  fhir:Observation.reliability @<LitShape>?,
  fhir:Observation.bodySiteCodeableConcept @<CodeableConceptShape>?,
  fhir:Observation.bodySiteReference @<ReferenceShape>?,
  fhir:Observation.method @<CodeableConceptShape>?,
  fhir:Observation.specimen @<ReferenceShape>?,
  fhir:Observation.performer @<ReferenceShape>*,
  fhir:Observation.device @<ReferenceShape>?,
  fhir:Observation.referenceRange @<BackboneElementShape>*,
  fhir:Observation.related @<BackboneElementShape>*

}

ShExC reads like the FHIR logical tables.
Captures FHIR's modest grammar:
- structure
- value constraints
- nested constraints (context-sensitive)
- disjunction

ShEx Semantic Actions

<IssueShape> {
    ex:state (ex:unassigned ex:assigned),
    ex:reportedBy @<UserShape>,
    ex:reportedOn xsd:dateTime
        %js:{ report = _.o; return true; %},
    (ex:reproducedBy @<EmployeeShape>,
     ex:reproducedOn xsd:dateTime
        %js:{ return _.o.lex > report.lex; %}
        %sparql:{ ?s ex:reportedOn ?rpt . FILTER (?o > ?rpt) %}
    ),
    ex:related @<IssueShape>*
}

<UserShape> {
    (foaf:name xsd:string
     | foaf:givenName xsd:string+,
       foaf:familyName xsd:string),
    foaf:mbox IRI
}

<Issue1>
    ex:state        ex:unassigned ;
    ex:reportedBy   <User2> ;
    ex:reportedOn   "2013-01-23T10:18:00"^^xsd:dateTime ;
    ex:reproducedBy <Thompson.J> ;
    ex:reproducedOn "2013-01-23T10:00:00"^^xsd:dateTime ;
#    ex:related      <Issue2>, <Issue3> 
.

<User2>
    foaf:givenName "Bob" ;
    foaf:familyName "Smith" ;
    foaf:mbox <mail:bob@example.org>
.

Named semantic actions associated with production.
Inline or external definition (a la ANTLR).
Leverages context-sensitive grammar.
Fired when grammar accepts a triple or pattern.
Provides ordered traversal of RDF graph.
Turn your validator into a parser.

Next Steps

Development of supplemental ontologies.
Schema Restriction and Subsumption.
Formalize FHIR extension/restriction process.

Model of Interoperability

Exmine two schemas to see:

intersection -- what's in both (interoperable data).
differences -- what are we losing when we exchange
isosemantic variability -- what's expressed differently on one than the other.
- Leverage:
  - terminology mappings
  - structural mappings to clinical models, e.g. CIMI
  - additional semantics captured in semantic actions
  to discover when two Profiles express the same thing in different ways.
- Complex to perform, high-yield if we can pull it off even a little.

extra slides

Term simplification

The popular CD datatype has:

code
code system
code system version
helpful text

Terms as URLs

authority
version

PREFIX snomed: <http://ihtsdo.org…20130131…> 
PREFIX hl7: <http://hl7.org/owl/metadata#> 

<myObs> hl7:coding snomed:282291009 .

Term oversimplification?

mixed versions?
version evolution?

Minimalist term evolution

Version terms, not terminologies.
Annotate with govornance metadata.
Marginally increased ontologist burden.
Hugely decreased consumer burden.

Taxonomy supplements

These are all sibling children of Degree findings:

Lowered (385440003)
Reduced (260400001)
Decreased (1250004)
Increased (35105006)
Raised (260399008)

Purpose-built supplemental ontologies

Separate augmenters and decreasers without requiring SNOMED to do the same.

terminology model

augmented terminology

Biggest challenges

5 outreach/education.
4 architecture.
3 validation.
2 knitting/gluing.
1 physician interface.

SNOMED CT - Systemized Nomenclature of Med - Clinical Terms

> 300,000 identifiers (e.g. 74400008, 18526009, 66754008, etc)
Multiple "descriptions" (preferred labels and synonyms) per identifier
Formal (DL based) assertions (rdfs:subClassOf and owl:equivalentClasss) about associations between identifier referents.
Formal (DL based) definitions of the referents of the identifiers. Note: English definitions are few and far between.
Ancillary information -- uses per languages, reference sets, maps.
Maps to ICD-10
Underway definition of LOINC entries using DL

SNOMED CT Identifiers

18 digit numeric identifiers. Examples:
- 74400008 - Appendicitis (Finding)
- 900000000000003001 - Fully specified name (Metadata)
- 900000000000207008 - SNOMED CT as a whole (also)
URI Scheme:
- http://snomed.info/id/74400008 - Appendicitis
- http://snomed.info/sct/900000000000207008 - the complete SNOMED CT

SNOMED CT URI's do not currently directly dereference. They can be used, however, using the Common Terminology Services 2 (CTS2) REST identifiers:

74400008 – “concept code” of appendicitis as defined by SNOMED CT
http://snomed.info/id/74400008 - URI that references the class or “concept” appendicitis as defined by SNOMED CT
http://informatics.mayo.edu/py4cts2/codesystem/SNOMED_CT/version/20150131/entity/74400008 - URI of a specific SNOMED CT description of appendicitis
http://informatics.mayo.edu/py4cts2/codesystem/SNOMED_CT/entity/74400008 - URI of the CURRENT SNOMED CT description of appendicitis
http://informatics.mayo.edu/py4cts2/entity/sctid:74400008 - URI of all descriptions of appendicitis (as defined by SNOMED CT) known to this server
http://informatics.mayo.edu/py4cts2/codesystem/SNOMED_CT/version/20150131/entitybyuri?uri=http://snomed.info/id/74400008 - same as above

C-CDA XML to RDF

similar to FHIR, but using the CDA-Turtle XSLT (see online example)

_:section0_allergyProblemAct0 a rim:Observation ;
    rim:Act.id [ a dt:DSET_II ;
        dt:COLL.item [ dt:II.root "69724b9d-5e77-402f-a5b6-3379dde3e8a9" ]
    ] ;
    rim:Act.classCode [ hl7:coding [ dt:CDCoding.code "ACT" ; dt:CDCoding.codeSystem "???" ] ] ;
    rim:Act.moodCode [ hl7:coding [ dt:CDCoding.code "EVN" ; dt:CDCoding.codeSystem "2.16.840.1.113883.5.1001" ] ] ;
    rim:Act.effectiveTime-low "2012-08-06"^^xsd:date ;
    rim:Act.statusCode "active" ;
  
    rim:Act.code [
        hl7:coding [ dt:CDCoding.code "48765-2" ; dt:CDCoding.codeSystem "2.16.840.1.113883.6.1" ;
                     dt:CDCoding.displayName "ALLERGIES, ADVERSE REACTIONS, ALERTS" ; dt:CDCoding.codeSystemName "LOINC" ]
    ];
    rim:Observation.value [ 
    ] .# SUBJ
[ a rim:ActRelationship ;
    rim:ActRelationship.typeCode [ hl7:coding [ dt:CDCoding.code "REFR" ; dt:CDCoding.codeSystem "???" ] ] ;
    rim:ActRelationship.source _:section0_allergyProblemAct0 ;
    rim:ActRelationship.target _:section0_allergyProblemAct0_entryRelationship0
] .
_:section0_allergyProblemAct0_entryRelationship0 a rim:Observation ;
    rim:Act.id [ a dt:DSET_II ;
        dt:COLL.item [ dt:II.root "69724b9d-5e77-402f-a5b6-3379dde3e8a9" ]
    ] ;
    rim:Act.classCode [ hl7:coding [ dt:CDCoding.code "OBS" ; dt:CDCoding.codeSystem "2.16.840.1.113883.5.6" ] ] ;
    rim:Act.moodCode [ hl7:coding [ dt:CDCoding.code "EVN" ; dt:CDCoding.codeSystem "2.16.840.1.113883.5.1001" ] ] ;
    rim:Act.effectiveTime-low "2012-08-06"^^xsd:date ;
    rim:Act.statusCode "completed" ;
  
    rim:Act.code [
        hl7:coding [ dt:CDCoding.code "ASSERTION" ; dt:CDCoding.codeSystem "2.16.840.1.113883.5.4" ;
                     dt:CDCoding.codeSystemName "HL7ActCode" ]
    ];
    rim:Observation.value [ a dt:PQ ;
        dt:CD.code [ a dt:CD ;
            hl7:coding [ rim:CDCoding.code "416098002" ; rim:CDCoding.codeSystem "2.16.840.1.113883.6.96" ;
                         rim:CDCoding.displayName "drug allergy" ; rim:CDCoding.codeSystemName "SNOMED CT" ]
        ]
    ] .# Participant
[ a rim:Participation ;
    rim:Participation.typeCode [ hl7:coding [ dt:CDCoding.code "CSM" ; dt:CDCoding.codeSystem "???" ] ] ;
    rim:Participation.act _:section0_allergyProblemAct0_entryRelationship0 ;
    rim:Participation.role _:section0_allergyProblemAct0_entryRelationship0_participant0
] .
_:section0_allergyProblemAct0_entryRelationship0_participant0 a rim:Role ;

    rim:Role.player _:section0_allergyProblemAct0_entryRelationship0_participant0_player ;
    rim:Role.scoper _:section0_allergyProblemAct0_entryRelationship0_participant0_scoper ;
    rim:Role.classCode [ hl7:coding [ dt:CDCoding.code "ROL" ; dt:CDCoding.codeSystem "???" ] ] ;
.
_:section0_allergyProblemAct0_entryRelationship0_participant0_player a rim:Person ;
    rim:Entity.classCode [ hl7:coding [ dt:CDCoding.code "PSN" ; dt:CDCoding.codeSystem "???" ] ] ;
    rim:Entity.determinerCode [ hl7:coding [ dt:CDCoding.code "INSTANCE" ; dt:CDCoding.codeSystem "???" ] ] ;
    rim:Entity.name [ a dt:COLL_EN ;
    ].

O-RIM

The MIF underpins HL7 definitions and groupthink
MIF contains
- RIM (think "UML" + ~400 features)
- datatypes
- codes
- valuesets
- all history
xslt transform from MIF to O-RIM
roughly follows ODM UML->OWL mapping
relation predicates named by SourceClass.relation.TargetClass
attribute predicates named by SourceClass.attribute
GForge site (requires HL7 password)

CDA RMIM

C-CDA RMIM

Interoperability value proposition

Reduce redundancy
Commoditize systems
Effective quality metrics
Cheaper protocol development and distribution
Cheaper and more comprehensive drug reasearch

Interoperability state of the art

Short-term commercial interests oppose interop.
Lock-in provides stability.
Use cases percieved as sci-fi.

Technical barriers:

Standardization (precise communication) is expensive.
Multiple intersecting domains with intersecting authorities:
- drugs, diseases, tests, diagnoses (Terminology Model)
  pathology: SNOMED (IHTSDO), tests: LOINC, drugs: RxNorm, NDC, CPT (AMA), NPU (IUPAC), ICDⁿ (WHO), research results: MeDRA (US FDA), HCPCS, billing: NDC, efficacy: CQM (CMS) …
- graph of what happened to whom and why (Information model)
  Reference Information Model (HL7), SDTM (CDISC), MIMIC II database schema, I2B2, SMART, OpenEHR, all 700+ EMRs, closed (EPIC, Cerner) or open (CommCare)
- datatypes and units
  ISO21090, XML Schema, UCUM
Legacy systems (success of HL7 V2).
Insufficient or overly complex implementation guidelines.
Insufficient information model, inappropriate model, inconsistent data types.

Modeling and Validating HL7 FHIR Profiles Using ShEx

AMIA~21 March, 2016

Data Value

Clinical Data

FHIR Goals

Semantic FHIR Goals

Clinical history graph

TermInfo Opportunity

Terminological Resources in Medicine

FHIR-RDF Tools

FHIR XML to RDF

FHIR Profiles to ShEx

FHIR XML to RDF

Navigating profiles

FHIR Profiles

BNF for the Semantic Web

Observation Profile

ShEx Semantic Actions

Next Steps

Model of Interoperability

extra slides

Term simplification

Terms as URLs

Term oversimplification?

Minimalist term evolution

Taxonomy supplements

Purpose-built supplemental ontologies

Biggest challenges

SNOMED CT - Systemized Nomenclature of Med - Clinical Terms

SNOMED CT Identifiers

C-CDA XML to RDF

O-RIM

CDA RMIM

Interoperability value proposition

Interoperability state of the art

sprites

AMIA
~21 March, 2016