EMR EBM EBMgmt

[patrick blanchard-2]

patrick blanchard wrote:
> The short list:
> I think version control may be useful for Electronic Medical Records
> (EMR), and improving patient care by linking Evidenced Based Medicine
> (EBM) and Evidence Based Management (EBMgmt). Do you?
Thomas Lord wrote:

My answer is "Yes, but...."

...snip...

The "But" part is that we have a "category problem".   Revision control
offers all the great things listed in the previous paragraph, and more,
but....   so does the category "global distributed file system".    And,
really, neither of those categories intrinsically begins to address (or
even make a good framework for addressing) the domain-specific data
types we expect in PHRs.

So, "version control may be useful" but that may not be the most
immediately useful way to look at it.   Maybe we want a versioning file
system, for example.   And, anyway, the particular nature of the data
has to be discussed.

Stay tuned.   I'm working on defining a new category.

Unless I am missing something, domain-specific data types in medicine are not any different than CMS. Ok, so they might have a different tag, but that's all.

I don't think the catagory problem is really a problem after all, unless you want to start storing voxel image in a 3d array. If the data type is kept 2d, then Perl can sort out the minutia, while Arch can do the bird's eye view of data changes. It might work w/ a medical specific markup language similar to HTML. ...just some thoughts. CGI can make it presentable to the enduser. I'll bet what you have already will take this 90% of the way, and surpass 100% of the EMRs on the market.

_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@...
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/

[Thomas Lord]

patrick blanchard wrote:

Unless I am missing something, domain-specific data types in medicine are not any different than CMS. Ok, so they might have a different tag, but that's all.

The key thing to consider is that CMS systems mostly deal with files of source code.   The syntax of most programming languages is such that a revision control system for CMS can treat those source files as a "list of lines" -- a sequence of strings, one string per line.  For example, if someone saves a change to a file, the revision control system can usefully think about that change in terms of "what lines were added to this file and which were deleted?".   Another example:  a revision control system for CMS usefully includes a feature like "find me all of the lines of code that contain the string X" or "tell me all of the changes that have been made to this line of code".

In a PHR, that "line-oriented" view of changes is less obviously useful.    You might want to know the history of changes to the patient's weight record, for example.   Well, don't you want to be able to ask "How has the 'weight' field on this chart changed, over time" rather than having to phrase the same question in ad hoc terms like "How have lines 10-15 of file X changed, over time"?

I don't think the catagory problem is really a problem after all, unless you want to start storing voxel image in a 3d array. If the data type is kept 2d, then Perl can sort out the minutia, while Arch can do the bird's eye view of data changes. It might work w/ a medical specific markup language similar to HTML. ...just some thoughts. CGI can make it presentable to the enduser. I'll bet what you have already will take this 90% of the way, and surpass 100% of the EMRs on the market.

I can't speak to the real world problem that you are trying to solve, right now.   You know that problem -- I don't.   If Arch in its current state is just what the doctor ordered (sorry :-), go for it.   I just think that the "leap-frog" plays in EMRs/PHRs is -- well, similar to Arch but also similar to file systems, git, and a few other things;   and that the leap-frog play makes it possible to handle data (like "weight" vs. "line 10 of file x") with semantic precision.

-t


_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@...
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/

[Mitch Amiano]

Thomas, Patrick, forgive me for butting in but when you toss in an
acronym that has almost become a cliché like CMS, I felt the need to
comment on that and a bit more.

There exists a general market (and a size-able one at that) for content
management systems which do not deal with code "source as lines of text"
as it were, but rather as networks of elements inserted as XML. The XML
provides tree structures through various interfaces, mostly but not only
document editing interfaces. A quick look at
http://xml.coverpages.org/healthcare.html shows a plethora of activity
in this area.

The value to the user, if I can read into Thomas' response, is the
ability to use the system to query and retrieve on the basis of the
structures, not just to store and seal it.

DITA, a layered XML standard, provides topical organization and an
ability to impose a class-hierarchy semantic on the tag labels. DITA
exist for asserting domain-specific data types on structured elements.  
The existing DITA open source toolkit is generally aimed at technical
documentation, so it provides a code base to leverage for generating
printed and Web based outputs. However, I think that a lot of the XML
compliance focus is on HL7. Therefore, my strategy would be to first
evaluate if a part of HL7 could be used effectively, and if there are
open source components to leverage for it. Then possibly bridge it to
DITA to get a publishing front end, and look at the storage/retrieval
interfaces and querying system.

