New Component based Functionality Idea

classic Classic list List threaded Threaded
9 messages Options
Carl Fourie Carl Fourie
Reply | Threaded
Open this post in threaded view
|

New Component based Functionality Idea

Hi All

I've created a wiki page to track an idea I've had and am working towards called OpenMRS Combi-Pen Components/Modules (its a working title) http://openmrs.org/wiki/Combi-Pen_Component

So the name I'll admit comes from a James Bond movie ;) The general idea is to build a component which will allow the injection of functionality into OpenMRS (Forms and Reports) much like the module extends the functions of OpenMRS.

For example: (taking a scenario we are looking into in Mozambique)
We are developing an OpenMRS solution to track deaths, we would like to add this to already running OpenMRS installs in Mozambique but to do this in say 10 sites requires us to implement the forms and reports (different data dictionaries from ours) at each site. The Combi-Pen solution would allow us to define the mapping of our concepts to the concepts in the live systems and we would simply ship a module file [Combi-Pen: Death] and the site administrator loads it like any other module to activate the functionality.

Thoughts, comments, ideas?

I also have the Mozambique OASIS group working on a Bulk-Concept Create/Upload module (reads data from a csv file) if anyone is working on something similar I'd love to hear about it.

Cheers,
Carl

[hidden email] from OpenMRS Implementers' mailing list
Ben Wolfe Ben Wolfe
Reply | Threaded
Open this post in threaded view
|

Re: New Component based Functionality Idea

This sounds similar to the idea we had about a "content" module.  Or
allowing a module to specify a lot of content (concepts, forms,
encounter types, etc) that get loaded into the system...but only if they
are not there already.

We hadn't gotten any farther with the idea than "we need this type of
functionality".

Ben

Carl Fourie wrote:

> Hi All
>
> I've created a wiki page to track an idea I've had and am working
> towards called OpenMRS Combi-Pen Components/Modules (its a working
> title) http://openmrs.org/wiki/Combi-Pen_Component
>
> So the name I'll admit comes from a James Bond movie ;) The general idea
> is to build a component which will allow the injection of functionality
> into OpenMRS (Forms and Reports) much like the module extends the
> functions of OpenMRS.
>
> For example: (taking a scenario we are looking into in Mozambique)
> We are developing an OpenMRS solution to track deaths, we would like to
> add this to already running OpenMRS installs in Mozambique but to do
> this in say 10 sites requires us to implement the forms and reports
> (different data dictionaries from ours) at each site. The Combi-Pen
> solution would allow us to define the mapping of our concepts to the
> concepts in the live systems and we would simply ship a module file
> [Combi-Pen: Death] and the site administrator loads it like any other
> module to activate the functionality.
>
> Thoughts, comments, ideas?
>
> I also have the Mozambique OASIS group working on a Bulk-Concept
> Create/Upload module (reads data from a csv file) if anyone is working
> on something similar I'd love to hear about it.
>
> Cheers,
> Carl
> ------------------------------------------------------------------------
> Click here to unsubscribe
> <mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l>
> from OpenMRS Implementers' mailing list

_________________________________________

To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-implement-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l]
Owais Ahmed Owais Ahmed
Reply | Threaded
Open this post in threaded view
|

Re: New Component based Functionality Idea

In reply to this post by Carl Fourie
Dear All,

I think both ideas are excellent. They would allow non-developers to make significant improvements to pre-existing implementations or to load content from other systems. This could make OpenMRS the best choice for an EMRS anywhere. This is definitely the way OpenMRS should evolve...assuming the ideas get past the "we need this type of functionality" phase.  :)

-Owais Ahmed
Systems Analyst
Interactive Research and Development
Suite 508, Ibrahim Trade Tower
Main Shahrah-e-Faisal
Karachi 75350 Pakistan
Tel: +92-21-4327697


On Sat, Nov 22, 2008 at 5:21 PM, Carl Fourie <[hidden email]> wrote:
Hi All

I've created a wiki page to track an idea I've had and am working towards called OpenMRS Combi-Pen Components/Modules (its a working title) http://openmrs.org/wiki/Combi-Pen_Component

So the name I'll admit comes from a James Bond movie ;) The general idea is to build a component which will allow the injection of functionality into OpenMRS (Forms and Reports) much like the module extends the functions of OpenMRS.

For example: (taking a scenario we are looking into in Mozambique)
We are developing an OpenMRS solution to track deaths, we would like to add this to already running OpenMRS installs in Mozambique but to do this in say 10 sites requires us to implement the forms and reports (different data dictionaries from ours) at each site. The Combi-Pen solution would allow us to define the mapping of our concepts to the concepts in the live systems and we would simply ship a module file [Combi-Pen: Death] and the site administrator loads it like any other module to activate the functionality.

