Conference call minutes 2 April 2015

Health Concern Topic

Patient Care WG

April 2, 2015

Attendees:

• Michael Tan – Chair
• Jay Lyle
• Dave Pyke
• Ken Chen
• Laura Heermann Langford

Participation Information Phone Number: +1 770-657-9270 Participant Passcode: 943377

Web Meeting Info www.webex.com Meeting number 230 634 425

Previous Meeting

Minutes from March 26 th, 2015 Move: Jay/Ken No – 0, Abstain – 0 Approve – 3

Review of new diagram

We continued with the new model and the questions that Jay had prepared for the call.

1. Is an order associated with a problem part of a concern or part of a plan?
   1. We could leave it very loose and permit it, or we could specify that the link is via the plan.Both are possible.
   2. Build an instance diagram to clarify the issue, and possibly demonstrate that there is no problem. Which is looking likely.
   3. There were concerns that this would might lead to the risk of duplication of orders, but that is more of a governance issue rather than an information architecture issue. We should notify Care Plan domain of risk of duplicate orders due to attaching orders to Concern object.
2. Is there a rule or assumption that related events (e.g., results, administrations) be associated with the source event's concern?
   1. Possibly; it could be left to policy.
   2. Events are already attached through the diagnosis.Do you buy anything by creating the explicit concern tag?
   3. There is a need for editorial control over potentially large volume of data
   4. Leave this as an option for manual or automatic attachment.
3. Is there a 'context' that automatically associates an event with a particular “in context” concern? Are there boundaries we need to identify--i.e., does the clinician need to be aware of context and consciously indicate when it changes?
   1. Good to reduce need to explicitly associate things. Clinicians are not inclined to extra administration.
   2. Closing contexts may not happen.
   3. We need more clinician input on UX.
   4. Or leave context management to implementers. Out of scope for DAM.
4. When merging, is the name the more recent, or does the merger get to choose?
   1. Both are kept. Option to adopt or not
   2. But: you may also want a “locally familiar” name that does not diverge semantically but is easier to read.
   3. The new custodian is likely to be from another discipline with other needs of recognizing the concern is his specialty domain. Added “localName” to model to support this.
5. Is ‘follow-up’ a concern? It looks like it might be a classifier for an encounter associated with the discharge dx concern.
   1. It may be an event under a concern.
6. Would a provider add a separate concern to the list to support past medical history, or is there a different mechanism for history? Might there be a different status--e.g., active, resolved but historically relevant, and inactive?
   1. Not likely. Most likely would be to change the state of a concern: Active or inactive.
   2. Or are there rules for what shows up in History -- timeframe, seriousness. These “history inclusion” rules are specific to the institution.
   3. Modern search engines in the big data era are capable of retrieving complex key words.

The document of the model can be found here: File:ConcernModel.doc

Go back to health concern minutes: [[1]]