Family History API

[nschwertner]

• Family history data model will return quantifiable data about relatives (when known). Could be based on CDA statement patterns. Will serve the parental height use case amongst the others.
  • Statements based on biological relatives
  • Three potential approaches:
    1. References to other patient records (acceptable, we should support, but not require)
    2. Inline patient record for each relative (too complicated for simple statements, we probably don’t want to do this)
    3. Ability to state simple facts about the patient’s relatives (need to find out the common facts that clinicians collect about patient relatives - allergies, history of hereditary diseases, biometrics (height), others?)
  • First step: ER model (translatable into tripples/RDF), coding systems
  • Second step: Translating into OWL/RDF/SampleData/Documentation (turning it into SMART Model)
• Advance directives model will return coded data specifying the patient’s terminal treatment elections -> not 0.6 priority; could be based on LOINC codes
• Microbiology Labs (see below)

[nschwertner]

Zack: JetCom have already implemented family relations. We should look into it.

[jmandel]

GEDCOM

[jmandel]

Examples of the kinds of things we want to say, in English:

vitals (height, weight, BMI)

"patient's father was 178cm tall."

problem list

"patient's father had Type 2 Diabetes."

some demographics

"patient's father died in 1940." "patient's father died in 1890."

How relations / family members are identified

• is SNOMED relation hierarchy enough? ( http://schemes.caregraf.info/snomed#!125677006)

(note: need ~sp:dateOfDeath in SMART demographics.)

[dhml]

In addition to family relations, SNOMED also has family history of clinical findings: http://schemes.caregraf.info/snomed#!281666001. Diabetes for instance: http://schemes.caregraf.info/snomed#!160303001 .

[jmandel]

Indeed! This comes down to a classic question of pre- vs. post-coordiantion.

If the SMART data model is specifically a data model for family history, then we can use post-coordinated expressions to break the disease from the context. E.g. We could say:

[ a sp:FamilyHistoryStatement;
  sp:belongsTo <http://my-smart-container/records/123>;
  sp:aboutRelative <http://snomed.info/grandfather> # (fake code for
grandfather)
  sp:problem [
    a sp:Problem;
    sp:problemName [
      sp:code <http://snomed.info/diabetes> # (fake code for diabetes)
    ]
  ]
]

---

On the other hand if we wanted more generic statements, we could embed the context into the code:

[ a sp:SomeGenericStatement;
  sp:belongsTo <http://my-smart-container/records/123>;
  sp:aboutRelative <http://snomed.info/grandfather> # (fake code for
grandfather)
  sp:snomedCode  <http://schemes.caregraf.info/snomed#!160303001>.
]

---

My sense is that the pre-coordinated approach requires app developers to understand a bit more of SNOMED CT to get started. So my preference is for the post-coordinated approach... but I'm swayable here. (The only thing I want to avoid is accidentally saying things like "my father has a family history of diabetes" unless it's really what I mean.)

[nschwertner]

Day of death is now part of the model: https://github.com/chb/smart_common/commit/fb1408ba6205fc5495093e36789e079523549189