Fairhaven, The River

On PCAST security

In Trust and PCAST model John Moehrke comments on the PCAST security model.  For some reason blogger won't let me add comments.  So here are some some legal requirements issues.  Most states have similar rules.  These are for MA. 

The ruling case is DYLAN KEENE vs. BRIGHAM AND WOMEN'S HOSPITAL, INC. 439 Mass. 223.  This was appealed, upheld, and later incorporated into MA law by the legislature.

In this case, B&W lost 8 hours of relevant medical records in a malpractice case.  There was no indication of intentional destruction.  This was an accident.  As penalty, B&W was ruled in default.  They could offer no defense.  All claims were awarded without question.  As a charitable hospital the damages were capped and their license to operate protected.  A for profit organization or doctor's practice would have their license subject to revocation.  One dissenting judge felt that this was too mild, and that B&W's record keeping practices should be reviewed and made part of their license renewal requirements.

PCAST may be unaware of the laws around record keeping.  In most commercial operations, record keeping rules are determined by the organization until a court issues a legal hold.  All medical records are subject to the equivalent of legal hold from the moment they are created.  They can only be deleted when allowed by law.  The medical provider is fully responsible for providing all medical records to a patient upon request.  Failure to do so can cost them their license, and will cost them an immediate default for any lawsuit where those records are relevant.

The diagram shown could work if it is entirely within one organization.  But if the user is in a different organization, it implies that the user has contracted with the DEAS to provide records management.  The user is 100% responsible if anything goes wrong in the DEAS, so these will be interesting contracts with staggering insurance requirements to cover the penalties for any record keeping errors.  If a doctor loses their license or a malpractice suit due to a record keeping problem, they will go after the DEAS insurance for compensation.

(All the above assumes that the data loss is un-intentional.  An intentional violation of these record keeping rules is a felony punishable by up to 5 years in jail.  But intentional violations are very rare.  Almost all lost record cases are un-intentional.)

In MA, the ethical issues of patient access to medical records for personal use, professional evaluations, second opinions, etc. are covered by the same laws.  The doctor or hospital can pay substantial fines and may lose their license if they lose records.

The users will also demand some extra capabilities from the DEAS.  It is the users that are responsible for providing records to patients upon request.  The users may have contracted with DEAS, but the patient deals with the user.   Again, this is a legal requirement consistent with the ethical demands for the doctor to provide patient information to the patient upon request.

Org-mode, documents, and XDS

I've created an org-mode date-tree for organizing my various documents. This leads to some thoughts on XDS, etc.

