So. What do we know?
- role-based access control is required. To make it work properly in a
shared care community context (e.g. a hospital, 50 GPs, aged care homes,
nursing care, social workers etc etc) then the roles need to be defined
congruently. I seem to remember some Canadian project coming to the
conclusion that really the roles need to be defined the same across the
entire (national) health care system. I think this is both correct and a
the same time unrealistic.
With all due respect, Thomas, it it's unrealistic then, IMO, it can't be
correct. (Pragmatism R Us )
I'd like to offer food for thought. The fundamental assumption at work here
seems to be that care givers will access the same system, thus driving the
need for all users of the system to be assigned roles that are defined
congruently. Let's consider an alternative model.
When I travel from the U.S. to the U.K., I (the physical being) move from
one socio-cultural-legal model to another. That does not change who / what
I am, but it does change my behavior because I operate under a different set
of norms and mores in the new environment. I accept new forms of
interaction and find that familiar forms are no longer available.
Why should it be any different for the information about me than it is for
me?
If we work from a perspective that posits that health information will move
from system to system and be used / modified based on the rule sets in place
within the various systems, does that make the problem more amenable to
solution?
I think we will be able to find ways of
having diversely defined roles without every health care facility having
incompatible definitions of "consultant", "treating physician" etc.
Bernd's work on this area is pretty detailed.
I thank Bernd for opening my eyes to what should have been obvious to me at
a much earlier stage. The security problem with EHR systems is
fundamentally the same problem faced in OLAP databases. Or perhaps I should
say that it's the OLAP security problem with a twist. At least OLAP
databases are typically confined to one environment / business. It's clear
that the EHR problem is more difficult in that EHR's must, IMO, be capable
of moving between environments. Perhaps, by requiring a more generalized
solution, the EHR problem will actually be easier to solve.
I don't know if you've checked out Mike Mair's paper but it implicitly poses
a very interesting question. "Is a biologically-based security model
fundamentally better aligned with the needs of an information system about
biological entities than alternative models?" I'm hopeful the list will
have some comments on Mike's paper. I think the question is worth some
thought / discussion.
/snip/
Best regards,
Bill
-
If you have any questions about using this list,
please send a message to d.lloyd@openehr.org
Dear friends,
A crucial challenge for EHR security is the formalisation of policies and their rule-based but also interactive negotiation. This reflects some of the issues mentioned.
Formal policy modelling is a CEN workitem over many years. Meanwhile (due to time constraints by other businesses also this project takes years), the issues mentioned are also content of a common 3 part CEN and ISO standard on Privilege Management and Access Control Management.
Formal policy modelling and policy negotiation are essential aspect of the specification.
Most of the serious issues in EHR security are essentially ethical, not
legal, in nature.
When the NHS first introduced a nationwide Healthcare Network, the BMA
Ethics Committee advised all practitioners to put NO patient-related data
on it because it had not been PROVED that the network's security mechanims
could guarantee non-violation of the ethical principles governing access
to such data (see Anderson, R. A., Security in Clinical Information
Systems, BMA, 1996).
Of course, such a proof cannot be performed, not only because the
security mechanisms are not formally defined, but because the ethical
principles themselves are not formally stated.
In an attempt to overcome this obvious impasse, I prepared a tentative
formal definition of some of the dozen or so governing ethical principles
stated in the BMA document. Unfortunately, this met with a deafening
silence from both sides of the argument.
I suspect that something of this nature is still needed and that the need
for it cannot be admitted by any of the stakeholders. The latest round of
discussions of this group merely confirm that suspicion.
Those who are interested in this line of enquiry may care to read my
seven-year-old paper at http://www.soi.city.ac.uk/~bernie/hsp.pdf
The approach you have identified makes a lot of sense to me and goes a long ways toward clarifying “ownership” of the record. I do think it would be helpful to develop standard taxonomy for distinguishing the two: EMR signifying within a closed health care system, and EHR signifying the continuity of care record which is the property of the patient. It seems to me that if this distinction is not made, “ownership” is going to boil down to issues like “intellectual property.” The way I see it, ownership and access are two, separate, albeit, overlappying issues. Did I hear somebody mention Napster?
I must confess I didn’t read very carefully each message on this thread ;
however, I think that I may contribute by explaining the direction we are
currently following.
First I think we must distinguish between care coordination (inside an
openEHR node) and continuity of care.
Continuity of care means that you manage to index every contributions for
a single patient (these contributions can be openEHR contributions or other
systems contribution, or even data here and there).
The acces rules must be very different in both cases since :
inside a node (care coordination) the system belongs to the team and/or
the careplace (say it is a domain, maybe a meta-domain) and see patients
passing through (from in to out).
a continuity of care system necesseraly belongs to the patient (when you
consider a wide period of time, it is the only stable user) and see medical
teams passing through.
To adress this change of point of view (from a steady referential to a
moving referential), we are building a system with the following rules :
the continuity of care system is an index of existing contributions and
is granted access rights to the nodes
inside the continuity of care system, people that may access data are
given a position inside the patient “health team” : the position depends on
the people “job” (doctor, other health professional, family, social worker)
and depends on his “distance” from the patient (usual care giver vs unusual
one).
Hence the access rights to the contribution are determined for each
possible position and depends on the current role inside the personal halth
team at the very moment.
You can like the way we do it or not, however, I don’t think you can make
proper access rights if you don’t adress the issue of steady referential
(care coordination - or groupware) vs moving referential (continuity of
care - every episod of care for every care team).
Thanks for your post - I thought nobody took the time to read mine ;o)
I tried to keep my post in the range of openEHR, however, since you are pushing me one step further, I need to tell that, from my point of view, continuity of care is probably a step to cross, but not the ultimate goal.
Once you agree that the patient is the owner of a system (say the EHR in the taxonomy you are proposing), you have to ask yourself : "when, why and by who shall this system get used ?". If you think that Electronic Health Record is the right concept for continuity of care, it is probably because you realized that Health doesn't mean "no disease", and that even people with chronic disease are most often managing their health than they are subject of care.
The conclusion we made is that if the system belongs to the patient, it must be a tool for the person (and not only the patient). So, this very tool must be a he "health capital" manager. Since the system we are working on is problem oriented, and it allows to establish health objectives - and not only records, we called it : Individual Health Project.
Now the taxinomy is richer, with three acronyms EMR, EHR and IHP ;o)
Except that the Need-To-Know paradigm doesn't work very well
in healthcare. The provider may not know what she needs to
know at the time of the patient encounter. The patient can't
possibly correctly decide what her doctor must know in order
to be able to make the right decisions (of course, the patient
is fully able to decide what she *wants* the doctor to know).
Etc.
Medicine is neither the military nor a secret service, literally
(it's not mass media either, on the other end of the spectrum).
Just a clinician's muttering ...
Karsten
--
Karsten,
I agree and have concerns about being expected to take responsibility
without access to all the facts.
I suppose this may not be an issue as I suspect that most people won't
restrict the information in their file.
However, to fragment a medical file into bits I can and can't see is similar
to taking the view that mind and body are separate entities.
If something is restricted, will I know there is something there that I
can't see? Or will I be blisfully ignorant? How can I know if a piece of
information is irrelevant unless I can see it to assess it?
Fragmented records and securing individual and groups of records is a common
approach. It is very much like taking a 300 page document and building a
security system that enables security:
1)covering the entire document
2)separate security covering chapters and
3)separate security for tables, graphs and figures.
Access to the document is the first step; access to a specific chapter
requires separate authentication; access to tables, etc can require separate
authentication. This focuses a specific reader's requests to those portions
that are "relevant"/"germane".
"one authentication" systems, e.g., password to your windows PC or Linux
workstation are really ancient security systems. There are typically more
ways to break-in than log-in.
Recall than system and network managers are often the targets of security
probes because they can access your raw data at will; that may include your
sensitive data. If you grant access to the entire EHR for a Patient to
anyone successfully passing a "one authentication" gate you are likely to
experience some real "pushback". Your obligation as a designer is to ensure
that "relevance" and NEED TO KNOW are essential elements of the security
system and that a successful authentication carries with it an assurance
that the requestor is provided access to only "relevant"/"germane"
information.
You know I think it would be more productive to realize that the
granularity of access control differs from enterprise to enterprise, from
state to state and from culture to culture.
Trying to demand that openEHR support a specific level of granualrity
(e.g. transaction vs. entry vs. structured item) is too hard as it will
never please everybody. If anything openEHR should be agnostic about such
things and just say that there is a "security service" out there which
gives users "priveleges" and these priveleges tell the EHR what kind of
data a user can see. In some enterprises such priveleges might give access
to whole transactions and in others it suppress certain kinds of
information. The definition of how priveleges are interpreted should be
totally up to the implementing organization.
In our case for an application we are building we use priveleges to allow
users to see different "views" on transactions (e.g. an administrators
view vs. a clinicians view vs. a mental health care team member's view)
and the priveleges are assigned based on the user's role and patient
consent. However, I would not impose this scheme on anyone else unless it
worked well with their local enterprise requirements and culture.
What is the EHR OpenEHR is building?
What is the scope?
Is it a complete EHR system?
Or is it that part of the EHR system that stores health data and that
retrieves it?
I think it is the latter. The question of privacy to answer boils down to:
What elements in the domain model for the EHR do we need (need to store and
transmit) in order for an other part of the system perform the access
control function?
The second question is: Access control needs Audit trails; which information
elements are necessary in the domain model for the audit trail function to
work.
These two questions are not to difficult to answer.
In other words: the OpenEHR can assume that the Access Control function
operates as if it is a fire wall that executes a set of rules and that the
Audit trail is the log with violations (Exceptions) the fire wall had to
grant.
The operation of the 'firewal' and audit trail are outside the scope of Open
EHR.
Gerard
Hi Guys,
You know I think it would be more productive to realize that the
granularity of access control differs from enterprise to enterprise, from
state to state and from culture to culture.
Trying to demand that openEHR support a specific level of granualrity
(e.g. transaction vs. entry vs. structured item) is too hard as it will
never please everybody. If anything openEHR should be agnostic about such
things and just say that there is a "security service" out there which
gives users "priveleges" and these priveleges tell the EHR what kind of
data a user can see. In some enterprises such priveleges might give access
to whole transactions and in others it suppress certain kinds of
information. The definition of how priveleges are interpreted should be
totally up to the implementing organization.
In our case for an application we are building we use priveleges to allow
users to see different "views" on transactions (e.g. an administrators
view vs. a clinicians view vs. a mental health care team member's view)
and the priveleges are assigned based on the user's role and patient
consent. However, I would not impose this scheme on anyone else unless it
worked well with their local enterprise requirements and culture.
cheers, Andrew
Hi Matt,
Fragmented records and securing individual and groups of records is a common
approach. It is very much like taking a 300 page document and building a
security system that enables security:
1)covering the entire document
2)separate security covering chapters and
3)separate security for tables, graphs and figures.
Access to the document is the first step; access to a specific chapter
requires separate authentication; access to tables, etc can require separate
authentication. This focuses a specific reader's requests to those portions
that are "relevant"/"germane".
"one authentication" systems, e.g., password to your windows PC or Linux
workstation are really ancient security systems. There are typically more
ways to break-in than log-in.
Recall than system and network managers are often the targets of security
probes because they can access your raw data at will; that may include your
sensitive data. If you grant access to the entire EHR for a Patient to
anyone successfully passing a "one authentication" gate you are likely to
experience some real "pushback". Your obligation as a designer is to ensure
that "relevance" and NEED TO KNOW are essential elements of the security
system and that a successful authentication carries with it an assurance
that the requestor is provided access to only "relevant"/"germane"
information.
-Thomas Clark
From: "Matt Evans" <mge@totalise.co.uk>
To: <openehr-technical@openehr.org>
Sent: Thursday, May 01, 2003 2:30 PM
Subject: FW: openEHR security; Directed to Thomas Beale
[...]
At all points NEED TO KNOW
governs access
[...]
Except that the Need-To-Know paradigm doesn't work very well
in healthcare. The provider may not know what she needs to
know at the time of the patient encounter. The patient can't
possibly correctly decide what her doctor must know in order
to be able to make the right decisions (of course, the patient
is fully able to decide what she *wants* the doctor to know).
Etc.
Medicine is neither the military nor a secret service, literally
(it's not mass media either, on the other end of the spectrum).
Just a clinician's muttering ...
Karsten
--
Karsten,
I agree and have concerns about being expected to take responsibility
without access to all the facts.
I suppose this may not be an issue as I suspect that most people won't
restrict the information in their file.
However, to fragment a medical file into bits I can and can't see is
similar
to taking the view that mind and body are separate entities.
If something is restricted, will I know there is something there that I
can't see? Or will I be blisfully ignorant? How can I know if a piece of
information is irrelevant unless I can see it to assess it?
More mutterings!
Matt
-
If you have any questions about using this list,
please send a message to d.lloyd@openehr.org
-
If you have any questions about using this list,
please send a message to d.lloyd@openehr.org
In other words: the OpenEHR can assume that the Access Control function
operates as if it is a fire wall that executes a set of rules
and that the
Audit trail is the log with violations (Exceptions) the fire wall had to
grant.
The operation of the 'firewal' and audit trail are outside the scope of
Open
EHR.
While I support the concept of seperating the access control functionality
from the storage / retrieval functionality, I'm afraid I have to disagree,
with all due respect, to the segregation of the audit trail and to what I
understand your definition of what needs to be contained in the audit trail.
The notion that the audit trail only log exceptions will be a non-starter
here in the U.S., I think. The "appropriateness" of an access to a record
can only be determined ex post facto in many cases. An example may help.
Suppose a nurse prints a copy of one of her patient's records during her
shift. Is this appropriate access? On it's face, at the time of access, it
would appear so. Suppose further, though, that the nurse later sells that
copy to a third party who uses it to the patient's disadvantage. Now it's
clear that the access was for inappropriate purposes. No system can
pre-judge intent. If the access is not logged, there will be no trail to
the event that led to the inappropriate disclosure and the system will have
contributed to the patient's disadvantage. Further, unless the list of
accesses is maintained as part of the EHR, there's no guarantee that the
patient will have access to that information. Thus, I believe the audit
trail functionality must be "in scope" for openEHR, at least to the extent
that the group intends it to be viable here in the U.S..
The following information must be added to get a fuller picture of how I
envisage things:
-0- The context for my remarks is the discourse, using human and computer
processable documents, between health professionals over time and space. My
context is not updating databases using messages.
-1- Electronic systems must provide at least the same quality in all aspects
when compared with paper based systems. The quality can be better but never
less.
-2- Of course persons entering the system are logged
-3- And only information is readily available to which one has rightful
access because one is working in the same department the patient is in.
All access to the information will not be logged in the audit trail.
(paper based systems don't record where the eyes hit the paper and ink)
I assume a high degree of social control in a department.
-4- Audit trails in the sense that is recorded why, what, when, from where,
by whom has used the exception path to reach information are needed when the
requestor is overruling the access controls.
-5- the preferred way of obtaining information must stay (as it always was)
direct contact between health professionals either orally or by writing.
My fear is that because anything can be recorded and tracked or traced we
feel obliged to do so in the electronic domain.
Example: The Data Registrars Office in the Netherlands is of the opinion
that access to electronic medical records can be granted only by using two
ways authentication (password AND biometrics) The only justification is that
it is possible. But it is unaffordable and to complex to organise in the
healthcare domain)
-- <private> --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands
> > BW: Further, it looks like the EHR access history should include reads as well as writes. That way, the trail would lead to the providers that have, with permission, made copies of the EHR within their own systems.
> SH: True - it will only be able to be stored as an HTML rendition unless there is an extract in openEHR - but you are right - this could be saved - this is difficult to police.
Oops! I'd assumed there would be extracts in openEHR. HIPAA specifies, under the Transaction Rules that go into effect in October of this year, a number of EDI transactions between systems that would require this. HTML will not be sufficient.
Can anyone clarify this bit of the debate - I have lost track of what is being said here!
I'm taking this to mean that there will be configurable permissions on type of access. Yes?
yes - probably quite sophisticated ones.
> SH: Research access will be via the kernel with an approved program unless it is one-to-one reading of records when the patient's consent is required anyway.
Hmmm.... Again, perhaps a difference at the national level. Research here is the U.S. typically requires extracted data to be transferred from a physician's system to the research organization's system.
both scenarios are equally ok. I would also have expected the one Bill mentions to be more likely - especially as data transformation and anonymisatino are often needed.
>Hi Thomas,
>
>Thomas Beale wrote:
>
>>So. What do we know?
>>- role-based access control is required. To make it work properly in a
>>shared care community context (e.g. a hospital, 50 GPs, aged care homes,
>>nursing care, social workers etc etc) then the roles need to be defined
>>congruently. I seem to remember some Canadian project coming to the
>>conclusion that really the roles need to be defined the same across the
>>entire (national) health care system. I think this is both correct and a
>>the same time unrealistic.
>>
>
>With all due respect, Thomas, it it's unrealistic then, IMO, it can't be
>correct. (Pragmatism R Us )
>
>I'd like to offer food for thought. The fundamental assumption at work here
>seems to be that care givers will access the same system, thus driving the
>need for all users of the system to be assigned roles that are defined
>congruently. Let's consider an alternative model.
>
when I wrote "health system" above, I meant the whole health delivery
system in a country or region, not literally an information system.
>
>When I travel from the U.S. to the U.K., I (the physical being) move from
>one socio-cultural-legal model to another. That does not change who / what
>I am, but it does change my behavior because I operate under a different set
>of norms and mores in the new environment. I accept new forms of
>interaction and find that familiar forms are no longer available.
>
>Why should it be any different for the information about me than it is for
>me?
>
exactly right. So many aspects of security, care process, what
archetypes are used etc will change.
>If we work from a perspective that posits that health information will move
>from system to system and be used / modified based on the rule sets in place
>within the various systems, does that make the problem more amenable to
>solution?
>
I think this is our base assumption. All I wanted to say above is that
access control rules somehow have to deal with the varying definitions
of same-named roles across widely differing jurisdictions.
I like Mike's paper too, I need to give it more thought.
>
> > > BW: Further, it looks like the EHR access history should include
> reads as well as writes. That way, the trail would lead to the
> providers that have, with permission, made copies of the EHR within
> their own systems.
>
> > SH: True - it will only be able to be stored as an HTML rendition
> unless there is an extract in openEHR - but you are right - this could
> be saved - this is difficult to police.
>
> Oops! I'd assumed there would be extracts in openEHR. HIPAA
> specifies, under the Transaction Rules that go into effect in October
> of this year, a number of EDI transactions between systems that would
> require this. HTML will not be sufficient.
Can anyone clarify this bit of the debate - I have lost track of what is
being said here!
>
> I'm taking this to mean that there will be configurable permissions on
> type of access. Yes?
yes - probably quite sophisticated ones.
> > SH: Research access will be via the kernel with an approved program
> unless it is one-to-one reading of records when the patient's consent
> is required anyway.
>
> Hmmm.... Again, perhaps a difference at the national level. Research
> here is the U.S. typically requires extracted data to be
> transferred from a physician's system to the research organization's
> system.
both scenarios are equally ok. I would also have expected the one Bill
mentions to be more likely - especially as data transformation and
anonymisatino are often needed.
Good list of requirements. My question concerns contact between Healthcare
Practitioners and others which may include geographically remote locations
and roving, e.g., in-hospital via wearable or hand-held units. This contact
would extend beyond that of the Practitioner-Patient.
A good example would be Remote Surgery with requirements that amount to
secure, continuous audio/visual connections. Another would be my clinic
where they have migrated to computer systems within the exam room and at
other points of contact.
If a process, procedure, technology is already in use would it be integrated
within the OpenEHR scope, requirements, goals and implementation? Judging
from the difficulty getting something implemented it would seem that
somewhere, sometime someone was able to justify the project and get it
implemented.
Bill Walton wrote:
>
> > > BW: Further, it looks like the EHR access history should include
> reads as well as writes. That way, the trail would lead to the
> providers that have, with permission, made copies of the EHR within
> their own systems.
>
> > SH: True - it will only be able to be stored as an HTML rendition
> unless there is an extract in openEHR - but you are right - this could
> be saved - this is difficult to police.
>
> Oops! I'd assumed there would be extracts in openEHR. HIPAA
> specifies, under the Transaction Rules that go into effect in October
> of this year, a number of EDI transactions between systems that would
> require this. HTML will not be sufficient.
Can anyone clarify this bit of the debate - I have lost track of what is
being said here!
I was inquiring about the audit trail capabilities intended to be
incorporated in v1.0 of openEHR and Sam was very graciously trying to
enlighten me. His commment re: HTML made me expand the question to
extracts. I'm not sure I was sufficiently clear about my line of
questioning, and comments by others make me wonder whether or not I should
take this off-line. I am specifically trying to ascertain the applicability
of openEHR to the emerging requirements here in the U.S. and do not wish to
infringe on the group's bandwidth if there is a less intrusive way to handle
my questions. Please let me know how you'd like me to proceed. And thank
you all for your patience to date.
There a many other products that will provide the same sort of Secure
Message Delivery as well. (HIPPA ain't an insignificant piece of work, but
hey, they might not have it right....)
Guys,Don't get bogged down in the technical detail, define the business
process and rules first, and the rest will follow.
I forgot I had set up an inbox rule for posts from this forum so have
probably missed the last 40 or more posts. Will have to go back through them
all to see exactly what has been covered.
Thank you for your useful description.
I had meant to put my case as a clinican but as this is the 'technical'
forum I don't know if it was the right place.
I agree that the described approach makes sense and offers a great deal of
customsation regarding access. What I am concerned about, I suppose, is how
the system will be implemented. These concerns stem from some examples I
have heard - for instance an orthopaedic surgeon only requiring information
to perform an operation. Perhaps this is an inaccurate example?
My viewpoint is that I spend up to an hour when assessing a patient
carefully extracting as much information as possible. My colleagues rely on
the thoroughness of this information to look after this patient. We also
rely on full access to the entire medical record (ever recorded) in order to
safely and holistically care for our patients. I would hope I would have
full access to the medical record in order to fulfill my clinical
responsibilities.
In my field, it is not unusual for patients to either provide unreliable
details or to conceal facts. We often rely on recorded facts rather than
what we are told. In these circumstances I have concerns about the patient's
right to keep private parts of their records. I believe that the suggestion
that a patient may essentially exclude sections of their notes from viewing
represents a major shift in the way we work. I would also argue that it's
difficult for a patient to know when this concealment may put themself or
others at risk.
Is the intended approach that the viewer would know there was information
that they could not view or that it is simply hidden?
TITLE: "... and open-source Electronic Data Interchange"
NOTES:
-"... SolAce Server was designed to do reliable, secure messaging in
compliance with the HIPAA Security Rule ..."
-written in Java
-Thomas Clark
From: "Bill Walton" <bill.walton@jstats.com>
To: <openehr-technical@openehr.org>; "Thomas Beale"
<thomas@deepthought.com.au>
Sent: Sunday, May 04, 2003 8:14 PM
Subject: Re: Access controls and Audit trails (was Re: openEHR security)
> Hi Thomas,
>
> Thomas Beale wrote:
> >
> > Bill Walton wrote:
> > >
> > > > > BW: Further, it looks like the EHR access history should
include
> > > reads as well as writes. That way, the trail would lead to the
> > > providers that have, with permission, made copies of the EHR within
> > > their own systems.
> > >
> > > > SH: True - it will only be able to be stored as an HTML rendition
> > > unless there is an extract in openEHR - but you are right - this
could
> > > be saved - this is difficult to police.
> > >
> > > Oops! I'd assumed there would be extracts in openEHR. HIPAA
> > > specifies, under the Transaction Rules that go into effect in
October
> > > of this year, a number of EDI transactions between systems that
would
> > > require this. HTML will not be sufficient.
> >
> > Can anyone clarify this bit of the debate - I have lost track of what
is
> > being said here!
>
> I was inquiring about the audit trail capabilities intended to be
> incorporated in v1.0 of openEHR and Sam was very graciously trying to
> enlighten me. His commment re: HTML made me expand the question to
> extracts. I'm not sure I was sufficiently clear about my line of
> questioning, and comments by others make me wonder whether or not I
should
> take this off-line. I am specifically trying to ascertain the
applicability
> of openEHR to the emerging requirements here in the U.S. and do not wish
to
> infringe on the group's bandwidth if there is a less intrusive way to
handle
> my questions. Please let me know how you'd like me to proceed. And
There a many other products that will provide the same sort of Secure
Message Delivery as well. (HIPPA ain't an insignificant piece of work,
but
hey, they might not have it right....)
I'll be checking into it. The test phase for HIPAA compliance re: the
Transaction Rules has just started and should yield some publicly available
information in short order.
Guys,Don't get bogged down in the technical detail, define the business
process and rules first, and the rest will follow.
HHS (Dept.of Health and Human Services of the U.S. Food and Drug
Administration) has, through the promulgation of the HIPAA Privacy Rule
(compliance date of 4/14/03), Transaction Rule (compliance date of
10/16/03), and Security Rule (compliance date of 4/20/05) defined a new set
of business rules for Health care providers, plans, and clearinghouses here
in the U.S.. The new rules are seen by practioners as introducing new costs
and risks in a business that's already under attack on many fronts. If
automation emerges that can help them reduce the costs and risks, the
likelihood is that they'll adopt it quickly. This is being viewed as an
important opportunity by EHR vendors, one that could see the rapid and
widespread adoption of EHR systems. IMO, it's an even larger opportunity
for the open source community given the financial pressures the provider
community are already under. So now it's time to see if we're up to the
task.
)