Thoughts, comments, ideas?

I also have the Mozambique OASIS group working on a Bulk-Concept Create/Upload module (reads data from a csv file) if anyone is working on something similar I'd love to hear about it.

Cheers,
Carl

[hidden email] from OpenMRS Implementers' mailing list


[hidden email] from OpenMRS Implementers' mailing list
Darius Jazayeri Darius Jazayeri
Reply | Threaded
Open this post in threaded view
|

Re: New Component based Functionality Idea

In reply to this post by Carl Fourie
Hi Carl,

I've been thinking about the mapping idea quite a bit recently, and my
solution is identical to something I sent out a couple days ago.

We need a table like this:

/Class/

       

/Namespace/

       

/Key/

       

/Value/

Concept

       

MDR-TB module

       

weight

       

5089

EncounterType

       

Lab Entry module

       

labOrder

       

3

Concept
        HIV Patient Dashboard
        cd4Count
        5497



When a module wants to load content the administrator should see
something like this (and this should be provided in the OpenMRS framework):

    Simple Lab Entry Module needs an Encounter Type like the following:

        Name: Lab Order
        Description: An encounter representing a clinician requesting a
    lab test

    [ I already have this, let me pick it ]      [ Create this please ]

Depending on what the admin picks, the framework may need to create a
new encounter type according to the xml that comes with the module. Then
it creates a mapping to it, so in the code for the module one can write
something like:
    EncounterType et = OpenmrsUtil.lookup(EncType.class, "Lab Entry
module", "labOrder");

-Darius

Carl Fourie wrote:

> Hi All
>
> I've created a wiki page to track an idea I've had and am working
> towards called OpenMRS Combi-Pen Components/Modules (its a working
> title) http://openmrs.org/wiki/Combi-Pen_Component
>
> So the name I'll admit comes from a James Bond movie ;) The general
> idea is to build a component which will allow the injection of
> functionality into OpenMRS (Forms and Reports) much like the module
> extends the functions of OpenMRS.
>
> For example: (taking a scenario we are looking into in Mozambique)
> We are developing an OpenMRS solution to track deaths, we would like
> to add this to already running OpenMRS installs in Mozambique but to
> do this in say 10 sites requires us to implement the forms and reports
> (different data dictionaries from ours) at each site. The Combi-Pen
> solution would allow us to define the mapping of our concepts to the
> concepts in the live systems and we would simply ship a module file
> [Combi-Pen: Death] and the site administrator loads it like any other
> module to activate the functionality.
>
> Thoughts, comments, ideas?
>
> I also have the Mozambique OASIS group working on a Bulk-Concept
> Create/Upload module (reads data from a csv file) if anyone is working
> on something similar I'd love to hear about it.
>
> Cheers,
> Carl
> ------------------------------------------------------------------------
> Click here to unsubscribe
> <mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l>
> from OpenMRS Implementers' mailing list

_________________________________________

To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-implement-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l]
Darius Jazayeri Darius Jazayeri
Reply | Threaded
Open this post in threaded view
|

Re: New Component based Functionality Idea

(Resending in html)

Hi Carl,

I've been thinking about the mapping idea quite a bit recently, and my solution is identical to something I sent out a couple days ago.

We need a table like this:

Class

Namespace

Key

Value

Concept

MDR-TB module

weight

5089

EncounterType

Lab Entry module

labOrder

3

Concept
HIV Patient Dashboard
cd4Count
5497


When a module wants to load content the administrator should see something like this (and this should be provided in the OpenMRS framework):

   Simple Lab Entry Module needs an Encounter Type like this:
   Name: Lab Order
   Description: An encounter representing a clinician requesting a lab test
   [I already have this, let me pick it]      [Create this please]

Depending on what the admin picks, the framework may need to create a new encounter type according to the xml that comes with the module. Then it creates a mapping to it, so in the code for the module one can write something like:
   EncounterType et = OpenmrsUtil.lookup(EncType.class, "Lab Entry module", "labOrder");

-Darius

Darius Jazayeri wrote:
Hi Carl,

I've been thinking about the mapping idea quite a bit recently, and my solution is identical to something I sent out a couple days ago.

We need a table like this:

/Class/

    

/Namespace/

    

/Key/

    

/Value/

Concept

    

MDR-TB module

    

weight

    

5089

EncounterType

    

Lab Entry module

    

labOrder

    

3

Concept
    HIV Patient Dashboard
    cd4Count
    5497