Org-mode stuff (skip this if you don't care much about org-mode)

• I've created a date-tree for these documents. 
• Each set of documents gets a headline, with whatever description, tags, and metadata I feel like adding.  This date-tree lives in my regular org files.  So I can now search for tags, concepts, dates, etc. to find headlines.  Then I can read the headlines, their descriptions, and their metadata in order to decide which documents I want to read.
• The attachments are in their own git archive.  I can make this work by having a different attachment directory in each of the .emacs files on each machine.  My first thought of using links in the file system failed because Windows XP does not support links.
• I still need to do extra manual work, but it's now tolerable.  I've created a temporary save area.  I detach the documents from an email into that save area.  I create a headline in the date-tree. The headline text includes key aspects from the email, if any, and a short description of the documents.  I then attach the documents from the temporary save area (which copies them into the org attachment directory) to the headline.  Finally, from time to time I empty the save area.
• The org attachments directory is outside the org tree so that my git sharing of org files doesn't pick up all the attachments too.  Those are managed separately, also by git sharing.  This lets me do things like put the attachments directory on a removable drive.  (This makes the org file vaguely like the XDS Registry, and the attachments kind of like an XDS Repository.)
• Attachments management is adjustable by machine.  On the Mac the nicest way to deal with them is to open the attachments directory for an entry, and then use Mac tools.  On the Linux and Windows, the easiest is to do directory management within emacs and open files from there.  (XDS folks can think of the attachments for a headline as being like a submission set.)
• I had to fix the ~/.mailcap on my Linux system to point the PDF relationship at "evince".  Emacs was opening the PDF files within an emacs buffer.  This works, but it's slow and has a lot fewer features.  It works by converting the PDF into a PNG and displaying that with image display tools.  That's not as good as a full function PDF viewer.  The Mac and PC already have PDFs pointed to the appropriate viewer.

Resulting thoughts on organizers and XDS

This raises some thoughts on the state of information organizers.  Most people still use something like Sharepoint with all of it's preconfiguration restrictions and rules.  Some use wikis, which don't have the tags, properties, and other metadata facilities of org.  (Most wikis also have a lot more problems with editing the content.  The good content editors are platform specific.)  There are various more sophisticated metadata management tools that do a better job with document management.

Org still has too many manual operations.  Properties, tags, etc. are good, but don't integrate well with ontology tools.  (On the other hand, org has no problems with multiple ontologies.)  Tags, etc. are at the level of headlines, so there can be inheritence and the like.  But this is all stuff that you need to set up for yourself.  So it's a tool for tool builders, not a tool for general users.

The potential is there to do all kinds of things since this is build upon a structurally aware lisp engine.  I think I could make this into an integrated XDS Registry/Repository if I felt like it.  The really hard part would be implementing all the SOAP crap and enforcing metadata rules.  Org's attitude toward metadata is "do whatever you want." Org tries to adapt as best it can.

My org approach doesn't have the XDS single registry viewpoint.  But that's because I'm accustomed to systems  and system designs that are normally "broken".  They are inconsistent in contents, etc. in that each different viewpoint may reflect a different set of updates and changes.  The processes exist to reconcile the changes, but there is no requirement to present a consistent or "accurate" viewpoint.

This kind of "it depends on where and when you look" is an inherent necessity for many operational environments.  Presenting a single view requires 100% connectivity, 100% functional, error free network and systems.  In some enterprise environments it is practical to achieve this, or close enough that people don't notice the failures. 

In telecoms management this is impossible.  Networks will have failures that partition the network.  The various parts must continue to operate and be managed based on what information is still available, and they must adapt to mergers, including reconciliation of conflicting information when merging.  In the largest of the networks that I was involved with we never had fully functional networks.  There was always a portion of the network that had failed.  There were always a few islands operating on their own while problems were being fixed.

Healthcare IT folks (like those involved with XDS) are still having real problems coming to grips with accepting a system design that is always "broken".  They don't realize that in healthcare  everything is always "broken" in that sense.  Patients don't provide full or consistent  information, so patient information is "broken".  Measurements are incomplete.  Diagnoses are really just working hypotheses to be tested.  Disease and health are constantly changing, so the recorded state is never correct.  It's like large networks.  You must proceed with incomplete, inconsistent, changing information.

With time they should come to grips with this.

 

Accounting systems matter in healthcare

Accounting theory is more important to healthcare than most people think.  A highly oversimplified example of a typical healthcare accounting decision illustrates this.

Consider a hospital that treats two diseases: A and B.  There are 2,000 cases per year of each.  There are two machines that can treat A and B.  Machine X costs $1,000,000 and can treat 5,000 cases per year of either disease.  Machine Y costs $100,000 and can treat 10,000 cases per year of disease B.

It's fairly clear that the lowest cost approach is to buy just machine X.  But, this will be challenged strongly by the cost accounting side.  Machine X costs $200/treatment of disease B, while machine Y costs only $10/treatment.  Clearly the hospital must be wasting money.

In this simplified case it's easy to explain why the cost accounting approach leads to the wrong decision.  But in the complexity of the real world this does lead to many wrong decisions.

Accounting has been used for thousands of years, and there are different kinds of accounting that are used for answering different questions.  The earliest accounting was simple inventory tracking.  This was in use thousands of years ago and continues to be useful.  It is used throughout healthcare to answer basic questions like "how many pills are in that bottle?".

The most common form of accounting for the overall hospital is the cost accounting system that was devised in the past century to answer basic questions like "should we lend them money? will they be able to make the payments?"  The accounting standards are uniform across most organizations because lenders and borrowers need to use the same accounting methods so that comparisons are valid.

Unfortunately, the cost accounting systems used to make operational decisions have been layered on top of these accounting systems with arbitrary allocations of costs.  These systems do not incorporate consideration of demand, capacity, or bottlenecks.  That is a severe problem.  You see this result in bad operational decisions in all sorts of manufacturing and service organizations.  Instead of rewarding decisions that eliminate bottlenecks and decisions that match capacity with demand, they reward decisions that match the arbitrary cost allocation rules.  In the simple example above, cost allocation would indicate that both machines X and Y should be purchased because cost allocation systems do not reflect the demand and capacity factors.

There are systems that attempt the include demand, capacity, and bottleneck effects.  One such is throughput accounting.  There are others.  Switching to this kind of accounting is a major change, but it will be needed to make the kinds of decisions that are needed to control healthcare costs.

org-weather report

I got org-google-weather working on my Linux system relatively easily.  Org-google-weather is a cute thing that adds a weather forecast to the agenda for each day.  (The link has a nice example.)  That was tonight's relaxation.

The Emacs URL management has too many problems to be useful on my laptops.  There is no easy way to detect whether the system has network connectivity at the moment.  There is no easy way to detect the current http proxy. The result is long long delays for timeouts on all the org agenda actions. Laptops are routinely on different proxy environments and different network connectivity.  It is not practical to constantly be changing emacs configurations.

This is a failing that's too big for me to tackle for a fun frill like this.  It's wrapped up in all sorts of system specific issues, since the laptops are Windows and MacOS systems.  Instead, the .emacs files on the laptops define org-google-weather to be a null function.  That way I can continue to use the same agenda files on desktop and laptops.