Date

25 Jul 2017

Attendees

Keith Campbell
Claude Nanjo
Sarita Keni
Joey Coyle
Catherine Staes
Stephanie Klepacki

Scribe

Stephanie Klepacki (NOTE: Call notes for approximately 2 minutes of the first part of the conversation were not captured.)

Goals

Discuss possible ways to reuse content within multiple KNARTs

Discussion items

Time	Item	Who	Notes
5min	Tasks to Work On	Sarita	Sarita: Prefers to continue to work on the blood pressure example as they are working on medications on their side.
15min	Reusability of KNART Content	Catherine	Catherine: Discussed review of systems (ROS), such as for skin exam, and how it would be modeled in the KNARTs. For Women's Health in the well-woman visit KNART, there is a lot of content that should be able to be shared with other KNARTs. How do we reuse that same information in other KNARTs? Should it be a layer of the ROS or a skin exam? Keith: It's good for a Monday call topic but we can do some pre-work as to what the reusable units should be. Catherine: Would the pre-work be on the requirements side? Keith: Let's figure out which KNARTs we're talking about and which parts are reusable/common across multiple things. Continue to proceed on defining the ANF, CIMI structure, clinical statement/topic and circumstances around that topic. Let's flesh these out more. Then say given these models, and we'll probably want CIF models as well, what are the reasonable aspects. Catherine: She wanted to ensure we vet the request and get it on the agenda for a Monday call. Claude: We have thought about it. The KNARTs allow you to reference another KNART, such as an order set referencing another order set. There is also the need for reusability, such as an order set that is being ordered over and over again. They had come up with the concept of a TSR repository. When you define the models, you can define the definition of them, use them, and incorporate them into a number of KNARTs. They did a demonstration previously with LEGOs, and they only created them when the didn't already exist. They could do a similar thing for orderables or parts of logic that needs to be reusable. Catherine: At some point, we need to discuss this on a Monday call and whether or not this resuable information is a KNART or something else.
10min	Confluence and JIRA	Keith	Keith: B3/Cognitive needs to transition the TSR spreadsheet to be in Confluence vs. Google docs. Should he setup a training call (during this call's timeslot) to be a training call for B3 to learn about Confluence and JIRA? Claude: Cognitive is using Confluence and JIRA. That is how they track all of their deliverables. Can we just use what we already have or do we need to set up another instance? Keith: We can either use yours or HSPC's. He is happy to use yours but we need to start using it. Claude: He doesn't need to be there for the session. He can have Chris Peck contact Keith and discuss whether or not to use their Confluence project. Sarita: She is pretty sure that the Deloitte team is not familiar with it and would need to access to the instance we are using. She is familiar with it but isn't sure about spreadsheets. If we do anything, can we include the Deloitte team? Keith: Yes, we want one solution. Claude, how wide open do you want your information to be vs. doing this on the HSPC instance? If they do this, they would open it up to Deloitte and could provide training to everyone who needs it. Stephanie: Asked if there is a benefit to having it on HSPC, particularly when the contract is over and we don't want to lose access to the information. Keith: As a contractor, they don't have to publish anything until it has been delivered and we can't force B3 to put it on HSPC. However, if they are willing to do that before their work is signed off, that is wonderful. His preference is to put it on HSPC, if they are willing to do so. Claude: The only issue is it would be nice if we could transfer from their instance to the HSPC instance. Keith: There is a certain amount of import/export that you can do. He had asked Susan to create the VA KNART effort under SOLOR and some of it is already setup. We can discuss the particulars and go forward.
30min	Spreadsheet Review	Group	Sarita: She wanted to revisit the terminology modeling piece of this. She pulled the modeling out of the SNOMED international release. The expression is modified to represent sitting BP. The expression is separated for systolic and diastolic BP. Precondition is an attribute that can be used for the sitting position. They weren't sure how the observable captures laterality. Is this an appropriate representation and what piece of this would go into the VA extension? Keith: What you have is very reasonable. You would write up your editorial guidance, and it seems that you are saying the observable entity model is the closest one you want to work with. But, he doesn't think findings always have value for them. He leaves the choice to you as to whether you use the observable entity vs. findings model. Keith: The way the Phenomenon model is being observed, everything except the value and UOM and subject of information/record are not part of the phenomenon and are represented in other aspects of the model. Everything you have put is correct. Claude: When he thinks of systolic BP, it is really definitional and the direct site is the specific area where the observation is made. One is really the definition as to what systolic BP is and the other is the site on which the BP cuff was placed. Keith: Proposes the process for dealing with that, and your concern is totally perfect, is maybe used in the "adheres in" case and it needs to be defined what that means. A clarification of what "adheres in" means to us is needed. We can't share the language from SNOMED outside of the licensing agreement but our own definition can be shared. Let's enter a JIRA issue for each thing, such as it's not clear to me that "adheres in" is the right way to go. Some of his questions will be very similar in that the root code is systolic BP and is the precondition of sitting already defined in systolic BP and you're just including it here for clarity, or is it missing? Sarita: In the international release, it is there. Keith: Okay, so you are including it here for clarity. Catherine: Looking at SNOMED, isn't it that we are saying - that "adheres in" isn't what it should be? Keith: Yes, that is exactly the quibble we need to clarify. You want to specialize both "adheres in" and "direct site," and maybe direct site isn't medial artery but something else (did not capture what he said). There are merits to both side. Catherine: Should the default be what's there already? Keith: No, because there is a lot of junk there and we need to decide if it's correct and appropriate. Sarita: Agrees that Claude's thoughts are valid. We need to decide how to approach this from a modeling perspective. If we were to put it in the VA extension and classify it, we would get whatever inheritance exists and put it into our own concepts. Keith: His goal is this expression would be a concept in the VA extension. He realizes there will be issues of very long names. To offset the impact, feel free to violate the rules, such as no abbreviations are allowed and you could use "BP" for blood pressure. Sarita: When we have the observable with the result, traditionally that is considered a finding in SNOMED> Keith: (Missed the first part of what he said.) He is fine with putting row 8 in the extension whenever you feel it fits the best and that is observable entity. Claude: You might be talking about different kinds of results. When you say "result," if you say blue eye color, is the result "blue"? Keith: Yes, that is described in CIF and in that case, blue is the value because the property being measured is the color. Claude: For diabetes, such as presence or absence, it is a little different. In the observable SNOMED model for result, it is outside of the terminology expression and they call it an incomplete model. For finding, such as blue eye color or patient has diabetes, the whole finding can be expressed in the concept model. In the TSR that goes with the finding of blue eye color, the result is a range, whether we are saying either it's present or absent. He wanted to ensure he understood what Sarita was talking about in terms of the TSR. Keith: He isn't sure he followed all of that. Asking a patient what is your eye color is neither a finding nor observable entity - is it both. Does that give us heartburn and we need to discuss it? The phenomenon of the color of someone's eye, I don't know how to say it's one or the other. Claude: If you have the question "what is your eye color" and expect an answer, the range of attributes (i.e., eye color) would be an observable entity within that hierarchy. Keith: The phenomenon is eye color and the measured value is blue. This is where the confusion comes in. You can have different people provide different answers. There is also the soft default. If we have this SNOMED code in the findings taxonomy for blue eye color with no indication of presence or absence, you assume it is present, which is the soft default, which is not the same thing as saying finding of blue eye color is present. The finding of blue eye in the finding taxonomy is supposed to say it's a finding phenomenon. Catherine: How would we model eye color? Keith: That is why we are trying to make use of the language with ANF and CIF and they are two different transformations of the same thing. Both ways of stating it are valid and transformable. Claude: The second question he has is regarding the SNOMED concept model for observable entity. Will SOLOR define essentially a new model that doesn't make this sort of artificial distinction? Would you expect two concept models? Keith: No. He looked at color of iris and there were differences with it. It's a false dichotomy. Sarita: It makes sense to her, given the environment she was previously in. It was their approach that there was an implied presence/absence or value/context. That is why there are so many findings or concepts that should be in the situation hierarchy instead. Keith: We need to harmonize those with the clinical statement model and stop trying to make the distinction between findings and observable entity. Sarita: When we get to the procedure model, the context is in the title of the models and of the titles of the fields. There isn't really anywhere that context is represented and should be in the model and field names. Keith: When David Sperzel was working with us, he pushed how would we represent a present/absent value and they used the "is about." It doesn't really solve the problem that it was trying to address. Claude: He can go over where that information is included.

Action items

Claude Nanjo: Determine with Chris Peck if Confluence will be done through Cognitive or HSPC. UPDATE 11/29/17: Per Chris Peck, "the CDS contractor team post things to the SharePoint site at the VA. We do not generally use Google Drive (or Confluence) as a platform for sharing items." Stephanie notified him that at least for the ANF modeling, some documents have been put on Google drive, which VA employees cannot access. A separate issue as to which instance of Jira Cognitive/B3 is using, Chris stated "We are using Cognitive/B3's instance of Jira for TSR requests & KNART production. I understand the plan is to provide an export of the Jira projects at the end of this contract so that it can be loaded to other places, like HSPC."
Stephanie Klepacki: Add a JIRA issue for the items shown above in the minutes in bold.