Common Platform Comparative Analysis Appendix

8/8/2019 Common Platform Comparative Analysis Appendix

1/98

Appendix - Comparison Charts

Meeting the Requirements of

Project HealthDesign:

Comparative Analysis with Respect to

Existing and Emerging Clinical Data Standards and Commercial PHR Data Repositories

Document Notes:

Comparative information presented in this document accurately reflects the data available on May 30, 2008.

The term "CCR-s" in this document refers to the Google subset of the CCR data model

August, 2008

Prepared by

Sujansky & Associates, LLCFor

Project HealthDesign

Legend

Y Supported

Modifications to standards and repositories subsequent to that date are not reflected in this document


2/98

P Partially Supported

N Not Supported


3/98

Observation Component - Comparison with Health Vault and Google

Project HealthDesign July 2008

Req ID Requirement CP HV Health Vault Support Description

Requirements for Observation Common Platform Component: Data Sources

OBS- 1 Y Y

OBS- 2 Y P

OBS- 3 Y P

OBS- 4 Y Y

[E.g., a glucometer, pedometer, or accelerometer]

OBS- 5 Y Y Files, images, etc. are supported via the File Item Type

The component shall have the ability to store observations thathave been manually entered by a patient or caregiver as

structured data elements (presumably via a structured data-entry form provided by a PHA).

HV supports this functionality. Microsoft does not provide auser interface to allow users to manually enter their data.However, PHAs connected to HV can allow users to manuallyenter structured data.

[E.g., a structured blood glucose reading with coded units, thecoded representation of a symptom or physical sign, the coded

representation of a physical exercise activity, etc.]

The component shall have the ability to store observations thathave been manually entered by a patient or caregiver via aPHA as responses to apre-defined questionnaire or surveyinstrument.

The HV data model does not natively support the submissionof questionnaire data. However, the data model may becustomized to support the storage of questionnaire data. Thisdata would not be interoperable with other healthvaultconnected systems.

[E.g., responses to a depression-scale questionnaire, selectionof other in response to a multiple-choice survey questions,free-text responses in questionnaires, etc.]

The component shall have the ability to store observations thathave been manually entered by a patient or caregiver asunstructured text notes, blogs, or journal entries

There is no structure in the HV data model that is intended tosupport blogs. HV has a Sleep Journal, but not a generic

journal. Medical Annotations may be stored in HV.

The component shall have the ability to store observations thathave been electronically uploaded from a measurement devicevia a PHA-mediated interface.

HV has been implemented to collect data from personalmedical devices.

The component shall have the ability to store observations thathave been electronically uploaded asphotographs or otherimage files


4/98




Types of Observation Records

The component shall have the ability to store and distinguish among the following types of observation events:

OBS- 6 Y P

OBS- 7 Y P

OBS- 8 Y P

OBS- 9 Y Y Encounter and/or Appointment

OBS- 10 Y P

[E.g., the photograph of a meal, an emoticon depicting apatients mood, a scanned drawing depicting a patients mood]

Medication administration Daily Medication Usage. Enables a user to keep a record ofthe actual doses taken for prescription medications, over-the-

counter drugs and regular dietary supplements. It does nottrack individual

[i.e., the occurrence of a medication being taken or

administered, including the time at which it took place andthe details of the dosing]

Physical Activity Aerobic Exercise Session and/or Aerobic ProfileAlso consider Weekly Aerobic Exercise GoalThese types are very specific, and do not accommodate other

physical-activity data in a general way (e.g., non-aerobicexercise)

[i.e., the structured description of a physical activity asentered by a user, including the type of activity, duration,intensity, etc.]

Meal/Snack Daily Dietary IntakeThis object does not represent a single instance of a meal, butrather the dietary intake for a whole day.

[i.e., the time and characteristics of an ingested meal orsnack, including the composition of the meal and/or a

photograph of the food items]

Healthcare Encounter

[i.e., an encounter with the healthcare system, such as aphysician office visit, hospitalization, phone consultation,etc.]

Sign or Symptom Condition (?) or Medical Problem (?)


5/98




OBS- 11 Y N

OBS- 12 Y P

OBS-12.1 Y N

OBS- 13 Y N HV does not support a generic style of observation recording.

There does not seem to be a good 1:1 representation of asign/symptom observation. The condition data type could beused for this purpose. Might have to use Application-Specificwrapper w/ custom xml schema.

[The presence or absence of a discrete sign or symptom,such as fever, fatigue, nausea, swelling, etc.; onlythe presence or absence of the sign or symptom can bedescribed using this type of observation no qualifiers aresupported]

Pain There is no appropriate HealthVault equivalent. Proposeusing Application-Specific wrapper w/ custom xml schema.[A sub-type of the Sign or Symptom type that allows a

relevant set of pain qualifiers to be recorded, includinglocation, severity, quality, radiation, etc.]

Observable Parameter Blood Glucose Measurement, Blood Pressure Measurement,Height Measurement, Spirometer Measurement, WeightMeasurement, Vital Signs, Lab Test Result-These are the specific HV specific measurement types that fallinto the "Observable Parameter Class". However, there is nogeneral class that could store other observable parameters,such as "knee range of motion" or "hours of sleep", withoutdefining a custom ItemType

[an attribute/value observation consisting of someobservable parameter (such as systolic blood pressure) andthe value of that parameter (such as 120 mmHg);

Note: The Observable Value type may be used to represent,among other things, the individual measurements captured

by activity monitors.]

Journal Entry No equivalent HealthVault data structure. Consider usingMedical Annotation or Application-Specific wrapper withhtml mark-up. HV supports a Sleep Journal but no general

journal entry.

[An unstructured text entry that captures a users generalsubjective observations; may be a diary entry, a blog entry,etc.]

General Observation


6/98




OBS- 14 Y Y

Common Attributes of Observations

For each observation record, the CP:OBS component shall be able to store the following data elements:

OBS- 15 Y Y

OBS- 16 Y Y

OBS- 17 Y Y TypeId = A GUID that uniquely identifies the type of data.

OBS- 18 Y N

[A catch-all observation type that allows other types ofobservations to be represented per the structure and codingspecifications of individual PHAs]

The set of observation types supported by the Observationcomponent shall be extensible, so that new or unanticipatedtypes of events may be recorded and processed by thecomponent when required by PHAs.

Can use Application-Specific extensions to accommodate thisrequirement.

Observation Unique ID (text) Key.Id = the GUID for each HV item. Any updates to arecord item updates the Key.VersionStamp[Note: The component shall assign a Observation Unique

ID to each distinct observation record. A PHA can later usethis identifier to reference a specific observation.]

Patient Record ID (text) PersonId, a System.Guid type in the PersonInfo class/elementis used to store the unique identifier of the personal health

record[Note: this attribute stores the unique identifier of the

patient record to which this observation applies.]

Observation Type (coded)

[i.e., one of the observations types defined by the commonplatform data model, such as medication administration,meal/snack, pain, etc.]

Observation Sub-Type (format TBD) Existing Health Vault data types may be extended to include


7/98




OBS- 19 Y Y The "Effective Date" is used to store the timestamp of the item

[E.g., 2007-11-09 21:14:33 GMT -0800]

OBS- 20 Y Y Handled by the "When" element of HV data objects

[E.g., 2007-11-07 15:00:00 GMT -0800]

OBS- 21 Y N

elements not part of the core data types. In addition HVallows client applications to define custom application-specific datatypes that are not shared with other HV clients.Finally, the core HV data type, HealthRecordItem provides afield for extra data to be stored. This field could be used tohold custom data not expected by the CP.

