View source for Computable semantic links from FHIR

'''Development of computable semantic links from FHIR specs to RIM'''
==Logistics:==
1.  Please join my meeting. 
https://global.gotomeeting.com/join/132910925 

2.  Join the conference call: 
770-657-9270 Passcode 854126# 

Meeting ID: 132-910-925

Meeting notes: https://goo.gl/7qjwNe

== August 6, 2015 ==
#Agenda
##Call to order
##Roll Call
##Status of Project Scope Statement
##What needs to be done?
##Who will do what?
##Next Steps
###Next call August 13, 2015

== 30 July 2015 Teleconference ==
See https://goo.gl/7qjwNe

==Scope==
The scope of this project is well-defined:  to define, design, develop, and demonstrate how tools based on RDF/semantic technologies can be used as part of the FHIR specification process to ensure that all FHIR specifications (and FHIR profiles) that fall within the jurisdiction of HL7 balloted artifacts can ensure the development of computable semantic links between FHIR artifacts and RIM semantic artifacts.  
==Need==
The importance of utilizing the rich semantics of the RIM in the context of FHIR specifications and profiles is (or should be) a core construct of “HL7 architecture.”  At present, the “documentation” of FHIR/RIM links is, at best, done in free text as part of a given FHIR specification (and many times not done at all).  Failure to provide computable links will, in the end, lead to specifications whose interoperability is based on knowledgeable human coherence at specification time and which does not take advantage of the considerable efforts already expended to define formal RIM structures.
==RDF usage==
RDF provides a standard, open technology on which to build links.  The Pharma Work Group has a virtually complete set of “text links” to RIM semantics that they have included in their FHIR specifications, and the ITS RDF group has the technical knowledge and interest in working to build tools that could be integrated into the FHIR specification package to enable specification authors to specify links that were, in fact, computable using standard RDF/SPARQL technologies.  The role of the ARB is to oversee the project and it’s deliverables since they are, in essence, essential to developing and maintaining a coherent, computably semantically interoperable architecture that integrates FHIR and the RIM.
==Kickoff Meeting==
*RDF kickoff. 
** Attendees: Dale Nelson, John Hatem, Eric P, Charlie, Paul Knapp, David Booth, Robert Hausam, Tony Julian
*Notes: Talked with callers about the goals.  Eric, Claude, and I had a call 2 hours ago about the basics:
*There is a desire by ARB, Pharmacy and ITS to look at computable links between a fhir spec and the RIM.
*David B: From the pharmacy side, what do people want to do with the links once created?  Is someone planning to make use of the machinery.
*Charlie: Problem is that links are not being created consistently: If links are only specified in text, they will not be consistent, and no way to valid two specification express the same semantics.
*John: No customers asking for them, but we think because of the work that we are doing, and others that overlap, we believe this will address the issues.
*Dale: The same thing was tried with CMETS, but templating has taken over it.
*Dale: How does this relate to the FHIR RDF project, and what is a link?  
*Charlie: Difference between this and CMETS is that we will have RDF graphs that can be traversed, using decent governance.  Dale has insight from the CMETS project.  What the links are, and how it relates to the FHIR RDF project, if it existed, the notion of links to the RIM would be done.  There would be at least SPARQL queries.  The canonical representation does not exist: Hope to take the Pharmacy text to create the links.  Hope to see the project drive the canonical representation of FHIR specifications.
*Eric: The computable link looks like . . . Could be expressed in XPATH.  SImple ones could be predicate-paths, or predicate transversals of the graph. You could synthsize RIM from FHIR, or FHIR from RIM.
*Dale: Looks useful.  Sounds like the CMET reference was pertinent: make a case for a simple resource: patient, which the RIM represents as an entity of type living subject of roll patient scoped by a organization.  Role of CMETS was to define the sub-graphs: Standardize patient with a common template.  The problem was that people choose to model things using their own interpretation of the model.  FHIR helps that:  the resources have a built-in CMET type structure - much is optional.
*Paul: Continue with XPATH?
*Eric: No, use RDF-speak.
*Paul: Requirement that something in the RIM we would say "this is that".  We had people who did not understand the language doing the mapping.  It is not high on the priority list.  No way to use the information to check for existence, or the right thing.  resource creation is the same as we did with the RIM in the first place.  Problem with V3 is that if you wanted a spoon, you had to get the drawer, cabinet, and kitchen sink.  FHIR we can have a cutlery resource.  It is still useful to be able to point it to the kitchen.  Cant use current FHIR formalism to see what was left off , no pointer to the RIM.  With computable mapping we can ensure that it points to a thing, the right thing, and determine what we left out.
*Eric:Coverage: tricky because of what the RIM covers.  Could easily map to CMETS, are they manifested in FHIR.  How were cmets defined?
*Dale: Patient administration, concrete entities, (how do you express the notion of a patient or a medication).We started with the small block, e.g.patient.  It got trickier when we tried to integrate the base cmets as components of larger cmets.  The issue with CDA stands as an outlier: We will not use cmets and follow the same patterns that everyone else does.  A resource in FHIR was created the same: what do we think a patient needs? Initial set of CMETS not unlike the initial set of FHIR resources.
*Charlie: CMETS were constraints on the RIM.  FHIR was derived from what people thought they needed.
*John: I look at the resource patient and the expression.
*Reviewed medicationprescription mappings: http://hl7-fhir.github.io/medicationprescription-mappings.html vs CMETS
*Eric:how to validate, and how to represent?
*Paul: The mapping on the screen has a pleasing presentation, but is not computable.
*David: Translate the pigeon to something else - in the process we will find the coverage. What is the expresivity, can we take the pigeon text and turn a crank to generate the RDF//
*Paul: retain the usebility for the current.
*When/where?
*where to document?
*HCLS/FHIR github.
*WHen? Monday-thursday. 
*Frequency? Weekly 4 eastern. 
*Tony will send out Doodle poll.
*Adjourned at 3:06pm Eastern.

[[User:Ajulian|Tony Julian]] ([[User talk:Ajulian|talk]]) 15:08, 17 July 2015 (EDT)