OpenMRS CDA Generator Presentation Slides
•Download as PPTX, PDF•
0 likes•572 views
The OpenMRS CDA Generator Module allows generation of CDA (Clinical Document Architecture) documents from OpenMRS. During the summer, the intern aimed to generate a valid CDA APHP message. They used the MDHT API to produce CDA documents and accomplished generating flexible CDA documents, populating required sections, and producing valid and error CDA messages. Next steps include adding tests, documentation, and integrating with the concept dictionary.
Recommended
Recommended
More Related Content
Similar to OpenMRS CDA Generator Presentation Slides
Similar to OpenMRS CDA Generator Presentation Slides (20)
Recently uploaded
Recently uploaded (20)
OpenMRS CDA Generator Presentation Slides
- 1. OpenMRS CDA Generator Module Intern • Vaibhav Agarwal Primary Mentor • Suranga Nath Kasturirathne Backup Mentor • Jeremy Keiper
- 2. Project Description • The aim of our module is to support the generation of CDA (Clinical Document Architecture) documents from OpenMRS • Our goal for the summer was to generate a valid CDA APHP message
- 3. What, Why and How • CDA is an XML based standard for the exchange of health information. • CDA is straight-forward to implement, and provides a mechanism for incremental semantic interoperability. We selected the MDHT API to produce CDA because • It’s easier • Adequate • Provides functionalities such as validation and consumption of documents.
- 4. Design
- 5. Design
- 6. Overall Accomplishments • Flexibility to Add/Edit/Delete CDA document types and sections. • Populated answers for all sections of a APHP CDA message. • Identified and listed out LOINC codes, SNOMED codes and new concepts that our module needs. • Produced a fully valid CDA message. • Produced an error page to report errors in a CDA message. • Refined CDA Message
- 7. Next Steps for the Project Outstanding tasks • Need to write Junit tests and complete wiki documentation. • Need to work with the MVP CIEL Dictionary team to update the Dictionary with LOINC codes, SNOMED codes and new concepts CDA needs
- 8. Next Steps for the Project Future Enhancements/Improvements? • Ability to Add/Edit/Delete CDA Document types and Sections through User Interface. • create clients to consume CDA’s by hitting a REST Web Service with a patient identifier to download their CDA. • Invoke Gazelle Validator via a web service call
- 9. Demo The demo includes 1. Export CDA Form validation 2. Generate CDA message 3. Generate CDA with Null Observations 4. Intentionally add error to show how our code catches it and report to error page Demo
- 10. Take Away from GSoC? Technical skills • MDHT API • Learning to work with IHE profiles and requirements • OpenMRS Concept Dictionary (about Concepts) • Spring MVC Framework • Junit • Git • Maven, Hibernate • Liquibase • XML
- 11. Take Away from GSoC? Project/People skills • Patience • Etiquette (Especially email etiquette) • Real time experience on SDLC • Communication • Effective utilization of resources (mailing list, IRC , Documentation, mentors help, community members help) • Made lot of friends and Met cool people out there! • Had Fun!
- 12. Resources • Wiki Page: https://wiki.openmrs.org/display/projects/OpenMRS+CDA+Generator • Source Code: https://github.com/openmrs/openmrs-module-cdagenerator • Blog Url : http://kmitvaibhav.wordpress.com/ • OpenMRS IRC Nickname: VaibhavAgarwal • OpenMRS Mail: vaibhavhp@openmrs.org • GMail: kmit.vaibhav@gmail.com
Editor's Notes
- Hello everybody, greetings My name is Vaibhav Agarwal and welcome to the final presentation on openmrs cda generator module for google summer of code 2014 My primary mentor is Suranga Nath Kasturirathne and backup mentor is Jeremy keiper
- The aim of our module is to generate CDA Documents from OpenMRS data on user’s request. CDA stands for Clinical Document Architecture Our work on this module is influenced by OpenHIE plans and they are interested in this module. Our goal for the summer was to produce a good APHP CDA Document
- Let’s quickly answers this questions What is CDA? Clinical Document Architecture (CDA) is a xml based standard for exchange of health information. It is means to achieve interoperability Why CDA? CDA is straight forward to implement and provides a mechanism for incremental semantic interoperability meaning (that is) an implementer can begin with a simple CDA and then add structured data elements over period of time How we are producing CDA Documents? We are using Model driven Health tools (MDHT API) to produce CDA documents for the following reasons i)It is simple ii)it is adequate approach to produce CDA than xml processing and binding techniques iii)it provides functionality to validate the CDA document and consume the CDA document which is important to us.
- During this summer our focus was to generate APHP CDA message, but their many type IHE profile or CDA documents types Now question is, will our module allow any other type of CDA Document? Yes. We have designed our module to ensure that our work is flexible for further extension. If someone wants to add new CDA type documents other than APHP our module accommodate this change. So, our design consists of hierarchy of classes or we call them as hierarchy of handler. BaseCdaTypeHandler is base class which contains all attributes necessary for CDA document and all other handlers extend this BaseCdaTypeHandler (example APHP handler, APS handler or some other handler) In our entire code base we are using the reference of BaseCDATypeHandler to make our work as generic as possible. If we want to add a new CDA Document Type all we need to do is create a class, extend from this BasCdaTypeHandler class and use setter methods to add values that’s it! The same design approach is followed for Section as well. There we have BaseCdaSectionhandler and child handlers extending it.
- Overall accomplishments during this summer are Flexibility to Add/Edit/Delete CDA document type and sections. Populating answers for all sections of a APHP CDA message. Identified and listed out LOINC codes, SNOMED codes and new concepts our module needs. Fully valid CDA message. Error page to report any errors in CDA message. Generated a good APHP CDA Message. 1-> Ability to Add/Edit/Delete CDA document type and sections programmatically 2->Aphp CDA message includes 9 sections populated answers for this sections from our openmrs data (concepts and observation) 3->CDA document require specific loinc codes and snomed codes. So,Identified and listed all loinc codes ,snomed codes and new concepts we are using in our module. 4->Generated CDA document is fully valid according to MDHT validator code in module and external gazelle validator 5->If CDA Document contains error then it will reported on error page and cda document won’t be generated 6->Generate a good APHP CDA Message is all I can say
- Which part of Project aren’t finished? I need to write few Junit tests and complete wiki documentation . Need to work with Andy to update MVP CIEL Dictionary with LOINC codes, SNOMED codes and new concepts which our module needs . I’ll complete this work after soft-pencil down date 11th and would finish before 18th firm pencil down date.
- 1->We can Add/Edit/Delete a CDA Documents and Sections Programmatically but not though UI. 2-> Create clients to consume CDAs by hitting a REST Web Service with a patient identifier and cda document type to download their CDA instead of user downloading through administrative tab. 3->We are using gazelle as a external validator in addition to mdht cda validation code in our module. I’m manually using GUI gazelle validator provides to check our cda documents. So, Instead of this we should call gazelle validator via a web service from our module