When a module wants to load content the administrator should see something like this (and this should be provided in the OpenMRS framework):

   Simple Lab Entry Module needs an Encounter Type like the following:

       Name: Lab Order
       Description: An encounter representing a clinician requesting a
   lab test

   [ I already have this, let me pick it ]      [ Create this please ]

Depending on what the admin picks, the framework may need to create a new encounter type according to the xml that comes with the module. Then it creates a mapping to it, so in the code for the module one can write something like:
   EncounterType et = OpenmrsUtil.lookup(EncType.class, "Lab Entry module", "labOrder");

-Darius

Carl Fourie wrote:
Hi All

I've created a wiki page to track an idea I've had and am working towards called OpenMRS Combi-Pen Components/Modules (its a working title) http://openmrs.org/wiki/Combi-Pen_Component

So the name I'll admit comes from a James Bond movie ;) The general idea is to build a component which will allow the injection of functionality into OpenMRS (Forms and Reports) much like the module extends the functions of OpenMRS.

For example: (taking a scenario we are looking into in Mozambique)
We are developing an OpenMRS solution to track deaths, we would like to add this to already running OpenMRS installs in Mozambique but to do this in say 10 sites requires us to implement the forms and reports (different data dictionaries from ours) at each site. The Combi-Pen solution would allow us to define the mapping of our concepts to the concepts in the live systems and we would simply ship a module file [Combi-Pen: Death] and the site administrator loads it like any other module to activate the functionality.

Thoughts, comments, ideas?

I also have the Mozambique OASIS group working on a Bulk-Concept Create/Upload module (reads data from a csv file) if anyone is working on something similar I'd love to hear about it.

Cheers,
Carl
------------------------------------------------------------------------
Click here to unsubscribe [hidden email] from OpenMRS Implementers' mailing list

_________________________________________

To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-implement-l" in the  body (not the subject) of your e-mail.

[[hidden email]]

[hidden email] from OpenMRS Implementers' mailing list
Andrew Kanter Andrew Kanter
Reply | Threaded
Open this post in threaded view
|

Re: New Component based Functionality Idea

I think this should take advantage of the reference maps available to concept (see discussion on forum) and of course the plans for the OCC. 
-Andy
 
--------------------
Andrew S. Kanter, MD MPH

- Director of Health Information Systems/Medical Informatics
Millennium Villages Project Earth Institute, Columbia University
- Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology
Columbia University


Email: [hidden email]
Mobile: +1 (646) 469-2421
Office: +1 (212) 305-4842
Skype: akanter-ippnw
Yahoo: andy_kanter



From: Darius Jazayeri <[hidden email]>
To: [hidden email]
Sent: Saturday, November 22, 2008 11:55:56 AM
Subject: Re: [OPENMRS-IMPLEMENTERS] New Component based Functionality Idea

(Resending in html)

Hi Carl,

I've been thinking about the mapping idea quite a bit recently, and my solution is identical to something I sent out a couple days ago.

We need a table like this:

Class

Namespace

Key

Value

Concept

MDR-TB module

weight

5089

EncounterType

Lab Entry module

labOrder

3

Concept
HIV Patient Dashboard
cd4Count
5497


When a module wants to load content the administrator should see something like this (and this should be provided in the OpenMRS framework):

   Simple Lab Entry Module needs an Encounter Type like this:
   Name: Lab Order
   Description: An encounter representing a clinician requesting a lab test
   [I already have this, let me pick it]      [Create this please]

Depending on what the admin picks, the framework may need to create a new encounter type according to the xml that comes with the module. Then it creates a mapping to it, so in the code for the module one can write something like:
   EncounterType et = OpenmrsUtil.lookup(EncType.class, "Lab Entry module", "labOrder");

-Darius

Darius Jazayeri wrote:
Hi Carl,

I've been thinking about the mapping idea quite a bit recently, and my solution is identical to something I sent out a couple days ago.

We need a table like this:

/Class/

    

/Namespace/

    

/Key/

    

/Value/

Concept

    

MDR-TB module

    

weight

    

5089

EncounterType

    

Lab Entry module

    

labOrder

    

3

Concept
    HIV Patient Dashboard
    cd4Count
    5497



When a module wants to load content the administrator should see something like this (and this should be provided in the OpenMRS framework):

   Simple Lab Entry Module needs an Encounter Type like the following:

       Name: Lab Order
       Description: An encounter representing a clinician requesting a
   lab test

   [ I already have this, let me pick it ]      [ Create this please ]

Depending on what the admin picks, the framework may need to create a new encounter type according to the xml that comes with the module. Then it creates a mapping to it, so in the code for the module one can write something like:
   EncounterType et = OpenmrsUtil.lookup(EncType.class, "Lab Entry module", "labOrder");

