This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

RIMBAA 201103 Minutes Washington DC

From HL7Wiki
Jump to navigation Jump to search

On March 30 and 31 an international RIMBAA meeting was held in Washington DC.

March 31 Agenda (09:00-14:00)

  1. Review of open Action items
  2. Update on outcomes of the Object Equivalence, determination of issue (Rene Spronk)
  3. Issues related to the querying of a RIM based persistence layer (Rene Spronk)
    • In the past the RIMBAA WG has seen various approaches to retrieving subsets of clinical data from a RIM based persistence layer (notably for data mining purposes / OLAP). Rene will provide an overview of the various issues, including how one determines the scope of the data which should be returned, versioning, use of metamodel repositories, data 'safety'.
  4. Solving data analytics for CDM using a RIM based approach (Diane Gutiw, Senior Technology Director, SAIC Canada, max. 45 minutes)
    • Chronic Disease Management (CDM) is an area where collaborative teams of clinicians share data on patient demographics, encounters, disease events, treatment protocols and outcomes to determine the most effective treatment protocols and regimes. CDM data and documents are stored in numerous clinician point of service systems such as EMRs, hospital ADTs and clinical information systems. Canada Health Infoway funded the development of an HL7 v3 CDM message to help avoid manual re-entry of relevant data. The objective of this message is to facilitate the collection, transformation and normalization of CDM data and clinical document attachments.
    • The next step in this process is to implement the HL7 v3 message into a RIM-based Shared Health Record and point of service clinical applications. Various approaches to the development and implementation of this RIM based solution will be discussed.
  5. Persistence Models versus Interoperability Models (Rene Spronk)
    • See wiki page linked to above for the current state of the discussion.
  6. Status update/discussion: Datatypes R2 Programming Library, JavaSIG 2010

RIMBAA WGM #30 - March 30 Agenda (10:00-17:00)

Workgroup Date/Time Location Chair/Scribe
RIMBAA WG 2011-03-30,
10:00-17:00
Washington DC, US C/S: Rene Spronk

Attendance

At Name Affiliation Email Address
X Ann Wrightson NHS Wales, UK ann.wrightson@wales.nhs.uk
X Dan Kokotov 5AM Solutions, US dkokotov@5amsolutions.com
X Diane Gutiw SAIC, US gutiwd@saic.com
X Geoffry Roberts Blue Thread LLC, US geoffry.roberts@gmail.com
X George de la Torre Tufts Health, US delatorre.george@gmail.com
X Gordon Raup Datuit LLC, US graup@datuit.com
X Jean Henri Duteau GPI, CA jean.duteau@gpinformatics.com
X John Koisch Guidewire Architecture, CA jkoisch@guidewirearchitecture.com
X Kenneth Salyards SAMSHA, US kenneth.salyards@samsha.hhs.gov
X Lorraine Constable CA lorraine@constable.ca
X Mike Rossman KP, US michael.k.rossman@kp.org
X Pascal Mattiocco KP, US pmattiocco@yahoo.com
X Peter Hendler KP, US peter@hendler.net
X Rene Spronk Ringholm, NL rene.spronk@ringholm.com
X Richard Thoreson SAMSHA-CSAT, US richard.thoreson@samsha.hhs.gov
X Todd Parnell 5AM Solutions, US tparnell@5amsolutions.com

