Docstoc

DataStructure

Document Sample
DataStructure Powered By Docstoc
					 UNDERSTANDING
DATA STRUCTURES

Presented by David Hathaway
October 12, 2010
    Meditech’s Database Concept
• Hierarchical Model
• The Hierarchical database organizes its
  data in a tree structure similar to the
  folders on your computer. Just as a file
  can only be in one folder on your
  computer (without making a copy of it); a
  Hierarchical database only allows a record
  to have one parent record (a one-to-many
  relationship). It is easy to traverse the
  structure if you have the parent record.
  However, without it, it becomes a very
  difficult task.
     Introduction to Data Hierarchy
• All components of NPR are stored in
  this hierarchical structure. This
  includes data, programs and
  menus.
• EVERYHING IN MEDITECH IS
  STORED UNDER THIS HIERARCHY!
• Each level (Parent) has a one to
  many (Children) relationship with
  the levels directly below it
• A level is also called a segment.
• A segment is a data file that store
  records within a Data Procedure
  Module
     Introduction to Data Hierarchy
                                      APPLICATION



                       DPM                                MENU



Data Definition                        Procedure



                     Parent Segment



                  Parent Segment



                                          Child Segment



                                                          Child Segment (Grandchild)
              Applications
• Applications are the highest level of data
  storage for NPR.
• All data is broken down into different
  Application segments or Modules.
• Examples of Applications are ADM, BAR,
  OE or RAD.
• Menus are stored under the application
  level allowing users access to the
  procedures (routines) for any individual
  application.
    Data Procedure Module
• Generally referred to as DPM.
• DPMs are a set of closely related data files and
  procedures found within an Application.
• A DPM will contain both the file or data as well
  as the programs used to gather the data.
• An example of this would be the ADM.PAT
  DPM. Within this DPM would be all of the
  patient data as well as the Enter/Edit routines
  used to file the patient’s information.
              Defining DPMs
• The name of the DPM will contain first
  the Application and then a descriptor.
• The descriptor is used to help isolate
  the type of data that the DPM contains.
• ADM.PAT is broken into two parts
   the application: ADM
   the descriptor: PAT
  PAT is referring to the patient files of
  the Admissions module.
 ** A period is always used to separate the two parts of
 the definition **
Sample
                    Data Definitions
• Also called Data Defs are a collection of data
  files called segments.
• Data definitions can be used as an external
  map to see how the data is actually stored
  internally within NPR. Not only is the location
  of the data defined but also the field name
  used to access this data.
• You can either print data definitions via the
  PRINT DATA DEFINITION routine in Report
  Writer or check www.meditech.com for a
  listing for each DPM.

•   The Meditech Website offers additional functionality within
    each Data Def.
Sample Data Defs
             SEGMENTS
• A segment is a data file that stores
  records (fields of data) within a DPM.
• Segments are listed in a Hierarchy
  based on the relationship between the
  data files within each segment. (This
  Hierarchy is shown at the top of every
  data definition).
• Each Parent segment can have many
  child segments.
• An example of this would be that one
  patient visit can have several different
  insurances associated to that visit.
          Defining Segments
• The Hierarchy of a segment is a called a
  “Top Down” relationship.
• It is also referred to as a parent-child
  relationship
• The Top segment is also referred to as the
  Main segment.
• The Top segment is the parent segment for
  all other segments within that Data
  Definition.
• A child segment is a sub-segment to the
  parent.
                Segment Hierarchy

                       PARENT
                      SEGMENT


CHILD SEGMENT      CHILD SEGMENT   CHILD SEGMENT




                                   Grand child Segment
           Segment Hierarchy
• Parents can only have child segments
• A child segment can also be a parent segment
  (grand child)
• Child segments contain additional information
  that is associated with the parent segment.
• A Child segment can contains fields with
  multiple values (Can be referred to as
  multiples in Report Writer)
• Every record stored within a segment must be
  unique
• In order to keep the entries within a database
  unique a data value called a subscript is
  created for each record internally.
      Segments and Fields
