Thanks Roger! Let's devote some time to this on next week's design call.

-Darius

On Thu, Feb 23, 2012 at 9:31 AM, Friedman, Roger (CDC/CGH/DGHA) (CTR) <
[email protected]> wrote:

>  Per the dev call, here are some REST use cases:****
>
> ** **
>
> 1.  Raxa JSS Patient Registration example****
>
> ** **
>
> Names are often duplicated in this area; to discriminate between
> duplicates, a number of fields are used.  So ?q is done against the patient
> resources based on the name.  We want to display a table with the following
> fields:****
>
> a.            Patient ID (from preferred ID type of patient)****
>
> b.            Patient Name (from preferred name of patient)****
>
> c.             Village (from address2 field of preferred address)****
>
> d.            Sex (from person)****
>
> e.            DOB (from person)****
>
> f.             Father or Husband Name (from patient attribute
> Father_Husband of patient)****
>
> g.            Caste (from patient attribute Caste of patient)****
>
> h.            A link represented as an icon going to a new page with
> patient UUID as param****
>
> ** **
>
> 2.  HR Module example****
>
> ** **
>
> A particular instance of OpenMRS manages positions at locations which have
> the tag "HR".  A table called "post" contains a reference to a location and
> a job title (from another table).  A table called "post_history" contains a
> reference to a person and a post plus start_date, end_date and other data.
> Note that a person can appear in a post_history record from a location not
> managed by this instance of OpenMRS.  We want a table, in location
> hierarchy order, for locations which have the "HR" tag, of all post_history
> records with a null end date, showing person information, as follows:****
>
> a.            Location hierarchy number (from location attribute
> Hierarchy_Number)****
>
> b.            Location name (from location)****
>
> c.             Post ID (from post table)****
>
> d.            Job title (from job_title reference in post  table)****
>
> e.            Employee number (person attribute)****
>
> f.             Person name (preferred name from person)****
>
> g.            Salary grade (from post_history)****
>
> h.            Start date (from post_history)****
>
> i.              A link represented as an icon going to a new page with
> post_history UUID as param****
>
> ** **
>
> 3.  Lab Module example****
>
> ** **
>
> A table called panel contains a location (lab offering test), a section
> concept _id (lab section which performs test), a panel concept_id (name of
> panel which is a concept set), and other information.  A table called test
> is a child table of panel and contains a test concept_id (name of test
> which is a member of the panel's concept set), a result_type (CONCEPT or
> NUMERIC), a sort_weight and other information.  If the test type is
> CONCEPT, then the test will be a question in concept_answer, which will
> have all possible answer concepts.  If the test type is NUMERIC, then there
> may be corresponding record in test_ranges.  Test_ranges contains test_id
> (link back to test), a logic rule definition reference, a sort_weight, and
> high and low normal and critical values.  Based on a ?q on panel searching
> on a panel name (which is really in concept), produce a table with the
> following:****
>
> a.            A link represented as an icon going to a new page with panel
> UUID as param****
>
> b.            Panel name (from panel concept in panel) (sort 2)****
>
> c.             Lab name (from location in panel) (sort 1)****
>
> d.            Section name (from section concept in panel)****
>
> e.            Cost (from panel)****
>
> f.             Turnaround time (from panel)****
>
> g.            Sort_weight (from test) (sort 3)****
>
> h.            Test name (from test concept) ****
>
> i.              Sort_weight (from concept_answer for CONCEPT test type,
> from test_range for NUMERIC test type) (sort 4)****
>
> j.             Result text (from concept found in concept_answer) (for
> CONCEPT test type)****
>
> k.            Logic rule token (from logic rule definition in test_ranges)
> ****
>
> ** **
>
>   ****
>

_________________________________________

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

[mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]

Reply via email to