Minutes

  1. Rene calls to order at 10:15
  2. Administrative
  3. Validation aspects of the caCIS project at NCI (Todd Parnell, Dan Kokotov, 5AMSolutions, see http://www.hl7.org/library/committees/java/20110330_RIMBAA_HL7_V3_validation.ppt for slides)
    • Schematron validation. Schematron has been extensively used to validate R2 datatypes in the XML ITS using an open source tech stack. Local modifications have been made to the MIF tooling to do validation of local datatype flavors. Todd will show how the use of schematron fits into the overall validation picture,which includes schema, vocab, and other layers.
    • Dan: “a post-mortem analysis”. Responsible for Enterprise Service Development (ESD).
    • V3 with Datatypes R2. About 70 RMIMs, with more to come. 50 project specific datatype flavors. SOAP with WS-* stack. XSDs and WSDL implied by HL7 tooling used. Tolven as a persistence layer.
    • Focus of this presentation is validation of incoming messages.
    • In addition to schema validation, added custom (message specific) code for validation, and validation at the model level (message independent validation –a model may be used in multiple messages)
    • Datatypes R2 has lots of invariants. Coding by hand would have taken a long time. Published schema for R2 has schematron rules – how could we use those? Had to fix a number of things. They had no context, were defined in an abstract fashion. OCL statements in R2 spec had issues, needed fixing. Limited in the depth (recursion) one can tackle in data types.
    • Create model(message) specific explicit schematron file. Didn’t create a ‘external bean validation’ code generator from the schematron – that would be much more work.
    • At a next phase, data type flavors were introduced to the project. Modified v3Generator to insert flavor names in XSDs.
    • Jean: we should incorporate changes into standard v3generator (Infoway is funding the development). Rene: schematron generator as well? Jean: ah, well, don’t know about that.
    • Dan: started trying to avoid MDA, the more we implemented, the more we realized that until you do everything with full RIM awareness all other things are a band-aid. In the context of HL7 v3 MDA is the only way to achieve full semantics.
    • Validation strategy depends on the IP being used. For example: some elements of datatypes are important for storage of long lived things.
    • Q&A: John: even iof RIM ITS, still explosion of models. Validation even more complex. Dan: with namespaces and element names (e.g. AD for all addresses) it would have been better, but right now, no. Todd: solid element names, potential to even use SAX level validation.
    • Ann: you were unable to use XSLT2, because requirement of using open source. What was the associated cost for not having that option. Todd: the additional investment was Dan’s time in time of additional coding effort, 2 or 3 developer weeks. Jean: also a run time cost in terms of performance.
    • Jean: RIMBAA should ensure that some of these issues are surfaced to Tooling.
      • Issues are: use data type names as elemnt names; support for data type flavors in v3 schema generator, xxxxxxxxxx
  4. Experiences with using the RIM to enable agile architecture - start developing and capturing data while use cases are forming (George de la Torre, Tufts Health, see http://www.hl7.org/library/committees/java/20110330_RIMBAA_Agile-RIM.ppt for slides).
    • George has been developing clinical based applications based on RIM Java objects for the past 6 years. Examples include: Proteomics experiments/robotics, Public Health immunization registries, Genomics EDC application, Clinical Repository and recently a Clinical Trials Scheduling system for the Harvard Medical School (HMS). He will focus on how the RIM enables agile architecture, that is, how one can start developing and capturing data while use cases are forming. The HMS case study is a great example..
    • George: started being intered in RIM approaches around 1994, with the USAM proposal. I’ll use a case study to illustrate. George has been docing 10 years of application developments – different types of systems. Using RIM models (pretty much as is), always seems to fulfill the requirements. Future proof model. Good architecture, puts everything into 1 model.
    • Agile – start developing right away, without doing tons of requirements analysis. Show users (clinical users) an app and get them to comment.
    • GCRC – general clinical research center. Grant by NIH to create one unit across all Harvard organizations. No clinical-trial based data collection, but across all clinical trials. ‘Harvard Catalyst’ is the name of this project, which receives study grants.
    • Started with RIM model. Had to create a federated model across institutes. If I can get this to work I can show how powerful the RIM is. Start with modeling baseline: organizations, responsible parties, materials. Not services, too specific to each different clinical trial. RIM made it easy to support dashboards.
    • What’s the architecture? Domain driven design - 15 core team members, 40 domain experts, 5 software developers. RIM in the context of application development is very productive. Presents Domain Driven development (DDD) patterns.
    • Rene: Side note: Bounded Context + Aggregate Root DDD concepts = SMIRF
    • Agile RIM, lessons: RIM is a model for transactional commands. RIM is optimized for commands, open/generic/extensible enough that models stays intact if new requirements come in. View (based on published events) to optimize the user experience. View Model is a denormalized RIM model. Query is based on View Model. View Model specif for each Harvard organization because of differences in applications and requirements. Different View Model for extranet user interface. Example: view model on ‘resource’, underlying RIM model has manufactured material, assigned roles, organizations. RIM is transactional model; View Model is read only.
    • If you remember 1 thing: RIM, and I applied it many times, same interactions/models, I hear patterns of requirements. I hear “the RIM”.
    • Ann: benefits from the RIM being a standard? George: community shared design knowledge (v3 D-MIMs).
    • Rene: does this use any sort of meta model repository? George: no, tied to one specific RIM version.
    • (Todd and Dan leave the meeting; Richard joins the meeting)
  5. So it's a RIMBAA - so what? (Ann Wrightson ,NHS Wales Informatics Service - UK, see http://www.hl7.org/library/committees/java/20110330_So_it_s_a_RIMBAA.ppt for slides)
    • The fact that the internal model of an application is RIM-based has a "good feeling" in the context of communication using messages, documents or services based on the same RIM. What lies behind this good feeling? An architectural and philosophical exploration of the role of a RIM-based application alongside RIM-based interoperability standards in meaningful human-to-human communication such as a transfer of care using a patient summary expressed as a CDA document.
    • Ann: presenting some highlights from I paper I wrote a couple of years ago. I will be able to share the original paper at a later point in time.
    • Information flow between Clinicains – long distance with a lot of steps. Diagram shows optimal situation – with perfect ability to express knowledge in XML.
    • What does the RIM provide? Makes middle tier more sturdy, but doesn’t change the overall picture that much. What is we use the RIM at one of the endpoints? Much stronger relationship, provides a warm feeling in terms of alignment. What if we apply RIM all around? If one makes sure that all is the RIM, is that the proper way to stitch things together?
    • Ann presents a formal logic analysis. One does have the RIM, but it’s about clinical information in a particular context. Taking information out of its context and interpreting it in another context (a different perspective) – that’s the main issue.
    • Different universes of discourses, all expressed in RIM language. George’s presentation did show that RIM works really well in one application, but is difficult elsewhere.
  6. An approach to WSDL generation, and how to associate them with RMIMs. (Lorraine/Jean/John K.)
    • This approach is also used at NCI.
    • Services have a 'payload' R-MIMs; with context (e.g. author, patient) removed; the context shows up as a service parameter. The service 'payload' may consist of a simple II data type instance.
    • John: there is a fair amount of philosophy in this presentation.
    • caCIS , wanted to create a list of atomic services. Lots of analysis to determine the correct level. Main goal is reusability. Want to provide reusable contracts. In an EA WSDLs need to realize the requirements. Atomic QRL (query/retrieve/locate) services. Assemble those into e.g. a CDA document builder or a UI view.
    • Information content: lots of content needs to be decomposed – breakdown of full payload into appropriate service parameters. Fixed mood/status codes, explicit given a service contact (e.g. create a new patient). Lots of models, leads to governance issues on reusability and model management.
    • Reusable contracts: community contract, service contract, environmental contract. We defined a contract binding, a kind of wrapper.
    • WSDL generation – created a WSDL generator. Agile development process. MDA driven design. Goal is also un-hiding the complexity (developers have a tendency to hide the complexity, to avoid having to deal with it).
    • WSDL generator: XMI based tool, using EA. Objective is to bind the modeling in EA, to output of v3Generator and to the output of the RMIM designer. WSDLs are composites – all of the things need to come together.
    • Pascal: SOA-ML? John: good for modeling behavior. Doesn’t capture the reusability of jurisdictional patterns. We haven’t invalidated SOA-ML, our solution is maybe a step towards that.
    • (Kenneth and Richard leave the meeting)
  7. The KIS (Keep It Simple) EHR Architecture (Gordon Raup, Datuit LLC)
    • We are pursuing the development of a different architecture for EHRs:
      • The basic idea is to split both the logic and the data into small chunks so that they can be handled in a uniform fashion, allowing many different vendors and independent developers to work on the parts they know best and have everything work together as a whole. For example we use small separate electronic documents as the unit of permanent storage (almost certainly in the cloud), instead of databases
      • The current focus on interoperability and Health Information Exchanges (HIEs) only really supports serial collaboration (I'll take care of this patient and then refer them to you). To support true simultaneous collaboration, each provider caring for the patient needs to be able to access the patients entire chart at any time, all the time. This is not possible with the current architecture of storing the data for each provider in separate databases in separate locations. It is with the new architecture we are proposing.
    • Gordon: started by a business need, cross provider collaboration. Goal: a single Electronic Chart for the patients that all vendors use. Allow provider to modify EHRS without vendor assistance.
    • Current HIT database model = “the hairball” (lots of strange mappings). Data is stored in silos. Provider is dependent on vendor, innovation is expensive.
    • KIS Framework: part 1: document model. All permanent storage is done in documents. CCD/CDA/RIM based document standards. Use logic Apps to extract and combine data from multiple documents, create summary information.
    • Try to predict what the end user is going to ask for, and to have data ready if an when the user requires it. Predictive modeling (in “Accelerator App”) based on user past behavior, knowledge of health system, patient health status.
    • KIS framework, part 2: the assembly line. Apps from other vendors that create documents. Create interchangeable UI apps.
    • Attempting to commoditize healthcare data, by providing a backend storage layer. Utility model. Cloud model.
    • Rene: Document = XML document, or ‘document paradigm’ ? Gordon: all RIM-based XML blobs, they’d be stored as documents though.
    • Gordon: BigTable, not SQL. May not be doable, will not be easy, to create today.
    • Diane: does utility model work, what’s the vendor motivation? Gordon: this will be something that people will embrace because it works.
    • Ann: you’re doing the information coalescing, and nested apps on the other hand. May require two different business structure.
    • Rene: taking data out of the content of a CDA document is potentially dangerous. Gordon: we have control over the system, so we control the context and content of any CDA documents.
  8. Meeting adjournes at 16:00