This XSD defines the contents of an HealthFrame PHR document, and is the format of an Export file for HealthFrame 2.0 ISO-4217 3-letter currency codes, as defined at http://www.xe.com/iso4217.htm Only a subset are defined here. For HeatlhFrame 2.0, we will allow for bogus KEY values, since that is (basically) how we support user-defined entries (for 2.0). But - in future versions (3.0) - we will be more strict about the allowable values in the KEY a unique identifier - roughly in the format - Hxxx, Cxxx - as UMLS codes. (to be specified in more detail for 3.0) Nearly always have exactly one of these - in english, but allow for supporting more in different language. One exception is an empty key will have no print name. Name of a given code - eg. UMLS; enumeration of names is identical to that in CCR 1.0 (spreadsheet) This is the value of the code, as a string. Version of the codeset A physical address (currently US-centric) Objects with IDs - that can be refered to via link (LinkType) objects. This is a power mechanism to create relationships between objects, like conditions and medications etc. Logically - we want this to be inherit from both NillableBase64 and DataObjectType, but I haven't found the syntax for this multiple inheritance This is used for an event which may take several days (like the span of a disease). If it takes one day - simply set Start and End to be the same value. To indicate a Start date - where the associated item has not yet terminated - omit the optional End date. The start date can also be omitted - indicating that it is not known. This is used for an event which may take several days (like the span of a disease). If it takes one day - simply set Start and End to be the same value. To indicate a Start date - where the associated item has not yet terminated - omit the optional End date. The start date can also be omitted - indicating that it is not known. Locations contain a pretty name, together with an associated address Note that this name is NOT a key. It is a shorthand whcih maybe helpful in the context in whcih its shown. For example "office" for a Providers Location record. Sometimes something can be associated with either a provider or a provider organization (e.g. a test). Body part associated with the symptom An activity is an event which the user engages in periodcally - like swimminmg, biking, smoking, or alcohol consumption - that is kept track of in the PHR - and is health-relevant. Advance directives capture. This will change dramtically for 3.0, but hopefully this allows us to capture enough informatoin for the 2.0 life cycle to be useful. This will probably end up mirroring what is done in CCR over the next year, or other existing advance directive forms/standards. Union of CommunicationTypeEnumeration xs:string This is for a medical device, such as eyeglasses, a heart-implant, a nebulizer, or any other medical device you want to track (for reasons of expenses or showing on medical reports or whatever) Note - its common to use expenses with links (LinkType) to link expenses to the thing they are an expense for (e.g. Medical Device, visit, etc) This could be soemthing like CoPay, or ??? - need list - need new ConceptCategory for this! Journals are logically collection of journal entries. The JournalEntires associated with a given journal are aggregated using 'aggregates' link relationships. To find the owning journal, lookup the (sole/unique) link relationship which aggregates this object. It should be of type Journal. A 'Link' object is meant to specify an arbitrary relationship between two objects in the PHR (or between one object in the PHR and one external object). N-ary relationships can be represented via multiple link objects. The L1 element is - in some sense - primary - in that it must refer to an element of this PHR. L2 can either be an object in this PHR, or an external object. When deleting objects, the links must also be deleted to assure referential integrity. If the link relationship is Aggregates (UMLS C0332621) - then when object L1 is deleted, object L2 will be silently deleted as well. In either case, you must delete any links that refer to objects that have been deleted. As an example, a VisitObject might create a link to an Expense object with relationship 'Aggregates' for the COPAY - and then when the visit is deleted - you would delete the co-pay expense a the same time. This end of the link must be an internla link - an IDREF to an element that extends DataObjectType. This end of the link can be either an internla link - an IDREF to an element that extends DataObjectType - or it can be a url (for external links). EITHER an idref or a url - but not both - and not neither. For now 'owns' or 'owns-sub-object' - but we can extend this to more types later. Note that the fullfillment history is currently (2006-01-24) as related Expense objects. This neglects SOME information that might be useful to keep track of for fullfillment, but appears to be adequate for HealthFrame 2.0. Amount per pill (or solution strength if liquid). Addiitional Instructions (e.g. take with food, take as needed, etc) IDREF points to a Provider Boolean flag to indicate if this medicine was prescribed. Note - even if this is false - Prescriber can be set to indicate the doctor recomending this non- prescription medicine. Amount which should be taken per day. Optional reference to location (from among list in PrividerOrOrganizationRef The Dates record almost always will contain a start/DATE the same as the endDate (though the time part maybe different and maybe omitted). The entire Dates section must be omitted if the DuringVisitRef is specified (and then the date from that visit is used). If the Administered section is eliminated (or just its date portion) - then get teh date from the Ordered element. Union of TestResultTypeEnumeration xs:string. I THINK THIS IS UNUSED - and could be delted, or re-thought. These are all measurements - (LIST SEMANTIC TYPE OF NAME BELOW). Consider adding underneath this object - a Provider/ProviderOrganization for who administered the immunization (optionally) Optional reference to visit where test performed (or ordered) preferred values are good,excellent,fair,poor,dead (MUST REVISE THIS ONCE WEVE INTEGRATED WITH NEW UMLS STUFF) relationship of phr owner to the subscriber A Provider is any person who provides medical care (e.g. doctor, nurse, etc). Note that even though by XSD checking - the supported roles CAN be empty, its strongly recomended to include a supported role. The only reason we allow for it being empty is to facilitate mapping of imported XML sources that might not have a reasonable (required) supported role. This is a reference to a ProviderOrganization A ProviderOrganizationis any organization whcih provides medical care (e.g. hospital, HMO, etc) Freeform description of reason for visit Freeform notes to prepare for doctor visit (e.g. list of things to ask) Notes taken after the visit - probably relating to PreparationNotes and about future things to do The VisitLocation is selected from among the various Provider (ProviderRef)'s owned Locations. Start/End date apply iff Type=SpecifiedDateRange ID is URL (or id/name) of the page for which these customizations apply. Note - this is not necessarily (or likely) a user-visible, displayable name. Relationship code should be (not required) concept of type EmergencyContactRelationship Current images of the PHR owner. Historical images can be retrieved through the change/history mechanism.????? Or not? Top level record for the PHR (Personal Heath Record) This is if the user afirmatively declares he has no allergies, so we can distinguish between that case and simply not having had any entered into the list yet. All attachements are stored in one big group with references to them managed by LinkType relationships. As for HF 2.0b9 - they are 'owned' via Aggregates relationships All journal entries are stored in one big group with references to them managed by LinkType relationships. As for HF 2.0b9 - they are 'owned' by Journal objects via Aggregates relationships