[Note: PHAs may arbitrarily assign sub-types toobservation records to assist in the processing ofobservations. For example, a PHA may store additionalstructured data for an observation (i.e., data not defined bythe common platform data model see the AdditionalStructured Data attribute below), and the Sub-Typedesignator allows PHAs to retrieve and process observationsspecific to the sub-types that they have defined. The Sub-

Type value must consist of a Sub-Type designator and theunique identifier of the PHA that created the observationrecord (to ensure uniqueness for the Sub-Type designatorsacross PHAs)]

Observation Entry Datetime (formatted Date/Time)

(Note: This attribute represents the date/time at which theobservation was recorded in the CP:OBS database)

Observation Effective Start Datetime (formattedDate/Time)

(Note: represents the beginning of the time interval atwhich the recorded action, symptom, medical appointment,etc. actually took place)

Observation Effective End Datetime (formattedDate/Time)

No equivalent base property on data types. It could be addedas an extension to those datatypes for which an end date/timeis appropriate.

(Note: represents the end of the time interval at which therecorded action, symptom, medical appointment, etc.actually took place. For observations occurring at a single

point in time, this value may be equal to ObservationEffective Start Datetime)


8/98




OBS- 22 Y Y

OBS- 23 Y Y

OBS- 24 Y Y Handled through "RelatedItems" field

Text Comment/Description (text) Text-only descriptions may be associated with a HV dataobject[Note: stores an arbitrary text comment typically made by

the recorder of the observation. For example, a brief noteexplaining why a medication was taken outside of itsregularly scheduled dose, or why the patient visited theemergency room. This comment field is distinct from anannotation (see below), which is not an attribute of theobservation, per se, but may be added to an observation by

any authorized user. The separate treatment of annotationsis required for access control purposes]

Annotations (text) Annotations are a separate data type within HV rather than aproperty on an object, but annotation items may be linked toobservations items via the "RelatedItem" field

[E.g., This value is a little high. Please contact me if thisdoesnt go back below 150. Dr. Grayson]

(Note: These annotations may be entered by other users, aspermitted by the relevant access controls. Each annotationshall include a timestamp and the identity of the user whoinserted it.)

Reference/Link to associated calendar event (formatTBD)

[Note: This attribute applies when an observation recordsan action that fulfilled or helped to fulfill a calendar event,such as a scheduled medication administration or exercisesession; the attribute is populated at the discretion of thePHA (i.e., it is not maintained by the CP:OBS component).]


9/98




Y Y Handled through "RelatedItems" field

OBS- 25 Y N Custom field required

OBS-25.1 Y Y OtherData field used for this purpose

Reference/Link to associated Observation record (formatTBD)

[Note: this may be useful, for example, to relate the systolicand diastolic blood pressure readings of a single BPmeasurement.]

Additional Structured Data (XML text)

[Note: This attribute can store additional information aboutan observation that a PHA wishes to store in a structuredform, but is not accommodated by any of the existingstructured attributes for the relevant observation type. Forexample, a PHA for breast cancer patients may wish to addstructured information regarding the type of chemotherapyor radiation therapy administered during a medicalappointment. Also, this field allows PHAs to store and

process structured data for observation types that are not yetdefined by the common platform data model. To do this,PHAs may specify a Observation Type of GeneralObservation and create their own structured data model forrepresenting the observation data.]

Multi-media attachments (format type + content)


10/98




OBS-25.2 Y Y Source field used from this purpose

(Values = MedicalSource

PersonalSource)

Attributes of Medication Administration Observations

For each observation of type Medication Administration, the CPC shall be able to store the following data elements in addition to the general data at

P

OBS- 26 Y Y drug-name/text

OBS- 27 Y Y drug-name/code/value

