Date

13 August 2009

In Attendance

• Ben Wolfe
• Darius Jazayeri
• Burke Mamlin
• Paul Biondich
• Nareesa Mohammed
• Win Ribeka
• Brian McKown
• Zeshan Rajput
• Justin Miranda
• Rita Cuckovich
• Mike Seaton
• Hamish Fraser

Agenda

• Feature to add/edit Relationships via FormEntry module using HL7 NK1 segments. -Brian
• We need more larger Projects -Ben
• Retiring or deactivating of users? See #1725.

Minutes

• 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'
  • We need to have several big projects on the Projects page
  • We need a place for just putting project ideas or suggestions. Perhaps the Talk__Projects page is best. This will just be for one
• 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