IRC log of hcls on 2021-08-12

Timestamps are in UTC.

14:59:40 [RRSAgent]
RRSAgent has joined #hcls
14:59:40 [RRSAgent]
logging to https://www.w3.org/2021/08/12-hcls-irc
14:59:47 [dbooth]
rrsagent, make logs public
15:05:51 [dbooth]
Meeting: FHIR RDF
15:06:02 [dbooth]
Topic: Brad Simons, SureScripts
15:07:58 [dbooth]
Present: David Booth, Emily Pfaff, Darrell Woelk, EricP, Gopi, Harold Solbrig, Guoqian Jiang, Brad Simons
15:08:53 [dbooth]
brad: Motivation for the project was to reuse info from C-CDA: strip out wanted data and get at it more effectively. Work is patented.
15:09:23 [dbooth]
... We take a FHIR RDF model and a SureScripts model.
15:10:05 [dbooth]
... We created our own full FHIR model: all resources, all property, all constraints, cardinalities, datatypes. Then added SureScripts model, to: 1. add properties.
15:10:33 [dbooth]
... Grahame's model does not have a system name on coding. We added one to make it more readable.
15:11:00 [dbooth]
... Also the SureScripts model has a whole mapping model -- what a C-CDA would be to FHIR.
15:11:38 [dbooth]
... Take in the FHIR model and SureScripts model and take all the possible xpath permutations, and breadcrumb trail of all resources and properties needed to populate it.
15:12:17 [dbooth]
... So an instance or attribute that contains a problem.code it knows what all the components are, so it can instantiate it.
15:12:47 [dbooth]
... I'm able to execute those to extract the relevant data to build all the RDF objects that you see, to populate them with the appropriate data.
15:13:08 [dbooth]
... Can also generate a list of instances w data values.
15:13:43 [dbooth]
... For coding value I can get the relevant info from the FHIR model and give it to HAPI, and HAPI will generate the proper code using reflection.
15:13:47 [dbooth]
Present+ Sajjad
15:14:35 [dbooth]
sajjad: FHIR in RDF vs FHIR RDF? You have your own ont of FHIR.
15:14:57 [dbooth]
brad: the base FHIR model is our own ont, but if you lay it next to the FHIR ont, it is very similar.
15:15:18 [dbooth]
... My goal is to adopt yours.
15:15:35 [dbooth]
eric: The stuff you add is to make it more readable?
15:16:34 [dbooth]
brad: I also have my own mappings to get from C-CDA to FHIR, but also rules in that add-on model.
15:17:55 [dbooth]
sajjad: scalability and maintenance issue, when FHIR spec changes? Diff between FHIR RDF and FHIR in RDF.
15:19:11 [dbooth]
brad: Yes, and I want to get off of using my own model. Want to be able to use your FHIR RDF.
15:19:55 [dbooth]
sajjad: you're taking xpaths to populate your schema? Why not JSON into FHIR schema?
15:20:52 [dbooth]
brad: If the purpose was to go from XML to FHIR, you probably wouldn't need to go through RDF, but you cannot do rules processing on JSON.
15:22:02 [dbooth]
sajjad: There are rules reasoners available on RDF.
15:22:55 [dbooth]
brad: Can support augmentation, process breadcrumb trail, capture data from text section and auto-populate the coded section.
15:24:10 [dbooth]
brad: Ran into naming convention issues -- not consistent across FHIR RDF models.
15:24:28 [dbooth]
... Also ran into recursion issue.
15:25:15 [dbooth]
... contains can have a "contains" and the names keep being concatenated.
15:26:16 [dbooth]
eric: questionnaire response has that recursion problem too.
15:26:47 [dbooth]
harold: Yes, there are recursive structures in FHIR, and that's one of the reasons we need JSON-LD 1.1
15:27:17 [dbooth]
brad: You don't want to keep concatenating contains.contains.contains ....
15:28:21 [dbooth]
brad: Instead, we just had valueset expansion contains component and left it at that.
15:29:57 [dbooth]
harold: I think we've addressed this with JSON-D 1.1
15:30:02 [dbooth]
eric: Q about xpath annotations.
15:30:32 [dbooth]
brad: We have a mapping file, w a multitude of nodes with xpath segments, and those segments have an affiliation w a particular FHIR resource property.
15:30:58 [dbooth]
... When I churn through that stuff, I dynamically build full xpath from breadcrumb trail.
15:31:25 [dbooth]
eric: Do those end up on instance data, like Sally's diagnosis, or on metadata.
15:31:50 [dbooth]
brad: The xpath that I built is captured in a binary file, and access them at parse time. They're never passed through to anybody.
15:32:23 [dbooth]
... Point is to generate a FHIR rep of the C-CDA data, but there's too much unnecessary stuff in C-CDA.
15:32:48 [dbooth]
eric: Could we see one of the instances, populated with your extra stuff?
15:33:45 [dbooth]
guoqian: When you convert C-CDA to RDF, how many FHIR resources do you cover?
15:34:41 [dbooth]
brad: A lot of the resources are reused: Allergy, Med, Immun, Problems, Condition, OBservations (incl familiy history, vitals, etc.), insurance.
15:35:38 [dbooth]
guoqian: Do you have issues with your FHIR RDF to the XML representation?
15:37:36 [dbooth]
brad: None. Part of the reason I'm converting to FHIR, is a lot of vendors (Epic, etc.) want to consume FHIR. Meaningful Use caused vendors to use C-CDA, but it didn't tell them how, so the C-CDAs differ.
15:38:03 [dbooth]
... I want to be able to pass on only the info that is needed, to maintain privacy.
15:38:24 [dbooth]
guoqian: No issues w HAPI FHIR? brad: None.
15:39:12 [dbooth]
brad: I'm using HAPI to take my FHIR RDF and produce JSON, and using reflection it produces everything, with only hundreds of lines of code.
15:40:24 [dbooth]
brad: I'm generating metadata that a colleague uses to generate from POJOs in HAPI.
15:41:11 [dbooth]
eric: C-CDA diversity was the shortcoming? And will that be any better with FHIR?
15:41:43 [dbooth]
brad: Probably more structured, but not better.
15:42:04 [dbooth]
... Consider Allergies. people will codify your Allergies, or your lab results, with ranges, etc.
15:43:17 [dbooth]
... But if you go into the doc's office and say which meds you are taking, they never look up the codes. Allergies are even worse: 9/10 times its coded in the text section -- never codified.
15:43:38 [dbooth]
... But here, I'm able to extract info like that and put it into the codified section.
15:45:05 [dbooth]
david: How to improve FHIR RDF model?
15:45:31 [dbooth]
brad: We compared w ours, and matched it as much as possible.
15:45:59 [dbooth]
... We saw that if we could fix the recursion and standardize on naming, we could drop our model and go with yours.
15:47:10 [dbooth]
david: Got the list of diffs between yours and ours?
15:48:15 [dbooth]
brad: I had a few data augmentations that I put into the base FHIR model that are not relevant to you -- branch points.
15:48:47 [dbooth]
david: Lists?
15:49:05 [dbooth]
brad: We have lists of lists.
15:49:40 [dbooth]
ACTION: Brad to find the comparison of their FHIR RDF to ours
15:51:04 [dbooth]
sajjad: Suppose you have Organization w a name, assume it is 0 or 1. How would you define the cardinality in RDF?
15:51:40 [dbooth]
brad: We use OWL to capture the cardinality.
15:53:33 [dbooth]
sajjad: For usability, from C-CDA, vendors are more interested in being in FHIR. When you transform C-CDA to FHIR, how do you deal w templating? E.g. family history? They all go to Observation. Specialized rules/templates?
15:54:12 [dbooth]
brad: i have mappings defined for specific sections like Family History. They're driven off of LOINC code in C-CDA for the section.