Difference between revisions of "User:Shawndouglas/sandbox/sublevel10"

From LIMSWiki
Jump to navigationJump to search
 
(160 intermediate revisions by the same user not shown)
Line 3: Line 3:
| type      = notice
| type      = notice
| style    = width: 960px;
| style    = width: 960px;
| text      = This is sublevel2 of my sandbox, where I play with features and test MediaWiki code. If you wish to leave a comment for me, please see [[User_talk:Shawndouglas|my discussion page]] instead.<p></p>
| text      = This is sublevel10 of my sandbox, where I play with features and test MediaWiki code. If you wish to leave a comment for me, please see [[User_talk:Shawndouglas|my discussion page]] instead.<p></p>
}}
}}


==Sandbox begins below==
==Sandbox begins below==
==1. Introduction to materials and materials testing laboratories==


=Laboratory informatics software acquisition and implementation considerations=
What is a material? This question is surprisingly more complex for the layperson than may be expected. The definition of "material" has varied significantly over the years, dependent on the course of study, laboratory, author, etc. A 1974 definition by Richardson and Peterson that has seen some use in academic study defines a material as "any nonliving matter of academic, engineering, or commercial importance."<ref>{{Cite book |last=Richardson |first=James H. |last2=Peterson |first2=Ronald V. |date= |year=1974 |title=Systematic Materials Analysis, Part 1 |url=https://books.google.com/books?id=BNocpYI8gJkC&printsec=frontcover&dq=Systematic+Materials+analysis&hl=en&newbks=1&newbks_redir=0&sa=X&ved=2ahUKEwjB1OeQx-aAAxWnmmoFHSV2BSsQ6AF6BAgMEAI#v=onepage&q=Systematic%20Materials%20analysis&f=false |chapter=Chapter 1: Introduction to Analytical Methods |series=Materials science series |publisher=Academic Press |place=New York |page=2 |isbn=978-0-12-587801-2 |doi=10.1016/B978-0-12-587801-2.X5001-0}}</ref> But recently biomaterials like biopolymers (as replacements for plastics)<ref>{{Cite journal |last=Das |first=Abinash |last2=Ringu |first2=Togam |last3=Ghosh |first3=Sampad |last4=Pramanik |first4=Nabakumar |date=2023-07 |title=A comprehensive review on recent advances in preparation, physicochemical characterization, and bioengineering applications of biopolymers |url=https://link.springer.com/10.1007/s00289-022-04443-4 |journal=Polymer Bulletin |language=en |volume=80 |issue=7 |pages=7247–7312 |doi=10.1007/s00289-022-04443-4 |issn=0170-0839 |pmc=PMC9409625 |pmid=36043186}}</ref> and even natural<ref>{{Cite journal |last=Kurniawan |first=Nicholas A. |last2=Bouten |first2=Carlijn V.C. |date=2018-04 |title=Mechanobiology of the cell–matrix interplay: Catching a glimpse of complexity via minimalistic models |url=https://linkinghub.elsevier.com/retrieve/pii/S2352431617301864 |journal=Extreme Mechanics Letters |language=en |volume=20 |pages=59–64 |doi=10.1016/j.eml.2018.01.004}}</ref> and engineered biological tissues<ref>{{Cite journal |last=Kim |first=Hyun S. |last2=Kumbar |first2=Sangamesh G. |last3=Nukavarapu |first3=Syam P. |date=2021-03 |title=Biomaterial-directed cell behavior for tissue engineering |url=https://linkinghub.elsevier.com/retrieve/pii/S246845112030057X |journal=Current Opinion in Biomedical Engineering |language=en |volume=17 |pages=100260 |doi=10.1016/j.cobme.2020.100260 |pmc=PMC7839921 |pmid=33521410}}</ref> may be referenced as "materials." (And to Richardson and Peterson's credit, they do add in the preface of their 1974 work that "[a]lthough the volumes are directed toward the physical sciences, they can also be of value for the biological scientist with materials problems."<ref>{{Cite book |last=Richardson |first=James H. |last2=Peterson |first2=Ronald V. |date= |year=1974 |title=Systematic Materials Analysis, Part 1 |url=https://books.google.com/books?id=BNocpYI8gJkC&printsec=frontcover&dq=Systematic+Materials+analysis&hl=en&newbks=1&newbks_redir=0&sa=X&ved=2ahUKEwjB1OeQx-aAAxWnmmoFHSV2BSsQ6AF6BAgMEAI#v=onepage&q=Systematic%20Materials%20analysis&f=false |chapter=Preface |series=Materials science series |publisher=Academic Press |place=New York |page=xiii |isbn=978-0-12-587801-2 |doi=10.1016/B978-0-12-587801-2.X5001-0}}</ref> A modern example would be biodegradable materials research for tissue and medical implant engineering.<ref>{{Cite journal |last=Modrák |first=Marcel |last2=Trebuňová |first2=Marianna |last3=Balogová |first3=Alena Findrik |last4=Hudák |first4=Radovan |last5=Živčák |first5=Jozef |date=2023-03-16 |title=Biodegradable Materials for Tissue Engineering: Development, Classification and Current Applications |url=https://www.mdpi.com/2079-4983/14/3/159 |journal=Journal of Functional Biomaterials |language=en |volume=14 |issue=3 |pages=159 |doi=10.3390/jfb14030159 |issn=2079-4983 |pmc=PMC10051288 |pmid=36976083}}</ref>) Yet today more questions arise. what of matter that doesn't have "academic, engineering, or commercial importance"; can it now be called a "material" in 2023? What if a particular matter exists today but hasn't been thoroughly studied to determine its value to researchers and industrialists? Indeed, the definition of "material" today is no easy task. This isn't made easier when even modern textbooks introduce the topic of materials science without aptly defining what a material actually is<ref>{{Cite book |last=Callister |first=William D. |last2=Rethwisch |first2=David G. |date= |year=2021 |title=Fundamentals of materials science and engineering: An integrated approach |url=https://books.google.com/books?id=NC09EAAAQBAJ&newbks=1&newbks_redir=0&printsec=frontcover |chapter=Chapter 1. Introduction |publisher=Wiley |place=Hoboken |pages=2–18 |isbn=978-1-119-74773-4}}</ref>, let alone what materials science is.<ref>{{Cite book |last=Sutton |first=Adrian P. |date=2021 |title=Concepts of materials science |edition=First edition |publisher=Oxford University Oress |place=Oxford [England] ; New York, NY |isbn=978-0-19-284683-9}}</ref> Perhaps the writers of said textbooks assume that the definitions of "material" and "materials science" have a "well duh" response.


==Starting out==
To complicate things further, a material can be defined based upon the context of use. Take for example the ISO 10303-45 standard by the [[International Organization for Standardization]] (ISO), which addresses the representation and exchange of material and product manufacturing information in a standardized way, specifically describing how material and other engineering properties can be described in the model/framework.<ref name="ISO10303-45">{{cite web |url=https://www.iso.org/standard/78581.html |title=ISO 10303-45:2019 ''Industrial automation systems and integration — Product data representation and exchange — Part 45: Integrated generic resource: Material and other engineering properties'' |publisher=International Organization for Standardization |date=November 2019 |accessdate=20 September 2023}}</ref><ref name=":0">{{Cite journal |last=Swindells |first=Norman |date=2009 |title=The Representation and Exchange of Material and Other Engineering Properties |url=http://datascience.codata.org/articles/abstract/10.2481/dsj.008-007/ |journal=Data Science Journal |language=en |volume=8 |pages=190–200 |doi=10.2481/dsj.008-007 |issn=1683-1470}}</ref> The context here is "standardized data transfer of material- and product-related data," which in turn involves [[Ontology (information science)|ontologies]] that limit the complexity of materials science discourse and help better organize materials and product data into information and knowledge. As such, the ISO 10303 set of standards must define "material," and 10303-45 complicates matters further in this regard (though it will be helpful for this guide in the end).
The two main questions you will need to answer at the outset are:


1. What do I want the laboratory informatics solution to do for me?
In reviewing ISO 10303-45 in 2009, Swindells notes the following about the standard<ref name=":0" />:


2. What kind of budget do I have?
<blockquote>The first edition of ISO 10303-45 was derived from experience of the testing of, so-called, "materials" properties, and the terminology used in the standard reflects this experience. However, the information modelling of an engineering material, such as alloyed steel or high density polyethylene, is no different from the information modelling of a "product." The "material" properties are therefore one of the characteristics of a product, just as its shape and other characteristics are. Therefore all "materials" are products, and the information model in ISO 10303-45 can be used for any property of any product.</blockquote>


Additionally—and secondarily—you'll want to be sure you can participate in one or more vendor demonstrations and, afterwards, build a requirements list.
Put in other words, for the purposes of defining "material" for a broader, more standardized ontology, materials and products can be viewed as interchangeable. Mies puts this another way, stating that based on ISO 10303-45, a material can be defined as "a manufactured object with associated properties in the context of its use environment."<ref>{{Cite book |last=Mies, D. |date=2002 |editor-last=Kutz |editor-first=Myer |title=Handbook of materials selection |url=https://books.google.com/books?id=gWg-rchM700C&pg=PA499 |chapter=Chapter 17. Managing Materials Data |publisher=J. Wiley |place=New York |page=499 |isbn=978-0-471-35924-1}}</ref> But this representation only causes more confusion as we ask "does a material have to be manufactured?" After all, we have the term "raw material," which the Oxford English Dictionary defines as "the basic material from which a product is manufactured or made; unprocessed material."<ref name="OEDRawMat">{{cite web |url=https://www.oed.com/search/dictionary/?scope=Entries&q=raw+material |title=raw material |work=Oxford English Dictionary |accessdate=20 September 2023}}</ref> Additionally, chemical elements are defined as "the fundamental materials of which all matter is composed."<ref>{{Cite web |last=Lagowski, J.J.; Mason, B.H.; Tayler, R.J. |date=16 August 2023 |title=chemical element |work=Encyclopedia Britannica |url=https://www.britannica.com/science/chemical-element |accessdate=20 September 2023}}</ref> Taking into account the works of Richardson and Peterson, Mies, and Swindells, as well as ISO 10303-45, the concepts of "raw materials" and "chemical elements," and modern trends towards the inclusion of biomaterials (though discussion of biomaterials will be limited here) in materials science, we can land on the following definition for the purposes of this guide:


===Features and benefits===
:A material is discrete matter that is elementally raw (e.g., native metallic and non-metallic elements), fundamentally processed (e.g., calcium oxide), or fully manufactured (by human, automation, or both; e.g., a fastener) that has an inherent set of properties that a human or automation-driven solution (e.g., an [[artificial intelligence]] [AI] algorithm) has identified for a potential or realized use environment.
The answer to the first question is largely the same as most other kinds of labs. The benefits of laboratory informatics software include:


* increased accuracy, with a minimization or elimination of transcription and other errors;
First, this definition more clearly defines the types of matter that can be included, recognizing that manufactured products may still be considered materials. Initially this may seem troublesome, however, in the scope of complex manufactured products such as automobiles and satellites; is anyone really referring to those types of products as "materials"? As such, the word "discrete" is included, which in manufacturing parlance refers to distinct components such as brackets and microchips that can be assembled into a greater, more complex finished product. This means that while both a bolt and an automobile are manufactured "products," the bolt, as a discrete type of matter, can be justified as a material, whereas the automobile can't. Second—answering the question of "what if a particular matter exists today but hasn't been thoroughly studied to determine its value to researchers and industrialists?"—the definition recognizes that the material needs at a minimum recognition of a potential use case. This turns out to be OK, because if no use case has been identified, the matter still can be classified as an element, compound, or substance. It also insinuates that that element, compound, or substance with no use case isn't going to be used in the manufacturing of any material or product. Third, the definition also recognizes the recent phenomena of autonomous systems discovering new materials and whether or not those autonomous systems should be credited with inventorship.<ref>{{Cite journal |last=Ishizuki |first=Naoya |last2=Shimizu |first2=Ryota |last3=Hitosugi |first3=Taro |date=2023-12-31 |title=Autonomous experimental systems in materials science |url=https://www.tandfonline.com/doi/full/10.1080/27660400.2023.2197519 |journal=Science and Technology of Advanced Materials: Methods |language=en |volume=3 |issue=1 |pages=2197519 |doi=10.1080/27660400.2023.2197519 |issn=2766-0400}}</ref> The question of inventorship is certainly worth discussion, though it is beyond the scope of this guide. Regardless, the use of automated systems to match a set of properties of a particular matter to a real-world use case isn't likely to go away, and this definition accepts that likelihood.
* streamlined processes, where each step in a protocol or method is completed in the proper order, with all requirements met, updating statuses automatically;
* automation of integrated instruments, allowing for automatic uploading of samples/specimens and processing of results;
* regulatory and standards compliance for your procedures helps keep you doing the right things the right ways, while tracking history so you can provide documentation when you need to;
* data security via configurable role-based secure access to data, processes, reporting, etc.;
* custom reporting tools, which allow you to design and generate reports to your own specifications, incorporating exactly the information you want;
* instant data retrieval, allowing you to search and call up any information instantly according to any criteria (date range, test, product type, etc.), particularly useful during audits; and
* cost-effectiveness through improved efficiency and accuracy, which means less waste of time, and if a user-configurable system (as opposed to hard-coded, requiring development for any modifications), its return on investment {ROI) increases over time, due to built-in adaptability and thus longevity.


===Budgeting===
Finally, this leads us to the realization that materials, by definition, are inherently linked to the act of intentional human- or automation-driven creation, i.e., manufacturing and construction.
The second question of budget is more difficult to answer by the fact that laboratory informatics software comes in all kinds of price ranges, from over $1 million all the way down to free. How are you supposed to honestly judge where the appropriate system price for your lab lies?


There are some basic realities that can help in figuring an appropriate budget, however.


1. A rough sense of price can generally be based on how much ownership you want in the software itself and how many will be using the laboratory informatics solution.
===1.1 Materials testing labs, then and now===


''Ownership: Buying versus renting'': There are two primary ways to price laboratory informatics software: a one-time license fee or a subscription (cloud-hosted [[software as a service]] or SaaS ). If you have your own dedicated IT department and staff, you may prefer the former. Otherwise, a SaaS-based subscription may well be the better and more cost-effective way to go (no IT costs at all other than internet access). This item will be part of your up-front cost and, in the case of a subscription, it will also figure in your first year and ongoing costs. A vendor may have a subscription fee of say $500, with the initial month due at signing. However, more often the vendor may require three months or even the first year up front, so be prepared to factor that into up-front costs. However, it still is almost always less expensive at the outset (and over time, if you factor in IT and service costs) than paying for a license fee.
====1.1.1 Materials testing 2.0====


''User numbers: Named versus concurrent'': In addition to the two types of software pricing above, there are pricing sub-types. Generally these are based on the number of users (or, in some cases, "nodes," which are simply any entities that access the software, including other systems, instruments, etc.). How these are counted can vary. They may be counted as "named" users, which bases pricing on the actual individual users of the system, even if they may only log in once in awhile. Users typically may not use each other's logins (this is prohibited regardless of pricing structure, for GxP and other standard- and regulatory-based reasons). They may also be counted as "concurrent" users, which bases pricing on the maximum number of users who will be logged in at any given time. You can define an unlimited number of named users in the system, each with their own login credentials. However, only the number of (concurrent) users specified in the license/subscription may be logged in at any one time. For example, you may have 10 staff, but due to work processes, shifts, etc., only up to six might ever be logged in simultaneously. Whereas this would require a named user license for 10, it would only require a concurrent user license for six. Finally, you may have the option for "unlimited" users. This may be useful for huge labs (typically 30 to 50 and up), where the license or subscription may simply be a flat fee that allows any number of users.
*https://onlinelibrary.wiley.com/doi/full/10.1111/str.12434
*https://onlinelibrary.wiley.com/doi/full/10.1111/str.12370


2. Most costs are related to work. Try to choose a solution that has what you need out of the box, as much as possible. The more customized or unique options you ask for, the more it costs, because extra items are a function of the time it takes developers to add them.


3. User-configurable solutions beat vendor-configurable solutions on cost-effectiveness. Many software vendors offer a free or low-cost option, but don't be fooled. They are in business to make money, and they are counting on the fact that you'll need to pay them to make things work, add necessary functionality, support, training, etc. If you can find one who offers a genuinely user-configurable solution, and whose manuals and other support materials are clearly helpful and available so you can adjust things the way you want, when you want, then that will go a long way toward budget efficiency and longevity.
===1.2 Industries, products, and raw materials===


4. Interfaces cost money. If necessary, consider whether it's feasibly or not to phase in those instrument and other interfaces over time, as revenue eases cash flow. You may be able to go live with your laboratory informatics solution more quickly, entering results manually until you can afford to interface your instruments one-by-one. This goes for reports too. A standard report will do. You can make fancy ones later.


Pricing will vary depending on what kind of solution you need. For example, you'll probably want to budget a minimum of around $40,000 to $80,000 plus or minus, minimum, (including setup, training, interfaces, etc.) for a decent, bang-for-your-buck [[laboratory information management system]] (LIMS) with maybe an interface or two, plus an additional $300 to $900 per month (depending on number of users) for ongoing subscriptions. At around five concurrent (logged in at the same time) users, the economics start to favor purchasing perpetual licenses rather than paying subscription. Purchased licenses will also entail ongoing annual or monthly costs as well (maintenance, support, warranty for updates etc.), but somewhere around that number of users it may tend to be cheaper than a subscription option. Subscriptions (if available) are generally aimed at smaller labs. If you will be growing and scaling up, it may be a great way to get started, but ensure you have the option to switch to perpetual licenses later.
===1.3 Laboratory roles and activities in the industry===


===Demonstration and requirements===
====1.3.1 R&D roles and activities====
You no doubt are quite familiar with all of your lab's or potential lab's processes, but that doesn't mean you necessarily have even an inkling about how exactly a laboratory informatics solution fits into your workflow. That's pretty common, and it's fine. That's what software companies should be able to show you. A good developer already generally understands your kind of lab but will ask you a lot of questions about exactly how you do things. It's the exceptions that need catering to. Doing a live demo (online is actually even better than in-person; it can be recorded so you can review and share it as much as you want) is a great context for exploring how a candidate software solution performs the functions your lab needs. It is interactive and live, so there can be no tricks—you see just how it performs in real time, and you can throw as many intricate scenarios at the developer as you like. The demo experience can go a long way towards giving you a real feel for the software's suitability. Additionally, you can both (laboratory and vendor) gain a budgetary idea of cost based on what you do, what you want the software to do, what it can do, as well as the product and services pricing itself.


One note: too often labs think the first thing they must do is create a requirements list, then sit back and let the software vendors tell them how they meet those requirements. As mentioned earlier, even though laboratory personnel understand their lab and its processes, most don't have much of a clue about laboratory informatics and workflow integration. Participating in a a demo before creating the requirements list is a great way to plug in the features you have seen demonstrated to your lab's to your own processes and needs. After all, how can you effectively require specific functions if you don't fully know what a given laboratory informatics tool is capable of? After the demo, you are much more equipped to create a requirements list that becomes the contractual product set and statement/scope of work (SOW) that represents your laboratory informatics solution.
====1.3.2 Pre-manufacturing and manufacturing roles and activities====


==Implementation==
====1.3.3 Post-production quality control and regulatory roles and activities====
Features, budget, and requirements aside, you'll also want to consider what implementation details will affect your overall bottom line. There are two main keys to successful implementation: having an accurate SOW and high team availability.


:1. ''Accurate SOW'': A statement of work or SOW describes the work that will be done by the vendor, including milestones, deliverables, and any other end products and services. It should be absolutely clear in both your and the vendor's minds exactly what the delivered, operational laboratory informatics solution should look like. If possible, ask for a validation script that addresses each function and process. Read through it and make sure you agree with each test, that it is an effective measure of the software function it purports to validate. If not, work with the vendor to modify it to your satisfaction. Remember, vendors are required to meet exactly what the contracted requirements are, no more or no less. The SOW should avoid ambiguity in all cases. If they are worded poorly, the delivered item may not match what you envisioned. This is also where the demo—mentioned previously—comes in handy. If it is documented (e.g., recorded), you can always use language like "per demo" or "as demonstrated in demo" so there is no question how a feature is supposed to work for you.
==References==
 
{{Reflist|colwidth=30em}}
:2. ''High team availability'': Make your team available. Far too many laboratory informatics solution implementations drag on way past what is needed simply because the lab doesn't keep up with the process. While regular daily operations consume a lot of time, and it can be very difficult to allocate extra time for bringing on the new software, it's best to just make the time. The initial energy and impetus of the implementation project—which can take as few as a couple of weeks—disappear surprisingly quickly once delays set in. Interest wanders and a once-great initiative becomes a nagging burden. The single greatest thing you can do to avoid this is allocate the right person(s) to focus on successfully getting the system in place on time and on (or under) budget. That means plenty of communication with the vendor's project manager, executing the training and any configuration tasks your lab is responsible for, and signing off when tasks are complete. You may be surprised how often unsuccessful implementations are actually the fault of the customer.
 
===Implementation details===
The implementation itself can be quite simple for a pretty standard system. The minimum scenario would be one to five users, no customization, no configurations beyond standard setup (name the lab's location and any departments, add users, lab logo, address, etc. to report, enter contacts), no interfaces and around two hours of training (online, recorded for reference). And if the solution is cloud-hosted, there is no time (i.e., money) wasted in buying and/or setting up servers, firewalls, etc., so the solution itself can optimistically be in place and running in a day. The rest is up to you; figure something like one to three weeks to go live (a little more if your schedule is tight).
 
A larger and/or more comprehensive implementation can include several components and be rolled out in phases over one to three months or so. In fact, you can be operational manually for as long as you need to be, bringing instrument interfaces in over time as your budget permits, which allows you to begin using the solution earlier.
 
All of the phases and their deliverables have price tags associated with them. Your total cost is a function of the license fee or subscription plus the work the vendor performs. The work they do (and the work you do) is what constitutes the implementation and its phases. They can include (in order):
 
* Project management: The vendor will provide a project manager to coordinate with you and make sure all deliverables are implemented on time and according to the contract. The cost of this is a function of their hours, which begin at the initial meeting (kickoff) and end once your system goes live and all deliverables have been met.
 
* Kickoff meeting: This is the initial get-together between your project manager and theirs. Review the SOW and the plan to implement it, and clarify resource and time commitments and responsibilities, making sure the schedule works for everybody.
 
* System installation: If it's to be an onsite installation (discussed later), then your system administrator and the vendor's technical representatives will need to work closely to make sure this is done properly. If the vendor is hosting it for you, the system should be spun up and available for you to log in to within a day or so.
 
* Gap analysis: This is the identification or verification of the gap between the system as installed and the system as fully functional according to the contract. There should not be any surprises here. If there are (and not good ones), the vendor should rectify them speedily and at no extra charge.
 
* Work plan (system acceptance test plan): This is the deliverable that spells out essentially what was discussed in the kickoff, with the gap analysis factored in. It's what will be worked towards in order to get to a fully functional, contractually complete system. It should include all tasks, including your verification and sign-off of each deliverable.
 
* Administrator training: Whether a small and simple setup or something more complex, this is important and integral. Get it online and record it if you can. That way you can refer to it as often as you need to, and also use it to train new administrators.
 
* Configuration and customization: This is really the bulk portion of implementation. It includes the standard configuration of the solution, plus any extras: instrument interfaces, system/software/agency interfaces, additional custom reports, screen modifications, new fields, etc. (beyond standard setup), adding tests, custom notifications/alerts, web portal configuration, additional training, etc.
 
* System validation and acceptance: This should be going on throughout the implementation as you sign off on each completed task. Then the final acceptance of the complete system is simply a matter of final overall review and sign-off. A more comprehensive validation involves test scripts for each function, and you will need to go through each, noting pass/fail and any comments. If more work is needed to bring things up to full acceptance level, the vendor (or you, if it was your responsibility) should apply whatever resources necessary to swiftly bring the items to acceptance level.
 
* User training: Like admin training, user training is essential for a professional, dedicated laboratory informatics system. And in the same ways, online training by job function is the most effective method, enabling recorded sessions to be referred back to by the trainees and used for repeat and additional staff training.
 
* Go-live support: As with any new informatics system, it is a great contributor to a successful launch if the vendor's support staff are readily available during the initial "go-live" period. This may be a few days, a week or two, or a month, depending on complexity, number of users/samples, etc.
 
* One year (times X) maintenance and support: This recurring item can be included with your monthly or annual subscription if your solution is a cloud-hosted SaaS one. Otherwise, if you purchase licenses (the vendor may still offer cloud-hosting if you want), then this is a separate annual fee. It's usually wise to include this, at least for the first few years so that updates and upgrades are included, and support hours help your users as they become more comfortable and proficient. Cost usually is around 15-20% of original license fee annually, or bundled into a subscription automatically.
 
==Services==
When calculating the overall costs associated with implementing your laboratory informatics solution, don't forget to include calculations of services. No matter how pre-configured the solution may be, any professional laboratory informatics solution will require some amount of standard setup to reflect your particular lab, e.g., lab name and contact details for reports/COA, entering users and their roles/access permissions, adding and/or modifying tests and processes/workflows, renaming some fields, adding/hiding fields, setting up a web portal, interfaces, etc. As mentioned previously, equally indispensable is proper training for both administrators and users. And you may find at any time that you would like additional features or functions. The services here are listed in hourly units. (Again, be very careful if any items that are services-based are listed as fixed-price items.)
 
Services can include:
 
* Kickoff meeting: initial planning, identify delta, set schedule, etc.
* Project management
* Setup
* Training (user and admin)
* Additional configurations and/or customization
** Interfaces
** Custom screens
** Custom reports and labels
** Additional triggers, alerts, etc.
** Additional or custom functionality
* Validation/Acceptance testing: either to a third-party standard (certification) or to manufacturer claims/specs/contract
* Hosting
 
===Hosting===
From the previous list of services, most items have been talked about in some regard, but the hosting of your software deserves a few additional comments. There is strong "service" component that comes with whoever is responsible for hosting your laboratory informatics solution, whether that's you (self-hosted) or some other provider (cloud-hosted).
 
If you choose to self-host the software, you will have most likely decided to buy the software license rather than rent the solution via a subscription. This is typically the domain of larger businesses that have their own IT department with the knowledge and budget to tackle most of the implementation and much of the maintenance. Even then, there may be times where outside IT help and/or support is required from a consultant or the original software vendor, and this must be calculated into any potential future costs.
 
If you choose to cloud-host the software, you're either hosting the software on your company's cloud (if they are large enough to have such resources in the first place) or, more likely, you're choosing another company to host the software for you. Regardless of whether its you or another company, several questions emerge about the cloud facilities:
 
* Does the cloud hosting provider provide purpose-built, reliable and secure cloud hosting infrastructure housed in a state-of-the-art data center that is SSAE 16 SOC 2 certified?
* Are industry standard hardware, software, and configuration practices employed, ensuring first-class performance, security and reliability, with a full 100% uptime guarantee?
* Are global cloud networks employed to provide a seamless global cloud hosting service?
* Can facility meet the special requirements for [[HIPAA]], [[CLIA]], [[21 CFR Part 11]], or other regulatory compliance data? For example, does it have comprehensive redundancy, failover, data backup and protection (database backups and system-wide backups in secondary location for redundancy), and SSL security and encryption?
 
Of course, the software can not only be hosted in the cloud but also be served up as a service, typically arranged through the vendor. This SaaS-based approach has its own advantages, as previously discussed.
 
==Maintenance, support, and warranty==
The maintenance, support and warranty (MSW) offered by the vendor you choose is almost as important as the laboratory informatics solution itself. The solution is likely to become mission-critical, so having a reliable and responsive team and resources available 24/7 is hugely important in retaining operational and competitive status. Downtime can negatively affect not only immediate customer satisfaction but also your reputation. And professional reputations take a long time and hard work to build, though they can be destroyed swiftly and easily.
 
As such, when budgeting for a solution, be sure to ask about the company's MSW coverage. Determine what it includes exactly, what it doesn't, and the cost. For example, a purchased LIMS will usually include an MSW as a percentage of the license fee, typically 15-20% annually. It should include some support hours (check how many) so your users can contact the company and get help when they encounter problems, as they are still learning the details and becoming comfortable with the system (that's called support). It should include updates and upgrades (maintenance), and unlimited free fixes of any bugs (warranty).
 
If the solution is a cloud-hosted, SaaS system, then these are typically rolled in with the annual or monthly subscription (and are typically less costly anyway, since it's easier for the vendor to access and work with the system). Even a purchased, perpetual licensed solution may be available as a cloud-hosted option, and it may be at a lower rate than if you host it yourself (for the same reason). And you have the added bonus of not needing your own servers and IT personnel.
 
Finally, any provider should warranty (stand behind) all of their work for as long as you are our customer. Any customization work, setup, or configurations they do should also be guaranteed; if they don't work, they should be corrected to perform the way they're supposed to at no additional charge.
 
==Putting it all together==
After considering all the above, it's time to put it all together. The importance of an accurate statement of work, as reflected in the sales agreement, can't be understated. Each line item should clearly show exactly what is expected, being as specific as possible, since this will be the entire contractual obligation for both parties. Obviously, the line items may differ from system to system somewhat, according to what features and functions are included by default with the laboratory informatics solution and which, if any, are additional. While the contract SOW is always ultimately an estimate, if careful attention was paid to the above, then it should be quite accurate, and in fact the final cost may even be below the quoted cost if you prioritize your own obligations so that the vendor's hours are used sparingly and efficiently.
 
The costs can be a mixture of subscriptions (annual and/or monthly), fixed one-time costs (unit of "Each") and/or hourly services. However, the reality is that they really are either license/subscription or services. Any fixed costs for other items are really for services, and represent one of two possible scenarios:
 
* Final fixed cost: In this case, the cost has been figured by the vendor so as to cover their worst-case hourly labor total. If the item (typically interfaces) is not "worst case," then you are overpaying.
* "Expandable" fixed cost: This is as bad as final fixed cost, and maybe even worse because it's almost a case of "bait-and-switch," popping up as a surprise. The initial "fixed cost" number is low, and additional hourly services are needed to actually deliver the item. This will have been provided for somewhere in the small print. The bottom line is that everything in the solution is really either licensing or hourly services. Just be careful if they are portrayed as anything else.
 
It is important to be clear which category each line item falls under when figuring costs, which can be divided into 1. up-front (due upon signing), 2. annual, and 3. ongoing (e.g., SaaS subscription). It is useful to clearly lay out each and compute initial costs, as well as first year and subsequent years' costings.
 
As an example, imagine you're considering a cloud-based SaaS LIMS:
 
1. Initial: Your initial layout may be as little as your first month's subscription plus the first 40 hours of services, say $500 + $6600 = $7,100. Different vendors have different policies, however, and you may be required to pay for your first full year's subscription and no services, or some other combination. Normally, though, any instrument interface or other services charges aren't due until  they are implemented, which may be a few weeks or even a month or so down the road, depending on your budget, complexity of the SOW, and urgency.
 
2. First year: Your first year's expenses will include everything, including initial license fees, all setup and training, any interfaces and additional configurations or customization, and first annual maintenance, service, and warranty (MSW). (If this isn't included in the SaaS subscription, then it usually commences on full system delivery).
 
3. Ongoing: Your subscription and MSW will be the only ongoing expenses (included as one in this example), unless you choose to have additional interfaces or other services performed at any time.
 
Your total laboratory informatics software costs are tallied according to the licenses or subscriptions and hourly services, plus any additional MSW. Two ways to help maximize affordability and success are 1. as stated before, make sure you plan as thoroughly as possible and set aside sufficient funding for the lab operation you envision, and 2. plan out your implementation, perhaps staggering some of the major non-central items to be phased in over time in favor of getting operational with your solution as early as possible.

Latest revision as of 23:51, 20 September 2023

This is sublevel10 of my sandbox, where I play with features and test MediaWiki code. If you wish to leave a comment for me, please see my discussion page instead.

Sandbox begins below

1. Introduction to materials and materials testing laboratories

What is a material? This question is surprisingly more complex for the layperson than may be expected. The definition of "material" has varied significantly over the years, dependent on the course of study, laboratory, author, etc. A 1974 definition by Richardson and Peterson that has seen some use in academic study defines a material as "any nonliving matter of academic, engineering, or commercial importance."[1] But recently biomaterials like biopolymers (as replacements for plastics)[2] and even natural[3] and engineered biological tissues[4] may be referenced as "materials." (And to Richardson and Peterson's credit, they do add in the preface of their 1974 work that "[a]lthough the volumes are directed toward the physical sciences, they can also be of value for the biological scientist with materials problems."[5] A modern example would be biodegradable materials research for tissue and medical implant engineering.[6]) Yet today more questions arise. what of matter that doesn't have "academic, engineering, or commercial importance"; can it now be called a "material" in 2023? What if a particular matter exists today but hasn't been thoroughly studied to determine its value to researchers and industrialists? Indeed, the definition of "material" today is no easy task. This isn't made easier when even modern textbooks introduce the topic of materials science without aptly defining what a material actually is[7], let alone what materials science is.[8] Perhaps the writers of said textbooks assume that the definitions of "material" and "materials science" have a "well duh" response.

To complicate things further, a material can be defined based upon the context of use. Take for example the ISO 10303-45 standard by the International Organization for Standardization (ISO), which addresses the representation and exchange of material and product manufacturing information in a standardized way, specifically describing how material and other engineering properties can be described in the model/framework.[9][10] The context here is "standardized data transfer of material- and product-related data," which in turn involves ontologies that limit the complexity of materials science discourse and help better organize materials and product data into information and knowledge. As such, the ISO 10303 set of standards must define "material," and 10303-45 complicates matters further in this regard (though it will be helpful for this guide in the end).

In reviewing ISO 10303-45 in 2009, Swindells notes the following about the standard[10]:

The first edition of ISO 10303-45 was derived from experience of the testing of, so-called, "materials" properties, and the terminology used in the standard reflects this experience. However, the information modelling of an engineering material, such as alloyed steel or high density polyethylene, is no different from the information modelling of a "product." The "material" properties are therefore one of the characteristics of a product, just as its shape and other characteristics are. Therefore all "materials" are products, and the information model in ISO 10303-45 can be used for any property of any product.

Put in other words, for the purposes of defining "material" for a broader, more standardized ontology, materials and products can be viewed as interchangeable. Mies puts this another way, stating that based on ISO 10303-45, a material can be defined as "a manufactured object with associated properties in the context of its use environment."[11] But this representation only causes more confusion as we ask "does a material have to be manufactured?" After all, we have the term "raw material," which the Oxford English Dictionary defines as "the basic material from which a product is manufactured or made; unprocessed material."[12] Additionally, chemical elements are defined as "the fundamental materials of which all matter is composed."[13] Taking into account the works of Richardson and Peterson, Mies, and Swindells, as well as ISO 10303-45, the concepts of "raw materials" and "chemical elements," and modern trends towards the inclusion of biomaterials (though discussion of biomaterials will be limited here) in materials science, we can land on the following definition for the purposes of this guide:

A material is discrete matter that is elementally raw (e.g., native metallic and non-metallic elements), fundamentally processed (e.g., calcium oxide), or fully manufactured (by human, automation, or both; e.g., a fastener) that has an inherent set of properties that a human or automation-driven solution (e.g., an artificial intelligence [AI] algorithm) has identified for a potential or realized use environment.

First, this definition more clearly defines the types of matter that can be included, recognizing that manufactured products may still be considered materials. Initially this may seem troublesome, however, in the scope of complex manufactured products such as automobiles and satellites; is anyone really referring to those types of products as "materials"? As such, the word "discrete" is included, which in manufacturing parlance refers to distinct components such as brackets and microchips that can be assembled into a greater, more complex finished product. This means that while both a bolt and an automobile are manufactured "products," the bolt, as a discrete type of matter, can be justified as a material, whereas the automobile can't. Second—answering the question of "what if a particular matter exists today but hasn't been thoroughly studied to determine its value to researchers and industrialists?"—the definition recognizes that the material needs at a minimum recognition of a potential use case. This turns out to be OK, because if no use case has been identified, the matter still can be classified as an element, compound, or substance. It also insinuates that that element, compound, or substance with no use case isn't going to be used in the manufacturing of any material or product. Third, the definition also recognizes the recent phenomena of autonomous systems discovering new materials and whether or not those autonomous systems should be credited with inventorship.[14] The question of inventorship is certainly worth discussion, though it is beyond the scope of this guide. Regardless, the use of automated systems to match a set of properties of a particular matter to a real-world use case isn't likely to go away, and this definition accepts that likelihood.

Finally, this leads us to the realization that materials, by definition, are inherently linked to the act of intentional human- or automation-driven creation, i.e., manufacturing and construction.


1.1 Materials testing labs, then and now

1.1.1 Materials testing 2.0


1.2 Industries, products, and raw materials

1.3 Laboratory roles and activities in the industry

1.3.1 R&D roles and activities

1.3.2 Pre-manufacturing and manufacturing roles and activities

1.3.3 Post-production quality control and regulatory roles and activities

References

  1. ↑ Richardson, James H.; Peterson, Ronald V. (1974). "Chapter 1: Introduction to Analytical Methods". Systematic Materials Analysis, Part 1. Materials science series. New York: Academic Press. p. 2. doi:10.1016/B978-0-12-587801-2.X5001-0. ISBN 978-0-12-587801-2. https://books.google.com/books?id=BNocpYI8gJkC&printsec=frontcover&dq=Systematic+Materials+analysis&hl=en&newbks=1&newbks_redir=0&sa=X&ved=2ahUKEwjB1OeQx-aAAxWnmmoFHSV2BSsQ6AF6BAgMEAI#v=onepage&q=Systematic%20Materials%20analysis&f=false. 
  2. ↑ Das, Abinash; Ringu, Togam; Ghosh, Sampad; Pramanik, Nabakumar (1 July 2023). "A comprehensive review on recent advances in preparation, physicochemical characterization, and bioengineering applications of biopolymers" (in en). Polymer Bulletin 80 (7): 7247–7312. doi:10.1007/s00289-022-04443-4. ISSN 0170-0839. PMC PMC9409625. PMID 36043186. https://link.springer.com/10.1007/s00289-022-04443-4. 
  3. ↑ Kurniawan, Nicholas A.; Bouten, Carlijn V.C. (1 April 2018). "Mechanobiology of the cell–matrix interplay: Catching a glimpse of complexity via minimalistic models" (in en). Extreme Mechanics Letters 20: 59–64. doi:10.1016/j.eml.2018.01.004. https://linkinghub.elsevier.com/retrieve/pii/S2352431617301864. 
  4. ↑ Kim, Hyun S.; Kumbar, Sangamesh G.; Nukavarapu, Syam P. (1 March 2021). "Biomaterial-directed cell behavior for tissue engineering" (in en). Current Opinion in Biomedical Engineering 17: 100260. doi:10.1016/j.cobme.2020.100260. PMC PMC7839921. PMID 33521410. https://linkinghub.elsevier.com/retrieve/pii/S246845112030057X. 
  5. ↑ Richardson, James H.; Peterson, Ronald V. (1974). "Preface". Systematic Materials Analysis, Part 1. Materials science series. New York: Academic Press. p. xiii. doi:10.1016/B978-0-12-587801-2.X5001-0. ISBN 978-0-12-587801-2. https://books.google.com/books?id=BNocpYI8gJkC&printsec=frontcover&dq=Systematic+Materials+analysis&hl=en&newbks=1&newbks_redir=0&sa=X&ved=2ahUKEwjB1OeQx-aAAxWnmmoFHSV2BSsQ6AF6BAgMEAI#v=onepage&q=Systematic%20Materials%20analysis&f=false. 
  6. ↑ Modrák, Marcel; Trebuňová, Marianna; Balogová, Alena Findrik; Hudák, Radovan; Živčák, Jozef (16 March 2023). "Biodegradable Materials for Tissue Engineering: Development, Classification and Current Applications" (in en). Journal of Functional Biomaterials 14 (3): 159. doi:10.3390/jfb14030159. ISSN 2079-4983. PMC PMC10051288. PMID 36976083. https://www.mdpi.com/2079-4983/14/3/159. 
  7. ↑ Callister, William D.; Rethwisch, David G. (2021). "Chapter 1. Introduction". Fundamentals of materials science and engineering: An integrated approach. Hoboken: Wiley. pp. 2–18. ISBN 978-1-119-74773-4. https://books.google.com/books?id=NC09EAAAQBAJ&newbks=1&newbks_redir=0&printsec=frontcover. 
  8. ↑ Sutton, Adrian P. (2021). Concepts of materials science (First edition ed.). Oxford [England] ; New York, NY: Oxford University Oress. ISBN 978-0-19-284683-9. 
  9. ↑ "ISO 10303-45:2019 Industrial automation systems and integration — Product data representation and exchange — Part 45: Integrated generic resource: Material and other engineering properties". International Organization for Standardization. November 2019. https://www.iso.org/standard/78581.html. Retrieved 20 September 2023. 
  10. ↑ 10.0 10.1 Swindells, Norman (2009). "The Representation and Exchange of Material and Other Engineering Properties" (in en). Data Science Journal 8: 190–200. doi:10.2481/dsj.008-007. ISSN 1683-1470. http://datascience.codata.org/articles/abstract/10.2481/dsj.008-007/. 
  11. ↑ Mies, D. (2002). "Chapter 17. Managing Materials Data". In Kutz, Myer. Handbook of materials selection. New York: J. Wiley. p. 499. ISBN 978-0-471-35924-1. https://books.google.com/books?id=gWg-rchM700C&pg=PA499. 
  12. ↑ "raw material". Oxford English Dictionary. https://www.oed.com/search/dictionary/?scope=Entries&q=raw+material. Retrieved 20 September 2023. 
  13. ↑ Lagowski, J.J.; Mason, B.H.; Tayler, R.J. (16 August 2023). "chemical element". Encyclopedia Britannica. https://www.britannica.com/science/chemical-element. Retrieved 20 September 2023. 
  14. ↑ Ishizuki, Naoya; Shimizu, Ryota; Hitosugi, Taro (31 December 2023). "Autonomous experimental systems in materials science" (in en). Science and Technology of Advanced Materials: Methods 3 (1): 2197519. doi:10.1080/27660400.2023.2197519. ISSN 2766-0400. https://www.tandfonline.com/doi/full/10.1080/27660400.2023.2197519. 
Retrieved from "https://www.limswiki.org/index.php?title=User:Shawndouglas/sandbox/sublevel10&oldid=53066"