[Note: This attribute may store one or more multi-mediaattachments of allowable format types (e.g., JPG, MPEG,etc. The set of types is TBD). A single observation mayhave multiple types of attachments (e.g., both a photo andan audio annotation).

Provenance (code)

[Note: This coded flag denotes whether the observationoriginated from an authorized and trusted medical source(such as directly from an EHR or laboratory) or whether itoriginated from a patient or other lay caregiver orcustodian.]

Medication Text (text)

[Note: describes the medication administered, includingroute and dosage strength, if available]

Medication ID (code)


11/98




OBS- 28 Y Y drug-name/code/type

OBS- 29 Y Y Handled through "RelatedItems" field

OBS- 30 Y P single-dose-description/text

[E.g., 2, 500]

OBS- 31 Y P single-dose-description/text[E.g., mg, units]

OBS- 32 Y P number-doses-consumed{intended}-in-day

[E.g., 1. 2.5]

OBS- 33 Y P number-doses-consumed{intended}-in-day

[Note: If the CP:OBS component is used as a shared datarepository, the same terminology model shall be used as forthe CP:MED component; if the CP:OBS component isintegrated into a specific PHA, the PHA may use whateverterminology it wishes (or no coded terminology) .]

Medication ID Code System (code)

[Note: Identifies the terminology/coding system used forthe Medication ID; for example, RxNorm, NDC, etc.]

Reference/Link to medication-list record (format TBD)

[Note: Allows PHA to navigate to the associatedmedication-list record, as specified by the PHA that

populates this observation record. Does not assume that theCP:MED component is used (a PHA may use anothercomponent or its own medication-list managementmodule).]

Dose Amount Administered Value (number)

Dose Amount Administered Units (coded)

(Note: If the CP:OBS component is used as a shared datarepository, the same terminology shall be used as for theCP:MED component)

Physical Quantity Administered Value (number)

Physical Quantity Administered Units (coded)


12/98




OBS- 34 2 N Custom field required

[E.g., oral, handheld injection, pump injection, transdermal]

OBS- 35 Y N Custom field required

[E.g., thigh, shoulder for I.M. injection]

OBS- 36 Y N Custom Field required

[values = scheduled administration, PRN]

Attributes of Physical Activity

OBS- 37 Y Y AerobicData.Mode.Text

[e.g., walking, biking, swimming]

OBS- 38 Y Y

[E.g., 875764993 {code = swim}]

OBS- 39 2 Y AerobicData.Mode.Code.Type

(Note: If the CP:OBS component is used as a shared datarepository, the same terminology shall be used as for theCP:MED component)

Route of administration (text and coded)

(Note: If the CP:OBS component is used as a shared data

repository, the same terminology shall be used as for theCP:MED component)

Site of administration (text and coded)

(Note: this attribute may be relevant in cases when the siteof administration affects the absorption rate of amedication)

Reason for administration (coded)

(Note: Additional information regarding the reason for aPRN administration should be stored in the TextComment attribute see Table 6.4)

For each observation of typePhysical Activity Described, the CPC shall be able to store the following data elements in addition to the general data

Activity Text (text)

Activity ID (coded) AerobicData.Mode.Code.ValueHV supports the following "coded" values in their dictionary:

bike, hike, jog, row, run, spin, swim, walk Activity ID Code System (coded)


13/98




[E.g., SNOMED]

OBS- 40 Y Y AerobicData.Minutes

[E.g., 30 minutes, 2 hours, 4 miles]

OBS- 41 2 Y AerobicData.Minutes

[E.g., 30, 2]

OBS- 42 2 Y

[codes = minutes, hours, miles]

OBS- 43 2 N N/A

[E.g., SNOMED]

OBS- 44 Y N

OBS- 45 2 P AerobicData.Intensity (1-5 scale supported)

[E.g., 150, medium, 20]

OBS- 46 2 N N/A

Attributes of Meal/Snack Observations

For each observation of type Meal/Snack, the CPC shall be able to store the following data elements in addition to those listed in Section 6.3.2.1:

N

OBS-46.1 Y N See Above

[E.g., small, 3 large slices, tall glass

OBS- 47 1 N See Above

Duration Text (text)

Duration Value (number)

Duration Units (coded) Minutes is the assumed duration. Conversions can be handledby the client app

Duration Units Code System (coded)

Intensity Text (text) Custom Field Required. There are many discreet propertiesthat allow capture of min/peak/average intensity available forthe AerobicData object.

[E.g., achieved max HR of 150, medium intensity, 20minutes before breaking a sweat]

Intensity Value (text)

Intensity Units (coded)

[e.g., max HR achieved, scale 1-10,enumerated{low,medium,high}, minutes before breaking asweat, etc.]

There is no appropriate HealthVault equivalent to the CPMeal/Snack Observation Type. An application-specificwrapper w/ custom xml schema could be used to support thisgiven the current data model. HV currently supports dailydietary records but not discreet meal documents. A request toHV to add Meal/Snack as a supported type could be made.

Meal/Snack Quantity (text)

Food Items (zero to many values, structured)


14/98




- Food Item Text (e.g., Lasagna)

- Food Item Coding System (E.g., SNOMED)

- Food Item Quantity (E.g. 16, large, 2)

count)

- Glycemic Index (integer)


- Ingredient Text (E.g., Pasta)

- Ingredient Quantity Value (E.g., 6)

- Ingredient Quantity Units Text (E.g., oz)

- Glycemic Index (integer)

Attributes of Sign or Symptom Observations

For each observation of type Sign or Symptom, the CPC shall be able to store the following data elements in addition to those listed in Section 6.3.2.1

- Food Item Code (E.g., 923847 {code =Lasagna})

- Food Item Quantity Units (E.g., oz,enumerated{small, medium, large},

- Food Item Quantity Units Coding System (E.g.,SNOMED)

Food Ingredients (zero to many values for each FoodItem, structured)

- Ingredient Code (E.g., 5778 {code =pasta})

- Ingredient Quantity Units Code (E.g., 5784{code = oz})

- Ingredient Quantity Units Coding System (E.g.,SNOMED)


15/98




Y

OBS- 50 Y Y Condition/Name/Code/Text

[E.g., fatigue, nausea, rash, palpitations]

OBS- 51 Y Y Condition/Name/Code/Value

[E.g., 868590388 {code = fatigue}]

OBS- 52 Y Y Condition/Name/Code/Type

[E.g., SNOMED, UMLS, ICD-9]

OBS- 53 Y

Assume we can use Condition data type. It has all of thenecessary fields. If not using Condition for anything else, thisshould suffice. The HV description of what constitutes aCondition is the following: "Represents a health record itemtype that encapsulates a single condition, issue, or problem."

Symptom Text (text)

Symptom Code (text)

Symptom Code Type (coded)

Status (coded) Condition status is stored in the Condition/Status/Text or


16/98




[values = Present, Absent, Unknown]

Attributes of Pain Observations

For each observation of type Pain, the CPC shall be able to store the following data elements in addition to those listed in Section 6.3.2.1:

N

OBS- 54 Y N See Above

[E.g., Lumbago, Neck pain, stomach cramps]OBS- 55 Y N See Above

[E.g., Back, Left knee, Big toe]


[E.g., 94382793 {code= Big toe}]


[E.g., SNOMED]


Condition/Status/Code/Value element.The Status element is a HV codable-value type, whichrequires a text value and allows an optional code value. Codeelements may repeat. If code is populated then code/value andcode/type must be populated.

No appropriate data type for Pain in HV. Would have tocreate a custom type. - Propose requesting this from MS as asupported data type.

Pain Text Description (text)

Anatomic Location Text (text)

Anatomic Location Code (coded)

Anatomic Location Coding System (coded)

Severity Coding System (coded)

[E.g., 1-10 scale,enumerated{mild,moderate,severe,worst ever}]


17/98





[Allowed values = Yes or No]


[E.g., Throbbing, Sharp, Aching, etc.]


[E.g., 2 days ago, last week]


[E.g., 2007-11-09 00:00:00 GMT -0800]


[E.g., 2007-11-09 23:59:59 GMT -0800]


[E.g., constant, intermittent, worst in the morning]



[E.g., exercising, sitting at work, carrying baby]

Attributes of Observable Parameter Observations

For each observation of type Observable Parameter, the CPC shall be able to store the following data elements in addition to those listed in Section

Radiation? (coded)

Pain Quality (text)

Onset (text)

Onset Timestamp Start Interval

Onset Timestamp End Interval

(An interval is specified to formally represent varyinggranularity in the absolute time of onset, i.e., at some pointduring a specified hour, day, week, etc.)

Temporal Pattern (text)

Attempted Treatments and Effectiveness (text)

[E.g., Aspirin didnt help, rested pain resolved,

warm compress a little relief] Perceived Precipitants (text)


18/98




N


[E.g., Blood Glucose, Range of Motion Knee]


[E.g., 10290293842 {code = blood glucose)]


[E.g., SNOMED, LOINC]


[E.g., numeric, string, coded]

(Note: HL7 has a good list of value types for observations)

OBS- 71 Y N See Above[E.g., 130, 50, 9287928472 {code = normal}]


[E.g., mg/dl, %,]


There is no generic data type that meets this requirement. HVhas taken the approach of explicitly defining data types thataddress specific observations as opposed to this genericapproach. This could be implemented as a custom type.

Parameter Text (text)

Parameter ID (coded)

Parameter ID Coding System (coded)

Value Type (coded)

Value ()

Value Units Text (text)

Value Units Code (text)


19/98




[E.g., MGPERDECI, PCT,]


[E.g., UCUM, ISO]



[E.g., PEDMON {code = pedometer}]

Requirements for Controlled Terminologies for Medication Management

For each type of observation, the CPC shall support and strongly recommend the use of the following coded medical terminologies

Value Units Coding System (code)

Recording Context - Text (text)

[E.g., Pedometer, Depression scale survey APA-11 Question 3, Quality of Life Survey #6 Question 22a]

(When relevant, this attribute records the means by whichthe observed parameter was collected. This may be

particularly important when the responses to surveyquestions are recorded, because the responses may need to

be interpreted in the context of the specific question asked.)

Recording Context - Code (coded)

(Note: These codes will be part of the common platformcomponent data model; this attribute will not be used torecord PHA-specific codes for recording contexts. PHA-specific codes may be recorded in the Additional StructuredData attribute.)


20/98




Y

OBS- 77 Y Y

[Medication Administration:Medication ID]

OBS- 78 Y

YOBS- 79 Y

Y

OBS- 80 Y

Meal/Snack : Meal Quantity Units,

Meal/Snack : Ingredient Quantity Units]

HealthVault has a very generic approach for the coding ofdata. All data types that support a coded data element allowfor multiple names, codes, code types, and code versions. Theactual codes that are used are up to the discretion of the clientapplication.

Any of the coding systems indicated for any of the observationtypes listed in this section can be handled.

In some cases HV provides codes as part of their datadictionary. These are recommended but not required.

Coded Medication

The same code types as allowed for the Identityof Medication attribute in the CP:MED component

Proprietary drug coding systems (First Databank,Medispan, Multum)

Coded Physical Quantity Units

[Medication Administration : Dose AmountAdministered Units,

Medication Administration : Physical Quantity Administered Units


21/98




OBS- 81 Y Y

OBS- 82 2 Y

OBS- 83 Y

OBS- 84 Y

OBS- 85 2

OBS- 86 1

Pain : Anatomic Location]

OBS- 87 3 Y

OBS- 88 Y

[Physical Activity : Activity ID]

OBS- 89 Y Y

OBS- 90 Y

[Physical Activity : Duration Units]

OBS- 91 Y YOBS- 92 2 Y

OBS- 93 Y

[Physical Activity : Intensity Units]

OBS- 94 2

OBS- 95 0

SNOMED

UCUM

Coded Medication Route of Administration

[Medication Administration : Route ofAdministration]

The same code types as allowed for theMedication Intended Route attribute in the CP:MED

component

Routes in proprietary drug coding systems (FirstDatabank, Medispan, Multum)

Coded Anatomy

[Medication Administration : Site ofAdministration,

SNOMED

Coded Physical Activity

SNOMED

Coded Time Units

SNOMED UCUM

Coded Exercise Intensity Scale

Enumerated list of possible intensity scales, asdefined in the CP:OBS component

[e.g., max HR achieved, scale 1-10,low,medium,high, minutes before breaking a sweat

Coded Meal Component


22/98




[Meal/Snack : Food Item Code

Meal/Snack : Ingredient Code]

OBS- 96 0 Y

OBS- 97 2

[Sign or Symptom : Symptom Code]

OBS- 98 2

Y

OBS- 99 1

[Pain : Severity]

OBS- 100 2 Y

OBS- 101 2 Y

OBS- 102 1

[Observable Parameter : Parameter ID]

OBS- 103 1 Y

OBS- 104 2

[Observable Parameter : Value Type]

OBS- 105 1

OBS- 106 1

[Observable Parameter : Value]

OBS- 107 1

OBS- 108 0

[Observable Parameter : Recording Context]

SNOMED

Coded Sign/Symptom

SNOMED

Coded Pain Severity

1-10 scale

SNOMED

Coded Observable Parameter

SNOMED

Coded Parameter Value Data Type

HL7 Data Types for observations (e.g., numeric,string, coded element, date, time)

Coded Parameter Value

SNOMED

Coded Parameter Recording Context


23/98




OBS- 109 1

Required Functionality for the Observation Platform Component

OBS- 110 Y Y Yes

OBS- 111 Y Y Yes

OBS- 112 Y Y Yes

OBS- 113 Y Y Yes

OBS- 114 Y Y Yes

Enumerated list of possible contexts, as defined inthe CP:OBS component

The component shall have the ability to insert a newobservation recordinto the observation database for anexisting patient when a PHA supplies all of the requiredattribute values and represents all attribute values usingallowed formats and coding systems.

The component shall have the ability to modify an existingobservation record(as referenced by its Observation UniqueID) when a PHA represents all of the updated attribute valuesusing allowed formats and coding systems.

The component shall have the ability to delete an existingobservation record (as referenced by its Observation UniqueID)

The component shall make all modifications to and deletionsof existing observations records non-destructively, i.e., a

record of the previous values of any modified or deletedobservation records will be retained within the system, alongwith a record of when the modification/deletion occurred andwhich user requested it (see Audit Logging in Section 7.5).

The component shall have the ability to retrieve and return toa PHA all attributes of all the observation records for aspecified patient in a single operation


24/98




Y Y

OBS- 115 Y Y Yes

OBS- 116 Y Y Yes

OBS- 117 Y N Not a HV default property and so not a standard query.OBS- 118 Y Any query other than the built in attributes are not supported.

Medication Administration Medication ID

Physical Activity ID

The component shall have the ability to return to a PHA asubset of the observation records for a specified patient basedon a query expression that includes type-appropriatecomparisons (>,


25/98




Observable Parameter Parameter ID

OBS- 120 Y Y A range may be specified to search against entry date

OBS- 121 Y P

OBS- 122 Y P

(Certain observation types may not include a codedidentifier.)

Observation Entry Datetime

Observation Effective Start Datetime A value may be specified to search against the minimum(earliest) effective date (EffectiveDateMin).

Observation Effective End Datetime A value may be specified to search against the maximum(latest) effective date (EffectiveDateMax).


26/98



GH Google Health Support Description

Y

P

P

Y

N

Google Health (H9) supports this functionality via an ajax-featured web application for the "patient". Account holdersmay enter some structured "observations". The types ofobservations supported by H9 are listed below in thisdocument. Other PHA applications may submit structureddata as a "notification" to an account.

The data supported by the H9 data model is not flexibleenough to support arbitrary pre-defined questionnaire orsurvey data (unless the data captured can be represented in aCCR document, which is possible for at least somequestionnaires). The H9 data model primarily supports healthsummary data.

H9 supports entry of non-structured textual data that may haveconsiderable length. However, blogs/journal entries are notsupported by the CCR-s data model, per se. The data modeldoes support comments (similar to CP annotations).

One can store device data in the "Results" section of theCCR-s.

The CCR-s data model and the H9 service does not supportimage or attachment upload.


27/98




N

N

N

N

Y

Prescribed medications are supported in the data model butnot the occurrence of the medication being

taken/administered.

CCR-s has no data structure that supports the storage ofphysical activity observations.

CCR-s has no data structure that supports the storage of mealconsumption observations.

The CCR-s has support for surgeries and procedures.

However the kind of data supported by CCR is limited to thekind of procedure and the date of the procedure. This doesn'tfull address the requirements of the CP to support therecording of a healthcare encounter.[Note that CCR-s does not include the elementfrom the CCR]

Conditions and Symptoms section fully support the


28/98




P

Y

N

P

requirements for Sign or Symptom as defined by the CP[Note that signs or symptoms would be represented in theCCR-s as a with a of "symptom","complaint", or "finding"]

Pain could be reported as a Problem with type "symptom", butthe CCR-s condition element doesnt explicitly specify therange of attributes that have been defined for the CommonPlatform Pain observation type (although these attributes may

be constructed in an ad hoc fashion usin theThe CCR-s document supports the recording of discrete

parameters using the "Results" element, which can store testsor observations. Hence, Results could record data fromdevices (e.g., glucometer, pedometers), if the parameter weredenoted as the Result/Test/Description and the value weredenoted as the Result/Test/TestResult.

There is no support for journal entries in the CCR-s datamodel

CCR-s does not support generic observations explicitly, but


29/98




N The elements in the CCR-s data model cannot be extended

Y

Y

P

P

the "Results" section is intended to express all kinds ofobservations. Specifically, the Result/Description field canstore structured or unstructured text for just about any kind ofobservation, although there is no explicit notion of an"ObservationSubType" to indicate what kind of structure has

been written to that field...

The id for an observation is stored in the CCRDataObjectID(String)[Although the CCR explicitly states that these IDs do not needto be globally unique]

Patient/ActorID identifies the patient to which the CCR refers.Details about the Patient are stored in the Actor element and

related through Actor/ActorObjectID (String).

The type is determined by the type of element used to store thedata. There is no field used to separately indicate the type.[Relevant types of elements include "Result" (forObservableParameter) and "Problem[Type=Symptom,Finding, or Complaint] (for SignOrSymptom)]

Each Body child element (e.g., Problems, Medications,


30/98




P

P

P

Immunizations, etc.) has a Type element. This is alwaysoptional, but in many cases, the CCR constrains the values forTYPE, E.g., for Results, the type can only be "Observation" or"Test. This is different and less "application-specific" than thePHD ObservationSubType, which can be arbitrarily assigned

by the client application

DateTime of the document is recorded inContinuityofCareRecord. This DateTime is tied to thedocument version.

Each Body child element has a DateTime element. Althoughthe CCR allows a DateTimeRange as the value of this, CCR-sonly allows an ExactDateTime, which doesn't allow forcleanly denoting the granularity of the time during which theobservation was effective

Each Body child element has a DateTime element. Althoughthe CCR allows a DateTimeRange as the value of this, CCR-sonly allows an ExactDateTime, which doesn't allow forcleanly denoting the granularity of the time during which theobservation was effective


31/98




Y

Y

N

Each Body child element has a description element.Description can be Text and/or Code information.[OR, this could be represented using the CommentID field]

CCR-s supports comments (equivalent to annotations) to beassociated with any supported data element.[Again, this is done via the CommentID field, which is part of

both the and element in the CCR-s]

Not supported[Note that the CCR field Medication/ReferenceID is not part

of CCR-s. This field is intended to reference a element in the footer, which itself can refer to a calendar eventin an external system]


32/98




N

N

N

Not supported[Note that the CCR field Medication/ReferenceID is not partof CCR-s, nor is Medication/InternalCCRLink. These are thefields intended to reference a element in thefooter [in the case of ReferenceID], which itself can refer to anobservation record in an external system OR reference anobservation in the same CCR document (in the case ofInternalCCRLink)]

The definitions of the elements in CCR-s are not extensibleand do not have any elements that allow the posting ofstructured xml data.

Binary and text attachments are not supported by the CCR-s


33/98




Y

ributes:

N

N See Above

N See Above

data model.

The CCR-s model allows the source of data to be recorded inthe element of the entire CCR or in the

element associated with each DataObject, although the valueof these elements are typically the specific source of the data(i.e., the actor) rather than the **type** of source (i.e.,"MedicalSource" vs. "PersonalSource"). The former iscertainly more precise, but it may require client applications toinspect the "ActorRole" of the "Actor" (if the source isexpressed as Actor)

Google Health does not support the concept of MedicationAdministration Observations. However, it does support therecording of prescribed medications (equivalent to the CP

Medication List data element). Comparison between therequirements of the CP with regards to Medication Lists andGoogle Health's support of these requirements is covered onthe Medication List Comparison tab.


34/98




N See Above

N See Above

N See Above

N See Above

N See Above

N See Above


35/98




N See Above

N See Above

N See Above

N

N See Above

N See Above

N See Above

attributes:Google Health does not support the Physical Activity datastructure as defined by the Common Platform requirements.


36/98




N See Above

N See Above

N See Above

N See Above

N See Above

N See Above

N See Above

N

N See Above

N See Above

Google Health does not support the Meal/Snack data structureas defined by the Common Platform requirements


37/98




N See Above

:


38/98




Y

Y

Y

Y

Sign/Symptom text is stored in the Problem/Description/Text

element.The Description element is "used to express the problem".Description is a CodedDescriptionType which allows for Textand or Coded data to be provided (the Code element mayrepeat an unlimited number of times).

Sign/Symptom Code is stored in theProblem/Description/Code/Valueelement.The Description element is "used to express the problem".Description is a CodedDescriptionType which allows for Textand or Coded data to be provided (the Code element mayrepeat an unlimited number of times).

Sign/Symptom code type is stored in the

Problem/Description/Code/CodingSystemelement.The Description element is "used to express the problem".Description is a CodedDescriptionType which allows for Textand or Coded data to be provided (the Code element mayrepeat an unlimited number of times).

Sign/Symptom status is stored in the Problem/Status/Text or


39/98




P

p See Above

p See Above

p See Above

p See Above

p See Above

Problem/Status/Code/Value element.The Status element "defines the status of the problem". Statusis a CodedDescriptionType which allows for Text and orCoded data to be provided (the Code element may repeat anunlimited number of times).[allowed values are Active, Inactive, Chronic,Intermittent, Recurrent, Rule Out, Ruled Out, Resolved.,which overlaps with the PHD status list, but lacks the explicitnegation status "Absent" and the status "Unknown"]

Pain could be reported as a Problem with type "symptom", butthe CCR-s condition element doesnt explicitly specify therange of attributes that have been defined for the CommonPlatform Pain observation type (although these attributes may

be constructed in an ad hoc fashion using theCodedDescriptionTyped element "Description").


40/98




p See Above

p See Above

p See Above

p

p

p See Above

p See Above

p See Above

.3.2.1:

includes an value (although

this doesn't explicitly denote that it is the **onset** date-time,nor allow the representation of a time **range** for theonset)

includes an value (althoughthis doesn't explicitly denote that it is the **onset** date-time,nor allow the representation of a time **range** for theonset)


41/98




P

P

P

P

N Not supported

P

P

P

The CCR-s document supports the recording of discreteparameters using the "Results" element, which can store testsor observations. Hence, Results could record data fromdevices (e.g., glucometer, pedometers), if the parameter weredenoted as the Result/Test/Description and the value weredenoted as the Result/Test/TestResult. However, forobservations that are not readily expressed as test results, theconcept of a parameter/value pair is not supported by

"Results" [e.g., for "Range of Motion" = "reduced"]

Works when the observation can be represented as a test result=> Result/Test/Description/Text

Works when the observation can be represented as a test result=> Result/Test/Description/Code/Value

Works when the observation can be represented as a test result=> Result/Test/Description/Code/CodingSystem

Works when the observation can be represented as a test result=> Result/Test/TestResult/Value ORResult/Test/TestResult/Code ORResult/Test/TestResult/Description/Text ORResult/Test/TestResult/Description/Code/Value

Works when the observation can be represented as a test result=> Result/Test/TestResult/Units/Unit

Works when the observation can be represented as a test result


42/98




p

P

P

=> Result/Test/TestResult/Units/Code/Value

Works when the observation can be represented as a test result=> Result/Test/TestResult/Units/Code/CodingSystem

Works when the observation can be represented as a test result=> Could be captured as Result/Test/Method/Text

Works when the observation can be represented as a test result=> Could be captured as Result/Test/Method/Code/Value


43/98




Y

N

N See Above

N See Above

N See Above

The CCR format allows for any number of codes to beattributed to a data element (e.g., a Condition/Symptom or can have multiple codes provided for a singleentry, all describing the same problem concept). CCR doesnot limit the type of coding system used to identify an entryand can be a mix of standardized terminologies and custominternal codes. Having said this the CCR specification doesrecommend the use of certain terminologies for different types

of elements.Google Health has gone a step further and defined a list ofterminologies that the service will attempt to "understand".This list is specific to each type of element. For example,Problems may be coded using SNOMED-CT, ICD-9, Googlecustom codes, and text-only descriptions.

N/A - Medication Administration Observations are notsupported by Google Health


44/98




N

N

N

N

N

N

N

N

N

N

NN

N

N

N

N/A - Physical Activity Observations are not supported byGoogle Health

N/A - Meal/Snack Observations are not supported by Google


45/98




N

Y

Y

P

P

Health

Problem/Description/Code/Value +Problem/Description/Code/CodingSystem

This is an "understood" coding system for Conditions andSymptoms data type in Google Health

Works when the observation can be represented as a test result

=> Result/Test/TestResult/Value ORResult/Test/TestResult/Code ORResult/Test/TestResult/Description/Text ORResult/Test/TestResult/Description/Code/Value

Works when the observation can be represented as a test result=> Could be captured as Result/Test/Method/Code/Value


46/98




Y

Y

Y

?

Y

New observation record may be added to the summaryinformation by importing the observation from a noticereceived from an external personal health application, but theimport must be done manually by a user ("reconciliation").The new summary information could be a single Observation(i.e., a new problem), but adding it would result in an updateto the entire CCR-s document

Existing records may be modified, but this requires updatingthe entire CCR or CCR-s document

Existing records may be deleted, but this is done as an updateto the entire CCR or CCR-s document.

It is presumed that the Google health service keeps version ofthe patient CCR record to retain previous data. However, this

assumption hasn't been confirmed. Information about recorddeletion wasn't available. Deletes of individual observationrecords are non-destructive, because the entire CCR/CCR-sdocument is **updated** and the previous version is retained(which includes the now-deleted record).

All information in a patient record is returned when requestedfrom the H9 service.


47/98




P

N Not an available query parameter

Y

N Not an available query parameterP

Client applications may retrieve CCR-s documents based oncertain limited query parameters, and may retrieve only partsof CCR-s documents (see description below). However, therange of available query parameters is smaller than thatspecified for observations in the PHD functional requirements.Also, these query capabilities are available only in the gAtomAPI, not the Java and .NET libraries.

Queries may retrieve data from a specified CCR category(e.g., Medication, Condition, Result, etc.)

Queries may retrieve individual data objects by their textdescriptions (e.g., "Ibuprofen" for medications). Availableonly in the gAtom API, not the Java and .NET libraries.


48/98








49/98

Medication Component - Comparison Health Vault and Google

Project HealthDesign,July 2008

Req ID Requirement CP HV

Requirements for Medication List Common Platform Component: Data Source

MED- 1

Y Y

MED- 2

Y Y

MED- 3

Y Y

MED- 4

Y P

MED- 5

Y P

MED- 6

Y P

Types of Medication List Records

MED- 7

Y Y

The component shall have the ability to store prescriptionsthat are electronically imported from external EHR datarepositories, which may contain variable degrees of structure

and coding

[E.g., from an EHR that can export medication records viaHL7 messages or CCR documents]

The component shall have the ability to store prescription datathat are manually entered by the prescribing physician in amanner that is controlled by a PHA

[i.e., the PHA can control the degree of structure and codingof the data]

The component shall have the ability to store prescription datathat are manually entered by the patient or another lay personin a manner that is controlled by a PHA and that is based oninformation appearing on the prescription that the patientreceived from a physician.

The component shall have the ability to store dispense recordsthat are electronically imported from external systems thatmay contain variable degrees of structure and coding, but at aminimum include the NDC codes for dispensed medications

[E.g., a pharmacy, pharmacy benefit manager, or payer viabatch files or real-time EDI transactions]

The component shall have the ability to store dispense recordsthat are manually entered in a manner that is controlled by aPHA and based on information appearing on the label of thedispensed medication.

The component shall have the ability to store dispense recordsfor prescription, over-the-counter, and alternative medicationsthat are manually entered via a PHA based on whateverinformation a patient may have about her medications(possibly just the name)

The component shall have the ability to store a medicationprescription, i.e., the identity of a medication, the amount tobe dispensed, the dosing instructions, and any refillallowances as specified by the prescribing physician.


50/98




MED- 8

Y P

MED- 9

Y P

Attributes of Medication List Records

For each medication record in the medication list, the component shall be able to st

MED- 10

Y Y

MED- 11

Y Y

Y N

The component shall have the ability to store a medicationdispense record, i.e., the identity and quantity of the actualmedication product dispensed by a pharmacy, physician, orover-the-counter outlet, as well as the dosing instructionsprovided with the dispensed medication, and any refillallowances granted by the dispenser. Note that certain ofthese data may be different from those in the correspondingmedication prescription (e.g., a generic equivalent may bedispensed, although a brand-name drug was prescribed).

The component shall have the ability to store an ad hocmedication record, i.e. information regarding a medicationtaken by a patient that is derived from neither a prescriptionnor a specific dispense record. For example, a patient may betaking an over-the-counter medication, such as baby aspirin or

chondroitin sulfate, that is purchased regularly and repeatedlyby the patient. It would not be useful to enter each purchase(dispense record) of such a medication, nor is there aprescription for it.

Medication Record Unique ID (text)

[Note: Assigned automatically by the component. Thecomponent shall assign a unique ID to each distinctmedication record, with distinct medication recorddefined as a specific prescription for a medication,dispensing of a medication, or ad hoc recording of amedication. For example, if a medication record is updatedto reflect a change in the prescribed frequency, that will notrequire the creation of a new record. If the identity of themedication is changed (e.g., from a brand to a generic), thatwill require a new medication record.]]

Patient Record ID (text)

[Note: this attribute stores the unique identifier of thepatient record to which this medication record applies.]

Medication Record Type


51/98




MED- 12

[E.g.., prescription, dispense record, or ad hoc]

MED-12.1 Y N

MED- 13

Y Y

[E.g., Lotensin | 875764993 | NDC ]

MED- 14

Y Y

[E.g., benazepril | 74885933 | RxNorm/IN]

MED- 15

Y Y

MED- 16

Y Y

MED- 17

Y Y

[e.g., by mouth | 8293842 | Snomed {code = oral}]

Y Y

Medication Record Sub-Type (format TBD)

[Note: PHAs may arbitrarily assign sub-types to medicationrecords to assist in the processing of these records. Forexample, a PHA may store additional structured data for amedication record (i.e., data not defined by the commonplatform data model see the Additional Structured Dataattribute below), and the Sub-Type designator allows PHAsto retrieve and process medication records specific to thesub-types that they have defined. The Sub-Type value mustconsist of a Sub-Type designator and the unique identifierof the PHA that created the observation record (to ensure

uniqueness for the Sub-Type designators across PHAs)]

Identity of the medication as prescribed, dispensed, ordescribed by user (text, code, and coding system)

Identity of the generic ingredient(s) of the medication(text, code, and coding system)

Medication unit strength (text, strength value, codedstrength units, units coding system)

[E.g., 10 mg | 10 | 578932 | Snomed {code =milligrams} ]

Medication dosage form (text, code, and coding system)

[E.g., tablet | 84732934 | RxNorm/DF {code =tablet}]

Medication intended route (text, code, and coding system)

Medication intended or actual quantity dispensed andunits (quantity dispensed, units text, units code, unitsCoding System)


52/98




MED- 18

MED- 19

Y P

[E.g., once per day | 8579347 | PHD {code = bid} ]

MED- 20

Y Y

MED- 21

Y Y

[E.g., for breakthrough pain, take with food]

MED- 22

Y Y

MED- 23

Y P

MED- 24

Y N

[E.g., $45.00]

MED- 25

Y Y

[E.g., 100 | tablet | 485738 | RxNorm/DF {code =tablet}]

Medication intended dosing frequency (text, code, andcoding system)

Medication intended dosing quantity and units (text,

quantity value, coded quantity units, units coding system)

[E.g., 2 tablets | 2 | 485738 | RxNorm/DF {code =tablet}]

Medication intended dosing conditions and other

instructions (text only)

Medication intended number of refills (integer)

Complete description of the prescription and/or dispensedata for the medication as a single text string (text only)

[E.g., Lotensin 10mg tabs, 2 tablets by mouth once perday, take with food; disp 100 tabs, no refills

[Note: to allow the import of entirely unstructuredmedication data from external systems]

Out-of-pocket cost for the prescribed/dispensed quantityof the medication (formatted currency)

Reference/link to Calendar events related to themedication [format TBD]

[Note: this attribute allows the users of a PHA to navigatefrom a medication-list record to the specific schedule fortaking the medication, if one has been specified]


53/98




MED- 26

Y Y

MED- 27

Y Y

MED- 27.1

Y Y

[E.g., Remind Grammy to take this medication with food]

MED- 27.2

Y Y

Y P

Reference/link to Observation records related to themedication [format TBD]

[Note: This attribute allows the users of a PHA to navigatefrom a medication-list record to the patient-entered

observations that document when the medication wasactually taken, if such observations have been recorded.]

Reference/link to other Medication-List records related to

the same medication [format TBD]

[Note: This attribute allows a PHA to navigate from aprescription to the corresponding dispense records or fromone dispense record to a subsequent dispense record (i.e.,when multiple refills have been dispensed)]

Annotations (text)

(Note: These annotations may be entered by other users, aspermitted by the relevant access controls. Each annotationshall include a timestamp and the identity of the user whoinserted it.)

Additional Structured Data (structured text)

[Note: This attribute shall store an ASCII-encoded text blob(structured or unstructured) that may be inserted andaccessed by one or more PHAs. The structure and/orcoding used within this field (such as XML) shall be definedad hoc by the PHAs that use the field; i.e., it will not be partof the data model of the medication list component itself.

Medication dosing status


54/98




MED- 28

[Allowed values = active, on hold, discontinued]

(whether the patient is currently taking the medication)

MED- 29

Y Y

MED- 30

Y Y

Terminology Requirements for Medication List Records

MED- 31

Y Y

MED- 32

Y Y

MED- 33

Y Y

MED- 34 Y Y

MED- 35

Y Y

MED- 36

Y Y

MED- 37

Y Y

MED- 38

Y Y

Y N

Medication Record Effective Start Date

[i.e., the date on which the prescription was written, the

medication was dispensed to the patient, or the patientindicates that she began taking the medication]

Medication Record Effective End Date

[i.e., the date on which the medication dosing status of amedication record was changed to discontinued]

The componentshall suggest one or more controlledterminologies that allow the identities of medications to becaptured in a coded format at the following levels ofabstraction.

Brand name only

Generic name only

Brand name + dosage form + dosage strength

Generic name + dosage form + dosage strength

NDC code

The controlled terminology for medications shall supportmapping between the brand names of medications and the

generic ingredients of those medications

The controlled terminology for medications shall supportmapping between NDC codes and all other levels ofabstraction for medication coding

The component shall define a controlled terminology for thedosage forms of medications


55/98




MED- 40

MED- 41

Y N

[e.g., qd, bid, qAM, q4h, etc.]

MED- 42

Y N

[E.g., oral, intramuscular, transdermal, inhaled, etc.]

MED- 43

Y Y

[e.g., mg, mg/ml, etc.]

Required functionality for the medication-list management component

MED- 44

Y P

MED- 45

Y Y

MED- 46

Y Y

MED- 47

Y Y

[e.g., oral tablet, syrup, I.V. solution, transdermalpatch, etc.]

The component shall define a controlled terminology and/orrepresentation syntax for prescribed frequencies of medication

administration

The component shall define a controlled terminology for theroutes of administration of medications

The component shall define a controlled terminology for unitsof measure pertaining to dosage strengths

For any medication on a patients medication list, thecomponent shall have the ability to store theprescription, thedispense record, an ad hoc record, or any combination of thethree. If multiple records are stored for the same medication,the component shall have the ability to explicitly represent theassociation between these records.

The component shall have the ability to insert a newmedication record into the medication list for an existingpatient when a PHA supplies all of the required attributevalues, and the PHA represents all attribute values using

allowed formats and coding systems.

The component shall have the ability to modify an existingmedication record (identified by its Medication RecordUnique ID) when a PHA represents all of the updated attributevalues using allowed formats and coding systems.

The component shall have the ability to delete an existingmedication record, as identified by its Medication RecordUnique ID (for example, if a prescription or dispense recordwas entered erroneously).


56/98




MED- 48

Y Y

MED- 49

Y Y

MED- 50

Y

MED- 51

Y

MED- 54

P

MED- 55 Y

The component shall make all modifications to and deletionsof existing medication records non-destructively, i.e., arecord of the previous values of any modified or deletedmedication records will be retained within the system, alongwith a record of when the modification/deletion occurred andwhich user requested it (see Audit Logging in Section 7.5).

The component shall have the ability to return to a PHA allattributes of all the medication records for a specified patientin a single operation

The componentshall have the ability to return to a PHA asubset of the medication records for a specified patient basedon query expressions that include comparisons (>,


57/98



HealthVault GH

s

Y

Y

Y

P

P

P

Y

HV supports the storage of medication data by external EHRsystems

HV supports the storage of medication data manually enteredby a physician via a PHA.

HV supports the storage of medication data manually enteredby a patient/lay person via a PHA

HV does not distinguish between dispense records andprescription records.



HealthVault supports the storage of prescription data. Most, ifnot all of the medication properties listed in the CommonPlatform requirements are supported by HealthVault.


58/98



HealthVault GH

P

P

re the following data elements:

Y

Y

Custom element required P

HealthVault does not have an element to explicitly indicate ifa medication record represents a prescription, dispense record,or ad hoc (created by the patient manually). The source couldbe used to infer the type. Possibly, the DateFilled couldindicate that the record is a Dispense record rather than aprescription record, but that wouldn't always be reliable,because a prescription could have a value in the DateFilledfield to denote that the patient had filled the prescription,although the record still would not be a "dispense record", perse.

HealthVault does not have an element to explicitly indicate ifa medication record represents a prescription, dispense record,or ad hoc (created by the patient manually). The source couldbe used to infer the type. In addition, the isPrescribed flagallows a system to indicate if a medication was a prescription

or an OTC.

Key.Id = the GUID for each HV item. Any updates to arecord item updates the Key.VersionStamp

PersonId, a System.Guid type in the PersonInfo class/elementis used to store the unique identifier of the personal healthrecord


59/98



HealthVault GH

Custom element required N

Y

Y

Medication/Strength-unit & Strength-value Y

Medication/Dose-unit/Text & Code Y

Medication/Route/Text & Code Y

Medication/Amount-prescribed N

Medication/Name &Medication/Code. Element repeats tosupport brand identification in addition to generic ingredients.

Medication/Code. Element repeats to support brandidentification in addition to generic ingredients.


60/98



HealthVault GH

Medication/Frequency (text only) Y

Medication/dose-value & Medication/dose-unit Y

Medication/Instructions Y

Medication/Refills & Medication/Refills-left N

Y

Custom element required N

Handled through "RelatedItems" field N

Medication/Name can be used to provide a brief text-onlydescription of a medication (absent any coded data in otherfields). However, this wouldn't meet the intent of thisrequirement, which is to provide a *complete* textrepresentation of the entire prescription or dispense record, sothat client applications without the capability to display the

discrete components of a prescription and without thecapability to assemble the discrete components into a singledisplay string would still be able to display the prescriptiondata in its entirety.


61/98



HealthVault GH



Y

N

Y

Annotations are a separate data type within HV rather than aproperty on an object, but annotation items may be linked tomedications items via the "RelatedItem" field

AdditionalData is used to store structured XML data notdefined by the HV service.

Medication/Date-discontinued.


62/98



HealthVault GH

Medication/prescription-duration/start-date Y

Medication/prescription-duration/end-date Y

Y

Y

Y

Y

Y

Y

Y

Y

Text only Y

Allows to indicate that a medication is discontinued. There isno way to indicate that a medication is "on hold"

Health Vault recommends coded identifiers for some of themedication record elements but does not require or depend ona particular coding system.


63/98



HealthVault GH

Text only Y

Text only Y

x12-de-1330 is preferred Y

P

Y

Y

Y

Health Vault does not explicitly support distinguishingbetween prescriptions, dispense records, and patient createdOTC records. However, using a combination of availablefields does provide some support for this concept.

the PutThings method allows for the creation of newMedication records

The PutThings method allows for the update of existingMedication records

The RemoveThings method allows for the deletion of existingmedication records.


64/98



HealthVault GH

?

Y

P

GetAuthorizedRecords/info/id N

N

thing-state allows filtering based on a state of a thing. N

HV keeps track of the different versions of a record aschanges are made.

The GetThings method allows for the retrieval of existingmedication records

HV data may be queried by supplying a number of filtergroups.

Type as defined by the CP Medication List requirements is notsupported. Type queries can be limited to Medication recordsusing ThingFilter/type-id


65/98



Google Health

Google Health supports the storage of medication data byexternal EHR systems

Google Health supports the storage of medication datamanually entered by a physician via a PHA.

Google Health supports the storage of medication datamanually entered by a patient/lay person via a PHA

Google Health does not distinguish between dispense recordsand prescription records.



Google Health allows for the storage of Medication recordswithin the CCRg format. Most, if not all of the medicationproperties listed in the Common Platform requirements aresupported by Google Health.


66/98



Google Health

Google health does not provide an data element to clearlydistinguish between prescription records and dispense records.However, the source information associated with a

medication record can indicate that the originator was apharmacy or payer system, and assumed to be a dispenserecord).

Google Health allows for the source of data to be stored so asto be able to distinguish between medication records createdby the patient and those created by a physician in an externalsystem.

The id for a medication is stored in the CCRDataObjectID(String)

Patient/ActorID identifies the patient to which the CCR refers.Details about the Patient are stored in the Actor element and

related through Actor/ActorObjectID (String).

Google Health CCRg supports the type element of medication.


67/98



Google Health

Not supported

Medication/Directions/Direction/Route/Text & Code

However, only the following types are supported

{Medication, IV Fluid, Parental Nutrition, SupplementalNutrition, Immunization, Disposable, Supplies, Device,Implantable Device, Durable Medical Equipment}

Medication/Product/ProductName/Text & Code(value,system, version)Also Medication/Description/Text & Code

Medication/Product/ProductName/Text & Code(value,system, version)Also Medication/Description/Text & Code(value, system,

Medication/Product/Strength/Text, Units(Unit & Code), &Code(value, system, version)

Medication/Product/Form/Text & Code(value, system,version)

Dispense quantity is not available. If the medication has astandard unit-of-use packaging, the NDC code used to identifythe medication could be used to indicate dispensed quantity,


68/98



Google Health

Medication/Directions/Direction/Dose (Value, Units, Code)

Medications/Medication/Description/Text

.[Note: CCRg does not include the nor the element that is part of Medicationsin the CCR]

Medication/Directions/Direction/Frequency (Description,value, units, code).Medication/Directions/Direction/Interval

Medications/Directions/Direction/Dose

The dose element may repeat for this purpose.

Refill information (e.g., Number, PRN) is not supported[Note: CCRg does not include the element that ispart of Medications in the CCR]

Cost information is not supported by CCRg[Included in neither CCRg nor the CCR]

Note: The CCR field Medication/ReferenceID is not part ofCCRg. This field is intended to reference a element in the footer, which itself can refer to a calendar eventin an external system


69/98



Google Health

CCR does not support extensible data structures.

Medications/Medication/Status (Text, Code)

Note that the CCR field Medication/ReferenceID is not part ofCCRg, nor is Medication/InternalCCRLink. These are thefields intended to reference a element in thefooter [in the case of ReferenceID), which itself can refer to anobservation record in an external system OR reference anobservation in the same CCR document (in the case ofInternalCCRLink)

Note that the CCR field Medication/ReferenceID is not part ofCCRg, nor is Medication/InternalCCRLink. These are thefields intended to reference a element in thefooter [in the case of ReferenceID), which itself can refer to aMedication record in an external system OR referenceanother medication in the same CCR document (in the case ofInternalCCRLink)

Handled through Medication/CommentID, which is intendedto reference a element in the footer


70/98



Google Health

Multiple codes are allowed for a medication

The FDA code set for dosage form is supported by H9

Medications/Medication/DateTimeMultiple DateTime elements may be created for a single

medication. The type would be "Start Date"

Medications/Medication/DateTimeMultiple DateTime elements may be created for a singlemedication. The type would be "Stop Date"

CCRg supports multiple coded identifiers to be associatedwith a single product.

Handled through BrandName => a CodedDescriptionType thatallows text description and a code

Handled through ProductName => a CodedDescriptionTypethat allows text description and a code]; it's explicitly intendedfor the *generic* name of the drug; CCR indicates that anNDC code or RxNorm code should be used here, so it's notclear whether this code can/should include the strength/dosageform info, too. It's also not clear what NDC code should beused in the case of a **brand drug**, because the NDC codewill be for the *branded* drug, not for the generic formulation

Could be handled through ProductName, if the drug is at thelevel of an NDC code or an RxNorm clinical drug code

Yes, NDC is one of the codes allowed for the ProductNamefield

H9 supports RxNorm, NDC, RxNorm_Brand,RxNorm_Ingredient, NDC_nameonly, text (in this order of

preference)


71/98



Google Health

The SNOMED-CT code set for frequency is supported by H9

The FDA code set for route is supported by H9

UCUM is preferred

Existing medications may be updated

Existing medications may be deleted

The CCR format does not explicitly support distinguishingbetween prescriptions, dispense records, and patient createdotc records. However, the source information supported byCCR can provide some of this information.

New medication records may be added to a health summary[Although this must be manually done by a user through thereconciliation wizard]


72/98



Google Health

All CCR data is transmitted when requested.

Not an available query parameter

Not an available query parameter

Unknown if Google Health Retains deleted record data inversions.[This may not be applicable, given the Google model ofupdating the entire CCR document, rather than an individualrecord; so, the deletion of a med record implies an updateddocument, with that particular DataObject absent. However,the entire CCR document has not been deleted, so a record ofits previous state (i.e., including the deleted med record) stillexists, i.e., the deletion is "non-destructive" [unless the entireCCR document can be deleted]

Client applications may retrieve CCRg documents based oncertain limited query parameters, and may retrieve only partsof CCRg documents . However, the range of available queryparameters is smaller than that specified for observations inthe PHD functional requirements. Also, these querycapabilities are available only in the gAtom API, not the Javaand .NET libraries.

Not an available query parameter[A complete CCR or CCRg document may be selectivelyretrieved by its UniqueID, but not individual DataObjectswithin a CCR]


73/98

Calendar Component - Comparison with iCAL/WCAP

Project HealthDesign, July 2008

Req ID Requirement

CAL- 1

CAL- 2

CAL- 3

CAL- 4

Req ID Requirement

CAL- 5

CAL- 6

CAL- 7

CAL- 8

CAL- 9

The Calendar component shall have the ability to store events and related reminders thatare entered manually by the patient, a family member, a caregiver, or a healthcare providerin a manner controlled by a PHA.

The Calendar component shall have the ability to store medical-appointment events that

are imported from external scheduling applications, such as those used by a health-carefacility.

The Calendar component shall have the ability to store personal events and relatedreminders that are imported from an alternative personal calendar system (E.g., Outlook,Google, etc.) that may be used by a patient

The Calendar component shall have the ability to store events and related reminders thatare generated automatically by a PHA (for example, an automatically generated dosingschedule for a specific medication, an automatically generated exercise schedule, or anautomatically generated schedule for patients to record observations regarding theircondition).

The calendaring component shall have the ability to store and distinguish am

Common Platform Comparative Analysis Appendix

Documents

Transcript of Common Platform Comparative Analysis Appendix