Patient Administration Resource development

Return to FHIR Mainpage

Project Information

This project will identify and define the initial set of “key” FHIR resources related to the domain of Patient Administration. These resources will be defined using the available FHIR tooling and in accordance with documented quality guidelines and balloted as part of the initial FHIR specification. Expected FHIR resources to be produced include: Patient, Person, Group, Organization, Encounter, Appointment, Service Delivery Location, Place

In addition, as the committee deems appropriate and time availability permits, it will define a small number of FHIR extensions relevant to domain content and expected to be necessary to support consistent early implementations.

Meeting Information

• link to or list project meeting schedule
• link to minutes web page or wiki minutes page, or list project meeting agendas and minutes

General Considerations

Tier 1: attribution

The single must important question with the administration resources is how to structure the patient/person/role.

• Should you have patient and something like agent/employee/provider?
• That's simple, but what do you do about animal? fold it in to patient?
• maybe you just have patient and animal - but then, do all the clinical resources need to offer either person or animal as context?
• which clinical resources are human only? are any animal only?
• what about animals that aren't patients?
• must you treat patients separately to other kinds of people even if you know they are the same person?
• what's a patient beyond a person or an animal anyway?
• how should you manage linking/merging in a restful way? in a safe way?

The current design has the following shape:

• person - the basic demographics of a human, along with the some intrinsic information about the person themselves
• animal - a non-human equivalent. Has different demographics and relationships
• patients - the notion of an individual who has an ongoing record care provision at given institution (scope is flexible)
  • patient points to either person or animal
  • patient records can be linked or unlinked. Records are never "merged" - that's not restful.
• organization - an abstractly defined entity that provides healthcare or is otherwise related
• agent - a person authorized to perform some role on behalf of an organization (possibly certified by yet another organization)
  • LM: This is often used for Provider, but is more general. Is it too confusing to combine them?
  • GG: don't know. you mean, the name, or the role? not combining them is also confusing. The name - would be good to do better. I'm not a fan of "role" for this.

Ongoing open issues:

• Is it useful to have person separate from patient? should person just be collapsed down into patient and agent? (if so, what happens to animal?)
• should a person (and animal) have observations? Are some of the attributes (some of which were added in tutorials to demonstrate the methodology) observations
• which things are in the 80%?
  • For instance, person qualifications are not in the 80%, because you don't keep them about patients. Except that some systems/countries do, and it's about 80% of implementers, not cases. Still, the question is open
• with regard to patient linking, should there be a preferred? Are only patient records ever merged? How would you cope with this in a legacy system that does true merge at the person level?

Tier 2: process / workflow

The current FHIR resource list anticipates two more resources:

• admission - the patient is actively moved into care, and out of care.
  • The anticipation is a physical visit (inpatient, emergency, or clinic), but the notion of a physical visit is starting to get outmoded.
  • There are many arguments around what an admission / episode is. This is also frequently called "encounter" though this is other implications

• InterestOfCare - where a care provider has an ongoing interest in the patients care that continues across multiple episodes
  • typical example, a registered GP in countries where this concept applies
  • an oncologist who will care for a patient across various episodes of surgery, radiotherapy etc
  • LM: Generally this is handled by Patient Care
  • GG: which points out a problem - there's an overlap between the clinical concern and the administrative concern

Unfortunately, the differences between these two are somewhat blurry where they meet, and where they intersect with real world work flows. Generally, what else might be required?

• Future Appointment
  • LM: Aren't all appointment's "future"? Appointment = Scheduled mood. Encounter = Event mood
  • GG: there's past appointments - ones that were in the future, but are no longer, and concerning which we now have additional records. "Future" was an attempt to scope that out in a few words

• Transfers
  • LM: That belongs to patient care
  • GG: no, that would be referrals. Transfers is the rather boring business of getting orderlies or taxis or ambulances to move a patient from here to there

• record tracking?
  • LM: Not sure what this means
  • where is the paper record (or film bags, or prescription list) today? Used to be important, but everybody is going paperless...... sloooowly

Analysis of the domain, list of resources

• Person has a list of roles to record guardianship, care givers, responsible persons, contact persons, personal relationships etc. How to represent these "related parties"? If as nested groups of attributes within person, what to do with those groups that are relevant for animal too? Duplicate them? Animal uses "RelatedEntity" to cover these cases. Should we collapse all of the above as RelatedEntity for Person too?
• There is value in separating patient and person, since combining them results in attributes about patientship ending up in person. In current DMIM these are:
  • Person attributes used only for Patients: educationLevel, disabilityCode, livingArrangement, religiousAffiliation, raceCode, ethnicGroupCode
  • Roles used with Person when a patient: CareGiver, R_Guarantor
  • Coverage is connected to Patient role
  • Patient.id, address, telecom, status, effectiveTime, confidentiality, VIP code
• Differences between Animal and Person
  • Animal.existenceTime, Animal.riskCode, Animal.handlingCode, Animal.strainText, Animal.genderStatusCode, Person.addr, Person.educationLevelCode, Person.disabilityCode, Person.livingArrangementCode, Person.religiousAffiliation, Person.race, Person.ethnicGroup
• Many roles and entitites have id with card > 1, as modeller this is convenient because you leave open the possibility of having multiple, but as implementer you have to keep track of them, map to 1-n relationships, search in multiple records for a query etc. So, is it useful to stick to "1", unless there's a usecase for "n" ?

Group

• Group: Id, Code (, name and description is core.
• Is this a care-related group (e.g. household) or administrative (projectgroups, tribes)
• LM: This will need to be distinguished from Organization as well (which seems like a type of group - and not necessarily restricted to legal organizations). Also, consider "Resource Group" from the RIM, which is a different kind of grouping.

Resource development pages

• FHIR Person
  • Person_FHIR_Resource_Proposal

• FHIR Animal
• FHIR Agent
• FHIR SubjectOfCare
  • SubjectOfCare_FHIR_Resource_Proposal
• FHIR Group
• FHIR Organization
• FHIR Encounter
• FHIR Appointment
• FHIR AppointmentRequest
• FHIR Service Delivery Location
• FHIR Place

Template for new resource proposals

Template:FHIR_Resource_Proposal