Doesn't a HIPAA compliant system also have to restrict access on the
basis of roles and privileges? So you'll need some sort of access
control lists or other security controls to even get in the door.

One last comment - where's the money for it going to come from?



Thomas Lord wrote:

> patrick blanchard wrote:
>>
>> Unless I am missing something, domain-specific data types in medicine
>> are not any different than CMS. Ok, so they might have a different
>> tag, but that's all.
>
>
> The key thing to consider is that CMS systems /mostly/ deal with files
> of source code.   The syntax of most programming languages is such
> that a revision control system for CMS can treat those source files as
> a "list of lines" -- a sequence of strings, one string per line.  For
> example, if someone saves a change to a file, the revision control
> system can usefully think about that change in terms of "what lines
> were added to this file and which were deleted?".   Another example:  
> a revision control system for CMS usefully includes a feature like
> "find me all of the lines of code that contain the string X" or "tell
> me all of the changes that have been made to this line of code".
>
> In a PHR, that "line-oriented" view of changes is less obviously
> useful.    You might want to know the history of changes to the
> patient's weight record, for example.   Well, don't you want to be
> able to ask "How has the 'weight' field on this chart changed, over
> time" rather than having to phrase the same question in ad hoc terms
> like "How have lines 10-15 of file X changed, over time"?
>
>
>>
>> I don't think the catagory problem is really a problem after all,
>> unless you want to start storing voxel image in a 3d array. If the
>> data type is kept 2d, then Perl can sort out the minutia, while Arch
>> can do the bird's eye view of data changes. It might work w/ a
>> medical specific markup language similar to HTML. ...just some
>> thoughts. CGI can make it presentable to the enduser. I'll bet what
>> you have already will take this 90% of the way, and surpass 100% of
>> the EMRs on the market.
>
> I can't speak to the real world problem that you are trying to solve,
> right now.   You know that problem -- I don't.   If Arch in its
> current state is just what the doctor ordered (sorry :-), go for it.  
> I just think that the "leap-frog" plays in EMRs/PHRs is -- well,
> similar to Arch but also similar to file systems, git, and a few other
> things;   and that the leap-frog play makes it possible to handle data
> (like "weight" vs. "line 10 of file x") with semantic precision.
>
> -t
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Gnu-arch-users mailing list
> Gnu-arch-users@...
> http://lists.gnu.org/mailman/listinfo/gnu-arch-users
>
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/

_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@...
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/

[Thomas Lord]

Mitch Amiano wrote:
> There exists a general market (and a size-able one at that) for
> content management systems which do not deal with code "source as
> lines of text" as it were, but rather as networks of elements inserted
> as XML. The XML provides tree structures through various interfaces,
> mostly but not only document editing interfaces. A quick look at
> http://xml.coverpages.org/healthcare.html shows a plethora of activity
> in this area.

I agree about that market and thank you for the link to what looks a
useful resource.


>
> The value to the user, if I can read into Thomas' response, is the
> ability to use the system to query and retrieve on the basis of the
> structures, not just to store and seal it.
>

That's an example of a benefit to the user.    Other benefits of an
XML-based format include:  exchange formats "for free", directly
executable data type (aka schema) definitions (also in XML), generic
stores and processors, etc.   I realize that that list starts to sound
more like "benefits to the programmer" rather than "benefits to the
user" so, another way to say it is that XML-based approaches give
customers a lot of liberty to invent new database structures because,
from just a definition of the new structure, the customer can get a
working database, working exchange format, and to some extent a working
UI pretty much "for free".

The medical record standardization efforts you link to above are a good
example:   domain experts in medicine concentrate on applying their
knowledge to things like translating a paper Continuity of Care form
into an XML type.    Increasingly, we should expect the results of such
efforts to be more and more "directly executable" -- those guys are
doing the heavy lifting of writing entirely new applications.



> Doesn't a HIPAA compliant system also have to restrict access on the
> basis of roles and privileges? So you'll need some sort of access
> control lists or other security controls to even get in the door.

