ARB 20090924 minutes
Arb Hosting SD, Clinical Statements, O&O, ITS, InM, Patient Care, Pharmacy, PHER, MnM, IC
aka CDA Bakeoff
September 24, 2009
Attendance
Call to order
The meeting was called to order at 1:45 Local by chair Ron Parker with Tony Julian as scribe. 54 persons were present. Quorum was achieved.
Establish the Agenda
Bakeoff(sic) Arb Hosting SD and Clinical Statements, O&O, ITS, InM, Patient Care, Pharmacy, PHER, MnM, IC Summary: Bob Dolin Presentation
Agenda approval
- Calvin Beebe :Summary: SD is time-limited on CDA-R2 - to refresh in 5 year cycle. Significant technical concerns how we manage 'our' clinical statement. Developed Use cases, created a model with act classes and participation, added vocabularies. NEw use cases were identified, then implementation guides were created.
- Calvin Beebe :Started to model. Found a challenge - take all of the domain and shoehorn into clinical statements.
- Issues that we want to discuss:
- Support for domain models from other committees
- Internal consistency across domains - Critical
- Identical XML between HL7 V3 standards
- May want to consider a different ITS
- Simplicity for implementers
- Limited/Fixed set of CDA Schemas for implementers
- Enter into the architecture at varying degrees of sophistication (levels of CDA)
- Supports sophistication
- Supports Meaningful use
- Administrative and Financial Data needs to be addressed
- Should not do patient merge (Grahame)
- Data with dynamic aspects
- Formalization of best practices established over the past five years.
- Extension mechanisms
- Originally extension in different namespaces - end up with set that is Not parseble v/v the RIM
- Creator and Recipient Roles and Responsibilities
- Adopt existing extensions
- Extension mechanisms
- Extensions need to be “validatable” against schema
- Support for schema tooling (e.g., binding, API creation, et cetera).
- Bob’s Idea: Take the SDA Approach, build one model that has four choice boxes [one for each backb
- Ensure that use of components is invariant (e.g., C-METS) for some period of time based on review.
Bob Dolin: Need CDA R3 to be sufficiently broad to cover use cases, and no broader.
Calvin Beebe: DO we want 5 different models, or one.
Bob Dolin: Woody further extended Bobs Idea
Ron Parker: Intent around CDA was to take messages and plunk into CDA construct to use for referral and reporting.
Calvin Beebe: Really nice to have mechanical way to take expressions and apply constraint set. Data inside the CDA generically, with template or transform.
Bob Dolin: There are several patterns
- Basically the RIM minus the dynamic aspects
- Gunthers Stragegy Let the CDA header be a wrapper for the committees model.
- take existing clinical statements to include other classes.
Gunther: CMET with choice boxes.
Bob displayed a picture of the RIM turned into a RMIM.
Grahame: Model from each committee to be placed in CDA. Not all models are suitable for workflows.
Bob: I dont like the idea: Take a class, we would now have twelve different ways to represent an observation.
Gunther: If pharmacy has observation different from other, they would need harmonization.
Austin: Exception: I want to see how an observation is done regardless of implementation guide.
Calvin: Limited set of schemas. We have experience in harmonizing the models. We want the model to be consistent.
Cecil: Echo Austin: Have to have one way to express an observation regardless of domain. Committees should be constrained.
Bob: The principle
Gabby:Violently agree: Identical models regardless of modality, consistent.
Kevin: Have the same concern regarding the presentation of modeling. We want to be a source of models. We would like to be involved with the clinical content.
Larry:When you say each domain submits their requests, could you do that with CDA R2. How is what you are proposing different.
Grahame: Clinical Statements in CDA is restrictive.
Larry:If you opened up Bobs rim-in-a-box?
Grahame: It is scary. I want consistency, but I dont want all of the RIM.
Ron Parker:HEre is the problem. We are not going to use CDA documents for one domains view. Grahame is right. Work Groups own the subject area. Some of us are consumers, but we dont own all of the use cases. We have to be consumers of aspects of the model, but not take all of the content. The use cases and the aspects tell us what the payloads will be. We have to find a way
Calvin: Asking for all of the use cases is too large scope. This has not had venting, but we somehow have to ensure that the work done by the domain committee is somehow what we sent, still using the RIM. CDAR3 requirement may be a template that references a balloted model.
Gunther:What are we talking about? Structured documents, CDA R3?
Bob Dolin:Not necessarily the case that CDA is about a single patient.
Gunther: We have to be real, and do what we have learned to do. There is a process for the clinical statement, we should carry it forward. TO limit the schema, we would have to ask all committes to submit their use cases.
Cecil: Bob brought the content into scope. Only if you say CDA cant be used for this, or may be.
Bob: Only half kidding.
Cecil: Probably not guidelines, public health reporting, NCL.
Kevin: We ned to be precise - DMIM, RMIM, single point of entry.
Calvin: Small set of schemas.
Ron: Grahame stated that those declaring their model in their space own the model. The invested stakeholder will declare.
Liora: In terms of scope, if anyone is unclear, it is NOT SDL, merge, consent: This is a classic issue between expressivity and implementability. Everything is a comprise. CDA R2 is done OK, since it is implemented, and it has inadequacies that have been brought to the committee. DOes not allow appropriate expression of lab, genomics. THe idea of incorporating the entire RIM woul proliferate the problem of inconsistancy: we would inherit this problem. It is elminated by the need for consistancy among domain levels. All of the committees would have put their use cases into clinical statement. We know we need to address financial. Why do domain committees not use clinical statements? If we can develop/agree that the clinical statement model, that expressed sht domain models - we know that future requiremens will come up.
Bob: I dont care if we have solution today - we need insight into how we select a model. If you have insight, it would be helpfull.
Gordy:I am a newbie, from the outside, you did a good job on CDA. Cecil stated that some things should not be CDA, and I ask why?
Cecil: For grahams proposal to work, it means you could not do using subset of RIM.
Kevin: CDA is used for touchstone for fixed specifications. When releasing CDAR3, there might be others with structures used for other purposes. In terms of clinical statement:When domains dont fit, it is a matter of working with the clinical statement patters, domains dont know how to model in clinical statements.
Hans:In my mind it is a level of abstraction. A lot of work in clinical statements to express domains, and is becoming closer to the RIM. Challenge is as the model becomes more generic, how do the constraints get applied consistantly. Wherever I am going with my data set, I have a generic model, but no guidelines. What level do we use? Conceptual notion of template identifiers, I know, and have defined rules that tell me how to do so. Ultimately I can get to the same level of abstraction in support of any content. You cannot go up unless you have that level of abstraction, as well as tools.
Larry: You need constraints beyond clinical statements. I first thought that clinical statements is a model, it is not, it is a pattern. What is simplicity? Constrained to a model, or is the RIM-in-a-box as simple as it gets.
Dale: All of the complexities have problems at the ITS level. At the (SA)EAF level, we have to determine how the split will affect.
David:Einstein said that everything should be as simple as possible, and no simpler. R3 needs to take R2 forward. A number have been on Vocab sessions: Binding terminology to content needs to be discussed. We need to have a consistent information model, which we cannot without a consistent terminology model.
Grahame:One of the emerging issues is clinical architecture: ArB is focused on Enterprise model. I found Liora, Hans, and Davids comments valid.
Cecil:What we have heard is that it is required from the top down as well as the bottom up. We are lobbying from ArB that domain analysis model are critical from the top level, to detect divergence.
Ron Parker:clinical statements are an abstraction that should drive the modeling. The DAM people describe -we talked to CDA about using SAEAF modeling to determine the business: Then we would find flexibility. CDA is successful, other people want to use. SO now we are running out of time. There is an elequent expression of the problem.
Bob: Larrys question is valid. One schema is not necessarily the right way to go. I dont want to go to ballot - we need evidence of simplicity.
Ron Parker:We need design heuristics.
Calvin: Constraint system on top of schema: we have to attack as an organization.
Austin: SD put artifacts in the 12 boxes. Stuff from Kyoto need to be allocated to boxes. Audience determined.
Liora:It is important - the SAEAF will help us speparate ITS from the model. Answer to HANS: clinical statements R2 needs constraints to be implemented.
Kevin: Constraints to CDA will be published as templates. This will provide one solution, bound to guidelines. Not meet everyones requirements.
John Koisch: Should we schedule in January?
Ravi: Backward compatability is needed.
Meeting was adjourned Tony 19:02, 24 September 2009 (UTC)