An example of a parent segment would
 be a patient record.
  – There can only be one file for a patient visit
  – Each patient visit file will have only one
    name, date of birth, admit date and other
    distinct data
An example of a child segment would be
 insurances that are associated to that
 patient visit.
  - There can be many insurances per visit
  - Each insurance will have different fields
    such as address, phone number, name, etc.
                                Sample
•   An example of the parent
    is the adm.patient.file.
•   This segment is a parent
    segment because it is
    shown to be over to the
    left side of the page.
•   A child segment of this
    segment is the
    adm.pat.allergies
•   It is shown to be
    indented under the
    adm.patient.file segment
    which means it is a child
    of that segment
            SUBSCRIPTS
• A subscript is a unique value that is
  used to identify data within a segment
• Subscripts are comprised of one or
  more data fields that make a record
  unique
• Subscripts define the sort order of
  records within a segment as well as
  provide access to the data fields
• To access any data element within a
  segment the subscripts for that
  segment must be defined!
    Functions of Subscripts
• The MEDITECH system uses an internal
  sequential counter to assign a number
  value to each unique record filed.
• This unique record is called a URN
• This prevents records from being
  overwritten with other records within
  the database
• The first patient visit to be entered in
  ADM.PAT will have a URN of 1, the
  second 2 and so on
              Types of Subscripts
• There are two types of subscripts
   – URNs
   – Mnemonic

URNS are Unique Record numbers that are created within
  the database (internally)
Mnemonics are free text values that container alpha numeric
  characters including spaces and/or punctuation. An
  example of a mnemonic would be a dictionary entry (ex:
  TEST.1).
The MEDITECH system will not allow more then one entry
  with the same mnemonic so all entries are unique.
                     Rules of Subscripts




The subscript above is defined under the segment name (adm.patient.file) and
is the first field listed within the segment. The rest of the fields are listed
alphabetically but the subscript will always be first. With the above example
the subscript is a unique record number or URN (internal).
                         Subscripts




In the above example there are three subscripts that would need to be
defined to access the data within the adm.pat.events.queries segment.
The first is URN, the second is event.date and the third is event.seq.no.

  - All three of these fields will be listed at the top of their
    segments
  - The top or main segment’s subscript is URN.
  - The second and third subscripts are both defined with the
     adm.pat.events segment and are listed at the top of the
     segment.
    Subscripts
ADM.PAT.adm.patient.file
  adm.pat.insurance.order (1 to many)


ADM.PAT.adm.patient.file           Insurance Order File

[1] M00001|DAVIS,JOHN..            [1,1] AETNA
[2] M00002|MOUSE,MICKEY..          [1,2] BC
[3] M00003|MOUSE,MINNIE..          [2,1] MC
[4] M00004|DUCK,DONALD..           [4,1] AETNA
                                   [4,2] BC
                                   [4,3] HEALTHNET
                Subscripts
    Rule
In order to access a field within a segment, the
subscript(s) of that segment must be defined

There are four ways to define a subscript:
   Choose a detail segment
   Use a DPM pointer and possessive
   Multiples
   Subscripting
                 POINTERS
• Subscripts can be passed from one DPM to
  another as long as it is the same value.
• The DPM column within the data definition
  page will identify data fields that have a DPM
  pointer.
• Data fields that have a DPM pointer exist
  throughout every NPR application
• Generally the pointers are mnemonics that
  point to dictionaries.
• This allows the MEDITECH system to only
  store the dictionary information once but the
  data to be shared with other DPMs.
                    Sample Pointer
• The MIS.ACCOM.DICT is a pointer.
• The accommodation field within ADM.PAT is also the subscript that
is used in the MIS Accommodation dictionary.
• The accommodation field (above) and the mnemonic field (below)
are the same Data field within MEDITECH.
               READING DATA
• Each segment has data elements that store the
  responses users enter when processing routines
  within the DPM module.

• These Reponses are called fields. These fields
  are the actual data files that are stored within
  Meditech.

• Each data field has associated attributes that
  control the type, length as well as where the
  data is stored within the segment
              Common Terms
                         Demographic Information