-Darius

Carl Fourie wrote:
Hi All

I've created a wiki page to track an idea I've had and am working towards called OpenMRS Combi-Pen Components/Modules (its a working title) http://openmrs.org/wiki/Combi-Pen_Component

So the name I'll admit comes from a James Bond movie ;) The general idea is to build a component which will allow the injection of functionality into OpenMRS (Forms and Reports) much like the module extends the functions of OpenMRS.

For example: (taking a scenario we are looking into in Mozambique)
We are developing an OpenMRS solution to track deaths, we would like to add this to already running OpenMRS installs in Mozambique but to do this in say 10 sites requires us to implement the forms and reports (different data dictionaries from ours) at each site. The Combi-Pen solution would allow us to define the mapping of our concepts to the concepts in the live systems and we would simply ship a module file [Combi-Pen: Death] and the site administrator loads it like any other module to activate the functionality.

Thoughts, comments, ideas?

I also have the Mozambique OASIS group working on a Bulk-Concept Create/Upload module (reads data from a csv file) if anyone is working on something similar I'd love to hear about it.

Cheers,
Carl
------------------------------------------------------------------------
Click here to unsubscribe [hidden email] from OpenMRS Implementers' mailing list

_________________________________________

To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-implement-l" in the  body (not the subject) of your e-mail.

[[hidden email]]

[hidden email] from OpenMRS Implementers' mailing list

[hidden email] from OpenMRS Implementers' mailing list
Ben Wolfe Ben Wolfe
Reply | Threaded
Open this post in threaded view
|

Re: New Component based Functionality Idea

This kind of "data loading" isn't the same as the occ stuff.  This
loading is general for all types of data and not really used for
inter-linking different openmrs installations.  I could see concept
content loading special tags/mappings along with it so that mapping
later on is easier, but the other data and objects won't have that and
won't need it really.

Ben

Andrew Kanter wrote:

> I think this should take advantage of the reference maps available to
> concept (see discussion on forum) and of course the plans for the OCC.
> -Andy
>  
> --------------------
> Andrew S. Kanter, MD MPH
>
> - Director of Health Information Systems/Medical Informatics
> Millennium Villages Project Earth Institute, Columbia University
> - Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology
> Columbia University
>
>
> Email: [hidden email]
> Mobile: +1 (646) 469-2421
> Office: +1 (212) 305-4842
> Skype: akanter-ippnw
> Yahoo: andy_kanter
>
>
> ------------------------------------------------------------------------
> *From:* Darius Jazayeri <[hidden email]>
> *To:* [hidden email]
> *Sent:* Saturday, November 22, 2008 11:55:56 AM
> *Subject:* Re: [OPENMRS-IMPLEMENTERS] New Component based Functionality Idea
>
> (Resending in html)
>
> Hi Carl,
>
> I've been thinking about the mapping idea quite a bit recently, and my
> solution is identical to something I sent out a couple days ago.
>
> We need a table like this:
>
> /Class/
>
>
>
> /Namespace/
>
>
>
> /Key/
>
>
>
> /Value/
>
> Concept
>
>
>
> MDR-TB module
>
>
>
> weight
>
>
>
> 5089
>
> EncounterType
>
>
>
> Lab Entry module
>
>
>
> labOrder
>
>
>
> 3
>
> Concept
> HIV Patient Dashboard
> cd4Count
> 5497
>
>
>
> When a module wants to load content the administrator should see
> something like this (and this should be provided in the OpenMRS framework):
>
>    Simple Lab Entry Module needs an Encounter Type like this:
>    Name: Lab Order
>    Description: An encounter representing a clinician requesting a lab test
>    [I already have this, let me pick it]      [Create this please]
>
> Depending on what the admin picks, the framework may need to create a
> new encounter type according to the xml that comes with the module. Then
> it creates a mapping to it, so in the code for the module one can write
> something like:
>    EncounterType et = OpenmrsUtil.lookup(EncType.class, "Lab Entry
> module", "labOrder");
>
> -Darius
>
> Darius Jazayeri wrote:
>> Hi Carl,
>>
>> I've been thinking about the mapping idea quite a bit recently, and my
>> solution is identical to something I sent out a couple days ago.
>>
>> We need a table like this:
>>
>> /Class/
>>
>>    
>>
>> /Namespace/
>>
>>    
>>
>> /Key/
>>
>>    
>>
>> /Value/
>>
>> Concept
>>
>>    
>>
>> MDR-TB module
>>
>>    
>>
>> weight
>>
>>    
>>
>> 5089
>>
>> EncounterType
>>
>>    
>>
>> Lab Entry module
>>
>>    
>>
>> labOrder
>>
>>    
>>
>> 3
>>
>> Concept
>>     HIV Patient Dashboard
>>     cd4Count
>>     5497
>>
>>
>>
>> When a module wants to load content the administrator should see
>> something like this (and this should be provided in the OpenMRS
>> framework):
>>
>>    Simple Lab Entry Module needs an Encounter Type like the following:
>>
>>        Name: Lab Order
>>        Description: An encounter representing a clinician requesting a
>>    lab test
>>
>>    [ I already have this, let me pick it ]      [ Create this please ]
>>
>> Depending on what the admin picks, the framework may need to create a
>> new encounter type according to the xml that comes with the module.
>> Then it creates a mapping to it, so in the code for the module one can
>> write something like:
>>    EncounterType et = OpenmrsUtil.lookup(EncType.class, "Lab Entry
>> module", "labOrder");
>>
>> -Darius
>>
>> Carl Fourie wrote:
>>> Hi All
>>>
>>> I've created a wiki page to track an idea I've had and am working
>>> towards called OpenMRS Combi-Pen Components/Modules (its a working
>>> title) http://openmrs.org/wiki/Combi-Pen_Component
>>>
>>> So the name I'll admit comes from a James Bond movie ;) The general
>>> idea is to build a component which will allow the injection of
>>> functionality into OpenMRS (Forms and Reports) much like the module
>>> extends the functions of OpenMRS.
>>>
>>> For example: (taking a scenario we are looking into in Mozambique)
>>> We are developing an OpenMRS solution to track deaths, we would like
>>> to add this to already running OpenMRS installs in Mozambique but to
>>> do this in say 10 sites requires us to implement the forms and
>>> reports (different data dictionaries from ours) at each site. The
>>> Combi-Pen solution would allow us to define the mapping of our
>>> concepts to the concepts in the live systems and we would simply ship
>>> a module file [Combi-Pen: Death] and the site administrator loads it
>>> like any other module to activate the functionality.
>>>
>>> Thoughts, comments, ideas?
>>>
>>> I also have the Mozambique OASIS group working on a Bulk-Concept
>>> Create/Upload module (reads data from a csv file) if anyone is
>>> working on something similar I'd love to hear about it.
>>>
>>> Cheers,
>>> Carl
>>> ------------------------------------------------------------------------
>>> Click here to unsubscribe
>>> <mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l>
>>> from OpenMRS Implementers' mailing list
>>
>> _________________________________________
>>
>> To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail
>> to [hidden email] with "SIGNOFF openmrs-implement-l" in
>> the  body (not the subject) of your e-mail.
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l]
> ------------------------------------------------------------------------
> Click here to unsubscribe
> <mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l>
> from OpenMRS Implementers' mailing list
> ------------------------------------------------------------------------
> Click here to unsubscribe
> <mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l>
> from OpenMRS Implementers' mailing list

_________________________________________

To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-implement-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l]
Andrew Kanter Andrew Kanter
Reply | Threaded
Open this post in threaded view
|

Re: New Component based Functionality Idea

It just occurred to me that if the new module needed to "link" to a concept within the target system, instead of blindly asking for a similar concept it could look for those concepts mapped to the same reference concept or to a concept with the same OCC id. But I've been so busy I haven't been able to follow these discussions closely. One of these days, I'll get through them.
-Andy
 
--------------------
Andrew S. Kanter, MD MPH

- Director of Health Information Systems/Medical Informatics
Millennium Villages Project Earth Institute, Columbia University
- Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology
Columbia University


Email: [hidden email]
Mobile: +1 (646) 469-2421
Office: +1 (212) 305-4842
Skype: akanter-ippnw
Yahoo: andy_kanter



From: Ben Wolfe <[hidden email]>
To: [hidden email]
Sent: Saturday, November 22, 2008 2:35:29 PM
Subject: Re: [OPENMRS-IMPLEMENTERS] New Component based Functionality Idea

This kind of "data loading" isn't the same as the occ stuff.  This loading is general for all types of data and not really used for inter-linking different openmrs installations.  I could see concept content loading special tags/mappings along with it so that mapping later on is easier, but the other data and objects won't have that and won't need it really.

Ben

