Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

  • Relationships via FormEntry
    • Does the xslt make multiple hl7 messages from the formentry xml? -Darius
      • It does not have to, nk1 segments are part of the R01 message (like a PID and PV1)
    • Background: We need to create/update relationships through infopath forms
      • Formentry module needs a place for the relationships
      • The r01 parser in core needs to recognize this and create relationships
    • Hl7 has "suggested" codes (not required) for nk1 segments
      • We are proposing adding two 3 digit columns to relationship_type: aIsToBNk1 and bIsToANk1
      • Sec 3.4.5 of hl7 manual, the length of seq 3 (relationship) the length is 250 -Darius
      • Darius suggests using a fully specified name
      • Ben says that only works within openmrs, not for sending or receiving outside hl7
      • The nk1 is a triplet ID^NAME^CODE
      • Paul proposes we use relationship_type_id instead of the aIsToBNK1, etc
      • The proposal for the triplet is relationship_type_id^name^99REL
        • But there are two sides to a relationship, so relationship_type_id
      • Brian is concerned about two openmrs instances trying to send messages...the relationship_type_ids are different. If we used hl7 codes, then they could line them up beforehand
      • Darius points out that we need a ConceptMap/ConceptSource for all objects
      • Burke asks if this is an imagined or real need
      • Darius would need it for datatypes, etc
    • The nk1 code needs to be relationship_type_ida^name^99REL or relationship_type_idb^name^99REL e.g. 1a^Child^99REL or 1b^Parent^99REL
    • The text portion can be either just one side of the relationship, both relationships, or some other random text. That decision is left up to the author
    • The two columns are not needed with this solution
    • How to put the person in there? person_id? identifier?
      • nk133 has "identifier" and is a cx. It can have internal id, then patient identifiers if exists
      • Remote formentry will need to be modified as well
    • Paul: Should nk1's be creating new people? Should we have another hl7 message?
      • Yes, nk1s have all the info needed for creating a person is in there
    • The relationship lookup widget should create the person stub in the database. This allows the uuid and person_id to be created. When a second child comes along (with the same
  • TODO: Ben: The remoteformentry preparsing should preserve the uuid of the patient that was created remotely
  • We have several inquiries for projects based on openmrs for thesis'
  • Should users be retirable instead of voidable?
    • Retired means "this was valid up until a certain time". Voided means "this was never valid". According to this, the Users should be 'retired'
  • Should users have an "active" flag to allow logging in?
    • Should this just be a module?
    • Paul: Someone should be able to be inactive but not retired.
    • Darius: If retired is not meant to be used for "this user is suspended for a while", then 'retired' is not needed.
    • Burke: active vs inactive is more about a lockout from being able to be logged in
    • Darius doesn't like having both retired and a status/active flag
    • TODO: Burke will create a ticket for changing users.voided to users.retired (Done: archive:TRAC-1725@ticket)
    • TODO: Mike will make a ticket for creating a module to control user's creating their own accounts