Field    Name           Address               City     State
         Adams,John     1 First Street        Dallas   TX
         Brown,Sally    2 Second Street       Dallas   TX
Record   Carter,John    3 Third Street        Dallas   TX
         Fuller,Simon   4 Fourth Street       Dallas   TX
         Pitt,Brad      5 Fifth Street        Dallas   TX
         Smith,Donna    6 Sixth Street        Dallas   TX
 File
           FIELD ATTRIBUTES
• The attributes that are given to a field define
  how the field is displayed and stored.

• Standard Meditech fields always have the
  attributes of LEN, TYP, and JFY.

• Users can change these within the NPR Report
  Writer.

• Users can also control many more aspects of
  the field such as FONT, SIZE and other
  functions of the report writer system
Samples of Fields and Attributes
                    Names
• The field name listed on a data definition is
  how the system identifies that specific internal
  location. Users can access the data within
  these fields by using the defined name
• Field names are always listed in a lower case
  format
• The only punctuation that is allowed is a
  period (“.”)
• Example of a field name is “accident.24.hours”
• The full field name would be:

  ADM.PAT.accident.24.hours
                    Length
• The length attribute is the maximum number
  of characters that a field can hold as the data
  is entered into the MEDITECH system via a
  routine.
• Users can increase or decrease the length of a
  field
• If the length is changed to be shorter than the
  standard field length then the output of the
  field will be truncated and some of the data
  will not be displayed
• Example: If the Standard field length is 6 and
  a user inputs 123456. 123456 will be stored
  internally. If you change the Length attribute
  to 3 the system will output 123.
               Data Type
• The data type is the input/output
  format of the data contained within the
  field.
• The format or output of the field may
  be different than how the data is
  actually stored internally
• If a field has a DATE data type then the
  system will convert the data from an
  internal date format (YYYYMMDD) to a
  external format (MM/DD/YYYY).
                    Justify
• This controls the justification of the field

• The JFY attribute will position the data to
  either be Centered, Left or Right Justified

• JFY = C, L or R

• Generally, Numeric data is right justified
  while non-numeric data is left justified.
                  DPMs
• The DPM column is referring to if a field
  is a pointer to another DPM
• If there is a value under this column
  then the associated field is a subscript
  to another DPM.
• These usually point to dictionaries so
  that data can be referenced several
  times but stored in only one location
• An Example is MIS.ACCCOM.DICT
         Identifying Computed Fields
• Standard Computed fields are fields that are a
  combination of data fields along with a
  computation, program call or operation
• An example of this is
  VAL=IF{@admit.date;@reservation.date}
• The value of this field is an IF statement
• The system will first check to see IF the admit date
  exist else (“;”) it will use the reservation date
• Other types of computed fields can be programs,
  such as %Z (standard programs), calculated
  values and values with predefined subscripts.
Examples of Computed fields
                  Samples of Fields and Attributes




• Note that there are two computed fields above. The first is admit.time.out. This field is using an IF statement
to check to see IF one of the two fields exist. The import aspect of the IF statement is that it reads left to right.
So IF there is an admit.time then that is what is the value of that field will be. IF admit.time does NOT (; = else)
exist then the system will look for the other field in MRI
• The other computed field is using a Z.program to run a calculation. Generally these types of computed fields
are used to alter the format of the data. In the example above it is a date format change.
                      %Z.date.add
• There is a good listing of the most common Z.programs on the
  Meditech web page under the Report Writer module
• An example of how a Z program will work is the Z.date.add
  (used in field anticipated discharge date field)
• Z.date.add has two variables that are passed to the program.
  The first is referred to as “A” the second as “B”. The format of
  program is %program.name(A,B)
• For the Z.date.add A is equal to a date that is in an internal
  format (YYYYMMDD) and B is equal to the number of days to
  add to A.
• %Z.date.add simply takes an internal date and adds a number
  of days to that to create a new date value.
• If admit.date is equal to 20060607. this would be the A
  variable.
• expected.length.of.stay is 14. This is the B variable.
• The Z.date.add will take the B and add it to A to produce the
  result of 20060621.
