Patient
A patient is a person that is receiving care. Note that much of the content model is common between patient and person (the relationship is explicit in the data dictionary).
The relative url is /patients
todo: * animals? * guardians and NOK
See also the Patient Data Dictionary
Content
<Patient xmlns="..."> <id mand type="id">Master Resource Id, always first in all resources</id> <version opt type="id">version identifier</id> <status mand type="code">active|retired. See status below</status> <created opt type="datetime">date created, always present except on create</created> <updated opt type="datetime">date updated, present if resource updated</updated> <links type="list"> <!-- Zero+ --> <link mand type="Resource(Patient)">Other patient records linked to this record</link> </links> <identifiers type="list"> <!-- One+ --> <identifier type="HumanId">Human identifiers for this patient</identifier> </identifiers> <institution opt type="Resource(Organisation)">Which institution this patient is registered to???</institution> <names type="list"> <!-- Zero+ --> <name type="Name">A name associated with the patient</name> </names> <addresses type="list"> <!-- Zero+ --> <address type="Address">An address for the patient</address> </addresses> <contacts type="list"> <!-- Zero+ --> <contact type="Contact">A contact detail for the patient</contact> </contacts> <dob opt type="HumanDate">The birth date for the patient</dob> <dod opt type="HumanDate">The date of death for the patient</dod> <birthplace opt type="Location">Where the patient was born</birthplace> <languages type="list"> <!-- Zero+ --> <language> <language mand type="code">ISO code for language</language> <use opt type="list(code)">Proficiency, modes, preferences</use> </language> </languages> <citizenships type="list"> <!-- Zero+ --> <citizenship> <passport opt type="Identifier">Passport Id</passport> <country type="code">country of which the person is a citizen (iso XXX)</country> <period opt type="Interval(HumanDate)">Time when patient was a citizen</period> </citizenship> </citizenships> <employments type="list"> <!-- Zero+ --> <employment> <title opt type="string">The position title</title> <code opt type="Concept">Code for the kind of position</code> <employer opt type="Resource(Organisation)">The employer</employer> <occupation opt type="Concept">Code for the kind of vocation/occupation</occupation> <identifier opt type="HumanId"/>Identifier for this position</identifier> ??? <address opt type="Address">Address associated with this employment</address> <place opt type="Location">Where the person works</place> <period opt type="Interval([[HumanDate">Time of employment</period> </employment> </employments> <studies type="list"> <!-- Zero+ --> <student> <institution opt type="Resource(Organisation)">Administering</institution> <identifier opt type="HumanId"/>Student identifier</identifier> <address opt type="Address">Address of instition</address> <place opt type="Location">Physical Location of institution</place> <period opt type="Interval([[HumanDate)">Time of study</period> </student> </studies> <qualifications type="list"> <!-- Zero+ --> <qualification> <title opt type="string">name or title of the qualification</title> <code opt type="Concept">A code for the qualification</code> <institution opt type="Resource(Organisation)">Conferring</institution> <date opt type="HumanDate">When the qualification was gained</date> </qualification> </qualifications> <extensions> See Extensions </extensions> <text type="Narrative">Text summary of patient, fall back for human interpretation</text> </Patient>
Concept Bindings:
- The use codes for a language (written, spoken, preferred, excellent, poor, etc) are a space separated list and must come from the list of language use codes.
- employment.code is bound to the concept domain "EmploymentCodes"
- employment.occupation is bound to the concept domain "Occupations"
- qualification.code is bound to the concept domain "QualificationCodes"
Notes:
- This overlaps with person but provides additional detail appropriate to a patient
- At least one human identifier is required (at least one of the identifiers must not have a dataAbsentReason flag)
- Various jurisdictions define their own position, occupation and qualification codes, and some care about this more than others.
- The organization references are all optional, so can be replaced by simple text
- Kind of employment is usually level of employment
Managing Patient Registration
Managing Patient registration is a well known difficult problem. Around 2% of registrations are in error, mostly duplicate records. Sometimes the duplicate record is caught fairly quickly and retired before much data is accumulated. In other cases, substantial amounts of data may accumulate. For these and other reasons, the identifiers associated with a patient may change over time.
The master identifier for the Patient Resource can never change. For this reason the identifiers with which humans are concerned (often called MRN - Medical Record Number, or UR - Unit Record) should not be used as the master identifier. Instead they should be represented in the identifier list where they can be managed. This is also useful for managing institutions that have acquired multiple numbers because of mergers of patient record systems over time.
In this specification, patient records are never merged. Either the content is moved to a different patient record (by updating the relevant resources directly) and the patient record retired, or an assertion is made the two patient records concern the same actual person ("linked"). When this happens, all linked records must reference each other using the "linked" Resource references.
Note: Most systems will not support deleting/destroying patients.
Resource Status
Patient records may only be in one of two statuses: active and retired. A normal record is active - it is in use. The status retired is used when a record is created in error. Once the error is discovered, it can either be retired or deleted.
Transactions
The patient resource type defines one special transaction provided by the patient manager: "Link" for linking records. The reason is that linking records is effectively a transaction that involves at least two records, and all or none must change. Since the transaction involves multiple resources, it is implemented on the type.
<Link xmlns="..."> <transaction/> <!-- See Transaction Support --> <links type="list"> <!-- Two+ --> <link mand type="Resource(Patient)">Patient records to link</link> </links> </Link>
There is no content model for the response, except for an HTTP status code.
TODO: Should there a transaction for retiring, or is it just a straight update?
Searching Criteria
The following simple search/filter parameters are defined for patient:
name | a portion of name in any name part |
phonetic | a portion of name using some kind of phonetic matching algorithm |
algorithm | specify which phonetic matching algorithm applies |
id | search id in any identifiers (including employment related etc) |
The standard search parameters also apply (see Searching).
Example
<Patient xmlns="..."> <id>3a654dc</id> <version>3</id> <status>active</status> <created>2011-06-04T16:14:05</created> <updated>2011-06-04T20:43:31</updated> <links> <link> <type>Patient</type> <id>25bd34</id> </link> </links> <identifiers> <identifier> <type>mrn</type> <identifier> <system>0.1.2.3.4.5.6.7</system> <id>2356</id> </identifier> <period> <low> <date>2009-06-05</date> </low> </period> </identifier> </identifiers> <institution> <type>Organization</type> <id>34</id> </institution> <names> <name> <use>usual official</use> <part> <type>given</type> <value>Peter</value> </part> <part> <use>callme</use> <type>given</type> <value>James</value> </part> <part> <use></use> <type>family</type> <value>Chalmers</value> </part> </name> </names> <addresses> <address> todo </address> </addresses> <contacts> <contact> <dataAbsentReason>unknown</dataAbsentReason> <use>home</use> </contact> </contacts> <dob> <date>1974-12-25</date> </dob> <languages> <language> <language">en-us</language> <use>good spoken written</use> </language> </languages> <employments type="list"> <!-- Zero+ --> <employment> <title>Leading Hand</title> <employer> <text> <plain>Acme Enterprises Inc.</plain> </text> </employer> <address> <text> <html xmlns="http://www.w3.org/1999/xhtml"> 1050 W Wishard Blvd<br/>RG 5th floor<br/>Indianapolis, IN 46240 </html> </text> </address> </employment> </employments> <text> <html xmlns="http://www.w3.org/1999/xhtml"> <table> <tr><td>Name:</td><td>Peter James Chalmers</td></tr> <tr><td>MRN:</td><td>2356</td></tr> <tr><td>DOB:</td><td>25-Dec 1974</td></tr> <tr><td>Gender:</td><td>Male</td></tr> </table> </html> <generated>true</generated> </text> </Patient>
© 2011