Andrew Kanter wrote:
> I think this should take advantage of the reference maps available to concept (see discussion on forum) and of course the plans for the OCC. -Andy
>  --------------------
> Andrew S. Kanter, MD MPH
>
> - Director of Health Information Systems/Medical Informatics
> Millennium Villages Project Earth Institute, Columbia University
> - Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology
> Columbia University
>
>
> Email: [hidden email]
> Mobile: +1 (646) 469-2421
> Office: +1 (212) 305-4842
> Skype: akanter-ippnw
> Yahoo: andy_kanter
>
>
> ------------------------------------------------------------------------
> *From:* Darius Jazayeri <[hidden email]>
> *To:* [hidden email]
> *Sent:* Saturday, November 22, 2008 11:55:56 AM
> *Subject:* Re: [OPENMRS-IMPLEMENTERS] New Component based Functionality Idea
>
> (Resending in html)
>
> Hi Carl,
>
> I've been thinking about the mapping idea quite a bit recently, and my solution is identical to something I sent out a couple days ago.
>
> We need a table like this:
>
> /Class/
>
>    
>
> /Namespace/
>
>    
>
> /Key/
>
>    
>
> /Value/
>
> Concept
>
>    
>
> MDR-TB module
>
>    
>
> weight
>
>    
>
> 5089
>
> EncounterType
>
>    
>
> Lab Entry module
>
>    
>
> labOrder
>
>    
>
> 3
>
> Concept
>     HIV Patient Dashboard
>     cd4Count
>     5497
>
>
>
> When a module wants to load content the administrator should see something like this (and this should be provided in the OpenMRS framework):
>
>    Simple Lab Entry Module needs an Encounter Type like this:
>    Name: Lab Order
>    Description: An encounter representing a clinician requesting a lab test
>    [I already have this, let me pick it]      [Create this please]
>
> Depending on what the admin picks, the framework may need to create a new encounter type according to the xml that comes with the module. Then it creates a mapping to it, so in the code for the module one can write something like:
>    EncounterType et = OpenmrsUtil.lookup(EncType.class, "Lab Entry module", "labOrder");
>
> -Darius
>
> Darius Jazayeri wrote:
>> Hi Carl,
>>
>> I've been thinking about the mapping idea quite a bit recently, and my solution is identical to something I sent out a couple days ago.
>>
>> We need a table like this:
>>
>> /Class/
>>
>>   
>> /Namespace/
>>
>>   
>> /Key/
>>
>>   
>> /Value/
>>
>> Concept
>>
>>   
>> MDR-TB module
>>
>>   
>> weight
>>
>>   
>> 5089
>>
>> EncounterType
>>
>>   
>> Lab Entry module
>>
>>   
>> labOrder
>>
>>   
>> 3
>>
>> Concept
>>    HIV Patient Dashboard
>>    cd4Count
>>    5497
>>
>>
>>
>> When a module wants to load content the administrator should see something like this (and this should be provided in the OpenMRS framework):
>>
>>    Simple Lab Entry Module needs an Encounter Type like the following:
>>
>>        Name: Lab Order
>>        Description: An encounter representing a clinician requesting a
>>    lab test
>>
>>    [ I already have this, let me pick it ]      [ Create this please ]
>>
>> Depending on what the admin picks, the framework may need to create a new encounter type according to the xml that comes with the module. Then it creates a mapping to it, so in the code for the module one can write something like:
>>    EncounterType et = OpenmrsUtil.lookup(EncType.class, "Lab Entry module", "labOrder");
>>
>> -Darius
>>
>> Carl Fourie wrote:
>>> Hi All
>>>
>>> I've created a wiki page to track an idea I've had and am working towards called OpenMRS Combi-Pen Components/Modules (its a working title) http://openmrs.org/wiki/Combi-Pen_Component
>>>
>>> So the name I'll admit comes from a James Bond movie ;) The general idea is to build a component which will allow the injection of functionality into OpenMRS (Forms and Reports) much like the module extends the functions of OpenMRS.
>>>
>>> For example: (taking a scenario we are looking into in Mozambique)
>>> We are developing an OpenMRS solution to track deaths, we would like to add this to already running OpenMRS installs in Mozambique but to do this in say 10 sites requires us to implement the forms and reports (different data dictionaries from ours) at each site. The Combi-Pen solution would allow us to define the mapping of our concepts to the concepts in the live systems and we would simply ship a module file [Combi-Pen: Death] and the site administrator loads it like any other module to activate the functionality.
>>>
>>> Thoughts, comments, ideas?
>>>
>>> I also have the Mozambique OASIS group working on a Bulk-Concept Create/Upload module (reads data from a csv file) if anyone is working on something similar I'd love to hear about it.
>>>
>>> Cheers,
>>> Carl
>>> ------------------------------------------------------------------------
>>> Click here to unsubscribe <mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l> from OpenMRS Implementers' mailing list
>>
>> _________________________________________
>>
>> To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-implement-l" in the  body (not the subject) of your e-mail.
>>
>> [mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l]
> ------------------------------------------------------------------------
> Click here to unsubscribe <mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l> from OpenMRS Implementers' mailing list
> ------------------------------------------------------------------------
> Click here to unsubscribe <mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l> from OpenMRS Implementers' mailing list

