Talk:Information Model Design Patterns

It seems that we are going to come up a very large number of design patterns, esp. when we get to patterns of disease and therapy. This makes creation of some meta-design management potentially useful.

Types/Patterns of Design Patterns

Many of these which I can think follow into a handful of patterns:

• ActGraph: Act -- (0..*)ActRelationship --> (1..*)ActGraph
• Introduction to HL7 v3: Person -- Patient -- recordTarget --> ActGraph --> responsibleParty -- Provider (e.g. Patient Bob diagnosed with the flu by his physician)
• Provider:

 Person Instance <-- Licensed Entity -- Licensing Organization
   <-- Employee -- Organization
   -- Responsible Entity -->  responsibleParty

• • This doesn't quite get all the nitty-gritty. There is usually a clinic involved, which typically is associated with the location (Place) but which is really an Organization (which scopes the Patient and Employee roles), and there is a relationship between the provider-person and the patient-person, i.e. a patient of a clinic and a patient of a specific provider @ the clinic. It gets even more complex w/ ACO/MCOs, since you can be a patient of an ACO/MCO, which scopes the clinic and the provider--so three scoping relationships of patient, and provider.

Patterns based on type of information

Temporal

This is a big "feature" with ActGraphs. Esp. with all the ActRelationship _temporallyPertains variety

Act Organizer design patterns (data structures/collection)

Easy to make lists, trees, networks/graphs, sets, bags, maps, etc. from Act-ActRelationships

Executable Act logic design patterns

With some branching logic and conjunction codes (AND, OR, XOR), plus Act.isCriterionInd=true, you can pretty much write your own software using RIM semantics.

Core EHR structure design patterns

• Patient Encounter Event documentation
  • See CDA r2 H&P IG

Most narrative medical history is structured. It just isn't discrete, typed and coded/numerical/Boolean. It is logical to define design patterns which are hammered into our heads in medical school.

Health record/Patient encounter document section design patterns

Good example where it will be hard to differentiate between what gets called a design pattern and what is just another model.

Example: Chief complaint/presenting problem/reason for visit

• Chief complaint (CC) = what patient says in narrative text
  • Not coded, but can be structured
• Presenting problem (PP) = translation of CC into one or more clinical concepts
  • Can be represented as structured, coded data
• Reason for visit (R4V) = health care service/process which is focus of patient encounter
• Rules:
  • Must have at least CC | PP | R4V
  • May have >1 CC | PP | R4V
  • Usually should have PP and/or R4V for each CC

Now, the PP is usually a symptom, so it may have some interesting patterns:

Example: Symptom

• Symptoms have usual attributes which are an archetype/template/design pattern/model
  • Temporal
    • Change in location over time
    • Time series A then B then C while D but before E which ended before end of F...
    • Change in response to stimulus (trigger, exacerbating factor, treatment) which are always temporally associated (at least under current known laws of physics)
    • All the various qualifiers (below) have temporal nature as well, i.e. wrap them up in their own little IVL<TS> and ActGraph (where the ActRelationships are all temporal)
  • Various qualifiers
    • Severity
    • Descriptive quality
  • Associated symptoms

--Kcoonan 08:11, 25 November 2011 (UTC)