Monday, October 15, 2012
Purpose of Detailed Clinical Models (DCM)
Detailed Clinical Models (DCM) prescribe a static model-of-meaning specification for clinical content within the context of SAIF. Detailed Clinical Models are intended for computable semantic interoperability between and within (including longitudinally) clinical information systems as the level of detail which is clinically relevant. Interpretation of DCMs is context independent: meaning is represented in a fashion which is agnostic to source system or intended use. Ambiguity in implementation is avoided, while clinical ambiguity is clearly represented, and clinical context provided in a systematic fashion.
They are intended to meet the requirements of a virtual medical record (vMR) for clinical decision support; to enable massive-scale analytics (effectively eliminating the ambiguity and uncertainty associated with assimilating data from multiple sources) required for a “learning healthcare system”; to promote quality measure reporting; to improve the quality of HL7 standards; to reduce the complexity needed to create modern, sophisticated electronic health record systems (EHRS), personal health record systems (PHRS) and clinical trial management systems (CTMS) with electronic data capture (EDC); to enable creation of a component-oriented approach to EHRS where a single GUI could inter-operate with any number of 3rd party systems; and to provide rich, context dependent information for public health disease surveillance and outbreak detection.
HL7 DCMs are intended to supply the clinical content specifications for HL7 v3 messages, HL7 v3 CDA r3 (CDA r2 has too many limitations in the “body” to support the semantics required), and HL7 v3 based web services. Other serializations could include class libraries, implementation guides, UML class diagrams.
Thursday, January 26, 2012
Introduction to the problem
Are we there yet?
In spite of decades of experience with electronic health records and clinical decision support, the lack of semantic interoperability has prevented the predicted sea-change in healthcare. Health data is not comparable, it cannot be aggregated and it cannot be used to automate or augment clinical decision making. The solution requires a robust information model and rigorous attention to detail in use of clinical terminology which is well suited for clinical documentation, decision support, public health reporting, quality improvement and clinical trials. A Detailed Clinical Model (DCM), within the scope of HL7, is a set of specifications for clinical content represented in HL7 v3 formalism. It provides the canonical static semantics for clinical information exchange independent of the particular information exchange paradigm. The specific implementation presented is implemented as HL7 version 3 specifications which extend by constraint HL7 Clinical statement model using HL7 Templates and following the HL7 TermInfo (Use of SNOMED-CT) specifications. Furthermore, the model adopts a subset of the SNOMED-CT concept model attributes for Findings with Explicit Circumstances as mandatory, relying on the mechanism within the CD data types for post-coordination. This allows for a compact message which is reliably interpreted even by systems which are not designed around this model.It may be possible to create DCMs with the same semantic content using terminologies other than SNOMED-CT. However, it is the consensus of the HL7 terminology community that SNOMED-CT offers the greatest opportunity to success. There is also a growing recognition (q.v. the TermInfo guide) that creation of implementable specifications which are not specific to a given terminology does not result in semantic interoperability. Thus, while the efforts at HL7 will initially focus on SNOMED-CT based DCM efforts, it should be kept in mind that subsequent efforts will be needed to evaluate other terminology approaches at some later time.
One other use of SNOMED-CT is as a reference terminology. DCMs defined using SNOMED-CT concept models could be re-implemented using other terminologies. The role of SNOMED-CT here isn't as an exchange terminology, but rather to define the semantics of the model, regardless of what controlled vocabulary is used at the interface/message level.Detailed clinical models address issues of clinical content of health record systems and do not mandate a specific implementation, as transformations between this model and other alternative representations is possible. Furthermore, they are explicitly designed for use in multiple applications including messaging, structured documents, web services, or as the specification of a virtual medical record API for decision support or other components.Clinical records serve multiple primary uses and roles. They primarily serve as a set of notes so a provider may refresh their recollection of a patient at a subsequent encounter, or as a means of communicating with other providers who may subsequently see the patient. Clinical records further provide a legal document to provide evidence of compliance with regulatory requirements as well as the account which documents the quality and conformance of care which is used to substantiate claims for reimbursement and defend against claims of malpractice. The record may also be primarily concerned with documenting observations gathered as part of a research endeavor, much as a laboratory notebook documents more basic experiments. Clinical decision support systems represent a more modern primary use of captured clinical findings. While the distinction is not terribly informing, secondary uses typically fall outside the direct care or purpose of the encounter, and more often (like the collection of information for research or use in a decision support application) have an analytic or computational focus. Some additional examples include collection of case histories required for board certification in some clinical specialties, reporting of cases of interest for public health authorities, quality assurance reviews, and research involving clinical encounter information (as contrasted with use of information collected primarily for research use). While the primary use requirements are well established, often by statute, and are often met with pre-Gutenberg technology, secondary use is highly dependent upon computational methods.To meet the requirements of clinical research, clinical decision support, and the analytic requirements, clinical findings must be represented with considerations beyond the simple record keeping mandates and beyond the capability of narrative text. For information to be useful to anyone but another comparably educated professional, an author must express their findings as discrete observations in an information model that reflects the context in a structured manner using an appropriate controlled terminology (or proper structure for numeric data types). The representation of a shared pattern of expression, with the necessary structure to represent simple cases simply while allowing for semantic richness and complexity is the core requirement of the detailed clinical models (DCM) process. The use of shared detailed clinical models is essential to functional semantic interoperability. In addition, clinical system design is complicated by the need to create, often de novo, data structures and application logic. This is often left to the discretion of a non-clinician (and all too often, informatics naive) programmers resulting in the proliferation of lackluster electronic health records which fall short of the decades old promises of automation and improved patient outcomes due to decisions support technologies. One of the objectives of the detailed clinical models effort is the creation of a library of reference information components created by the leading clinical informatics experts in a peer-reviewed and maintainable manner for use by anyone wishing to create an application or system using clinical information.Detailed clinical models have specific requirements. First, they reflect the clinical and biomedical reality with accuracy and precision. It is not sufficient to create data models which cannot capture the relevant details in complex cases, nor is it acceptable to have data models which impose rigid and complicated requirements for cases where the observation is simple (such as the case with most normal findings documented). Furthermore, there is nearly always some degree of imprecision in describing a finding, and often a degree of uncertainty as to the very existence or truth of the finding. For example, a physician may appreciate the soft, rounded edges of what appears to be an enlarged spleen on physical exam. They may be able to quantify it as mild, moderate, etc. or describe the lower edge in centimeters below the costal margin. In many patients, appreciation of abdominal masses is limited by their body habitus, and general physical examination estimation of size of visceral contents is notoriously inaccurate. The physician may not even be certain that they are palpating the spleen, and may wish to qualify it as “probably present” or “possibly present”. In contrast, diagnostic imaging (such as an abdominal CT or ultrasound) can provide accurate measurements with known precision/error.
In spite of decades of experience with electronic health records and clinical decision support, the lack of semantic interoperability has prevented the predicted sea-change in healthcare. Health data is not comparable, it cannot be aggregated and it cannot be used to automate or augment clinical decision making. The solution requires a robust information model and rigorous attention to detail in use of clinical terminology which is well suited for clinical documentation, decision support, public health reporting, quality improvement and clinical trials. A Detailed Clinical Model (DCM), within the scope of HL7, is a set of specifications for clinical content represented in HL7 v3 formalism. It provides the canonical static semantics for clinical information exchange independent of the particular information exchange paradigm. The specific implementation presented is implemented as HL7 version 3 specifications which extend by constraint HL7 Clinical statement model using HL7 Templates and following the HL7 TermInfo (Use of SNOMED-CT) specifications. Furthermore, the model adopts a subset of the SNOMED-CT concept model attributes for Findings with Explicit Circumstances as mandatory, relying on the mechanism within the CD data types for post-coordination. This allows for a compact message which is reliably interpreted even by systems which are not designed around this model.It may be possible to create DCMs with the same semantic content using terminologies other than SNOMED-CT. However, it is the consensus of the HL7 terminology community that SNOMED-CT offers the greatest opportunity to success. There is also a growing recognition (q.v. the TermInfo guide) that creation of implementable specifications which are not specific to a given terminology does not result in semantic interoperability. Thus, while the efforts at HL7 will initially focus on SNOMED-CT based DCM efforts, it should be kept in mind that subsequent efforts will be needed to evaluate other terminology approaches at some later time.
One other use of SNOMED-CT is as a reference terminology. DCMs defined using SNOMED-CT concept models could be re-implemented using other terminologies. The role of SNOMED-CT here isn't as an exchange terminology, but rather to define the semantics of the model, regardless of what controlled vocabulary is used at the interface/message level.Detailed clinical models address issues of clinical content of health record systems and do not mandate a specific implementation, as transformations between this model and other alternative representations is possible. Furthermore, they are explicitly designed for use in multiple applications including messaging, structured documents, web services, or as the specification of a virtual medical record API for decision support or other components.Clinical records serve multiple primary uses and roles. They primarily serve as a set of notes so a provider may refresh their recollection of a patient at a subsequent encounter, or as a means of communicating with other providers who may subsequently see the patient. Clinical records further provide a legal document to provide evidence of compliance with regulatory requirements as well as the account which documents the quality and conformance of care which is used to substantiate claims for reimbursement and defend against claims of malpractice. The record may also be primarily concerned with documenting observations gathered as part of a research endeavor, much as a laboratory notebook documents more basic experiments. Clinical decision support systems represent a more modern primary use of captured clinical findings. While the distinction is not terribly informing, secondary uses typically fall outside the direct care or purpose of the encounter, and more often (like the collection of information for research or use in a decision support application) have an analytic or computational focus. Some additional examples include collection of case histories required for board certification in some clinical specialties, reporting of cases of interest for public health authorities, quality assurance reviews, and research involving clinical encounter information (as contrasted with use of information collected primarily for research use). While the primary use requirements are well established, often by statute, and are often met with pre-Gutenberg technology, secondary use is highly dependent upon computational methods.To meet the requirements of clinical research, clinical decision support, and the analytic requirements, clinical findings must be represented with considerations beyond the simple record keeping mandates and beyond the capability of narrative text. For information to be useful to anyone but another comparably educated professional, an author must express their findings as discrete observations in an information model that reflects the context in a structured manner using an appropriate controlled terminology (or proper structure for numeric data types). The representation of a shared pattern of expression, with the necessary structure to represent simple cases simply while allowing for semantic richness and complexity is the core requirement of the detailed clinical models (DCM) process. The use of shared detailed clinical models is essential to functional semantic interoperability. In addition, clinical system design is complicated by the need to create, often de novo, data structures and application logic. This is often left to the discretion of a non-clinician (and all too often, informatics naive) programmers resulting in the proliferation of lackluster electronic health records which fall short of the decades old promises of automation and improved patient outcomes due to decisions support technologies. One of the objectives of the detailed clinical models effort is the creation of a library of reference information components created by the leading clinical informatics experts in a peer-reviewed and maintainable manner for use by anyone wishing to create an application or system using clinical information.Detailed clinical models have specific requirements. First, they reflect the clinical and biomedical reality with accuracy and precision. It is not sufficient to create data models which cannot capture the relevant details in complex cases, nor is it acceptable to have data models which impose rigid and complicated requirements for cases where the observation is simple (such as the case with most normal findings documented). Furthermore, there is nearly always some degree of imprecision in describing a finding, and often a degree of uncertainty as to the very existence or truth of the finding. For example, a physician may appreciate the soft, rounded edges of what appears to be an enlarged spleen on physical exam. They may be able to quantify it as mild, moderate, etc. or describe the lower edge in centimeters below the costal margin. In many patients, appreciation of abdominal masses is limited by their body habitus, and general physical examination estimation of size of visceral contents is notoriously inaccurate. The physician may not even be certain that they are palpating the spleen, and may wish to qualify it as “probably present” or “possibly present”. In contrast, diagnostic imaging (such as an abdominal CT or ultrasound) can provide accurate measurements with known precision/error.
Sunday, January 22, 2012
Summary of DCMs
There is a critical dependence on representing clinical content in a fashion which is both human readable (usually easy), useful for secondary analysis (hard), and which is machine-interpretable (very hard). Casual approaches nearly always fail, as they effectively tie their logic in knots, and use-specific, highly focused approaches lead to volumes of hard (if not impossible) to use piles of important information. There is a recognized need to have a systematic, precise, yet expressive and flexible approach to representation of structured clinical content specification at the level of clinical, research, and legal detail required.
Detailed Clinical Models (DCM) are a precisely defined set of data element specifications which capture the meaning and context of clinical information is a format which is amenable to analysis and use in clinical decision support systems. They provide a common information model for clinical data (including procedures, history and physical exam findings, diagnosis, problems, medication use) which is independent of the use of the information, the source of the information, and which can be shared between applications/services to facilitate semantic interoperability.
Benefits of DCMs include reducing the long-term cost of system development and maintenance by centralizing the management of complexity, and providing data element specifications which can be safely reused for multiple purposes. They also can help simplify migration of data from legacy systems, can be used to define persistence mechanisms which “future proofs” the clinical data, and makes it available for use outside the application which created it.
Specific examples where DCMs are the key enabling technology include interfacing “best of breed” systems, robust clinical decision support, rich data warehouses with precisely defined data, cross organizational quality measures, early recognition of infectious disease outbreaks, and computable electronic health record information exchange.
Design of DCMs is as complex as the clinical information they represent. They need to be able to capture data at the most specific and detailed level which is clinically relevant and which meets the basic requirements of clinical documentation. They also need to be able to represent simple findings simply, while allowing for arbitrary complexity. One of the most important advantages, and requirements, for DCMs is the need to have explicit representation of relationships between data elements, such as those linking a test result to a diagnosis to a therapy.
Detailed Clinical Models include both compositional rules to combine simple models into more complex models, and using multiple hierarchical design patterns (i.e. a broader pattern is constrained into a more specific child pattern) to create models which can be easily parsed and which have deterministic meaning. Similarly, terminology is bound and further constrained as part of the model definitions. All DCMs are a constraint on a common reference model (in the HL7 context, this would be the Clinical Statement Pattern), and will follow a common approach to definition to provide consistent data structures.
Detailed Clinical Models (DCM) are a precisely defined set of data element specifications which capture the meaning and context of clinical information is a format which is amenable to analysis and use in clinical decision support systems. They provide a common information model for clinical data (including procedures, history and physical exam findings, diagnosis, problems, medication use) which is independent of the use of the information, the source of the information, and which can be shared between applications/services to facilitate semantic interoperability.
Benefits of DCMs include reducing the long-term cost of system development and maintenance by centralizing the management of complexity, and providing data element specifications which can be safely reused for multiple purposes. They also can help simplify migration of data from legacy systems, can be used to define persistence mechanisms which “future proofs” the clinical data, and makes it available for use outside the application which created it.
Specific examples where DCMs are the key enabling technology include interfacing “best of breed” systems, robust clinical decision support, rich data warehouses with precisely defined data, cross organizational quality measures, early recognition of infectious disease outbreaks, and computable electronic health record information exchange.
Design of DCMs is as complex as the clinical information they represent. They need to be able to capture data at the most specific and detailed level which is clinically relevant and which meets the basic requirements of clinical documentation. They also need to be able to represent simple findings simply, while allowing for arbitrary complexity. One of the most important advantages, and requirements, for DCMs is the need to have explicit representation of relationships between data elements, such as those linking a test result to a diagnosis to a therapy.
Detailed Clinical Models include both compositional rules to combine simple models into more complex models, and using multiple hierarchical design patterns (i.e. a broader pattern is constrained into a more specific child pattern) to create models which can be easily parsed and which have deterministic meaning. Similarly, terminology is bound and further constrained as part of the model definitions. All DCMs are a constraint on a common reference model (in the HL7 context, this would be the Clinical Statement Pattern), and will follow a common approach to definition to provide consistent data structures.
Saturday, January 21, 2012
Why HL7 needs a DCM standard to collaborate as part of CIMI
First, I want to be sure that there is a good understanding why HL7 needs a DCM DSTU when most of us working in the HL7 DCM space are also working on the CIMI () efforts.
I think the most important thing to remember is why some of us took up the banner after the "Bocca DCM Summit". There are clearly different aspects of the problem, and different motivations for trying to advance the agenda, so it isn't surprising that different aspects of this complex area require some experimentation and development.
Second, my focus has not been on UML modeling conventions for clinical content. The HL7 DCM DSTU draft/strawman I am working on is all about the methodology, intermediate level models, terminology-RIM interactions, and modularity.
In addition to the bottom-up clinical detail, we need a top-down specification so we can build complex things from simple parts, and so that we can write software which can process information, not just parse data into some local system. Thus, we need design patterns defined as HL7 Templates (whatever those turn out to be. Eg. the time series, which becomes a parent/contributor to the "pharmacological challenge and response model" (which the GTT is a specialization of).
The notion I have been selling (which is useful to consider for CIMI, explains why I think HL7 needs a DCM standard to provide a deterministic target to map CIMI models into).
#1 HL7 DCMs are critically needed as a quality improvement initiative in HL7 specifications (and fit nicely into one of the empty boxes of the SAIF matrix). There is too much variability in how various groups model the same content, and far too many complex issues of RIM semantics which are often not appreciated, ignored, not supported (e.g. CDA r2), or just done wrong.
#2 HL7 DCMs are needed because the existing 'reusable' representations are not terribly reusable and don't support generic programming methods. They are either specific to a standard desperately in need up updating (CDA r2, and I am not just picking on them, I am trying to find a few free minutes to help with a r2.1/2.5/3) or which lack the detail needed to implement in a fashion which supports interoperability.
#3 HL7 DCMs need to support non-messaging uses, particularly decision support and long term data persistence. I can throw together an XSD which conveys the data of a glucose tolerance test (and will post a UML of a 'sketch' for something more useful on the blog) in about a half hour. Of course, a year from now, you need to know exactly what I was thinking at the time to write any sort of algorithm to use the information. Using information is the goal, not just exchange or capture.
#4 HL7 DCMs need to provide explicit semantics which are based on both RIM semantics and terminology semantics as a cohesive whole. This turns out to be harder than a lot of people think, and requires expertise in terminology, modeling, RIM semantics, clinical statement pattern, and particularly (in most cases) SNOMED-CT concept model/TermInfo guidelines. So having a centralized and pre-built library of properly modeled content can serve to accelerate the development of a domain's clinical content specifications.
I think the most important thing to remember is why some of us took up the banner after the "Bocca DCM Summit". There are clearly different aspects of the problem, and different motivations for trying to advance the agenda, so it isn't surprising that different aspects of this complex area require some experimentation and development.
Second, my focus has not been on UML modeling conventions for clinical content. The HL7 DCM DSTU draft/strawman I am working on is all about the methodology, intermediate level models, terminology-RIM interactions, and modularity.
In addition to the bottom-up clinical detail, we need a top-down specification so we can build complex things from simple parts, and so that we can write software which can process information, not just parse data into some local system. Thus, we need design patterns defined as HL7 Templates (whatever those turn out to be. Eg. the time series, which becomes a parent/contributor to the "pharmacological challenge and response model" (which the GTT is a specialization of).
The notion I have been selling (which is useful to consider for CIMI, explains why I think HL7 needs a DCM standard to provide a deterministic target to map CIMI models into).
#1 HL7 DCMs are critically needed as a quality improvement initiative in HL7 specifications (and fit nicely into one of the empty boxes of the SAIF matrix). There is too much variability in how various groups model the same content, and far too many complex issues of RIM semantics which are often not appreciated, ignored, not supported (e.g. CDA r2), or just done wrong.
#2 HL7 DCMs are needed because the existing 'reusable' representations are not terribly reusable and don't support generic programming methods. They are either specific to a standard desperately in need up updating (CDA r2, and I am not just picking on them, I am trying to find a few free minutes to help with a r2.1/2.5/3) or which lack the detail needed to implement in a fashion which supports interoperability.
#3 HL7 DCMs need to support non-messaging uses, particularly decision support and long term data persistence. I can throw together an XSD which conveys the data of a glucose tolerance test (and will post a UML of a 'sketch' for something more useful on the blog) in about a half hour. Of course, a year from now, you need to know exactly what I was thinking at the time to write any sort of algorithm to use the information. Using information is the goal, not just exchange or capture.
#4 HL7 DCMs need to provide explicit semantics which are based on both RIM semantics and terminology semantics as a cohesive whole. This turns out to be harder than a lot of people think, and requires expertise in terminology, modeling, RIM semantics, clinical statement pattern, and particularly (in most cases) SNOMED-CT concept model/TermInfo guidelines. So having a centralized and pre-built library of properly modeled content can serve to accelerate the development of a domain's clinical content specifications.
Monday, January 31, 2011
Return after hiatus
It has been far too long since I was last on-line, and it is high time to resume some discussions about the importance of proper modeling of clinical content.
There are a lot of balls in the air in the healthcare IT world today. With so many different, often disconnected, efforts, we risk the creation of specifications which impair large scale interoperability, secondary use of information, and the benefits of clinical decision support as part of the order entry functions of an electronic health record system.
Several efforts are underway which will help pave the way. The Health Story project, which I am providing technical assistance, will seek to consolidate the existing discrepencies between HL7 v3 CDA r2 implementation guides. This helps to both correct some of the issues many have had, but also is a great illustration of the divergence in approaches which occurs without an overarching information model for the content.
The clinical statement pattern is the current foundation for modeling HL7 clinical content, be it for a message, a clinical document or as part of a web service. The clinical statement pattern provides a mechanism to create interoperable detailed clinical models, but does in an of itself will not provide this. Experience has shown that there are 'many ways to skin a cat'; the DCM effort simply exists to provide one best practice for doing so which can be shared between applications.
There are a lot of balls in the air in the healthcare IT world today. With so many different, often disconnected, efforts, we risk the creation of specifications which impair large scale interoperability, secondary use of information, and the benefits of clinical decision support as part of the order entry functions of an electronic health record system.
Several efforts are underway which will help pave the way. The Health Story project, which I am providing technical assistance, will seek to consolidate the existing discrepencies between HL7 v3 CDA r2 implementation guides. This helps to both correct some of the issues many have had, but also is a great illustration of the divergence in approaches which occurs without an overarching information model for the content.
The clinical statement pattern is the current foundation for modeling HL7 clinical content, be it for a message, a clinical document or as part of a web service. The clinical statement pattern provides a mechanism to create interoperable detailed clinical models, but does in an of itself will not provide this. Experience has shown that there are 'many ways to skin a cat'; the DCM effort simply exists to provide one best practice for doing so which can be shared between applications.
Monday, August 3, 2009
Off topic: future of Windows
A little off topic, but since I have put the effort into evaluating Windows 7 v. Windows XP as well as OpenSolaris w/ GNOME 2.24 and openSUSE with KDE 4.3, I thought I would share (for the record, I am still using openSUSE 11.1/KDE 3.5.10 for actually doing work! Once they fix the bugs/glitches in the Kontact PIM--an Outlook killer--I will switch over full time).
I have been using Windows 7 for testing for the last few weeks and it seems so far to be as stable as Windows XP (only one BSOD so far) and unscrewed up a lot of Vista's folly.
The biggest implication is that for most business users is that they can probably expect to make the transition on their next laptops (which always come with some OS pre-installed) rather than having to request that Vista be downgraded to Windows XP.
That said, it looks like Windows is nearing the end of its usefulness, and even Windows 7 lags behind Linux which has a range of graphic user interfaces (KDE 4.3 in particular is visually stunning, fast and very easy to use) can run most Windows software (via WINE or in some virtual machine), and is much more stable (three weeks w/ one BSOD is pretty good for Windows, most Linux desktop users only reboot for kernel updates and unexpected/unrecoverable crashes are less than once a year in my experience. Laptop support is still a bit of an issue, since support for hot switching display settings and problems w/ WiFi after suspend-resume isn't quite there, but for the most part, things work well, easily and predictably).
As far as the future of Windows: I predict they will take (another) a page from Apple and pitch the whole OS and start over (well, Apple started with a venerable open source Unix) with a microkernal design (maybe even doing to Minix* what Apple did to BSD), security by design, with legacy support via WINE. The big part of the OS will be CLR (the .NET runtime standard) with a return to having POSIX as a Windows service (it was dropped from NT 4.0 along w/ OS/2 support when M$ released Win2K). This will be a change for Microsoft, since it will give them a modern OS, but at the cost of making it easier for application developers (including games) to use the same code base to generate software for Linux, Mac OS/X and Windows. This will run contrary to the long standing practice of making it as hard as possible for Windows developers to port their software to non-Windows platforms.
Beyond the fortune telling (which only time will bear out): KDE 4 is available for pretty much any OS which supports C++ and for which there are QT4 libraries. This includes Windows! You can replace the entire Windows desktop with KDE 4 and enjoy all the eye candy and fancy visual effects that Microsoft had to drop from Vista and Windows 7. I don't know if you can drop it in as easily on Mac OS/X, but it runs fine on just about any other UNIX-like OSs with a few odd balls that I don't know for sure (like QNX).
So, if you use XP and are happy, you are not missing any major functionality that I could fine. If youa re using Vista you should probably upgrade unless you got lucky and everything works. Once KDE 4.3 (currently in release candidate status) is stable, you will have a richer UI and more stable OS with Linux. If you are buying a new laptop, it is worth waiting until the vendor offers Windows 7 and go with that, rather than downgrade to XP or get stuck with Vista.
*Minix is a "UNIX-like" operating system that has some similarities to Linux, but uses a very different kernel design. Linux has the option to add modules to the kernel, and you can end up with a very functional, but large, runtime. For desktop and modern laptop PCs this isn't a big deal. For running Linux on your toaster, cell phone, wrist watch or other minimal platforms it usually takes some work to get a conventional distribution to fit on a non-traditional platform. Minix treats most of those things people usually think of as core kernal functions as services and this gives you some very interesting options for slimming things down to the bare minimum, and, if done right, is theoretically easier to design an ultra-stable platform. There are other microkernal OS's out there (QNX being one--it is stable enough that it is used for nuclear power plant control, the controls on a submarine, and the guideance and launch systems used on ICBMs).
Next top:
I have been using Windows 7 for testing for the last few weeks and it seems so far to be as stable as Windows XP (only one BSOD so far) and unscrewed up a lot of Vista's folly.
The biggest implication is that for most business users is that they can probably expect to make the transition on their next laptops (which always come with some OS pre-installed) rather than having to request that Vista be downgraded to Windows XP.
That said, it looks like Windows is nearing the end of its usefulness, and even Windows 7 lags behind Linux which has a range of graphic user interfaces (KDE 4.3 in particular is visually stunning, fast and very easy to use) can run most Windows software (via WINE or in some virtual machine), and is much more stable (three weeks w/ one BSOD is pretty good for Windows, most Linux desktop users only reboot for kernel updates and unexpected/unrecoverable crashes are less than once a year in my experience. Laptop support is still a bit of an issue, since support for hot switching display settings and problems w/ WiFi after suspend-resume isn't quite there, but for the most part, things work well, easily and predictably).
As far as the future of Windows: I predict they will take (another) a page from Apple and pitch the whole OS and start over (well, Apple started with a venerable open source Unix) with a microkernal design (maybe even doing to Minix* what Apple did to BSD), security by design, with legacy support via WINE. The big part of the OS will be CLR (the .NET runtime standard) with a return to having POSIX as a Windows service (it was dropped from NT 4.0 along w/ OS/2 support when M$ released Win2K). This will be a change for Microsoft, since it will give them a modern OS, but at the cost of making it easier for application developers (including games) to use the same code base to generate software for Linux, Mac OS/X and Windows. This will run contrary to the long standing practice of making it as hard as possible for Windows developers to port their software to non-Windows platforms.
Beyond the fortune telling (which only time will bear out): KDE 4 is available for pretty much any OS which supports C++ and for which there are QT4 libraries. This includes Windows! You can replace the entire Windows desktop with KDE 4 and enjoy all the eye candy and fancy visual effects that Microsoft had to drop from Vista and Windows 7. I don't know if you can drop it in as easily on Mac OS/X, but it runs fine on just about any other UNIX-like OSs with a few odd balls that I don't know for sure (like QNX).
So, if you use XP and are happy, you are not missing any major functionality that I could fine. If youa re using Vista you should probably upgrade unless you got lucky and everything works. Once KDE 4.3 (currently in release candidate status) is stable, you will have a richer UI and more stable OS with Linux. If you are buying a new laptop, it is worth waiting until the vendor offers Windows 7 and go with that, rather than downgrade to XP or get stuck with Vista.
*Minix is a "UNIX-like" operating system that has some similarities to Linux, but uses a very different kernel design. Linux has the option to add modules to the kernel, and you can end up with a very functional, but large, runtime. For desktop and modern laptop PCs this isn't a big deal. For running Linux on your toaster, cell phone, wrist watch or other minimal platforms it usually takes some work to get a conventional distribution to fit on a non-traditional platform. Minix treats most of those things people usually think of as core kernal functions as services and this gives you some very interesting options for slimming things down to the bare minimum, and, if done right, is theoretically easier to design an ultra-stable platform. There are other microkernal OS's out there (QNX being one--it is stable enough that it is used for nuclear power plant control, the controls on a submarine, and the guideance and launch systems used on ICBMs).
Next top:
Sunday, July 26, 2009
One small (overdue) example.
You can see some early prototypes of detailed clinical models with the Clinical Data Definition work I did with Tolven a few years ago. A reasonable example would be the chest exam which isn't a complete, flushed out, all bells and whistles example, but it gives a basic idea of where we were two years ago.
One of the components, shown here, are the attributes of a heart ascultation finding. It has a main finding, or entry point, (just called Murmur) which has a fairly value set for the Observation.value drawn from a handful of SNOMED-CT concepts which describe the bulk of the murmurs we routinely encounter in practice.
Subscribe to:
Posts (Atom)
Posts