_________________________________________

To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-implement-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l]

[hidden email] from OpenMRS Implementers' mailing list
Darius Jazayeri Darius Jazayeri
Reply | Threaded
Open this post in threaded view
|

Re: New Component based Functionality Idea

I think that's absolutely right. If the metadata for the requested
concept includes a mapping that already exists in the database, that
should be used (or at least suggested).

-Darius

Andrew Kanter wrote:

> It just occurred to me that if the new module needed to "link" to a
> concept within the target system, instead of blindly asking for a
> similar concept it could look for those concepts mapped to the same
> reference concept or to a concept with the same OCC id. But I've been
> so busy I haven't been able to follow these discussions closely. One
> of these days, I'll get through them.
> -Andy
>  
> --------------------
> Andrew S. Kanter, MD MPH
>
> - Director of Health Information Systems/Medical Informatics
> Millennium Villages Project Earth Institute, Columbia University
> - Asst. Prof. of Clinical Biomedical Informatics and Clinical Epidemiology
> Columbia University
>
>
> Email: [hidden email]
> Mobile: +1 (646) 469-2421
> Office: +1 (212) 305-4842
> Skype: akanter-ippnw
> Yahoo: andy_kanter
>
>
> ------------------------------------------------------------------------
> *From:* Ben Wolfe <[hidden email]>
> *To:* [hidden email]
> *Sent:* Saturday, November 22, 2008 2:35:29 PM
> *Subject:* Re: [OPENMRS-IMPLEMENTERS] New Component based
> Functionality Idea
>
> This kind of "data loading" isn't the same as the occ stuff.  This
> loading is general for all types of data and not really used for
> inter-linking different openmrs installations.  I could see concept
> content loading special tags/mappings along with it so that mapping
> later on is easier, but the other data and objects won't have that and
> won't need it really.
>
> Ben
>
> Andrew Kanter wrote:
> > I think this should take advantage of the reference maps available
> to concept (see discussion on forum) and of course the plans for the
> OCC. -Andy
> >  --------------------
> > Andrew S. Kanter, MD MPH
> >
> > - Director of Health Information Systems/Medical Informatics
> > Millennium Villages Project Earth Institute, Columbia University
> > - Asst. Prof. of Clinical Biomedical Informatics and Clinical
> Epidemiology
> > Columbia University
> >
> >
> > Email: [hidden email] <mailto:[hidden email]>
> > Mobile: +1 (646) 469-2421
> > Office: +1 (212) 305-4842
> > Skype: akanter-ippnw
> > Yahoo: andy_kanter
> >
> >
> > ------------------------------------------------------------------------
> > *From:* Darius Jazayeri <[hidden email] <mailto:[hidden email]>>
> > *To:* [hidden email]
> <mailto:[hidden email]>
> > *Sent:* Saturday, November 22, 2008 11:55:56 AM
> > *Subject:* Re: [OPENMRS-IMPLEMENTERS] New Component based
> Functionality Idea
> >
> > (Resending in html)
> >
> > Hi Carl,
> >
> > I've been thinking about the mapping idea quite a bit recently, and
> my solution is identical to something I sent out a couple days ago.
> >
> > We need a table like this:
> >
> > /Class/
> >
> >    
> >
> > /Namespace/
> >
> >    
> >
> > /Key/
> >
> >    
> >
> > /Value/
> >
> > Concept
> >
> >    
> >
> > MDR-TB module
> >
> >    
> >
> > weight
> >
> >    
> >
> > 5089
> >
> > EncounterType
> >
> >    
> >
> > Lab Entry module
> >
> >    
> >
> > labOrder
> >
> >    
> >
> > 3
> >
> > Concept
> >     HIV Patient Dashboard
> >     cd4Count
> >     5497
> >
> >
> >
> > When a module wants to load content the administrator should see
> something like this (and this should be provided in the OpenMRS
> framework):
> >
> >    Simple Lab Entry Module needs an Encounter Type like this:
> >    Name: Lab Order
> >    Description: An encounter representing a clinician requesting a
> lab test
> >    [I already have this, let me pick it]      [Create this please]
> >
> > Depending on what the admin picks, the framework may need to create
> a new encounter type according to the xml that comes with the module.
> Then it creates a mapping to it, so in the code for the module one can
> write something like:
> >    EncounterType et = OpenmrsUtil.lookup(EncType.class, "Lab Entry
> module", "labOrder");
> >
> > -Darius
> >
> > Darius Jazayeri wrote:
> >> Hi Carl,
> >>
> >> I've been thinking about the mapping idea quite a bit recently, and
> my solution is identical to something I sent out a couple days ago.
> >>
> >> We need a table like this:
> >>
> >> /Class/
> >>
> >>  
> >> /Namespace/
> >>
> >>  
> >> /Key/
> >>
> >>  
> >> /Value/
> >>
> >> Concept
> >>
> >>  
> >> MDR-TB module
> >>
> >>  
> >> weight
> >>
> >>  
> >> 5089
> >>
> >> EncounterType
> >>
> >>  
> >> Lab Entry module
> >>
> >>  
> >> labOrder
> >>
> >>  
> >> 3
> >>
> >> Concept
> >>    HIV Patient Dashboard
> >>    cd4Count
> >>    5497
> >>
> >>
> >>
> >> When a module wants to load content the administrator should see
> something like this (and this should be provided in the OpenMRS
> framework):
> >>
> >>    Simple Lab Entry Module needs an Encounter Type like the following:
> >>
> >>        Name: Lab Order
> >>        Description: An encounter representing a clinician requesting a
> >>    lab test
> >>
> >>    [ I already have this, let me pick it ]      [ Create this please ]
> >>
> >> Depending on what the admin picks, the framework may need to create
> a new encounter type according to the xml that comes with the module.
> Then it creates a mapping to it, so in the code for the module one can
> write something like:
> >>    EncounterType et = OpenmrsUtil.lookup(EncType.class, "Lab Entry
> module", "labOrder");
> >>
> >> -Darius
> >>
> >> Carl Fourie wrote:
> >>> Hi All
> >>>
> >>> I've created a wiki page to track an idea I've had and am working
> towards called OpenMRS Combi-Pen Components/Modules (its a working
> title) http://openmrs.org/wiki/Combi-Pen_Component
> >>>
> >>> So the name I'll admit comes from a James Bond movie ;) The
> general idea is to build a component which will allow the injection of
> functionality into OpenMRS (Forms and Reports) much like the module
> extends the functions of OpenMRS.
> >>>
> >>> For example: (taking a scenario we are looking into in Mozambique)
> >>> We are developing an OpenMRS solution to track deaths, we would
> like to add this to already running OpenMRS installs in Mozambique but
> to do this in say 10 sites requires us to implement the forms and
> reports (different data dictionaries from ours) at each site. The
> Combi-Pen solution would allow us to define the mapping of our
> concepts to the concepts in the live systems and we would simply ship
> a module file [Combi-Pen: Death] and the site administrator loads it
> like any other module to activate the functionality.
> >>>
> >>> Thoughts, comments, ideas?
> >>>
> >>> I also have the Mozambique OASIS group working on a Bulk-Concept
> Create/Upload module (reads data from a csv file) if anyone is working
> on something similar I'd love to hear about it.
> >>>
> >>> Cheers,
> >>> Carl
> >>>
> ------------------------------------------------------------------------
> >>> Click here to unsubscribe <mailto:[hidden email]
> <mailto:[hidden email]>?body=SIGNOFF%20openmrs-implement-l>
> from OpenMRS Implementers' mailing list
> >>
> >> _________________________________________
> >>
> >> To unsubscribe from OpenMRS Implementers' mailing list, send an
> e-mail to [hidden email]
> <mailto:[hidden email]> with "SIGNOFF
> openmrs-implement-l" in the  body (not the subject) of your e-mail.
> >>
> >> [mailto:[hidden email]
> <mailto:[hidden email]>?body=SIGNOFF%20openmrs-implement-l]
> > ------------------------------------------------------------------------
> > Click here to unsubscribe <mailto:[hidden email]
> <mailto:[hidden email]>?body=SIGNOFF%20openmrs-implement-l>
> from OpenMRS Implementers' mailing list
> > ------------------------------------------------------------------------
> > Click here to unsubscribe <mailto:[hidden email]
> <mailto:[hidden email]>?body=SIGNOFF%20openmrs-implement-l>
> from OpenMRS Implementers' mailing list
>
> _________________________________________
>
> To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail
> to [hidden email] <mailto:[hidden email]>
> with "SIGNOFF openmrs-implement-l" in the  body (not the subject) of
> your e-mail.
>
> [mailto:[hidden email]
> <mailto:[hidden email]>?body=SIGNOFF%20openmrs-implement-l]
> ------------------------------------------------------------------------
> Click here to unsubscribe
> <mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l>
> from OpenMRS Implementers' mailing list

_________________________________________

To unsubscribe from OpenMRS Implementers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-implement-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-implement-l]