Todd Biske: Outside the Box

Archive for the ‘Health Care’ Category

I’ve been reviewing the FHIR (Fast Healthcare Interoperability Resources, http://www.hl7.org/fhir) specification and they have an interesting concept called a compartment.  Per the spec:

Each resource may belong to one or more logical compartments. A compartment is a logical grouping of resources which share a common property. Compartments have two principal roles:

• Function as an access mechanism for finding a set of related resources quickly
• Provide a definitional basis for applying access control to resources quickly

Let’s look at these statements one at a time. First, the component concept provides an access mechanism for finding related resources. One very common compartment in the specification is Patient. Other resources, like Condition, clearly have a relationship with Patient. So, if I want to find all conditions that a particular patient has, I actually have two paths for doing this.

• GET /Patient/[id]/Condition
• GET /Condition/?patient=[id]

[id] is the unique identifier in question. In this case, both of these requests should return the same thing.  But it’s not quite that simple.  Take another resource, Communication, which deals with secure messages sent as part of patient care.  In this case, we have:

• GET /Patient/[id]/Communication
• GET /Communication/?subject=[id]
• GET /Communication/?sender=[id]
• GET /Communication/?recipient=[id]

The first example returns any communication that involves the identified patient, whether to, from, or about.  The Communication specific inquiries only allow for inquiry by the attribute of the resource where a Patient identifier can be specified.  It just so happens that in the earlier case, the relationship within Condition is represented in a patient attribute.

Independent of whether you think this is a good or bad thing, this approach where there are two ways of getting to the same resources creates a decision point for the organization.  In a large enterprise, it’s entirely possible that the implementation for different resources may be handled by different teams.  With two (or more) different ways of doing this, it creates the risk of two (or more) different implementations.  It also creates a situation where a resource that can be a compartment needs to make sure that any time a new related resource is defined and implemented, they also need to make a modification to provide the compartment-based inquiry.  Once again, if this is a separate team, this means coordination. Anyone who’s worked in an enterprise knows that the more teams that get involved, the more challenging it becomes.  

These are not insurmountable difficulties by any stretch of the imagination.  In the case of the implementation, the compartment resource should simply act like a façade and make the appropriate calls to the resource (i.e. the implementation of the first URL in the examples above simply turns around and makes the call(s) below them to complete the inquiry, such as Patient calling Condition, or Patient calling Communication).  In the case of the coordination, that’s a matter of education and oversight to make sure it happens.  The greater risk is probably that too many things get defined as a sub-structure within the compartment resource, rather than defined as standalone resources.  This can be avoided by recognizing when a proposed resource has multiple compartments.  Take the following requests:

• GET /Practitioner/[id]/Condition
• GET /Condition?asserter=[id]

These inquiry would give me a collection of all conditions that a particular practitioner has ever dealt with.  If Condition  wasn’t a standalone resource, and instead a sub-structure within Patient, how would I go about forming this query?  It can be done, but it’s probably not going to look as simple as what is shown above. This is where I see the hidden strength of this compartment concept.  By recognizing where we can have multiple ways of organizing a particular collection of data and traversing relationships, we can then make good design decisions on what our resources should be.

Finally, FHIR also mentions that the compartment concept can also play a role in access control.  I haven’t dug into this one as much, but I think it may have some potential. The challenge lies with data that really has multiple owners.  As a patient, I may want to use an OAuth model to grant access to my health records to a mobile app I’ve downloaded. My doctor may want to do the same thing for an application he or she uses as part of my care.  The compartment approach could give independent access paths for each of these channels with their own policies.  Again, I need to give this one more thought, but I can definitely understand why HL7 put the bullet point about access control in their specification.

What are your thoughts about this notion of compartments?  Good thing? Bad thing?  Have you implemented a similar approach? What were the pros and cons of it?  Let’s start the discussion.

I had a doctor’s appointment today, and in the office, they had a poster asking their patients for patience as they work to implement electronic records. The signs have been up for the last few visits, so I think the bulk of the efforts are complete. From an experience standpoint, I’m very satisfied.

When the effort first started, one of the first things they did was take a digital photo of me at my next visit. In addition to the office staff now recognizing me when I come in the office, I personally feel that this has greater potential for reducing errors. Why? Every staff worker that’s not permanently seated at a desk is carrying around a laptop (Fujitsu Lifebook, I believe). When they are dealing with patients, they should be seeing my smiling face as they enter in various information. That provides a constant reminder of who they’re working with. When dealing with paper files, there’s a risk that someone gets them mixed up, and the people using them don’t realize it. While I’m sure this is a very infrequent occurrence, it’s still possible, and having the person’s photo there the whole time should reduce those occurrences even more.

With today’s visit, the cool thing that happened is that my doctor needed to issue a new prescription, and she simply typed into her laptop and told me it would be at the front desk. When I went to the front desk, they handed me a printout, but also indicated that the printout had already been faxed to my preferred pharmacy. Cool.

Overall, I like what it has enabled. The thing that stood out like a sore thumb, however, was the dependency on the FAX machine. They communicated with my pharmacy via FAX. They issue requests to the lab downstairs via FAX. It would be great if some standards could exist so that the doctor’s systems are directly communicated with the pharmacy network or the laboratory. While the electronic prescription FAX has the medication printed in a nice 14 point serif font, it still gets turned into a bitmap, spat out on a sheet of paper, and interpret by some pharmacy technician. From my standpoint, I’d prefer that the doctor’s office talk directly to the pharmacy’s information systems to make this happen and take as much human element out of it as possible. I’d rather have the pharmacist talking to people about their medications than having to interpret doctor’s handwriting or some poor resolution fax.

The other piece of this that could be improved is to provide a secure way for me to get at the information. Suppose you get a cholesterol test. Often times, the doctor may just tell you, “you’re normal.” Typically, however, it’s important to look at trends. (Aside: Yes, just as you should be looking at the metrics of your IT systems and associated trends when things are working fine, you should be looking at your own metrics and trends for your own physical health!) To look at trends, you need the actual test results. Today, I have to call up and have someone read them to me. It would be far more convenient to have some secure electronic way of accessing it. It’s especially true when you’re dealing with multiple doctors. They have a major data synchronization problem, where the patient is viewed as the authoritative source, but often times, we don’t have all the information because our doctor’s haven’t given it to us, or if they did, it was 6 months ago. How many of us have our own medical record keeping system?

Anyway, kudos to my doctor for trying to push the envelope a bit and leverage technology. Here’s to hoping the trend continues.