• It is also important to note that since this field has a Data type
  of DATE so then the output will be altered to actually be
  06/21/06.
      Understanding the Physical
• The physical structure is shown under
  the Internal Name header
• The first field listed will always be the
  subscript
• Each data field has a specific prefix
  associated to it.
• “*”,”:”,”?”,”\” Are all used for data fields
• & is always used for dictionaries
• % is a program call
              Offset/Local/Val
• This column shows the internal physical
  address of the data field within the MEDITECH
  database.
• The offset is the physical base plus a “|” and a
  number which shows the exact location of the
  field
• “|” is referred to as a pipe.
• The |0 is the exact location where this field is
  located
• Note that all Meditech structures start at Zero
• All of these elements tell the system exactly
  where to find a specific field within the
  Meditech database. It is important to realize
  that this is the actual address that the system
  uses.
• Each part of the internal structure is referred
  to as a “piece”. (|0 = piece Zero)
                Physical Structures
• An example of this is *AA[aa]DR|0
• “*” is the prefix
• AA is the location for the segment
• [aa] is the subscript for this segment.
  This would represent a value that is either a URN
  or a Mnemonic.
• The base is the Prefix plus the physical structure
  (location).
    – *AA[aa]
• The DR is the descriptor for that field within the
  segment. Descriptors are used to isolated
  specific data types together within a segment.
• In this example it is all doctor information (DR)
  for a patient visit.
                  Physical Base
Type        Name                 Physical Base
Table       adm.patient.file     Magic: *AA[aa]
                                 CS: $(A)AA[aa]
Subscript   urn                  Local variable = aa
Field       acct.number          Magic: *AA[aa]|0
                                 CS: $(A)AA[aa]|0
Field       name                 Magic: *AA[aa]|1
                                 CS: $(A)AA[aa]|1
Table       adm.pat.insurances   Magic:
                                 *AA[aa]I[ggm]
                                 CS:
                                 $(A)AA[aa]I[ggm]
Example of the Physical Structure
Sample of Internal Data
              Data Structures
RULE:
In order to access a field within a segment, the
subscript(s) of that segment must be defined


 1      Which application?

 2      Which DPM (Data Procedure Module)?

 3      Which detail segment?
                    Data Structures
Application                            BAR


DPM           BAR.BCH                BAR.PAT             BAR.PROC


Segment                 bar.acct          bar.acct.insurances
   Main - 1:1
   Child - 1:Many
                        [account]        [account,insurances]


                         account                insurance
                         acct.type             assign.ben
                          addr1              ins.deductible
                          addr2                ins.dem.id
Rules of the Parent-Child Relationship

• Parent segments can have one or more
  than one associated child segments
• Child segments can also be parent
  segments to other segments (grand
  child)
• Child segments contain data that is
  associated to the parent segment
• The subscript of a parent segment
  MUST always exist in the child segment
Glossary of Terms for Data Structures
• DPM = Data Procedure Module
• Parent = Top Segment or Segment that has
   other segments below it
• Child = A Segment that is related to another segment
  and has a subscript
• Segment = A Data file that stores records within a DPM
• Field = Responses users enter when processing
   routines. The actual data within the Meditech database.
• Attributes = Characteristics that control the type, length
  as well as where the data is stored within the segment
• Application = The highest level of data storage within
  MEDITECH.
• Subscript = An internal sequential counter to assign a
  value to each unique record within the MEDITECH
  database. Can either be a Number or a Mnemonic.
           Hierarchy of ADM
                                  ADM


           ADM.PAT                           MAIN.MENU

ADM.PAT.                        ADM.PAT.
segments                        programs

               ADM.PAT.
            adm.pat.doctor.list

               ADM.PAT.
             adm.patient.file

                                    ADM.PAT.
                                  adm.pat.events

                                                        ADM.PAT.
                                                   adm.pat.other.locations
Thanks for joining us today!



     Interface People, LP
     214.222.1125
     www.ipeople.com
     info@ipeople.com

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:23
posted:3/9/2011
language:English
pages:50