| 40min | Update on CDS Effort and White Papers | Catherine | - The CDS team has been reviewing the white papers and providing comments back to the contractor. During that process, a significant number of issues has been raised. There are a set of things, such as improved QA, that needs to be done before the white papers are submitted to the CDS team for review. There are issues occurring across multiple white papers. Another holdup is that the white papers are in different stages of evolution. The CDS team is meeting with the contractor to address multiple issues for multiple white papers vs. addressing them one at a time. The plan is to apply the decisions made to the chest pain and breast cancer white papers. Diane and Apurva are in the process of prioritizing the white papers.
- Keith: If we could standardize on a use case format for the deliverables, that would also help to ensure future releases address the issues by making sure they comply with the standard form. Catherine: What we are talking about is responding to the white papers. Keith: Shared an example of a use case document, which is also in DocBook format. It uses a standard format that MITRE developed for Clinical Care Ontology (CCO). He previously shared it with Claude, and Joey may have seen it as well. Stephanie also sent it to Diane indicating that if they were in the standard language for order sets and documentation templates, it would be valuable.
- Keith: He would like the white papers to provide use cases and be in DocBook format. Each use case has a standard set of sections, such as Introduction, Actors, Description, and Triggers. Keith displayed the document that has multiple use cases, such as for Unstable Angina. We will make the use cases more comprehensive over time. They are meant to be collaborative between the business owners and the development team. There is a section for the normal flow of the use case. For the example of sublingual nitroglycerin that requires more detailed instructions, we can identify, based on the business requirements of the use case, in the data fields required section, the sublingual nitroglycerin PRN and provide more detail, such as the type of clinical statement (e.g., action performance). The use case document also has references relating to each use case. This is similar to the content that the CDS KNART contractor has developed in the white papers, but it's different enough that we will lose valuable work because we're not integrated well and where both are provided in a common format. Since use case-driven seems to be a well-accepted paradigm, we should focus there.
- Catherine: She has not seen the use case document before. She recommends that Rocky Reston be involved. She thinks there may be two levels of white papers: 1) the clinical content white paper and 2) the conceptual structure. Maybe this documentation for use case would be what is expected in the second level. Claude: For the conceptual structure, that is the L2 representation. (NOTE: L2 is a semi-structured form, and a representation of the L1 narrative but generally following some kind of grammar, and still in human understandable form. L2 is not bound to a representation of a model.) Keith: Part of his belief is that any of the TSRs should be pulled out of the use case. For example, here is a phrase you need to model. It could be a smaller use case that is for a specific purpose. For example, we could come up with use cases specific to writing instructions for administering nitroglycerin to a patient. Or, we could capture it in this larger use case. This is how I think we should proceed, but it will take some time to get there. For now, what is the basis for which a TSR is launched because it seems kind of loose. Claude: The white paper is essentially a use case document. Keith: In some regards, we are violently agreeing. You are saying the document is serving the purpose of the use case. I am saying we want them to be consistent. Claude: We will be able to show you that hopefully early next week. We will have the ANF of the white paper and the L2 form (i.e., conceptual structure). Keith: If we can find a way to harmonize the L2 form to be consistent with the use cases, that would be good.
- Catherine: With respect to modeling, we want to standardize the content that goes into a consult request. Keith: We will have a general use case for what goes into a consult request. IT will have a standard flow and may have alternate flows, each with their own data. Catherine: In the neurosurgery one, it didn't include patient identifiers and demographic data and obviously that needs to be included, and we told the contractor that.
- Catherine: For documentation templates, it's not clear if it's documenting something that needs to be ordered. The problem is the order set has not been defined as one of the deliverables for it. There is no decision support, and it's basically being presented to the clinician. Keith: In part, it's a learning process. If we can push people to use the standard use case processes, it will allow us to evolve and integrate the KNARTs more gracefully. Catherine: There are chunks of things in certain KNARTs, such as for evaluating DVT risk. How do we define linkage to it from other KNARTs? Keith: There is run time language that is defined by the HL7 KNART specification. Each use case has an ID and each flow in the use case has an ID. For example, you could say use #32 and normal flow #1.
- Catherine: How much of this needs to be done in the original white papers vs. the next level of them? For example, we would say we want to point to something that will eventually get content. Claude: This is where we take the semi-structured narrative and turn it into the L2. We need to take the white paper and structure it more formally, and that is what we do in the L2. The white papers are in L1 format. (NOTE: L1 is text in human narrative, intended to be understood by humans and is unstructured.) We are building the L2 from the white papers, which is a sanity check to say what is in the white paper can really be structured.
- Keith: We don't want them focusing on representation; rather, we want them to focus on what needs to be represented - what is clinically significant that needs to be represented. It's our job to figure out the clinical statement models. They should stick to a clinical narrative and underline what they feel is a clinical statement. We don't need them to say a patient's pregnancy status is true and refutability is false, for example.
- Claude: He talked with Rocky about this. What we need from the white paper is for the requirements to be clear enough so we can structure it. They shouldn't need to know about ANF or visual representation.
- Keith: L1 is a narrative of a use case. As you move to L2 and L3, you are moving to Java-like code. (NOTE: L3 is a platform-independent, declarative representation of that model but not tied to a technology like Java. There is also L4.)
- Catherine: For the white papers, are they L1 or L2 because they look like something in between. Claude: They are technically L1 but they are sort of in between. Keith: Wants L1 to look more and more like a use case format that we all agree on, and we could revise that format if need be.
- Claude: We will have a TSR for an order set and a documentation template. Cognitive wants to know what they will do with the UUID. He has one for a topic and one for the instruction so they can start building the KNART. Keith: Have a quick huddle with Sarita and Kirsten and the question to be answered is to you provide the UUID with your spreadsheet or do they provide it to you after the spreadsheet has been provided to them? Claude: He thinks it's better that Deloitte provides the UUID in the event it's a request for something that already exists. Keith: Agrees, provided they can turn around the UUIDs in a timeframe that is acceptable to you. Claude: Our goal is work with Deloitte on this rather than a "throw it over the fence" relationship. We want to be coordinated between the two groups.
- Catherine: Showed an example for rheumatoid arthritis that has a different representation for medication history. Keith: It's okay for that particular purpose. We need to ensure the model can represent it but there are also other complexities we have to represent as well. Being able to represent different granularity levels within a single model is a requirement. This medication history would be a contributor for use cases for an action request, but medication history would be for a rheumatic consult form. Catherine: Her point is when we are doing this, we need to look across multiple white papers and not just one. She isn't sure how to do that. Keith: The first step is to get it into semantic-based markup in DocBook. It will have a number and an item. We can reference multiple documents within a single document. For example, here is our medication request requirements and they are in these 15 white papers. You could do something similar with a wiki page but it's not semantic-based markup. DocBook is where we have been trying to formalize it and get the white papers in DocBook format. Catherine: They are in DocBook format. Keith: Then they need to get checked into the IA Compendium so we can change them and start making cross-references. Perhaps Rocky should start attending the Monday calls where we discuss this type of information and how to get this information into DocBook in a prospective way. Claude: Asked Catherine if she wants to debrief Rocky. Claude has also discussed this with Rocky. There has to be some kind of structure in the white paper that allows you to capture use cases in a more consistent manner. Keith: Absolutely agree. We have an XML structure for use cases in DocBook, and if we could get that L1 structure in DocBook, that is a huge step in the right direction.
|
| 15min | ANF Modeling of Nitroglycerin Use Case | Group | - Keith: He put in the chat window (see below) the more detailed instructions for the nitroglycerin use case that is in part in response to Bob Greenes' questions from the Monday IA CDS call.
- One (nitroglycerin) tablet should be dissolved under the tongue or in the buccal pouch at the first sign of an acute anginal attack. The dose may be repeated approximately every 5 minutes until relief is obtained. If the pain persists after a total of 3 tablets in a 15-minute period, or if the pain is different than is typically experienced, prompt medical attention is recommended. Nitroglycerin may be used prophylactically 5 to 10 minutes prior to engaging in activities that might precipitate an acute attack. During administration, the patient should rest, preferably in the sitting position.
- Keith: Let's take this nitroglycerin example as a use case and figure out how to represent these details with the topic and the particular divisions of circumstances that we think is appropriate. There is a repetition but also a bound to it and bound for episode.
- Claude: Is this use documented in our white paper? Kirsten: Keith just put it in the chat window. She just put it into her ANF modeling guidelines document so we have it. Are these instructions not specific to any sort of situation and just inherent to nitroglycerin administration? Keith: That is part of the question that we need to answer; here is a set of instructions - what part is general and what part is not? We don't have enough time today than to do more than just introduce the topic. For our Tuesday call, he would like to have an action request model and turn this into a use case. We will need to keep other topics out of that call until we finish focusing on modeling.
- Claude: He will look at this use case.
- Claude: For the circumstances part, if there is a UUID with an assumption, they will be handled by some sort of concept model. Keith: The circumstance as part of a request is what we'll discuss on the Tuesday call. There will be a technique field in the circumstance field with its UUID, and another UUID for repetition, for example. In other words, each portion of the circumstance will have its own UUID. Kirsten: There isn't an over-arching UUID for circumstance. Claude: He would like to propose to Keith how they would break it down. Keith: If you want to bring a number of fields that we can reach agreement on quickly, that will be fine.
|