Not yet, but I have that in my TODO list! What I will do in the future is to separate the clinical and demographic parts of EHRServer (https://www.youtube.com/watch?v=D-hs-Ofb8SY) so we'll have a pure EHRServer and a DemographicServer, both based on REST services and supporting openEHR archetypes / OPTs 1.4. I may propose this as a student project in the engineering university here in Montevideo, because right now I don't have much development time. Last year I proposed a GUI generation project to improve what EHRGen does right now, but to generate UIs for different technologies (HTML5, .Net web & desktop, Java Swing, etc.). After we present the paper, I will propose the UITemplate model to the community to evaluate if it can be integrated in the future to the openEHR stack (I'm very excited about this!) The idea of the DemographicServer is to emulate IHE PIX/PDQ profiles with openEHR data to simplify future integration with IHE enabled systems. BTW, is really easy to extend EHRGen to add demographic data support, just need to add the model classes (Person, Group, etc.), the data binder and the UI gen for demographic classes fields.
-- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com From: [email protected] Date: Fri, 21 Mar 2014 17:14:56 +0000 Subject: Re: Archetype for patient demographics. To: openehr-technical at lists.openehr.org Hi Pablo, Does your software stack support DEMOGRAPHIC class archetypes? Ian On 21 March 2014 16:51, pablo pazos <pazospablo at hotmail.com> wrote: I would recommend to use archetypes if you now that your data schema will change in the future. E.g. if your system design is based on archetypes, it can allow to change archetypes and store different kinds of information adding or removing stuff from archetypes. This is the approach of EHRGen to generate UI and store data: http://www.youtube.com/watch?v=QqFTU2RC7eI If you know that data schema will not change in the future, you might use archetypes not in the system itself, but for two purposes: 1. communicate data to other systems in openEHR format, 2. specification of the design, as a communication tool that you can show to others to understand your system's design. If not used directly by the system, archetypes are great for requirement gathering and specification. Hope that helps. -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com Date: Fri, 21 Mar 2014 10:13:49 -0600 Subject: Re: Archetype for patient demographics. From: [email protected] To: openehr-technical at lists.openehr.org Thank Pablo for you answer. We want store this information because the RIS, will start stored the information demographic patients and not will have way make query to a MPI. Maybe we need to provide in this projeThank Pablo for you answer. We want store this information because the RIS, will start stored the information demographic patients and not will have way make query to a MPI. Maybe we need to provide in this project an MPI, but this is not even considered yet. So, the RIS need keep this information. The RIS will work with different models of health, as it will be part of a "radiological ring" as a service in several countries and possibly the app will need to adapt not only demographic information, but also in workflow and radiological information as reports MPI, but this is not even considered yet. So, the RIS need keep this information. The app will need to adapt not only demographic information, but also in workflow and radiological information as reports. What then would be the recommendation on the use of archetypes? 2014-03-20 19:32 GMT-06:00 pablo pazos <pazospablo at hotmail.com>: Don't know if I fully understand your question... as you said, these are use to model demographic data, so use them for that. I'll go back a little: where do you want to store demographics in your RIS and for what (for reports, for scheduling, as MPI, ...)? Maybe knowing your specific requirements we can help you on when to use those archetypes. If I were developing a RIS, I would use archetypes and templates to model imaginology reports, and use demographic archetypes to model the demographic part of the reports. That way I can store reports and demographics in an openEHR repo (i.e. an archetype enabled repository). -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com Date: Thu, 20 Mar 2014 10:17:41 -0600 Subject: Re: Archetype for patient demographics. From: [email protected] To: openehr-technical at lists.openehr.org Sorry,When I should use these archetypes? 2014-03-20 10:06 GMT-06:00 pablo pazos <pazospablo at hotmail.com>: Sorry, what's "cases archetypes"? -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com Date: Thu, 20 Mar 2014 09:42:34 -0600 Subject: Re: Archetype for patient demographics. From: [email protected] To: openehr-technical at lists.openehr.org Thanks Pablo. So, for cases archetypes need these archetypes? (Those who put in the first post). Regards 2014-03-18 16:13 GMT-06:00 pablo pazos <pazospablo at hotmail.com>: Hi, you can use plain archetypes since there's no need to create a composition to store patient demographics. I.e. there's no need to create a template to group the demographic information. You'll need a template for exaple to represent radiology report documents. Hope that helps. -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com Date: Tue, 18 Mar 2014 14:53:13 -0600 Subject: Archetype for patient demographics. From: [email protected] To: openehr-technical at lists.openehr.org Hi. We are developing a RIS, which eo archetypes should be used to record patient demographics? We have reviewed the following archetypes in openEHR CKM of: * - Patients (Model Arquetype) * - Person name (Archetype Model) * - Person data (Structure) * - Person name (Arquetype) They should build a template with these? We should use just one? We would appreciate recommendations. regards -- _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com ian at mcmi.co.uk Clinical Analyst Ocean Informatics Honorary Senior Research Associate, CHIME, University College London openEHR Archetype Editorial Group Member BCS Primary Health Care SG Group www.phcsg.org / BCS Health Scotland _______________________________________________ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140321/d3952f23/attachment.html>
