CDAKHealthKitBridge

Singleton for all shared properties and methods.

Placeholder for non-localized HealthKit quantity identifier descriptions.

Example: [HKQuantityTypeIdentifierBasalBodyTemperature, Basal Body Temperature]

This is initially loaded from the local CDAKitDefaultSampleTypeIdentifierSettings resource file in CDAKit.

The plist uses the displayName key and associated string value

 <key>HKQuantityTypeIdentifierBasalBodyTemperature</key>
 <dict>
 <key>displayName</key>
 <string>Basal Body Temperature</string>

Default preferred units for a given set of quantity types.

Example: [HKQuantityTypeIdentifierBasalBodyTemperature, degF]

This is initially loaded from the local CDAKitDefaultSampleTypeIdentifierSettings resource file in CDAKit.

The plist uses the unit key and associated string value

<key>HKQuantityTypeIdentifierBasalBodyTemperature</key>
<dict>
<key>unit</key>
<string>degF</string>

You can, instead, use the individual user’s preferred unit settings from their Health App settings. If you wish to do so, use the setCDAKUnitTypesWithUserSettings method

preferredUnitsForQuantityTypes

Default classification for a specified quantity type identifier.

Two primary groups as of version 1.0:

• vital
• result

These attempt to tie the HealthKit concepts to a given CDA section for convenience (vitals or lab results).

Example: [HKQuantityTypeIdentifierBasalBodyTemperature, vital]

This is initially loaded from the local CDAKitDefaultSampleTypeIdentifierSettings resource file in CDAKit.

The plist uses the type key and associated string value

<key>HKQuantityTypeIdentifierBasalBodyTemperature</key>
<dict>
<key>type</key>
<string>vital</string>

Convenience enumeration of all HealthKit quantity identifiers

For a given HealthKit biologicalSex, returns a tuple of the CDA code and displayName.

Reference: https://www.hl7.org/fhir/v3/AdministrativeGender/index.html

Example CDA element:

<administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1" codeSystemName="AdministrativeGenderCode" displayName="Male"/>

For a given CDA HL7 gender code, returns an HKBiologicalSex.

Reference: https://www.hl7.org/fhir/v3/AdministrativeGender/index.html

Example CDA element:

<administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1" codeSystemName="AdministrativeGenderCode" displayName="Male"/>

Attempts to converts a CDA entry to a HealthKit quantity sample.

This method relies completely on both the concept and unit mapping functions.

Concepts are matched/found based on coded entries bound to HealthKit sample identifier types. These can be found in the CDAKitDefaultHealthKitTermMap plist file. You can inject your own input/output concept mappings through the loadHealthKitTermMap method.

Units are matched based on a function that reviews units against known formats. If you wish to change it (you probably will), you can do so by supplying your own closure. Just update cdaStringUnitFinder and all unit matching logic will be changed at runtime.

Closure that allows you to specify how unit strings from CDA templates are transformed into HealthKit units (if possible)

Refer to unitForCDAString for information on arguments

var cdaStringUnitFinder : ((unit_string: String?, typeIdentifier: String? ) -> HKUnit?) = {
(unit_string: String?, typeIdentifier: String?) -> HKUnit? in

 //example
 if unit_string == "beats" || aTypeIdentifier == HKQuantityTypeIdentifierBodyMassIndex {
   return HKUnit(fromString: "count/min")
 }

return nil
}

There are a fixed number of HKUnit code strings we can use to initialize an HKUnit. EX: cm dL etc. CDA does not, however, entirely fix that list like HKUnit. We’ve seen inches units which should be represented by in be formatted with unit strings like inch or inches.

Additionally, the UCUM units CDA uses may be somewhat broader than HKUnit SI units. EX: inch may be represented as in_us

There may also be formatting conventions in CDA that make it difficult to utilize the identifier strings with HealthKit. EX: [in_us] or hh[Mg]

We need to attend to all of these scenarios to see if we can clean up the CDA unit codes so they’re viable for HKUnit’s fromString initializer.

If you want to export HealthKit objects, you may want to let the user’s personal unit settings drive the HKUnit selection (where possible). For example, we may import a body temperature in Fahrenheit, but a user may prefer to see that information rendered in Celsius. If their personal unit settings for a quantity type are set, this will overwrite the global defaults with the user’s preferred setting.

This feature uses HKHealthStore. It is assumed all authorizations will be managed by your application.

NOTE: This functionality modifies the HealthKit samples - NOT the native CDA data stored in the CDAKRecord. You must set the unit preferences BEFORE you export a HKRecord (exportAsCDAKRecord). Once exported to a CDAKRecord, any changes to the bridge’s unit types will not be reflected. CDA unit types are fixed strings.

NOTE: HealthKit does this on a background thread, so be careful how you handle things on the UI

preferredUnitsForQuantityTypes

Allows you to specify the type of unit that should be preferred for a particular HealthKit quantity type identifier

Supplies a list of all supported HealthKit quantity types

Supplies a list of all supported HealthKit sample type identiifers

Allows you to tell the sample generator how it should classify a specificy type of sample and what it should use for default units (works in tandem with the unit match closure).

• The primary key is HealthKit sample type identifier you wish to bind. (EX: HKQuantityTypeIdentifierActiveEnergyBurned)
• unit is the default unit (EX: cal)
• displayName is the display name you wish to use for the sample (EX: Active Energy Burned)
• type defines how you want to classify the sample. These attempt to tie the HealthKit concepts to a given CDA section for convenience (vitals or lab results).

Two primary type groups as of version 1.0:

• vital
• result

<key>HKQuantityTypeIdentifierActiveEnergyBurned</key>
<dict>
  <key>unit</key>
  <string>cal</string>
  <key>displayName</key>
  <string>Active Energy Burned</string>
  <key>type</key>
  <string>vital</string>
</dict>

Allows you to inject your own HealthKit sample type mappings to CDA vocabulary entries. These mappings are the core of what drives the linkage between the two.

The mappings must specify a direction:

• import : used exclusively when importing values from CDA to HealthKit
• export : used exclusively when exporting values from HealthKit to CDA

• both : used for import and export

• The primary key is HealthKit sample type identifier you wish to bind.

• Within this, there is a child array bound to the key/tag CDAKit uses to map to a vocabulary. EX: LOINC or SNOMED-CT. This declares that all following coded entries within the array will be of that specified vocabulary.

• Details for code, displayName, and mapping restriction. code is the vocabulary concept code (EX: 39156-5) for the associated displayName (EX: Body mass index (BMI) [Ratio]).

<key>HKQuantityTypeIdentifierBodyMassIndex</key>
<dict>
<key>LOINC</key>
<array>
<dict>
<key>code</key>
<string>39156-5</string>
<key>displayName</key>
<string>Body mass index (BMI) [Ratio]</string>
<key>mapRestriction</key>
<string>both</string>
</dict>
</array>
... (more vocabularies)
</dict>