It's even worse than that.   To really get anywhere you not only access
controls based on roles and privileges, but you need to innovate a
little bit about how to implement those.    The problem is that, as an
industry, health care needs to learn to maintain widely distributed,
portable records.   Yet, during transport from one end-use to another,
we should expect this data to pass through plenty of untrusted
processes.    Therefore, I predict (not very boldly -- it's obvious),
that standards for encrypting XML content,  standards for signing XML
content, standards for distributed management of "identity", and
standards for managing public cryptography keys are going to become very
important in the near future.


> One last comment - where's the money for it going to come from?

Are you asking me or Patrick?


Health records are not my primary focus -- I'm aiming for a bigger
target with health records as a potentially tasty application.  I'm
doing "lower level" work that "enables" stuff like health record
applications.

My plan, such as it is, is to try to make money "on the margins" of a
distributed, anarchic build-out of an important new open source
technology.   Right now, the work I'm doing is an investment being made
by fiance and I -- I leverage some of this work for my part-time day job
and we invest some of our household income in my spending plenty of
additional time on this "practical research".  I think that when I
"release early" the open source results,  astute people in the open
source community will likely want to use the code, probably fork it and
improve it on their own, turn into direct-to-customer products of their
own, etc.  By making money "on the margins" I mean that I intend to
charge small amounts for the download of some (GPLv3) components, charge
for documentation downloads, charge for a la carte consultations,
etc.    That's chump change per transaction but, for a family business,
chump change can quickly add up.    Of course, I'll also keep my eyes
open for unique direct-to-customer niches that, by luck, I'm the best
positioned to pounce on, build some equity, sell a company (or just
operate one), and "win big".

This being open source, the "big" investment building out this new
technology is likely to occur (if it does at all, knock on wood), in a
distributed, incremental way.    My job as an open source researcher is
basically just to create the "frame" -- to create the new market for
that incremental, distributed investment by "shaping" the technology the
right way.


-t





_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@...
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/

[patrick blanchard-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

On 8/14/07, Thomas Lord <lord@...> wrote:

Mitch Amiano wrote:
> There exists a general market (and a size-able one at that) for
> content management systems which do not deal with code "source as
> lines of text" as it were, but rather as networks of elements inserted
> as XML. The XML provides tree structures through various interfaces,
> mostly but not only document editing interfaces. A quick look at
> http://xml.coverpages.org/healthcare.html shows a plethora of activity
> in this area.

I agree about that market and thank you for the link to what looks a
useful resource.

pb:
yes, although I have not dug to the root of the initiative, and any potential bias (but http://xml... is my first clue). As a Fellow of AAFP, the first link I read was here: http://xml.coverpages.org/healthcare.html#ccr

specifically, some highlights:

The Continuity of Care Record (CCR) is a core data set of the most relevant and timely facts about a patient's healthcare.

Data sets for extensions of the CCR to address such areas as clinical specialties and disease management are not included in the specification.

Whether this initiative has the support of other standards bodies and potential primary and secondary users or if it can be aligned with other efforts, such as the EHR Functional Model, open EHR, the HL7 CDA and so forth remains to be seen.

From my experience, working on the 'core data set' is missing from most if not all EMRs. Many promised it would happen, but it has not yet materialized. EMRs utilizing RDBs are working from the top down and have not yet reached bedrock.

>
> The value to the user, if I can read into Thomas' response, is the
> ability to use the system to query and retrieve on the basis of the
> structures, not just to store and seal it.
>

That's an example of a benefit to the user.    Other benefits of an
XML-based format include:  exchange formats "for free", directly
executable data type (aka schema) definitions (also in XML), generic
stores and processors, etc.   I realize that that list starts to sound
more like "benefits to the programmer" rather than "benefits to the
user" so, another way to say it is that XML-based approaches give
customers a lot of liberty to invent new database structures because,
from just a definition of the new structure, the customer can get a
working database, working exchange format, and to some extent a working
UI pretty much "for free".

The medical record standardization efforts you link to above are a good
example:   domain experts in medicine concentrate on applying their
knowledge to things like translating a paper Continuity of Care form
into an XML type.    Increasingly, we should expect the results of such
efforts to be more and more "directly executable" -- those guys are
doing the heavy lifting of writing entirely new applications.

pb:
Lawrence Weed first published a paper on EMRs in the late 60s.

WEED LL.
MEDICAL RECORDS, PATIENT CARE, AND MEDICAL EDUCATION.
Ir J Med Sci. 1964 Jun;17:271-82. No abstract available.
PMID: 14160426 [PubMed - indexed for MEDLINE]

Later, he wrote a book Medical records, medical education, and patient care;: The problem-oriented record as a basic tool- I read it cover to cover in 1992. In the book, he gave fresh perspective on the linking of medical literature to the patient in the office in front of the physician. Today, he is founder of www.pkc.com

However, there still is not a EMR capable of 'linking' knowledge. Proprietary code and profiteering prevent real progress envisioned by Dr. Weed. I paid a consultant to link www.pubmed.gov w/ a website in my office - because I didn't know how to do it. It works and I think is the information gathering arm of the 2 armed beast of knowledge coupling. But, it remains unlinked from the EMR I was using.

> Doesn't a HIPAA compliant system also have to restrict access on the
> basis of roles and privileges? So you'll need some sort of access
> control lists or other security controls to even get in the door.

It's even worse than that.   To really get anywhere you not only access
controls based on roles and privileges, but you need to innovate a
little bit about how to implement those.    The problem is that, as an
industry, health care needs to learn to maintain widely distributed,
portable records.   Yet, during transport from one end-use to another,
we should expect this data to pass through plenty of untrusted
processes.    Therefore, I predict (not very boldly -- it's obvious),
that standards for encrypting XML content,  standards for signing XML
content, standards for distributed management of "identity", and
standards for managing public cryptography keys are going to become very
important in the near future.

pb:
Security innovations are as old as the hills, but became a software problem when computers developed the capability of partitioning user information (R. Stallman knows this better than anyone).

In the 'real world' trenches of medicine, security of a properly configured LAMP server surpasses "paper" and all EMRs. Security is not the EMR's role, although they think it is. Although GNU/Arch may not provide the security level needed, proper configuration of the LAMP server hosting GNU/Arch can provide more than enough security for HIPPA, and plenty more. In fact, a LAMP server will probably raise the bar for HIPPA as to computer security. IME, opening a MS server to the internet for tech support is risky. Most RDB companies provide their service accross the internet (and it's a booming business). MS Windows is a terrible security risk and I know if first hand. In 2002, tech support logged in and infected my network w/ nimda. I never found the smoking gun, but it was a wakeup call as to what HIPPA really means for binary data; nothing. Frankly, HIPPA amounts to nothing more than simply verifying the user and restricting roles. That's old school for LAMP. HIPPA is not a deal breaker for GNU/Arch.

from the CCHIT website:

CCHIT was founded in 2004 with support from three leading industry associations in healthcare information management and technology - The American Health Information Management Association (AHIMA), the Healthcare Information and Management Systems Society (HIMSS) and The National Alliance for Health Information Technology (Alliance). In September 2005, CCHIT was awarded a contract by the U.S. Department of Health and Human Services to develop, create prototypes for, and evaluate the certification criteria and inspection process for EHRs and the networks through which they interoperate. More information on CCHIT and a list of CCHIT Certified products is available at www.cchit.org.

> One last comment - where's the money for it going to come from?

Are you asking me or Patrick?


Health records are not my primary focus -- I'm aiming for a bigger
target with health records as a potentially tasty application.  I'm
doing "lower level" work that "enables" stuff like health record
applications.

My plan, such as it is, is to try to make money "on the margins" of a
distributed, anarchic build-out of an important new open source
technology.   Right now, the work I'm doing is an investment being made
by fiance and I -- I leverage some of this work for my part-time day job
and we invest some of our household income in my spending plenty of
additional time on this "practical research".  I think that when I
"release early" the open source results,  astute people in the open
source community will likely want to use the code, probably fork it and
improve it on their own, turn into direct-to-customer products of their
own, etc.  By making money "on the margins" I mean that I intend to
charge small amounts for the download of some (GPLv3) components, charge
for documentation downloads, charge for a la carte consultations,
etc.    That's chump change per transaction but, for a family business,
chump change can quickly add up.    Of course, I'll also keep my eyes
open for unique direct-to-customer niches that, by luck, I'm the best
positioned to pounce on, build some equity, sell a company (or just
operate one), and "win big".

This being open source, the "big" investment building out this new

technology is likely to occur (if it does at all, knock on wood), in a
distributed, incremental way.    My job as an open source researcher is
basically just to create the "frame" -- to create the new market for
that incremental, distributed investment by "shaping" the technology the
right way.


-t

pb
I hope you join in... https://sourceforge.net/projects/medsystemsgnu/ , or at least lob some advice when you see me struggle.

5 years ago I dropped 8k into Praxis EMR www.infor-med.com with the understanding that I would be provided 'lifetime' support. For me, that meant 25 years of practice before retirement. That 'lifetime' support has been shifting horizons for the last 24 months and 2 weeks ago, after a hard crash of a dual AMD64 running 4GB, MSwindows server, I was locked out of 5 years worth of patient information. Without getting into the nasty details, I informed my staff to utilize PraxisEMR only for archiving information, and sent the following email to the company..

Hello Mr. Gutierrez,

I am using Praxis only for retrieving archived data and have returned to paper charts again.

Unfortunately, Praxis does not have the capability of printing the entire chart at once; it never has and continues to crash (softly now) when more than one visit is selected for printing. So, as we require the information, it is carefully selected from Praxis and printed for the new paper chart.

As you know, I have over 5 years of paient information archived in Praxis.

Your suggestions for developing a successful exit strategy from Praxis would help.

Thank you,

Patrick Blanchard, M.D.
Board Certified in Family Medicine
Fellow, American Academy of Family Practice


-----Original message-----
From: "Martin Gutierrez" marting@...
Date: Mon, 06 Aug 2007 08:32:07 -0500
To: pbmd1@...
Subject: praxis don't open

> Dear Doctor Blanchard,
>
>  
>
> By the time our team got to your practice, your office was closed.
>
>  
>
> Please have your staff call us at 818 592 2900. We'll like if you could
> restart Client 32 on your server and let us know, so we can log in an check
> how is running after the last recovery
>
>  
>
> Warmest Regards,
>
>  
>
> Martin Lucas Gutierrez
> Director of Customer Support
> Infor-Med Corporation
> 6271 Variel Avenue, Suite A
> Woodland Hills, California 91367-2512, USA
> Phone:  [phone]
> Email: <Marting@...>
> URL:  http://www.infor-med.com < http://www.infor-med.com/>
>
>  

So, no response, and I don't really expect one, and I'm on my own. Where is the 'lifetime' support?'.

As to my business, it's like yours Thomas, and I hope you the best. Your motive are admirable. FWIW, I donate every now and then, but not near as much as what I recieve in return. Frankly, I don't think MedSystemsGnu will be a money making machine, but thats not its point either. But look at CUPS, and we will never know the details, but someone somewhere is financially better off; http://apple.slashdot.org/apple/07/07/12/1342258.shtml

OK, today when I woke up, a goal of mine was to get GNU/Arch running on a PII w/ 128MB RAM. So, it's back to the salt mines, to round at the hospital and also to finish my paperwork from yesterday's clinic!

Patrick

_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@...
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/

[Mitch Amiano]

Thomas Lord wrote:

> Mitch Amiano wrote:
>> There exists a general market <snip/>
>> http://xml.coverpages.org/healthcare.html shows a plethora of
>> activity in this area.
>
> I agree about that market and thank you for the link to what looks a
> useful resource.
>
>
>>
>> The value to the user, if I can read into Thomas' response, is the
>> ability to use the system to query and retrieve on the basis of the
>> structures, not just to store and seal it.
>>
>
> That's an example of a benefit to the user.    Other benefits of an
> XML-based format include:  exchange formats "for free", directly
> executable data type (aka schema) definitions (also in XML), generic
> stores and processors, etc.   I realize that that list starts to sound
> more like "benefits to the programmer" rather than "benefits to the
> user" so, another way to say it is that XML-based approaches give
> customers a lot of liberty to invent new database structures because,
> from just a definition of the new structure, the customer can get a
> working database, working exchange format, and to some extent a
> working UI pretty much "for free".
>
> The medical record standardization efforts you link to above are a
> good example:   domain experts in medicine concentrate on applying
> their knowledge to things like translating a paper Continuity of Care
> form into an XML type.    Increasingly, we should expect the results
> of such efforts to be more and more "directly executable" -- those
> guys are doing the heavy lifting of writing entirely new applications.
>

OTOH, I would suggest to anyone initiating a project such as was
suggested, be extremely disciplined and NOT be distracted by the
plethora of XML efforts. Choose a path and go down it, with a specific
set of users in mind, possibly even using your own "non-standard" tag
set. Trying to be compliant with everything, nothing will be completing
or it will be so convoluted it is incomprehensible.

An appealing aspect of the DITA XML methodology with respect to the
problem of bridging to different XML tag sets, above-and-beyond using
one-of XSLT transforms, is the ability to cross-translate DITA documents
between domain-specific DITA tags and the more generic Topic types. It
is inheritance: "Topic" in DITA is as "Object" is to Smalltalk. The
exiting DITA-Open Toolkit transformations are keyed off of a kind of
"base-class/instance-of" attribute built-into the stock schemas and
modified in schemas used for specializations.

>
>
>> Doesn't a HIPAA compliant system also have to restrict access on the
>> basis of roles and privileges? So you'll need some sort of access
>> control lists or other security controls to even get in the door.
>
> It's even worse than that.   To really get anywhere you not only
> access controls based on roles and privileges, but you need to
> innovate a little bit about how to implement those.    The problem is
> that, as an industry, health care needs to learn to maintain widely
> distributed, portable records.   Yet, during transport from one
> end-use to another, we should expect this data to pass through plenty
> of untrusted processes.    Therefore, I predict (not very boldly --
> it's obvious), that standards for encrypting XML content,  standards
> for signing XML content, standards for distributed management of
> "identity", and standards for managing public cryptography keys are
> going to become very important in the near future.
>

A few months ago, I applied to NCSU, and was told that I had to be
immunized. Well, I was, but long story short my records consisted of the
doctor scribbling a note on a prescription pad - and it didn't meet the
criteria. So I'm getting shots in my arms, and cursing the doctor, who
has long since passed on. In any case, I'd add to the above, that I
could have trivially forged a document that would have looked perfectly
valid - the doctor, after all, is dead, his office and records gone. So
(a) society is expecting a far higher standard of proof regarding
digital content than what one could possibly expect from a paper trail
and (b) it was primarily my interest that was harmed through the lack of
thoroughness and diligence regarding records management.

They are my records, and while I shouldn't be allowed to falsify someone
else's entries, or muck with some other's version of the same records,
by the same token I should have complete access to the content as it
pertains to me. From that aspect, I think Arch philosophically is
appealing.




>> One last comment - where's the money for it going to come from?
>
> Are you asking me or Patrick?
>
Definitely posing that question to Patrick. I recognize from listening
in on the Arch list that you've been through the wringer financially
while working on Arch.

I'm playing Devil's advocate rather than looking at it as the techie I
am at heart.  Regardless of how many neat open source projects that
could be leveraged to address one aspect or another of medical records
management, it still costs people time, effort, and resources to attempt
such an endeavor. People have to eat; better still if they can pay their
own medical expenses too, and have something left over. I'm not a big
mover and shaker, but I would think it would be best to identify one
aspect or two of the problem that is REALLY PAINFUL to someone with
money, so that you can get them to start transferring capital to you in
exchange for addressing their perception of the pain.

Another way to put it: Patrick, are you viewing this as an "internal" IT
problem, or have you considered the problem/solution in terms of a
business model?  Doubtless there is a market for medical records
management for doctor's practices, clinics and hospitals. What about for
the client or families? It would have been worth about a hundred bucks
to me in the case I outlined above, to get a valid immunization record
and avoid the hassle of being poked with a needle. (Perhaps it's about
time someone created a medical records "credit union" as it were, and
separate the ownership of the records from the institutions.)

>
> Health records are not my primary focus -- I'm aiming for a bigger
> target with health records as a potentially tasty application.  I'm
> doing "lower level" work that "enables" stuff like health record
> applications.
>
> My plan, such as it is, is to try to make money "on the margins" of a
> distributed, anarchic build-out of an important new open source
> technology.   Right now, the work I'm doing is an investment being
> made by fiance and I -- I leverage some of this work for my part-time
> day job and we invest some of our household income in my spending
> plenty of additional time on this "practical research".  I think that
> when I "release early" the open source results,  astute people in the
> open source community will likely want to use the code, probably fork
> it and improve it on their own, turn into direct-to-customer products
> of their own, etc.  By making money "on the margins" I mean that I
> intend to charge small amounts for the download of some (GPLv3)
> components, charge for documentation downloads, charge for a la carte
> consultations, etc.    That's chump change per transaction but, for a
> family business, chump change can quickly add up.    Of course, I'll
> also keep my eyes open for unique direct-to-customer niches that, by
> luck, I'm the best positioned to pounce on, build some equity, sell a
> company (or just operate one), and "win big".
>
> This being open source, the "big" investment building out this new
> technology is likely to occur (if it does at all, knock on wood), in a
> distributed, incremental way.    My job as an open source researcher
> is basically just to create the "frame" -- to create the new market
> for that incremental, distributed investment by "shaping" the
> technology the right way.
>
>
> -t
>
>
>

_______________________________________________
Gnu-arch-users mailing list
Gnu-arch-users@...
http://lists.gnu.org/mailman/listinfo/gnu-arch-users

GNU arch home page:
http://savannah.gnu.org/projects/gnu-arch/