Personal Health Information workshop
- The following is an automated response - to your message generated on behalf of rnardi at tin.it Sono assente sino al 15 Agosto. Risponder? al mio ritorno! I will be out of office until August the 15th. I will answer to your message ASAP when back in office! Dr. Roberto Nardi - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
Validating an objecrt against its archetype
Rong Chen wrote: >> >> >> The main thing is that the insert_at_path() (or whatever you call it) >> call must check the relevant archetype node that the insertion is >> allowable, and it should fail if it is not. Your code should always >> know in advance what node this is, due to the choosing of archetypes >> beforehand (e.g. by the GUI forms). > > > This should work for single object node insertion since most of the > object nodes with their runtime name are already created. > > But I start to wonder if runtime path is enough for data creation from > scratch, which requires: > 1. path is unique so it can be used as key to group input values; > 2. link to the original archetype node; You are right - in my explanation, I did not try to be complete. There is a step of major importance which should be carried out by the assembled archetype (i..e after slot-filling has occurred) structure in memory, namely to generate a default data structure. This should be done by defining a method create_default() or similar, which can be called recursively down the archteype hierarchy; the effect of this method called on every C_OBJECT is to create the appropriate data instance e.g. an OBSERVATION or ELEMENT object. The overall result is that in the vast majority of cases, there is a reasoable (often complete, apart from values) data object to work with. Then modifications can proceed by using paths. However, even when following this desing aproach, there are occasions when this is not enough. Imagine the archteype in question is the openEHR BP measurement archetype; in this archetype, there is a subtree called 'protocol', which has existence = 0..1, i..e optional. It would be reasonable for the create_default() method not to create this subtree at all in the data. But what if the user does want it (1 time out of 50)? Then what the software has to do is to call create_default() on the protocl subtree of the BP archetype, and attach the result into the correct place in the main data structure created with the original create_default() call. In general I would never expect data to be created completely from scratch - the only archetype which would justify this is the notional 'any' archetype which allows absolutely anything. During this data create/modify phase Inside the kernel, there are both data instances and archetype instances. Each data instance has to be connected logically to its corresponding archetype node. This could be effected by pointers/references (which is what we did in our GeHR kernel of 3 years ago) or could just be tracked logically by using paths (every data node has embedded in it a value for the attribute archetype_node_id, inherited from he LOCATABLE class). > > 1) is satisfied by using current runtime path, > 2) is not fully satisfied, since runtime path consists of mainly data > node names (LOCATABLE.name()) and node names could either be the text > value in the local language of archetype_node_id code of the node or > explicitly set by the user. If more than one data node should be > created by the same archetype node, the name should include both the > text value and a modifier to make it unique. Not 'could'; it must: it is a condition of correctness that no two sibling LOCATABLEs can ever have the same name value. > The algorithm used for generating unique name modifier can be > predefined so it is possible to find the original archetype node. But > it will fail if the name is explicitly set by a user. Automatic generation (e.g. of "_1", "_2", or "(1)", "(2)" etc) will work fine in many cases; but user setting has to be allowed as well. Everything will be fine as long as when the relevant insert() or append() method is called, that a uniqueness precondition is observed, as shown in the following signature: insert(new_item: LOCATABLE) is pre: not this.has(new_item) where the 'has()' method compares LOCATABLE objects on the basis of their names. > > Besides, it is preferred to have archetype node id as the direct link > instead of some text values in local languages, which mainly is meant > to be used by humans. > > Perhaps a combination of both archetype id and some kind of modifier > based on simple algorithm, eg. a counter could be used to form the > path for object creation. It is bit like archetype path, but it is > unique and easier to process. > > Examples: > > Suppose the "occurrences" of an archetype node[at0004] is "0..*", > meaning from from zero to many nodes can be created by this archetype > node. The archetype path to this node is: > > /[at0001]/action[at0002]/representation[at0003]/items[at0004]/ > > The paths used to bind input data to the archetype node, notice "-1" > and "-2" used as suffix of the archetype node id, which stands for the > first and second object node created from the same archetype node. > > /[at0001]/action[at0002]/representation[at0003]/items[at0004]-1/value/ > /[at0001]/action[at0002
Personal Health Information workshop
I apologize for cross-posts September 30, 2005 New York City www.release1-0.com/events/ I'm writing to invite you to my Personal Health Information (PHI) workshop on September 30 in New York City. If you care about the business of collection, management and use of personal health information, whether you are an entrepreneur, investor, IT vendor, policymaker or a health-care provider, you will want to participate. To make effective use of the capital that investors, government and the public (individuals, employers and insurers) will be pouring into this sector over the next decade, the market first needs to see itself more clearly: Investors need to see models of success, and start-ups need to understand what competitors and potential partners are doing. At the PHI workshop, you will meet other early entrants, see examples of what is already happening in the field, and then discuss what could and should happen. It's a unique chance to get comprehensive exposure to a nascent, unformed market ripe with opportunities. - "Esther's insights in Release 1.0 were the single most important influence on me as I planned and executed the integration of Pfizer and Pharmacia's technical infrastructure." - Jonathan White, Pfizer Release 1.0 subscriber since 2000 - Each type of player in the PHI market will have a different role, but overall the best strategy - and the best outcome - is to improve personal health information liquidity, the ability of that information to move around relatively friction-free. That is, it's not enough just to collect or to store personal health information; it must be shared (under privacy controls) and used in new applications by both patients and health-care providers. Those kinds of tangible benefits, not the mere presence of a record, will drive the market for personal health information forward. That's the goal - and the ways to achieve it - that we'll be discussing on Friday, September 30. We'll also talk about what could happen when many of those records can be aggregated (again with proper privacy protection) for use in public health, epidemiology and evidence-based medicine of all kinds. What kinds of better-targeted treatment will be possible? How real will the promise of "personal medicine" be in five or ten years? And finally, what are the potential side-effects - discrimination in employment, denial of coverage, the very real issues around privacy and individuals' desire (or not) to know the truth about their own conditions - and how can we guard against them? - "Over the years, Esther has consistently shown the uncanny ability to identify important IT trends well before others doand then bring together those new ideas, the right people and the best technologies, and synthesize it all into concrete business opportunities." - Jim Breyer, Accel Partners Release 1.0 subscriber since 1993 - At Release 1.0, we have a 28-year history of putting IT innovations in context, from standards to specifics, from infrastructure to applications, from economics to policy, from technology to business. We also know how to bring investors, entrepreneurs, policymakers and customers together to move markets forward. Come join us in this exciting opportunity on September 30! To register, visit www.release1-0.com/events/ Speakers will include: Larry Augustin, CEO, Medsphere Systems/Vista Giovanni Colella, President & CEO, RelayHealth George Church, Professor of Genetics, and Director, Lipper Center for Computational Genetics, Harvard Medical School Carol Diamond, Managing Director, Health Program, Markle Foundation Ed Fotsch, CEO, Medem Carol McCall, VP, Center for Health Metrics, Humana Ryan Phelan, Founder & CEO, DNADirect Jeffrey Rideout, VP, Internet Business Solutions Group, Healthcare Practice, Cisco Systems Paul Sheils, CEO, Aetna Health Information Solutions Charles Silver, President & CEO, RealAge Jonathan White, Senior VP, Planning, HHIT and Business Development, Pfizer Yours, Esther Dyson Editor, Release 1.0 edyson at release1-0.com PS - Register today for the Personal Health Information workshop on September 30. Feel free to pass this invitation along to a colleague as well. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050818/e6326998/attachment.html>
RFC - CR-000150 - express language etc as a String
As part of the current group of CRs being analysed for openEHR, we are considering CR-000150 (http://coruscant.chime.ucl.ac.uk:8200/openEHR_Collector/projects/specifications/CR/150 in the CR system) which basically says that where we have an attribute in the refreence model which represents language, encoding or territory, we should directly use Strings rather than use CODE_PHRASE as we do now. Current Situation - These particular attributes, which occur, for example in the class DV_TEXT (see http://svn.openehr.org/specification/TRUNK/publishing/architecture/rm/data_types_im.pdf) use international standard codesets as follows: - language is represented by a CODE_PHRASE object containing a code-set id for openehr-languages, which is the same as ISO 639 2-character language codes - encoding is similarly represented, but using codes from IANA character sets, see http://www.iana.org/assignments/character-sets - territory is similarly represented, using ISO 3166 2-character country codes All three of these codesets are currently 'wrapped' by openEHR code-sets (see Support IM, http://svn.openehr.org/specification/TRUNK/publishing/architecture/rm/support_im.pdf), and it is the openEHR code-sets which are mentioned in the reference model invariants, thus forcing the appropriate attributes always to be a code from the appropriate code set. This level of indirection allows for openEHR to, in the future, use different code sets for this purpose (e.g. the ISO 3-character code sets, or perhaps an ISO replacement for the IANA charater set names, or even IANA equivalents for the ISO code sets); the reference model would remain valid regardless. The logic for choosing to model these codes as CODE_PHRASEs in openEHR was for consistency: every coded entity in openEHR is either a DV_CODED_TEXT (which contains a CODE_PHRASE) or a CODE_PHRASE (used when the codes themselves carry the meaning, as most of the ISO and IANA codesets do). IN practical terms it does of course mean slightly more data instances at a fine-grained level; e.g. in XML you would see more tags and data items for each CODE_PHRASE compared to a simple String field. Proposed Situation --- Sam Heard has proposed that these three types of codes should be hard-wired into the reference model - as direct string attributes, and that the reference model documentation should simply say that the particular ISO or IANA codes are mandatory in each case. This is a reasonable position - these codesets seem to be very stable - some would say they are the most stable of any coded entity today. There is undoubtedly software around which does hardwire such codes, and has never had a problem. There is also an argument for simpler object structures as well - a String is simpler than a CODE_PHRASE. However, semantically, the current and proposed solutions are the same - in the current situation, invariants guarantee the the codes must come from the appropriate codesets for each particular attribute. Possible objections are: - the indirection we currently have is useful: there is no guarantee that we won't have to move to another code-set which better serves the same purpose - the consistency in the software (all coded entities are _always_ dealt with via the terminology service, no matter what they are) is preferable to having certain fields that the software itself directly knows the codes of We would be interested in opinions on this proposal. I personally do not know whether we can regard the ISO and IANA code sets for country, language and character-sets as 'safe for all time'; does anyone have inside knowledge on this? Any other opinions welcome. - thomas beale -- ___ CTO Ocean Informatics (http://www.OceanInformatics.biz) Research Fellow, University College London (http://www.chime.ucl.ac.uk) Chair Architectural Review Board, openEHR (http://www.openEHR.org) - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
ANNC: lists functioning properly again
On Wed, Aug 17, 2005 at 07:38:56PM +0100, Thomas Beale wrote: > USM Bish wrote: > > > >Thomas, > > > >Are you sure that things are ironed out now ? I seem to be > >getting two copies of each mail (inclusive of above mail). Or, > >is it only me ? > > > You are probably subscribed to both technical and clinical lists - I > cross-posted, to pick up people who might only be on one or other. > > - thomas ---end quoted text--- Bingo, you hit the nail right on the head ... Bish - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
