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: unnamed link)

  • TODO: Mike will make a ticket for creating a module to control user's creating their own accounts